共识是指网络决定哪些信息将被保留在区块链中的过程。在像区块链这样的系统中，用新信息扩展区块链的责任分布在整个网络的参与节点上。这些节点不能被假定为网络中的“诚实”节点，因此，网络中的“诚实”参与者必须合作，以将各个节点提出的信息进行选择性保留。有许多不同的方法可以实现分布式共识，我们将其称为共识机制。在我们的代码库中，我们建立了一个单一的接口，通过这个接口，共识机制通知协议的其余部分。通过这个接口，共识机制的各种实现可以在编译时交换出来，从而允许我们编写协议的其余部分而不依赖于所选择的共识机制。因此，我们可以将共识机制看作是某种东西，一旦定义，协议的其余部分就可以建立在它之上。

共识机制控制建立在协议之上的许多方面。为了便于讨论，我们将共识机制的规定分为两部分：数据（可用的数据结构和与之可用的交互）和钩子（构建在共识机制之上的协议调用的特定顶级钩子）。由共识机制提供的数据结构对于与之交互的外部系统来说是抽象的，而主要被共识机制的钩子所使用。

**数据 **

本地状态

Local_state 是与共识相关的状态，只存储在本机本地。它为共识提供了一个位置，以便在协议状态的最终点上跟踪本地节点上的一些信息。查看 frontier_root_transition  钩子了解更多细节。

共识转换数据

Consensus_transition_data 是包含在 Snark_transition 中的一段状态。它为共识提供了一个地方去添加额外的信息，而这些被证明的信息是为了向 snark 证明一个转换。与 Consensus_state 不同，Consensus_transition_data 中的信息仅由创建转换的节点使用，而其他节点不可用。

共识状态

Consensus_state 包含在协议的 Protocol_state 中。它为共识机制提供了一个存储信息的地方，这些信息在协议的每个状态都是可用的，并且可以在 snark 中得到证明。因为它包含在 Protocol_state，所以网络上的其他节点都可以检查到这个信息。

Prover_state（证明者状态）

待办事项

Proposal_data（提案数据）

待办事项

其他实例化数据

• Blockchain_state

• Protocol_state

• Snark_transition

钩子

生成转换

generate_transition 的钩子完全生成一个新的协议状态和共识转换数据，从而作为区块链上先前协议状态的扩展。这个功能提供了新的区块链状态，以及要包括在分段分类帐差异和相关建议数据中的交易。这个钩子旨在由提议者调用，并在作为 previous_protocol_state 传入，同时最好 tip 位于前端。倡议者应该与 next_proposal 钩子进行交互，以确定何时应该调用这个钩子。

下一步提议

next_proposal 的钩子会通知协议何时可以有效地生成并提议下一次转换。这个钩子可以返回建议转换的时间，或者再次检查钩子的时间。这允许一种共识机制来分隔提案，并根据协议中的其他信息控制更高级的提案调度。

已检查的下一步状态

next_state_checked 钩子将一个经过检查的计算结果返回，该计算结果将计算或约束区块链序列中的下一个共识状态。这个钩子被包含在组成区块链 snark 约束系统的检查计算中。因此，这是在共识状态上执行验证的主要功能。

选择

select 钩子通知协议，并给定两个状态，表明哪个状态在共识机制的眼里是“更好的”。这个钩子在如何达成共识方面起着至关重要的作用，因为它是决定两条链之间哪个应该被保留的主要操作。当被调用时，它将通知调用者要么 Keep 现有状态，要么 Take 候选状态。

在有效时间接收

received_at_valid_time 钩子是有断定性的，用于判断给定的共识状态在给定的时间是否有效。这使得共识机制可以选择性地控制共识状态何时有效生成的时间属性，如果它是在带外接收的，则该协议状态被拒绝接收。协议的实现应该在从网络接收到转换之前，在处理转换并将其添加到边界之前调用这个钩子。

边界 root 转换

当一个转换发生在最终点（在 mina 中，这是转换边界的 root）时，frontier_root_transition 钩子需要被调用。这为共识机制提供了一个根据网络最终状态更新其本地状态的机会。

应该引导程序

should_bootstrap 钩子通知协议通过网络接收到的转换是否需要节点开始引导其状态到当前网络状态。共识机制决定状态结束之前需要多长时间，以及节点是否也应该引导到这个概念。当从网络接收到转换并且初始验证成功执行时，应该调用这个钩子。

