# Argument-0007: Retention at Rank II

|                  |                                                                                |
| ---------------- | ------------------------------------------------------------------------------ |
| **Report Date**  | 2026/03/23                                                                     |
| **Submitted by** | Alexandru Gheorghe                                                             |

## Member details

- Matrix username: @alexggh:parity.io
- Polkadot address: 14uA7Vc828e2Q6oL5GBHP9UzTkEvwqbroERwRmucGrLmPuuL
- Current rank: 2
- Date of initial induction: 2024/07/20
- Date of last report: 2025/12/21
- Area(s) of Expertise/Interest: Parachains consensus, statement-store protocol

## Reporting period

- Start date: 2025/12/21
- End date: 2026/03/23

## Argument

During this reporting period my focus has been on making the polkadot-sdk statement-store scalable. My work here is threefold: profiling and optimising the node to lower propagation latency and increase throughput, redesigning the RPC API so clients can efficiently interact with the store, and working on a v2 protocol design to overcome the scalability limits of the current flood-gossip model.

## User API

As part of making the statement-store production ready, I worked on [restructuring the RPC API](https://github.com/paritytech/polkadot-sdk/issues/10457), defining and [implementing a new API](https://github.com/paritytech/polkadot-sdk/pull/10690) with topic-based subscriptions so that clients can receive only the statements they care about.

## Performance optimisations

After profiling the node under load, I fixed several bottlenecks in propagation, encoding, and initialisation (e.g. [#10785](https://github.com/paritytech/polkadot-sdk/pull/10785), [#10796](https://github.com/paritytech/polkadot-sdk/pull/10796), [#10882](https://github.com/paritytech/polkadot-sdk/pull/10882), [#11117](https://github.com/paritytech/polkadot-sdk/pull/11117)). I've also been proposing and guiding the wider team on further scalability work around benchmarking, observability, rate limiting, and concurrency (e.g. [#10617](https://github.com/paritytech/polkadot-sdk/pull/10617), [#10941](https://github.com/paritytech/polkadot-sdk/pull/10941), [#11051](https://github.com/paritytech/polkadot-sdk/pull/11051), [#10976](https://github.com/paritytech/polkadot-sdk/pull/10976)).

## Long-term scalability

The current flood-gossip model, where every node stores all statements and forwards them to all peers, doesn't scale well. I've been working on a v2 protocol design that replaces flood gossip with topic-based DHT routing.

The team has already begun translating parts of this design into implementation. The first step is adding support for [light statement store nodes](https://github.com/paritytech/polkadot-sdk/pull/11329), and making smoldot talk the statement-store protocol.

## Other work

Besides the mentioned topics, I'm providing reviews for my area of expertise in polkadot-sdk. During this reporting period I reviewed PRs in [polkadot-sdk](https://github.com/paritytech/polkadot-sdk/pulls?q=is:pr+reviewed-by:alexggh+created:2025-12-21..2026-03-23), spanning statement-store, parachain consensus, and collator protocol.

## Voting record

|  Ranks | Activity thresholds | Agreement thresholds | Member's voting activities | Comments |
|---|---|---|---|---|
|I  |90%   |N/A   | | |
|II |80%   |N/A   | I have voted on 0 out of 0 referenda in which I was eligible to vote (i.e 100 % voting activity) | There were no referendums available for my rank to vote on. |
|III|70%   |100%  |   |  |
|IV |60%   |90%   |   |  |
|V  |50%   |80%   |   |  |
|VI |40%   |70%   |   |  |

## Misc

- [ ] Question(s):

- [ ] Concern(s):

- [ ] Comment(s):