Routes to enshrining a settlement layer in Celestia

Celestia is unique among L1 designs because it doesn’t have smart contract functionality. It instead opted for as simple a design as possible – eliminating execution in the process. The idea is that other blockchains, like rollups, can be the place for users to deploy smart contracts. At the same time, Celestia provides rollups with the scalable infra they need (consensus and data availability).

In the face of giving up smart contracts, Celestia can’t provide rollups with any settlement services. While settlement is a relatively vague term, there are a few things that a settlement layer with smart contracts can provide.

  • A bridging hub that facilitates token transfers between rollups.
  • Dispute resolution for verifying fraud proofs and resolving disputes.
  • A source of liquidity.

As it stands, if a rollup is intent on using Celestia but wants any of the settlement functionality listed above, it can use a settlement layer on top of Celestia. Really, this settlement layer would just be a rollup (so we end up with a rollup on a rollup).

While stacking rollups for settlement is one potential solution, what other routes could Celestia take to enshrine a settlement layer?

Adding smart contracts

Bringing smart contract functionality to Celestia seems counterintuitive, considering it was explicitly designed not to have them. The main problem with adding smart contracts is that it negates many of the benefits it receives from not having smart contracts in the first place. Some of these trade-offs:

  • Nodes need to verify transaction validity in addition to the block header and data availability. They must consume and provide resources to the network other than bandwidth. Celestia can no longer take advantage of simple gas accounting (charge gas based on the size of data that rollups publish) but must now consider all fields related to smart contract gas pricing, like execution and state storage costs.
  • Light nodes would lose their trust-minimized security properties unless a proof system is added that allows them to verify transactions without re-executing the entire block. Without a proof system, the security properties of light nodes would no longer be equivalent to that of Celestia full nodes.
  • The problem of state growth would be re-introduced. Celestia, as it stands, reduces state growth to the minimal possible rate (account balances and validator set info). Adding smart contracts brings back all the potential problems that are associated with a bloated state, like performance bottlenecks and increased node requirements.

Celestia does use the Cosmos SDK, so it does have a direct route to integrate smart contracts via something like CosmWasm. One additional benefit of adding smart contracts is that Celestia could have trust-minimized bridges between its rollups for migrating tokens.

Aside from that, making Celestia a smart contract L1 brings about a significant number of trade-offs, many of which are likely undesirable.

An execution shard

This idea would entail adding another blockchain that is tied to Celestia. The main Celestia chain would remain minimal, while the shard would have smart contracts for rollup settlement. There are a couple of ways this could take shape.

  1. Celestia validators become validators for the shard: transactions get processed on the shard with the validators going through a consensus process every X seconds. The Merkle root of each confirmed block is checkpointed into the Celestia main chain.
  2. Celestia validators become block producers for the shard: transactions are processed and bundled into blocks by the block producers. The blocks get published to the Celestia main chain with any fraud/validity proofs. In this instance, the shard acts like a rollup (enshrined rollup).

Option 2 would make it significantly easier to maintain trust-minimized light nodes on the shard since it operates like a rollup with a proof system. Verifying the shard could be an opt in process to ease the burden on nodes. Using a light node as an example, node runners might have the option of:

  • Run a light node on the Celestia main chain
  • Run a light node on the shard
  • Run a light node on both the main chain and the shard

Regardless, if nodes want full security guarantees, they should verify both the main chain and the shard, which means increased hardware requirements. Nodes on the shard must also take an interest in transaction validity instead of just consensus and data availability. However, proofs are a scalable way to keep overhead low for verifying transactions – though they aren’t without their own trade-offs.

One potentially glaring problem is that sharding could significantly increase protocol and engineering complexity. If Ethereum’s growing technical debt is any sign, blockchains should strive for less complexity wherever possible.

Interchain security

An alternative route to sharding is possible – interchain security. The concept of interchain security is that the validators of a given chain opt in to become validators for a subsidiary chain. The subsidiary chain can be an independent chain in its own right – have a separate community – while inheriting security from the provider chain.

What Celestia can use interchain security for is to bring another chain under its security without creating a shard that is inextricably tied to the protocol. There’s also nothing stopping the enshrined settlement layer from being an L1 or a rollup on top of Celestia.

Interchain security is managed via a module in the cosmos SDK, which would introduce significantly less complexity in bootstrapping and maintaining the enshrined settlement layer than execution sharding.

Since the enshrined settlement layer would be a distinctly separate blockchain, there would be no additional requirements from nodes verifying Celestia. Only the Celestia validators would be required to participate in validating it. Nodes could also choose to verify the settlement layer, but they wouldn’t lose security guarantees if they decided not to.

The security model of the bridge between Celestia and its enshrined settlement layer would depend on its implementation. Would it be standard IBC, custom IBC with fraud/validity proofs, or a more esoteric bridge solution?

At a brief glance, interchain security could allow Celestia to maintain all its technical benefits around scaling, and node requirements without the complexity of sharding or adding smart contracts directly to the chain.

Credible neutrality

There is a possible argument that Celestia loses some neutrality if it enshrines a settlement layer – putting it in competition with all settlement layers on top of it.

There are multiple reasons why the Celestia community may want to enshrine a settlement layer unrelated to competing in a new domain.

Ultimately, enshrining a settlement layer into Celestia is a decision that the community would likely make – perhaps through a governance vote or some off-chain social coordination. If the community believes it is in its best interest to enshrine a settlement layer, then maybe it is a path worth pursuing.