[draft] update MCR to include an acceptor role

[apenzk]

Summary

• MIPs: MIP-37.
• Categories: protocol-units

Introduces the role of acceptor in the MCR contract, see MIP-37.

The acceptor

• should be selected based on L1 randomness
• serves for a certain term period.
• should be checked for liveness
• should receive rewards for service
• should be replaceable by volunteer attester
• volunteer attester should receive rewards if acceptor is not live.

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 acceptor, where acceptor is a new role that converts provided attester commitments into a postconfirmation and update the state (i.e., rollover to new epochs). The sole role of the attester becomes to commit.

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

Changelog

• add acceptor role: attesters do not postconfirm or rollover anymore
• postconfirmation by acceptor
• rollover by acceptor
• anyone can be acceptor

Testing

forget test ok
cargo check ok
cargo test fail

Outstanding issues

• acceptor is always live
• everyone can attest
• no rewards

[l-monninger]

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.

[apenzk]

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

[apenzk]

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