干货 | Eth1.x 术语表：节点的各种行为、同步方法

点击阅读前文《 Eth1.x 术语表（上） 》

节点行为

Gossip

事务广播

• P2P 网络的功能，帮助分发 新的 事务到网络中的所有节点
• 依赖于节点能够访问 ETH DevP2P Protocol 或者 LES DevP2P Protocol
• 依赖于执行事务验证的能力来防止对节点的 DoS 攻击
• 而验证事务是计算密集型的（译者注：计算密集是重点吗？还是具备相关状态数据的需求才是重点？）

区块广播

• 广播最新的区块
• 依赖于区块验证的能力

历史数据检索

• 检索区块头
• 根据哈希
• 根据区块号
• 可批请求，所请求内容必须是连续的，或者其前后之间有一致的间隔
• 检索区块体
• 所得数据需要根据 Header.transactions_root 和 Header.uncles_root 来验证（译者注：即依据本地已有的区块头数据来验证相应区块体的完整性）
• 检索收据
• 根据区块分批检索
• 所得数据需要根据 Header.receipts_root 来验证

状态检索

• 根据哈希值来检索单个状态树节点
• 在未来的协议中有可能会移除，因为这种检索机制与 flat database layout 有冲突

追随区块链

• 依赖于节点能访问区块广播网络
• 依赖于具有从全体区块头中获得的近期区块头
• 依赖于执行区块验证的能力来防止 DoS 攻击

事务验证

验证事务需要：

• 有能力执行 ecrecover 操作来确定发送者（译者注：即从签名数据中恢复出发送者的地址）
• 确认该事务的 nonce 正是 该发起事务的账户的下一个 nonce
• 确认该账户的余额足以支付该事务的 gas（译者注：该检查的方法应为 余额 > 该交易指定的 gas price * gas limit ）
• 需要了解 EVM 的规则来计算事务的 gas 值

区块验证

区块验证包含下述事项中的所有内容：

• 检查工作量证明的 seal
• 计算密集型
• 比较同一高度上其它竞争区块的挖矿总难度
• 执行交易，以验证 Header.state_root 的正确性
• 需要区块执行能力
• 计算密集型

主链索引

主链区块索引

把区块号映射为该高度的主链区块的哈希值

• 需要从全部区块头中构建
• 每 100 万个区块，存储映射需占用 61 MB
• 每个条目需要 64 bytes（字节）
• 区块号需要 32 字节
• 可以使用更高效的变长编码方法来减少长度
• 区块哈希值也要 32 字节
• 截至 2021 年 1 月 29 日，主链区块索引总共占用约 600 MB 的空间
• 只能够通过验证所得区块哈希是否等于该高度上已知主链的区块哈希值来证明
• 如果能为协议引入区块头累加器的话，证明效率可以更高

主链事务索引

把事务的哈希值映射成该事务所在主链区块的哈希值，以及该事务在该块内的索引值。

• 需要从历史区块体中构建
• 截至 2021 年 1月 29 日，总共有 10 亿笔历史事务
• 每个条目都需要占用 70 字节
• 事务哈希值 32 字节
• 主链区块哈希值 32 字节
• 事务索引 4 字节
• 可以使用变长编码方法来稍微减少长度
• 截至 2021 年 1 月 29 日，这些索引总共占用 65 GB 空间
• 可以使用根据 Header.transactions_root 生成的默克尔证据来证明

区块头累加器

一类能让我们高效证明某个区块头来自主链的机制。基于 https://ethresear.ch/t/double-batched-merkle-log-accumulator/571

同步

历史同步

区块头同步

即一个节点追赶区块链的顶端时所用的进程。基于不同的安全等级，有几种同步方法“

• 完全验证
• 从创世块起下载全体区块头
• 检查点式下载法
• 使用一个自己信任的较近区块的区块头，并从该区块头开始追及区块链
• 追随 HEAD（区块链最新区块）
• 只需追随最新区块头，就可以相当有自信（自己同步得到的是主链而非伪链）。区块链越长，攻击者要制造伪链所需付出的代价就越大

