Besides being cheap and fast, how about the Security of Orbiter’s cross-rollup mechanism?

Security is the most important thing besides being cheap and fast as a bridge protocol. What’s the specific mechanism of Orbiter to make sure the cross-rollup process is safe enough for both Senders and Maker?

First of all, Orbiter Finance aims to solve the cross-rollup problems instead of the cross-chain issues. Vitalik has already made it clear:

Why not cross-chain? And why cross-rollup apps within one zone of sovereignty is fine?

The cross-chain project’s primary goal is to ensure the security of transactions between two unique chains and avoid the 51% attack. But the cross-rollup project uses the same Ethereum data layer with each rollup which can naturally prevent the 51% attack. Based on this, Orbiter comes up with a cross-rollup mechanism that can inherit the security of Ethereum L2.

Sepcific mechanism of Orbiter Finance

Orbiter is designed as a decentralized optimistic cross-rollup bridge for transferring the Ethereum-native assets between L1 and L2s.

The system has two roles: Sender and Maker. Maker needs to deposit excess margin in Orbiter’s contract before offering the cross-rollup service for Senders. In the correct usual process, the Sender will send to the Maker on the Source Network, and Maker will send back to Sender on the Target Network.

Here are several crucial questions:

• How does Maker send it back to Sender correctly and automatically?

• How to ensure Sender can get back tokens when Maker doesn’t send them back on the Target Network?

• How to make sure the Orbiter’s contracts can keep the Maker’s margin safely?

Let’s see Orbiter’s specific mechanism with the following flow chart.

Correct Process

Orbiter supports the high-frequency cross-rollup transaction in an optimistic way, so it can be cheap and fast enough to fit more cross-rollup user cases in the long term. If you have already tested Orbiter App and viewed the transaction log on the block explorer, you will find you’ve sent it to a Maker’s EOA address, not to a contract’s address. That’s the remarkable difference between Orbiter and other bridge protocols.

Maker can develop and run a client to provide the service automatically or use the Orbiter team’s open-sourced client:

https://github.com/OrbiterCross/OrbitalModule/tree/main/.

After Sender sends it to Maker on the Source Network, to send it back to Sender on the Target Network, Maker needs to know the token type, send-back amount, and which Target Network it is on. How does the Maker get these three parameters?

• Token types and send-back amount. Maker need to set the withholding fee (a fixed fee), the trading fee (0.04%~0.3%), and supported token types when depositing the margin in Orbiter’s MDC contract. These set parameters will be kept in Orbiter’s EBC contract and synced update with Maker’ clients. Maker know the send-back token type and calculate the send-back amount after receiving Senders’ funds in this way.

• Target network. Orbiter uses “Security Code” to record the Target Network. The correspondence between Security Code and Target Network is also kept in the MDC contract. Senders need to add a Security Code at the end of the decimal point of the transfer amount. Then, the Maker will know which the Target Network is.

Maker are motivated to send back to Senders instantly and correctly.

First, in Orbiter’s mechanism, Maker can get considerable income (with no impermanent loss risk) from every service. Second, if a Maker does not send back to the Sender correctly in time, Orbiter’s MDC contract will make the send-back and compensate the Sender with Maker’s margin.

Incorrect Process and Obiter’s contract system

Obiter’s contract system will deal with the low-frequency incorrect cross-rollup transactions. There are three kinds of smart contracts in Orbiter’s system:

• MDC contract (Maker Deposit Contract). MDC contract has two functions — keep Maker’ margin and handing the send-back and compensation for Senders.

• EBC contract (Event Binding Contract). EBC contract is used to make the validity proof of Source Tx and Target Tx. EBC also keeps the rules of Orbiter: ① The rule for Maker to deposit margin on different rollups. ② The rule of the correspondence between the Source Tx and Target Tx.

• SPV contract. SPV is used to make the existence proof of Source Tx on the Source Network.

We need one MDC and one EBC; they can support all domains in Orbiter. But, we need to build an SPV contract for each domain connected by Orbiter. MDC, EBC, and SPVs will be deployed on the same domain, and the domain can be L1 or any EVM-L2.

How do MDC, EBC, and SPV cooperate to resolve a dispute for the Sender? Once a Maker didn’t send back to Sender correctly, the following steps will be happened in sequence to help the Sender get the tokens:

1. Sender needs to provide the relevant Source Tx to SPV.
2. Sender initiates the arbitration through Orbiter’s MDC contract.
3. MDC gets the existence proof of Source Tx from SPV and knows the Source Tx has happened on the Source Network.
4. MDC gets the validity proof of Source Tx from EBC. MDC will know that the Source Tx is legally based on Orbiter’s rules; the Source Tx was sent from a Sender to one of Orbiter’s Maker with a legal Security Code.
5. Then, MDC will set this arbitration as a pending case and wait for the Maker to provide the Target Tx for 0.5~3 hours(This function can be aggregated in the Maker’s client, so the Maker will not miss it). If Maker can provide a correct Target Tx, MDC will get the validity proof from EBC and know the Target Tx matches the Source Tx. MDC will close this arbitration and show the Target Tx to Sender. But, if Maker cannot provide the relevant Target Tx after 0.5~3 hours, Sender can apply the withdrawal and then go to the next step.
6. MDC starts to compensate Sender.
7. MDC will send the tokens and compensation (~$15) back to Sender on the domain where the MDC deployed. The send-back tokens and compensation come from the Maker’s margin.

Security solutions for extreme cases

Are there any risks in Orbiter’s mechanism? We need to solve all the potential risks for both Sender and Maker in any extreme case.

Eliminate the Double-Spending risk for Senders

As Maker’s margin is used to guarantee send-back, there will be a problem when many Senders send to one Maker simultaneously. Because the Maker’s margin is less than the total received funds, the Maker can earn more by not sending back to these Senders. This will cause a Double-Spending problem for Senders.

Orbiter uses the excess margin mechanism to solve the Double-Spending problem. The Maker should deposit different amounts of excess margin on other domains based on Orbiter’s MDC contract rules. The minimum amount of the margin is relevant to whether the Source Network has EVM or not:

• With EVM: Orbiter’s MDC contract can divide one block into 5~10 slots; Maker will need to deposit at least 5~10 * limit margin to support this network. The “limit” is the maximum amount per cross-rollup transfer.

• Without EVM: To support the domains without EVM, like dYdX, Loopring, and Immutable X, Maker needs to deposit more margin in the MDC contract. The margin amount is relevant to the domain’s block size; it might be 100~200 * limit.

Security of Maker’s liquidity funds

All Maker’ margins will be kept in Orbiter’s MDC contract. As said before, Orbiter is a cross-rollup protocol and only supports Ethereum-native assets; Orbiter will not face the 51% attack risk or other risks caused by cross-chain motivation. But Orbiter’s contracts still need to be audited before opening to the third-party Market Maker.

Schedule

We are developing as fast as we can to implement the above plan and become an infrastructure for L2. Here is Orbiter’s scheduled for 2022: