Read the history of cross-chain development in one article How to build the bridge between Rollups proposed by V God?

What is a bridge? What is the difference between different schemes?

Why do we need cross-chains? What is a bridge?
Why do you need cross-chain solutions? Blockchains have multiple operating environments, and different blockchains support different protocols, dApps, and crypto assets. If someone wants to hold bitcoin but wants to participate in the DeFi protocol on ethereum, or just wants to exchange bitcoin for ETH, then a cross-chain infrastructure will be essential. Because they can’t communicate directly, different blockchains won’t be able to read data on each other’s chains directly, and direct transfers between chains won’t be possible. Then we need to design solutions to allow fragmented assets to be connected.

What is a bridge? In layman’s terms, a system that supports the transfer of crypto assets between different blockchains is a bridge. The core function of a 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. Besides researching how to continuously improve TPS, finding solutions to build bridges to support the transfer of crypto assets from one blockchain to another is also an important topic in the field of blockchain technology.

Regarding cross-chain and bridge solutions, we may often hear these words: Polkadot, Cosmos, NEAR Rainbow Bridge, xDAI Bridge, BSC Bridge, Arbitrum Bridge, Optimistic Bridge, Matic So what is the difference between these schemes?

Comparison of the various bridges – from centralized to decentralized
We present the differences between the different bridge schemes in as easy-to-understand a manner as possible, and in the order in which they entered the mainstream, to illustrate how Orbiter Finance’s scheme differs from the previous cross-chain or bridge schemes.

  1. CEX and Notary scheme

The earliest bridge widely used in the crypto world was CEX, based on proven centralized internet technology, which created a centralized bridge for exchanging crypto assets between different blockchains through the Notary solution.

Also a centralized solution is WBTC, where BitGo Trust hosts assets in the BTC blockchain while issuing WBTC and updating the balance on Ether by running smart contracts to keep WBTC in line with the number of BTC it hosts.

Although the centralized mechanism is efficient, it always faces regulatory policy risk, platform manager risk, and still has problems in security.

  1. Lightning Network and Hash-locking

Lightning Network originated from the BTC scaling scheme and adopted the Hash-locking scheme. Lightning Network designed two types of transaction contracts: RSMC, HTLC. RSMC solves the problem of one-way coin flow in the channel, and HTLC solves the problem of coin transfer across nodes. Among them, HTLC carries the function of bridge. The function of HTLC is to require the recipient to submit proof of transfer to the transferring party before the time cutoff, otherwise the funds will be returned to the transferring party.

To facilitate understanding, an example of how Hash-locking works: Alice, Bob and Evan want to play a complex BTC trading game together, and the 3 people mutually agree to lock a certain amount of each person’s BTC on the BTC network with a hash lock, and then enter into the State Channel (similar to Layer 2 of BTC) for After the game is over, they pass the asset balance data that all 3 of them recognize back to the BTC network and unlock it, and then the 3 of them can transfer their BTC on the BTC network again.

  1. Polkadot Relaychain

Polkadot, which focuses on cross-chain solutions, has gained a lot of attention in 2020. In the original blockchain solution, there are different blockchains first and then developers build bridges between the different chains. In contrast, Polkadot builds the bridge first and then builds different blockchains on top of the bridge, with smart contracts running on top of the blockchains.

Read the history of cross-chain development in one article How to build the bridge between Rollups proposed by V God?

The goal of Polkadot is to be able to pass arbitrary messages between parallel chains, i.e., parallel chain A can call smart contracts in parallel chain B. The relay chain acts as the underlying bridge that can support communication and transfer between parallel chains. polkadot has a 3-layer structure.

A relay chain with message interaction and verification function is developed as the underlying layer.

Developers in the ecosystem can build parallel chains on the relay chain, which contains all the data information of all the parallel chains, and the parallel chains will share the verifiers on the relay chain to obtain higher security.

Smart contracts can be run on top of parallel chains, and there is a fragmented state between relay and parallel chains to ensure the whole system can be continuously effective.

In addition, Polkadot uses 2 mechanisms to ensure the security of cross-chain communication.

Relay chains share security with parallel chains, which makes message communication easier and enables parallel chains to have the same level of security, and parallel chains can trust each other.

