最近 $Obol 登上 Binance，也借这个机会聊下 Obol 的技术架构。

首先 Obol 项目存在的意义，是帮 ETH 的 Staking 增加容错性。

不太精准地说，Obol 相当于创造了一个专门用于管理 Staking 的多签机制。

最常见的一个场景是：如果你直接跑以太坊客户端去 Stake ETH，那么一旦节点掉线，你掉线的时间非但颗粒无收，甚至会被倒扣和低保等额的 ETH 罚款。

所以，如何防止 ETH Staking 节点掉线就成为了大家的研究课题。

Obol 的解决思路是：

你在运行 ETH 客户端的同时，再多运行一套 Obol 的客户端（中间件）。

运行 Obol 客户端之后，你可以选择 3-10 个节点运营商共同管理你的节点，这样即便其中若干节点掉线了，其他节点还能正常工作。

PS：当然，理论上也可以你自己多服务器自己跑，或者让你的朋友来帮你跑。

不过，这个过程看起来容易，实现上却有难度。

ETH 的 Staking 机制就摆在那里，在设计之初没有给 DVT 协议留下专门位置，因此 DVT 协议们必须在 ETH Staking 现有机制的约束下工作。

所以，Obol 采用的迂回方式是，通过节点运行额外的客户端，它建立了一个 Obol 网络，独立于 ETH 网络之外。

（Charon 就是 Obol 客户端的名字）

这个网络是个点对点网络，解决了不同节点之间的通讯安全问题。

然后，在同一个小组里的节点们完成相互握手之后，它们就会举行一个 DKG 仪式。

所谓 DKG，它的全称是分布式密钥生成，这种设计可以实现（以 3/4 签名为例）：

1. 没有中间人

2. 四个节点相互不知道对方的密钥碎片

3. 至少三个节点在线就可以执行验证者工作

这样，私钥就存储在节点本地。另外 Obol 没有【拆分】这个动作，它直接要求节点在本地生成碎片之一，这样可以避免密钥触网的问题。

另外，由于 ETH Staking 本身【资产私钥】和【验证者私钥】就是两把。

和非托管 Staking 一样，DVT 协议在这里同样只负责验证者这一把，并没碰到资产私钥，而资产私钥永远掌握在 ETH 持有者本人手里。

所以 DVT 协议即便出现多人串通，最多是干扰让节点无法出块，而技术上没法把你 Staked ETH 直接偷走，带来实际的本金损失。

相反，如果你的 Staking 不慎掉线，另外 3 个依然可以把你的节点救起来。

另外还有一些小的机制设计也比较有趣，例如 Obol 允许那些客户端根据自己意愿决定升级，可以运行不同版本，无需同时升级。

所以，当 Obol 发布新版本时，现有的 3/4 不升级依然可以继续使用，只要小组内的客户端保持一致即可。这样，最大程度降低Obol 官方导致故障的可能性。

这就是 Obol 如何增加 ETH Staking 容错性的技术原理。