原标题：干货 | Eth1.x 术语表（上）

目录

• 数据

• 区块链历史

• 见证数据

• 节点类型

数据

Header（区块头）

即以太坊协议所定义的Header对象。（译者注：区块头包含一个区块的元信息）

Block（区块）

一个区块由两部分数据组成：

• 区块头

• Block Body（区块体）；区块体又由两部分内容组成：

• Transactions（交易，事务）

• Uncles（叔块信息）

Block Body（区块体）

就是一个区块中的事务和叔块信息的集合。

事务

即以太坊协议所定义的Transaction对象。（译者注：事务可视为触发以太坊协议状态变更的操作的基本单元）

事务的构建

创建一条完全签名的事务的过程：

• 必须知道发起事务的 Account（账户）的nonce（流水号）。

• 一般来说需要使用eth_estimateGas方法来确定该事务需要使用的gas消耗量。

• 需要该账户的私钥，用于生成数字签名。

叔块信息

即被该区块视作叔块的区块的区块头。（译者注：对于任一区块来说，叔块指的是那些上溯 7 代及以内、并非其祖先区块的有效区块；一个区块可标记两个叔块；标记叔块可使区块挖出者获得额外的 “侄块奖励”，也会使叔块挖出者获得奖励，奖励大小随叔块与侄块之间的代际距离递减；叔块内的所有事务视作没有上链，除非另一些区块中包含了这些事务，否则都回到待打包事务的内存池中）

区块链历史

Header Chain（全部区块头）

所有历史区块的区块头的集合

• 截至 2021 年 1 月 29 日，约有 1100 万个区块头

• 截至 2021 年 1 月 29 日，全体区块头约占用 5 GB 的存储空间

• 是验证其余大部分链数据所必需的数据

• 如果使用 Header Accumulator（区块头累加器），我们将能证明某个区块头存在于主链上

Block Body History（区块体历史）

所有由事务和叔块信息所组成的历史区块的集合

• 截至 2021 年 1 月 29 日，约有 1100 万个区块体

• 截至 2021 年 1 月 29 日，所有区块体需占用约 120 GB 的存储空间

Receipt History（收据历史）

由历史事务所产生的所有收据的集合

• 截至 2021 年 1 月 29 日，约有 10 亿条收据

• 截至 2021 年 1 月 29 日，所有收据需占用约 60 GB 存储

State（状态）

所有账户及 contract storage（合约存储项）的集合

账户

由Header.state_root所代表的主状态树的一部分

• 字段：balance/nonce/state_root/code_hash

合约存储项

每个账户的Account.state_root标识的单个存储值

• 所有数据都以0 - 2^^256-1 范围内的整数作为键 （该整数也被当作存储槽的序号）

Contract Code（合约代码）

合约代码仅使用Account.code_hash来指代；并非状态的显式部分。

Archive State（归档状态）

所有历史状态的集合。详见 Archive Node（归档节点）

• 使用 Naive Database Layout，存储归档状态需占用约 7 TB 的存储

• 使用一些基于 Flat Database Layout 的高级技巧，Trube Geth 客户端使用约 800 GB 实现了归档状态存储

Recent State（近期状态）

指作为 近期 状态根一部分的状态。

• “近期” 一般来说是 128～256 个区块内

维护这一数据需要某种形式的垃圾回收技术，以清除不再是近期状态一部分的状态对象

Cold State（冷状态）

指的是很长一段时间没有被触及（访问 及 修改）的状态对象

Database Layouts（数据库布局）

Naive Database Layout

该数据库实现将所有的状态对象都存储为单个的树节点，通过节点哈希值来访问

• 导致性能低下以及高硬盘读写开销

• 相对易于理解和实现

• 此方案下的垃圾回收算法更加复杂

Flat Database Layout

将所有的状态对象都存储为树的路径，某种程度上有点类似于 键值对 存储

• 性能更高、硬盘开销更小

• 更难以理解和实现

Witness（见证数据）

即以一种可验证的形式存储的状态数据

Block Witness（区块见证数据）

一种类型的见证数据，提供了执行区块所需的所有状态数据

Transaction Witness（事务见证数据）

一种类型的见证数据，提供了一笔事务的 EVM 执行所需的所有状态数据

Node Type（节点类型）

Full Node（全节点）

指一个满足了下列要求的节点：

• 存储了所有的区块头

• 存储了全部区块体历史

• 存储了全部收据历史

• 存储着近期状态

• 维护者一个主链区块索引系统

• 维护者一个主链事务索引系统

• 参与ETHDevP2P 协议（译者注：该协议用于在以太坊网络的对等节点之间传输数据，如区块、事务、状态数据等；以太坊交易的广播就是靠这个协议实现的）

Archive Node（归档节点）

其他特点与全节点都一样，但归档节点会存储全部归档状态。一般都需要执行 Full Sync（全量同步）。

LES Light Node（LES 轻节点）

连接到LESDevP2P 协议的客户端，意图是跟上区块链并暴露 JSON-RPC API。

此类客户端依赖于链接到至少一个 LES Server（LES 服务器）来满足对数据的需求。

Stateless Node（无状态节点）

一个仍在计划中的客户端类型，如果能够实现区块见证数据的话，就可使之成真。

• 此类客户端不需要状态数据来执行区块，因为它们可以使用见证数据

（TODO：还需增加对其他功能所需技术的描述）

Ultra Light Node（极轻节点）

增加这个术语只是为了区分当前类型的轻节点和一种新类型的轻节点 —— Piper

一种仅暴露 JSO-RPC API 的节点。

ETHDevP2P 协议

DevP2P 网络中所用的点对点协议，是所有主网客户端的基石

作为这个点对点网络中的一部分，一个节点需要：

• 参与 Transaction Gossip（事务广播）

• 参与 Block Gossip（区块广播）

• 拥有近期状态

• 拥有完整的区块链历史

LESDevP2P Protocol

作为轻客户端基础的 DevP2P 网络所用的点对点协议

LES 服务器

参与 LES 网络、向 LES 客户端提供数据的节点。

在这个网络中成为一个服务器需要：

• 完整的近期状态

• 全部区块链历史

• 主链 区块索引/事务索引

• 有能力参与事务广播

• 有能力参与区块广播

LES 客户端

参与 LES 网络、向 LES 服务器请求数据的节点。

（未完）

原文链接: https://github.com/ethereum/stateless-ethereum-specs/wiki/Glossary
作者: Piper Merriam
翻译: 阿剑