We want to reduce smoldot's cold-start latency before clients can receive parachain blocks via RPC.
Today
- Relay chain warp-syncs to a finalized block close to the tip.
- The included parahead for the configured parachain is fetched from that finalized RC block and treated as the parachain's finalized head.
- The parachain tip-syncs from there.
The dominant cost is the wait for the first finalized RC block (17–67s on Paseo, see #3235).
Proposal
The same idea applies to the RC and the parachain: follow the peer-reported tip and report best blocks immediately. Finalized notifications wait until warp sync gives us a
verifiable finalized block.
- The RC starts following its tip from peers right away and reports best blocks. Warp sync runs in the background. Once it completes, the RC checks that the followed headers
descend from the warp-sync target and reorgs if they do not.
- The parachain does not wait for RC warp sync. It starts following the parachain tip immediately, based on headers reported by peers.
- Once the RC has a finalized block, the parachain checks that the headers it followed descend from the corresponding finalized parahead, and reorgs if they do not.
Finality
A reported finalized block must never reorg. That is a hard RPC contract. The approach in #3236 breaks it by deriving the parachain's finalized header from an RC best block.
While running in tip-following mode, neither the RC nor the parachain may report any block as finalized via RPC. Finalized notifications resume only once we have a verifiable
finalized RC block and have checked the parachain head against it.
All of this needs to make sure to still follow https://github.com/paritytech/json-rpc-interface-spec closely. From my mental model it should be possible as long as we never output wrong finalized blocks, but needs to be verified by the implementer.
Opt-in
This must be opt-in, not the default. Without any finalized block to anchor against, peers can lie to us for longer than they normally could. That's fine for some clients but
shouldn't be on by default.
We want to reduce smoldot's cold-start latency before clients can receive parachain blocks via RPC.
Today
The dominant cost is the wait for the first finalized RC block (17–67s on Paseo, see #3235).
Proposal
The same idea applies to the RC and the parachain: follow the peer-reported tip and report best blocks immediately. Finalized notifications wait until warp sync gives us a
verifiable finalized block.
descend from the warp-sync target and reorgs if they do not.
Finality
A reported finalized block must never reorg. That is a hard RPC contract. The approach in #3236 breaks it by deriving the parachain's finalized header from an RC best block.
While running in tip-following mode, neither the RC nor the parachain may report any block as finalized via RPC. Finalized notifications resume only once we have a verifiable
finalized RC block and have checked the parachain head against it.
All of this needs to make sure to still follow https://github.com/paritytech/json-rpc-interface-spec closely. From my mental model it should be possible as long as we never output wrong finalized blocks, but needs to be verified by the implementer.
Opt-in
This must be opt-in, not the default. Without any finalized block to anchor against, peers can lie to us for longer than they normally could. That's fine for some clients but
shouldn't be on by default.