Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

alindima: retain at rank 1 #100

Merged
merged 1 commit into from
Jan 13, 2025
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
75 changes: 75 additions & 0 deletions evidence/alin/0003-alin-retain-I-2024.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,75 @@
# Evidence-0002: Retention at Rank I

| | |
| --------------- | ------------------------------------------------------------------------------------------- |
| **Report Date** | Date of submission (2024/12/19) |
| **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/10/01
- Area(s) of Expertise/Interest: Parachains consensus, Elastic Scaling, Availability


## Reporting period

- Start date: 2024/10/01
- End date: 2024/12/19


## Evidence

My contributions in these past months have been mostly centered around Elastic Scaling.

### Elastic Scaling

I have continued the implementation of [RFC103](https://github.com/polkadot-fellows/RFCs/pull/103), which enables having an untrusted collator
Copy link
Member

@ggwpez ggwpez Jan 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please explain a bit as to why this is important for Polkadot's broader mission?
It seems relevant to me, but i dont really understand what the impact is.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's important for decentralisation and resilience. More motivation is included in the RFC text:

For Elastic Scaling, it prevents anyone who has acquired a valid collation to DoS the parachain by providing the same collation to all backing groups assigned to the parachain. This can happen before the next valid parachain block is authored and will prevent the chain of candidates from being formed, reducing the throughput of the parachain to a single core.

If you agree, I wouldn't modify the text of the evaluation now, because there's already a referendum up for vote. Thanks for the feedback, I'll try to be more explicit in my next evaluation

set when using elastic scaling:
- creating v2 receipts on collation-generation: https://github.com/paritytech/polkadot-sdk/pull/5908
- refactoring and hardening the core index check: https://github.com/paritytech/polkadot-sdk/pull/6217
- validating the receipt version when fetching the collation: https://github.com/paritytech/polkadot-sdk/pull/6011
- adding e2e zombienet-sdk test that verifies elastic scaling works both with the old and new receipt versions: https://github.com/paritytech/polkadot-sdk/pull/6452
- successfully debugged 12 core elastic scaling which will enable 500ms block times: https://github.com/paritytech/polkadot-sdk/issues/6858

I have also started updating the elastic scaling enablement guide for parachain teams (PR still open): https://github.com/paritytech/polkadot-sdk/pull/6739

Another notable contribution is my involvement in the design discussions around [streamlined block production](https://github.com/paritytech/polkadot-sdk/issues/5190#issuecomment-2505949587)
I researched and proposed an alternative implementation idea which would achieve the desired result in a much shorter time
(thanks to the simpler design, despite it being less efficient). I successfully developed a PoC and tested it with gluttons and spammening parachains.
The code is available here: https://github.com/paritytech/polkadot-sdk/tree/alindima/post-state-poc

### Other contributions:

- Offering significant guidance and help on the collation fetching fairness PR: https://github.com/paritytech/polkadot-sdk/pull/4880
- I have started offering technical mentorship for a new hire inside Parity's parachains team (which I'm a part of)
- Fix a best backable chain reversion bug in prospective parachains: https://github.com/paritytech/polkadot-sdk/pull/6417
- Rewriting some of the flaky zombienet tests to zombienet-sdk: https://github.com/paritytech/polkadot-sdk/pull/6757

Polkadot-sdk reviews: https://github.com/paritytech/polkadot-sdk/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 0 referenda in which I was eligible to vote (i.e 100 % voting activity). |There were no referendums available for my rank 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):