Lean Staking is an L1-native, two-phase staking protocol that breaks the public link between Ethereum deposit addresses and consensus layer validator keys. Depositors submit ETH alongside a cryptographic commitment to the staking contract, without revealing any validator keypair. A separate party later claims the deposit by submitting a zero-knowledge proof of commitment ownership, at which point the deposit enters the validator entry queue. The protocol is implemented through changes to the staking contract coupled with a zkSNARK only, requiring no consensus layer modifications.
We benchmark our zkSNARK on a Macbook M1 Pro using LeanVM, a post-quantum, expected to be formally verified, proving system currently developed by the Ethereum Foundation.
We also introduce an optional two-phase withdrawal extension using a new 0x03 withdrawal credential type. It allows validators to break the link between their validator key and their withdrawal address. This enables a direct pending-deposit-to-pending-withdrawal path, preventing privacy-only seeking users to ever activate as a validator. This extension offers two-sided plausible deniability: both sender and recipient perform actions indistinguishable from routine staking operations.
To our knowledge, this is the first construction providing two-sided plausible deniability for private ETH transfers on Ethereum.
I think that idea of making staking a powerful shielding pool for Ethereum has legs. I don’t know if there’s a way to make non-custodial protocols possible here which I think is a must for adoption, though. As proposed, there’s two points in validator lifecycle where there should be a custodial secret holder. maybe there’s a way to make MPC around that and upgrade it to multisig model which is a bit but not the whole way better?
I agree that accommodating non-custodial validation is very important. For a non-custodial arrangement between a staker and a validator to work we need to guarantee two things:
a. Staker or a smart contract can trigger/force withdrawals
b. Staker or a smart contract controls the withdrawal address
The current version of the EIP supports both:
(a) is possible with a pre-signed exit message
(b) is possible trivially by setting the type 0x3 withdrawal credential appropriately (likely to a smart contract).
We could go one step further to support smart contract triggered withdrawals (EIP-7002), either by revealing the withdrawal address or making a ZK proof that the withdrawal request contract has indeed requested withdrawal. Both have non-ideal privacy implication and it requires more exploration.
We will add a discussion about non-custodial validation to the next version of the EIP.
In my mental model, validator shares pub key and withdrawal credential with staker before the initial deposit, so either of them can enqueue a pending deposit and there is no room for validator griefing the full deposit. I am probably missing your point, if so could you please expand?
similar to the deposit flow, withdrawal with type 3 credentials has two phases. The first is exiting the active validator pool (which could happen with a pre-signed exit message shared with staker before making the initial deposit; it doesn’t need a proof), and the second phase is claiming the released funds with a proof. Again assuming the staker knows the withdrawal credential and pub key, they can do the claim.