Fishermen are introduced as “bounty hunters” to monitor the malicious activities of parallel chains. Fishermen can submit a proof to the relay chain that the verifier of the parallel chain has submitted an invalid block, and can roll back the entire state of the Polkadot network and the related parallel chain.

  1. Cosmos and IBC

The most discussed alongside Polkadot is Cosmos. while Polkadot aims to be able to transfer tokens between two chains at the level of any other type of communication, Cosmos in contrast focuses on asset transfer between blockchains and is a much simpler protocol than Polkadot.

In Cosmos’ scheme, the Hub acts as a central hub that manages a number of blockchains called Zones. the Hub keeps track of the status of each Zone, and the Zone reports newly produced blocks to the Hub and synchronizes the status of the Hub. However, the state synchronization between Hub and Zone is not done directly, but interoperability is achieved through the Inter-Blockchain Bridge protocol (IBC).

Read the history of cross-chain development in one article How to build the bridge between Rollups proposed by V God?

Compared to Polkadot’s architecture model, the biggest difference in Cosmos is that the security of each Zone is guaranteed by the verifier of that Zone only, and if a Zone wants high security, then it needs to introduce more verifiers by itself. This approach has operational difficulties for smaller applications, but it also improves control for applications that want to have more control.

  1. sidechain bridges

NEAR, xDAI network, BSC and Heco are some of the most popular ethereum sidechains. There are 2 main options for sidechain bridges.

  • NEAR’s Rainbow Bridge

Also in 2020, Near’s Rainbow Bridge solution has gained high attention. rainbow Bridge is a cross-chain interoperability bridge that not only supports the flow of assets between Ether and Near, but also supports more blockchains.

Read the history of cross-chain development in one article How to build the bridge between Rollups proposed by V God?

Rainbow Bridge is implemented by building a light client smart contract on NEAR that tracks data from Ether, and also building a light client smart contract on Ether for NEAR. In simple terms, Rainbow Bridge will transfer data from NEAR to Ether, and also transfer data from Ether to NEAR, so that Ether and NEAR can read each other’s data to realize cross-chain transfer.

This solution also has some minor problems, such as the so-called light client is actually not light. Ethernet generates a block every 13 seconds, and the light client on NEAR needs to verify the data in the block header every 13 seconds. This validation process takes up 10% of its block gas limit.

  • POA Network with a bridge backed by subject credit

xDAI network, BSC and Heco are representatives of POA Network and all have sidechain bridges that link to the ETH mainnet. The common point is that these bridges have verification nodes, all involve human participation in governance, and all are not decentralized enough. The differences are that xDAI Bridge is dynamically multi-node verified, and BSC and Heco are single-subject verified with exchange credit as backing.

  1. Bridges built for Layer 2 extensions

The ethereum ecosystem is currently the largest in the crypto world. While the current TPS of the main Ethernet network is 15, layer-1 and layer-2 extensions are rapidly evolving.

Layer-1 extensions: Eth2 shard chain with native computation is coming out soon. eth2 has about 1000-5000 TPS.

Layer-2 extensions: Stateful channels, Plasma, and rollup are the three main types of Layer-2 extensions, with rollup being the dominant solution. If everyone moves to rollup, we will soon have about 3000 TPS.

The reason decentralized bridges between BTC and ETH or other blockchains are hard to implement is that – these blockchains cannot communicate directly with each other. But in the Ethernet system, because Layer 1 can take care of communication, rollups of Layer 2 can communicate through Layer 1.

In order to explain it in more detail, we put the cross-chain and bridge scheme related to Layer 2 in a separate paragraph to focus on it.

Cross-link and bridge solutions in Layer 2
Here we focus on the bridge solution related to the rollup technology in Layer 2 extensions. First, we will briefly review the 3 main functions of Rollups.

Record transaction data on the chain.

Compute and compress the transaction data of each batch under the chain, and pass the state root obtained from the compression calculation back to 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 completely contained in the batch corresponding to the post-state root, the pre-state root is proven to be correct to be passed back to the Rollups contract.

Read the history of cross-chain development in one article How to build the bridge between Rollups proposed by V God?

The difference between different Rollup solutions mainly lies in the two steps of off-chain calculation and verification methods. In the Rollup technology scheme, Rollups can directly communicate with Layer1 to transfer money, but Rollups cannot directly communicate with each other to transfer money in real time. If Alice wants to transfer money from Rollup A to Rollup B, Alice needs to transfer money from Rollup A to the main network first (incurring a withdrawal time of 1 hour or at least 7 days), and then transfer money from the main network to Rollup B (incurring a $4~$10 gas fee on the main network).

