While Celestia is designed as a minimal blockchain with no smart contract environment, a future native Celestia token should not be restricted from interacting with applications that live outside of Celestia. This post briefly details some of the considerations between potential two way bridges to Celestia.
Spectrum of bridges (from most to least trust assumptions)
- Third party committee-based bridge
- Light client bridge (e.g. IBC)
- Trust minimized bridge (e.g. rollup bridge)
Third party committee-based bridge
Committee-based bridges that rely on external verification through a third-party present the weakest security assumptions. A quorum of the committee is required to approve bridge transactions, which are typically made up of a small set of participants (such as a 5 of 8 multi-sig). In this example, the security of the bridge is dependent on five committee members. If four collude to stop signing bridge transactions, the bridge will halt. If five collude they can steal funds that are locked in the bridge.
While the committee size and quorum are parameterizable, and some type of cryptoeconomic guarantees could increase the cost of collusion, such as staking and slashing, the level of security provided by such a bridge is likely insufficient.
Light client bridge
Natively verified bridges, like a light client bridge, only require the validators sets of the communicating chains to verify bridge transactions. IBC’s light client bridge relies on an honest majority of both communicating chains to ensure correctness, which is done through verifying block headers and Merkle proofs of the counterparties state transition. Because of this, the security of IBC is determined by that of the validator sets (stake distribution and amount of value staked in particular). Therefore, two communicating chains with sufficient stake distribution to minimize collusion, and sufficient staked value for economic security, can use IBC with relatively strong security guarantees.
To minimize security and engineering considerations, IBC connections to Celestia should be restricted to a small set of external chains. For example, only connecting to the Cosmos Hub would enable sufficient routes for bridging between Celestia and any Cosmos-based chain that has an IBC connection to the Hub – serving as a hub and spoke model. Limiting IBC connections also reduces considerations that the state machine would have to make if any Cosmos-based chain could create a direct IBC connection to Celestia.
Trust minimized bridge
Bridges that utilize fraud/validity proofs and verify data availability of the state transition require the weakest trust assumptions of all types of bridges. These types of bridges are used by rollups, where the base layer is responsible for verifying the state transitions of rollups. While trust minimized bridges present ideal trust properties, they are also vulnerable to implementation risks through smart contracts. However, Celestia does not possess an execution environment capable of implementing such a bridge using smart contracts. Therefore, to implement a trust minimized bridge between a rollup and Celestia, the rollup and its bridge would have to be enshrined into the chain as a shard. Although, this presents multiple challenges.
It increases the complexity of both building and maintaining Celestia (now there’s an execution shard). Additionally, it increases the overhead for validators that must ensure the validity of the shard and non-consensus nodes that verify its state transitions. While the overhead would be execution minimal (validity/fraud proofs) it would also increase bandwidth requirements from downloading the shard’s data.
Summing up the trust assumptions
- Third party committee-based bridge: M of N committee members where M is the quorum. Typically N is small – less than 10.
- Light client bridge: 2/3 of N of both communicating chains where N is the size of the validator set. Cosmos chains typically have between 100 and 150 validators.
- Trust minimized bridge: Fraud proofs - 1 of N where N is the number of rollup full nodes. Validity proofs - Soundness and completeness of the proof.
Summing up other considerations
- Third party committee-based bridge: They are generalizable and extensible but the quorum and committee size is typically very small.
- Light client bridge: IBC is a native module in the Cosmos SDK and connection to the Cosmos Hub gives access to all cosmos-based chains that have a Hub IBC connection.
- Trust minimized bridge: Increased protocol complexity and node overhead. Decreased credible neutrality if a pre-existing rollup is enshrined with a two-way bridge.