State Sync

​

通道

状态同步有四个不同的通道。通道标识符如下所示。

​

消息类型

​

SnapshotRequest

当一个新节点开始进行状态同步时，它会询问遇到的所有对等节点是否有可用的快照：

​

SnapShotResponse

接收方将通过 ListSnapshots 查询本地 ABCI 应用，并为最近的 10 个快照分别发送一条包含快照元数据的消息（限制为 4 MB）；这些快照存储在应用层。当一个对等节点启动时，它会请求快照。

​

ChunkRequest

运行状态同步的节点会通过 OfferSnapshot ABCI 调用将这些快照提供给本地 ABCI 应用，并跟踪哪些对等节点持有哪些快照。一旦某个快照被接受，状态同步器就会向合适的对等节点请求该快照的分块：

​

ChunkResponse

接收方将通过 LoadSnapshotChunk 从本地应用加载所请求的分块，并返回该分块（限制为 16 MB）： 这里，Missing 用于表示该分块在对等节点上未找到，因为空分块也是一种有效的响应（尽管不太可能出现）。 返回的分块会通过 ApplySnapshotChunk 提交给 ABCI 应用，直到快照恢复完成。如果某个分块响应在一段时间内未返回，将会重新请求，且可能改由另一个对等节点提供。 ABCI 应用能够作为 ABCI 协议的一部分，请求封禁对等节点并重新抓取分块。

​

LightBlockRequest

为了验证状态并为共识提供与状态相关的信息，节点会向对等节点请求指定高度的轻区块。

​

LightBlockResponse

接收方会从区块存储和状态存储中检索并构造轻区块。接收方会通过比较哈希来验证数据，并在必要时存储区块头、提交信息和验证者集合。快照高度对应的轻区块将用于验证 AppHash。 状态同步将使用轻客户端验证来验证这些轻区块。 如果当前没有进行状态同步（即正常运行期间），任何未经请求的响应消息都会被丢弃。

​

ParamsRequest

为了构建状态，状态提供方会请求快照高度处的参数，并使用区块头对其进行验证。

​

ParamsResponse

请求的接收方将使用状态存储获取该高度的共识参数，并将其返回给发送方。

​

Message

Message 是一种 oneof protobuf type。该 oneof 由八种消息组成。

---

​

Channels

State sync has four distinct channels. The channel identifiers are listed below.

​

Message Types

​

SnapshotRequest

When a new node begin state syncing, it will ask all peers it encounters if it has any available snapshots:

​

SnapShotResponse

The receiver will query the local ABCI application via ListSnapshots, and send a message containing snapshot metadata (limited to 4 MB) for each of the 10 most recent snapshots: and stored at the application layer. When a peer is starting it will request snapshots.

​

ChunkRequest

The node running state sync will offer these snapshots to the local ABCI application via OfferSnapshot ABCI calls, and keep track of which peers contain which snapshots. Once a snapshot is accepted, the state syncer will request snapshot chunks from appropriate peers:

​

ChunkResponse

The receiver will load the requested chunk from its local application via LoadSnapshotChunk, and respond with it (limited to 16 MB): Here, Missing is used to signify that the chunk was not found on the peer, since an empty chunk is a valid (although unlikely) response. The returned chunk is given to the ABCI application via ApplySnapshotChunk until the snapshot is restored. If a chunk response is not returned within some time, it will be re-requested, possibly from a different peer. The ABCI application is able to request peer bans and chunk refetching as part of the ABCI protocol.

​

LightBlockRequest

To verify state and to provide state relevant information for consensus, the node will ask peers for light blocks at specified heights.

​

LightBlockResponse

The receiver will retrieve and construct the light block from both the block and state stores. The receiver will verify the data by comparing the hashes and store the header, commit and validator set if necessary. The light block at the height of the snapshot will be used to verify the AppHash. State sync will use light client verification to verify the light blocks. If no state sync is in progress (i.e. during normal operation), any unsolicited response messages are discarded.

​

ParamsRequest

In order to build the state, the state provider will request the params at the height of the snapshot and use the header to verify it.

​

ParamsResponse

A reciever to the request will use the state store to fetch the consensus params at that height and return it to the sender.

​

Message

Message is a oneof protobuf type. The oneof consists of eight messages.