Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

Decouple Staking and Election - Part 3: Signed Phase #7910

Merged
103 commits merged into from
Jun 28, 2021

Conversation

kianenigma
Copy link
Contributor

@kianenigma kianenigma commented Jan 15, 2021

Attempt to break down #7319. Part 3

Part1: #7908
Part 2: #7909

Adds signed phase, relatively light to review.

polkadot companion: paritytech/polkadot#2793

@kianenigma kianenigma added A0-please_review Pull request needs code review. B0-silent Changes should not be mentioned in any release notes C1-low PR touches the given topic and has a low impact on builders. labels Jan 15, 2021
@apopiak apopiak changed the title Decouple Stkaing and Election - Part3: Signed Phase Decouple Staking and Election - Part 3: Signed Phase Jan 28, 2021
Base automatically changed from kiz-election-provider-2-two-phase-unsigned to master February 23, 2021 14:46
Copy link
Contributor

@emostov emostov left a comment

Choose a reason for hiding this comment

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

Looks good to me with the caveat that I did not carefully examine the benchmarking code and my rust is still developing :)

I left several low level rust questions and some small suggestions/nits

Copy link
Member

@shawntabrizi shawntabrizi left a comment

Choose a reason for hiding this comment

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

looks reasonable to me

didn't dive super deep, but reviewed tests and eyed through the logic

The signed reward base can be treated as a constant. It can in principle
change, but even if it's updated in the middle of an election, it's
appropriate to use the current value for the winner.
Makes it easier to see who won/lost with signed submissions.
@coriolinus
Copy link
Contributor

bot merge

@ghost
Copy link

ghost commented Jun 28, 2021

Waiting for commit status.

@ghost ghost merged commit c44e5d6 into master Jun 28, 2021
@ghost ghost deleted the kiz-election-provider-3-signed-phase branch June 28, 2021 09:20
ordian pushed a commit to paritytech/polkadot that referenced this pull request Jun 28, 2021
…2793)

* Companion for Decouple Staking and Election - Part 3: Signed Phase

paritytech/substrate#7910

* remove some config types

* allow up to 5 signed submissions on polkadot and kusama

* signed phase is equal induration to unsigned phase

* use chain defaults for base and per-byte deposits; >= 16 SignedMaxSubmissions

* use a small but non-trivial solution reward

* reduce signed deposit per byte fee

* reduce signed reward, adjust polkadot expected soln size

* copy submit benchmark from substrate

* demo calculating an appropriate fee for the signed reward

Unfortunately, this doesn't work: it needs to be a constant function,
and AFAIK there's no way to make a trait method constant.

* SignedRewardBase is 1.5x the fee to submit a signed solution

* all chains use deposit byte of base per 50k

* update Substrate

* cargo update -p pallet-election-provider-multi-phase

Co-authored-by: parity-processbot <>
@jakoblell jakoblell added D1-audited 👍 PR contains changes to fund-managing logic that has been properly reviewed and externally audited and removed D9-needsaudit 👮 PR contains changes to fund-managing logic that should be properly reviewed and externally audited labels Jul 1, 2021
kianenigma added a commit to kianenigma/seeding that referenced this pull request Sep 27, 2022
# Membership Request 

Hi, I am Kian Paimani, known as @kianenigma. I have been working on Polkadot/Kusama through Parity since February 2019 and I can categorize my main contributions to Polkadot's ecosystem as follows: 

1. Maintaining and developing the staking sub-system.
2. General FRAME development, especially testing and quality assurance. 
3. Polkadot-native side-projects. 
4. Education 

> My first contribution to Polkadot is also indeed related to staking: paritytech/substrate#1915

### Staking system

