Continuum Technical Description

--- title: 'Continuum' disqus: hackmd --- Continuum === > The space-time continuum describes the series of points that could be occupied by something moving from the past, through the present, and into the future. ## Table of Contents [TOC] ## Overview Continuum is an **aggregated multi-chain interoperability protocol** that employs a *trustless* and *permissionless* infrastructure layer for transferring information and value between connected chains. It encompasses both a *general message-passing framework* and an *asset transfer framework*. Additionally, Continuum features a novel, multi-chain **protocol-owned treasury** designed to continuously create value within its ecosystem. **Aggregation** is a novel approach that combines the best of both worlds: the unified operation of a monolithic blockchain with the scale and efficiency of a modular blockchain stack. Advantages compared to other interoperability solutions: - **User perspective**: Unified, bridgeless UX - **Developer perspective**: Seamless cross-chain interactions accessing user bases across multiple blockchain networks - **Blockchain perspective**: Retain sovereignty without additional fragmentation Multi-chain Interoperability --- Interoperability is a spectrum of communication between different blockchain networks (*L1s*, *L2s*, etc.). One of the key properties of an interoperable ecosystem is asset portability. The *fair exchange problem* is a fundamental issue in computer science and cryptography, particularly relevant in the context of blockchain interoperability. It involves ensuring that two parties can exchange digital assets in such a way that either both parties receive the items they expect, or neither party does. The challenge is to accomplish this without relying on a *centralized trusted third party* (TTP) to facilitate or guarantee the exchange. > Read more about the [fair exchange problem](https://ethz.ch/content/dam/ethz/special-interest/infk/inst-infsec/information-security-group-dam/research/publications/pub2010/FairExchange.pdf) The Continuum protocol employs **trust-minimized cryptographic techniques** integrated into a *decentralized* and *permissionless* infrastructure to verify transactions and state changes across different blockchains without needing a centralized authority for coordination. Interoperability Trust Gradients --- Interoperability solutions can be classified based on their trust gradients, indicating the level of decentralization and security. #### Proof-of-Authority (PoA) and External Decentralized Verifier Networks (DVN) Uses private keys controlled by a central authority or information provided by external third parties (DVNs) to verify blockchain state and transactions. - Examples: LayerZero, Chainlink CCTP - Trust Level: Requires trust in the entities that run the DVN #### Multi-Party Computation (MPC) and Threshold Signature Schemes (TSS) Distributes the private key among a group of network participants using threshold signatures. It is a more decentralized approach than PoA if the TSS group is sufficiently large. However, scalability issues still arise when the TSS group is very large (i.e. more than 100). - Examples: Thorchain - Trust Level: Requires trust in the TSS group #### Consensus Verification Relies on the blockchain's own consensus mechanism to verify transactions. More decentralized and secure, as long as a significant portion of validators are honest. - Examples: Axelar - Trust Level: Requires trust in the validator set that runs the consensus. #### State Verification Uses cryptographic proofs, such as zero-knowledge proofs (zk-proofs), to verify the entire state of the blockchain. The highest level of security and decentralization, providing cryptographic assurance of state transitions without relying on any third-party intermediaries. State verification is performed by on-chain zk-on-chain light clients where zero-knowledge proofs are used to provide cryptographic guarantees of state transitions. Continuum aims to provide the most trust-minimized way to achieve permissionless interoperability. - **Decentralization**: By utilizing consensus verification, Continuum ensures a higher degree of decentralization compared to MPC or PoA-based solutions. - **Scalability**: Continuum's consensus layer based on a modified version of [CometBLS](https://union.build/docs/architecture/cometbls/) is decoupled to scale and support thousands of validators, enhancing the operation and security of the network. - **Future-Proofing**: Continuum's approach to state verification puts it in a pole position to achieve trustless and permissionless interoperability. In summary, Continuum addresses the limitations of traditional bridging solutions by focusing on consensus and state verification, thus providing a more secure, decentralized, and scalable approach to blockchain interoperability. Architecture --- A typical modular blockchain stack divides the monolithic design into distinct layers as follows: - **Execution layer**: Where transaction and state changes are executed. - **Settlement layer**: An optional layer where execution layers verify proofs, resolve fraud disputes, and connect to other execution layers. - **Consensus**: The layer where agreement on the order of transactions is performed. - **Data availability**: Ensures transaction data is available for every participant. Continuum's design philosophy is based on a **bridgeless architecture** to achieve trustless and permissionless transfer of value or information between different blockchains, by leveraging cryptographic truth represented by zero-knowledge consensus proofs. This design is robust, yet modular. It does **not** require additional security assumptions beyond those of the underlying blockchain networks. This approach does not rely on any external trusted third parties such as *bridges*, *oracles*, *multi-signature* or *threshold-signature schemes*. One can think of it as a **universal aggregation layer** that has the following layers: 1. **General data availability layer** 2. **Settlement layer** for execution environments 3. Specialized **zk-light-rollup** where the execution of the zk-light-clients is performed Continuum features a custom *execution layer* in the form of a specialized **zk-light-rollup** where zero-knowledge proofs of consensus are generated, a settlement layer where the validity of those proofs is verified, and a general data availability layer for ordering and efficient data retrieval. Trust-minimized bridging between rollups can be achieved only between rollups that share the same data availability layer. This approach follows the *enshrined rollup design* that shares the settlement layer to benefit from a trust-minimized "bridge" with it. Additionally, this benefits the ecosystem by having indirect trust-minimized bridging to other rollups that also enshrine bridges to this same settlement layer. Basically, we reduce the $O(N^2$) bridging complexity back down to $O(N)$, solving two important issues: * The issue of **asset fungibility** that arises from bridging between many different blockchain networks * The issue of **fragmented liquidity** We have an alternative way to achieve all-to-all interoperability between connected chains and reduce the bridging complexity from $O(N^2)$ to $O(N)$, without using one rollup as coordination hub: we take proof for all N chains, recursively aggregate all of them off-chain, then verify the aggregate zk-proof on each rollup independently. Now each rollup has a single proof for all rollups in this network. *Horizontal topology* vs *vertical topology* The flat topology contrasts with the hub-and-spoke model where you're bridging up and down through a single point. This allows you to eliminate the two-hop bridging process, but at an increased cost of off-chain execution. Continuum Components --- ### Continuum Core Contracts To communicate information between two blockchains without a trusted intermediary, we can simply verify the consensus of the source chain in the execution environment of the destination chain. zk-SNARK proofs can be used to prove that a certain consensus state transition has occurred on a blockchain. For example, a zero-knowledge proof can show that a transaction has been included in a block on chain `B` without revealing the transaction details. Smart contracts on chain `A` can verify the zk-proofs. If the proof is valid, the smart contract will trigger a specific execution depending on the type of swap mechanism that was implemented: *lock-and-release* or *mint-and-burn*. ### Continuum ZK-on-chain Light Clients The principle behind light clients is to keep track of the state of a blockchain in a *compute* and *storage-efficient* manner. Light clients are designed to be computationally cheap to run to allow resource-constrained participants to be part of a blockchain network. However, they are not designed to be implemented as smart contracts: that's why we are developing custom zk-SNARK circuits to unlock gas-efficient on-chain light clients. Light clients embedded within blockchain `A` can verify the state of another blockchain `B` using zk-proofs. These light clients can verify state transitions with minimal data and compute footprint. **zk-SNARKs** enable a prover to efficiently convince `SC2` that a certain state transition occurred on chain `C1`. To achieve this, `SC2` tracks a digest `D` of the latest tip of `C1`. To sync `SC2` with new blocks in `C1`, anyone can generate and submit a zk-SNARK that proves the corresponding state transition to `SC2`. ### Continuum Relayers At its core, a **Continuum Relayer** operates as a modular execution engine with no persistent state and public key identifiers to securely exchange and relay data. The instructions it processes define methods for retrieving data from multiple blockchains, aggregating, and relaying messages back to the respective chains. To manage message storage and processing, Continuum Relayers use a Kafka-based priority queue, leveraging Kafka's robust message handling and fault tolerance to ensure system reliability. The Continuum Relayers are part of the **block header relay network** that actively listens to the state changes on the integrated chains and retrieves block headers from the full nodes. One key difference between existing solutions and Continuum Relayers is that the trust assumption is reduced to the existence of a single honest node in the relay network and that the zk-SNARK circuits are sound. ### Continuum QTSS (Quorum-based TSS) For blockchains without smart contract capabilities, **TSS Quorums** will manage asset custody in a decentralized manner. For example, a Bitcoin TSS Quorum based on [FROST](https://eprint.iacr.org/2020/852.pdf) will be required to lock and unlock BTC when certain events are emitted. ### Continuum ZKProvers Zero-knowledge proofs solve the problems of a trustless and secure interoperable layer at the cost of computational bottlenecks due to large circuit sizes. The problem of computational overhead can be reduced using hardware acceleration. Since much of the processing is proving data-parallel circuits, a generalization of ZKP for parallelism like [deVirgo](https://rdi.berkeley.edu/zkp/zkBridge/uploads/paper.pdf) is important. > Read more about [Zero Knowledge Proofs System without Trusted Setup](https://people.eecs.berkeley.edu/~kubitron/courses/cs262a-F19/projects/reports/project5_report_ver2.pdf) ## Appendix ### A. Glossary of Terms **Aggregation**: The process of combining multiple blockchain networks to function as a unified system, leveraging the benefits of both monolithic and modular blockchain architectures. **Asset Portability**: The ability to transfer digital assets across different blockchain networks without losing their value or functionality. **Bridgeless Architecture**: A system that facilitates the transfer of value and information between blockchains without the need for bridges, oracles, or multi-signature schemes. **Consensus**: A protocol that ensures all participants in a blockchain network agree on the state of the blockchain. **Data Availability Layer**: A layer in the blockchain architecture responsible for ensuring that all transaction data is accessible to participants. **Execution Layer**: The layer where transactions are processed and state changes occur. **Light Client**: A type of blockchain client that requires minimal resources to operate, typically used by participants with limited computational power. **Settlement Layer**: An optional layer where execution layers verify proofs, resolve disputes, and connect to other execution layers. **Trustless**: A system design where participants do not need to trust any single entity or intermediary because the system's security is maintained through cryptographic proofs and decentralized consensus mechanisms. **Zero-Knowledge Proofs**: Cryptographic methods that allow one party to prove to another that a statement is true without revealing any additional information. ### References - zk-SNARKs: Groth, J. (2016). "On the Size of Pairing-based Non-interactive Arguments". EUROCRYPT 2016. - Proof-of-Authority: Wood, G. (2017). "Ethereum: A Secure Decentralised Generalised Transaction Ledger". Ethereum Project Yellow Paper. - Multi-Party Computation: Yao, A. C. (1986). "How to Generate and Exchange Secrets". FOCS 1986. - Threshold Signature Schemes: Shamir, A. (1979). "How to Share a Secret". Communications of the ACM. ###### tags: `Interoperability` `Blockchain` `Light clients` `Relay Network`