使用区块同步时，节点会从创世块开始下载应用的全部数据并进行验证。 使用状态同步时，节点会下载与链头或接近链头相关的数据并验证这些数据。 这会大幅缩短加入网络所需的时间。

​
使用状态同步

状态同步会在后台持续运行，在引导启动期间为节点提供分块数据。
注意：在尝试使用状态同步之前，请先确认你所运行节点对应的应用是否支持该功能。
在 config.toml 的状态同步部分中，你会看到多个需要配置的设置，节点只有完成这些配置后才能使用状态同步。 下面逐项说明这些配置：
  • enable：用于告知节点，你将使用状态同步来引导启动该节点。
  • rpc_servers：需要配置 RPC 服务器，因为状态同步会使用轻客户端进行验证。
    • 需要 2 个服务器，更多通常也会有帮助。
  • temp_dir：用于在机器本地存储中保存数据分块的临时目录。如果未设置，将会在 /tmp 中创建目录。
接下来，你需要通过你信任的公开 RPC 或区块浏览器获取以下信息。
  • trust_height：可信高度，定义你的节点应当从哪个高度开始信任这条链。
  • trust_hash：可信哈希，即与可信高度对应的 BlockID 中的哈希值。
  • trust_period：信任期，即区块头可被验证的时间范围。
    :warning: 该值应明显小于解绑期。
如果你依赖公开 RPC 来获取所需信息，可以使用 curl 和 jq。 示例： 
curl -s https://233.123.0.140:26657/commit | jq "{height: .result.signed_header.header.height, hash: .result.signed_header.commit.block_id.hash}"
返回结果如下： 
{
  "height": "273",
  "hash": "188F4F36CBCD2C91B57509BBF231C777E79B52EE3E0D90D06B1A25EB16E6E23D"
}
With block sync, a node downloads all of the application’s data from genesis and verifies it. With state sync, your node will download data related to the head or near the head of the chain and verify the data. This leads to drastically shorter times for joining a network.

​
Using State Sync

State sync will continuously work in the background to supply nodes with chunked data when bootstrapping.
NOTE: Before trying to use state sync, see if the application you are operating a node for supports it.
Under the state sync section in config.toml, you will find multiple settings that need to be configured in order for your node to use state sync. Let’s break down the settings:
  • enable: Enable is to inform the node that you will be using state sync to bootstrap your node.
  • rpc_servers: RPC servers are needed because state sync utilizes the light client for verification.
    • 2 servers are required, more is always helpful.
  • temp_dir: Temporary directory to store the chunks in the machine’s local storage. If nothing is set, it will create a directory in /tmp.
The next information you will need to acquire through publicly exposed RPCs or a block explorer which you trust.
  • trust_height: Trusted height defines at which height your node should trust the chain.
  • trust_hash: Trusted hash is the hash in the BlockID corresponding to the trusted height.
  • trust_period: Trust period is the period in which headers can be verified.
    :warning: This value should be significantly smaller than the unbonding period.
If you are relying on publicly exposed RPCs to get the needed information, you can use curl and jq. Example: 
curl -s https://233.123.0.140:26657/commit | jq "{height: .result.signed_header.header.height, hash: .result.signed_header.commit.block_id.hash}"
The response will be: 
{
  "height": "273",
  "hash": "188F4F36CBCD2C91B57509BBF231C777E79B52EE3E0D90D06B1A25EB16E6E23D"
}