彩虹桥：连接以太坊和NEAR的桥梁

区块链项目和相应的扩容方案层出不穷，普通人在开发产品的过程中很难判断哪种方案更适合自己。特别是当其中涉及绑定资产或数据的时候，这一点会表现的十分明显。理想情况下，我们并不想绑定这些信息。我们想在不同链之间自由地转移资产和数据，或更进一步——在几个链上同时运行我们的产品并对每个链加以利用。比如，我们可以利用一条链的性能，同时利用另一条链的社区和生态。
在NEAR的平台上，我们不想让以太坊开发者们在NEAR和以太坊之间做选择，也不想让他们只绑定一条链。我们想让他们在两条链上拥有相同的资产，甚至想让他们拥有可以实现无缝跨链通信的应用。所以我们开发了一种类似桥的工具，也就是我们所说的彩虹桥，以此来连接以太坊和NEAR。而且我们还针对互操作性解决方案创建了尽可能低的信任等级，用户只需要信任彩虹桥连接的对象，即NEAR和以太坊，而无需信任彩虹桥本身。除了以太坊矿工和NEAR验证节点之外，任何人或实体都没有权力。
具体来说，信任彩虹桥需要用户需要做到以下几点：
· 相信在经历过X次确认之后，以太坊区块的最终性。当前版本的彩虹桥为应用开发者决定X的代表数字，不过开发者很快就能自行决定这一数字了。如果您是一名典型的应用开发者，该数字可能是25；如果您做事十分谨慎，则该数字就有可能是500。
· 相信无论在什么时候，NEAR链上三分之二的验证节点质押都是诚实的。不仅是彩虹桥，还有所有其他NEAR上的应用都会在这一假设下运行。
· 直到EIP665被接受为止，您需要相信：每个区块的gas费以超过2倍的速率呈指数增长，且这样的状态持续4个多小时这样的事，是不可能发生的。假设gas费的基础价格为40gwei和14bps，您可以轻易地计算出将gas费提升两倍的企图会迅速突破它的合理界限，整个过程远用不了4个小时。我们会在下文中向您解释这样的限制出自何处。
因为彩虹桥只需要用户信任区块链本身，所以我们将其称之为无需信任的。
这种无需信任的模型导致了因为跨桥互动而产生的延迟，下面是具体的延迟数字：
· 对于ETH至NEAR的互动，延迟时间相当于生产X枚以太坊区块所需的时间。生产25个以太坊区块大约需要6分钟。
· 对于NEAR至ETH的互动，延迟时间为4小时；EIP665被接受后，该时间会骤然缩短至14秒左右。
注意只要EIP665被接受，延迟时间就会大大缩短。鉴于很多扩容方案在实现互操作性上需要高达7天的等待时长，我们认为NEAR的彩虹桥技术是比较快速的。目前该技术的速度仅仅因为EIP665的缺席以及以太坊区块的确认次数（任何基于以太坊的项目均受到该因素的限制）而受到限制。
随着我们的进一步发展，我们的彩虹桥技术在部署、维护或使用的过程中不需要特别许可。任何人都可以部署一个新的彩虹桥，使用现有的彩虹桥或者和别人一起对现有的彩虹桥实施维护，这些操作都是不需要任何机构和个人批准的，包括让我们的彩虹桥实现去中心化的NEAR基金会。
而且彩虹桥技术还是通用的。任何可以在NEAR平台以加密方法证明的信息在以太坊合约都是可用的，反之亦然。以下信息对NEAR和以太坊来说都是可以使用加密方法证明的：
· 在区块中收录一笔交易
· 执行一笔交易并有一个具体的结果
· 合约状态
此外，区块链相关的信息都是可证明的，比如某一区块头（header）的内容。以太坊区块头包括矿工信息，NEAR区块头则包括验证节点信息。这种通过加密证明的信息允许我们构建各种用例：
· 我们可以桥接同质化通证、非同质化通证或任何一种资产
· 我们可以编写使用合约状态或NEAR验证节点的以太坊合约
· 我们可以使用彩虹桥做跨合约调用
尽管用例的种类看起来是无限的，我们目前只提供从以太坊至NEAR或者从NEAR至以太坊转账ERC-20通证的开箱即用支持。然而，我们也会基于需求为其他用例提供这种支持。此外，任何人都可以投入进来，为他们的私人用例增加支持，而无需等我们或者与我们的代码库合作。
为了理解为何这一特点和其他我们在上文中列举的特点站得住脚，我们需要理解彩虹桥的设计。
设计
Anton Bukov在NEAR工作期间，承担了彩虹桥的主要设计工作。虽然他现在已经是1inch交易所的CTO，但仍然指导着彩虹桥技术的高层设计工作。
该技术背后的核心理念是执行两个轻型客户端：
一个用Rust语言执行的以太坊轻型客户端，作为一个NEAR合约
一个用Solidity语言执行的NEAR轻型客户端，作为一个以太坊合约
如果您对轻型客户端的概念很熟悉，这一简短的概要已经解释了上述关于桥的保证。简单来说，区块链轻型客户端是一种规范或是这种规范的实现。客户端可对区块链状态进行追踪，同时无需运行大量计算，而且该客户端还可以以一种无需信任的方式对其追踪的状态进行验证。我们在这里想表达的重点是能够以少量计算的代价追踪和验证状态。
我们意识到计算量可能很小，小到可以在合约内运行一个轻型客户端。这是让彩虹桥方案可行的关键。
轻型客户端

