Eth2 提案中已经包含 eth1-> eth2 的单向桥接 ，这对能够把 Eth1 中的 ETH 抵押到 eth2 中是必要的。这种单向桥接通过 eth1 数据投票机制[1]来实现。请注意，该机制 假设大多数的 PoS 验证者是诚实的，同时 PoW 链没有受到攻击 (具体来说，就是 PoW 链中回滚不会超过5个小时)。如果这两个假设中的任一假设失败，那么 eth1 和 eth2 这两条链将不再彼此“一致”。其中一开始便存在一条隐式的“社会合约”，即如果发生任何一种意外都有补救措施，很可能通过 PoS 链的软分叉来补救 ;然而也有可能如果 PoW 链回滚确实超过5个小时，那么社区可能会达成攻击链无效的共识。需要注意的是，不管在哪种情况下，PoS 链的故障是不可能需要 PoW 链进行软分叉的。
而如果我们希望 eth1 链知道 eth2 的状态(也即实现两条链的双向桥接 ，这是允许 ETH 从 eth2 链转移回到 eth1 链的前提)，有两种方法可以实现：
一种是使 PoW 链接受一个 PoS 链的轻客户端 ;
另一种是使 PoS 终态也敲定 PoW 链 。
第一种方法要求 eth1 中实现 eth2 客户端 (见下图)。 这将需要对 BLS-12-381 验证的 webassembly 或者原生支持，不要期望这种支持能够很快实现。另外，这种方法仅提供轻客户端级别的安全性 。
第二种方法可以通过添加这一机制来实现，即如果一个经由 eth1_data 投票的 PoS 区块，Bs包含一个指向 PoW 区块，Bw的引用(reference)，当区块 Bs 确认后，Bw 区块也可视为被确认(见下图)。不过这意味着 PoW 矿工(和客户端)也要运行 eth2 实现版，以便他们知道哪些 eth2 链被确认。
第二种方法更有趣，因为它为 eth1 提供了“原生”版回滚限制(通常称为“终态小工具提议(finality gadget proposal)”)。请注意，这与第一种方法有所不同，因为虽然它确实使 eth1 的分叉选择知道 eth2，但并没有立即使 eth1 知道 eth2 的状态。例如，理论上有可能两条竞争的 eth2 链确认同一个 eth1 区块 (这意味着 eth2 已经出故障，但从理论上讲还是有可能出现的)。更常见的情况是 eth2 链确认的两个区块，其中一个区块是另一个的子区块，而这两个区块都支持相同的 eth1 区块，从而有些矿工可能知道这两个 eth2 区块的最近状态，而另一些矿工不知道。这对“eth2 作为终态小工具”来说不是问题，但这确实意味着我们需要更多底层设计，使 eth1 清楚知道 eth2 的区块状态，以便允许从抵押合约(Deposit Contract)中提取 ETH。
一种可能方案是在 eth1 中简单地创建一个 eth2_data 投票机制;本质来说，就是复制使 eth2 知道 eth1 状态的同一种机制。可将其与上文方案结合起来确保一致性：eth1 矿工仅会为 eth2_data 区块进行投票，条件是只有当这些区块满足(i)已确认， 以及(ii)引用的 eth1_data 区块是矿工正在打包的 eth1 区块的祖块 (ancestors)。
面临的挑战
这两种方法都需要对 eth1 方面进行改动 。目前在eth1-> eth2的“最终转换”之前，eth2 路线图对 eth1 方面没有改动。而如果 eth2 中断，这两种方法都需要 eth1 采取紧急补救措施。第二种方法将要求所有 eth1 矿工也要运行 eth2 节点 。因此，尽管这两个中方法都是绝对可行的，但并不会很快实现 。但是，随着 eth2 持续运行并证明其稳健性，那么肯定会到一个实现这种双向桥接很有意义的阶段 。为了降低风险，可以做一些事情：
在 eth1 上运行 eth2 投票时有一周的投票时间，以便在出现问题时有时间进行人工干预;
由于同样的原因，eth1 通过轻客户端知道 eth2 中已敲定的区块时，ETH 的提取也会有一周时间的延迟;
当抵押的 ETH 数量足够多(如大于500万)的时候才开启这种桥接;
将投票阈值设置为高于50%(例如80%);并使系统更倾向于不包含任何 eth2 区块 (除非这些区块获得了很强的共识)。
