科普 | 定义 Eth2.0 中的验证者质量

引言

我们 Attestant 是非托管的 ETH 2.0 质押服务，既能为客户资金提供更高的安全性，又能利用先进的验证策略来获取比传统验证基础设施更高的收益。衡量收益的方法之一是，追踪 ETH 2.0 区块链上见证消息的生成和上链情况。这是一大关键指标，因为见证消息越早上链，收益就越高。本文将介绍 Attestant 是如何单独或综合计算见证有效性的。

见证消息

见证消息（attestation）是验证者对 ETH 2.0 区块链当前状态的投票。每个激活状态的验证者都会在每个 epoch （时段）（约长 6.5 分钟）创建见证消息。见证消息包含以下部分：

– 图 1 ：见证消息的结构 –

其中比较有趣的部分是链首投票（chain head vote），即，验证者在创建这条见证消息时认为哪个区块是链上**的有效区块。链首投票的结构如下所示：

– 图 2 ：链首投票结构 –

图中的 sLoot （时隙）定义了验证者认为当前区块链的链首所在位置（所在高度） ，Hash（哈希）定义了验证者认为的链首区块。二者共同定义了区块链上的一个点。有了足够多的投票，网络就可以就区块链的状态达成共识。

虽然一条见证消息的数据量比较小，但是验证者有数万名 ， 数据量很快就会积少成多。由于这些数据将永远存储在区块链上，减少数据量非常重要。这是通过一个被称为 “聚合（aggregation）” 的过程实现的。

聚合就是将多条 committee（委员会）、chain head vote（链首投票）、finality vote（终局性投票）都相同的见证消息（译者注：即同一委员会中作了相同的链首投票和终局性投票的见证消息） 合并成一个聚合见证消息（aggregate attestation）：

– 图 3 ：聚合见证消息的结构 –

聚合见证消息与单个见证消息存在两点差异。首先，前者有多个验证者。其次，聚合签名是由单个见证消息的签名合并生成的。聚合见证消息的存储效率很高，但是会增加通信和计算方面的负担（详见下文）。

如果我们强制要求每个验证者将所有见证消息聚合起来，那么将每个见证消息传给每个验证者所需的通信量很快就会导致网络过载。同样地，如果聚合只是可选项，那么验证者就不会浪费自己的资源这么做。因此，网络会选择一组验证者来负责进行聚合¹。出于利益考虑，验证者会认真履行职责，因为包含较多验证者的聚合见证消息更有可能被添加到区块链上，验证者就更有可能获得奖励。

执行这一聚合过程的验证者就是聚合者（aggregator）。

见证奖励的变化情况

ETH 2.0 在为验证者计算见证奖励时采用了打包距离（inclusion distance）这一指标。打包距离指的是见证消息生成时所处的 sLoot 与该见证消息被打包到区块时所处的 sLoot 之差。例如，在 sLoot s 生成的见证消息在 sLoot s+1 被打包到区块中，这时打包距离就是 1 。如果见证消息在 sLoot s+5 被打包到区块中，这时打包距离就是 5 。

在 ETH 2.0 网络中，见证消息的价值取决于打包距离，打包距离越小越好。这是因为越早上链的信息越有用。

为体现见证消息的相对价值，验证者所获得的见证奖励会随打包距离的增大而减少。具体来说，见证奖励会乘以 1/d （d 为打包距离）。

– 图 4 ：见证消息与打包距离之间存在函数关系 –

见证消息的打包过程

见证消息是如何打包到 ETH 2.0 区块链上的？其过程如下²：

1. 每个参与见证的验证者都会使用其所拥有的链状态的相关数据生成见证消息；
   
2. 见证消息会通过 ETH 2.0 网络广播给相关聚合者；
   
3. 每个聚合者在收到见证消息后都会将它与其它具有相同声明的见证消息聚合起来；
   
4. 聚合见证消息会通过 ETH 2.0 网络广播至所有节点；
   
5. 只要是没有在链上看见该聚合见证消息的区块提议者都可以将其打包到区块中。
   

一旦你发现打包距离大于 1 ，就要了解其背后原因。可能有以下几个原因：

见证消息生成延迟

验证者可能会遇到一些问题，从而导致见证消息生成延迟。例如，验证者所拥有的链状态相关数据过时，或者验证者在生成和签署见证消息上花费时间过久。无论出于哪种原因，见证消息生成步骤的迟滞都会对整个流程的剩余步骤产生连锁反应。

见证消息广播延迟

验证者生成见证消息后需要通过网络将见证消息广播至聚合者处。这**程的本质意味着，广播宜早不宜迟，因为这样可以确保验证者及时收到该见证消息，并将其合并到聚合见证消息中。验证者应该连接到足够多的对等节点，从而确保自己能尽快将见证消息广播给聚合者。

