1. 引言

NEAR系列博客有：

NEAR协议简介
NEAR共识机制
NEAR light client
Aurora与NEAR的关系
NEAR的storage staking

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

相关代码实现见：

https://github.com/aurora-is-near/rainbow-bridge（Solidity & Go & Java & Rust）【Rainbow Bridge核心层】
https://github.com/aurora-is-near/aurora-relayer【Relayer】
https://github.com/Shard-Labs/rainbow-non-fungible-token-connector【目前未被NEAR官方认可的NFT Connector】
https://github.com/aurora-is-near/rainbow-token-connector【ERC-20/NEP-141 Token Connector】
https://github.com/aurora-is-near/near-erc20-connector【$NEAR Connector】
https://github.com/aurora-is-near/eth-connector【$ETH Connector】
https://github.com/near/rainbow-bridge-sol【早期原型】

Bridge跨链方案，可支持利用 A链的性能 + B链的社区和生态。

Rainbow bridge在NEAR链上实现了一个以太坊light client，可在NEAR链上验证以太坊区块头。EthOnNear client使用DAGs which are precomputed to make the computation of Ethash (a space hard hashing algorithm) viable on-chain on NEAR。
假设25个区块确认之后的以太坊区块即已固化。
以太坊区块头和NEAR区块头可get relayed by any actor and rejected if invalid according to the previous headers and proofs。
由于以太坊目前暂未支持Ed25519预编译合约，目前需要采用bond模型，设置有4小时的挑战窗口期。为了避免在以太坊链上验证the costly Ed25519签名，Rainbow采用Optimistic fraud proofs。Relayers必须在其header proposal中bond一些ETH（当前设置为5 ETH），在challenge期间，若某actor提交了一个有效的proof，则一半会burnt，另一半归该actor所有。当challenge有效期过后，则认为相应的ed25519 signature是有效的。注意，只要EIP-665实现，在以太坊上支持Ed25519预编译，则不再需要这种Optimistic fraud proofs。
在NEAR链上，仅存储7天的以太坊区块头（以防止unbounded state growth）。用户必须在7天内完成其由以太坊到NEAR的交易，否则可能会丢失资产。
EthOnNear client将在4年后过期，因为到时将reach the end of precomputed DAGs。

以太坊端：

NearBridge合约：作为以太坊端的NEAR light client，relayers每4小时向其提交NEAR区块头。
NearProver合约
EthCustodian合约【$ETH Connector】
Erc20Locker合约【ERC-20 Connector】
eNear合约【$NEAR Connector】

NEAR端：

relayer.bridge.near 账号【主链relayer.bridge.near账号add_block_header交易】
client.bridge.near合约【主链EthOnNear light client合约】
event-relayer.near 账号【主链event-relayer.near账号deposit交易】
factory.bridge.near合约
prover.bridge.near合约
e-near.near合约【主链ERC20 Connector合约】

根据https://etherscan.io/tx/0x13efcf3d0f84cf0027081e516a628d50833aebcb0a002f6f87def6f2e09bd924 可知，对于NEAR->以太坊的转移，向以太坊提交proof event的为用户本人，而不是relayers。
根据NEAR主链finalise_eth_to_near_transfer 交易可知，由Ethereum->NEAR端的交易，由专门的event-relayer负责向NEAR端提交。

Rainbow Bridge总体架构为：

为了信任Rainbow Bridge，需：

1）对以太坊的信任：信任 X X X个确认之后的以太坊区块是固化的。当前，Rainbow Bridge中为app 开发者确定了 X X X的值，未来，app开发者将可自己定义 X X X的值。app开发者可将 X X X定义为经典的 25 25 25，也可超级慎重地将其定义为 500 500 500。
2）对NEAR链的信任：信任无论何时，NEAR链上2/3的validators stake都是honest的。这不仅对Rainbow Bridge本身成立，对NEAR链上的所有其它应用也遵循该假设。
3）对以太坊最低gas费增长的信任：除非 EIP665 被接受，否则，可一直信任以太坊最低gas费不可能以每个区块增加2x倍的速度持续超过4个小时。假设基础gasfeud为40gwei和14bps，可计算出每个区块gas费以2倍速度快速增长4小时的gas费。

由于Rainbow Bridge用户除了信任链本身之外，无需信任任何其它东西，因此可称Rainbow Bridge为trustless的。这种trustless存在延迟：

1）对于ETH->NEAR交互，延迟量取决于生成 X X X个以太坊区块的速度，通常为25个区块（约6分钟）；
2）对于NEAR->ETH交互，延迟为4小时，一旦以太坊接受了EIP665，将缩短为约14秒。

与其他一些需要7天waiting time的扩容方案相比，Rainbow Bridge可认为是rapid的。当前Rainbow Bridge的速度仅受限于缺少EIP665 和以太坊区块的确认数，任何基于以太坊的项目都有相同的限制。

Rainbow Bridge为去中心化的，无需经过其他人（甚至是NEAR基金会）的同意，任何人都可：

部署一个新的Rainbow Bridge
使用一个现有的Rainbow Bridge
参与维护现有的Rainbow Bridge