共识是指网络决定哪些信息将被保留在区块链中的过程。在像区块链这样的系统中，用新信息扩展区块链的责任分布在整个网络的参与节点上。这些节点不能被假定为网络中的“诚实”节点，因此，网络中的“诚实”参与者必须合作，以将各个节点提出的信息进行选择性保留。有许多不同的方法可以实现分布式共识，我们将其称为共识机制。在我们的代码库中，我们建立了一个单一的接口，通过这个接口，共识机制通知协议的其余部分。通过这个接口，共识机制的各种实现可以在编译时交换出来，从而允许我们编写协议的其余部分而不依赖于所选择的共识机制。因此，我们可以将共识机制看作是某种东西，一旦定义，协议的其余部分就可以建立在它之上。

共识机制控制建立在协议之上的许多方面。为了便于讨论，我们将共识机制的规定分为两部分：数据（可用的数据结构和与之可用的交互）和钩子（构建在共识机制之上的协议调用的特定顶级钩子）。由共识机制提供的数据结构对于与之交互的外部系统来说是抽象的，而主要被共识机制的钩子所使用。

**数据 **

本地状态

Local_state 是与共识相关的状态，只存储在本机本地。它为共识提供了一个位置，以便在协议状态的最终点上跟踪本地节点上的一些信息。查看 frontier_root_transition  钩子了解更多细节。

共识转换数据

Consensus_transition_data 是包含在 Snark_transition 中的一段状态。它为共识提供了一个地方去添加额外的信息，而这些被证明的信息是为了向 snark 证明一个转换。与 Consensus_state 不同，Consensus_transition_data 中的信息仅由创建转换的节点使用，而其他节点不可用。

共识状态

Consensus_state 包含在协议的 Protocol_state 中。它为共识机制提供了一个存储信息的地方，这些信息在协议的每个状态都是可用的，并且可以在 snark 中得到证明。因为它包含在 Protocol_state，所以网络上的其他节点都可以检查到这个信息。

Prover_state（证明者状态）

待办事项

Proposal_data（提案数据）

待办事项

其他实例化数据

• Blockchain_state

• Protocol_state

• Snark_transition

钩子

生成转换

generate_transition 的钩子完全生成一个新的协议状态和共识转换数据，从而作为区块链上先前协议状态的扩展。这个功能提供了新的区块链状态，以及要包括在分段分类帐差异和相关建议数据中的交易。这个钩子旨在由提议者调用，并在作为 previous_protocol_state 传入，同时最好 tip 位于前端。倡议者应该与 next_proposal 钩子进行交互，以确定何时应该调用这个钩子。

下一步提议

next_proposal 的钩子会通知协议何时可以有效地生成并提议下一次转换。这个钩子可以返回建议转换的时间，或者再次检查钩子的时间。这允许一种共识机制来分隔提案，并根据协议中的其他信息控制更高级的提案调度。

已检查的下一步状态

next_state_checked 钩子将一个经过检查的计算结果返回，该计算结果将计算或约束区块链序列中的下一个共识状态。这个钩子被包含在组成区块链 snark 约束系统的检查计算中。因此，这是在共识状态上执行验证的主要功能。

选择

select 钩子通知协议，并给定两个状态，表明哪个状态在共识机制的眼里是“更好的”。这个钩子在如何达成共识方面起着至关重要的作用，因为它是决定两条链之间哪个应该被保留的主要操作。当被调用时，它将通知调用者要么 Keep 现有状态，要么 Take 候选状态。

在有效时间接收

received_at_valid_time 钩子是有断定性的，用于判断给定的共识状态在给定的时间是否有效。这使得共识机制可以选择性地控制共识状态何时有效生成的时间属性，如果它是在带外接收的，则该协议状态被拒绝接收。协议的实现应该在从网络接收到转换之前，在处理转换并将其添加到边界之前调用这个钩子。

边界 root 转换

当一个转换发生在最终点（在 mina 中，这是转换边界的 root）时，frontier_root_transition 钩子需要被调用。这为共识机制提供了一个根据网络最终状态更新其本地状态的机会。

应该引导程序

should_bootstrap 钩子通知协议通过网络接收到的转换是否需要节点开始引导其状态到当前网络状态。共识机制决定状态结束之前需要多长时间，以及节点是否也应该引导到这个概念。当从网络接收到转换并且初始验证成功执行时，应该调用这个钩子。