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

[draft] update MCR to include a confirmer role #713

Draft
wants to merge 14 commits into
base: main
Choose a base branch
from

Conversation

apenzk
Copy link

@apenzk apenzk commented Oct 18, 2024

Summary

  • RFCs: $\emptyset$.
  • MIPs: To be written.
  • Categories: protocol-units

Introduces the role of Confimer in the MCR contract. The confirmer is selected based on L1 randomness and serves for a certain term period.

Motiviation

Currently rewarding based on time of commitment and the complexity that arises from the last committer having higher commit cost and different rewards may cause race conditions, co-location and centralization.

This can be resolved by separating the tasks into attesters and confirmer, where confirmer is a new role that converts provided attester commitments into a proof and update the state. Note that the confirmer has not to be from the epoch that the L2-block or the attestations are. The sole role of the comitter is to advance the acceptance.

As a simple first PoC the current confirmer could be selected based on "slow" randomness from L1. E.g. using hashes from L1-blocks.

Changelog

  • get the current confirmer based on L1-block hashes
  • give the task for updating the new state to the current confirmer

Testing

Outstanding issues

  • investigate for better randomness
  • adapt the reward scheme
  • allow volunteering attesters to also confirm (but no reward)


address[] memory attesters = getAttesters();
// map the blockhash to the attesters
uint256 leaderIndex = uint256(blockHash) % attesters.length;
Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm sure this is in the MDs that I haven't gotten to you, but doesn't this particular election allow a leader to just mine for a blockhash that would elect themselves. Really, we would want quorum-based leader election if we are going to introduce a leader.

Copy link
Author

@apenzk apenzk Oct 18, 2024

Choose a reason for hiding this comment

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

It's L1 blockhash not L2. My assumption is L1 blockhash is not predictable or cannot be influenced by the L2 validators

Copy link
Author

Choose a reason for hiding this comment

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

(Long term I think this is also not a great assumption but it buys time to look into a better randomness solution )

@apenzk apenzk changed the title [draft] update MCR to use a leader based approach [draft] update MCR to include a confirmer role Oct 21, 2024
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

Successfully merging this pull request may close these issues.

2 participants