干货 | 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 -
区块号需要 32 字节 -
区块哈希值也要 32 字节 -
可以使用更高效的变长编码方法来减少长度 -
每个条目需要 64 bytes(字节) -
截至 2021 年 1 月 29 日,主链区块索引总共占用约 600 MB 的空间 -
只能够通过验证所得区块哈希是否等于该高度上已知主链的区块哈希值来证明 -
如果能为协议引入区块头累加器的话,证明效率可以更高
主链事务索引
-
需要从历史区块体中构建 -
截至 2021 年 1月 29 日,总共有 10 亿笔历史事务 -
每个条目都需要占用 70 字节 -
可以使用变长编码方法来稍微减少长度 -
事务哈希值 32 字节 -
主链区块哈希值 32 字节 -
事务索引 4 字节 -
截至 2021 年 1 月 29 日,这些索引总共占用 65 GB 空间 -
可以使用根据 Header.transactions_root
生成的默克尔证据来证明
区块头累加器
同步
历史同步
-
完全验证 -
从创世块起下载全体区块头 -
检查点式下载法 -
使用一个自己信任的较近区块的区块头,并从该区块头开始追及区块链 -
追随 HEAD(区块链最新区块) -
只需追随最新区块头,就可以相当有自信(自己同步得到的是主链而非伪链)。区块链越长,攻击者要制造伪链所需付出的代价就越大
-
验证这些数据需要先有全体区块头,然后根据 Header.transactions_root
和Header.uncles_root
来检查
-
验证这些数据需要先有全体区块头,然后根据 Header.receipts_root
和来检查
状态同步
-
最简单的同步方法 -
计算量非常大 -
需要区块头同步 -
需要区块同步
-
使用了一个安全假设:从历史区块中得到的状态根都是正确的 -
要求历史同步 -
会给提供这些状态数据的节点造成很大的负担 -
Flat Dtatabase Layout 不容易满足快速同步的要求
-
使用了一个安全假设:从历史区块中得到的状态根都是正确的 -
要求历史同步 -
非常适合 Flat Dtatabase Layout -
带宽、硬盘读写和耗费时间都有指数级节省
这个术语并不常用,其定义也可能随时调整
-
需要区块广播 -
需要区块见证数据
-
需要区块广播 -
需要按需状态检索 -
Access list(访问列表)的可得性大大提高了这种方法的效率
On Demand State Retrieval(按需状态检索)
GetNodeData
ETH
DevP2P 协议会暴露信息对 GetNodeData/NodeData
,允许检索任意状态。此消息格式可能会被弃用。执行
挖矿
-
访问待打包事务池 -
运行 EVM
Access List(访问列表)
State Access Patterns(状态访问模式)
区块执行
-
需要 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(文内有许多超链接,可点击左下 ”阅读原文“ 从 EthFans 网站上获取)
原文链接:
https://github.com/ethereum/stateless-ethereum-specs/wiki/Glossary
作者: Piper Merriam
链得得仅提供相关信息展示,不构成任何投资建议
评论(0)
Oh! no
您是否确认要删除该条评论吗?