Why do we need cross-chain? What is a bridge?
Why do we need cross-chain solutions? There is a wide variety of blockchain operating environments, and different blockchain supports different protocols, dApps and crypto assets. If someone wants to hold BTC but to participate in DeFi protocols on Ethereum, or someone just wants to trade BTC for ETH，Cross-Chain infrastructure will be essential. Because cannot communicate directly，and different blockchains cannot read the data on each other’s chains, so direct transfer between chains cannot be realized. Then we need to design some solutions to connect the assets that are separated.
What is a bridge? In general, the system that supports transfer of crypto asset between different blockchains is the bridge. The core functions of the bridge can be summarized as follows: the user deposits assets from one end of the bridge → the bridge updates the account balance → the user can withdraw money from the other end of the bridge. In addition to studying how to constantly improve TPS, finding solutions to build up bridges to support transfer of crypto asset from one blockchain to another is also an important topic in blockchain technology.
In terms of cross-chain and bridge solutions, we might hear these a lot：Polkadot, Cosmos, NEAR Rainbow Bridge, xDAI Bridge, BSC Bridge, Arbitrum Bridge, Optimistic Bridge, Matic Network Bridge and zkSync Bridge. So what is the difference between these solutions？How does Orbiter Finance differ from these bridges as a cross-rollup bridge?
Comparison of bridges — from centralization to decentralization
We try our best to explain the differences between the different bridge solutions in a way that is as easy to understand as possible. And explain how Orbiter Finance’s solutions differ from previous cross-chain or bridge solutions in the order of entering the mainstream view：
1. CEX and Notary scheme
The earliest bridge widely used in the crypto world is CEXs, They are based on mature centralized Internet technology. CEXs have built up centralized bridge for crypto assets exchanging between different blockchains by Notary schemes solution.
WBTC is also a centralized solution. BitGo Trust hosting assets in the BTC blockchain, and it also runs a smart contract on Ethereum to issue WBTC and update its balance, WBTC is consistent with the amount of BTCs it is hosting.
Although the centralized mechanism is highly efficient, it is always faced with risks of regulatory policies and platform managers, and there are still problems in security.
2. Lightning Network and Hash-locking
Lightning Network originated from BTC’s scaling solution and adopted the Hash-locking solution. Lightning Network has designed two types of trading contracts: RSMC（Revocable Sequence Maturity Contract)，HTLC（Hashed Timelock Contract） RSMC solves the problem of one-way flow in the channel, and HTLC solves the problem of cross-node transfer. HTLC bears the function of bridge. The function of HTLC is to require the payee to submit the transfer certificate to the transferor before the deadline, otherwise the funds will be returned to the transferor.
For ease of understanding, an example of how Hash-locking works: Alice stored assets in the hash-locking contract of Chain A, while Bob stored assets in the hash-locking contract of Chain B. They exchanged the hash-key. Bob went to Chain A to take out the assets deposited by Alice, and Alice went to Chain B to take out the assets deposited by Bob, thus cross-chain transaction could be completed.
3. Polkadot Relaychain
Polkadot, which focuses on cross-chain solutions, gained a lot of attention in 2020. In the original blockchain solution, there were different blockchains first, and then developers built bridges between the different chains. In contrast, Polkadot builds bridges first and then builds different blockchains on the bridges, running smart contracts on the blockchain.
The goal of Polkadot is to transmit any message between parachains, that is, parachain A can call the smart contract in parachain B, and RelayChain, as the underlying bridge, can support communication and transfer between parachains. Polkadot has 3 layers:
- Developed a RelayChain with the function of information interactive verification as the underlying layer。
- Developers in the ecosystem can build the parachain on Relaychain. Relaychain contains all the data information of all parachains. Parachains will share the validators on Relaychain for higher security.
- Smart contract can run on parachain, and there is Shared State between Relaychain and parachains to ensure that the whole system can be continuously valid.
In addition, Polkadot uses two mechanisms to ensure the security of cross-chain communication：
- RelayChain and parachains shared security not only make message communication easier, but also make both parachains have the same level of security. Parachains can trust each other.
- Introducing Fishermen as “bounty hunters” to monitor the parachains’ malicious activities. Fishermen can submit a certificate to Relaychain stating that parachain’s validators have submitted an invalid block. The entire state of the Polkadot network and associated parachains can be rolled back.
4. Cosmos and IBC
Along with Polkadot, the most discussed is Cosmos. Polkadot’s goal is the users can transfer any type of tokens between two chains. In contrast, Cosmos focuses on the assets transfer between blockchains, is a simpler protocol than Polkadot.
In Cosmos’s solution, the Hub acts as the central hub, managing many of the blockchains known as ZONE. The Hub tracks the status of each Zone, and the Zone reports the newly produced blocks to the Hub. And then synchronizes the status of the Hub. But the state synchronization between Hub and Zone is not done directly, but the interoperability achieved through the Inter-Blockchain Communication protocol (IBC).
The biggest difference between Cosmos and Polkadot’s structure is that the security of each Zone is guaranteed only by its validators. If a Zone wants to be highly secure, it needs to introduce more validators by itself. This approach is difficult for smaller apps to operate on, but it also gives more control to apps that want to control.
4. Sidechain bridges
Near, xDAI network, BSC and HECO are all Ethereum sidechains with high attention. Sidechain bridges mainly have
two solutions:
- NEAR Rainbow Bridge
Also in 2020, Rainbow bridge solution of Near also received high attention. Rainbow bridge is a cross-chain interoperability bridge that not only supports the flow of assets between Ethereum and Near, but also supports more blockchains.
Rainbow Bridge does this by building a light client smart contract on NEAR that tracks Ethereum data on NEAR. And at the same time building a NEAR light client smart contract on Ethereum. That is, Rainbow bridge will transfer data from NEAR to Ethereum, and also from Ethereum to NEAR, so that Ethereum and NEAR can read each other’s data and realize cross-chain transfers .
This solution also has some problems. For example, the so-called light client is not that “light”. Ethereum generates a block every 13 seconds, and a light client on NEAR needs to validate the data in the block header every 13 seconds. This validation process takes up 10% of the gas limit of the block.
- The bridge between POA Network and the endorsement by subject credit
XDAI network, BSC and HECO are representatives of POA network, and they all have sidechain bridges that connect to the ETH mainnet. The common thing is that these bridges have validation nodes, involve human participation in governance, and are not decentralized enough. The difference is that xDAI bridge is validated by dynamic multi-nodes, while BSC and HECO are validated by exchange credit as endorsement.
5. Bridges for Layer 2 scaling
The Ethereum ecosystem is the largest in the crypto world. Although the current TPS of the Ethereum mainnet is 15, layer-1 and layer-2 scaling solutions are developing rapidly:
- Layer-1 scaling: eth2 sharded chains with native computations is coming along. Eth2 will give us ~1000–5000 TPS.
- Layer-2 scaling: state channels, Plasma and rollups are three major types of layer-2 scaling, and rollup is the mainstream solution. If everyone moves to rollups, we will soon have ~3000 TPS.
Why is a decentralized bridge between BTC and ETH or other blockchains difficult to achieve？ Because these blockchains cannot communicate directly with each other. But in the Ethereum system, Layer 1 is responsible for communication, Layer 2 rollups can communicate through Layer 1.
In order to explain more details, we put the cross-chain and bridge solution related to Layer 2 in a separate paragraph to focus on.
Cross-chain and bridge solutions in Layer 2
We mainly discuss the bridge solutions related to rollups technology in Layer 2 scaling solutions. Let’s briefly review the three main functions of rollups:
- Record transaction data on the chain.
- Calculate and compress the transaction data for each batch off the chain and transfer the compressed state root back to the rollups.
- The validator is responsible for verifying whether the returned state root is correct. And recording the correct result on the ETH mainnet: If the batch corresponding to the pre-state root is fully included in the batch corresponding to the post-state root, then proving that the pre-state root is correct, and it will be passed back to the rollup contract.
The difference between the rollups solutions is mainly in off-chain calculation and validation method. In the Rollup solution, the rollups can communicate directly with Layer1 for transfers, but there is no direct real-time communication between rollups for transfers. If Alice wants to transfer asset from Rollup A to Rollup B, Alice needs to transfer asset from Rollup A to mainnet first (with a withdraw time of 1 hour or at least 7 days), and transfer from mainnet to Rollup B (generating $4–10 gas fee on mainnet).
Therefore, in the overall technical framework of Rollup, there needs to be not only a bridge between Rollup and Layer1, but also a direct bridge between rollups to ensure the security and real-time of transactions.
1. Bridge solutions between rollups and Layer 1
ZK rollups and validity proofs
Every batch in ZK rollups includes a crypto graphic proof called a ZK-SNARK, which proves that the post-state root is the correct result of executing the batch. No matter how large the computation, the proof can be very quickly verified on the chain.
The technical complexity of ZK rollups is higher than that of Arbitrum or Optimistic, which requires higher off-chain computation costs, but the per-transaction on-chain gas costs are lower, with a short withdrawal time of about 4h. After ZK rollups can support EVM for smart contracts this year, it is likely to become the best rollups technical solution. Loopring, StarkWare, Matter Labs ZKSync, and Aztec 2.0 are all applying ZK technology.
The bridging solution for ZK Rollup from L2 to L1 is : The user initiates the withdrawal from L2, encodes the transaction data into a string, signs and sends the transaction to L1, and the transaction enters into the ZKSync smart contract on L1. After withdrawal period, it is proved that this block generates ZK proof correctly and publishes it to L1 and completes the validation, the withdraw is completed.
Arbitrum, Optimistic and fraud proofs
Fraud proofs rollups keep track of their entire history of state roots and the hash of each batch. If anyone discovers that one batch had an incorrect post-state root, they can publish a proof to chain, proving that the batch was computed incorrectly. The contract verifies the proof, and reverts that batch and all batches after it. The complexity of Optimistic rollups is lower than ZK rollups，off-chain computation costs lower，making it easier to support smart contracts. But it takes about 1 week withdraw time to give enough time to the person who submitted the fraud proof, and the gas fee of per-transaction on-chain will be higher.
Arbitrum and Optimistic use the same bridge solution available to developers to support the transfer assets from L1 to L2 ( It should be noted that this solution mainly solves the problem of assets from L1 to L2, rather than from L2 to L1 Or from L2 to L2) :
- Transfer assets from L1 to L2: At first，deposit the assets into the Arbitrum bridge contract of L1, and then the same number of assets are minted on L2 and transferred to the specified address.
- Transfer assets from L2 to L1: Burn the assets on L2, and then the equivalent amount of assets becomes available in the bridge contract of L1. However, withdraw time is required for fraud proof during this process.
Arbitrum is different from Optimistic in the way of resolving differences. When the validator submits a block that is considered incorrect to L1, the solution is as follows:
- Optimistic adopts a single-round interactive solution: On-chain data needs to be fully written, and the length of time for resolving disputes will be not face the problem like delay attack.
- Arbitrum resolves disputes through multiple rounds of interactive protocols: Less data is written to the chain, and contracts that break the Ethereum gas limit can be processed to reduce the cost of the chain, but it also increases the length of time to resolve disputes and may face delay attacks.
Arbitrum’s compatibility with EVM will be more friendly than Optimistic. Developers will not need to rewrite the program to move the smart contract developed in Solidity language from L1 to Arbitrum, and Arbitrum will use ETH as gas to reduce the user barrier.
Polygon’s aggregation SDK of Layer 2
Polygon, as the aggregation SDK of Layer 2, supports developers to develop L2 blockchains quickly and easily. By grafting Polkadot and Cosmos mechanics to ETH via Plasma technology, developers can develop contracts based on Polygon as easily as they can develop on the sidechains. In addition, Polygon is aggregating more options, such as ZK rollups, Optimistic and sidechains.
Polygon supports developers to build two types of blockchain networks on Ethereum quickly:
- Stand-alone network: The network has its own POS or DPOS consensus model, and the network builds its own validator node, which is suitable for enterprise blockchain or chains with strong communities. This mechanism is very similar to the structure of Cosmos, but the difference is that Cosmos is based on its own Hub and Polygon is based on ETH.
- Secure chain: ETH directly provides security services, such as using Fraud proof through Plasma, or provided by professional nodes. Security validation nodes can be shared by multiple projects, similar to Polkadot’s Shared Security Node model. It is suitable for start-up projects or more safety-oriented projects.
Polygon uses a 4-layer structure solution to support developers to develop stand-alone networks or security chains:
- The ETH layer as the base layer: Taking advantage of the high security of ETH, Polygon runs smart contracts on ETH for checking validation, pledge, dispute resolution, and messaging.
- Security layer: This layer runs the Polygon’s validator, which periodically checks the validity of the Polygon chain for a profit.
- Polygon network layer: This layer runs the blockchain based on the Polygon structure, The blockchain maintains the transaction records and consensus mechanism.
- Execution layer: This layer is responsible for reading and executing transactions in the Polygon Chain.
In the above four layers, the ETH layer and the security layer are optional layers, and the Polygon network layer and the execution layer are not optional. Polygon not only provides a security solution for developers, but also solves the problem of communicating with Layer1 uniformly.
2. Bridge between rollups and the rollups
Orbiter Finance and Cross-Rollup transaction protocol
Under the existing technical framework, there is no direct transfer between rollups, so a decentralized bridge solution needs to be built. In the current Layer 2 scaling framework, if the user wants to transfer the assets from Rollup A to Rollup B, he or she must transfer the assets from Rollup A to mainnet first (it will produce a withdrawal time of 1 hour or at least 7 days). Transfer from mainnet to Rollup B (which generates a gas fee for ERC20 tokens on mainnet). With the massive migration of users and assets to Layer 2, the bridge solution of cross-rollup direct transfers will also become the technical infrastructure of Layer 2.
Orbiter Finance builds a decentralized bridge protocol between rollups that allows cross-rollup direct transfers in one block time (~13s), with each transfer requiring only one smart contract validation on the destination rollup .
For example, if Alice wants to transfer 100USDT from Rollup A to Rollup B, Evan is a market maker and Orbiter Contract is located on Rollup B, Orbiter Finance helps Alice to transfer assets across rollups in this way:
- Market maker Evan will need to deposit 110USDT as margin in the Orbiter Contract in Rollup B. The margin for providing trading services is 100USDT, and the additional 10USDT is a penalty for Evan’s failure to provide services in time. (There will be no penalty as long as Evan provides his services normally. If Evan does not want to continue to provide his market-making services, he can submit an application and calculate the amount that Evan can get after the withdraw time, and then to get back the margin ). Transaction data of Optimistic or Arbitrum will be synchronized to OVM_CanonicalTransactionChain in rollup B of Layer 1.
- Alice in Rollup A can check the block browser off the chain and know that the current maximum amount that can be traded is 100USDT. Alice transfers 100USDT to Evan’s address on Rollup A. Again, these transfers are recorded by the sequencers on Layer 1.
- Alice completes the transfer after T time:
- T < 1min: Evan gives priority to provide the transfer service and should transfer 99.7USDT to Alice’s address on Rollup B (the gas fee of Rollup B should be deducted during the actual operation) and earn 0.3USDT as service commission.
- -1min < T < 5mins: Evan does not provide service in time, other market makers can compete to provide service to ensure Alice’s user experience and take over Evan’s margin. While other market makers earn 0.2USDT fee, Evan can still earn 0.1USDT fee.
- -5mins < T: If Evan and other market makers fail to provide the service in time, Orbiter will introduce pushman, and pushman checks sequencers to see that Alice does complete the transfer on Rollup A. Pushman will transfer 99.7USDT to Alice’s Rollup B account. PushMan will earn the 110USDT that Evan deposited, and Evan’s deposit will be cleared and the penalty money will be confiscated. Pushman can be anyone.
In summary, Orbiter Contract has the following three functions:
- Bookkeeping settlement: Record the deposit and withdrawal data of market makers, and settle accounts for market makers and pushman.
- Dispute resolution: Handling margin escrow transfers between market makers and pushman.
- Safekeeping margin: To store the margin of market makers and ensure the safety of funds.
Originally posted on
medium.com
by orbiter finance
