Gravity bridge——IBC Bridge to Ethereum
Posted mutourend
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Gravity bridge——IBC Bridge to Ethereum相关的知识，希望对你有一定的参考价值。
1. 引言
前序博客有：
Gravity由Osmosis network开发，为以太坊 与 Cosmos生态链 之间的bridge，可实现token之间的相互转换。不同于其它bridge，Gravity采用IBC协议，为完全非监管的，仅需要信任Cosmos chain的安全性，而不需要信任任何第三方的bridge管理员，这些bridge管理员存在携款潜逃的可能。【Osmosis采用Cosmos SDK中标准的DPoS staking 机制。为了便于表达，后续将Osmosis统称为Cosmos。】
Gravity相关代码见：
借助Gravity，为：
- 给以太坊上的Gravity合约发送25 DAI，指定接收的Cosmos地址。
- Cosmos链上的Validators看到你确实已往以太坊的Gravity合约中发送了25 DAI，在Cosmos接收地址mint 25 DAI。
- DAI可发送给Cosmos中的其他账号，用于Cosmos应用、或者通过IBC发送给其它Cosmos链等等。
- 为了返回以太坊，可将25 DAI发送给Cosmos链上的Gravity module，指定接收的以太坊地址。
- Cosmos validators会burn掉Cosmos链上的这25 DAI，然后向以太坊上的Gravity.sol合约发起交易，将25 DAI发送给以太坊接收地址。
2. Gravity
Gravity由4部分组成：
- 以太坊上的 Gravity.sol 合约
- Cosmos上的 Gravity module
- 由Cosmos validators 运行 的随Cosmos区块链代码一起运行的orchestrator（编配）程序
- a market of relayers：这些relayers会竞争，代替Cosmos validators来向以太坊提交交易。
2.1 以太坊端的Gravity.sol合约
Gravity.sol合约的主要作用为锁定以太坊链上的ERC20 token，使得其可在Cosmos上mint出来。
当前的Cosmos validators 控制Gravity.sol，具体控制比例取决于其在Cosmos链上的validation power。
Gravity.sol中存储了a checkpoint——对应为the active validator set on the Cosmos side at a given moment in time。
a checkpoint为a set of addresses and their validation power。The more validation power an address has, the more its vote counts。
Gravity.sol中的method为public的，可由任意relayer调用，但是必须包含超过2/3+的当前checkpoint的validator set的签名。
2.1.1 updateValset
由于Osmosis上的validator set总是在变化，随着Osmosis token持有者将其token委托给不同的validator，validator的power会变化。Cosmos validators会调用Gravity.sol合约中的updateValset方法来更新its stored checkpoint to the latest validator set。若某validator未对an update进行签名，或者更糟的是，对欺诈update进行签名，则会被slash掉，损失其在Cosmos链上的资产。
2.1.2 sentToCosmos
用户会调用Gravity.sol合约的sendToCosmos方法来将以太坊的token转移至Cosmos。该方法会从用户那接收一定数量的ERC20 token然后锁定在Gravity.sol合约内，同时会释放an event，使得Cosmos validators知道其应在Cosmos端为该用户mint相应数量的token。
2.1.3 submitBatch
当用户将Cosmos链上的token发送给Gravity module，并指定了以太坊端的接收地址。
用户可attach a fee to compensate whoever relays their transaction。
为了节约gas费，由Cosmos发往以太坊的token是以批量进行的。
Gravity module会创建batches of transactions of one type of token，然后validators对这些batches进行签名。
Relayers会调用Gravity.sol合约的submitBatch方法来提交batches：
- 首先检查该batch has signatures from 2/3+ of the validator set in the current checkpoint。
- 然后检查该batch具有a nonce that is higher than any other batch of the same token type that was already submitted。
- 然后send ERC20 Ethereum transactions transferring the tokens to their destinations。Gravity.sol也可send the fees on the transactions to
msg.sender（即发起该交易的relayer）。
2.2 Cosmos端的Gravity module和orchestrator程序
Gravity module为基于Cosmos SDK构建的module，Cosmos链上包含了大量类似的module，由其validators同步运行。
每个validator 与 其它validators 运行的都是完全一样并确定性的逻辑。这些validators对a key-value store的状态达成共识，不同的的modules可具有状态的不同部分。
Gravity module负责在Cosmos链上mint代表以太坊ERC20 token的Cosmos token。
Gravity module会与orchestrator紧密合作。orchestrator会在每个validator上，与Cosmos代码一起运行。由于每个validator的cosmos module都是以相同的逻辑同步运行，因此，无法sign messages or transactions with a validator’s unique key。但是，安装了Gravity module的validators借助orchestrator，可实现签名操作。
2.2.1 Ethereum oracle
Gravity module必须知道what is going on on the Ethereum chain，从而才可mint tokens on Cosmos for people when they send tokens to the Gravity.sol contract on Ethereum，同时可see when a batch of transactions going from Cosmos to Ethereum has been successfully processed。
Cosmos链上具有Gravity module的每个validator都必须运行一个以太坊全节点。每个validator的orchestrator会监听该全节点的以太坊event。有一个名为EthBlockDelay的参数，orchestrator会监听以太坊链上EthBlockDelay之前的事件。EthBlockDelay参数可让validators放心该事件已在以太坊链上完全固化，当orchestrator看到来自于Gravity.sol合约的事件时，会将该事件放入a Cosmos message，签名并广播到Cosmos链上。
Gravity module会接收这些messages，并跟踪哪些validators已对各个以太坊event进行了投票。当event收到了超过2/3的validation power选票时，可认为其是“observed”，然后可修改Cosmos state。
当a SendToCosmosEvent is observed，Gravity module会为目标地址mint tokens。
当 a TransactionBatchExecutedEvent is observed，Gravity module会从batch pool中移除该batch，并取消该token type的任何earlier batches。
2.2.2 Transaction batching
由Cosmos到以太坊的交易，在发送到以太坊链上之前，会打包为batches。主要原因在于以太坊链上交易费昂贵，通过批量操作可将交易费分摊至该batch内的所有交易。
当用户想要将token由Cosmos发送到以太坊上某地址，用户先将token发送到Gravity module。Gravity module会从用户账户中扣除token，然后将一笔交易放入交易池中。交易池中存储了所有由Cosmos到以太坊的待打包的交易。
任何人都可向Gravity module发送a transaction request来收集a batch of a particular token type。通常由relayers来发起，relayers可relay a batch of tokens for profit。当Gravity module收到该message时，其会按如下流程收集batch：
- Find all transactions for the token
- Choose the 100 transactions with the highest fee and put them in a batch. The number of transactions may not be 100 in future. It may be configurable, or even dynamic。
- If there is a batch in the batch pool with a higher sum of fees than the newly assembled batch, discard the new batch. If not, include it in the batch pool. More on this later.
然后Gravity module会将batch放入batch pool中。一旦某batch加入到batch pool中，所有validator的orchestrqtors都会对该batch进行签名，并在Cosmos messages中提交签名。每个签名都会与其相应的batch一起存储。
relayers会持续监测batch pool中的batches，一旦某batch的签名数达到了Gravity.sol中当前checkpoint的validator set的2/3+，relayer就会将该batch提交到Gravity.sol。Relayers自身也可判断提交某特定batch是否可获利，然后选择提交可获利的batch。若batch中包含的 fee高于提交到以太坊所需的gas，则是可获利batch。当然，这是一个非常微妙的计算，它考虑了以太坊链上当前的平均gas price、链上的拥堵以及代币和以太坊gas之间的汇率。这就是为什么我们有一个自由的relayers市场。
一旦某batch在以太坊链上执行，Gravity.sol会释放TransactionBatchExecutedEvent事件。以太坊EthBlockDelay个区块之后，Cosmos validators会将该事件提交到Gravity module。当该event被fully observed（如上所述，即达到2/3+签名），该batch将从batch pool中移除，因为该batch已处理完毕。同时，会将batch pool中具有更低batch nonce的该token类型batches也都移除。原因在于，我们确认这些更低batch nonce的batches将无法提交，因为其batch nonces are two low。这种机制支持被打包进unprofitable batches的交易 有机会再次打包进 profitable batch中。
如上所述，Gravity module仅打包a new batch if there are no batches already in the batch pool with a higher sum of fees。这可防止以下场景：
- 当交易池中有大量unprofitably low fee交易，随后每个区块来了少量具有high fee的交易，在每个batch中包含一笔high fee交易 和一堆unprofitable交易。
这样的batch可能是unprofitable to submit，使得这些profitable交易因被打包进了unprofitable batches，而不被提交。
因此，要求每个new batch必须比现有待提交任何batch都更profitable，会给这种每个区块中少量的profitable交易机会，可被打包进一个足够profitable的batch中从而被提交。
3. Validator set updates
更新Gravity.sol中的validator set，与Cosmos当前的validator set一致。这一点很重要。
因为Gravity的trust model 要求 trusting Gravity.sol is the same as trusting the Cosmos chain running it。
valdiator set update必须有Gravity.sol中存储的checkpoint中的当前validator set的2/3+签名。
任何人都可发送a Cosmos message requesting a validator set update。当收到相应的request时，Gravity module会存储当前validator set的snapshot。然后validators对该snapshot进行签名。一旦达到Gravity.sol中当前checkpoint validator set的2/3+签名，relayer即可将它提交到以太坊链上。需要注意以下几点：
- Gravity module并不知道Gravity.sol中存储的当前checkpoint。因为
EthBlockDelay，Gravity module中所有关于以太坊的信息都是过时的。因此，需要依赖relayers来判断某validator set update是否有足够的签名可提交。 - relayers提交validator set update并没有激励。不像transaction batch，此时没有fees。后续更新可能会解决。有很多种方式可解决，在Cosmos端或以太坊端。但是目前，Cosmos链上运行Gravity的validators会设立一个无私的relayer，用于负责提交validator set updates。
- Gravity.sol不是Cosmos light client，其并不知道完整的Cosmos共识和质押流程。其本质是个多签，其签署中为某特定Cosmos链的validator set。我们在Cosmos端采用slash策略来保证正确性。
4. Slashing
Slashing为Gravity安全性的重要组成部分。Validators在Cosmos端或以太坊端若表现不正常，都会在Cosmos端进行Slash操作。This is what links the security of the Gravity bridge to the security of the Cosmos chain it is run on.
4.1 Liveness slashing for batches and validator sets
通过参与Cosmos共识流程，a validator隐式地声明该流程生成的所有validator set update和batches都是正确的。若某validator未对validator sets和batches签名，则该validator运行不正确。After a grace period，这种未签名行为将被slash。
4.2 Slashing for fake batches and validator sets
可能会存在向Gravity.sol合约提交 不是由Cosmos链生成的 batches和validator sets，只要这些batches和validator sets达到Gravity.sol合约中当前checkpoint validator set 2/3+的签名。为了防止恶意validators组成联盟，通过伪造transaction batch或validator set update从Gravity bridge中窃取，Gravity会Slash签名出现在（这些从未在链上生成的）batches和validator set updates中的validator。这是通过evidence机制实现的，任何人都可以在伪造的batch或valset上提交evidence of a signature，该链将slash相应的validator。
参考资料
[1] How Gravity works
[2] About Staking on Osmosis
以上是关于Gravity bridge——IBC Bridge to Ethereum的主要内容，如果未能解决你的问题，请参考以下文章