当前，只有掌握了全体区块头，才能够任意地验证其他历史数据。区块头累加器可以改善这个状态，使得一个客户端可以把检查点设在区块链顶端，而仍然能够验证历史数据。

区块同步

客户端用来 pull（拉取）历史事务和叔块信息的进程。

• 验证这些数据需要先有全体区块头，然后根据 Header.transactions_root 和 Header.uncles_root 来检查

收据同步

不执行 Full Sync（完全同步）的客户端往往需要通过 ETH DevP2p 协议来取得历史收据

• 验证这些数据需要先有全体区块头，然后根据 Header.receipts_root 和来检查

状态同步

节点获得近期状态完整副本的机制。

Full Sync（完全同步）

下载所有历史区块并按顺序执行这些区块。

• 最简单的同步方法
• 计算量非常大
• 需要区块头同步
• 需要区块同步

快速同步

下载全部历史区块，以及近期状态数据的副本

• 使用了一个安全假设：从历史区块中得到的状态根都是正确的
• 要求历史同步
• 会给提供这些状态数据的节点造成很大的负担
• Flat Dtatabase Layout 不容易满足快速同步的要求

Snap Sync（快照同步）

下载全部历史区块以及近期状态数据的副本

• 使用了一个安全假设：从历史区块中得到的状态根都是正确的
• 要求历史同步
• 非常适合 Flat Dtatabase Layout
• 带宽、硬盘读写和耗费时间都有指数级节省

Stateless Sync（无状态同步）

这个术语并不常用，其定义也可能随时调整

不像其它状态同步方法，这一方法最终无法使节点获得近期状态数据的完整副本。就其自身而言，其用法是免去维护状态数据本地副本之需、仍能验证区块；或者，它可以与其他同步方法结合，从而能即时验证区块，然后慢慢在本地构建出可访问的完整状态数据。

• 需要区块广播
• 需要区块见证数据

Beam Sync（光子同步）

光子同步本质上就是一种无状态同步，但不要求网络提供区块见证数据。相反，客户端是按需从网络中请求所需的状态

• 需要区块广播
• 需要按需状态检索
• Access list（访问列表）的可得性大大提高了这种方法的效率

On Demand State Retrieval（按需状态检索）

即从网络中检索任意状态元素的能力。

GetNodeData

ETH DevP2P 协议 会暴露信息对 GetNodeData/NodeData ，允许检索任意状态。此消息格式可能会被弃用。

基于 DHT 的状态网络

一种设想：我们可以让状态分散在网络中的所有节点中，并使这些数据能够按需被发现及检索到。

执行

挖矿

要求节点能够：

• 访问待打包事务池
• 运行 EVM

Access List（访问列表）

在某些形式的 EVM 执行过程中会触及的账户和合约存储位置的列表

State Access Patterns（状态访问模式）

Static State Access（静态访问模式，SSA）

EVM 执行在某些时候会具备的一种属性：调用者可以准确地预知该次执行会触及哪些状态

Dynamic State Access（动态访问模式，DSA）

EVM 执行在某些时候会具备的一种属性：调用者无法准确地预知到底会触及哪些状态

区块执行

• 需要 EVM 执行
• 就是执行给定区块中所有事务的过程
• 计算密集型

EVM 执行

• 举要 EVM 的某种实现
• 要求能够访问该次执行所触及的状态
• 可以使用近期状态来实现
• 也可使用区块见证数据来实现

账户管理

• 管理用于签署事务的私钥
• 账户一般会存储在一个 Keyfile （密钥文件）里

密钥文件

一种加密的存储格式，用于存储私钥

• Eth2 BLS Keystore 规范： https://eips.ethereum.org/EIPS/eip-2335
• Eth1 Keystore 规范： https://github.com/ethereum/wiki/wiki/Web3-Secret-Storage-Definition

解密一般来说依赖于一些密码学元件，如： keccak 、 scrypt 、 pbkdf2 和 ECC/BLS12-381

（未完）

原文链接:

https://github.com/ethereum/stateless-ethereum-specs/wiki/Glossary

作者: Piper Merriam

翻译: 阿剑