撰文：Frank Fan、0xCryptolee，Arcane Labs
「只要勇于做出承诺，世界自会助你铲除不可逾越之障碍。去完成未竟之梦想，宇宙绝不会抑制你前进的步伐，这即是奥义所在。」
——以太坊 PoW 时代最终区块留言
以太坊经历了历史性的升级，发展进入了新的阶段。合并之后，以太坊将继续沿着扩容和去中心化的方向前进。The Merge 仅仅是 PoS 时代的第一步，以太坊依然面临着巨大的挑战，验证者群体中心化，扩容，Lazy Validator Problem 等问题依然制约着应用的爆发和以太坊的安全扩展，本文将从 The Merge 开始，逐步分析 POS 采用的共识算法，重点探索使用 DVT 技术来解决验证者单点风险的问题，和从业者一起分析以太坊的问题和未来的发展机会，建议具备一定以太坊基础的读者阅读此文章。
1. The Merge
1.1 背景
The Merge 是以太坊有史以来最大的技术升级，在 2022 年 9 月 15 日实现了 Execution Layer 和 Consensus Layer 的合并，其最大的变化是将以太坊的 PoW 共识切换为 PoS 共识。
除此之外，合并以后以太坊的能源消耗降低了将近 99.95%，据 Vitalik Buterin 推文，以太坊合并将使全球用电量减少 0.2%。
1.2 合并带来的改变
- 代币增发：PoW 时代的 ETH 代币增发停止，新的 ETH 仅通过 PoS 共识出块产生，以太坊的通胀率降低，当 base fee 超过 15gwei 的时候，以太坊甚至进入通缩。
- 质押收益：gas 费用和 MEV 的收入被分配给 Validator，验证者的质押币本位收益达到 5-7%。
- Withdraw：合并以后质押的 ETH 并不能立即 Withdraw，需要在上海升级以后才会放开 Withdraw 的限制，并且在提款的时候，用户并不能直接提取，为了避免大规模的提款，对于单次提款的数量和时间都有一定的限制，所以开放提款以后，并不会出现大量提款抛售的情况。具体的信息可以参考 EIP-4895：Beacon chain push withdrawals as operations
- 数据结构的改变：Consensus Block 里面会包含 Execution Block 的 Hash 值，同时 Execution Block 里面和 PoW 相关的参数不再生效。mixHash 字段会记录以太坊原生的 RANDAO 随机数，供 EVM 调用，以太坊的开发者可以直接使用这个随机数到智能合约开发中。
- 共识替换：PoW 共识被 PoS 替换，原有的矿工职责被验证者替代，同时存在两条链，需要同时运行两个客户端节点，Execution Layer Client（EL）和 Consensus Layer Client（CL）。
切换为 PoS 共识以后，以太坊的算法由 Ethash 转换为了 Casper FFG（Gasper），相较之前的算法，Gasper 更加节能，不需要再通过专门的矿机计算难度值，而是通过随机的方式来出块，让我们往下继续探索以太坊的共识算法和出块方式！
2. Gasper
目前信标链上面质押了13,830,378 个 ETH，活跃验证者的数目为432,203 个（截至 2022 年 9 月 23 日），根据 PBFT 的特点，beacon chain 的验证者数目很多，网络通信数据量大，简单的 PBFT 不再适用于以太坊网络，于是以太坊在网络结构上面采用 PBFT 的思想对网络架构进行了改进和设计，使用了 Gasper 算法。
Gasper 为 beacon chain 协议中的终局性工具（finality gadget），用于确定哪些区块应被参与者认定为已经确定的、不可更改的，同时在分叉的时候用于确定哪个分叉链是主链。Gasper 的终局性一般化了《Casper Friendly Finality Gadget（casper FFG）》论文中的概念。
2.1概念
- Slot（时隙）：合并以后一个 Slot 就是一个区块，有一个 committee 负责在 12S 的时间内生成该 Slot。
- Epoch：每 32 个 Slot 组成一个 Epoch，一个 Epoch 的时间为 384S，即 6.4Min。
- Committee（验证者委员会）：每个验证者委员会最低会分配 128 个 Validator，验证者会对自己负责的 Slot 进行 Attestation 操作，并且在委员会中有一个 Validator 会被随机选为 Proposer，进行出块。
- Attestation（投票签名）：每一个 Slot 对应的 committee 里面的 Validator 都需要对上一个 Epoch 进行投票签名，确保自己认可了上一个 Epoch 里面的交易。
- Validator（验证者）：由于以太坊 The Merge 以后共识算法切换为了 POS，原来的矿工被 Validator 取代，Validator 通过质押 32ETH 资产成为 Validator，负责参与各个 Epoch 内 slot 的出块和签名工作。
- Proposer（提议者）：Proposer 来自 committee 中的 Validator，通过 RANDAO 产生的随机数选出，被选用于 Slot 区块的打包。
- Beacon chain（信标链）：用于替代 PoW 共识的 PoS 区块链，beacon chain node 被用来挂载 Data Blobs 的交易类型，为 Rollup 提供更多的存储空间。
2.2 流程
Epoch 开始的时候，通过 RANDAO 为每一个 Slot（时隙）分配一个 Committee（验证者委员会）对上一个 Epoch 进行 Attestation（签名投票）。
为当前 Epoch 的 32 个 Slot 分配多个 Aggregator 将 committee 对上一个 Epoch 的 Attestation 聚合以后记录进 Slot 区块里。
RANDAO 通过生成随机数确定 Proposer 负责出块。
在当前 Epoch，每一个 Slot 在出块的时候，committee 都对上一个 Epoch 的检查点进行 Attestation，连着两个检查点 Attestation 以后，上一个检查点才 Finalised，直到 32 个 Slot 都依次对检查点进行了 Attestation，本轮 Epoch 结束。Post-Epoch 的第一个 Slot 开始的时候，Pre-Epoch 达到了终局性的共识，即 Post-Epoch 经历了 Pre-Epoch 和当前 Epoch，一共两轮 Epoch（因为两个 Attestation 的检查点之外，还有冲突的检查点的话，必然有 1/3 的验证人作恶了，比如 32 64 96 三个区块高度，可能 64 号高度没有达成检查点，到了 96 号才有检查点，这时候 32 号高度才是 Finalised），时间上为 12.8Min，交易就在链上确定下来了，即所谓的终局性。
2.3 特性
RANDAO 赋予了链上的随机数。RANDAO 生成的随机数将会放进 Execution Layer Block，智能合约能够直接使用该随机数，在拥有链上的原生随机数以后，DeFi 可能会有新的应用诞生，比如博彩类的 DeFi 应用可以直接信任和使用 RANDAO 产生的随机数。
2.4 Latest Message Driven GHOST（LMD-GHOST，由最新消息驱动的 GHOST）
在以太坊新的 POS 共识机制中使用 LMD-GHOST 作为分叉选择规则，当发生分叉的时候，GHOST 会选择获得更多消息支持的子树。其背后的理念是在计算链头时，只考虑每个验证者最近的投票，而不是过去产生的任何投票，以此降低运行 GHOST 所需的计算量。
想要深入学习的可以查阅：https://eprint.iacr.org/2013/881.pdf
2.5 随之而来的问题
- 通信与验证成本增加：是不是验证者越多越好呢？其实不然，虽然验证者的数量增多有利于数据可用性采样（DAS）和去中心化，但是验证者增多意味着单个 Slot 的验证者也会变多，在收集各个验证者签名的时候就会增加 Aggregator 和验证者之间的通信负担，除此之外，聚合签名的验证成本也会增大，这无形中会增加验证者节点的负担。
- 长程攻击：长程攻击是指某个验证者在 Withdraw 质押在信标链上的 ETH 后，他可以利用旧私钥在某个曾经签署过的区块进行恶意分叉，因为此时其在链上已无任何质押资产，然后迅速产生空块至目前的区块高度，对网络进行攻击。这也是未来可能出现的攻击方式。以太坊在设计的时候是对 Pre-Epoch 的 checkpoint（检查点）进行投票，其设计思路也就是将初始状态不断往前推进，避免可能出现的攻击。
3. 以太坊质押挖矿
3.1 Staking
质押门槛：验证者为了履行职责参与共识出块需要质押 32ETH 作为保证金资产。
验证者的职责：在协议规定的时间生产区块和 attestation。
3.1.1 Staking 方式
- Solo Staking：solo staking 的方式是由想要自己出资 32 个 ETH 做验证者的质押人自己在云服务器上运行验证者节点，除了选择在云服务器上面运行节点，也可以选择在自己家中摆放服务器设备运行以太坊节点，区别在于云服务之上运行节点更加稳定，在参与网络共识的时候可以避免和减少因为停电和网络原因造成的怠工惩罚，而在家自己搭建节点的优势在于硬件和网络服务的成本低于云服务器，这里质押人可以自行选择采用哪种托管方案。
- Staking Pool：由于 32 个 ETH 对于普通人来说是一笔不菲的资金，寻常小资金的质押者想要参与网络共识却没办法自己运行节点，于是出现了质押池解决方案，其中以许可型的半去中心化质押解决方案 Lido 为主要项目，其吸收了较大的资金体量，成为赛道内的头部解决方案，其次还有去中心化程度更高一些的解决方案如 Rocket Pool 和 Swell 等，在现有的质押池解决方案之上，还产生了 Unamano 这样的聚合解决方案来帮助和发展以太坊 Staking 领域。
在节点运营方面，Lido 选择指定部分专业的运营商来运行网络节点，这也是其相对中心化的一点，运营商掌握签名私钥，用户的资产部分信赖 Lido 和运营商，至于提款私钥，2021 年 7 月之前，提款地址是一个 6/11 的多签地址，多签私钥由行业内 OG 保管，2021 年 7 月之后，提款地址指向一个可升级的合约地址，该合约由 DAO 进行管理。Rocket Pool 在节点方面选择更加去中心化，任何人只需要提供 16 个 ETH 和相应的软硬件设备就可以作为运营商运行节点，虽然降低了运营商门槛，但是 Rocket Pool 引入 $RPL 质押来降低运营商作恶的风险。
Staking Pool 的方案使得普通的用户可以将小额的 ETH 存入合约来获得以太坊的挖矿奖励，同时返还生息代币如 stETH 和 rETH 来释放质押资产的流动性，进一步增强了以太坊的去中心化程度和资金使用效率，是社区最为看好的方向。
- CEX，中心化托管机构：除了 Solo Staking 和 Staking Pool,中心化的交易所和一众资管机构都是以太坊质押的主要参与者，例如 Coinbase 和币安等也都推出了自己的质押服务，通过吸收小额的 ETH 来参与低风险的以太坊质押挖矿。三种方案在去中心化程度和安全性方面都各有优劣，这取决于质押者的信任对象，但是无可置疑的是，三种方案都捕获到了相应的资金和用户，共同维护着以太坊的安全和去中心化。
3.1.2 风险与隐患
是否合并以后真的就万事大吉？我觉得未必，从下图的数据我们可以窥探一下解除信标链提款限制以后的局面。
目前以太坊的质押量主要集中在 Lido，Coinbase 和 Solo Staking，合并以后新的以太坊质押则大量流向了 Lido 和 Coinbase 这类相对中心化的机构和协议里，在解除提款限制以后，我觉得原来质押的以太坊会被重新分配到 Lido 和 Coinbase 里，随着时间的流逝，Lido 和 Coinbase 将会掌握越来越多的以太坊验证者和质押量，最终对以太坊的去中心化带来严重的威胁，当他们控制住以太坊以后，对于想要重新打破这种局面的交易，将会被 Lido 或 Coinbase 这样的大矿池所拒绝，因为你想质押 ETH 到以太坊的这笔交易能否上链也是他们说了算，并且新产生的 ETH 也将会往 ETH 越多的人手里集中，因为他们在质押的时候就掌握了大量的 ETH，这无疑对以太坊的去中心化会是新的挑战，我们可以期待社区和核心开发者一起来解决这个问题。
3.1.3 奖励类型
- Attestation 奖励：每一个 slot 的 committee 都要对前一个 Epoch 历史区块检查点进行 Attestation，成功 Attestation 以后会获得 Attestation 奖励，作为 Validator 的收入之一。（概率大，奖励低）
- 出块奖励：每一个 Slot 会有一个 Validator 作为 proposer 来打包区块，被选为 proposer 的 Validator 可以获得出块奖励。（概率低，奖励多）
- MEV（矿工可提取价值）收入：MEV 收入除了 gas 费用的收入以外，还有三明治攻击等方式的收入，据 EigenPhi 的数据，过去 7 天三明治攻击的 Volume 都在 100M 以上，最高 Volume 接近 400M，MEV 的收入成为验证者的重要收入组成之一。
3.1.4 惩罚类型
- 怠工惩罚：未能按照共识预期产生出块：未在预期时间对区块进行 Attestation。
- 恶意行为导致 slash（罚没）：在单个 Slot 内生产两个区块或者进行两次 Attestation；违反 Casper FFG 共识规则提议错误区块。
3.2私钥类型
- 签名私钥：签名私钥用于验证者在履行职责时的消息签署，包括 attesting 和 proposing blocks，每 6.4min，即每个 Epoch，该密钥将被使用一次。
- 提款私钥：提取质押资产和出块奖励时使用的密钥，需要离线存储，在上海分叉以后，可用提款私钥提取质押的 ETH 和奖励。
3.3ETH2 质押风险
- 私钥被盗：ETH2 的签名 / 提款私钥被盗。
- 单点故障 / 验证者的有效性：目前，验证人以单一的机器或节点存在并履行其职责。协议严格的规则禁止常见的冗余形式，如在多个节点上运行同一个验证人，这样做可能会导致验证人被 「惩罚」（slashed）。如果使用质押服务，密钥位于一个云服务器上（ 如 AWS）。如果任何组件出了问题，验证人就会停止验证，从而受到惩罚。
4. 分布式验证者技术（DVT）
在质押层面，虽然我们有去中心化的质押解决方案来降低质押门槛和提高质押服务的去中心化，但是在 Validator 层面，依然存在着单点风险，现在单个验证者运行着网络的多个客户端，如果因为网络原因或者是断电等物理因素会造成怠工惩罚，slot 也无法收集到有效的签名，我们无法通过冗余的方式在多个地方运行同一个验证者节点，因为这会造成签名的混乱，会被认为是对网络的攻击，但是我们可以将签名私钥拆分，通过 DVT 技术来降低单点故障的风险，在实施升级的时候，也为节点提供了升级空间，并不会因为网络升级导致节点的大面积掉线，具体分析，请让我们往下探究！
4.1 概念
- operator：运行一个（或多个）节点的个人或实体。
- operator node：指的是一个硬件和软件，执行以太坊验证者的任务。这些任务可以由节点单独完成，也可以与其他使用 DVT 工具的节点联合完成。
- 分布式验证者技术：分布式验证者技术是一种将单个以太坊验证者的工作分配给一组分散节点的技术。相比验证者客户端在单台机器上运行，分布式验证者技术能够提供更加安全和去中心化的服务。
4.2 分布式验证者节点需要运行
- 以太坊执行层客户端
- 以太坊共识层客户端
- 以太坊分布式验证者客户端
- 以太坊验证者客户端
4.3DV 如何防范 ETH2 质押风险
私钥被盗
- 使用门限签名技术（m-of-n）可以实现防止私钥被盗的风险
- 一个完整的验证者密钥被拆分为多个小的密钥
- 拆分后的小份密钥通过聚合产生完整密钥的签名
节点宕机
Crash Faults：
- 原因：因为停电，断网，硬件故障，软件错误导致的崩溃；
- 防范措施：通过在多个地方运行同一个节点的冗余备份方案来防范节点掉线；
Byzantine Faults：
- 原因：由软件 bugs，网络攻击导致；
- 防范措施：多个参与节点通过共识决定，单个节点无法做出决定。
4.4 总体架构
- 分布式验证者使用私钥分片远程签署消息
- 在分布式验证者客户端内通过聚合签名技术对分布式验证者的签名进行聚合，达到阈值以后，对区块进行签名。
4.5 实现 DVT 技术的两种路径
- An approach to DVT using SSS：该方案由质押 32 个 ETH 的实体创建签名私钥（sk，pk）和提款私钥，并运行一个 Secret Sharing Scheme 程序在委员会节点中安全的分发 sk 密钥的份额。
- An approach to DVT using a DKG protocol：在 DKG 的方案中，没有一个实体来为验证者分发签名私钥的份额，而是一群验证者委员会节点一起运行 DKG 协议。因此，一个秘钥和公钥（sk，pk），以及 sk 的 n 个份额 sk_1，…，sk_n 被创建，i=1，…n 的第 i 个节点拥有份额 sk_i。
4.6 Threshold Signature Schemes (TSS)（阈值签名方案）
当验证者对区块达成一致需要签名时，采用 BLS 阈值签名方案来实现签名。其允许 N 个验证者共同签名数据，并且在 t+1（0) 个验证者正确签名的情况下实现完整签名。通过 tss 的方案，既实现了每一个验证者都无法获得完整的签名私钥，又保证了完整签名的顺利生成。
5. 从主流项目看 DVT
5.1 SSV
表面上看，SSV 提供了稳健的、去中心化的进入以太坊质押（Staking）生态系统的途径。再深入一点，SSV 是一个复杂的、配有共识层的多签钱包，SSV 在信标链节点和验证者客户端之间充当缓冲器的作用。
5.1.1 配置的主要组成部分
- Distributed Key Generation：operator 通过运行 SSV 程序计算生成了一个共享的公私钥集。每个 operator 只拥有私钥的单一部分，确保没有一个运营商可以影响或控制整个私钥做出单方面的决定。
- Shamir Secret Sharing：这个机制被用于使用预先定义的 KeyShares 阈值重构验证者密钥，单个的 KeyShared 不能被用于签署消息。SSV 能够利用 BLS 技术聚合签名，创建验证者的完整密钥签名。通过结合 Shamir 和 BLS，验证者的签名私钥被切片共享，并在需要签名时聚合重组。
- Multi-Party Computation：将安全的多方计算（MPC）应用于 secret sharing，允许 SSV 的 KeyShares 安全地分布在 operators 之间，以及执行验证者职责的分散计算，而无需在单个设备上重建验证者密钥。
- Istanbul Byzantine Fault Tolerance Consensus：将这一切联系起来的是 SSV 的共识层，基于伊斯坦布尔拜占庭容错（IBFT）算法。该算法随机选择一个验证者节点（KeyShare），负责区块提议并与其他参与者分享信息。一旦预定的 KeyShares 阈值认为该区块是有效的，它就被添加到链上。因此，即使一些 operators（达到阈值）有问题或目前不在线，也可以达成共识。
5.1.2 SSV 生态的三类参与者
- Stakers：利用 SSV/DVT 技术的交易所，服务商或个人 ETH 持有者，以实现其验证者的最佳有效性、安全性和去中心化。stakers 向 operators 支付 SSV 代币的费用，以管理他们的验证器。
- Operators：operators 提供硬件基础设施，运行 SSV 协议，并负责维护验证者和 ssv.网络的整体健康。operator 以 SSV 代币确定其服务费用，并向验证者收取运营和维护验证器的费用。
- DAO (SSV token holders) ：ssv.network DAO 分散了 ssv.network 协议和资金的所有权和治理权，SSV 是网络的原生代币。任何拥有 SSV 代币的人都可以参与 DAO，对提案和其他需要投票的项目进行投票。拥有的 SSV 代币的数量决定了对影响网络的决策的投票权。
5.1.3 ssv.network DAO 负责以下工作：
- Operator scoring：ssv.network 依靠 operators 和对他们的质量、经验和提供的服务进行 0-100% 的去中心化和透明的评分。DAO 还负责审核 「Verified Operators」（VOs），并维护 VOs 的名单。Stakers 可以查看并使用这些排名来选择管理其验证者的 Operators
- Network fees：为了使用 ssv.network，Stakers 需要支付网络费。网络费是对每个验证者收取的固定费用，被添加到 operators 费用中。网络费直接流入 DAO 国库，可用于资助 SSV 生态系统的进一步发展和通过 DAO 投票程序的活动。
- Treasury：stakers 支付的网络费用为 DAO 国库提供资金，它被用于发展 SSV 协议和生态系统的项目。可能包括协议开发和网络增长的赠款，与 SSV 代币持有人直接分享收入，营销和社区激励，代币交换以实现国库的多样化，以及战略合作伙伴的投资以换取 SSV 代币。
- Voting：提交给 DAO 的拨款请求和其他需要投票通过的提案。任何持有 SSV 代币的人都可以对影响 DAO 的决定进行投票，例如拨款请求、成为验证运营商的请求以及提交给 DAO 考虑的其他想法或请求。
5.2 Obol
Obol 是一种通过 multi-operator 促进 staking 信任最小化的协议，该协议能够被作为多种类 web3 产品的核心模块以低信任成本获得以太坊质押收益。
5.2.1 Obol 的四个核心公共产品：
- Distributed Validator Launchpad：引导分布式验证者的 CLI 工具和 dApp
- Charon：Charon 是 Obol Network 的分布式验证者客户端，也是启用信任最小化验证的第一步。Charon 支持容错、高可用性验证，使一群人能够在多台机器上共同运行验证者，而不是在单个机器上运行。
- Obol Managers：一组用于形成分布式验证器的可靠智能合约
- Obol Testnets：一组正在进行的公共激励测试网，使任何规模的运营商都可以在为 Obol 主网网络服务之前测试他们的部署。
5.2.2 关键概念：
- Distributed Validator：分布式验证器是运行在多个节点 / 机器上的以太坊权益证明验证器。使用分布式验证器技术 (DVT) 可以实现此功能。分布式验证者技术避免了单点故障的问题，如果 DVT 集群中<33% 的参与节点下线，剩余的活跃节点仍然可以就签署达成共识，并为 Staking 的验证者生成有效签名。这是主动冗余方式，用于最大限度减少关键任务系统停机时间的常见模式。
- Distributed Validator Node：分布式验证器节点是 operator 需要配置和运行以履行分布式验证器 operator 职责的一组客户端。operator 可以在同一硬件上运行冗余的执行和共识客户端，运行执行层中继器（如 mev-boost），其他检测服务，以确保最佳的性能。在上述例子中，客户端堆栈包括 Geth，Lighthouse，Charon 和 Teku。
- Execution Client：执行层客户端（以前称为 Eth1 客户端）专门负责运行 EVM 和管理以太坊网络的交易池。
执行层客户端包括：Go-Ethereum、Nethermind、Erigon。
- Consensus Cilent：共识客户端的职责是运行以太坊的权益证明共识层，通常称为信标链。共识层客户端包括：Prysm、Teku、Lighthouse、Nimbus、Lodestra。
- Distributed Validator Client：
分布式验证者客户端通过标准化的 REST API 拦截验证者客户端↔共识层客户端的信息流，并聚焦于两个核心职责：
- 就所有验证者签署的候选人职责达成共识
- 将所有验证者的签名组合成一个分布式验证者签名
- Validator Client：验证者客户端是运行一个或多个以太坊验证者的一段代码。
- 验证者客户端包括：Vouch、Prysm、Teku、Lighthouse
- Distributed Validator Cluster：分布式验证者集群是连接在一起的分布式验证者节点的集合。
- Distributed Validator Key：Distributed Validator Key 是一组 BLS 私钥，它们共同作为参与权益证明共识的阈值密钥。
- Distributed Validator Key Share：分布式验证者私钥的一份私钥。
- Distributed Validator Key Generation Ceremony：为了在分布式验证器中实现容错，各个私钥份额需要一起生成。与其让受信任的经销商产生私钥，将其分割并分发，不如让分布式验证器集群中的每个操作员参与所谓的分布式密钥生成仪式，这样做的好处是在任何时候都不会构建完整的私钥。分布式验证器密钥生成仪式是 DKG 仪式的一种类型。仪式产生签名的验证器存放和退出数据，以及所有的验证器密钥份额和它们相关的元数据。
6. 总结与展望
6.1 总结
行文通篇，从 The Merge 开始叙述，讲述合并以后以太坊采用的 Casper FFG 算法，熟悉了合并以后区块的产生方式以及新的一些技术概念，随后讲到了以太坊新的挖矿方式以及目前存在的 Staking 方案，了解到验证者存在的单点故障问题，随后又深入到 DVT 技术，并通过两个项目的案例简述 DVT 如何解决了这个问题，整篇文章按照去中心化的思路叙述，为读者了解以太坊的共识算法和去中心化发展方向提供了一定的参考。
6.2 展望
以太坊在 The Merge 以后，将会逐步实现 Danksharding，首先通过 EIP-4488 降低 calldata 的 gas 花销，从 16gwei 降低到 3gwei，为 rollup 的提速扩容进行强有力的支持，之后一步是在 Proto-danksharding 中引入 Blobs 的交易类型，使得以太坊能够为 rollup 提供更多的存储空间，降低 D/A 的成本，并逐渐实现 Danksharding。
要实现 Danksharding 中描述的数据可用性采样（DAS）、区块提议者 / 构建者分离（PBS）等设想，必须要确保以太坊网络的节点足够多，足够去中心化，数据可用性采样才能实施，也就是说要确保扩容和低成本的 D/A，以太坊的去中心化是最为重要的一环，因为去中心化的质押方案和 DVT 等技术对以太坊后续的发展至关重要。
特别感谢前火币研究院首席研究员李炼炫、Arbitrum 的集成工程师 JasonWan、Lido 社区的 Jerry、Unipass 研究员 cyberorange、Web3Q 的周齐博士以及石榴矿池的币圈李白对于本文成文的建议和审阅。
参考资料
1.https://www.ethereum.cn/validated-staking-on-eth2-2-two-ghosts-in-a-trench-coat
2.https://www.youtube.com/watch?v=awBX1SrXOhk
3.https://github.com/ObolNetwork/
4.https://www.ethereum.cn/Eth2/distributed-validator-specs
5.https://medium.com/nethermind-eth/sorting-out-distributed-validator-technology-a6f8ca1bbce3
6.https://docs.ssv.network/learn/introduction
8.https://ecn.mirror.xyz/kFzA6fZKF-qIjAOvOkJT03WizNea0Bo2Gx6tUDamFsY
10.https://twitter.com/VitalikButerin/status/1570299062800510976?s=19
15.https://ethos.dev/beacon-chain/
16.https://medium.com/nethermind-eth/sorting-out-distributed-validator-technology-a6f8ca1bbce3
