# EPF Weeks 10/11
These weeks I have been focusing on the newly discovered Lean protocol effort. I found out about the Lean protocol and spent time understanding how ZK and quantum proofing should work, and what Lean is striving to become. This is where I made the choice (in my head) to pivot to Lean, and focus implementing/adapting eoDS into a form of Rainbow Staking for Lean.

## Intro
Going towards my initial goal and having a POC client implementation whould have been a nice thing to have, and I am sure that we could have learned a few things from my effort. But then I found out there is an effort to build a more efficient protocol, from the grounds up, one that will include Rainbow Staking (from which eODS originated). I started paying attention and getting sidetrack by the idea of actually working on a Lean Rainbow Staking implementation.

Lean is in early stages yet, which is good and bad for me. Good because I can come up with things and propose them, bad because there is not much to build on - other that the previous Beacon Chain ideas and mistakes.

### Lean
I've found the repo for lean and started reading the code, and all the concepts that that went into Lean, organized in subspecs.

### Post quantum
The Lean is designed to offer post quantum resistance. For that, most of the effort so far has gone into quantum proofing that future.

In order to do that, BLS signatures need to go away - they are vulnerable to quantum attacks ([interesting read here, a bit off topic](https://ethresear.ch/t/how-to-hard-fork-to-save-most-users-funds-in-a-quantum-emergency/18901))

BLS is replaced by XMSS (eXtended Merkle Signature Scheme), that will use Poseidon2 as a hashing function. XMMS is based on Winternitz One-Time Signature.

Each key pair is used to sign only one message. It has 3 parameters: a hash function, a security parameter, and a Winternitz parameter.

The Winternitz parameter is usually a power of 2 number, and it controls the signature size / signing speed.

To sign a message using this, some steps are required:

#### Key generation
A private key vector is chosen: sk=(sk1​,sk2​,...,skℓ​), ski​∈{0,1}
where ℓ is the number of “chains,” determined by message length and 𝑤

A public key is constructed by applying the hash function multiple times.
The public key will be in pk=(pk1​,pk2​,...,pkℓ​)

### Message signing
Convert the message digest 𝑚=𝐻(message) into base-𝑤 digits. Here, each 𝑚i is a digit between 0 and 2pow𝑤 - 1.

For each digit we compute σi​=Hpowmi​(ski​)

### Message verification
For each σi we hash it forward, and if all checks pass the signature is valid.

This is designed to be quantum proofed, because the signature can't be followed back to the private key.

### Optimising
To further optimise the verification cost of signatures, a "Top of the Hypercube" algorythm is used to map a message hash to a signature that requires the least amount of operations to verify. I've included a link to the relevant paper in the Resources.

## Lean Rainbow Staking
This cryptography is not a major part of the Lean Rainbow Staking, but it it at the core of Lean. It will change the way signatures work, and will affect all areas of the protocol.

## The Lean Repo
Lean is being currently worked on in a [repo](https://github.com/leanEthereum/leanSpec) I've spent time cloning, exploring, and uderstanding how things are organised and connected. The Rainbow Staking specs will live here and they must integrate seamlesly.

### Resources
[Winternitz One-Time Signature Scheme](https://sphere10.com/articles/cryptography/pqc/wots)
[Efficient Prime Fields for Zero-knowledge proof](https://hackmd.io/@Voidkai/BkNX3xUZA)
[Top of the Hypercube](https://eprint.iacr.org/2025/889)