You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

134 lines
7.1 KiB

  1. ---
  2. order: 5
  3. ---
  4. # State Sync
  5. ## Channels
  6. State sync has four distinct channels. The channel identifiers are listed below.
  7. | Name | Number |
  8. |-------------------|--------|
  9. | SnapshotChannel | 96 |
  10. | ChunkChannel | 97 |
  11. | LightBlockChannel | 98 |
  12. | ParamsChannel | 99 |
  13. ## Message Types
  14. ### SnapshotRequest
  15. When a new node begin state syncing, it will ask all peers it encounters if it has any
  16. available snapshots:
  17. | Name | Type | Description | Field Number |
  18. |----------|--------|-------------|--------------|
  19. ### SnapShotResponse
  20. The receiver will query the local ABCI application via `ListSnapshots`, and send a message
  21. 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.
  22. | Name | Type | Description | Field Number |
  23. |----------|--------|-----------------------------------------------------------|--------------|
  24. | height | uint64 | Height at which the snapshot was taken | 1 |
  25. | format | uint32 | Format of the snapshot. | 2 |
  26. | chunks | uint32 | How many chunks make up the snapshot | 3 |
  27. | hash | bytes | Arbitrary snapshot hash | 4 |
  28. | metadata | bytes | Arbitrary application data. **May be non-deterministic.** | 5 |
  29. ### ChunkRequest
  30. The node running state sync will offer these snapshots to the local ABCI application via
  31. `OfferSnapshot` ABCI calls, and keep track of which peers contain which snapshots. Once a snapshot
  32. is accepted, the state syncer will request snapshot chunks from appropriate peers:
  33. | Name | Type | Description | Field Number |
  34. |--------|--------|-------------------------------------------------------------|--------------|
  35. | height | uint64 | Height at which the chunk was created | 1 |
  36. | format | uint32 | Format chosen for the chunk. **May be non-deterministic.** | 2 |
  37. | index | uint32 | Index of the chunk within the snapshot. | 3 |
  38. ### ChunkResponse
  39. The receiver will load the requested chunk from its local application via `LoadSnapshotChunk`,
  40. and respond with it (limited to 16 MB):
  41. | Name | Type | Description | Field Number |
  42. |---------|--------|-------------------------------------------------------------|--------------|
  43. | height | uint64 | Height at which the chunk was created | 1 |
  44. | format | uint32 | Format chosen for the chunk. **May be non-deterministic.** | 2 |
  45. | index | uint32 | Index of the chunk within the snapshot. | 3 |
  46. | hash | bytes | Arbitrary snapshot hash | 4 |
  47. | missing | bool | Arbitrary application data. **May be non-deterministic.** | 5 |
  48. Here, `Missing` is used to signify that the chunk was not found on the peer, since an empty
  49. chunk is a valid (although unlikely) response.
  50. The returned chunk is given to the ABCI application via `ApplySnapshotChunk` until the snapshot
  51. is restored. If a chunk response is not returned within some time, it will be re-requested,
  52. possibly from a different peer.
  53. The ABCI application is able to request peer bans and chunk refetching as part of the ABCI protocol.
  54. ### LightBlockRequest
  55. To verify state and to provide state relevant information for consensus, the node will ask peers for
  56. light blocks at specified heights.
  57. | Name | Type | Description | Field Number |
  58. |----------|--------|----------------------------|--------------|
  59. | height | uint64 | Height of the light block | 1 |
  60. ### LightBlockResponse
  61. The receiver will retrieve and construct the light block from both the block and state stores. The
  62. receiver will verify the data by comparing the hashes and store the header, commit and validator set
  63. if necessary. The light block at the height of the snapshot will be used to verify the `AppHash`.
  64. | Name | Type | Description | Field Number |
  65. |---------------|---------------------------------------------------------|--------------------------------------|--------------|
  66. | light_block | [LightBlock](../../core/data_structures.md#lightblock) | Light block at the height requested | 1 |
  67. State sync will use [light client
  68. verification](https://github.com/tendermint/tendermint/blob/master/docs/tendermint-core/light-client.md)
  69. to verify the light blocks.
  70. If no state sync is in progress (i.e. during normal operation), any unsolicited response messages
  71. are discarded.
  72. ### ParamsRequest
  73. In order to build tendermint state, the state provider will request the params at the height of the snapshot and use the header to verify it.
  74. | Name | Type | Description | Field Number |
  75. |----------|--------|----------------------------|--------------|
  76. | height | uint64 | Height of the consensus params | 1 |
  77. ### ParamsResponse
  78. A reciever to the request will use the state store to fetch the consensus params at that height and return it to the sender.
  79. | Name | Type | Description | Field Number |
  80. |----------|--------|---------------------------------|--------------|
  81. | height | uint64 | Height of the consensus params | 1 |
  82. | consensus_params | [ConsensusParams](../../core/data_structures.md#ConsensusParams) | Consensus params at the height requested | 2 |
  83. ### Message
  84. Message is a [`oneof` protobuf type](https://developers.google.com/protocol-buffers/docs/proto#oneof). The `oneof` consists of eight messages.
  85. | Name | Type | Description | Field Number |
  86. |----------------------|--------------------------------------------|----------------------------------------------|--------------|
  87. | snapshots_request | [SnapshotRequest](#snapshotrequest) | Request a recent snapshot from a peer | 1 |
  88. | snapshots_response | [SnapshotResponse](#snapshotresponse) | Respond with the most recent snapshot stored | 2 |
  89. | chunk_request | [ChunkRequest](#chunkrequest) | Request chunks of the snapshot. | 3 |
  90. | chunk_response | [ChunkRequest](#chunkresponse) | Response of chunks used to recreate state. | 4 |
  91. | light_block_request | [LightBlockRequest](#lightblockrequest) | Request a light block. | 5 |
  92. | light_block_response | [LightBlockResponse](#lightblockresponse) | Respond with a light block | 6 |
  93. | params_request | [ParamsRequest](#paramsrequest) | Request the consensus params at a height. | 7 |
  94. | params_response | [ParamsResponse](#paramsresponse) | Respond with the consensus params | 8 |