Proposal: separate Seeder role from Block Generator

[fed-franz]

Summary

To avoid potential MEV attacks by block generators, we propose to delegate the computation of the seed value for the next-round sortition to a different provisioner than the block generator.
The proposed seed is agreed upon through quorum consensus.

The selection of the seeder is done via Sortition during the Validation step. In particular, one of the validators is also appointed to produce the new seed (by signing the old one).

Relevant Context

In the current protocol, the seed used for the Sortition process is computed at each round by the block generator and included in the candidate block. As such, when creating the block, the generator can also predict the generator(s) of the next round/block.
In a provisioner is selected for two (or more) consecutive round, or is colluded with future generators, this predictability can be exploited for potential MEV attacks.

To prevent this situation, the generator must be oblivious of the next generator at the time of block construction. This is achieved by computing the seed for the next round after the candidate block is created, so that the generator has no knowledge of the next generator when adding transactions to the block.

Detailed Description

This DIP proposes the following scheme:
In each iteration

• In Proposal, the block generator proposes the candidate block, not containing the new seed
• In Validation:
• one of the committee members is appointed as the Seeder (this can be, for instance, the 1st member of each committee)
• the seeder computes the new seed by signing the old seed, and attaches the new seed to its vote
• In Ratification, committee members only vote Valid Quorum if the vote from the Seeder is included and
  it contains the new seed as a valid signature

Alternatives Solutions

A desirable solution would be to have one committee (e.g. the Validation one) compute the new seed with a threshold signature. This would remove the requirements of a second specific provisioner to participate in the iteration.
However, current Distributed Key Generation (DKG) schemes would require, at least, one additional round to make committee members generate the shared key.
As this would introduce a considerable overhead to the consensus protocol, this solution has been discarded.

This can be reconsidered in the future, if new DKG are discovered that allowed creating a shared key without requiring an extra round of messages.
Ideally, the protocol should be able to derive a committee key from either their public keys, or from some information added by each provisioner in the stake transaction.

[goshawk-3]

To avoid potential MEV attacks by block generators, we propose to delegate the computation of the seed value for the next-round sortition to a different provisioner than the block generator.

Isn't MEV attack about a scenario where an attacker submits transactions (with proper gas) before/after the victim transaction to benefit from an arbitrage trade? (weirdly in HFT world , MEV is not an attack but is considered a strategy)

The selection of the seeder is done via Sortition during the Validation step. In particular, one of the validators is also appointed to produce the new seed (by signing the old one).

Does this simply assume that the appointed validator is not also controlled by the owner of the actual Block Generator?

In a provisioner is selected for two (or more) consecutive round, or is colluded with future generators, this predictability can be exploited for potential MEV attacks.

Regardless of the predictability, any attacker can execute MEV attack by simply monitoring mempool and submit txs with proper gas? Am I mistaken?

one of the committee members is appointed as the Seeder (this can be, for instance, the 1st member of each committee)
the seeder computes the new seed by signing the old seed, and attaches the new seed to its vote

If it happens the Seeder is behind the other committee members, isn't it possible that committee members will reach 2/3 quorum on Validation step without knowing the Seeder vote (new seed) thus wasting the iteration?

[goshawk-3]

Instead of appointing a Seeder amongst committee members of Validation step, we may just introduce another step after Selection step.

Proposal - extracts Block Generator that generates the candidate/proposal.
Seed step - extracts Seeder (generator excluded) that generates the seed
Validation - ...
Ratification - ...

[fed-franz]

Isn't MEV attack about a scenario where an attacker submits transactions (with proper gas) before/after the victim transaction to benefit from an arbitrage trade? (weirdly in HFT world , MEV is not an attack but is considered a strategy)

In this context, it refers to the ability of manipulating gas prices but also a more high-level security trading, specific to our scope, by colluding with the next generator (or being the same one). This risk was highlighted by the security audit from Oak and stems from the predictability of the next generator, which allows acting over the span of two or multiple consecutive blocks.

Does this simply assume that the appointed validator is not also controlled by the owner of the actual Block Generator?

Yes. This proposal is meant to mitigate the risk, not to completely solve the problem. A complete solution would require more complex strategies that would add an unacceptable overhead to the protocol.
An additional measure that we discussed is to make the seed dependent on the candidate block (e.g. the new seed could be the signature of the previous seed + the hash of the candidate): this would prevent the colluded seeder from computing the new seed without knowing the candidate itself. In other words for the generator to know the next block producer, it would need to provide the candidate first, slowing down the interaction, and further reducing the available time to preduct the next generator.

Regardless of the predictability, any attacker can execute MEV attack by simply monitoring mempool and submit txs with proper gas? Am I mistaken?

Block generators can always choose transactions to include according to whatever strategy they think more profitable. This is part of the expected behavior of block producers and is not considered as a threat.

If it happens the Seeder is behind the other committee members, isn't it possible that committee members will reach 2/3 quorum on Validation step without knowing the Seeder vote (new seed) thus wasting the iteration?

Yes, this is the main drawback of this solution: it forces the seeder vote to be in the quorum, and thus the iteration to have two specific provisioners to participate (generator+seeder) instead of just one (the generator). This was deemed as a minor drawback, since we always require provisioners to participate and be in sync. We also discussed making this explicit by introducing a soft slash for seeders missing their vote

[fed-franz]

Instead of appointing a Seeder amongst committee members of Validation step, we may just introduce another step after Selection step.

Proposal - extracts Block Generator that generates the candidate/proposal. Seed step - extracts Seeder (generator excluded) that generates the seed Validation - ... Ratification - ...

I think using one of the Validators would be generally more efficient, as it would be integrated in the current protocol (no extra messages would be required).
What would you think would be the advantage of adding a separate step? A part from a "cleaner" design, as I agree this would be.