Dialogue with Orbiter Finance: With frequent cross-chain attack incidents, how to evaluate different bridging solutions?

Source: ETH Chinese

This interview focuses on cross-chain related topics. Cross-chain security has always been a major concern in the community, with frequent cross-chain attack incidents leading to increasing skepticism about cross-chain security. Of course, different cross-chain solutions use different technologies, which results in varying levels of security.

As the multi-chain ecosystem and Ethereum L2 gradually mature, the demand for cross L1 and cross L2 transactions is also growing. For users and developers, understanding how to assess the security of a cross-chain solution is crucial, as it involves the safety of their assets.

In this episode, we invited Eric from the technical team of Orbiter Finance to introduce us to cross-chain and Orbiter Finance. Orbiter Finance is a decentralized bridging solution focused on Ethereum cross-rollup, based on a "pre-trust + dispute arbitration" model, relying on the security of the Ethereum network itself. Orbiter Finance has announced that it will soon launch its liquidity provision mechanism and Maker contract testing.

Topics discussed include:

• Discussion on cross-chain attack incidents and their fundamental security limitations

• Basic principles of cross-chain and different types of cross-chain

• Implementation methods and project introduction of Orbiter Finance

• How does Orbiter Finance's arbitration mechanism protect user asset security?

• Introduction and open plans for Maker liquidity provision contracts

• Introduction to data service L2 data

• Future outlook on the cross-chain ecosystem

Why do we say that cross-chain has fundamental security limitations?

Franci: When it comes to cross-chain, many people might have a negative impression that many hacker attacks target cross-chain protocols, and the amounts stolen are often huge. For example, last year’s ChainSwap and Poly Network attacks, as well as this year’s Multichain, Wormhole, Ronin Network, Nomad, etc. I won't list them all, but these attacks resulted in losses reaching millions or even billions of dollars.

Moreover, cross-chain transactions can have a counter-network effect: when transaction activity is low, the network is very secure because the incentives for hackers to attack do not cover their attack costs; however, as transaction volume increases, the risk of attacks grows. In other words, the more prosperous the cross-chain ecosystem, the more vulnerable it becomes to attacks. This poses a fatal risk for users with large assets and cross-chain applications. So why is this the case? Why are cross-chain bridges so easily hacked?

Vitalik once stated in the seventh Reddit AMA of the Ethereum Foundation that he maintains a positive attitude towards multi-chain blockchain ecosystems but a negative attitude towards cross-chain applications, primarily because bridging has fundamental security limitations. What do you think about this?

Eric: Actually, many of these examples are caused by flaws in the logic code within contracts and verification proofs, but I believe these issues will be resolved with the development and growth of technology.

However, there is indeed a fundamental security limitation in cross-chain protocols. I believe it is related to the security of the chains themselves. The security limitations of cross-chain protocols align with the bucket theory. Cross-chain involves multiple chains, and the upper limit of the security performance of a cross-chain protocol is determined by the lower limit of the security performance of a specific chain involved. If one of the chains in your cross-chain protocol has poor security and is easily attacked, then the security performance of your cross-chain protocol cannot be guaranteed, making it easy for users to lose assets during the cross-chain process.

For example, if there are two chains that are heterogeneous, and one of them has poor security, when you transfer funds from Chain A to Chain B or run a cross-chain protocol, if Chain B needs to roll back due to some security issues, there is no way to handle it on Chain A. In such cases, the bottleneck of Chain B's security can compromise the overall security of the cross-chain protocol.

Franci: Continuing on this topic, Vitalik later wrote an article based on this subject. He proposed a concept called shared security. After reading this article, my understanding is that the shared security area refers to whether I can share the security of the source chain when I cross from one chain, say Chain A, to another chain, Chain B, using assets from that chain. According to this classification, cross-L1s and cross-L2s are two different situations; cross-L2 is much safer than cross-L1 because their security is provided by Ethereum, similar to rollups. Orbiter is focused on cross-L2 solutions. Regarding Vitalik's shared security, how do you understand it, Eric? Do you think cross-L2 is safer than cross-L1, and does it also have significant security vulnerabilities?

Eric: I believe cross-L2 inherits the security mechanism of L1, thus benefiting from the security of the L1 network. Therefore, I think it does not have any obvious security vulnerabilities, but it does have a very clear disadvantage. Rollups have an exit time issue, which we often refer to as withdrawal time. This is determined by the technical characteristics of rollups; validity proofs may take about four hours, while fraud proofs require seven days. This significantly limits asset liquidity and hinders the development of rollups.

Basic Logic of Cross-Chain

Franci: What is the basic logic of cross-chain? Generally speaking, how do users achieve cross-chain activities between two different chains?

Eric: Those familiar with Ethereum and the blockchain ecosystem will know that our current blockchain systems consist of many heterogeneous chains that cannot be interconnected. Some chains cannot directly exchange value and information with each other. This greatly limits the functional development of blockchains.

What we refer to as cross-chain actually means exchanging information between these different blockchain networks. Moreover, we utilize the exchanged information to achieve interoperability and value transfer between different blockchains.

When a user uses cross-chain, the basic logic is as follows: there are Chains A and B, and a cross-chain message is initiated from the source network Chain A. This message may go through some trusted and secure means before being sent to the target Chain B. During this process, it may be necessary to verify the validity of this message, ensuring that the cross-chain message is authentic; when this message is sent to Chain B, there may also be confirmations regarding the validity of this message on Chain B. Then, based on the message from Chain A, certain processing will occur on Chain B. After processing, we can obtain a result on Chain A. This is essentially the basic logic of cross-chain.

