开发: C++知识库 Java知识库 JavaScript Python PHP知识库人工智能区块链大数据移动开发嵌入式开发工具数据结构与算法开发测试游戏开发网络协议系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程
数码: 电脑笔记本显卡显示器固态硬盘硬盘耳机手机 iphone vivo oppo 小米华为单反装机图拉丁

-> 区块链 -> Rainbow Bridge：trustless bridge between NEAR and Ethereum -> 正文阅读

[区块链]Rainbow Bridge：trustless bridge between NEAR and Ethereum

1. 引言

NEAR团队开发的Rainbow Bridge，无需信任bridge本身，仅需要信任所连接的NEAR链和以太坊链。除了以太坊链的矿工和NEAR链的validators，无任何authority。

2. Rainbow Bridge的设计理念

Rainbow Bridge的核心思想为其事项了2个light clients：

1）在NEAR链上，以Rust语言实现了一个以太坊light client作为NEAR合约。
2）在以太坊上，以Solidity语言实现了一个NEAR light client作为以太坊合约。

light client的关键在于可track and verify the state with a small amount of computation。light client所需的计算量需足够小，以支持在合约中运行。

以太坊light client所需的资源更多，因为其需要跟踪每个区块头，并仅需Ethash验证。
NEAR light client所需的资源更少，其仅需要跟踪一个epoch中的一个区块，NEAR 每个epoch有将近43k个区块。（NEAR产块速度快与以太坊，若要跟踪每个NEAR区块，所需的gas费将非常高。）
NEAR链上的gas费便宜，因此可在NEAR链上运行相对更expensive的以太坊light client合约，而在以太坊上运行相对便宜的NEAR light client。

详细的NEAR light client设计可参看：NEAR Light Client

3. Rainbow Bridge中的Light clients

Rainbow Bridge上的light client流程为：
在这里插入图片描述
Rainbow Bridge中除了2个实现light client的智能合约之外，还有2个名为relayer的service，负责定期将区块头发送到light client合约：

1）Eth2NearRelay 会将每个以太坊区块头发送到EthOnNearClient合约；
2）Near2EthRealy 会每4小时将一个NEAR区块头发送到NearOnEthClient合约。

对于一组 EthOnNearClient/NearOnEthClient 合约，可存在多组 Eth2NearRelay/Near2EthRealy 服务。每个Rainbow Bridge 维护者都可运行一组Eth2NearRelay/Near2EthRealy 服务。这些服务可相互竞争，如：

1）同时提交相同的区块头，每次仅有一个是成功的。【目前Rainbow Bridge采用的是这种模式。】
2）相互进行备份，如某服务未及时提交区块头，其它服务可代为提交。

3.1 NEAR链上的EthOnNearClient合约

EthOnNearClient 为在NEAR链上以Rust语言实现的以太坊light client。其会接收以太坊区块头，并维护the canonical chain，其假设某区块一旦有finalized_gc_threshold个确认之后，就不会leave the canonical chain，并memorizes up to hashes_gc_threshold of the blocks from the canonical chain，其中hashes_gc_threshold>=finalized_gc_threshold。
默认hashes_gc_threshold=46k，约为7天的区块头。这种设计可保证EthOnNearClient上的合约状态不会无休止地增长。

在NEAR链上，要求合约owner锁定一定的数量的token来使用state，具体见NEAR Storage staking。若将每个以太坊区块头都存储在EthOnNearClient中，将需要大量持续增加的locked tokens。因此，在EthOnNearClient中仅存储有限数量的hashes of Ethereum headers。造成的影响为，Rainbow bridge仅可用于证明在该time horizon期间发生的events。即，你若通过以太坊向NEAR转移ERC20 token，若在转移过程中有中断，请确保在7天内完成所有操作。

EthOnNearClient另一个重要特征在于如何验证以太坊区块头：

无法直接在合约中验证以太坊PoW，因为这将要求存储以太坊DAG file，从而将需要极其昂贵的memory usage。幸运滴是，每个以太坊区块仅使用a subset of the elements from the DAG file，且在每个Ethereum epoch中仅有一个DAG file。此外，未来epoch的DAG file可提前计算。可提交计算出4年的DAG files然后merkelize each of them。EthOnNearClient合约在初始化时，会memorize the merkle roots of the DAG files for the next 4 years。然后，EthOnNearClient仅需要接收以太坊区块头、the DAG elements、the merkle proofs of these elements。从而可verify PoW without having the entire DAG file in memory。

