fix(cnight-observation): bound IDP queries by CardanoBlockWindowSize#1432
fix(cnight-observation): bound IDP queries by CardanoBlockWindowSize#1432skylar-simoncelli wants to merge 2 commits into
Conversation
The cNight observation IDP was querying cardano-db-sync from NextCardanoPosition all the way to the current Cardano tip on every Midnight block. For sparse assets like cNight, this caused multi-minute db-sync queries that scanned essentially the full Cardano history on each Midnight block, blocking block import to ~0.1 bps when the IDP's start position was far behind tip. CardanoBlockWindowSize already exists as runtime storage and is exposed via CNightObservationApi::get_cardano_block_window_size, but the IDP never read it. Read it in the IDP, thread it through the data source trait, and clamp the query upper bound to start + window. The genesis-creation tool passes u32::MAX to keep its full-history scan. Removes the unused DEFAULT_CARDANO_BLOCK_WINDOW_SIZE constant in the IDP module since the value now comes from the runtime API.
| .try_into() | ||
| .map_err(|_| IDPCreationError::AuthTokenAssetNameNotString)?; | ||
| let cardano_position_start = api.get_next_cardano_position(parent_hash)?; | ||
| let block_window_size = api.get_cardano_block_window_size(parent_hash)?; |
There was a problem hiding this comment.
This is possibly breaking change.
If the runtime api of mainnet didn't have this method it will fail when syncing chain from genesis.
Otherwise, if the runtime api had this function, new node, when syncing from genesis, will apply this limit and return possibly different result what chain has observed without this addition.
ObservedUtxo contains bounds. So, if it happened on the mainnet that CNightObservation returned observed_utxos spanning more than 10000 blocks, it won't sync.
I think that solution here is (unfortunately) to use more complex code. block_window_size usage should be enabled conditionally. Condition can be presence of a runtime API, but a new one, not one that existed before and wasn't used.
|
|
||
| // Clamp the upper query bound to `start + block_window_size`. Without this, every | ||
| // per-block invocation scans from `start_position` to the current Cardano tip, which | ||
| // for sparse assets (e.g. cNight) means scanning the whole chain on every Midnight |
There was a problem hiding this comment.
start advances every Cardano block and being sparse doesn't matter here.
This code "fixes" only one case of the first cNIGHT observation queries, when start is somewhere in distant past (it is defined in configuration) and end (renamed to tip) is the highest stable block.
2 participants
Overview
The cNight observation Inherent Data Provider was querying cardano-db-sync from
NextCardanoPositionall the way to the current Cardano tip on every Midnight block. For sparse assets like cNight — which appear in only a tiny fraction of Cardano outputs — this caused db-sync queries that effectively scanned the entire Cardano history on every 6-second Midnight block, blocking block import to ~0.1 bps whenever the IDP's start position fell behind tip.CardanoBlockWindowSizealready exists as runtime storage onpallet-cnight-observation(default 1000) and is already exposed viaCNightObservationApi::get_cardano_block_window_size, but the IDP never actually read it. The "window" was effectively[start, ∞). This PR finishes that wiring.Change
MidnightCNightObservationInherentDataProvider::newreadsblock_window_sizefrom the runtime API.MidnightCNightObservationDataSource::get_utxos_up_to_capacitytakes a newblock_window_size: u32parameter.start + block_window_size. When tip is closer thanstart + window, behavior is unchanged.db::get_block_by_block_nohelper is added to fetch the bounded block for the upper bound.u32::MAXto preserve its existing full-history scan (it's a one-time, off-the-hot-path job).DEFAULT_CARDANO_BLOCK_WINDOW_SIZEconstant in the IDP module is removed (the value now comes from the runtime API).The cap on
endalso tightens theget_high_boundsinteger-id ranges that constraintx/tx_out/ma_tx_out/tx_injoins, so each query benefits twice from the smaller window.🗹 TODO before merging
📌 Submission Checklist
🧪 Testing Evidence
SQLX_OFFLINE=true cargo check -p midnight-primitives-mainchain-follower— cleanSKIP_WASM_BUILD=1 SQLX_OFFLINE=true cargo check -p midnight-node— cleanSKIP_WASM_BUILD=1 SQLX_OFFLINE=true cargo clippy -p midnight-primitives-mainchain-follower -p midnight-node— cleancargo fmt -p midnight-primitives-mainchain-follower -p midnight-node— no diffFunctional verification on a node that's currently stuck at 0.0–0.1 bps with ~118s db-sync queries: expect query latency to drop to sub-second and
bpsto recover to normal AURA cadence once a node running this build replaces the existing one. The window-size pallet storage is already populated at default 1000 across networks; no chain-spec or genesis change required.Please describe any additional testing aside from CI:
🔱 Fork Strategy
This is a node-client behavior change only — the runtime API surface is unchanged (the
get_cardano_block_window_sizeruntime API already exists and was already being implemented; only its consumer changed). Old nodes will continue to function (with the existing slow behavior); new nodes will use the bounded window.Links