Introduction to Different Types of Cross-Chain

Franci: I noticed some points you mentioned earlier. When a user performs a cross-chain transaction, the target chain needs to verify the validity of the transaction from the source chain. There may be different technical options for verification. Could you list some of the more mainstream methods? Can we understand the basic architecture of different cross-chain solutions through these methods?

Types of Message Relayers

Eric: In the basic logic of cross-chain, we find a relatively important role. This role is responsible for sending transaction information from the initiating chain to the target network. This role must be trustworthy because we need to ensure that it sends the correct transaction. It belongs to the category of message relayers. In cross-chain protocols, it is generally an off-chain role. This relayer can be implemented in different ways; it may be a single node, multiple nodes, or even third-party organizations like Chainlink.

The most basic model is the fully trusted relayer model. In normal message transmission, this off-chain relayer role is selected through various methods. Some may be selected through voting, while others may be selected through staking funds. This role can be one or multiple. These roles will verify and package the cross-chain information from the initiating chain off-chain. The verification process may involve multi-signatures or distributed signatures to ensure security. However, this method has a problem: it requires that the majority of the signing members are honest.

The second type is Layer Zero. It adds another role based on the trusted relayer model, distinguishing the oracle role from the relayer role. The oracle is used to submit information about the block headers of the initiating chain, while the relayer is only responsible for sending transaction verification proofs. Then, off-chain, these two are matched and proven through algorithms to verify the block header.

The final type is the optimistic verification model. This model also has an off-chain relayer role, along with watcher and updater roles. The updater is required to stake funds, and by staking, it gains the right to package the cross-chain information from the initiating chain. The relayer simply sends the updater's signature information to the target chain. There is also a watcher role responsible for supervising the updater who signs transaction information. If the updater acts maliciously, the watcher can respond in a timely manner and use other proof methods to prevent the updater from acting maliciously. This method is the most secure because it assumes that as long as one honest updater is running, it will work. However, because it uses fraud proofs, it may have higher time costs compared to the previous two methods.

Verification Methods for Message Validity

Eric: When these messages reach the target network, their validity is verified in different ways.

The first method is contract verification on the target network. This contract verification can be divided into two aspects: consensus verification and validity verification. Validity verification is relatively easy to understand; our current rollups actually use this method. They verify the state of L2 through fraud proofs and validity proofs in the L1 rollup contract. For consensus verification, it involves verifying the consensus of the source chain on the target chain, which may relate to the consensus mechanism used by the source chain, whether it uses PoW or PoS protocols. The second method is actually performed off-chain, involving some external verifiers. These external verifiers are elected through some means to be trusted verifiers, and they unify through multi-signatures or consensus algorithms. After verifying off-chain, they submit to our target network. The third method is the optimistic verification model mentioned earlier. Only when there is malicious behavior will the watcher be responsible for submitting fraud proofs on the target network. So these are three possible different verification methods.

Orbiter uses a solution that combines pre-trust with dispute arbitration, relying entirely on the security of the Ethereum network itself. Under the premise of ensuring this security, we focus on the development of cross-L2.

Implementation Method of Orbiter Finance

Introduction to Orbiter's Architecture

Eric: From the perspective of roles, it can be divided into two: one is the sender role, and the other is the maker role. One can say that one is the role using cross-chain services, while the other is the role providing liquidity to facilitate cross-chain transactions.

I can briefly explain the process when users use Orbiter Finance for cross-chain. For example, if a user wants to transfer their Ethereum funds from the zkSync network to the Ethereum network, they can operate on the front end of the Orbiter website and transfer their funds from their own EOA address on zkSync to the Maker address we provide.

Once the Maker receives the funds, they will send the calculated tokens to the user's address on the target network. This involves the transfer logic between EOAs. During this process, for the Maker, Orbiter will provide a client. The Maker can also deploy a client themselves to automate the backend, which is the process of returning funds. This client will monitor data such as the user's cross-chain amount, currency, and network status. This is a normal process, but if malicious behavior occurs, there will be a different logic.

Orbiter adopts a pre-trust model, meaning we assume that these makers will correctly handle assets and return funds to users properly. However, throughout the process, there is a possibility of malicious behavior from the Maker, who may receive the user's assets on the initiating network and then withhold those assets.

Image Source: Orbiter Finance

We have implemented a decentralized mechanism to prevent malicious behavior, primarily through three contracts: MDC, EBC, and SPV.

The MDC contract is essentially a maker registration contract. This contract is responsible for creating its cross-chain rule service, storing some maker collateral, and providing arbitration processing rules for senders and makers.

The EBC contract is an event binding contract. Currently, we mainly use it for asset transfers, so this EBC contract will calculate the target chain transaction based on the transaction from the sender to the maker on the source chain.

The SPV contract is a simple transaction verification contract used to prove whether a transaction provided by the user on a certain chain is genuinely on that chain.

Through these three contracts, we can ensure that when a maker acts maliciously, users will not suffer asset losses. They can go through the entire appeal and arbitration process to ultimately receive compensation for their assets, even exceeding the original amount.

Easter Egg

Franci: Has there been any interesting story since the founding of Orbiter Finance?

Eric: An interesting story would be from the end of last year when Vitalik posted a cross-rollup bounty on Gitcoin. I found this quite interesting and had some ideas at the time. My colleague and I spent over twenty days creating a pizza contract to participate. Ultimately, we won and received a reward of 16 ETH from Vitalik. This was a significant encouragement for us.