I joke as the Polkadot staking to be both my blessing and my curse over the years. I started working on it since the first days that I joined this ecosystem and the work [is ongoing ever since](https://github.com/orgs/paritytech/projects/33/views/9). In the past, I focused on making sure that the staking system is secure and to some extent scalable. More recently, I coordinated the (imminent) launch of Nomination Pools. Nowadays I also put an extra effort on making sure that this sub-system of Polkadot is *sustainable*, through code refactor and educating other core developers. 

Lastly, I have been the main author of the [Polkadot staking newsletter](https://gist.github.com/kianenigma/aa835946455b9a3f167821b9d05ba376), which is my main attempt at making the entire complexity and development of this part of the protocol transparent to the end-users.

I expect myself to contribute *directly* to the staking system for at least another ~12, if not more, and afterwards having the role of an advisor. 

Some notable contributions: 

- paritytech/substrate#4517
- paritytech/substrate#7910
- paritytech/substrate#6242
- paritytech/substrate#9415
- paritytech/polkadot#3141
- paritytech/substrate#11212
- paritytech/substrate#12129

### FRAME 

Historically, I have contributed a variety of domains in FRAME, namely: 

- Early version of the weight system paritytech/substrate#3816 paritytech/substrate#3157
- Early version of the transaction fee system
- Primitive arithmetic types paritytech/substrate#3456
- Council election pallet paritytech/substrate#3364

Many of which were, admittedly, a PoC at most, if not considered "poor". I am happy that nowadays many of the above have been refactored and are being maintained by new domain experts. 

These days, I put most of my FRAME focus on testing and quality assurance. Through my work in the staking system, I have had to deal with the high sensitivity and liveness requirement of protocol development first hand (I believe I had to do among the [very first storage migrations](paritytech/substrate#3948) in Kusama) and consequently I felt the need to make better testing facilities, all of which have been formulated in https://forum.polkadot.network/t/testing-complex-frame-pallets-discussion-tools/356. Some relevant PRs:

- paritytech/substrate#8038
- paritytech/substrate#9788
- paritytech/substrate#10174

Regardless of wearing the staking hat, I plan to remain a direct contributor to FRAME, namely because I consider it to be an important requirements of successfully delivering more features to Polkadot's ecosystem. 

### Polkadot-Native Side Projects

I have started multiple small, mostly non-RUST projects in the polkadot ecosystem that I am very happy about, and I plan to continue doing so. I have not yet found the time to make a "polished product" out of any of these, but I hope that I can help foster our community such that someday a team will do so. I consider my role, for the time being, to *put ideas out there* through these side projects. 

- https://github.com/substrate-portfolio/polkadot-portfolio/
- https://github.com/kianenigma/polkadot-basic-notification/
- https://github.com/paritytech/polkadot-scripts/
- https://github.com/paritytech/substrate-debug-kit/

### Education 

Lastly, aside from having had a number of educational talks over the years (all of which [are listed](https://hello.kianenigma.nl/talks/) in my personal website), I am a big enthusiast of the newly formed Polkadot Blockchain Academy. I have [been an instructor](https://singular.app/collectibles/statemine/16/2) in the first cohort, and continue to contribute for as long and as much as I can, whilst still attending to the former 3 duties. 

---

With all of that being said and done, I consider myself at the beginning of the path to Dan 4, but happy to start at a lower one as well.
bkchr added a commit to polkadot-fellows/seeding that referenced this pull request Sep 27, 2022
# Membership Request 

Hi, I am Kian Paimani, known as @kianenigma. I have been working on Polkadot/Kusama through Parity since February 2019 and I can categorize my main contributions to Polkadot's ecosystem as follows: 

1. Maintaining and developing the staking sub-system.
2. General FRAME development, especially testing and quality assurance. 
3. Polkadot-native side-projects. 
4. Education 

> My first contribution to Polkadot is also indeed related to staking: paritytech/substrate#1915

### Staking system

I joke as the Polkadot staking to be both my blessing and my curse over the years. I started working on it since the first days that I joined this ecosystem and the work [is ongoing ever since](https://github.com/orgs/paritytech/projects/33/views/9). In the past, I focused on making sure that the staking system is secure and to some extent scalable. More recently, I coordinated the (imminent) launch of Nomination Pools. Nowadays I also put an extra effort on making sure that this sub-system of Polkadot is *sustainable*, through code refactor and educating other core developers. 

Lastly, I have been the main author of the [Polkadot staking newsletter](https://gist.github.com/kianenigma/aa835946455b9a3f167821b9d05ba376), which is my main attempt at making the entire complexity and development of this part of the protocol transparent to the end-users.

I expect myself to contribute *directly* to the staking system for at least another ~12, if not more, and afterwards having the role of an advisor. 

Some notable contributions: 

- paritytech/substrate#4517
- paritytech/substrate#7910
- paritytech/substrate#6242
- paritytech/substrate#9415
- paritytech/polkadot#3141
- paritytech/substrate#11212
- paritytech/substrate#12129

### FRAME 

Historically, I have contributed a variety of domains in FRAME, namely: 

- Early version of the weight system paritytech/substrate#3816 paritytech/substrate#3157
- Early version of the transaction fee system
- Primitive arithmetic types paritytech/substrate#3456
- Council election pallet paritytech/substrate#3364

Many of which were, admittedly, a PoC at most, if not considered "poor". I am happy that nowadays many of the above have been refactored and are being maintained by new domain experts. 

These days, I put most of my FRAME focus on testing and quality assurance. Through my work in the staking system, I have had to deal with the high sensitivity and liveness requirement of protocol development first hand (I believe I had to do among the [very first storage migrations](paritytech/substrate#3948) in Kusama) and consequently I felt the need to make better testing facilities, all of which have been formulated in https://forum.polkadot.network/t/testing-complex-frame-pallets-discussion-tools/356. Some relevant PRs:

- paritytech/substrate#8038
- paritytech/substrate#9788
- paritytech/substrate#10174

Regardless of wearing the staking hat, I plan to remain a direct contributor to FRAME, namely because I consider it to be an important requirements of successfully delivering more features to Polkadot's ecosystem. 

### Polkadot-Native Side Projects

I have started multiple small, mostly non-RUST projects in the polkadot ecosystem that I am very happy about, and I plan to continue doing so. I have not yet found the time to make a "polished product" out of any of these, but I hope that I can help foster our community such that someday a team will do so. I consider my role, for the time being, to *put ideas out there* through these side projects. 

- https://github.com/substrate-portfolio/polkadot-portfolio/
- https://github.com/kianenigma/polkadot-basic-notification/
- https://github.com/paritytech/polkadot-scripts/
- https://github.com/paritytech/substrate-debug-kit/

### Education 

Lastly, aside from having had a number of educational talks over the years (all of which [are listed](https://hello.kianenigma.nl/talks/) in my personal website), I am a big enthusiast of the newly formed Polkadot Blockchain Academy. I have [been an instructor](https://singular.app/collectibles/statemine/16/2) in the first cohort, and continue to contribute for as long and as much as I can, whilst still attending to the former 3 duties. 

---

With all of that being said and done, I consider myself at the beginning of the path to Dan 4, but happy to start at a lower one as well.

Co-authored-by: Bastian Köcher <git@kchr.de>
ggwpez pushed a commit to ggwpez/runtimes that referenced this pull request Mar 10, 2023
…2793)

* Companion for Decouple Staking and Election - Part 3: Signed Phase

paritytech/substrate#7910

* remove some config types

* allow up to 5 signed submissions on polkadot and kusama

* signed phase is equal induration to unsigned phase

* use chain defaults for base and per-byte deposits; >= 16 SignedMaxSubmissions

* use a small but non-trivial solution reward

* reduce signed deposit per byte fee

* reduce signed reward, adjust polkadot expected soln size

* copy submit benchmark from substrate

* demo calculating an appropriate fee for the signed reward

Unfortunately, this doesn't work: it needs to be a constant function,
and AFAIK there's no way to make a trait method constant.

* SignedRewardBase is 1.5x the fee to submit a signed solution

* all chains use deposit byte of base per 50k

* update Substrate

* cargo update -p pallet-election-provider-multi-phase

Co-authored-by: parity-processbot <>
ggwpez pushed a commit to ggwpez/runtimes that referenced this pull request Jul 13, 2023
…2793)

* Companion for Decouple Staking and Election - Part 3: Signed Phase

paritytech/substrate#7910

* remove some config types

* allow up to 5 signed submissions on polkadot and kusama

* signed phase is equal induration to unsigned phase

* use chain defaults for base and per-byte deposits; >= 16 SignedMaxSubmissions

* use a small but non-trivial solution reward

* reduce signed deposit per byte fee

* reduce signed reward, adjust polkadot expected soln size

* copy submit benchmark from substrate

* demo calculating an appropriate fee for the signed reward

Unfortunately, this doesn't work: it needs to be a constant function,
and AFAIK there's no way to make a trait method constant.

* SignedRewardBase is 1.5x the fee to submit a signed solution

* all chains use deposit byte of base per 50k

* update Substrate

* cargo update -p pallet-election-provider-multi-phase

Co-authored-by: parity-processbot <>
This pull request was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A0-please_review Pull request needs code review. D1-audited 👍 PR contains changes to fund-managing logic that has been properly reviewed and externally audited
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

9 participants