Therefore, in the overall technical framework of Rollup, there is a need to have a bridge not only between Rollup to Layer1, but also a direct bridge between Rollups to ensure the security and real-time of transactions.

  1. Bridging scheme between Rollups and Layer 1

ZK rollups and valid proofs

Each batch in a ZK aggregation contains a cryptographic proof called ZK-SNARK, which proves that the post-state root is the correct result of the executed batch. This proof can be quickly verified on the chain, regardless of the amount of computation.

ZK rollups are more technically complex than Arbitrum or Optimistic and require higher off-chain computation costs, but have a lower on-chain gas cost per transaction and a shorter withdrawal time of about 4h. With ZK Rollups being able to support EVM for smart contracts this year, it is likely to be the best Rollups technology. Loopring, StarkWare, Matter Labs ZKSync and Aztec 2.0 are all using ZK technology.

ZK rollups bridge from L2 to L1: the user initiates a withdrawal from L2, signs and sends the transaction to L1 after encoding the transaction data as a string, the transaction goes to the zkSync smart contract on L1, and after the withdrawal deadline, a ZK proof proving the block is correct is generated and posted to L1 and validated, and the withdrawal is complete.

Arbitrum, Optimistic and Fraud Proofs

Fraud proof rollups keep track of their entire state root history and the hash value of each batch. If someone finds that the post-state root of a batch is incorrect, they can post a proof to the chain that the batch was calculated incorrectly. The contract validates the proof and restores that batch and all subsequent batches. optimistic rollups are less complex than ZK rollups, less expensive to compute off-chain, and easier to support smart contracts. However, it takes about 1 week of withdrawal time to give enough time to the person submitting the fraud proof, and the on-chain gas cost per transaction will be higher.

Arbitrum and Optimistic use the same developer-optional bridge scheme to support users moving assets from L1 to L2 (it is important to note that this scheme primarily addresses assets from L1 to L2, not from L2 to L1 or from L2 to L2).

Transferring assets from L1 to L2: the assets are first deposited in the Arbitrum Bridge contract on L1, after which the same number of assets will be minted on L2 and transferred to the specified address.

Transferring assets from L2 to L1: the assets are destroyed on L2, after which an equal amount of assets become available in the bridge contract on L1, but this process requires a withdrawal time for fraud proof.

Arbitrum differs from Optimistic in the way the disagreement is resolved, when the verifier submits a block to L1 that is deemed incorrect, the solution.

Optimistic uses a single round of interaction to resolve: it requires a complete write to the on-chain data, and the short dispute resolution time does not face the problem of latency attacks.

Arbitrum resolves disputes through the Dorian interaction protocol: less data is written to the chain and can handle contracts that break the ethereum gas limit reducing on-chain costs, but also increasing the length of time to resolve disputes and potentially facing latency attacks.

Arbitrum’s compatibility with EVM will be more friendly than Optimistic. Developers migrating smart contracts developed in Solidity language on L1 to Arbitrum do not need to rewrite the program, while Arbitrum’s use of ETH as gas also lowers the threshold for users.

Polygon’s Layer 2 Aggregation SDK

Polygon is a Layer 2 aggregation SDK that supports developers to develop L2 blockchains quickly and easily. The overall design solution is simple to understand and roughly the mechanism of Polkadot and Cosmos is grafted onto ETH through Plasma technology, so developers can develop contracts based on Polygon as simple as on the sidechain. In addition, Polygon is also aggregating more options such as ZK rollups, Optimistic and sidechains.

Polygon mainly provides developers with a solution for security services, Polygon supports developers to quickly build two types of blockchain networks on Ether.

Stand-alone network: The network has its own PoS or DPoS consensus model and the network builds its own verifier nodes, which is suitable for enterprise blockchains or chains with strong communities. This mechanism is very similar to the structure of Cosmos, but the difference is that Cosmos is based on self-built Hubs and Polygon is based on ETH.

Secured chain: Security services are provided directly by ETH, e.g. through Plasma using proof of fraud, or by specialized nodes. Security verification nodes can be shared by multiple projects, similar to Polkadot’s shared security node model. Suitable for startup projects or projects with more security focus.

