作者：NicLin，imTokenLabs资深区块链工程师
本文受众：区块链开发者、对Rollup有所了解的区块链爱好者
本篇是RollupBridge介绍的第五篇，主要用来补充第二篇HopProtocol第一部分的运作细节，建议先从第二篇看起：
以下所称的L2皆指Rollup而非Plasma或侧链以下所称「资产」和「代币」两个词指的是一样的东西以下所称「七天」和「Rollup挑战期」两个词指的是一样的东西以下示意图中Arbitrum会是RollupA，Optimism会是RollupB，使用者要将资产从RollupA跨到RollupBHopProtocol第一部分中用fasttransfer代指跨Rollup的transfer，来和第一篇MakerBridge的fastwithdraw做区隔，不过本文会用transfer/withdraw代指一样的事情Recap:Relaytransfer资料
为什么要relaytransfer资料？
因为transfer资料是客观的资料，Hop合约不能随便相信流动性提供者说他替谁先垫付了某笔transfer就拨款给Bonder，Hop合约只会认transfer资料来确认实际上transfer是否发生，所以Hop合约只有等到transfer资料真的抵达RollupB时才会拨款给Bonder。
对使用者来说，如果Bonder帮他垫付了，则他完全不需担心transfer资料的relay过程。但如果Bonder下线了，使用者就要自己把transfer资料relay到RollupB来向Hop合约证明并取回自己应得的代币。
注：Hop把transfer资料从Rollup送到L1的过程叫做commit。
Recap:BatchTransfer
HopProtocol第一部分有提到为了节省Bonder的成本，Hop设计让transfer可以以batch的方式一次commit回L1，不需每一笔都commit一次。而batch的条件分别是(1)累积512笔transfer或(2)离上一次该Bondercommit的时间已经过了一天。
注1：条件(2)是为了在不打扰Bonder前提下让使用者能够自己完成relay的条件：当Bonder下线太久时，使用者可以自己把transfer资料commit到L1，再relay到RollupB。
注2：Bonder自己来commit时可以不受(1)限制，不管累积几笔transfer，随时都可以commit。
而batchtransfer也不会真的把batch里面所有transfer资料都commit进去，而是把transfer资料组成一个MerkleTree，然后只commitMerkleRoot。当要使用到transfer资料时，再提供MerkleProof来证明transfer存在于该MerkleTree里。
注：实际上commit的函式名称为commitTransferRoot。这里看到Hop用的是transfer的字眼，而待会可以看到在RollupB上的操作Hop会用withdraw，但其实两个指的是一样的。
接下来会搭配图示介绍使用者和Bonder的操作流程及challenge机制。
使用者视角的运作流程
对使用者来说，使用Hop会有两种结果：(一)Bonder为你在RollupB上垫付，或是(二)Bonder没有垫付，导致使用者必须自己完成把transfer资料从RollupArelay到RollupB的旅程。
结果一：Bonder有垫付
Happycase：Bonder完成垫付
1stTx
使用者发起withdraw，他有两个选择：如果使用者有hUSDT，则他直接触发L2_Bridge合约的send函式；如果他没有hUSDT，则触发AMM_Wrapper合约的swapAndSend函式，先用USDT去换成hUSDT。L2_Bridge合约会销毁hToken，表示资产从RollupA离开，并emitevent，让Bonder知道。
2ndTx
接着Bonder执行垫付，如果使用者要收hUSDT，则合约会直接铸造hUSDT给使用者，如果使用者要收USDT，则会多一步，把铸造的hUSDT去换成USDT再给使用者。
结果二：Bonder没有垫付
Unhappycase:使用者要自己relaytransfer资料到RollupB来领取资产
这边的步骤是接续在使用者已经透过L2_Bridge合约申请withdraw并销毁hToken之后。
1stTx
如果使用者的withdraw刚好是第512笔withdraw，则会直接触发commitTransferRoot函式，将TransferRoot送到L1。
如果不是的话，则他需要等到离Bonder上次commit时间的一天后才能自己去执行commitTransfer，commitTransfer会去触发commitTransferRoot函式，将TransferRoot送到L1。
2ndTx
接着就要等到RollupA的挑战期过后，才能完成TransferRoot到L1的写入。假设今天该TransferRoot已经经过了七天挑战期，则任何人都可以去把TransferRoot的跨链讯息relay到L1_Bridge合约，这笔交易会同时把TransferRootrelay到RollupB。
3rdTx
通常等个五到十分钟，TransferRoot就会被relay到RollupB上的L2_Bridge合约。等到TransferRoot被写进L2_Bridge合约后，使用者就可以触发合约的withdraw函式，提供MerkleProof去证明自己的withdraw存在在这个MerkleTree里，这时合约就会直接铸造hUSDT给使用者，完成withdraw。
Bonder视角的运作流程
第一步：流动性提供者先垫付
第一步是Bonder发现使用者在RollupA上申请withdraw后，他在RollupB去触发bondWithdrawalAndDistribute函式，垫付给使用者。
你可能会以为垫付是Bonder将自己的hToken转给使用者。但实际上的过程是：合约会铸造新的hToken给使用者，然后在合约的帐本上记录下该Bonder因为这笔垫付所新增的负债。
第二步：等待TransferRoot被commit
Bonder可以等待凑满512个withdraw再开始relaywithdraw资料。或是提前去RollupA的L2_Bridge合约触发commitTransfer，开始relaywithdraw资料。当Bonder在RollupB的负债多到他没办法再垫付后，他就可能会提前去触发commitTransfer。
第三步：在TransferRoot被写进L1_Bridge合约前，先为该TransferRoot做担保
因为等待RollupA挑战期结束才能relayTransferRoot的时间可能太久了，会影响Bonder的资本效率，所以Hop做了一个trade-off：引入一个challenge机制。
Bonder可以为自己的TransferRoot担保：不需要等到RollupA挑战期结束并把TransferRoot写入L1_Bridge合约，就可以直接去触发bondTransferRoot，把TransferRootrelay到L2的合约。等待五到十分钟TransferRoot写进L2_Bridge合约后，Bonder就可以触发settleBondedWithdrawal，将之前垫付所累积的负债抵销。
Bonder在执行bondTransferRoot时要顺便抵押TransferRoot总金额的110%。因此当一个Bonder担保一个假的TransferRoot，意图在RollupB抵销负债被抓到时，他在L1会被没收的金额会是他在RollupB抵销负债金额的110%，所以想要造假是有风险在的。
注：TransferRoot总金额指的是这一批withdraw金额的加总。
但如同其他challenge机制，challenge也是有时效性的。目前如果Bonder触发bondTransferRoot后，经过一小时都没有人challenge的话，则该TransferRoot就会被视为合法，不能再被challenge。
第四步：Bonder完成TransferRoot的relay，将TransferRoot写进L1_Bridge合约
等到RollupA挑战期过后，Bonder就可以将TransferRoot的跨链讯息relay到L1_Bridge合约。但如果Bonder没有被challenge的话，其实他没有动机要完成relay。不过只要Bonder担保的是正确的TransferRoot或是Bonder造假TransferRoot都有被抓到的话，没有完成TransferRootrelay不会影响系统的安全性。
当TransferRoot被challenge
第一步：bondTransferRoot
首先，从BonderbondTransferRoot开始。
第二步：challenger抵押TransferRoot总金额10%来挑战TransferRoot
如果challenger发现Bonder产生的TransferRoot不合法，例如里面偷偷夹带了不存在的withdraw，则challenger可以透过抵押TransferRoot总金额的10%来进行challenge。
Challenge被申请后，L1_Bridge合约会把Bonder担保的金额新增到Bonder的负债。
注：如果没有被challenge，系统就会放行，不以增加Bonder负债的方式来扣住Bonder资产。
如果challenge成功，则负债会保留，表示Bonder的钱被系统没收；如果challenge失败，系统会从Bonder负债中减去原本担保的金额，表示系统将钱还给Bonder。
第三步：等待RollupA挑战期结束，将真正的TransferRoot写进L1_Bridge合约
等到RollupA挑战期过后，Bonder或Challenger就可以将TransferRootrelay到L1_Bridge合约。但还不能resolvechallenge，Hop有设定一个challengeResolutionPeriod来确保challenge可以resolve时，Rollup挑战期已经结束，意即确保TransferRoot已经被写入L1_Bridge合约里了。
注：目前challengeResolutionPeriod是十天。
第四步：等待challengeResolutionPeriod结束
真正的TransferRoot讯息抵达后就可以验证Bonder当初担保的TransferRoot是不是对的，决定challenge是否成立。
如果challenge不成立，系统会从Bonder负债中减去原本担保的金额，表示系统将钱还给Bonder。而Challenger的抵押则会被没收。
如果challenge成立，则Bonder的负债会保留，表示Bonder的钱被系统没收。Challenger除了拿回自己的押金，还会获得Bonder担保金额当作challenge奖金的那10%。
注：奖金其中有一半会被销毁，目的是避免Bonder自己challenge自己，同时拿回完整的押金和奖金。
风险评估
使用者风险
如果Bonder有垫付给使用者，则使用者成功完成withdraw，皆大欢喜。
如果Bonder没有垫付给使用者，则使用者必须要自行完成TransferRoot的relay，这会需要讯息能够正确地从RollupA->L1->RollupB传递。
不过只要Hop合约和RollupL1<->L2messegebridge都有顺利接上，且Rollup都正常运作，就能够达成，这是一个相对可靠的安全假设。所以对使用者来说，风险是相对小很多的。
Bonder风险
因为Bonder们的钱都锁在同一个合约，所以假设有challenge没被抓到，则代表攻击者可以凭空降低自己的负债、提走不该提走的钱，这对所有Bonder都会造成损失。
而目前一小时的challengewindow其实是相对短暂的，再加上一个withdraw可以是从任意?Rollup转任意资产到任意其他Rollup，要假设整个系统内所有的withdraw都能被监控会是一个具有挑战性的要求。
风险提示：本文内容均不构成任何形式的投资意见或建议。imToken对本文所提及的第三方服务和产品不做任何保证和承诺，亦不承担任何责任。数字资产投资有风险，请谨慎评估该等投资风险，咨询相关专业人士后自行作出决定。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。