以下是使用彩虹桥技术运行的轻型客户端简图。

请注意，除了执行轻型客户端的智能合约外，我们还有两项叫做转播（relay）的服务，该服务会定期将区块头发送至轻型客户端。Eth2NearRelay将每个单一区块头发送至EthOnNearClient合约，同时Near2EthRelay每隔四个小时就会将一个区块头发送至NearOnEthClient合约。每一对EthOnNearClient和NearOnEthClient合约，都可能会有若干对Eth2NearRelay和Near2EthRelay服务。每个彩虹桥维护者可以运行一对服务。这些服务可能和彼此竞争——他们会试图同时提交同样的区块，每次只会有一对服务成功。他们也会为彼此提供支持——一些服务只会在其他服务对没有按时提交区块的情况下提交区块。我们目前的服务执行以第一种模式运行。
EthOnNearClient
正如我们之前说过的那样，EthOnNearClient是采用Rust语言编写的以太坊轻型客户端的一种执行，也是一个NEAR合约。它接受以太坊区块头并对正统链（canonical chain）进行维护。它假设拥有finalized_gc_threshold次确认的区块不能离开正统链，它会记住正统链的hashes_gc_threshold个区块。在该正统链上，hashes_gc_threshold>=finalized_gc_threshold。默认状态下，finalized_gc_threshold=46,000，这与累积7天的区块头数量大致吻合。这样做可以保证EthOnNearClient的状态不会无限制地增长。请记住在NEAR平台，用户需要有一定量的被锁定的通证才能使用状态(更多信息)，如果我们对单一合约内的每一个以太坊正统区块头进行存储，使用状态就需要大量的且处于不断增长状态的锁定通证。因此，我们只会存储一定量的以太坊区块头的哈希值。所以彩虹桥只能被用来证明在这一时间范围内发生的活动。所以如果您在进行ERC20通证转账（以太坊至NEAR）时，进程发生了中断，请确保在7天之内完成转账流程。
有关EthOnNearClient另外一个重要的差异是它验证以太坊区块头的方式。直接在合约内部验证以太坊PoW是不可以的，因为这么做需要存储以太坊的DAG文件，而这一操作会占用大量内存，价格不菲。幸运的是，每个以太坊区块都仅仅使用DAG文件元素的一个子集，且每个以太坊周期都只有一个DAG文件。此外，DAG文件可以提前进行预计算，以备未来的周期使用。我们会提前4年对DAG文件进行预计算并将每个文件进行默克尔化（merelize）。初始化之后，EthOnNearClient合约会在未来四年记住DAG文件的默克尔根。之后，EthOnNearClient仅需要收到以太坊区块头、DAG元素和这些元素的默克尔证明，这将允许它无需拥有内存中的全部DAG文件就可以对PoW进行验证。我们借用的是文章《Kyber网络使用的EOS桥技术》中的方法，而且我们甚至可以复用他们的一些代码。幸运的是，以太坊区块头的验证工作仅使用交易gas费上限的三分之一和区块gas费上限的十分之一。
NearOnEthClient
NearOnEthClient采用Solidity语言编写，是NEAR轻型客户端的一种实现，也是一个以太坊合约。和EthOnNearClient不同的是，它并不需要对每个单一的NEAR区块头进行验证，且可以跳过大多数区块头，前提是它验证了每个周期中的至少一个区块头。每个周期大概有43,000个区块，大概持续半天时间。最终，NearOnEthClient可以记住历史上所有已提交的NEAR区块头的哈希值。如果您正在进行由NEAR至以太坊的转账并且该过程被中断了，对此您无需担心，您可以在任何时候恢复这一进程，即使是几个月之后也可以。 NEAR轻型客户端另一个有用的特点是，每一个NEAR区块头包含一个默克尔树根，该默克尔树根是从该区块头前面的区块头计算得来的。如果您有一个NEAR区块头，您可以高效地验证任何发生在该区块头前面的区块头中的任一事件。
NEAR轻型客户端另一个有用的特点是该客户端只接受最终区块，而在NEAR平台，最终区块不能离开正统链。这就意味着，NearOnEthClient无需担心分叉。
然而，不幸的是，NEAR 使用 Ed25519对负责审批区块的验证节点的消息进行签名，而该签名不会以EVM预编译的形式可用。这就使得对NEAR单一区块头的全部签名进行验证变得十分昂贵。所以技术上看，我们不能只通过对NearOnEthClient进行一次合约调用就完成NEAR区块头的验证工作。因此，我们采用了 optimistic approach。按照该方法，NearOnEthClient会对区块头中除签名之外的全部信息进行验证。之后，任何人都可以在一个已提交的区块头中对签名提出质疑，质疑窗口为4小时。质疑需要对单一的Ed25519签名进行验证，这项工作将花费大约500,000的以太坊gas费（很昂贵，但是是可以做到的）。提交NEAR区块头的用户需要使用以太坊通证发布一个债券，一个成功的质疑将消耗一半的债券通证，剩下的一半会归还给质疑者。即使gas费在这4个小时期间呈指数增长，债券规模也必须足够支付gas费。比如，一个价值20枚以太坊的债券能够承担的gas费为20,000Gwei。这一optimistic approach需要有一个监督(watchdog)服务，负责对已提交的NEAR区块头进行监督，并对任何包含无效签名的区块头提出质疑。为了获得更多的安全性，独立用户可以运行若干个监督服务。
一旦EIP665被接受，以太坊将拥有Ed25519签名，可作为EVM预编译使用。这将让监督服务和4小时的质疑窗口变得不再必要。
彩虹桥最少会包含EthOnNearClient和NearOnEthClient合约以及3项服务：Eth2NearRelay、Near2EthRelay和Watchdog。我们可能会认为这已经是一个桥工具了，因为我们在两条链之间建立了一个加密链接。但是若要使用这种模式的桥，应用开发者们可能需要额外编写大量代码，这显然是不实际的。
证明工具（Provers）
能够证明某一事件在某条链上发生过会让客户端变得更有用。为此，我们用Rust语言执行NEAR合约——EthOnNearProver，并用Solidity语言执行以太坊合约——NearOnEthProver。 EthOnNearProver可以验证以太坊事件，NearOnEthProver合约可以验证NEAR合约执行结果。EthOnNearProver和NearOnEthProver的实现，与EthOnNearClient和NearOnEthClient的实现是分开的，理由如下：
· 关注分离（Separation of concerns ）：客户端负责追踪最新的区块头，证明工具则负责验证具体的加密信息
· 可拓展性（Scalability）——因为NEAR是一条分片链，如果桥的某一实例变得非常流行，用户可以通过部署某一证明工具的多个副本来提升负载能力
· 特异性（Specificity）——除了上文描述的证明工具，用户还可以执行其他种类的证明工具。用户可以验证合约状态区块头的具体内容，或是交易的收录情况。此外，证明工具的不同实现方式可能会使用不同的优化方法。
目前，我们仅提供了验证以太坊事件（events）和NEAR合约执行结果的实现，这对在不同链之间转移通证来说已经足够了。不过我们仍然欢迎大家为证明工具执行贡献自己的力量。

