目录
数据
区块链历史
状态
见证数据
节点类型
P2P协议
数据
Header
即以太坊协议所定义的Header对象。
Block
一个区块由两部分数据组成：
区块头
BlockBody；区块体又由两部分内容组成：
Transactions
Uncles
BlockBody
就是一个区块中的事务和叔块信息的集合。
事务
即以太坊协议所定义的Transaction对象。
事务的构建
创建一条完全签名的事务的过程：
Ripple律师：正在进行的Coinbase与SEC的诉讼很重要:金色财经报道，在关于Ripple和美国证券交易委员会 (SEC)之间可能达成和解的猜测中，代表众多XRP代币持有者的律师John Deaton概述了如果双方选择和解可能采取的步骤。
在谈到可能影响双方之间潜在和解的因素时， Deaton律师指出了正在进行的Coinbase与SEC诉讼的重要性。他解释说，如果Coinbase案件的法官批准交易所的驳回动议，则表明该交易所的代币销售不受美国证券法的约束，尽管加密货币质押方面仍然是法律程序的一部分。
Deaton解释成，Ripple和SEC能够在今年年底前达成和解的唯一方法是，Failla法官是否批准 Coinbase动议，驳回或部分批准该动议，如果驳回动议获得批准，美国证券交易委员会提起上诉的能力将受到相当大的限制，从而使和解成为一个合乎逻辑的选择。 即使在这种情况下可以上诉，该机构的权威也会受到削弱。[2023/9/3 13:14:42]
必须知道发起事务的Account的nonce。
一般来说需要使用eth_estimateGas方法来确定该事务需要使用的gas消耗量。
需要该账户的私钥，用于生成数字签名。
叔块信息
即被该区块视作叔块的区块的区块头。
区块链历史
HeaderChain
所有历史区块的区块头的集合
截至2021年1月29日，约有1100万个区块头
截至2021年1月29日，全体区块头约占用5GB的存储空间
是验证其余大部分链数据所必需的数据
如果使用HeaderAccumulator，我们将能证明某个区块头存在于主链上
BlockBodyHistory
所有由事务和叔块信息所组成的历史区块的集合
截至2021年1月29日，约有1100万个区块体
截至2021年1月29日，所有区块体需占用约120GB的存储空间
ReceiptHistory
由历史事务所产生的所有收据的集合
截至2021年1月29日，约有10亿条收据
截至2021年1月29日，所有收据需占用约60GB存储
State
所有账户及contractstorage的集合
账户
由Header.state_root所代表的主状态树的一部分
字段：balance/nonce/state_root/code_hash
合约存储项
每个账户的Account.state_root标识的单个存储值
所有数据都以0-2^^256-1范围内的整数作为键
ContractCode
合约代码仅使用Account.code_hash来指代；并非状态的显式部分。
ArchiveState
所有历史状态的集合。详见ArchiveNode
使用NaiveDatabaseLayout，存储归档状态需占用约7TB的存储
使用一些基于FlatDatabaseLayout的高级技巧，TrubeGeth客户端使用约800GB实现了归档状态存储
RecentState
指作为近期状态根一部分的状态。
“近期”一般来说是128～256个区块内
维护这一数据需要某种形式的垃圾回收技术，以清除不再是近期状态一部分的状态对象
ColdState
指的是很长一段时间没有被触及的状态对象
DatabaseLayouts
NaiveDatabaseLayout
该数据库实现将所有的状态对象都存储为单个的树节点，通过节点哈希值来访问
导致性能低下以及高硬盘读写开销
相对易于理解和实现
此方案下的垃圾回收算法更加复杂
FlatDatabaseLayout
将所有的状态对象都存储为树的路径，某种程度上有点类似于键值对存储
性能更高、硬盘开销更小
更难以理解和实现
Witness
即以一种可验证的形式存储的状态数据
BlockWitness
一种类型的见证数据，提供了执行区块所需的所有状态数据
TransactionWitness
一种类型的见证数据，提供了一笔事务的EVM执行所需的所有状态数据
NodeType
FullNode
指一个满足了下列要求的节点：
存储了所有的区块头
存储了全部区块体历史
存储了全部收据历史
存储着近期状态
维护者一个主链区块索引系统
维护者一个主链事务索引系统
参与ETHDevP2P协议
ArchiveNode
其他特点与全节点都一样，但归档节点会存储全部归档状态。一般都需要执行FullSync。
LESLightNode
连接到LESDevP2P协议的客户端，意图是跟上区块链并暴露JSON-RPCAPI。
此类客户端依赖于链接到至少一个LESServer来满足对数据的需求。
StatelessNode
一个仍在计划中的客户端类型，如果能够实现区块见证数据的话，就可使之成真。
此类客户端不需要状态数据来执行区块，因为它们可以使用见证数据
UltraLightNode
增加这个术语只是为了区分当前类型的轻节点和一种新类型的轻节点——Piper
一种仅暴露JSO-RPCAPI的节点。
P2P协议
ETHDevP2P协议
DevP2P网络中所用的点对点协议，是所有主网客户端的基石
作为这个点对点网络中的一部分，一个节点需要：
参与TransactionGossip
参与BlockGossip
拥有近期状态
拥有完整的区块链历史
LESDevP2P协议
作为轻客户端基础的DevP2P网络所用的点对点协议
LES服务器
参与LES网络、向LES客户端提供数据的节点。
在这个网络中成为一个服务器需要：
完整的近期状态
全部区块链历史
主链区块索引/事务索引
有能力参与事务广播
有能力参与区块广播
LES客户端
参与LES网络、向LES服务器请求数据的节点。
原文链接:https://github.com/ethereum/stateless-ethereum-specs/wiki/Glossary作者:PiperMerriam翻译:阿剑
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。