作为桥协议，除了便宜和快速之外，安全性是最重要的。我们通过本文详解Orbiter的具体机制，如何确保跨rollup对sender和maker都足够安全
首先，Orbiter Finance要解决的是跨rollup问题而不是跨链问题。Vitalik已经在这篇文章中详述过
Why not cross-chain? And why cross-rollup apps within one zone of sovereignty is fine?
跨链项目的主要目标是确保两个独特链之间的交易安全，避免51%攻击。但跨rollup项目使用相同的以太坊数据层，每个rollup都可以防止51%攻击。基于此，Orbiter提出了一个可以继承以太坊L2安全性的cross-rollup机制。
Orbiter被设计成一个optimistic 跨rollup桥，用以在以太坊原生资产和L2之间来转移资产。
系统有两个角色。Sender和Maker。在为Sender提供cross-rollup之前，Maker需要在Orbiter的合约中存入多余的保证金。在正确的执行过程中，sender将资产发送至resource网络上的maker，而maker将资产发送回目标网络上的sender。 这里有几个关键问题。
Maker如何正确、自动地将资产送回给Sender？
如何确保当Maker没有在目标网络上发回代币时，Sender可以拿回代币？
如何确保Orbiter的合约能够安全地保持Maker的保证金？ 让我们通过以下流程图来看看Orbiter的具体机制。 Let’s see Orbiter’s specific mechanism with the following flow chart. 我们通过下图看看Orbiter的具体机制
正确过程
Orbiter以一种optimistic方式支持高频的跨rollup交易，足够便宜和快速，以适应长期的跨rollup使用案例。如果你已经测试了Orbiter App，并在区块探索器上查看了交易日志，你会发现你已经把它发送到了一个Maker的EOA地址，而不是合约的地址。这就是Orbiter和其他桥协议的显著区别。
Maker可以开发和运行一个客户端来自动提供服务，或者使用Orbiter团队的开源客户端。
https://github.com/OrbiterCross/OrbitalModule/tree/main/.
Sender在源网络上将资发送给maker之后，为了把资产在目标网络上发还给sender，maker需要知道token的类型、发还的数量，以及是在哪个目标网络上。maker如何得到这三个参数？
Token种类和发还数量。Maker在Orbiter的MDC合约中存款时，需要设置预扣费（一个固定的费用），交易费（0.04%~0.3%），以及支持的token种类。这些设定的参数将被保存在Orbiter的EBC合约中，并与Maker的客户端同步更新。Maker知道回送代币的类型，并在收到sender的资金后以这种方式计算回送金额。
目标网络。Orbiter使用 "安全代码 "来记录目标网络。安全代码和目标网络之间的对应关系也保存在MDC合约中。Sender需要在转账金额的小数点末尾添加安全代码。然后，maker将知道目标网络是哪个。
Maker被激励着即时和正确地发送回给sender。
首先，首先，在Orbiter的机制中，Maker可以从每项服务中获得可观的收入（没有无常损失风险）。其次，如果Maker没有及时向Sender发送正确的信息，Orbiter的MDC合约将会进行发送回去，并以Maker的保证金补偿Sender。
不正确的过程序和Orbiter合约系统
** **
Orbiter的合约系统会处理低频不正确跨rollup交易。Orbiter的系统中有三种智能合约。
MDC合约（Maker的存款合约）。MDC合约拥有两种功能—保存Maker的保证金和sender的发回和补偿。
EBC 合约（时间约束合约）。EBC合约用于证明源Tx和目标Tx的有效性。EBC还保留了Orbiter的规则：① Maker在不同的rollup上存入保证金的规则。源Tx和目标Tx之间的对应规则。
SPV合约。SPV用于证明源网络上的源Tx的存在
我们需要一个MDC和一个EBC。他们可以支持所有Orbiter上的域名。但我们需要为每一个链接到Orbiter的域名构建一个SPV合约。MDC, EBC和 SPV将会被部署到相同的域名。这个域名可以在L1也可以是任何L2。
MDC、EBC和SPV如何合作，为sender解决争议？一旦Maker没有正确地将资产发送回给Sender，以下步骤将依次发生，以帮助Sender获得代币
sender需要向SPV提供相关的源Tx。
sender通过Orbiter的MDC合约发起仲裁
MDC 从 SPV 处获得源 Tx 的存在证明，并知道源 Tx 已在源网络上发生。
MDC 从 SPV 处获得源 Tx 的存在证明，并知道源 Tx 已经在源网络上发生。MDC 从 EBC 获得源 Tx 的有效性证明。MDC 将知道，根据 Orbiter 的规则，源 Tx 是合法的；源 Tx 是由sender发送至 Orbiter 的一个具有合法安全代码的maker。
然后，MDC 将此仲裁设为待决案件，等待 Maker 提供 Target Tx，时间为 0.5~3 小时（此功能可在 Maker 的客户端汇总，所以 Maker 不会错过）。如果Maker能提供正确的Target Tx，MDC将从EBC获得有效性证明，并知道Target Tx与Source Tx匹配。MDC 将关闭该仲裁，并向发送方显示目标 Tx。但是，如果Maker在0.5-3小时后不能提供相关的Target Tx，Sender可以申请提款，然后进入下一步骤。
MDC开始赔偿sender
MDC在部署了MDC的域名上向sender发回token和赔偿（约15美元）。发回的token和赔偿来自maker的保证金。
极端案例中的安全解决方案
Orbiter的机制中是否有任何风险？我们需要解决在任何极端情况下sender和maker的所有潜在风险。
消除sender的双花风险
由于maker的保证金是用来保证回送的，当许多sender同时向一个做市商发送时，就会出现问题。因为maker的保证金少于收到的资金总额，maker可以通过不向这些sender发送回款来赚取更多的钱。这将导致sender的双花问题。
Orbiter使用超额保证金机制来解决双花问题。maker应根据Orbiter的MDC合约规则，在其他域名存入不同数额的超额保证金。保证金的最低数额与源网络是否有EVM有关。
有EVM。Orbiter的MDC合约可以将一个区块划分为5~10个槽；Maker需要存入至少5~10*极限保证金来支持这个网络。这个 "限额 "是指每次交叉滚动转移的最大金额。
无EVM。为了支持没有EVM的域，如dYdX，Loopring和Immutable X，Maker需要在MDC合约中存入更多保证金。保证金数额与域名的区块大小有关；可能是100~200 * 限制。
Maker的流动性资金安全 所有Maker的保证金将被保存在Orbiter的MDC合约中。如前所述，Orbiter是一个跨rollup协议，只支持以太坊原生资产；Orbiter将不会面临51%的攻击风险或其他由跨链动机引起的风险。但是Orbiter的合约在开放给第三方做市商之前仍然需要进行审核。
时间线
** **