共识协议

1。概述

EOS 区块链是一种高效、确定性、分布式状态机，可以以去中心化方式运行。区块链跟踪一系列互换区块内的交易。每个区块以密码方式提交到同一链上的先前区块。因此，在不破坏连续区块的加密检查的情况下修改在给定区块上记录的交易是很难解决的。这个简单的事实使区块链交易不可改变且安全。

1.1。区块生产者

在EOS生态系统中，区块生产和区块验证由称为 “区块生产者” 的特殊节点执行。制作人由EOS利益相关者选出（参见 4.制片人投票/日程安排）。每个生产者通过运行一个 EOS 节点的实例 nodeos 服务。因此，按活跃计划生产区块的生产者也被称为 “活跃” 或 “生产” 节点。

1.2。达成共识的必要性

区块验证在任何一组分布式节点中都是一项挑战。必须建立共识模型，以便在去中心化系统中以容错方式验证此类区块。共识是此类分布式节点和用户就区块链的当前状态达成共识的方式（参见 3.EOS 共识 (dPoS + abfT)）。

2。共识模型

在去中心化系统中，有多种方法可以在分布式各方之间达成共识。大多数共识模型都是通过一些证据达成共识的。最受欢迎的两个是工作量证明（PoW）和权益证明（PoS），尽管还有其他类型的基于证明的方案，例如活动证明（PoW 和 PoS 的混合体）、销毁证明、容量证明、已用时间证明等。还有其他共识方案，例如Paxos和Raft。本文档主要关注EOS共识模型。

2.1。工作量证明 (PoW)

区块链中最常用的两种共识模型是工作量证明和权益证明。在 Proof of Work 中，矿工节点竞相寻找在区块头部添加的随机数，这会使区块具有某种所需的属性（通常在区块头的加密哈希的最重要位中有一定数量的零）。通过使找到使区块有效的随机数在计算上变得昂贵，攻击者就很难创建被网络其他部分接受为最佳链的区块链的替代分支。工作量证明的主要缺点是，网络的安全性取决于在计算能力上花费大量资源来寻找随机性。

2.2。权益证明 (PoS)

在权益证明中，拥有最大股份或某些资产百分比最大的节点具有同等的决策权。换句话说，投票权与所持股份成正比。一个有趣的变体是委托权益证明（DPoS），在这种变体中，大量的参与者或利益相关者选出较少数量的代表，然后由他们做出决策。

3。EOS 共识 (dPoS + abfT)

EOS区块链使用委托权益证明（DPoS）来选举活跃的生产者，他们将被授权签署网络中的有效区块。但是，这只是EOS共识过程的一半。另一半参与确认每个区块的实际过程，直到它成为最终的（不可逆转），这是以异步拜占庭容错（abFT）方式执行的。因此，EOS共识模型涉及两个层面：

• 第 1 层-原生共识模型 (abFT)。
• 第 2 层-委托权益证明 (DPoS)。

EOS中使用的实际原生共识模型没有委托/投票、质押甚至代币的概念。dPoS 层使用它们来生成区块生产者的第一个时间表，如果适用，在每个生产者循环完成后，最多每轮更新该集合。在EOS软件中，这两个层在功能上是分开的。

3.1。第 1 层：原生共识 (abFT)

该层最终决定哪些区块在当选的生产者之间接收和同步，最终成为最终的，从而永久记录在区块链中。它得到了第二层提出的制作人时间表（见 3.2。第 2 层：委托 PoS）并使用该时间表来确定哪些区块由相应的生产者正确签名。对于拜占庭式容错，该层使用两阶段区块确认流程，通过该流程，当前计划集合中三分之二的绝大多数生产者对每个区块进行两次确认。第一个确认阶段提出最后一个不可逆区块 (LIB)。第二阶段确认拟议的自由党为最终决定。此时，区块变得不可逆转。该层还用于在每轮计划开始时发出制作人日程安排变更的信号（如果有）。

3.1.1。EOS 算法最终性

EOS共识模型通过选定的一组特殊参与者（活跃生产者）的签名来实现算法的最终性（不同于工作量证明模型中充其量只能实现的概率最终性），这些签名按时间表排列，以确定哪一方有权在特定时间段签署区块。此时间表的更改可以通过在EOS区块链上运行的特权智能合约启动，但是任何启动的时间表变更都要等到启动时间表变更的区块通过两个确认阶段完成后才会生效。每个阶段的确认都由来自当前预定活跃生产者的绝大多数制作人执行。

3.2。第 2 层：委托 PoS (DPoS)

委托 PoS 层引入了代币、质押、投票/代理、投票衰减、计票、生产者排名和通货膨胀薪酬等概念。该层还负责根据制作人投票生成的排名生成新的制作人时间表。这发生在大约两分钟（126秒）的计划回合中，这是为区块生产者分配生产和签署区块的时间段所花费的时间。每位制作人总共持续6秒，即制作人回合，最多可以制作和签名12个方块。DPoS 层由 WASM 智能合约启用。