Rainbow Bridge为generic的，任何NEAR链上可cryptographically provable的信息可用于以太坊合约中，反之亦然。两条链上的可cryptographically provable信息有：

Inclusion of a transaction in a block
Execution of a transaction with a specific result
The state of the contract
blockchain-specific信息，如特定区块头的信息。对于以太坊来说，区块头中包含了miner的信息；对于NEAR来说，区块头中包含了validators信息。

这些cryptographically-provable信息可用于多种场景：

bridge fungible tokens, non-fungible tokens，或任何资产类型。
write Ethereum contracts that use the state of a contract or validator from NEAR。
do cross-contract calls across the bridge。

尽管有以上应用场景，目前Rainbow Bridge仅用于支持以太坊和NEAR之间的ERC20 token转移。

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 X X个DAI由以太坊转移到NEAR时：

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

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

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

6. Rainbow Bridge使用流程

用户可通过RainbowCLI，或任何集成了RainbowLib的app（如NEAR wallet），也可以直接调用相应的合约来使用Rainbow Bridge。

假设以太坊上的Alice想要给NEAR链上的Bob转移 X X X个DAI，Alice会从RainbowCLI/RainbowLib中发起该transfer，基本流程为：

1）RainbowLib首先设置an allownace to transfer X X 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 X 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开发者来说，整个升级过程是透明的。

8. Rainbow Bridge中激励模型

当前Rainbow Bridge并未对支付gas费进行header relay的维护者进行激励。

目前，Rainbow Bridge由NEAR基金会维护。目前正在设计激励措施给那些维护bridge relay header支付gas费的relayer。

目前，维护Rainbow bridge的费用为每天约2 ETH，主要在于向以太坊relay NEAR 区块头，在NEAR端的开销可忽略不计。

约每4小时向以太坊relay一个NEAR区块头，相应的gas费约为0.15 ETH，具体可参见addLightClientBlock：

https://etherscan.io/tx/0x3b243c271312ca22937f3f9725c61cbf8db4f45230b3c478aeaa2b4eb936311e

参考资料

[1] ETH-NEAR Rainbow Bridge
[2] NEAR链共识机制
[3] 彩虹桥：连接以太坊和NEAR的桥梁
[4] The Rainbow Bridge: FAQs and Answers
[5] NEAR bridge官网

Rainbow Bridge：trustless bridge between NEAR and Ethereum相关推荐

Optics Bridge：Celo ＜-＞以太坊
1. 引言目前,Celo生态已上线的跨链方案主要有3种: 1)Optics Bridge:当前支持 cleo.以太坊.Polygon三者之间跨链.即将支持Avalanche. 2)AllBridge ...
adobe bridge cs6怎么卸载_adobe bridge cs6 64_adobe bridge cs6安装_adobe bridge可以删吗
Adobe® Bridge CS6 数字资产管理软件是功能强大的照片和设计管理工具,能够集中访问您的所有创意资产.借助 Adobe InDesign®.Photoshop® 和 Photoshop E ...
Chrome游戏：Cargo Bridge（桥梁工程师）
查看原文:http://www.hellonet8.com/462.html 在Chrome的应用里面,想要找到好玩的游戏真的不容易,有的小游戏也许画面不够出色而被玩家忽视,也许有的小游戏名字取的毫无 ...
趣谈设计模式 | 桥接模式(Bridge)：将抽象与实现分离
文章目录案例:跨平台应用开发桥接模式总结完整代码与文档案例:跨平台应用开发 A公司最近准备开发一组应用合集,目前包括了视频播放器.音乐播放器.文本播放器三种应用,但是在发售前,他们遇到了困难 ...
interlay： IBC bridge BTC to Cosmos
1. 引言目前interlay团队已实现了在波卡上引入BTC. interlay团队分别在波卡和Kusama上运行了相应的平行链. 基本流程为: 往interlay指定的地址存入BTC -> ...
bridge cc2021|adobe bridge cc 2021中文直装版（文件资源管理器） v11.0.0.83
adobe bridge cc 2021是adobe公司最新发布的一款功能强大的文件资源管理器,由于该软件可以很好的帮助用户管理电脑文件,因此受到了极大的欢迎,使用它可以帮助用户让电脑里面的文件排列井 ...
linux bridge 添加fdb,bridge fdb 与vxlan
10.10.18.214节点上 2: eth0@if6: mtu 1500 qdisc noqueue state UP group default qlen 1000link/ether 96:43 ...
如何扩大以太坊的规模：分片简介(How to Scale Ethereum: Sharding Explained)
2019独角兽企业重金招聘Python工程师标准>>> 分片是提高区块链效率的一个主要流派.下面简单通俗的解释一下分片算法. 以太猫(Cryptokitties)堵塞了以太坊网络好几 ...
NEAR 智能合约开发
1. 引言 NEAR系列博客有: NEAR协议简介 NEAR共识机制 NEAR light client Aurora与NEAR的关系 NEAR的storage staking Rainbow Bri ...

Rainbow Bridge：trustless bridge between NEAR and Ethereum