干货 | Eth1.x 术语表（上）
事务广播
P2P 网络的功能，帮助分发 新的 事务到网络中的所有节点
依赖于节点能够访问 ETH DevP2P Protocol 或者 LES DevP2P Protocol
依赖于执行事务验证的能力来防止对节点的 DoS 攻击
而验证事务是计算密集型的（译者注：计算密集是重点吗？还是具备相关状态数据的需求才是重点？）
区块广播
广播最新的区块
依赖于区块验证的能力
检索区块头
根据哈希
根据区块号
可批请求，所请求内容必须是连续的，或者其前后之间有一致的间隔
检索区块体
所得数据需要根据 Header.transactions_root 和 Header.uncles_root 来验证（译者注：即依据本地已有的区块头数据来验证相应区块体的完整性）
检索收据
根据区块分批检索
所得数据需要根据 Header.receipts_root 来验证
根据哈希值来检索单个状态树节点
在未来的协议中有可能会移除，因为这种检索机制与 flat database layout 有冲突
依赖于节点能访问区块广播网络
依赖于具有从全体区块头中获得的近期区块头
依赖于执行区块验证的能力来防止 DoS 攻击
验证事务需要：
有能力执行 ecrecover 操作来确定发送者（译者注：即从签名数据中恢复出发送者的地址）
确认该事务的 nonce 正是 该发起事务的账户的下一个 nonce
BTC突破57100美元关口:火币全球站数据显示，BTC短线上涨，突破57100美元关口，现报57101.42美元，日内涨幅达到0.26%，行情波动较大，请做好风险控制。[2021/3/13 18:41:50]
确认该账户的余额足以支付该事务的 gas（译者注：该检查的方法应为 `余额 > 该交易指定的 gas price * gas limit）
需要了解 EVM 的规则来计算事务的 gas 值
区块验证包含下述事项中的所有内容：
检查工作量证明的 seal
比较同一高度上其它竞争区块的挖矿总难度
执行交易，以验证 Header.state_root 的正确性
需要区块执行能力
把区块号映射为该高度的主链区块的哈希值
需要从全部区块头中构建
每 100 万个区块，存储映射需占用 61 MB
区块号需要 32 字节
区块哈希值也要 32 字节
可以使用更高效的变长编码方法来减少长度
每个条目需要 64 bytes（字节）
截至 2021 年 1 月 29 日，主链区块索引总共占用约 600 MB 的空间
只能够通过验证所得区块哈希是否等于该高度上已知主链的区块哈希值来证明
如果能为协议引入区块头累加器的话，证明效率可以更高
把事务的哈希值映射成该事务所在主链区块的哈希值，以及该事务在该块内的索引值。
需要从历史区块体中构建
截至 2021 年 1月 29 日，总共有 10 亿笔历史事务
每个条目都需要占用 70 字节
可以使用变长编码方法来稍微减少长度
库币DeFi专区项目AMPL 24h涨幅超72.1%:据库币KuCoin交易所DeFi专区行情显示，AMPL 24h涨幅超72.1% 现报价1.145USDT。据悉Ampleforth将于9月10日开启第二轮挖矿计划Ampleforth Geyser Beehive 2，将提供总供应量的 1％的 AMPL 代币奖励池，持续 3 个月时间。AMPL是最早上线库币的DeFi项目之一，非小号数据显示，目前AMPL全球交易量中，库币占比42.26%，是AMPL最主要的交易所。[2020/9/10]
事务哈希值 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（访问列表）的可得性大大提高了这种方法的效率
即从网络中检索任意状态元素的能力。
GetNodeData
ETH DevP2P 协议会暴露信息对 GetNodeData/NodeData，允许检索任意状态。此消息格式可能会被弃用。
基于 DHT 的状态网络
一种设想：我们可以让状态分散在网络中的所有节点中，并使这些数据能够按需被发现及检索到。
要求节点能够：
访问待打包事务池
运行 EVM
在某些形式的 EVM 执行过程中会触及的账户和合约存储位置的列表
Static State Access（静态访问模式，SSA）
EVM 执行在某些时候会具备的一种属性：调用者可以准确地预知该次执行会触及哪些状态
Dynamic State Access（动态访问模式，DSA）
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
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。