3.2.1。利益相关者和代表

活跃生产者（制作人日程安排）的实际选择开放供每轮日程表决，所有行使参与权的EOS利益相关者都参与其中。但是，实际上，活跃生产者的排名并不经常变化。利益相关者是普通的EOS账户持有者，他们投票选出优先的区块生产者，代表他们作为DPoS代表行事。但是，与常规DPO的一个主要不同之处在于，一旦当选，所有区块生产者都拥有平等的权力，无论获得的选票排名如何。在其他 DPoS 模型中，投票权与每位代表获得的选票数成正比。

3.3。共识过程

EOS共识过程由两部分组成：

• 制作人投票/排程-由 dPoS 第 2 层执行
• 区块生产/验证-由原生共识层 1 执行

这两个进程是独立的，可以并行执行，但创建区块链的第一个创世区块时启动序列之后的第一轮计划除外。

4。制片人投票/日程安排

将活跃生产者纳入下一个计划表的投票由 dPoS 层实现。严格来说，代币持有者必须首先质押一些代币才能成为利益相关者，从而能够以给定的质押权进行投票。

4.1。投票流程

每个EOS利益相关者可以在一次投票中为最多30个区块生产者投票。然后，前21名当选的制片人将作为DPoS的代表，代表利益相关者制作和签署区块。其余的生产者按获得的选票顺序列入待命名单。投票过程通过将每个生产者获得的选票数相加来重复每轮日程安排。未投票的制片人可以保留原来的选票，尽管由于选票衰减而贬值。投票的制片人也可以保留原来的选票，但每位选民最后一次投票权重的贡献除外，这会被他们的新投票权重所取代。

4.1.1。投票权重

每个利益相关者的投票权重是根据质押的代币数量和自EOS区块时间戳纪元（定义为2000年1月1日）以来经过的时间的函数计算的。在当前的实现中，投票权重与质押的代币数量成正比，base-2 与自2000年以来的几年时间成正比。实际体重以每周2^ {1/52} = 1.013419美元的速度增加。这意味着，对于相同数量的代币，投票权重每周都会变化，每年翻一番。

4.1.2。选票衰减

增加投票权重会使每个生产者当前持有的选票贬值。这种选票衰减是故意的，其原因有两方面：

• 通过允许新选票比旧选票更具权重来鼓励参与。
• 让那些积极参与重要治理事务的用户有更多的发言权。

4.2。制片人日程

在对制片人进行投票并入选下一个日程安排之后，他们只需按制片人姓名的字母顺序排序即可。这决定了生产顺序。每个生产者都会在即将开始的当前计划回合的第一个区块内收到下一轮计划回合的拟议制作人组，以进行验证。当绝大多数生产商加一个生产商认为包含拟议时间表的第一个区块不可逆转时，拟议的时间表将在下一轮计划中生效。

4.2.1。生产参数

EOS区块生产计划由当选的生产者平均分配。生产商计划根据以下参数（每轮赛程）生产预期数量的区块：

参数	描述	默认	图层
P（生产者）	活跃生产者数量	21	2
Bp（区块/生产者）	每个生产者的连续区块数量	12	1
Tb (s/block)	每个方块的生产时间（s：秒）	0.5	1

值得一提的是，Bp（每个生产者的连续区块数）和 Tb（每个区块的生产时间）是第 1 层共识常数。相比之下，P（活跃生产者数量）是由 dPoS 层配置的第 2 层常量，由 WASM 合约启用。

可以根据上述参数定义以下变量（每轮赛程）：

变量	描述	方程
B（区块）	区块总数	Bp（区块/生产者）x P（生产者）
Tp (s/producer)	每个制作人的制作时间	Tb (s/block) x Bp (blocks/producer)
T (s)	总制作时间	Tp (s/producer) x P (制作人)

因此，在第 2 层定义的 P 的值可以在 EOS 区块链中动态变化。但是，实际上，N的战略设置为21个生产商，这意味着三分之二的绝大多数生产者需要15个生产商加一个才能达成共识。

4.2.2。生产默认值

使用当前的默认值：P=21 个当选生产者，Bp=每个生产者创建12个区块，每T=0.5秒生成一个区块，当前的生产时间如下（每个计划回合）：

变量	值
Tp：每个生产者的制作时间	Tp = 0.5 (s/block) x 12 (blocks/producer) ⇒ Tp = 6 (s/producer)
T：总制作时间	T = 6（s/producer）x 21（制作人）⇒ T = 126（s）

当给定的生产者在指定的时间段内没有生成区块时，区块链中就会出现差距。

