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

除了便宜和迅捷，Orbiter的cross rollup机制也非常的安全。

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?

除了作为桥接协议便宜和快速之外，安全性是最重要的。 Orbiter 的具体机制是如何来确保交叉汇总过程对 Sender 和 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:

首先，Orbiter Finance 旨在解决 cross-rollup问题，而不是跨链问题。 Vitalik 已经明确表示：

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.

跨链项目的主要目标是确保两条独特链之间的交易安全，避免 51% 攻击。 但是cross-rollup项目每次rollup使用相同的以太坊数据层，自然可以防止51%攻击。 基于此，Orbiter 提出了一种交叉汇总机制，可以继承以太坊 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.

Orbiter Finance的具体机制

Orbiter 被设计为一个去中心化的乐观交叉汇总桥，用于在 L1 和 L2 之间转移以太坊原生资产。

系统有两个角色：Sender 和 Maker。 Maker 需要在 Orbiter 的合约中存入超额保证金，然后才能为 Senders 提供交叉汇总服务。 在正确的通常过程中，Sender 将发送给 Source Network 上的 Maker，Maker 将发送回 Target Network 上的 Sender。

这里有几个关键问题：

• Maker 如何正确、自动地将其发送回 Sender？

• Maker 未将代币发回目标网络时，如何确保 Sender 可以取回代币？

• 如何确保Orbiter 的合约能够安全地保持Maker 的保证金？

让我们用下面的流程图来看看 Orbiter 的具体机制。

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:

Orbiter 以乐观的方式支持高频交叉汇总事务，因此它可以足够便宜且足够快，以长期适应更多交叉汇总用户案例。 如果你已经测试过 Orbiter App 并在区块浏览器上查看了交易日志，你会发现你已经将它发送到了 Maker 的 EOA 地址，而不是合约的地址。 这是 Orbiter 和其他桥接协议之间的显着区别。

Maker 可以开发和运行一个客户端来自动提供服务，或者使用 Orbiter 团队的开源客户端：

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.

Sender 将其发送给 Source Network 上的 Maker 后，再将其发送回 Target Network 上的 Sender，Maker 需要知道 token 类型、回传数量以及它在哪个 Target Network 上。 Maker 是如何得到这三个参数的呢？

• 代币类型和返还金额。 Maker在Orbiter的MDC合约中存入保证金时需要设置代扣费（固定费用）、交易费（0.04%~0.3%）和支持的代币类型。 这些设置的参数将保存在 Orbiter 的 EBC 合约中，并与 Maker 的客户同步更新。 Maker 知道回传代币类型，并以此方式收到 Sender 的资金后计算回传金额。

• 目标网络。 Orbiter 使用“安全码”来记录目标网络。 安全码和目标网络之间的对应关系也保存在 MDC 合约中。 汇款人需在转账金额小数点后添加安全码。 然后，Maker 将知道目标网络是哪个。

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.

制造商有动力立即正确地发送回发件人。

首先，在 Orbiter 的机制中，Maker 可以从每项服务中获得可观的收益（没有无常损失风险）。 其次，如果 Maker 没有及时正确回传给 Sender，Orbiter 的 MDC 合约会进行回传，并以 Maker 的保证金补偿 Sender。

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.

iter的系统：

• MDC 合约（Maker 存款合约）。 MDC 合约有两个功能 - 保留 Maker 的保证金和为发件人处理返还和补偿。

• EBC 合同（事件绑定合同）。 EBC合约用于制作Source Tx和Target Tx的有效性证明。 EBC 也保留了 Orbiter 的规则： ① Maker 在不同的 rollups 上存入保证金的规则。 ② Source Tx和Target Tx的对应规则。

• SPV 合同。 SPV 用于在 Source Network 上制作 Source Tx 的存在性证明。

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:

我们需要一个 MDC 和一个 EBC； 他们可以支持 Orbiter 中的所有域。 但是，我们需要为 Orbiter 连接的每个域建立一个 SPV 合约。 MDC、EBC 和 SPV 将部署在同一个域上，该域可以是 L1 或任何 EVM-L2。

MDC、EBC 和 SPV 如何合作为 Sender 解决争议？ 一旦 Maker 没有正确发送回 Sender，将依次执行以下步骤来帮助 Sender 获取令牌：

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.

8. Sender 需要向 SPV 提供相关的 Source Tx。

   发送方通过 Orbiter 的 MDC 合约发起仲裁。

   MDC 从 SPV 获得 Source Tx 的存在证明，并知道 Source Tx 发生在 Source Network 上。

   MDC 从 EBC 获得 Source Tx 的有效性证明。 MDC 将知道 Source Tx 合法地基于 Orbiter 的规则；源 Tx 是从发件人发送到带有合法安全代码的 Orbiter 制造商之一。

   然后，MDC会将此仲裁设置为未决案件，并等待Maker提供Target Tx 0.5~3小时（此功能可在Maker客户端聚合，Maker不会错过）。如果 Maker 可以提供正确的 Target Tx，MDC 将从 EBC 获得有效性证明，并知道 Target Tx 与 Source Tx 匹配。 MDC 将关闭此仲裁并将 Target Tx 显示给 Sender。但是，如果 Maker 在 0.5~3 小时后无法提供相关的 Target Tx，Sender 可以申请提现，然后进行下一步。

   MDC 开始补偿 Sender。

   MDC 会将代币和补偿（约 15 美元）发送回 MDC 部署的域上的 Sender。返还代币和补偿来自 Maker 的保证金。

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.

Orbiter 的机制是否存在风险？ 在任何极端情况下，我们都需要解决 Sender 和 Maker 的所有潜在风险。

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.

由于 Maker 的保证金用于保证回送，当多个 Sender 同时发送给一个 Maker 时会出现问题。由于 Maker 的保证金少于收到的总资金，因此 Maker 可以通过不向这些发件人发送回款来赚取更多收益。这将导致发件人出现双花问题。

Orbiter 使用超额保证金机制来解决双花问题。 Maker 应根据 Orbiter 的 MDC 合同规则在其他域上存入不同数量的超额保证金。保证金的最低金额与源网络是否有 EVM 有关：

• 使用EVM：Orbiter 的MDC 合约可以将一个区块划分为5~10 个槽位； Maker 需要存入至少 5~10 * 限制保证金来支持这个网络。 “限制”是每次交叉汇总转移的最大金额。

• 无EVM：为支持dYdX、Loopring、Immutable X 等无EVM 的领域，Maker 需要在MDC 合约中存入更多保证金。保证金金额与域的块大小相关；它可能是 100~200 * 限制。

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.

所有 Maker 的保证金都将保留在 Orbiter 的 MDC 合同中。 如前所述，Orbiter 是一个交叉汇总协议，仅支持以太坊原生资产； Orbiter 不会面临 51% 的攻击风险或跨链动机带来的其他风险。 但 Orbiter 的合约在向第三方做市商开放之前仍需要进行审计。

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:

我们正在以最快的速度发展以实施上述计划，并成为 L2 的基础设施。 以下是 2022 年的 Orbiter 计划：