The key promise of Web3 is permissionless interoperability. For users to be able to use applications across blockchains, it is important that these blockchains can communicate in a secure, decentralized, permissionless and trustless manner. This makes the interoperability layer a critical infrastructure for a reliable and seamless user experience.
Our goal is to build Mover as an Aptos-first liquidity bridge and general cross-chain messaging protocol. Mover’s technical design will prioritize providing the most secure and efficient cross-chain experience by utilizing the architectural and technical capabilities of Aptos to the fullest extent. By focusing exclusively on Aptos as a destination chain, we plan to do better than other solutions in terms of trust assumptions, cost efficiency and usability trade-offs.
This article will outline Mover’s strategy to reach ultimate interoperability.
Cross-chain interoperability today
All cross-chain messaging and bridging approaches can be roughly divided into three categories:
- centralized entities (e.g. exchanges such as Binance), which can function as asset bridges
- multisig/consensus bridges and communication layers (e.g. Multichain)
- light client bridges (e.g. Rainbow bridge)
The centralized and multisig bridges cannot truly embody the values of Web3: they are not censorship resistant and involve trusted parties. But more importantly, they are much less secure than the blockchains they connect. We have witnessed far too many bridge hacks that resulted in over a billion dollars lost, damaging the credibility of the entire crypto space and slowing down its wider adoption.
We can do better than this
The key problem of secure and trustless bridging is that blockchains do not have shared security — they have disjoint sets of miners or validators, which operate inside their respective ecosystems and know nothing about each other.
Light clients close this gap by verifying the state of a source chain on a target chain. In other words, the consensus of the source chain is validated by the smart contract executed on the target chain, which is in turn validated by the target blockchain validators. As a result, target chain validators effectively validate a source chain, creating a shared security environment for cross-chain transactions.
The main challenge is to build light client nodes that can keep track of the state of a blockchain in a compute and storage-restricted on-chain execution environment. This hindered the initial adoption of the light client approach in favor of less secure, permissioned but computationally cheaper multisig and centralized designs.
However, with the rise of faster, more scalable L1 blockchains such as Aptos, we expect the light client approach to dominate. This is the path that Mover would take to bring true Web3 interoperability to Aptos.
How will we do this
Mover will go through multiple phases of deployment as it gradually delivers light client communication for Aptos ecosystem. This slow rollout will allow our developers to ensure that the protocol is safe during its nascent days, a period where bugs might be found and some components have to be redesigned. Mover is a community-driven project, so for us it is of utmost importance to be up-front with our users and stakeholders. We believe that it is prudent to acknowledge that these things happen, especially with new and complex systems, and to take all necessary steps to mitigate their impact.
Phase Zero: Semi-light client with non-colluding Relayers and Oracle
Mover’s initial rollout will utilize Oracles and Relayers that will independently supply a cross-chain transaction and an inclusion proof that it has been executed on the source Chain A to the target Chain B.
There design has a seemingly small, but important difference from the traditional multisig bridging: nodes responsible for cross-chain messaging are separated into two disjoint sets (relayers and oracles). Both types of nodes participate in validating the transaction by independently deliver messages to the destination blockchain, where a smart contract endpoint executes transactions after proving its validity. The key security assumption here is that relayers and oracles cannot collude. This will be ensured by running oracles together with key Aptos stakeholders and the community.
This semi-light client approach will drastically reduce initial development effort, possible attack surface and the amount of security audit needed, thus allowing us to launch early. This head start would give us enough time to thoroughly test and prepare key infrastructural components of Mover related to liquidity provisioning (LP pools, mining, swaps), security (watchdogs and health monitoring system) and usability (transaction monitoring). But more importantly, this Relayers-Oracles setup will serve us as a testbench for zkSNARK-based proofs that will kick in Phase 2.
Despite these advantages, there are several reasons we believe this design cannot become an ultimate cross-chain solution for the Aptos ecosystem:
- It relies on an intermediate consensus layer (Oracles)
- Growing variable costs (Oracles are paid per use)
- While user applications can choose Oracles and Relayers, not all protocols would be willing to do this because developers often are happy to use default trust assumptions and settings.
The semi-light client will be our initial milestone, but it doesn’t fulfill our requirement for an ultimate light client cross-chain communication for Aptos.
Phase One: Light Client
Phase One would be a gradual transition of major chains from a Semil-client to a trustless light-client setup. This setup will eliminate the intermediate consensus layer and non-collusion assumption for Relayers/Oracles.
Light node bridges require little to no additional security and trust assumptions apart from the ones provided by the source and destination blockchains. As an Aptos-first bridge, the light node approach is our preferred choice because it can fully utilize all the features of Aptos consensus and execution engines.
Our first goal is to build Aptos light client for Ethereum. After the Merge, Ethereum introduced a sync committee that allows light clients to keep track of the chain of beacon block headers. A sync committee is a group of 512 validators, randomly assigned by the Ethereum Beacon network. A new committee is chosen every 256 epochs, roughly 27 hours. This committee continually signs block headers for each new slot in the beacon chain. A light client can trust these headers to represent accurate and validated blocks.
The light client only needs to know:
- A previously validated & finalized Beacon block header
- Members of current and next committees
Sync committees are updated infrequently and available directly in the beacon state, thus allowing light clients on Aptos to verify the sync committee with a Merkle branch from a block header and use the public keys in the sync committee to directly authenticate block headers.
Ethereum execution headers are submitted by a relayer to the Ethereum Light Node contract on Aptos. Headers’ parent hashes are checked against finalized beacon header execution block hash. Execution block headers are hashed and stored as unfinalized headers.
When a light client update is submitted, it is relayed to the light node on Aptos that verifies the finality branch of the Merkley tree to confirm that header corresponds to the finalized root. Next, if it is a newer sync period, the node validates the next sync committee by verifying the corresponding Merkle branch. Finally, BLS aggregate signature of the sync committee with a bitfield of who participated is verified. If all checks pass successfully, the snapshot Beacon header is updated. All execution headers having a height lower than the update’s block height are removed from the execution headers list and become finalized. Headers older than N epochs (e.g. N=2048, approx. 9 days) are deleted.
The bridging flow for ERC20 tokens to Aptos would then be as follows:
- Users execute ERC20 an approve transaction on Ethereum for a bridge contract.
- Users execute a lock transaction that locks a specified amount of ERC20 tokens on Ethereum. This transaction creates a Deposit event, which contains the destination address on Aptos.
- Relayers send Ethereum blocks to the Ethereum light node on Aptos side.
- After an execution header of a block containing a transaction is finalized, a relayer submits a proof of the Deposit event on Ethereum side to the bridge contract on Aptos.
- Aptos bridge contract verifies this proof against the light node.
- On successful validation, Aptos bridge contract mints the same amount of wrapped tokens that represent the locked tokens or releases corresponding native tokens if they are available on Aptos
It’s important that the actual details of the consensus algorithm matter while constructing the light client, but taking these details into account will ensure the long term competitive advantage of Mover’s approach over alternatives.
Phase Two: zkSNARK Light Client and beyond!
Aptos consensus protocol is a higher throughput and lower latency protocol compared to many other blockchain, especially Ethereum. It makes the implementation of light clients on Aptos cost-efficient. However, running light clients on more expensive blockchains such as Ethereum is more challenging. Apart from the gas costs, some signature schemes used by a consensus protocol on one blockchain may not be supported by the smart contract execution environment of the other. To be able to work verify on the slower blockchain, Mover will rely on zkSNARK-based verification.
With recent advances in zero-knowledge proof systems, on-chain verification becomes feasible. In a nutshell, zero-knowledge proof systems allow a bridge to generate proof that some computation (signature from more than 2/3 of current validators) has resulted in a certain output (i.e a signature). It takes a significant amount of time and computational resources to build this proof, but verification is much faster and can be performed on a chain with high gas fees. On a faster and cheaper chain, proof-based light client design will further lower the costs of cross-chain transaction verification.
At Mover, we invest heavily in research and development to make Phase Two the pinnacle of our early development and growth phase. But we are confident that Mover’s development and growth will continue even after we fulfil our ambitious plans. The decentralized nature of Mover will remain at its core and later all changes will go through appropriate governance and consensus within the community. We already have a lot of ideas in our backlog that would contribute to Mover’s thriving cross-chain ecosystem. As such, we anticipate an exciting journey towards a more interconnected crypto ecosystem from Phase zero to Phase two and well beyond.
Join us in this amazing adventure!
