ABIC++

ABCI++包含了哪些方法？ 共识执行方法 InitChain InitChain方法在链刚启动的时候被调用，存在一个叫genesis的文件，里面包含了一些初始信息，比如validator列表。 PrepareProposal PrepareProposal和别的方法一样都是从Cometbft发起调用，根据推举的算法找出一个提案者，提案者是validator中的一员，cometbft负责从mempool中收集到交易信息，组建了名叫RequestPrepareProposal的信息，发送给提案者。提案者收到request之后会对收到的信息做一些优化。比如进行排序。 ProcessProposal 和上诉的PrepareProposal的执行者有所不同。processproposal对提案者的内容进行校验这个执行者是所有参与的validator。validator对内容进行投票，赞成或者反对。需要注意的时候这个时候的ProcessProposal的逻辑必须是确定性的。什么叫确定性呢？就是需要对于相同的输入，validator的输出应该是一致的。不能够在validator中有所区别，这个可能比较难以理解。 ExtendVote ExtendVote方法可以理解为，每个validator自己的提案信息。比如我们常见的跨链的信息，local validator从一个relayer中拿到跨链的信息，组成一个vote extension的内容。这个信息逻辑上是允许不确定的。可能每个validator会拿到不一致的信息。 VerifyVoteExtension 它允许验证者验证附加在 precommit 消息中的 vote extension 数据。如果验证失败，整个 precommit 消息将被视为无效，并被共识算法忽略。这会对（liveness）产生负面影响 —— 也就是说，如果正确的验证者反复无法验证 vote extension，共识算法可能无法最终确认一个区块，即便有足够数量（超过 2/3）的验证者为该区块发送了 precommit 投票。因此，VerifyVoteExtension 的实现必须格外谨慎。一个通用规则是：如果应用（Application）检测到无效的 vote extension，应该在 ResponseVerifyVoteExtension 中接受它，并在自身逻辑中忽略它。CometBFT 会在接收到某个高度的 precommit 消息（其中可能包含 vote extension）时调用此函数。但在该高度已完成、只是等待更多 precommit 投票的阶段，收到的 precommit 消息不会触发调用。VerifyVoteExtension 中的逻辑必须是确定性的 FinalizeBlock 它会将一个已确定（decided）的区块传递给应用（Application）。应用必须以确定性的方式执行该区块中的所有交易，并相应地更新其状态。 通过 ResponseFinalizeBlock 中的相关参数返回的对区块及交易结果的加密承诺（cryptographic commitments），将被包含在下一个区块的区块头中。 CometBFT 会在一个新区块被确定时调用该方法。当 CometBFT 的共识算法调用 FinalizeBlock 处理某个区块时，它能够保证至少有一个非拜占庭的验证者已经对该区块执行过 ProcessProposal 非拜占庭的验证者的意思是诚实的验证者。 Commit 指示应用程序（Application）持久化其状态。这是 CometBFT 崩溃恢复机制（crash-recovery）的核心部分，确保在系统恢复后，CometBFT 与应用之间的状态保持同步。 CometBFT 会在它自己将 ResponseFinalizeBlock 返回的数据持久化之后调用此方法。此时，应用程序可以丢弃除该区块交易执行结果之外的所有状态或数据。 Mempool方法 checkTx 状态同步方法 ​- ListSnapshots​ ​- OfferSnapshot​ ​- LoadSnapshotChunk​ ​ -ApplySnapshotChunk ...