| Report Date | Date of submission (2025-11-19) |
| Submitted by | rockbmb |
I have been working on Polkadot continuously since September 2024.
During this time, as mentioned in my request for induction, I have focused mainly on testing protocol components of the Polkadot SDK, such as pallets, runtimes and networks, through the Polkadot Ecosystem Tests (PET) project.
For promotion to I Dan, §6.2.1. of the Manifesto states as a requirement:
Three clear examples of a modest but substantial contribution to protocol development
Below, I list these, and explain why they are sufficient for I Dan.
About I Dan, §6.2.1. of the Manifesto states another expectation:
being available and playing a crucial operational role for a network fix
I assisted with the testing process for the Asset Hub Migration in the Westened and Paseo testnets, and in the Kusama and Polkadot networks. During the run-up to the migration, the tests I wrote as part of PET were used to validate the functionality of relay chain/asset hub runtimes (and other runtimes, too).
Furthermore, upon the Kusama (Oct 7th)/Polkadot (Nov 4th) migrations, these PET tests were part of larger
manual + automated (CI) testing processes to validate the migration's result, validation which was provided in real-time.
For more, see the ahm-dryrun project, where
PET was used in AHM dry-runs to validate relay/AH runtimes.
Some examples of findings (Polkadot SDK/Fellowship Runtimes):
As part of the previous point, but also as its own endeavour, I used PET to test protocol components of the Kusama/Polkadot networks. An extensive (but not exhaustive) list of pallets/components tested can be found here.
From this came some contributions to the Polkadot SDK:
Currency traits and others using Fungible), and once the runtime consumes the upstream fix, the suite can be switched to ensure compliancepallet-revive gas-meteringUnder the supervision of Fellowship Member Alex, I worked on implementing EIP-150 in pallet-revive's gas metering.
EIP-150 enforces an artificial stack depth limit to contract calls by limiting the gas available to a child call to
63/64ths of the parent's available gas at the time of the call.
Otherwise, the call limit would be 1024. At 1023 calls, subsequent attempts to increase the call stack would silently fail, but continue contract execution, which opens a class of call depth attacks (e.g. maliciously call something 1023 times before a certain call).
With EIP-150, there'd be an (inversely) exponential decay in the amount of gas available: no gas -> contract call fails and changes would be reverted.
Ultimately, the conclusion was that it was not possible at the time, as it removed the possibility of dry-running a contract call's execution - this is essential to estimating the computational cost in Polkadot-native weight (ref time/proof size).
Not being able to implement it in a straightforward way means that 1-to-1 parity with the EVM execution model will require an alternative gas metering solution than the one I attempted.
N/A
Thanks to seadanda, Oliver, muharem, Ankan, kianenigma, Alex for all the assistance with my work in the Polkadot SDK, and Bryan Chen for reviewing all of my PET/Chopsticks contributions.
No referendum was created