说明：对一个EthOnNearClient而言，可能有多个证明工具与其沟通并将信息复制到多个分片上；对一个NearOnEthClient而言，只有每类证明工具的一个与其沟通。
ERC20用例
使用证明工具可以帮助我们开发一套具备资产转账或跨链通信功能的合约。然而，由于我们想要通过彩虹桥实现互操作的对象的不同，这些合约也大不相同。比如，ERC20要求一套完全独立于ERC721或原生通证转账的合约。目前，彩虹桥为通用的ERC20通证转账提供了开箱即用支持，未来我们会增加更多的用例。在本篇博客中，我们仅关注ERC20用例。
假设以太坊有一套ERC20通证，比如说稳定币DAI。我们要想通过彩虹桥转移这类通证，就需要部署2套额外的合约：
使用Solidity语言执行的以太坊合约——通证锁定器
使用Rust语言执行的NEAR合约——可铸造的同质化通证（Mintable Fungible Token）
某用户想从以太坊转移X枚DAI至NEAR，他们首先会在通证锁定器合约锁定X枚DAI，然后在NEAR合约可铸造的同质化通证铸造X枚nearDAI。如果他们想从NEAR转移一些通证至以太坊，他们首先会在可铸造的同质化通证销毁Y枚nearDAI，然后在通证锁定器解锁Y枚DAI。
目前，ERC20通证的每个实例都要求部署一对独立的通证锁定器/可铸造的同质化通证。不过，我们未来会解除这一限制，为多种ERC20通证使用同样的通证锁定器。需要注意的是，如果某人想要增加ERC721的支持或另外一种资产转账，他们需要执行类似的锁定器/资产对，且有一个不同的外部界面和内部实现，不过高层（high-level）设计将维持原状——锁定器会锁定/解锁资产，Asset会铸造/销毁NEAR版的这一资产。
Usage flow
用户未来将能够使用RainbowCLI或任意一种集成RainbowLib的应用，如NEAR钱包。在极少数情况下，用户可能会选择以手动方式与彩虹桥互动，即使用低级别（low-level）的合约调用指令，从他们的shell调用以太坊和NEAR合约。目前，我们仅支持RainbowCLI，不过我们也在筹备RainbowLib和钱包集成。
从用户角度看，通证转账应该直白易懂：他们提供凭证，选择受益人和数量，通过RainbowCLI、钱包或其他应用启动转账。一段时间后，转账成功，用户收到可视的验证信息。然而，转账成功的背后，RainbowLib会执行下列复杂的操作：
1. 假设Alice想给Bob在NEAR链上转账X枚DAI，她使用RainbowCLI/RainbowLib启动了转账流程
2. RainbowLib首先会为由Alice至通证锁定器的转账设置一笔费用
3. 之后RainbowLib会调用通证锁定器，捕获那些导致通证锁定器释放“Alice为Bob锁定X枚通证”事件的通证
4. 然后，RainbowLib会等待一段时间，直到EthOnNearClient收到包含上述事件的以太坊区块头，以及25个区块来确认（具体可参见开篇一章中有关以太坊最终性的注释）
5. 然后，RainbowLib会计算这一事件的证据，并将其提交给可铸造的同质化通证合约
6. 可铸造的同质化通证合约会调用EthOnNearProver来验证这一证据是正确的
· EthOnNearProver验证该证据的区块头位于EthOnNearClient的正统链上，且该工具拥有规定数量的验证次数。该工具也会对证据本身进行验证；
· 可铸造的同质化通证拆解这一以太坊事件，并为Bob铸造X 枚nearDAI，转账至此结束。

