Evidence-0002: Retention at Rank I

Report Date	Date of submission (2024/10/01)
Submitted by	Alin Dima

Member details

• Matrix username: @alin:parity.io
• Polkadot address: 148f8D1P4CP2tV8JuaVHzEXQQgj3jBxEg3k9qZydPzkJjbQG
• Current rank: I
• Date of initial induction: 2024-04-26
• Date of last report: 2024/06/21
• Area(s) of Expertise/Interest: Parachains consensus, Elastic Scaling

Reporting period

• Start date: 2024/06/22
• End date: 2024/10/01

Evidence

My contributions in these past months have been mostly centered around Elastic Scaling, along with other general endeavours with bugfixing and refactoring across different components.

Elastic Scaling and Coretime

I have identified a bug in the relay parent progression check done in the runtime and fixed it: https://github.com/paritytech/polkadot-sdk/pull/5113. I made sure to perform the required backports of the PR to the fellowship repo so that the issue does not ever surface on production networks.

I identified the root-cause of this issue, which impacted the backing rewards of validators for fork-producing parachains. The fix for this was a major redesign of the prospective-parachain subsystem, which I successfully implemented and tested on private testnets: https://github.com/paritytech/polkadot-sdk/pull/4937. I believe the complexity and impact of this change, together with the demonstrated autonomy is supportive of my eventual promotion to the IInd rank (which is not yet possible due to the artificial 1-year waiting time between ranks).

I implemented the cumulus parts of RFC103, which enables having an untrusted collator set when using elastic scaling:

• https://github.com/paritytech/polkadot-sdk/pull/5372
• https://github.com/paritytech/polkadot-sdk/pull/5888

I worked on removing the scheduling TTL from the relay chain runtime, which was preventing proper core-sharing between paras: https://github.com/paritytech/polkadot-sdk/pull/5461. Doing this, I also refactored the runtime code and discovered an avenue for further improving the design of the scheduler module: https://github.com/paritytech/polkadot-sdk/issues/5529.

I opened the referendums for bumping AsyncBackingParams.max_candidate_depth to 6 (enabling the use of the elastic scaling MVP):

• https://kusama.subsquare.io/referenda/455
• https://kusama.subsquare.io/fellowship/referenda/87

Root-causing and fixing other network issues

• Root-caused and reproduced relay chain node panic: https://github.com/paritytech/polkadot-sdk/issues/5421#issuecomment-2301509454
• Root-caused and fixed node memory leak: https://github.com/paritytech/polkadot-sdk/pull/5321

Other contributions:

Polkadot-sdk reviews: https://github.com/paritytech/polkadot-sdk/pulls?q=is%3Apr+reviewed-by%3Aalindima

RFCs reviewed: https://github.com/polkadot-fellows/RFCs/pulls?q=is%3Apr+reviewed-by%3Aalindima+

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 1 referenda in which I was eligible to vote (i.e 0 % voting activity).	I will make sure to pay closer attention to referendums that I am allowed 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):