区块同步
区块同步是用 Kaia 区块链的最新区块和状态更新节点的过程。 节点运营商可根据自己的硬件规格和服务要求选择不同的同步方法。
完全同步
完全同步是 Kaia 的默认同步方式，通过使用 --syncmode full 标记或完全省略该标记来激活。 这种方法涉及从 p2p 对等方下载并执行每个区块（头和事务），以生成区块状态。
状态持久性选项
在完全同步处理每个数据块的同时，Kaia 在磁盘上持久存储状态数据的数量上提供了灵活性。 这样，节点操作员就能在数据可访问性和存储容量之间取得平衡。 下图说明了这些选项：
- ** 存档模式**：该模式会将每个数据块的状态保存到磁盘。 要启用它，请使用
--gcmode archive标志。 以这种模式运行的节点被称为 存档节点。 - 完整模式：该模式以特定时间间隔持续保持块状态，以优化磁盘使用。 要启用该功能，请使用
--gcmode full标记或省略--gcmode标记。 以这种模式运行的节点被称为 全节点。 不要将其与一般的 "完全同步 "方法混淆。
在全节点中，块状态每隔 --state.block-interval.NNN（默 认值：128）指定的倍数持久化到磁盘。 此外，最近的 --state.tries-in-memory-NNN（默认值：128）区块的区块状态也会保留在内存中，以便为 API 服务。 因此，区块状态只有在它是区块间隔的倍数或最近处理过时才可用。
// State available> eth.getBalance('0xf39Fd6e51aad88F6F4ce6aB88279cffFb92266', 150000000)735000000000002// State absent> eth.getBalance('0xf39Fd6e51aad88F6F4ce6aB88279cffFb92266', 150000001) 735000000000002 // State absent.getBalance('0xf39Fd6e51aad88F6F4ce6aB88279cffFb92266', 150000001)Error: missing trie node 64380a8de7bd83a6421c9ad45ae596a0eebbc7b504d061f4a57c61742eadc804 (path ) at web3.js:6812:9(39) at send (web3.js:5223:62(29)) at<eval>:1:15(4)
应用程序不应假定固定的块间隔为 128。 虽然这是默认设置，但节点可以配置为使用不同的时间间隔。
选择正确的方案
应用程序通常需要访问最新的状态数据，包括非ces、余额和合约存储。 虽然应用程序和开发人员偶尔会利用调试跟踪 API 来获取历史区块，但这些区块通常可以通过从最近的存储状态重新执行事务来重新创建（例如，根据默认的区块间隔，最多可在 127 个区块之前执行）。 因此，对于大多数应用而言，运行一个完整节点是一种经济高效的选择。
不过，数据分析通常需要使用归档节点。 值得注意的是，即使在查询历史共识数据（如验证器信息或奖励）时，仍然需要一个存档节点。 这是因为共识数据来自特定区块高度的区块链状态。
总而言之：
- 全节点：适用于大多数需要通过跟踪 API 访问最新状态数据和偶尔访问历史数据的应用程序。
- 存档节点：对于需要全面访问历史状态的应用程序（如数据分析工具）来说必不可少。
混合选项：上游 EN
如果您的节点主要提供最新数据，但偶尔也提供历史数据，那么请尝试使用 Upstream EN 功 能。 此功能可让您平衡归档节点的存储要求和完整节点的性能。
Chaindata 快照
Chaindata 快照为完全同步提供了更快的替代方案。 快照是同步节点数据目录的压缩归档文件（如.tar.gz文件）。 下载和提取快照可以让新节点快速跟上区块链，而无需单独处理每个区块。 更多信息，请参阅 使用 Chaindata 快照。
快照同步
目前，Kaia 节点不支持 Snap Sync 方法。 不过，使用链数据快照在更快的初始同步方面也有不相上下的优势。