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

Mid-term protection for multistaking #3635

Closed
AurelienFT opened this issue Mar 3, 2023 · 2 comments
Closed

Mid-term protection for multistaking #3635

AurelienFT opened this issue Mar 3, 2023 · 2 comments
Assignees

Comments

@AurelienFT
Copy link
Contributor

Context

Currently we are lacking of protection against multi-staking. We need to have some protections for the mainnet before implementing the solution that our research team developed : https://arxiv.org/pdf/2302.10009.pdf

Current implementation

Whenever a valid block (or a header) is received we will add it to our consensus, it will be processed and the cliques calculations will happens. In case of thousands of blocks at the same slot we could store and process thousands of cliques

Mid term solution

We will implement some rules that will prevent multiples blocks for the same slot to be processed

Current implementation

We receive a block or a header through massa-protocol and we send it to massa-consensus and the consensus make the clique calculation with this block. (If it's just a header massa-consensus ask to massa-protocol to retrieve the rest of the block) If we miss some parents of this block massa-consensus ask to massa-protocol to retrieve them

Changes implemented

The first two header (or full block) received for a slot are saved and follow the current workflow. Having two blocks for a slot that are propagated allow all the network to be aware that there is a double stake.

Any block after this two received for the same slot will not be processed by consensus.

Point of attention

If we receive a block that has as a parent one the block we refuse at previous slot because it was a third one we need to still be able to ask it through the consensus and not be blocked by protocol that have saved him in cache etc...

@AurelienFT
Copy link
Contributor Author

AurelienFT commented Mar 3, 2023

@damip ping for review

@AurelienFT AurelienFT self-assigned this Mar 6, 2023
@AurelienFT
Copy link
Contributor Author

Done in #3646

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant