Technology
Security is the most important thing aside from offering cheap and fast transactions as a bridge protocol. What's the specific mechanism of Orbiter that makes sure that the cross-rollup process is safe enough for both 'Sender' 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:
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.
Orbiter is designed as a decentralized cross-rollup bridge for transferring the Ethereum-native assets between L1 and L2s.
The system has two roles: 'Sender' and 'Maker'. Makers need 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 the 'Maker' will send back to the 'Sender' on the Destation Network.
Here are several important questions:
- How does a Maker send assets back to the Sender correctly and automatically?
- How can 'Sender' make sure that they will get the tokens back when the 'Maker' doesn't send them back to the Destation Network?
- How to make sure taht Orbiter's contracts keep the Maker's margin safely?
Let's look into Orbiter's specific mechanism in the following flow chart.
Mechanism
Correct Process
Orbiter supports high-frequency cross-rollup transactions in an optimistic way, so it can be cheap and fast enough to support 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 funds to a Maker's EOA address, and not to a contract's address. That's the remarkable difference between Orbiter and other bridge protocols.
'Makers' can develop and run a client to provide the service automatically or use the Orbiter team's open-sourced client: https://github.com/Orbiter-Finance/OrbitalModule/tree/eth_pro_new.
After the 'Sender' sends the funds to the 'Maker' on the Source Network, the 'Maker' is now required to send it back to 'Sender' on the Destination Network. The 'Maker' needs to know the token type, amount to send to the 'Sender', and which chain(Destination Network) it is on. How does the Maker get these three parameters?
- Token types and send-back amount. Makers 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 Makers' clients. Makers know the send-back token type and calculate the send-back amount after receiving Senders' funds in this way.
- Destination network. Orbiter uses "Identification Code" to identify the Destination Network. "Identification Code" is added to the last four digits of the transfer amount, and the 'Maker' will know which the Destination Network is from that. It is worth noting that the transfer will fail if the user modifies it.
Confirm Page
The supported networks and corresponding identifiers are as follows:
identification Code
Makers are motivated to send back to Senders instantly and correctly.
First, in Orbiter's mechanism, Makers can get considerable income (with no impermanent loss risk) from every transactions.
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.
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 Makers' 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:
Mechanism
- 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 Makers 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.
Last modified 1mo ago