#snapshot #zksync #recovery #blockchain #object-store #state #logs

zksync_snapshots_applier

用于应用 ZKsync 状态快照的库

1 个不稳定版本

0.1.0 2024 年 7 月 14 日

2828魔法豆

Download history 120/week @ 2024-07-10 15/week @ 2024-07-17 13/week @ 2024-07-24

148 次每月下载
用于 3 个 crate(通过 zksync_node_storage_init

MIT/Apache

1.5MB
38K SLoC

zksync_snapshots_applier

负责从协议级别快照恢复 Postgres 的库。

恢复工作流程

(有关高级快照恢复概述,请参阅 节点文档,有关快照格式细节,请参阅 快照创建者文档)

  1. 通过查询主节点并确定快照参数来启动恢复。默认情况下,从最新的快照进行恢复,但可以提供手动覆盖(快照的 L1 批次号)。
  2. 从对象存储下载工厂依赖项(= 合约字节码),并与快照元数据(L1 批次号 / L2 区块号和时间戳,L1 批次状态根哈希,L2 区块哈希等)一起原子性地保存到 Postgres 中。
  3. 从对象存储下载存储日志块;每个块都原子性地保存到 Postgres(storage_logsinitial_writes 表)。此步骤具有可配置的并发程度,以控制速度与 I/O 负载权衡。
  4. 在所有存储日志恢复后,从主节点获取令牌信息并保存在相应的表中。令牌与存储日志进行双重检查。

恢复对停止/失败具有弹性;如果恢复过程被中断,它将重新启动相同的快照,并跳过在 Postgres 中已存在的数据。

节点组件(例如元数据计算器和状态保持器)的恢复逻辑有意与Postgres恢复隔离。需要恢复的组件必须自行组织恢复。这源于至少某些需要恢复的组件可能在Postgres恢复后(或根本不运行)任意延迟后初始化,或者可能针对单个节点实例化多次。以元数据计算器/梅克尔树为例,这两个要求都成立。

依赖项

~93MB
~2M SLoC