Rainbow Bridge借鉴并复用了 Kyber network的EOS Bridge 中的部分代码。以太坊区块头的验证仅需要1/3 of the max transaction gas limit and 1/10 of the block gas limit。

3.2 以太坊上的NearOnEthClient合约

NearOnEthClient 为在以太坊上以Solidity语言实现的NEAR light client。

不同于EthOnNearClient，NearOnEthClient无需验证每个NEAR区块头，可以跳过大多数的区块头，仅需要在每个NEAR epoch中验证至少一个区块头。NEAR每个epoch对应有43k个区块，大约为半天。

因此，NearOnEthClient可memorize hashes of all submitted NEAR headers in history。因此，当你由NEAR向以太坊转移资产过程中若有终端，可不必担心，可在任何时候恢复，即使是数月之后也可以。

NEAR light client中具有如下有用的属性：

1）在每个NEAR区块头中，包含了a root of the merkle tree computed from all headers before it。因此，有某一NEAR区块头，可efficiently verify any event that happened in any header before it。
2）仅接收固化块，固化块不会leave the canonical chain in NEAR。即在NEAR light client中无需担心分叉。

但是，NEAR中的validators采用Ed25519来进行消息签名，Ed25519目前在EVM预编译合约中不支持，使得在以太坊合约中验证区块头中所有签名的费用很高。技术上来说，无法verify one NEAR header within one contract call to NearOnEthClient。因此，Rainbow Bridge中采用Optimistic Contracts方案，即NearOnEthClient验证NEAR区块头中除签名之外的所有内容。然后，任何人可challenge a signature in a submitted header within a 4-hour challenge window。该challenge中验证一个Ed25519签名需要约500k gas费（尽管很贵，但可能可以实现）。向NearOnEthClient提交NEAR区块头的用户需post a bond in Ethereum tokens，一旦challenge成功了，将burn half of the bond and return the other half to the challenger。bond的数额因足够大，足以覆盖即使指数增长持续4小时后的gas费。如，20 ETH bond将覆盖20000Gwei的gas费。

Optimistic Contracts方案需要由一个watchdog服务来监控提交的NEAR区块头，并challenge any headers with invalid signatures。为了增加安全性，不同的用户可运行不同的watchdog服务。

一旦以太坊接受了EIP665，使得可在EVM预编译中支持Ed25519签名，则不再需要有watchdog服务以及4-hour challenge window。

当前，Rainbow Bridge中至少包含了：

2个合约：EthOnNearClient合约和 NearOnEthClient合约。
3个服务：Eth2NearRelay、Near2EthRelay 以及 Watchdog。

4. Rainbow Bridge中的Provers

为了证明something happened on a specific blockchain：

1）在以太坊上以Solidity语言实现了NearOnEthProver合约：可验证NEAR contract execution results。
2）在NEAR链上以Rust语言实现了EthOnNearProver合约：可验证以太坊events

在EthOnNearClient/NearOnEthClient 之外单独实现 NearOnEthProver/EthOnNearProver 合约，主要基于以下考虑：

1）关注点不同：client合约负责跟踪最新的区块头，而provers合约负责验证特定的cryptographic information。
2）扩展性：NEAR为sharded blockchain，若a certain instance of the bridge becomes extremely popular，users可scale the load by deploying multiple copies of a given prover。
3）特异性：可实现多种类型的provers，分别用于验证a contract’s state、the specific content of a header、inclusion of a transaction。此外，不同的provers可采用不同的优化策略。

当前，Rainbow Bridge中仅验证Ethereum events和NEAR contract execution results，就足以moving tokens between NEAR and Ethereum。
在这里插入图片描述

5. ERC20用例

基于Rainbow Bridge的provers，可构建支持asset transfer或cross-chain communication的一系列合约。但是，基于不同的场景，具体的实现会有所不同。如，ERC20需要an entirely separate set of contracts from ERC721 or native token transfer。

