Roadmap
Roadmap Ultimate Trustless
Last updated
Roadmap Ultimate Trustless
Last updated
Orbiter Finance has achieved remarkable success in the cross-rollup market since its inception. It has managed to build a substantial user base and has been instrumental in connecting rollup environments and collaborating with various DApps to foster ecosystem growth in the cross-rollup space.
However, it's evident that several decentralised projects face challenges, such as censorship or disruptions in their frontend, leading to users losing direct access to the decentralised products. To tackle this issue, we have developed a range of incentive mechanisms. These mechanisms are designed to empower third-party DApps to create frontend interfaces that support the cross-rollup bridge protocol. This decentralised incentive frontend represents a significant milestone in Orbiter Finance's journey towards complete decentralisation and trustlessness.
In addition to the aforementioned roles within Orbiter Finance's protocol, two more roles play a crucial part in the decentralised incentive frontend. As two roles mentioned above, Dealer, who receives incentives for providing decentralised frontends, and Submitter, responsible for submitting the root of the revenue tree generated by Dealers.
By leveraging open protocols, the establishment of direct collaborative arrangements between Makers and Dealers becomes possible. This enables Makers to form partnerships with numerous Dealers, promoting increased frontend diversity. Through thoughtfully structured motivations, encourage Dealers to establish dependable frontends. Even when a particular Dealer intends to conduct malicious behaviour, users can still select alternative Dealer services, thereby minimising the potential impact of financial losses.
Dealers use their dealer IDs to identify themselves and register their fee rates with the Fee Manager Contract (FMC). This contract keeps track of all Dealers, manages and updates the dividends they receive from Makers, and ensures accurately the right amount of compensation is deducted once it goes through an arbitration mechanism.
As long as cross-rollup transactions are processed through Dealers and Makers, the profit-sharing between each Dealer and Maker for every transaction can be accurately calculated. Similar to the identification code appended to the last four digits of the transaction value within the target network, DealerID, EBCID, and DestinationChainID will be indicated in the last four digits of the transaction amount as well for Makers to recognize and distinguish these elements.
In order to provide a clearer understanding of how Dealers' profit is calculated, we will present an example here for better illustration.
Profit Sharing Agreement: Imagine Dealer3 enters into a profit sharing agreement with MakerB. Dealer3's ID is assigned as number 5, linked to address 0x_dealer_3. Additionally, MakerB's address 0x_maker_b is connected within the FeeManager contract. The profit sharing occurs at a ratio of 5%.
Precise Profit Calculation: Suppose a user aims to transfer 100 USDT assets from Arbitrum to zkSyncEra.
Using Dealer 3's provided frontend, the user opts for MakerB as the cross-rollup LP provider. After accounting for applicable charges, the user transfers 102 USDT to MakerB's Arbitrum address. Dealer3's interface appends specific ID codes to the transferred amount. The specific transfer amount for the user contains all elements:
102000000000000000253
The last four digits represent:
02 represents the user's target chain intention (Arbitrum, coded as 9002).
5 corresponds to the ID binding between Dealer3 and MakerB. This ID is utilised to retrieve Dealer 3's address and associated profit-sharing proportion from the FeeManager contract under the (0x_maker_b, 5) tuple.
3 reflects Maker's fee configuration, which can be determined by Maker in the MDC contract (set at 2 USDT in this case).
Once the cross-rollup transfer is completed, the Submitter aggregates this event with similar events from other users, forming a transaction batch. Precise calculations ascertain the profit due to each Dealer for each cross-rollup transaction. A Merkle Root is generated to accurately summarise the profit status for each Dealer account. In this illustration, Dealer3 is entitled to a profit of 2 USDT * 5% = 0.1 USDT. This sum accumulates as users progressively use the frontend deployed by Dealer3.
Following the Merkle Root update by the Submitter, Dealer3 can access their account's associated Merkle Proof data through the Submitter's RPC service. Dealer3 can interact with the FeeManager contract to commence the retrieval of profit balances aligned with their account.
We employ a Merkle tree to depict every Dealer’s profits. The key is hashed from Address: A, Chain Id: C and Token Address: TA. The formulas and calculation methods are as follows:
KEY(A) = HASH(A, C, TA)
The amount is Amt, the value is:
VALUE(A) = HASH(KEY(A), Amt)
State Transition, formally ST:
State Transition Tree Root, formally STR, s, e represent Start, End respectively:
The submitter finally updated the state of the balance of all dealers to the Fee Manager Contract.
As illustrated in the diagram provided above, once the submitter submits the updated status, a one-hour window is allocated as an open Challenge period. Within this timeframe, anyone has the opportunity to challenge the submitter's submission.
The process of Challenge is triggered by the Challenger through the Fee Manager Contract, involving a specified margin as a pledge. At this point, the Submitter's margin is also locked and a response is required to the Challenge process.
The Submitter provides the middle block number and its corresponding status. The validation of Pairm1 can be confirmed using a Merkle proof.
The Challenger is required to react to Pairm1. At this point, two scenarios arise:
If Challenger aggress with Submitter’s Pairm1 , the protocol will identify a smaller dispute, Pairm2 , m2 = ⌊(m1 + e)/2⌋.
If Challenger disagrees with Submitter’s Pairm1 , the protocol will identify a smaller dispute, Pairm2′ , m2′ = ⌊(s + m1)/2⌋.
Submitter and Challenger will finally Pair at most ⌈loge−s⌉ f2 rounds.
At this moment, the Submitter is obligated to demonstrate the validity of BT(f,m) and provide evidence of the ongoing presence of the Pair. Kz2 is the proving key of the circuit:
The Submitter Consensus Election is a process that ensures the validity of nodes. Nodes interested in becoming Submitters need to commit a portion of their funds upfront to meet the minimum requirements. In each epoch, the committee goes through a consensus election round, selecting a node from the qualified ones. This elected node is then responsible for submitting the current round's income state tree.
This consensus election process for Submitters differs from that of POS public chains. Unlike the need for over 2/3 of honest nodes in PBFT-based election mechanisms, having even a single honest node is sufficient to maintain the process. Any malicious behaviour by nodes is discouraged by incentives, and reporting such behaviour leads to their removal from the committee.
Two significant advantages of the Submitter Consensus Election are safety and liveness. Safety ensures correct calculations of Dealer income updates and Maker handling fees, which are accurately linked to each cross-rollup transaction. Liveness guarantees timely updates to income statuses, enabling dealers and makers to deposit and withdraw funds at their convenience.
