# Evidence-0004: Retention at Rank I

|                 |                      |
| --------------- | ---------------------|
| **Report Date** | 2025/03/19           |
| **Submitted by**| s0me0ne-unkn0wn      |


## Member details

- Current rank: I
- Polkadot address: 13WGadgNgqSjiGQvfhimw9pX26mvGdYQ6XgrjPANSEDRoGMt
- Date of initial induction: 2024/04/22
- Date of last report: 2024/12/17
- Area(s) of Expertise/Interest: WebAssembly, PolkaVM, PVF execution, throughput benchmarking

## Reporting period

- Start date: 2024/12/18
- End date: 2025/03/19

## Evidence

During the reporting period, I was busy pushing forward the [PolkaVM integration](https://github.com/paritytech/polkadot-sdk/pull/6704).
That included filing and getting approved [RFC-135](https://github.com/polkadot-fellows/RFCs/pull/135), which standardized binary blob prefixes to make it possible to use different execution engines effectively.
The implementation of said RFC is already a part of the [PolkaVM integration PR](https://github.com/paritytech/polkadot-sdk/pull/6704/commits/66eb9d961eb2804fccdb767e20f23e675779f901).
That is a valuable contribution as it paves the way to more performant and deterministic execution, thus making Polkadot more secure. It also agrees with principles or JAM, which will use PolkaVM as a main execution engine.

Besides that, I started my way toward implementing the long-awaited [RFC-4](https://github.com/polkadot-fellows/RFCs/pull/4) which will enable in-runtime allocation, making runtime execution faster and solving some significant problems regarding execution determinism.
As the first step, I picked up a relevant but stale [PR](https://github.com/paritytech/polkadot-sdk/pull/7375) and revived it, and now I'm collecting reviews for that breaking runtime interface change.

I have also worked on NFT throughput benchmarking for specific cases involving large chain states and have created some tooling to support that need: [a specialized version of the sTPS tool](https://github.com/paritytech/polkadot-stps/tree/s0me0ne/ethereum2) and a simple [state bloater](https://github.com/s0me0ne-unkn0wn/state-bloater/tree/master).
That is crucial to prevent future problems that could emerge in parachains with quickly growing state size. For the same reason, I [proposed increasing the PoV size on Polkadot to 10 MiB](https://polkadot.polkassembly.io/referenda/1480).

To sum up, my work during the reporting period was valuable, and thus, I'm applying for retention at Rank I.

## Voting record

|  Ranks | Activity thresholds | Agreement thresholds | Member's voting activities | Comments |
|---|---|---|---|---|
|I  |90%   |N/A   | I have voted on 0 out of 0 referendum in which I was eligible to vote (i.e undefined% voting activity). Out of 0 referenda in which members of higher ranks were in complete agreement, I have voted in line with the consensus 0 times (i.e undefined% voting agreement).  |  |
|II |80%   |N/A   |   |  |
|III|70%   |100%  |   |  |
|IV |60%   |90%   |   |  |
|V  |50%   |80%   |   |  |
|VI |40%   |70%   |   |  |


## Misc

- [ ] Question(s): 

- [ ] Concern(s): 

- [ ] Comment(s): 