5。区块生命周期

区块由活跃的生产者在其分配的时间段内按计划创建，然后中继到其他生产者节点进行同步和验证。这个过程从一个生产商持续到另一个生产商，直到在以后的日程安排中批准新的生产者时间表。当有效区块满足共识要求时（请参阅 3.EOS 共识），该区块将成为最终区块并被视为不可逆转。因此，区块在其生命周期内会经历三个主要阶段：生产、验证和最终完成。每个阶段也要经历不同的阶段。

5.1。区块结构

作为链间区块序列，区块链中的基本单位是区块。区块包含预先验证的交易记录以及额外的加密开销，例如区块确认所需的哈希值和签名、验证期间重新执行交易、区块链重播、防范重播攻击等（参见 block 下面的架构）。

区块架构

名称	类型	描述
timestamp	block_timestamp_type	此区块的预计生成时段（在 .000 或 .500 秒后结束）
producer	name	该区块生产者的账户名
confirmed	uint16_t	该区块的生产者在当前生产者计划中确认的先前区块数量
previous	block_id_type	上一个区块的区块 ID
transaction_mroot	checksum256_type	区块中包含的交易收据的 merkle 树根哈希
action_mroot	checksum256_type	区块中包含的操作收据的 merkle 树根哈希
schedule_version	uint32_t	自创世以来，制作人日程安排发生变化的次数
new_producers	producer_schedule_type	保存新的拟议制作人时间表的制作人名称和密钥；如果没有更改，则为 null
header_extensions	extensions_type	扩展区块字段以支持其他功能（包含在区块 ID 计算中）
producer_signature	signature_type	由创建和签名区块的制作人进行数字签名
transactions	数组 transaction_receipt	区块中包含的有效交易收据清单
block_extensions	extension_type	扩展区块字段以支持其他功能（不包含在区块 ID 计算中）
id	block_id_type	此区块 ID 的 UUID（区块头和区块号的函数）；可用于查询区块以进行验证/检索
block_num	uint32_t	区块号（自 genesis block 0 以来的顺序计数器值）；可用于查询区块以进行验证/检索
ref_block_prefix	uint32_t	降低区块 ID 的 32 位；用于防止重放攻击

有些区块字段在创建区块时是事先知道的，因此它们是在区块初始化期间添加的。其他则是在区块完成时计算和添加的，例如交易和操作的 merkle 根哈希、区块号和区块 ID、创建和签署区块的生产者的签名等（参见 网络对等协议：3.1。区块标识)

5.2。区块生产

在每轮计划区块生产中，生产者必须按计划创建 Bp=12 个连续的区块，其中包含尽可能多的经过验证的交易。目前，每个区块的生成时间为 Tb=500 ms（0.5 秒）。为了保证有足够的时间生产每个区块并传输到其他节点进行验证，区块生产时间进一步分为两个可配置的参数：

• 最大处理间隔：将交易推入区块的时间窗口（当前设置为 200 ms）。
• 最短传播时间：将区块传播到其他节点的时间窗口（当前设置为 300 ms）。

所有尚未过期或由于先前验证失败而丢弃的松散交易都将保存在本地队列中，以便加入区块并与其他节点同步。在区块生产期间，计划交易由生产者按计划应用和验证，如果有效，则在处理间隔内推送到待处理区块。如果交易超出此窗口，则该交易将取消申请并重新安排纳入下一个区块。如果当前生产者没有更多的区块槽可用，则交易最终会被另一个生产节点（通过点对点协议）接收，然后推送到另一个区块。最后一个区块（来自生产者回合 Bp 区块）的最大处理间隔略短，以补偿移交给下一个生产者期间的网络延迟。在处理间隔结束时，待处理区块中不再允许进行交易，该区块在广播给其他区块生产者进行验证之前要经过最终确定步骤。

区块在生产过程中会经历不同的阶段：申请、完成、签名和提交。

5.2.1。应用封锁

Apply block 本质上是将生成节点收到并验证的交易推送到一个区块中。在内部，此步骤涉及区块标头和已签名的区块实例的创建和初始化。已签名的区块实例仅使用签名字段扩展区块标头。该字段最终拥有签署区块的制作人的签名。此外，EOS的最新更改允许包含多个签名，这些签名存储在标题扩展字段中。

5.2.2。完成区块

生成的区块需要经过最终确定才能签名、提交、转发和验证。在完成过程中，将计算区块头中加密验证所需的任何字段，并将其存储在区块中。这包括为操作收据列表和推送到区块的交易收据列表生成默克尔树根哈希。

5.2.3。标志方块

在交易被推入区块并完成区块后，区块就可以由生产者签署了。这涉及根据区块头的序列化内容计算签名摘要，其中包括区块中包含的交易收据。使用生产者的私钥对区块进行签名后，签名摘要将添加到已签名的区块实例中。这样就完成了区块签名。

