# Argument-0005: Promotion to Rank II

|                 |                      |
| --------------- | ---------------------|
| **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

## Argument

Dear fellows,

According to the Manifesto, a rank II member should be a core part of the team, clearly demonstrate the knowledge of the protocol, communicate, share knowledge, become deeply familiar with a major area of the protocol, and should not be asking dumb questions. Well, I have to confess, I'm still doing the latter.

Otherwise, before joining the Fellowship and during a year of being a rank I member (since 22.04.2024), I developed solid familiarity with the PVF execution pipeline, WebAssembly, and PolkaVM, as a major area of the Polkadot protocol. Related work included:
* Implementing [execution environment parameters](https://github.com/paritytech/polkadot/pull/6161) that help to make execution more deterministic and are currently used on Polkadot to set execution-related limits on chain;
* Creating an [experimental deterministic Wasm executor](https://forum.polkadot.network/t/deterministic-pvf-executor/4204) from scratch to demonstrate fully deterministic execution behavior;
* [Opening a discussion](https://forum.polkadot.network/t/ux-implications-of-pvf-executor-environment-versioning/2519) about UX implications of Polkadot worker binaries separation and [co-authoring a relevant PR](https://github.com/paritytech/polkadot/pull/7337) implementing that important change;
* [Proposing a solution](https://github.com/paritytech/polkadot-sdk/issues/3139) for the long-standing worker version mismatch problem and [mentoring](https://github.com/paritytech/polkadot-sdk/pull/3187) an external contributor through implemening that solution;
* Implementing a custom [wrapping memory allocator](https://github.com/paritytech/polkadot-sdk/pull/1192) to enforce deterministic memory limit, which is one more important addition to the execution determinism;

I shared my research and knowledge on the problem of execution determinism in multiple discussions taking place across Github and Polkadot forums, to name a few:
* [Floating point in parachain runtimes](https://forum.polkadot.network/t/we-should-ban-floating-point-operations-from-parachain-runtimes-or-not/3586);
* [High level PVF non-determinism discussion](https://forum.polkadot.network/t/we-should-ban-floating-point-operations-from-parachain-runtimes-or-not/3586);

I proposed a change to the protocol (RFC-135, standardization of binary blob prefixes) important for [PolkaVM integration](https://github.com/paritytech/polkadot-sdk/pull/6704), which is one of my main goals for the current year. It will allow for less resource-hungry and much more deterministic execution. The RFC was accepted by Fellows and [preliminarly implemented](https://github.com/paritytech/polkadot-sdk/pull/6704/commits/66eb9d961eb2804fccdb767e20f23e675779f901) by myself as a part of PolkaVM integration PR.

Last but not least, I communicated with most of you directly or indirectly, hopefully making me a core part of the team.

As for the formal requirements:
* I am a person who is *de facto* responsible for the PVF execution host and candidate validation pipeline in general, which is obviously an important part of the protocol. The aforementioned RFC-135 is a peer-reviewed publication on that topic, as the Manifesto requires;
* A semi-technical article considering Polkadot, authored by me and published in the Polkadot blog, was [Async Backing: The way to 10x throughput lift on parachains](https://polkadot.com/blog/the-way-to-a-10x-throughput-lift-on-parachains).

Therefore, I am applying for the promotion to rank II member. I would lay my right hand on the spec to swear loyalty, but we don't have a spec (see "Concerns" section below). 

Sincerely yours,

Someone Unknown

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

- [x] Concern(s): 
While working on RFC-135, I found out we don't have a solid up to date protocol spec. I find the matter really disturbing and worth discussing, and I would like to speak up on that topic at the next in-person Fellowship meeting.

- [ ] Comment(s):