当前Rainbow Bridge支持开箱即用的generic ERC20 token transfer。

以以太坊上的ERC20 token DAI为例，通过Rainbow bridge进行转移，需要额外部署2个合约：

1）在以太坊上以Solidity原因实现的TokenLocker合约。
2）在NEAR链上以Rust语言实现的MintableFungibleToken合约。

当用户想要将 $X$ 个DAI由以太坊转移到NEAR时：

1）用户将 $X$ 个DAI锁定在TokenLocker合约中。
2）在MintableFungibleToken合约中mint $X$ 个nearDAI。

当用户想要将 $Y$ 个nearDAI由NEAR转移到以太坊时：

1）在MintableFungibleToken合约burn $Y$ 个nearDAI。
2）在TokenLocker合约中unlock $Y$ 个DAI。

6. Rainbow Bridge使用流程

用户可通过RainbowCLI，或任何集成了RainbowLib的app（如NEAR wallet），也可以直接调用相应的合约来使用Rainbow Bridge。
在这里插入图片描述
假设以太坊上的Alice想要给NEAR链上的Bob转移 $X$ 个DAI，Alice会从RainbowCLI/RainbowLib中发起该transfer，基本流程为：

1）RainbowLib首先设置an allownace to transfer $X$ DAI from Alice to TokenLocker；
2）然后调用TokenLocker合约来grab those tokens resulting in TokenLocker emitting event “Alice locked X tokens in favor of Bob”；
3）RainbowLib会等待EthOnNearClient收到包含该event的区块头之后再加25个确认；
4）RainbowLib为该event计算proof，并将该proof提交到NEAR链上的MintableFungibleToken合约。
5）MintableFungibleToken合约通过调用EthOnNearProver来验证该proof是正确的：
- 5.1）EthOnNearProver：会验证the header of the proof is on the canonical chain of EthOnNearClient，并具有足够的确认数，也会验证proof本身。
- 5.2）MintableFungibleToken合约会unpack the Ethereum event，并mint $X$ nearDAI for Bob。整个transfer结束。

7. Rainbow Bridge如何应对硬分叉

希望Rainbow Bridge不会中断，当遇到如下场景时：

当NEAR或以太坊协议发生了变化。
当EIP665等影响重要性能的升级发生时，如EIP665。

希望在不影响Rainbow Bridge trustless和去中心化特性的情况下，引入一种中心化的升级方案。

以太坊社区中开发了大量的proxy patterns来进行合约升级，但是我们认为，最安全的升级模式是将是否升级的决策交由用户自己来决定。

一种由用户控制的升级方案为：

1）Suppose the user is using the bridge to transfer DAI between Ethereum and NEAR. Suppose they have X DAI locked in TokenLocker and X nearDAI available on the NEAR side;
2）Suppose one day they receive an announcement that NEAR or Ethereum are making a protocol change and they need to migrate to bridge V2 within a week;
3）They transfer nearDAI back to DAI using the old bridge, then transfer DAI into nearDAI V2 using bridge V2.

但是，以上方案存在如下缺陷：

Unlike regular contracts, the bridge is a more complex system that requires maintenance — someone needs to run the relays constantly, otherwise the light clients will go out of sync with the blockchains and become useless. That means we cannot ask users to manually migrate from bridge V1 to bridge V2 at their convenience. If we shut down the relays of the V1 bridge before literally everyone migrates their assets out, their assets might be permanently locked without the ability to move to V2. If we run relays for too long and wait until every user migrates we will be spending gas on the fees daily, approximately 40 USD per day at 40gwei price;
Applications that integrate with our bridge would need to be aware of the migration as they would need to switch from an old MintableFungibleToken contract to a new MintableFungibleToken contract. Some of them might need to perform this migration themselves or guide the user through it with the UI.

为此，我们定的升级策略为：

当收到a proof that 2/3 of NEAR stake has voted for a new set of contracts时，采用proxy pattern模式来升级 EthOnNearClient、EthOnNearProver、NearOnEthClient 以及 NearOnEthProver 合约。大多数情况下，TokenLocker 和 MintableFungibleToken 合约将无需升级，因此对于用户和app开发者来说，整个升级过程是透明的。