5.2.4。提交区块

区块签名后，将提交到本地链。这会将区块推送到可逆区块数据库（参见 网络对等协议：2.2.3。分叉数据库）。这使得该区块可用于与其他节点同步以进行验证（请参阅 网络对等协议 了解有关区块同步的更多信息）。

5.3。区块验证

区块验证是在 EOS 区块链内达成共识所必需的基本操作。在区块验证期间，生产者会收到来自其他对等方的传入区块，并确认每个区块中包含的交易。区块验证就是要在活跃生产者中达到足够的法定人数，以达成共识：

• 区块及其包含的交易的完整性。
• 每个区块内交易的确定性、时间顺序。

验证区块的第一步从节点收到区块时开始。此时，对该区块进行了一些安全检查。如果该区块没有链接到已知的区块，或者它与节点已经接收和处理的任何区块的区块 ID 相匹配，则该区块将被丢弃。如果区块是新的，则将其推送到链控制器进行处理。

5.3.1。推方块

当链控制器收到区块时，软件必须确定在本地链中将区块添加到何处。fork 数据库（简称 Fork DB）用于此目的。fork 数据库包含所有带有可逆区块的分支，这些分支已收到但尚未完成。为此，执行了以下步骤：

1.向 fork 数据库添加区块。 2.如果将方块添加到包含当前 head block 的主分支中，则应用方块（请参阅 5.2.1。应用封锁）；或 3.如果必须将区块添加到不同的分支，那么：

1. 如果与当前主分支相比，该分支现在成为首选分支：将所有块倒带到最近的共同祖先（并在进程中回滚数据库状态），重新应用不同分支中的所有块，添加新块并应用它。该分支现在变成了新的主分支。
2. 否则：将新区块添加到 fork 数据库中的该分支，但什么都不做。

为了将区块添加到 fork 数据库，必须进行一些区块验证。在向 fork 数据库添加区块之前，必须始终完成区块头验证。而且，如果必须应用区块，则必须对区块内的交易进行一些验证。交易的验证程度取决于 nodeos 配置的验证模式。支持两种区块验证模式：完全验证（默认模式）和轻度验证。

5.3.2。全面验证

在完全验证模式下，应用的每笔交易都经过全面验证。这包括验证交易的签名和检查授权。

5.3.3。灯光验证

在轻量级验证模式下，由受信任的生产者签名的区块（可以在每个节点本地配置）可以跳过在完全验证期间完成的部分交易验证。例如，跳过签名验证，所有声称的操作授权都被假定为有效。

5.4。区块终结性

区块最终确定是EOS共识的最终结果。这是在绝大多数活跃生产者根据共识规则验证区块之后实现的（见 3.1。第 1 层：原生共识 (abFT)）。达到终结状态的区块将永久记录在区块链中，无法撤消。在这方面，链中最后一个不可逆区块 (LIB) 是指最近成为最终区块的区块。因此，从那时起，区块链上记录的交易就无法被撤销、篡改或删除。

5.4.1。终结的目标

最终的要点是让用户相信，在LIB区块之前和之前应用的交易无法修改、回滚或删除。无论哪个分支是最长的分支，LIB 区块也可用于让活动节点快速高效地确定要从哪个分支进行构建。这是因为给定的分支在不包含最新的 LIB 的情况下可能会更长，在这种情况下，必须选择一个包含最新 LIB 的较短分支。

5.4.2。EOS 终局性

目前，根据上述 EOS 共识规则（见 3.1。第 1 层：原生共识 (abFT)），每个拟议的 LIB 区块都需要两轮计划的 BP 验证才能成为最终版本。由于需要绝大多数2/3+1 Bps才能在EOS主网内达成共识（占总共21个Bp中的15个基点），因此每个拟议的LIB区块至少在最终版本中都将成为最终的 3 分钟 (180 秒），根据以下计算：

变量	值
Tp：每个制作人的制作时间	Tp = 0.5 (s/block) x 12 (blocks/producer) ⇒ Tp = 6 (s/producer) (\ *)
SP：绝大多数制作人	SP = int [2/3 * P（制作人）] + 1 ⇒ [P=21] SP = int [2/3 * 21（制片人）] + 1 = 14 + 1（制片人）⇒ SP = 15（制片人）
CR：确认回合	CR = 2（回合）(\ \ )
FT：Finality time	FT = SP x Tp（每轮）x CR（回合）⇒ [SP=15，Tp=6，CR=2] FT = 15（制作人）x 6（每轮）x 2（回合）⇒ FT = 180（s）= 3（分钟）

(\ *)：来自章节 4.2.2。生产默认值。 (\ \ )：验证提议的 LIB 区块所需的时间表轮数。