| Report Date | 2026/07/23 |
| Submitted by | skunert |
@sebastian:parity.io1682A5hxfiS1Kn1jrUnMYv14T9EuEnsgnBbujGfYbeEbSK3wCumulus Node, Substrate Node, Parachain Authoring, WeightDuring this reporting period my own technical focus was on enabling storage chains to sync with warp sync, which was not possible before. In addition, I continued my usual mentoring, tech leadership and review activities on polkadot-sdk.
Chains built on pallet-transaction-storage (like the Bulletin Chain) index large data payloads in the node database as a side effect of block execution. This model breaks down for nodes that do not execute every block from genesis: a node that tip-syncs past a Renew extrinsic after warp-sync never executed the original Store. Therefore does not hold the referenced payload locally and will be unable to serve this data or produce blocks. I designed and implemented the mechanism that closes this gap by fetching missing payloads from the network during sync:
TransactionStorageApi v2 (#11939): New runtime API version that allows the client to query which transactions are indexed by a block, so missing payloads can be identified without re-executing history. I also prepared the Bulletin Chain for the new API version (bulletin#471).sc-network previously only served inbound bitswap requests. I added a public client API for fetching CID-addressed data from peers, including wiring outbound requests through the litep2p backend. Follow-up: sync peer roles are now exposed to consumers of sync events (#12598).sc-client-db that lets block-import implementations supply payloads and index operations that block execution cannot provide, covering both tip-sync (payload missing) and gap-sync (block not executed) cases.StorageChainBlockImport (#12242): A block-import wrapper that detects missing payloads for Renew operations during tip-sync, fetches them over bitswap and hands them to the database backend via the carrier above.Along the way I found and fixed a ParityDB correctness bug where a store + reference on the same value within one transaction resulted in the value not being stored at all (#12082), and extended the client runtime-API interface to support calls on top of a custom storage overlay (#12084).
As a follow-up, I am currently reworking the bitswap client and server (#12686): Bitswap moves out of sc-network into a dedicated sc-network-bitswap crate, replacing the backend-specific implementations with a single actor-driven service and a streaming handle API. This centralizes CID deduplication, peer selection, retries, failover and backpressure handling, simplifies the integration with storage-chain sync, and improves test coverage. This work is in progress.
Slot must increase. With elastic scaling, multiple blocks per slot must be permitted. I fixed the runtime configuration and prepared release 2.2.2, which was enacted via Referendum 519.runtimes repository to make the release process better documented (runtimes#1066).I continue to apply general fixes across the node. I fixed a warp sync stall of up to 30 minutes (#11152), simplified the parent-search logic in the cumulus block-building path (#10998), fixed missed transaction status updates in the fork-aware transaction pool (#10965) and added Asset Hub Polkadot support to the omni-node (#10978). One more workstream that is in flight is an improvement to the compact proof encoding that we use in Substrate. I removes duplicates from the proof encodings. The work is under review here.
| Ranks | Activity thresholds | Agreement thresholds | Member's voting activities | Comments |
|---|---|---|---|---|
| III | 70% | 100% | I have voted on 53 out of 62 referenda in which I was eligible to vote (85% voting activity). |
Threshold