Orbiter Dealer: the Decentralized Frontend of Orbiter Bridge Protocol

6 min readOct 9, 2023

Background introduction

For most Web3 users, we can connect to the front end of the Dapp through a web3 wallet such as MetaMask, and then perform a few simple steps to send a transaction on the chain.

However, when the running environment of these Dapp front-ends is down and inaccessible, users will not be able to easily execute target transactions. Users need to master certain smart contracts and related blockchain technology knowledge and develop access scripts by themselves, which is very important for large users. It’s not feasible for some people!

Up to now, the Web3 community technology team has proposed decentralized file storage systems such as IPFS, StorJ, and Arweave to replace centralized cloud service platforms such as AWS, Azure, and Google Cloud. Dapps can use them to The static page tools of the front-end website are deployed into the decentralized storage system, so that users can access the decentralized Dapp and then interact with the blockchain service.

However, these current decentralized storage systems cannot well support the deployment of a wide range of Dapps, and have the following problems:

The user experience is still not comparable to the front-end of Web2, such as access speed and web browser compatibility, which will cause users to have to change their original usage habits.
The incentive mechanism of the storage layer is decoupled from the application layer. Although there is a certain incentive model in the decentralized storage protocol, this incentive model is isolated from the corresponding Dapp service. When there is a mismatch between the incentives of the storage layer and the application layer, To a certain extent, it will prompt the emergence of evil scenarios in the storage layer, which will eventually lead to users accessing an evil front-end web page.

How does Orbiter Finance implement a decentralized front-end?

Through open protocols, Makers and Dealers can reach point-to-point cooperation agreements. One Maker can cooperate with multiple Dealers, so that there is no longer only one front-end operator.
Through reasonable incentives, let the Dealer deploy a front-end that does not do evil. Even if a Dealer does evil, users can choose other Dealer services to minimize the degree of financial damage.

We briefly introduce the functions of several key modules here to help you understand the core content of this article. If you are interested, you can read the Orbiter Bridge technical yellow paper to understand the overall operating mechanism of the Orbiter Bridge Protocol.

— Maker：Cross-Rollup LP fund provider

— MDC contract: used to manage related configurations of cross-chain services

— Dealer: decentralized front-end role

— FeeManager contract: a contract module that manages Delaer’s profits

— Submitter client: periodically updates Dealer’s profit balance data to FeeManager

As long as cross-rollup transactions pass through Dealers and Makers, each transaction can accurately calculate the relevant profit sharing of the Dealer and the Maker.

An example of Dealer’s cross-chain profit sharing:

Signing of profit sharing agreement:

Dealer3 signs a profit sharing agreement with MakerB, binds Dealer3’s ID number 5 and its associated address 0x_dealer_3 and makerB’s address 0x_maker_b on the FeeManager contract, and shares profits at a rate of 5%

Accurate calculation of profit sharing value:

Users need to transfer 100 USDT assets from the Arbitrum to zkSyncEra.

The user chooses MakerB as the provider of cross-chain LP through the front-end provided by Dealer3. After calculating the relevant handling fees, the user needs to transfer a quota of 102 USDT to Arbitrum’s MakerB address. At the same time, the front-end of Dealer3 needs to transfer the amount at the end of the amount. Add some identification codes, that is to say, the user’s final specific transfer amount is as follows:

102000000000000000253

The last four digits of the withdrawal amount, where

02 represents the intention of the user’s goal chain
5 represents the binding ID of Dealer3 with MakerB. You can find the corresponding address of Dealer3 and the related profit sharing ratio through the (0x_maker_b, 5) tuple on the FeeManager contract.
3 represents Maker’s related fee service configuration. It can be determined in the MDC contract that the service fee this time is 2 USDT, which will not be elaborated here.

After completing the cross-chain transfer, the Submitter will summarize the event with the cross-chain events of other users, obtain a transaction batch, conduct precise calculations, obtain the amount of profit that the Dealer corresponding to each cross-chain transaction should receive, and calculate A Merkle Root. This Root can accurately summarize the profits under each Dealer account. We get that in this transaction, the profit that Dealer3 should obtain is 2 USDT * 5 % = 0.1 USDT. This amount will be allocated as the user uses Dealer3 The number of front-end increases and the superposition

Dealer withdraws profits

After the Submiter updates the Merkle Root, Dealer3 can obtain the Merkle Proof data corresponding to its own account through the Submitter’s RPC. Through this data, it can access the FeeManager contract and Dealer3 can withdraw the corresponding profit balance.

Security Model

The Submiter will accurately map the cross-chain Tx to the L1 area through a specific mapping rule (this rule is related to the timestamp of the Tx, the timestamp of the L1 block, and the characteristics of the Rollup network. For details, please refer to Chapter 6.2 of the Yellow Paper). On the block, when Submiter submits Merkle Root, it will bring the corresponding L1 block interval number information, as shown in the figure below, thereby ensuring that every cross-chain Tx can be perceived by FeeManager.

When submitting the Dealer balance status world, the Submitter will bring the following information

Merkle Root: can show the token balance of each Dealer
The corresponding L1 block range, such as (Block_100, Block113]
The Merkle Root of the continuous block state transfer corresponding to the block. This data is used to reflect the process of each block state transfer.

Fraud Challenge Model

After the Submitter submits the Merkle Root update, a challenge time will be reserved. At this time, anyone can challenge the correctness of the Merkle Root. However, a certain amount of funds needs to be pledged before the challenge to prevent DOS attacks.

If the Submiter does not follow this rule and maliciously modifies, increases, or decreases some cross-chain Tx, the challenger only needs to prove that the Tx information in one of the L1 blocks has malicious behavior. Here we introduce a binary search method.

As shown in the figure below, the perpetrator Submitter submitted the Merkle Root corresponding to the cross-chain Tx in the block from Block_100 to Block_113. Each block corresponds to a Merkle State, and each Merkel Sate is generated based on the previous Sate and the corresponding Tx.

The perpetrator Submitter maliciously added a cross-chain Tx in BLock_112, resulting in the final S_114 being incorrect and being challenged by others.

Round1: Lock S_107 and find that the status is correct, so the abnormal block is in the right range
Round2: Lock S_110, the status is correct, the abnormal block is in the right range
Round3: Lock S_112, the status is correct, the abnormal block is in the right range
Round4: Lock S_113, this status is wrong, so the abnormal block is in S_113

At this time, the perpetrator Submitter needs to provide proof of mapping of each cross-chain Tx under the block, proving that these Tx have been correctly executed between the Rollup network, and can obtain the status. If it cannot be given Prove it and you will be punished.

Zero-knowledge proof technology enables low-Gas Tx validity verification

In the above-mentioned fraud challenge process, we will use zero-knowledge proof to prove the validity of cross-chain Tx, so as to reduce the gas cost of the proof process and achieve a relatively low cost.