该方案的主要限制是 IVAN_B 需要持有大量资金以确保所有发送者都将得到付款。特别是,假设:
在即将进行的 Rollup A 批次之前,Alice 可以自己检查有多少未处理的交易,可以从她在 IVAN_B 合约中看到的资本中减去该值,然后检查剩余金额是否足够。因为提款是按顺序处理的(这是上述队列机制的目标),所以 Alice 不必担心那些自己的交易之前被处理的提款。 一个批次可以交易的最大金额为 TRADE_LIMIT * TXS_PER_BATCH,因此 IVAN_B 合约需要至少持有这个数量的 ETH,加起来需要足以覆盖未处理的交易。例如,假设 TRADE_LIMIT = 0.1 ETH (低限制是可以的,因为可以通过多次交易完成更大的交易)并且 TXS_PER_BATCH =1000。那么,IVAN_B 将需要持有 100 ETH。 请注意,这种设计需要支付额外的隐性费用,因为任何交易量超过 0.1 ETH 的人都将浪费区块空间。 这是向资金要求妥协的:如果将区块浪费减半,则资金要求将增加一倍,反之亦然。 对于正确的余额,似乎隐性费用比市场上出现的显性费用小几倍。 如果我们想减少或消除这种浪费,可以设计 Rollup A 来这样做,例如,让 sequencer 发送一个签名的消息,向 Alice 证明到目前为止在批处理中批准的所有消息。 这样,Alice 就会知道在她前面没有交易(尽管恶意 sequencer 可能会以高昂的代价诱骗爱丽丝)。 Memos上面的设计假定 Rollup A 上的交易具有一个备注字段(memo field),Alice 可以使用该字段将 ALICE_B 指定为目的地。如果 Rollup 不具有此功能,那么我们可以使用以下解决方法。Alice 可以按顺序注册表合约在 B 上注册 ALICE_B,并获得按顺序分配的 ID (因此,爱 Alice 的 ID 等于在她之前注册的用户数)。令 MAX_USER_COUNT 为最大用户数;如有必要,此值可以随时间向上调整。Alice 只需使用 TRADE_VALUE 的低位数字(表示无足轻重的金额)来表示她要交易的金额,即可确保 TRADE_VALUE%MAX_USER_COUNT 等于(Alice 的 ID)。 Rollup B 到 A 的交易如果 Alice 从 Rollup B 上的币开始并将其移动到 Rollup A,则可以使用类似的机制,但角色相反:
来源链接:www.8btc.com (责任编辑:admin) |