feat!: Fernet

[LHerskind]

---

To be discussed:

• We probably need to have both sequencer and reward_recipient such that they can be specified separately 🤔.
• Should we keep "history" (header hashes) in storage making it easy to enforce the bonds? Alternatively, at verification we can lookup if there is a bond, and if there is mark it as "available for withdrawal".
• What should the simple strategy look like? For sandbox just using propose if you are winner would do fine.

---

To implement Fernet as outlined from the yellow paper, a lot of tasks spanning the code-base is to be completed.

Preparation

Preview Give feedback

1. feat: Data Availability Oracle #3821
   3 of 3
   T-tracking +1
2. Align block structure with yellow paper #3533
   20 of 21
   T-tracking +1
   

Ethereum Contract Tasks

• Staking
  • We need some ability to deposit assets and in return be eligible to propose blocks.
  • There might need to be a enter/exit delay.
  • The receipt could be transferrable or not, it is really up to the instance. Making them transferrable can essentially be done through a 1-hop contract similar to Lido in the middle, so the actual diff might be less than expected.
  • Slashing rules. Right now it don't seem like there actually is staking.
• RANDAO values.
  • mapping(block_number => randao) randaos
  • We should have some way to map a block number to a RANDAO value. How exactly this value is filled is still do be figured out.
• Phases
  • Proposal: The proposal must be put on L1.
    • A "proposal" is a commitment to the block header following the definition from the yellow paper.
    • We keep track of only the currently winning proposal
    • Proposals are scored based on keccak256(randaos[l2_block_number], l2_block_number, proposer_address)
      • The l2_block_number might be redundant as it is influencing the randao value used.
    • When proposing, proposer_address = msg.sender.
    • If the proposal have a better score, it replaces the current winner, otherwise the tx reverts.
    • Proposals are only accepted when in the proposal phase
  • Prover commitment
    • A bond is put up for the specific proposal.
    • The bond must be put up by the sequencer, or the sequencer must have approved it.
      • This can be sequencer == msg.sender
      • or sequencer have provided a signature where address_recovered == sequencer. Over the inputs for the function call.
    • For sequencer that desire to be maximally following the markets, could use a contract to deposit in that integrate with a market contract etc.
    • The bond can only be recovered if the block made its way into the history.
      • If we keep track of the history in the state of the contract, we can simply lookup if the l2 block indeed was inserted or not.
  • Backup
    • In the case that no bond have been put up. It is a free for all.
    • I'm thinking that we can simply have a phase in the sequencer selection contract, and then it can be queried for a specific block.
    • If we query the phase and no bond was put up, it should be backup
    • Otherwise should return the active phase AND if waiting for proof submission it should return the tuple (phase, sequencer).
  • Reveal
    • Unclear if this process is directly desired as part of the sequencer selection. Regardless, it must be published before the verification can happen.
    • This should use the availability oracle that we spoke about in the Yellow-paper, but are still to implement.
  • Verification
    • The header and proof is passed to the state transitioner.
    • The state transitioner check what state the sequencer selector is in
      • if in backup continue
      • if in proof_submission the sequencer value fetched must match the sequencer of the block AND the block must match what was committed to in the commitment phase, i.e., can be checked by hashing the header and then comparing it to the value stored in sequencer_selection.
      • [?] We probably need to have both sequencer and reward_recipient such that they can be specified separately 🤔.
    • The state transitioner otherwise progresses as it usually does
    • The state transitioner pays out rewards to the reward_recipient.
      • These rewards will be based on a call to governance but for now, we can just have a claim_rewards(to, amount) function where amount will be the amount instance is trying to pay out, if amount > claimable by the instance, it should revert, if passing type(uint256).max as amount simply spend the remaining claimable.
      • The minting logic will be handled by the governance registry, but we can mock it with just a wrapper around a mint function initially.

Ethereum Contracts

Preview Give feedback

1. Implement "staking" (locking) for sequencer privileges
2. Implement block_number => randao map function
3. Implement Proposal phase
4. Implement Prover commitment phase
5. Implement Backup phase
6. Implement Verification (finalization) Phase + reward payout

Circuit tasks

