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 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 from scratch to demonstrate fully deterministic execution behavior;
• Opening a discussion about UX implications of Polkadot worker binaries separation and co-authoring a relevant PR implementing that important change;
• Proposing a solution for the long-standing worker version mismatch problem and mentoring an external contributor through implemening that solution;
• Implementing a custom wrapping memory allocator 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;
• High level PVF non-determinism discussion;

I proposed a change to the protocol (RFC-135, standardization of binary blob prefixes) important for PolkaVM integration, 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 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.

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

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