类似地，RainbowLib将能够执行ERC20之外的通证转账及合约调用等任务。
硬分叉
我们希望NEAR或以太坊协议发生变化时，现有的彩虹桥不会崩溃。我们也希望当重要的性能升级可用的时候（如EIP665被接受），我们能够对彩虹桥合约进行升级。然而，我们不想以中心化的方式启动升级，从而削弱其无需信任或去中心化的程度。
目前以太坊社区已开发出很多种允许合约升级的代理模式。不过，我们认为最安全的升级模式应该是将升级决策委托给用户。与这一用户控制的彩虹桥升级模式类似的方法应满足以下条件：
假设用户正在使用彩虹桥在以太坊和NEAR之间转账。他们有X枚DAI锁在通证锁定器（TokenLocker），有X枚nearDAI在NEAR这一端可用；
假设有一天他们收到一份声明，该声明称NEAR或以太坊正在进行协议变更，他们需要在一周之内转移至V2版本的彩虹桥
他们使用旧有的桥工具将nearDAI重新转回至DAI，然后使用V2版本的彩虹桥将DAI转移至 V2版本的nearDAI
不过这一方法存在一定缺陷：
· 和普通的合约不同，该桥是一套更复杂的且需要维护的系统——某些人需要持续地运行转播服务，否则轻型客户端就要和区块链失去同步，变得毫无用处。这就意味着，我们不能要求用户在他们方便的时候以手动方式从V1版本的彩虹桥转移至V2版本的彩虹桥。如果我们在全部用户将资产转出之前关闭V1版本彩虹桥的转播服务，他们的资产可能会永远处于锁定状态，且无法转移至V2版本的彩虹桥。如果我们运行中继的时间过长，并等到所有人都完成转移，我们每天都会在费用上消耗gas，每天大概会花费40美元（40gwei）。
· 集成彩虹桥的应用需要对彩虹桥迁移这一情况有所了解，因为它们需要从旧的可铸造的同质化通证合约切换至新的可铸造的同质化通证合约。他们中的某些成员需要自行完成这一任务，或通过UI指导他们的用户完成这一任务。
鉴于上述缺陷，我们已决定为彩虹桥技术集成下面的可升级性选项。我们会使用代理模式的一种来允许EthOnNearClient, EthOnNearProver，NearOnEthClient和NearOnEthProver收到能够证明三分之二的NEAR质押已经投票通过新一套的合约版本的证据后，自动切换至新的合约版本。大多数情况下，通证锁定器和可铸造的同质化通证不用做出改变，因此该升级对用户和应用开发者是透明的。因为无论如何我们都需要相信三分之二的NEAR质押，所以这不会影响彩虹桥的信任模型。我们会使用和其他的NEAR平台上治理机制同样的投票合约。我们也会尽量减少该机制被用作后门（backdoor）的几率。为此，我们会制造7天的升级延迟，用户可以在此期间对其进行观察、验证。如果他们不喜欢它，可以清算他们的通证或将通证手动转移至不同的桥。然而，我们会为NEAR验证节点预留权限，让他们可以对某一紧急升级活动进行投票，不过我们并不希望他们有一天会用到这一权限。
激励措施
当下的彩虹桥并不为转播区块头支付gas费的维护人员执行激励。彩虹桥的主要用户需要运行他们自己的转播服务，至少有一对转播服务会由NEAR团队运行。彩虹桥的未来版本会提供向用户收费的选项，执行转账的用户需要以gas、原生通证或其他方式支付使用费。然而，设计一套可靠的激励机制是很复杂的。最简单的方法是向彩虹桥用户征税，并将其分发给提供转播服务的维护者们。不幸的是，这样的系统并不能阻止死亡螺旋的情况，即彩虹桥可能会发生故障，导致用户在一段时间内停用该服务，并最终导致维护者对支付gas费失去兴趣。我们的组织正循序渐进地开发一套完善的彩虹桥激励机制。与此同时，我们会对其进行维护并自行垫付相应的成本。