聚合见证消息生成延迟

聚合者可能会推迟见证消息的聚合流程。最常见的原因是，聚合者节点已经因为生成见证消息而过载，但是如果需要聚合大量验证者，聚合算法的速度也会造成巨大延迟。

聚合见证消息广播延迟

与见证消息广播延迟类似，聚合见证消息也需要在网络中广播，因此存在相同的延迟风险。

区块生成失败

要想让见证消息上链，首先要将它打包到区块中。但是，区块生成并不一定总能成功。有两种情况会导致区块生成失败：1. 验证者离线；2. 验证者与网络中的其他验证者失去同步，导致其生成的区块因包含无效数据而被拒绝。如果区块生成失败，就无法确保见证消息在同一个 sLoot 内上链，导致打包距离大于**距离。

区块生成失败还会产生其它影响，即，增加了可打包进下一个区块的见证消息总量。如果可打包的见证消息总量超过了区块容量，区块生产者很可能优先打包那些可以带来较高收益的见证消息，也就是那些打包距离最小的见证消息。这就有可能导致那些错过**打包距离的见证消息一再被推后，因为它们能带来的收益越来越低。

由于验证者无法控制区块生成³，我们定义了 “最早打包 sLoot（earliest inclusion sLoot）” 这一术语。最早打包 sLoot 指的是见证消息生成后的第一个生成有效区块的 sLoot 。见证消息无法打包到一个不存在的区块中，因此，以见证消息生成后的第一个 sLoot 为标准也衡量不出见证者的效率。这个标准就体现了这些考量，将 “最早打包 sLoot” 定义为见证消息生成后的第 1 个产生有效区块的 sLoot（译者注：即过滤掉区块生产者的失误对衡量验证者效率造成的影响）。

恶意行为

尽管如此，恶意参与者依然有可能拒绝将见证消息聚合，或者拒绝将见证消息打包到区块中。前者的风险可以用让每个验证者团体都有多个聚合者来缓解 。为降低后者的风险，不打包见证消息需要承担一定的成本。但是，参与见证的验证者无法迫使区块生成者打包见证消息，因此如果不打包见证消息所产生的收益高于其成本，参与见证的验证者就束手无策了。

计算见证消息有效性

考虑到区块生成和打包距离，见证消息有效性可以理解为见证消息对网络的用处有多大。见证消息有效性的正式定义是：

区块有效性是以百分比呈现的。下表列出了一些示例：

区块距离的上限是 32 。如果未能在区块距离达到上限之前将见证消息打包进区块，则该见证消息的有效性为 0。

聚合见证消息有效性

单个见证消息的有效性很有趣，但本身意义不大。如果我们将不同验证者在不同 sLoot 生成的见证消息的有效性综合起来看，就能更好地了解这组验证者的整体有效性。我们只需取单个见证消息有效性的平均值，即可计算出聚合有效性，例如，一组特定验证者连续 7 天来的有效性均值。

总结

当 ETH 2.0 启动时，成千上万个节点会确定彼此的位置，然后开始提议和见证区块。就像所有不成熟的网络一样，你需要通过不断的摸索来找到如何让你的节点尽可能有效的方法。正如上文所述，见证消息有效性是用来追踪节点有效性的一大指标。希望实现奖励**化的验证者可以通过见证消息有效性来了解其总体表现。

Attestant 会为我们的验证者追踪其见证消息有效性，并将客户报告中的数据汇总起来，从而提供更清晰的表现指标。随着我们继续拓展非托管 ETH 2.0 质押服务，我们很乐于与大家分享更多的指标。

注释：

1. 验证者组合中的成员每过几分钟就会改变，因此所有验证者共同负担聚合成本。
   
2. 这是经过简化的见证流程，但是出于本文的目的而言，这个流程是准确的。
   
3. 显然，除了那些验证者自己生成的数据。
   

（完）

（文内有许多超链接，可点击左下 ”阅读原文“ 从 ETHFans 网站上获取）

---

原文链接:

https://www.attestant.io/posts/DeFining-attestation-effectiveness/

作者: Jim McDonald

翻译AMPL校对:
闵敏AMPL

阿剑

---

SOLid;border-right-width: 0px;border-bottom-width: 0px;border-left-width: 0px;border-color: rgba(0, 0, 0, 0.1);transform-origin: 0px 0px;transform: scale(1, 0.5);box-sizing: border-box !important;overflow-wrap: break-word !important;”>

你可能还喜欢：

科普 | ETH2 的验证者有效余额是什么

科普 | 以太坊 2.0 网络的四项健康指标

科普 | 保护验证者密钥的几种方法