|
在第一步之后,第二步可以立即进行。如果 Ivan 证明第二笔交易跟第一笔交易之间的差异非常小，那么甚至可以在合约里设置规则，允许收取更高的费用。 “最坏的情况”是 Ivan 没有像预期的那样向 ALICE_B 发送代币。在这种情况下，Alice 可以等待Rollup A上的交易确认，然后通过其他途径获得Rollup B 上的代币用来支付跨 Rollup 传输的手续费，然后她自己就可以 claim，获得资金。 按照 V 神的解释，用户 Alice 可以直接在 Rollup B 上完成。只需要让 Rollup B 可以获得在前一 批 Rollup 记录之前的 L1 上的相应 hash 记录，然后 RollupB 就能够记录下来 Merkle 分支，能够在 Rollup 里验证。 通俗来说，通过技术方式能够确保用户 Alice 在 Rollup A 上交易确认之后，可以有方式安全的在 Rollup B 上领取到对应的资金（支付了手续费之后），避免因为其中某一个或者几个交易中介出现问题，导致资金受损。 无论这个交易中介 Ivan 是谁，为什么别人会选择转给他代币，这些可以暂时不管；这里的含义是，存在连接层，让存入到各类孤立的 Layer2 智能合约上的资金保持同步，实现跨 Rollup 转账的功能。 具体的实现细节，可能要了解在 Rollup B 上的合约 IVAN_B 的规则了。遵从下面的设定（为便于理解有所删减）： 如果任何人发起一个交易，发送若干数量的比特币到 IVAN_A 这个账户（存在 Rollup A上），在 memo 中，包含了目标地址的信息。那么，在若干时间之后，他们可以向合约 IVAN_B 发送一笔交易，该交易包含了转账的证明，该证明能够将对应数量的比特币提到在 Rollup B 上的目标地址之中。提款要经过一些延迟(例如，1天的时间)，是为了确保对应的转账批次和索引可以记录到 Rollup A 的 Layer2 网络之中。当 Ivan 在 IVAN_A 收到资金时，他可以自己将代币发送到目标地址。他可以通过 IVAN_B 合约发送交易。在这种情况下， Ivan 充当了结算商的角色，可以收取一定的转账手续费，让 Rollup A 这个只支持简单转账交易的Layer2 网络，和可以支持智能合约交易的 Rollup B，能够连接起来。而通过转账证明、Merkle 索引等方式，也确保用户资产能够在转移过程中不会遇到损失。 结算商充当了跨 Rollup 转账的协作角色Ivan 自己也需要进行内部结算，毕竟有可能在某个 Rollup 上会耗尽资金。比如，用户一直在通过 Rollup A 向 Rollup B 转账，需要通过 Ivan 在 Rollup B 上的储备资金转给用户所指定的地址。这时候 Ivan 这类交易中介，就需要进行内部结算了，也因此这提案的限制，会要求 Ivan 这类中介商持有大量的资金在账户之中，以便服务用户需求。 我们用法币举例，或许能更好理解。如果你从工商银行向建设银行的卡转账，尽管 ATM 机上显示立即变更了，但是实际的结算过程是每天进行一次，只有在工行结算后，才将实际的资金转给建行，更具体来说，是通过在央行的结算账号之间进行的。 (责任编辑：admin) |