IPS:Vitalik：论eth1与eth2的双向桥接_BLS

原作者|?VitalikButerin

本文目的在于阐述在eth1链和eth2链之间建立

双向桥接的一些挑战(例如，支持ETH的双向转换)，以及如何实现。

Eth2提案中已经包含eth1->eth2的

单向桥接，这对能够把Eth1中的ETH抵押到eth2中是必要的。这种单向桥接通过eth1数据投票机制来实现。请注意，

该机制

假设大多数的PoS验证者是诚实的，同时PoW链没有受到攻击（具体来说，就是PoW链中回滚不会超过5个小时)。如果这两个假设中的任一假设失败，那么eth1和eth2这两条链将不再彼此“一致”。其中一开始便存在一条隐式的“社会合约”，即

如果发生任何一种意外都有补救措施，很可能通过PoS链的软分叉来补救；然而也有可能如果PoW链回滚确实超过5个小时，那么社区可能会达成攻击链无效的共识。需要注意的是，不管在哪种情况下，PoS链的故障是不可能需要PoW链进行软分叉的。

而如果我们希望eth1链知道eth2的状态，有两种方法可以实现：

一种是使PoW链接受一个PoS链的轻客户端；

另一种是使PoS终态也敲定PoW链。

第一种方法要求eth1中实现eth2客户端?(见下图)

。这将需要对BLS-12-381验证的webassembly或者原生支持，不要期望这种支持能够很快实现。另外，

这种方法仅提供轻客户端级别的安全性。

第二种方法可以通过添加这一机制来实现，即如果一个经由?eth1_data?投票的PoS区块?

Bs?包含一个指向PoW区块?

Bw?的引用(reference)，

当区块Bs确认后，Bw区块也可视为被确认?(见下图)。不过这意味着PoW矿工(和客户端)也要运行eth2实现版，以便他们知道哪些eth2链被确认。

第二种方法更有趣，因为它为eth1提供了“原生”版回滚限制。请注意，这与第一种方法有所不同，因为虽然它确实使eth1的分叉选择知道eth2，但并没有立即使eth1知道eth2的状态。例如，理论上有可能两条竞争的eth2链确认同一个eth1区块(这意味着eth2已经出故障，但从理论上讲还是有可能出现的)。更常见的情况是eth2链确认的两个区块，其中一个区块是另一个的子区块，而这两个区块都支持相同的eth1区块，从而有些矿工可能知道这两个eth2区块的最近状态，而另一些矿工不知道。这对“eth2作为终态小工具”来说不是问题，但这确实意味着我们需要更多底层设计，使eth1清楚知道eth2的区块状态，以便允许从抵押合约(DepositContract)中提取ETH。

一种可能方案是在eth1中简单地创建一个?eth2_data?投票机制；本质来说，就是复制使eth2知道eth1状态的同一种机制。可将其与上文方案结合起来确保一致性：eth1矿工仅会为?eth2_data?区块进行投票，条件是只有当这些区块满足已确认，以及引用的?eth1_data?区块是矿工正在打包的eth1区块的祖块。

面临的挑战

这两种方法都需要对eth1方面进行改动。目前在eth1->eth2的“最终转换”之前，eth2路线图对eth1方面没有改动。而如果eth2中断，这两种方法都需要eth1采取紧急补救措施。

第二种方法将要求所有eth1矿工也要运行eth2节点。因此，

尽管这两个中方法都是绝对可行的，但并不会很快实现。但是，随着eth2持续运行并证明其稳健性，那么

肯定会到一个实现这种双向桥接很有意义的阶段。为了降低风险，可以做一些事情：

在eth1上运行eth2投票时有一周的投票时间，以便在出现问题时有时间进行人工干预；

由于同样的原因，eth1通过轻客户端知道eth2中已敲定的区块时，ETH的提取也会有一周时间的延迟；

当抵押的ETH数量足够多的时候才开启这种桥接；

将投票阈值设置为高于50％；并使系统更倾向于不包含任何eth2区块(除非这些区块获得了很强的共识)。

原文链接：

https://ethresear.ch/t/two-way-bridges-between-eth1-and-eth2/6286

参考链接：

:https://github.com/ethereum/eth2.0-specs/blob/fffdb247081b184a0f6c31b52bd35eacf3970021/specs/core/0_beacon-chain.md

标签：IPSCHIETH2BLSIPSX币CHIKUNETH2SOCKS币BLST币

瑞波币热门资讯