Orbiter
Search…
Technology
Operation 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 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 Maker will send back to Sender on the Destation 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 Destation 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.
image-20201208165522338
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. 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.
- 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.
image-20201208165522338
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 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.
Contract System Design
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:
image-20201208165522338
- 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 3mo ago
Copy link