Skip to content

[storage] Boostrap state sync within current sync engine #3834

@clabby

Description

@clabby

Overview

Following #3778, we now need the OpsRootWitness to specify an initial target to sync towards. This complicates downstream consumption, requiring that users implement an auxiliary protocol to fetch the ops_root and an OpsRootWitness from an untrusted party, given just a root and an [inactivity_floor, database_size) range, verify it, construct the full current sync target, and only then kick off state sync.

Instead, it would be great if this initial fetch was routed through an extension of the existing Resolver trait, with the initial target to construct the current sync engine only consisting of the trusted components (the full root and the [inactivity_floor, database_size) range).

This way, downstream consumers don't need to bolt on a new protocol. Following this change, they will only need to pass in the trusted components of the full CurrentTarget and specify how to fetch an OpsRootWitness + ops_root keyed by a full root and range via implementing the suggested CurrentResolver trait.

The interface and bootstrap phase for the state sync engine should be uniform with other variants of QMDB to facilitate a shared abstraction in #3381.

Metadata

Metadata

Labels

No labels
No labels

Type

No type
No fields configured for issues without a type.

Projects

Status

Backlog

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions