# Lean rainbow staking design notes

## 1. Intro

This note gives a summary of Lean rainbow staking design, which consists in the specification and testing of Lean Consensus parts related to staker role specialization, enshrined delegation, staker's settings and more.

**NOTE**: This document is WIP

## 2. Functional specification

### 2.1 Staker

Users can opt to deposit ETH and participate in lean Ethereum, by building and securing the protocol. Depending on their preferences, resources and level of sophistication, stakers can have different reasons for participation, like seeking financial returns or altruistically improve on the chain's censorship resistance and hardness.

### 2.2. Intersection of rainbow staking and Lean consensus stack

#### 2.2.1 Roles & nodes design parameters

- Attester role is designed with a 1/N altruistic assumption (at least 1 person in the world who is altruistically doing the calculation of CL proofing in real time). Proving the CL timely each slot is expected to be done on upper-boundary consumer grade devices (the equivalent of 1 high-end laptop CPU, or better).
- Consensus layer clients are stateless from the EL perspective, they are only responsible for verifying the execution proofs and perform data availability sampling on EVM proofs and on the EVM blobs. They can be stateless or stateful from a CL perspective.
- The proposer role is designed as a rational, sophisticated actor. Failing to produce the EL proofs in real-time would count as a miss-slot, losing the associated MEV and fees. An extra penalty for missing the slot is in discussion. Proving the EL timely each slot is a resource-intensive process, demanding significant GPU power. This is a high entry barrier so, until sufficient zk proofing breakthroughs happen on hardware and software, the provision of such real-time proofs will be handled by specialized entities, called provers
- Execution layer clients (functionally similar to today's builders) can be stateful, in order to produce economically valuable EVM blocks. Can also be stateless if they delegate the role to a specialized builder.

### 2.3 Staker role specialization

#### 2.3.1 Attester role

This role is responsible for providing economic security by casting votes (attestations) according
to their view of the chain and proposing blocks.

- stakes in: CL
- stake entry barrier for role: top $2^{14}$
- slashable: YES
- selection mechanism
- attesting: per-slot when part of attesters set
- CL block proposing: proof-of-stake lottery when part of attesters set

#### 2.3.2 Includer role

This role is responsible for the availability of valid inclusion lists that will be part of the EVM
block validation.

##### R&D tracks

Depending on APS and how execution proposer R&D tracks develop.

- CL track
- participates in: CL
- slashable: NO
- selection mechanism: Proof-of-Stake lottery, part of FOCIL
- Resources
- https://ethresear.ch/t/fork-choice-enforced-inclusion-lists-focil-a-simple-committee-based-inclusion-list-proposal/19870/1

- EL track
- participates in: EL
- slashable: NO
- selection mechanism: part of execution tickets (ETs)

#### 2.3.3 (Execution) Proposer role

This role is responsible for building and proposing the EVM blocks.

##### R&D tracks

- No Multi-slot MEV track
- bids in: EL
- payment: cost of EAs
- selection mechanism: execution auctions (EAs)
- Relevant resources
- https://ethresear.ch/t/proposers-do-play-dice-introducing-random-execution-auctions-randeas/20938/1
- https://ethresear.ch/t/execution-auctions-as-an-alternative-to-execution-tickets/19894/1

- Preconfirmations track
- stakes / bids in: EL
- slashing / payment: opportunity cost / cost of the ETs
- selection mechanism: execution tickets (ETs)
- Relevant resources
- https://ethresear.ch/t/execution-tickets/17944

- APS Resources
- https://efdn.notion.site/Attester-Proposer-Separation-Tracker-15bd9895554180c2ac75cb40878ecd33

#### 2.3.4 Delegator role (exploratory)

- A new light protocol role for delegators can be explored, especially if Proposer and Includer get
implemented in EL
- stakes in: CL
- slashable: NO
- selection mechanism: Proof-of-Stake lottery
- Delegators could be randomly selected to countersign for validity messages issued by nodes (blocks, attestations). This would prevent a majority of stakers from engaging in finality reversion. Further research needed for how this would impact liveness.
- Relevant resources
- https://notes.ethereum.org/@vbuterin/staking_2023_10#Consensus-participation

### 2.4 Delegation

#### 2.4.1 Delegation lifecycle

- Each role can be delegated to a target staker and each role can be set as delegatable for other stakers to execute as operators.
- A staker can act either as a delegator or a delegate (never both);
- Self-delegation is not accepted.
- All-or-nothing delegation (many-to-1), or Many-to-many.
- Delegation operations:
- Delegate
- Undelegate
- Redelegate

#### 2.4.2 Staker's matrix

The staker's settings: a modular configuration

| Role config | ATTESTER | INCLUDER | PROPOSER |
|---------------|----------------------|----------------------|----------------------|
| active | boolean | boolean | boolean |
| target_staker | (StakerIndex, Value) | (StakerIndex, Value) | (StakerIndex, Value) |
| delegatable | boolean | boolean | boolean |
| fee_quotient | uint32 | - | uint32 |

#### 2.4.3 Balances

There are two design tracks on balances:

- Stakers have **unified balance** with the caveat that there are two issues with mixing slashable roles:
- It's problematic from the WS perspective (keeping delegated balances accountable)
- It would defeat the purpose of APS, since it would be rational for stakers to stake both roles, for capital efficiency.

So, this would work better in a non-APS world, or, arguably preferable in the APS + EL track for Includer and Proposer scenario (just Attester role in CL). It could, however work with all roles staking in CL if stakers would need to choose at most one of the attester and proposer roles.

So the only 5 options available would be:

- Attester only
- Proposer only
- Includer only
- Attester + Includer
- Proposer + Includer

- Stakers will have **per-role balance** in any other scenario.

In both tracks there will be no `effective_balance`, and no `MAX_EFFECTIVE_BALANCE`.

Hysteresis will not be applied on stake updates, processed [each slot](#251-State-transition).
The rationale behind this decision is that, at current hash speeds, a laptop CPU can prove 1M hashes/sec, thus hysteresis is no longer relevant for CL proofing.

##### Unified balance scenario

- A flat list of the corresponding stake will be kept in the consensus state, parallel to the list of stakers:

stakers: SSZList[Staker, staker_registry_limit]
"""The list of stakers in the state."""

stake: SSZList[Gwei, staker_registry_limit]
"""The list of the corresponding stake amounts."""

#### 2.4.4 Delegation models

##### Modelling Assumptions and Parameters

Minimal Functionality across models:

- Track delegation / undelegation / redelegation slot-by-slot.
- Apply rewards, penalties, and slashing proportionally to stake participation. Keep operator fee accounting.
- Remain reorg-safe and deterministic under a fast finality window.
- Support incremental slot updates with complexity O(Δ), where Δ = #delegation operations per slot.
- Expose verifiable commitments usable for zk proofs and historical audits.

##### Delegation architectures

Delegation architectures determine and verify relationships between stakers and their delegates, informing proportional rewards, penalties, and slashing accountability.

Delegation mechanisms fall into three structural families:

* A **horizontal inbound view**, where each delegate lists its delegators directly,
* A **vertical ledger**, where delegations are stored as centralized entries, preferably with deterministic offsets,
* A **committed mapping**, zk-friendly, where delegations exist as compact per-delegator mappings, completed by cumulative indices.

##### Design Parameters

| Parameter | Meaning | Value |
|----------------------|--------------------------------------------|------------|
| **N** | Total attesters (stakers) | 16,384 |
| **3SF window (K)** | Non-finalized slots that may reorg | 2/3 |
| **Role split** | Delegators **D** + Delegates **T** = **N** | — |
| **Many-to-many max** | **[N² / 4]** delegations (D ≈ T ≈ N/2) | 67,108,864 |
| **Many-to-one max** | **N − 1** delegations (D = N−1, T = 1) | 16,383 |

### Shared constraints.

- A staker can act **either** as a delegator **or** a delegate (never both);
- Self-delegation is not accepted.
- Stake flat list (`stake[S]`) holds self-owned balances.
- Relevant resources
- https://ethresear.ch/t/eods-enshrined-operator-delegator-separation-a-delegation-model-proposal/22826/1
- [A quantitative analysis of delegation models candidates for lean rainbow staking, based on their state-size impact and computational overhead](https://hackmd.io/@kboomro/S1Xot7GAgl)

### 2.5. Dependencies

A concept of lean Consensus with lean rainbow staking mini on top, exploring the intersection of the feature with the lean Consensus stack (ZK-proofed consensus + PQ multisig), can be found [here](https://hackmd.io/u3_R13jjSv6UREyxf4GwRg?view=#CONCEPT-for-the-rainbow-staking-feature-of-lean-consensus).

#### 2.5.1 State transition

- The Execution Layer provides a zkEVM proof (authenticating EL state transition + requests).

- The Consensus Layer (CL) produces a single recursive zk proof (the STF zk proof) that internally verifies:
- the `attestations_proof` (zk-aggregated PQ signatures / participation),
- the zkEVM proof outputs (verified EL correctness), and
- the consensus state transition logic (Δs apply → indices → slashing → withdrawals).

#### 2.5.2 Finality
* FF rules apply: justify target on 2 / 3 votes; finalize source if no intermediate justifiable slot
* Target finality goal ≈ 3 slots (3SF / other Fast Finality gadget)
* **Reorg depth** bounded to K ≈ 2–3 slots (FF window); finalized roots remain immutable
* All Δ entries ordered by `(slot, op_index, update_counter)` for deterministic [LWW behavior](https://hackmd.io/RMiAhhdTTiaUBXUk4Nh2jA#7-Core-Structural-Tools-CSR-and-LWW)
* Each slot’s proof references previous roots, the verified zkEVM outputs, and CL inputs only for recursive composition.

#### 2.5.3 Accountable safety via ultra-weak subjectivity

- Can we leverage ultra-weak subjectivity (in the context of FF & zk proofs) to alleviate any of the protocol constraints?
- Relevant resources
- https://notes.ethereum.org/@adiasg/weak-subjectvity-eth2
- https://hackmd.io/@kboomro/SJ3MlAKZeg#WS-period-calculation-for-this-model-Based-on-Electra
- Smarter activation / exit churn
- No sweep
- Retrospective view
- Single invariant
- Set `exit_epoch` in operation processing slot not in request slot
- Relevant resources:
- https://ethresear.ch/t/adding-flexibility-to-ethereums-exit-queue/22061
- https://www.youtube.com/watch?v=M6oRqhjMFQc

#### 2.5.4 Economic policy

- Enshrining LSTs
- Not necessary to enshrine LSTs with rainbow staking, staked ETH could be wrapped using
in-protocol oracle.
- Since EIP 4788 (Dencun) is possible to prove consensus layer information inside the EVM. The
most recent 8191 beacon block roots are stored and accessible in a smart contract at
`0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02`. Zk proofs can be created for anything inside the beacon state, including validator balances, withdrawal credentials, deposits, withdrawals, etc.
- Relevant resources:
- https://eips.ethereum.org/EIPS/eip-4788
- https://ethresear.ch/t/slashing-proofoor-on-chain-slashed-validator-proofs/19421/1
- https://hackmd.io/@willcorcoran/BJlA7FY0el