# Argument-0005: Promotion to rank II

|                 |                                                                                             |
| --------------- | ------------------------------------------------------------------------------------------- |
| **Report Date** | Date of submission (2025/09/05)                                                             |
| **Submitted by**|  Alexandru Gheorghe                                                                         |


## Member details

- Matrix username: @alexggh:parity.io
- Polkadot address: 14uA7Vc828e2Q6oL5GBHP9UzTkEvwqbroERwRmucGrLmPuuL
- Current rank: 1
- Date of initial induction: 2024/07/20
- Date of last report: 2025/04/19
- Area(s) of Expertise/Interest: Parachains consensus


## Reporting period

- Start date: 2024/07/20
- End date: 2025/09/05


## Argument

Since joining Polkadot ecosystem I've spent nearly 2 years and a half designing, implementing, testing, hardening and debugging Polkadot changes. My main area of expertise is parachain consensus protocol with a focus on increasing the scalability, stability and single core performance of our network.

Through these activities, I have developed the contributions and skills that I believe qualify me for promotion to rank 2. Below are my most notable contributions, listed in order of impact.

## Async backing enablement and maintaining on Polkadot and Kusama

Async backing was a huge network upgrade that increased the available throughput [many times](https://polkadot.com/blog/the-way-to-a-10x-throughput-lift-on-parachains/), while async backing is not something I designed & developed (kudos to my forebears), I was part of the 2-person team that handled the [last-mile effort](https://github.com/paritytech/polkadot-sdk/issues/3226), before enabling it seamlessly on Kusama and Polkadot. This work required large scale testing on test networks, fixing the remaining bugs, ensuring the upgrade was smooth for parachains, maintaining a direct communication with validators and providing support to parachains that migrated to using async backing. Post launch, I also acted as de-facto maintainer of parts of the new protocol components. 

## Make Polkadot ready for 1000 validators and 200 cores

Ensuring sufficient cores to meet periods of high demand and increasing the network's level of decentralization are both critical objectives. To support these goals, I have been actively involved in two key areas:

#### 1. Approval voting performance improvements

Approval voting protocol was one of the main bottlenecks that prevented the network from having more active validators, which would increase the number of available Polkadot cores and the level of decentralization. To improve this situation, I worked on two types of optimizations that allowed us to increase Kusama and Polkadot from 300 active para validators to the current 700 and 600, and this should allow us to achieve the end goal of having 1000 validators and 200 cores.

The optimization required modifying the protocol so that the amount of heavy work is reduced by sending [fewer messages](https://github.com/paritytech/polkadot-sdk/pull/1191) and a [re-architecture](https://github.com/paritytech/polkadot-sdk/pull/4849) of the implementation to
take advantage of available hardware by processing messages in parallel

Additionally, I also developed the [approval-voting subsystem-benchmark](https://github.com/paritytech/polkadot-sdk/pull/2621), which is a tool that simulates the performance of the approval-voting protocol under load, with that we were able to confirm the gains from the above optimisations and estimate the necessary hardware needs to reach 1000 validators and 200 cores, also we were able to find several micro-optimisation with gains around ~10% each [here](https://github.com/paritytech/polkadot-sdk/pull/5411) and [there](https://github.com/paritytech/polkadot-sdk/pull/4848) and few other places.

#### 2. Upgrading the minimum required validator hardware spec

To support this goal, I developed a benchmark to notify validators who did not meet the new requirements. I also ensured community alignment by sharing the changes early on the [forum](https://forum.polkadot.network/t/rfc-increasing-recommended-minimum-core-count-for-reference-hardware/8156/10) and initiating a [referendum](https://polkadot.subsquare.io/referenda/1051) for the proposed update. Additionally, I used various communication channels to inform validators about the upcoming changes and the need to upgrade.

## Trie database optimizations for smart contracts launch

With the end goal to increase the [parachain's single-core throughput](https://github.com/paritytech/polkadot-sdk/issues/6131), I optimized various parts of our Trie database and weights stack and evaluated the impact of the optimizations. This resulted in reducing the per key read/write costs in validation context from 25us/100us to around 13/31us. For the same goal, we improved the parachain block import and authoring time by making sure we keep the entire state in memory inside the [TrieCache](https://github.com/paritytech/polkadot-sdk/pull/7682)

## Active involvement in operations

I have been actively contributing in debugging various live production issues and handling the aftermath, this resulted in me root-causing and fixing various non-trivial bugs and publishing various post-mortem like:
- [Polkadot parachains stalled until next session](https://forum.polkadot.network/t/2024-04-21-polkadot-parachains-stalled-until-next-session/7526).
- [Polkadot finality lag/slow parachain production immediately after runtime upgrade - post mortem](https://forum.polkadot.network/t/2024-09-17-polkadot-finality-lag-slow-parachain-production-immediately-after-runtime-upgrade-post-mortem/10057)
- [Kusama parachains spammening aftermath](https://forum.polkadot.network/t/2025-11-25-kusama-parachains-spammening-aftermath/11108)

In addition, I strive to stay informed about ongoing issues and assist with root-cause analysis when possible, or simply provide support to misconfigured validators.

## Tooling to help with stability

To improve visibility and facilitate debugging within our decentralized network, I have also enhanced our tooling with features such as:
- [whois](https://github.com/paritytech/polkadot-introspector/pull/794), a tool that allows you to find a validator by all of its IDs keys.
- [bitfield performance command ](https://github.com/paritytech/polkadot-introspector/pull/834) a command that shows per validator bitfield performance compared with its peers.
- [missing blocks per validator metric](https://github.com/paritytech/polkadot-introspector/pull/900) a tool that allows to track validators that failed to author blocks.


### Other work:

Besides the mentioned topics, I'm providing reviews for my area of expertise in polkadot-sdk and RFCs.

## Voting record
*Provide your voting record in relation to required thresholds for your rank.*

|  Ranks | Activity thresholds | Agreement thresholds | Member's voting activities | Comments |
|---|---|---|---|---|
|I  |90%   |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. |
|II |80%   |N/A   |   |  |
|III|70%   |100%  |   |  |
|IV |60%   |90%   |   |  |
|V  |50%   |80%   |   |  |
|VI |40%   |70%   |   |  |


## Misc

- [ ] Question(s):

- [ ] Concern(s):

- [ ] Comment(s):