3.6 确认交易（Finalize）
当交易中的所有操作都被执行后，交易进入确认阶段。
这个阶段中，每个操作都会产生对应的操作收据。操作收据包括操作实例的哈希值，与分析相关的计数，操作的接收者账号信息。
3.6.1 交易收据
当所有的操作收据产生之后，交易收据最终会相应生成。交易收据被推送到签名块中。
交易收据包括交易执行状态，实际的cpu时间和net使用等数据。
具体字段：https://developers.eos.io/welcome/latest/protocol/transactions_protocol/#transaction_receipt-schema
3.6.2 延迟交易（Deferred Transaction）
延迟交易是处理区块链的一个副作用，所以它们的状态存储在链数据库中，而不是在一个块中（不理解）。
因此，不需要在交易收据中显式地包含它们的内容。所有同步节点都应该将延迟交易作为一种共识形式。
3.6.3延迟的用户交易（ Delayed User Transactions）
延迟的用户交易包含被推送到网络(在延迟计时器开始时)时打包的交易。
然而，与常规交易不同，它们的状态是“延迟”，常规交易的状态“被执行”，因此它们的执行和验证可以延迟。
稍后，当它们执行/失败/过期(在延迟计时器结束时)之后，它们只包含交易ID。
这是因为任何同步节点都有来自以前广播块的交易内容。
3.7 确认交易（Validate）
和3.4的Verify不同，为避免混淆，此处翻译成确认。
3.4的应该是事先核实，此处应该是最终确认。
在交易生命周期的不同阶段，都会被核实或者验证。
首先，在交易通过p2p网络被广播出去时
其次，当块被大多数BP确认时
然后，如果nodeos被配置成在重放时全校验的话，也有可能在区块链重放（replay）时。个人理解replay类似是一个新的节点从其他节点同步数据时，将所有交易再重新校验一遍。默认情况下，已经被记录的交易不会完成校验交易，因为这些数据都是可信的
3.7.1 确认过程
在块校验过程中，块中的所有交易会被重放，本地计算交易和操作的merkle树的根hash，和块头的hash值比较。
因此，如果交易被做了手脚，不仅merkle 树hash不会匹配，并且交易签名也会失败。
网友评论