区块如何工作

为了保存交易历史，区块被严格排序（创建的每个新区块都包含一个其父块的引用），区块内的交易也严格排序。 除极少数情况外，在任何特定时间，网络上的所有参与者都同意区块的确切数目和历史， 并且正在努力将当前的活动交易请求分批到下一个区块。
某位验证者在网络上构建完区块后，区块将传播到整个网络；所有节点都将该区块添加至其区块链的末尾，然后挑选新的验证者来创建下一个区块。 目前，确切的区块构建过程和提交/共识过程由以太坊的“权益证明”协议规定。

权益证明协议

权益证明是指：

• 网络，因为如果发生不诚实活动且可以证实，部分甚至全部质押金额将被销毁。
• 在每个时隙（12 秒的时间间隔）中，会随机选择一个验证者作为区块提议者。 他们将交易打包并执行，然后确定一个新的“状态”。 他们将这些信息包装到一个区块中并传送给其他验证者。
• 其他获悉新区块的验证者再次执行区块中包含的交易，确定他们同意对全局状态提出的修改。 假设该区块是有效的，验证者就将该区块添加进各自的数据库。
• 如果验证者获悉在同一时隙内有两个冲突区块，他们会使用自己的分叉选择算法选择获得最多质押以太币支持的那一个区块。

区块包含什么？

一个区块中包含很多信息。 区块的最高层包含以下字段：
1.slot：区块所属的时隙
2.proposer_index：提出区块的验证者的 ID
3.parent_root：前一个区块的哈希
4.state_root：状态对象的根哈希
5.body：包含一些字段的对象，定义如下:
还有一个 execution_payload_header，包含有关执行数据的重要摘要信息。 这些数据结构如下组织：
execution_payload_header 包含以下字段：
1.parent_hash：父块的哈希
2.fee_recipient：接收交易费的帐户地址
3.state_root：应用此区块中的变化后全局状态的根哈希
4.receipts_root：交易收据树的哈希
5.logs_bloom：包含事件日志的数据结构
6.prev_randao：随机选择验证者时使用的值
7.block_number：当前区块的编号
8.gas_limit：此区块允许使用的最大燃料量
9.gas_used：此区块实际使用的燃料量
10.timestamp：出块时间
11.extra_data：作为原始字节的任意附加数据
12.base_fee_per_gas：基础费的值
13.block_hash：执行区块的哈希
14.transactions_root：有效载荷中交易的根哈希

15.execution_payload 本身包含以下字段（这些与 header 字段相同，只是它包含的不是交易的根哈希，而是实际的交易列表）：
1.parent_hash：父块的哈希
2.fee_recipient：接收交易费的帐户地址
3.state_root：应用此区块中的变化后全局状态的根哈希
4.receipts_root：交易收据树的哈希
5.logs_bloom：包含事件日志的数据结构
6.prev_randao：随机选择验证者时使用的值
7.block_number：当前区块的编号
8.gas_limit：此区块允许使用的最大燃料量
9.gas_used：此区块实际使用的燃料量
10.timestamp：出块时间
11.extra_data：作为原始字节的任意附加数据
12.base_fee_per_gas：基础费的值
13.block_hash：执行区块的哈希
14.transactions：要执行交易的列表

出块时间

出块时间是指两个区块之间的时间间隔。 在以太坊中，时间划分为每 12 秒一个单位，称为“时隙”。 在每个时隙内，选择一个单独的验证者提议区块。 假设所有验证者都在线且完全正常运行，则每个时隙内都会有一个区块产生，意味着出块时间是 12 秒。 但是，偶尔验证者在被要求提议区块时不在线，导致有时候一些时隙是空的。 这与基于工作量证明的系统不同。在工作量证明系统中，出块时间是带有概率性的，并由挖矿难度调节

来自 https://ethereum.org/zh/developers/docs/blocks/

本文作者：硝基苯
本文链接：https://www.c6sec.com/index.php/archives/817/
最后修改时间：2023-06-02 16:55:45
本站未注明转载的文章均为原创，并采用 CC BY-NC-SA 4.0 授权协议，转载请注明来源，谢谢！