• The changes to the circuits are fairly minimal.
• The reward_recipient should be added.
  • What is the benefit of reward_recipient? It becomes much simpler to collect rewards in cold storage than if it is the same entity that needs to participate in some of the phases or create signatures. Also for operators that operate multiple sequencers it is much simple for them to aggregate their rewards.

Tasks

Preview Give feedback

1. Add reward recipient

Node (sandbox)

• Need a split of nodes which use different strategies for proposing.
  • Full-node that just syncs and participate in network but don't propose
  • Backup which is a full-node that will propose blocks if in backup phase (don't stake but need ethereum wallet to publish block)
  • Sequencer, a full-node that deposit funds and participate in SS
• Default sandbox node should be sequencer type and deposit as part of its setup
• The node software needs to listen to the sequencer selection contract for phases
• The node software needs to follow a strategy for proposing blocks.
  • A strategy could be only propose if you are the "winner", e.g., compute everyones scores and then propose if you have the highest.
  • Another would be propose if you are top 10% etc.
• The sandbox should be fully self-proving for now (no actual proving).
• For the sandbox we can accept going with pure self-proving, and putting up the bond itself
  • We shall run a multi-sequencer (all self-proving) end-to-end test to replace the current p2p test.

Node Tasks

Preview Give feedback

1. Implement SS for node that follows the contract
2. Write strategies for proposing blocks
3. Node settings for (full, backup, sequencer)
4. Standard sandbox node should be sequencer and deposit as part of setup
5. E2E test with a set of nodes all run the SS following the strategy
6. E2E test with a node that run SS and some full that just participate in network
7. E2E test with a set of nodes that never propose, and a backup that should propose
8. E2E test with set of nodes that all run SS with a strategy that make multiple propose and "compete"

[Cooper-Kunz]

Slashing rules. Right now it don't seem like there actually is staking.

At the moment, I do not think there are any acceptable sequencer slashing conditions. This is more for registration sybil resistance, and future proofing to more easily enable any future slashing conditions, than anything. According to some ethereum documentation, staking is the "act of depositing tokens to activate validator software" (ref) which (as far as I know) should be aligned with the definitions being used in the yellowpaper.

The state transitioner pays out rewards to the reward_recipient.

There should be (up to) 3 reward_recipients, correct? Maybe I'm out of context. But the current sequencer, the prover address committed to, and the address that submits the rollup to L1. For the initial instance it may be ok to assume that these are vertically integrated and therefore a single entity. Just wanna clarify what this intention is

Node (sandbox)

Pardon my ignorance but why does the sandbox itself need to implement Fernet? Running a local developer environment should probably not incur the overhead of it.. right? Is this just a semantic difference, or am i misunderstanding/silly? 🤔

Need a split of nodes which use different strategies for proposing.

This is a nice to have in my opinion. For the initial task / MVP I'd also consider just "everyone tries to propose always" and then we can iterate on strategies in subsequent releases? In the initial sandbox &/or small test environment I imagine there won't be a prohibitive number of participants.

[LHerskind]

According to some ethereum documentation, staking is the "act of depositing tokens to activate validator software" (ref) which (as far as I know) should be aligned with the definitions being used in the yellowpaper.

But with a validator, your funds are at stake. Image related.

The state transitioner pays out rewards to the reward_recipient.

The reward_recipient was what I though of as a sequencer controlled address. Think I was just a bit too quick when here.

Why does the sandbox itself need to implement Fernet

Sandbox is essentially a local node. It might be how people are testing contracts etc, but it is also how we test the node atm 🤷. For a pure sandbox mode, it would likely just be running with shorter timeframes such that it can always run in backup -> the backup strategy might be better for that then 🤷

[LHerskind]

There should be (up to) 3 reward_recipients, correct? Maybe I'm out of context. But the current sequencer, the prover address committed to, and the address that submits the rollup to L1. For the initial instance it may be ok to assume that these are vertically integrated and therefore a single entity. Just wanna clarify what this intention is

Actually, we would likely have 4 here. 1 for fees paid within the rollup, 1 for block rewards, 1 for prover and then 1 for the publisher.