数据
Header
即以太坊协议所定义的Header对象。
Block
一个区块由两部分数据组成：
区块头BlockBody；区块体又由两部分内容组成：TransactionsUncles
BlockBody
就是一个区块中的事务和叔块信息的集合。
事务
即以太坊协议所定义的Transaction对象。
事务的构建
创建一条完全签名的事务的过程：
必须知道发起事务的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服务器请求数据的节点。
节点行为
Gossip
事务广播
P2P网络的功能，帮助分发新的事务到网络中的所有节点依赖于节点能够访问ETHDevP2PProtocol或者LESDevP2PProtocol依赖于执行事务验证的能力来防止对节点的DoS攻击而验证事务是计算密集型的区块广播广播最新的区块依赖于区块验证的能力历史数据检索
检索区块头根据哈希根据区块号可批请求，所请求内容必须是连续的，或者其前后之间有一致的间隔检索区块体所得数据需要根据Header.transactions_root和Header.uncles_root来验证检索收据根据区块分批检索所得数据需要根据Header.receipts_root来验证状态检索
根据哈希值来检索单个状态树节点在未来的协议中有可能会移除，因为这种检索机制与flatdatabaselayout有冲突
追随区块链
依赖于节点能访问区块广播网络依赖于具有从全体区块头中获得的近期区块头依赖于执行区块验证的能力来防止DoS攻击事务验证
验证事务需要：有能力执行ecrecover操作来确定发送者确认该事务的nonce正是该发起事务的账户的下一个nonce确认该账户的余额足以支付该事务的gas需要了解EVM的规则来计算事务的gas值区块验证
区块验证包含下述事项中的所有内容：检查工作量证明的seal计算密集型比较同一高度上其它竞争区块的挖矿总难度执行交易，以验证Header.state_root的正确性需要区块执行能力计算密集型主链索引
主链区块索引
把区块号映射为该高度的主链区块的哈希值需要从全部区块头中构建每100万个区块，存储映射需占用61MB区块号需要32字节区块哈希值也要32字节可以使用更高效的变长编码方法来减少长度每个条目需要64bytes截至2021年1月29日，主链区块索引总共占用约600MB的空间只能够通过验证所得区块哈希是否等于该高度上已知主链的区块哈希值来证明如果能为协议引入区块头累加器的话，证明效率可以更高
主链事务索引
把事务的哈希值映射成该事务所在主链区块的哈希值，以及该事务在该块内的索引值。需要从历史区块体中构建截至2021年1月29日，总共有10亿笔历史事务每个条目都需要占用70字节可以使用变长编码方法来稍微减少长度事务哈希值32字节主链区块哈希值32字节事务索引4字节截至2021年1月29日，这些索引总共占用65GB空间可以使用根据Header.transactions_root生成的默克尔证据来证明
区块头累加器
一类能让我们高效证明某个区块头来自主链的机制。基于https://ethresear.ch/t/double-batched-merkle-log-accumulator/571
同步
历史同步
区块头同步即一个节点追赶区块链的顶端时所用的进程。基于不同的安全等级，有几种同步方法“完全验证从创世块起下载全体区块头检查点式下载法使用一个自己信任的较近区块的区块头，并从该区块头开始追及区块链追随HEAD只需追随最新区块头，就可以相当有自信。区块链越长，攻击者要制造伪链所需付出的代价就越大当前，只有掌握了全体区块头，才能够任意地验证其他历史数据。区块头累加器可以改善这个状态，使得一个客户端可以把检查点设在区块链顶端，而仍然能够验证历史数据。区块同步客户端用来pull历史事务和叔块信息的进程。验证这些数据需要先有全体区块头，然后根据Header.transactions_root和Header.uncles_root来检查收据同步不执行FullSync的客户端往往需要通过ETHDevP2p协议来取得历史收据验证这些数据需要先有全体区块头，然后根据Header.receipts_root和来检查
状态同步
节点获得近期状态完整副本的机制。FullSync下载所有历史区块并按顺序执行这些区块。最简单的同步方法计算量非常大需要区块头同步需要区块同步快速同步下载全部历史区块，以及近期状态数据的副本使用了一个安全假设：从历史区块中得到的状态根都是正确的要求历史同步会给提供这些状态数据的节点造成很大的负担FlatDtatabaseLayout不容易满足快速同步的要求SnapSync下载全部历史区块以及近期状态数据的副本使用了一个安全假设：从历史区块中得到的状态根都是正确的要求历史同步非常适合FlatDtatabaseLayout带宽、硬盘读写和耗费时间都有指数级节省StatelessSync这个术语并不常用，其定义也可能随时调整不像其它状态同步方法，这一方法最终无法使节点获得近期状态数据的完整副本。就其自身而言，其用法是免去维护状态数据本地副本之需、仍能验证区块；或者，它可以与其他同步方法结合，从而能即时验证区块，然后慢慢在本地构建出可访问的完整状态数据。需要区块广播需要区块见证数据BeamSync光子同步本质上就是一种无状态同步，但不要求网络提供区块见证数据。相反，客户端是按需从网络中请求所需的状态需要区块广播需要按需状态检索Accesslist的可得性大大提高了这种方法的效率OnDemandStateRetrieval
即从网络中检索任意状态元素的能力。GetNodeDataETHDevP2P协议会暴露信息对GetNodeData/NodeData，允许检索任意状态。此消息格式可能会被弃用。基于DHT的状态网络一种设想：我们可以让状态分散在网络中的所有节点中，并使这些数据能够按需被发现及检索到。
执行
挖矿
要求节点能够：访问待打包事务池运行EVM
AccessList
在某些形式的EVM执行过程中会触及的账户和合约存储位置的列表
StateAccessPatterns
StaticStateAccessEVM执行在某些时候会具备的一种属性：调用者可以准确地预知该次执行会触及哪些状态DynamicStateAccessEVM执行在某些时候会具备的一种属性：调用者无法准确地预知到底会触及哪些状态区块执行
需要EVM执行就是执行给定区块中所有事务的过程计算密集型
EVM执行
举要EVM的某种实现要求能够访问该次执行所触及的状态可以使用近期状态来实现也可使用区块见证数据来实现
账户管理
管理用于签署事务的私钥账户一般会存储在一个Keyfile里
密钥文件
一种加密的存储格式，用于存储私钥Eth2BLSKeystore规范：https://eips.ethereum.org/EIPS/eip-2335Eth1Keystore规范：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
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。