Read the history of cross-chain development in one article How to build the bridge between Rollups proposed by V God?

Polygon supports developers in developing standalone networks or secure chains with a 4-layer architectural solution: the

ETH layer as the base layer: Taking advantage of the high security of ETH, Polygon runs smart contracts on ETH for final check confirmation, pledge, dispute resolution and messaging.

Security layer: This layer runs Polygon’s validator, which periodically checks the validity of the Polygon chain and receives a certain amount of revenue.

Polygon Network Layer: This layer runs the blockchain based on the Polygon architecture, which maintains the transaction records and consensus mechanism.

Execution layer: This layer is responsible for interpreting and executing transactions in the Polygon Chain.

In the above 4-layer structure, ETH layer and security layer are optional, and Polygon network and execution layer are mandatory. polygon not only provides security service solution for developers, but also solves the communication problem with Layer1 in a unified way.

  1. Bridge between Rollups and Rollups

Orbiter Finance and Cross-Rollup Transaction Protocol

In the existing technical framework aggregation, direct transfer between rollups is not possible, and a decentralized bridge solution needs to be constructed. In the current Layer 2 extension framework, if a user wants to transfer money from Rollup A to Rollup B, they need to transfer assets from Rollup A to the main network (which will incur a withdrawal time of 1 hour or at least 7 days), and then from the main network to RollupB (which will incur a transfer gas fee of ERC20 tokens on the main network). As users and assets migrate to Layer 2 on a large scale, a bridge solution for direct transfers across rollup will also become the technical infrastructure for Layer 2.

Orbiter Finance has built a decentralized bridge protocol between rollups that supports direct transfers across rollups in one block time (~13s), with each transfer requiring only one smart contract verification by the user on the target side of the rollup.

Read the history of cross-chain development in one article How to build the bridge between Rollups proposed by V God?

For example, Alice wants to transfer 100 USDT from Rollup A to Rollup B. Evan is the market maker and the orbiter contract is located on Rollup B. Orbiter Finance helps Alice to bridge the transfer across rollups like this.

Evan, the market maker, needs to deposit 110 USDT in the orbiter contract in Rollup B first. The margin for providing trading services is 100 USDT, and the other 10 USDT is a penalty for Evan’s failure to provide services in a timely manner. (If Evan does not want to continue to provide market making services, he will be refunded after submitting a withdrawal request and calculating the amount Evan can remove after the withdrawal time) Optimistic or Arbitrum will synchronize these transaction data to the OVM_ of rollup B located in Layer 1. CanonicalTransactionChain located in Layer 1.

Alice in Rollup A learns that the maximum amount that can be traded is currently capped at 100 USDT by querying the block browser under the chain, and Alice transfers 100 USDT to Evan’s address in Rollup A. Again, these transfers are made to Evan’s address in Rollup A. Again, these transfers are recorded by the sequencer on Layer 1.

Alice’s transfer is completed after T time.

T < 1min: Evan gives priority to the transfer service and should transfer 99.7 USDT to Alice’s Rollup B address on Rollup B (the actual runtime also requires deducting the rollup B gas fee) and earns 0.3 USDT as a service commission.

1min < T < 5mins: Evan does not provide the service in time, other market makers can grab the order to provide the service to protect Alice’s user experience and take over Evan’s margin. Other market makers earn 0.2 USDT service fee, Evan can still earn 0.1 USDT fee.

5mins < T: If neither Evan nor the other market makers provide their services in a timely manner, the pushman role is introduced in the Orbiter system. pushman queries the sequencer and determines that Alice has indeed completed the transfer on Rollup A and that Evan does have sufficient margin and penalties in Rollup B. The pushman will transfer 99.7 USDT to Alice’s Rollup B account and the pushman will earn the 110 USDT deposited by Evan, while Evan’s margin is liquidated and the penalty is forfeited.

In summary, the Orbiter Contract has the following three functions.

Bookkeeping and Settlement: records the access data of the market makers and settles the accounts for the market makers and the pushman.

Dispute Resolution: Handles margin escrow transfers between market makers and pushman.

Margin Custody: stores the margin of the market makers and secures the funds.

Posted by:CoinYuppie,Reprinted with attribution to:
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2021-06-17 01:16
Next 2021-06-17 01:20

Related articles