对区块块签名而不是分片段。既然分片指派是隐藏的，验证节点就不能在段上签名，而是通常对整个块签名，这样就不会暴露他验证哪些分片。特别的，当一个验证节点收到一个区块并验证了所有的分片段后，他要么创建一条消息，证明他负责的所有分片（没有以任何方式表明是哪些分片）中所有的段都是有效的；要么在任意一个段无效时，创建一条消息，包含一个无效状态转换的证明。对如何聚合这些消息的详细介绍，参见 3.8 节。对如何防止验证节点照抄其他验证节点消息的详细介绍，参见 3.7.4 节。以及 3.7.5 节，详细介绍了当一个成功的无效状态转换质疑发生时，如何奖惩验证节点。

承诺生成 (commit)-展示 (reveal)

验证节点的一个常见问题是，他可以跳过状态的下载和对分片段和区块的实际验证，而是观察网络，看其他验证节点提交的内容并重复他们的消息。采用这种策略的验证节点并不能给网络带来任何安全的提升，只是获得奖励。

一个解决该问题的常见方案是，要求每个验证节点提供一个证明，证实他们确实验证了区块。例如，提供一个执行状态转换的独有痕迹，但是这种证明大大增加了验证的开销。

与其我们让验证节点先承诺 (commit) 一个验证结果（要么是一条证明段有效的消息，要么是一个无效状态转换的证明），等待一段时间，之后才能展示 (reveal) 实际的验证结果，如图 25 所示。承诺阶段和展示阶段不会重叠，因此一个懒惰的验证节点无法抄袭诚实验证节点。此外，如果不诚实的验证节点承诺了一条证实所负责的分片段都有效的消息，而最终有一个段无效。只要这个段的无效性被公开，该验证节点就无法逃避惩罚。就如我们将在 3.7.5 节所展示的，那种情况下，唯一不被惩罚的方式就是（在展示阶段）呈现一条包含无效状态转换证明的消息，并与自己的（在承诺阶段的）的申明匹配。。

处理质疑

如上所述，一旦验证节点收到一个含有无效分片段的区块，他们先准备一个无效状态转换的证明（参见 3.7.1 节），然后提交这样一个证明（参见 3.7.4 节），再在一段时间后展示这个质疑。一旦块里包含一个被展示的质疑，接下来会： (责任编辑：admin1)