# Argument-0004: Retention at Rank I

|                 |                                                                                             |
| --------------- | ------------------------------------------------------------------------------------------- |
| **Report Date** | Date of submission (2025/07/21)                                                             |
| **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: 2025/04/20
- End date: 2025/07/21


## Argument

During the reporting period, I continued my work on improving the scalability, stability, and performance of the Polkadot network.

On the performance side, I've spent most of my time helping to increase the parachains' single-core throughput by optimizing various parts of our Trie database and weights stack and evaluating the impact of the optimizations. For this goal, I [profiled](https://github.com/paritytech/polkadot-sdk/issues/6131#issuecomment-2891523233) and implemented  [several optimizations](https://github.com/paritytech/polkadot-sdk/pull/8606) to help pack more Solidity smart contract calls on AssetHub, this resulted in reducing the per key read/write costs in validation context from 25us/100us to around [13/31us](https://github.com/paritytech/polkadot-sdk/pull/8359). I also finished improving the parachain block import and authoring time by making sure we keep the entire state in memory inside the TrieCache [PR7682](https://github.com/paritytech/polkadot-sdk/pull/7682) and collaborated with Andrei Eres at an E2E test that prove the benefits of this optimisation with [ERC20 transfers](https://github.com/paritytech/polkadot-sdk/issues/7540#issuecomment-3009015002).

On the scalability and stability side, I worked on making sure [Polkadot](https://forum.polkadot.network/t/2025-05-03-polkadot-parachain-block-time-degradation/12963) and [Kusama](https://forum.polkadot.network/t/2025-05-09-kusama-dispute-storm-postmortem/12947/4) incidents are properly understood, and the lessons learnt from it addressed, to achieve this goal I've been involved in root-causing, providing fixes and versi scale testing of the changes. List of issues that I've been positively contributing to: 
- [statement-distribution: skip leafs where we can't fetch the state](https://github.com/paritytech/polkadot-sdk/pull/8510)
- [dispute-coordinator: increase lru_observed_blocks_capacity](https://github.com/paritytech/polkadot-sdk/pull/8831)
-  [increase session index cache](https://github.com/paritytech/polkadot-sdk/pull/8832)
-  [extend overseer to send priority messages ](https://github.com/paritytech/polkadot-sdk/pull/8834)
-  [dispute-coordinator: find_controlled_validator_indices takes a lot of time](https://github.com/paritytech/polkadot-sdk/issues/8823)
-  [dispute-coordinator: handle race with offchain disabling](https://github.com/paritytech/polkadot-sdk/pull/9050)


### 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):