The Shanghai/Capella upgrade for Ethereum, scheduled for March-April 2023, will introduce support for the unstaking of Ether. The ability to exit a validator and unstake associated Ether is required for the Lido protocol to build the withdrawals feature.
Designing the withdrawal feature for the Lido liquid staking protocol is a complex task due to the difficulty of interfacing data between the Consensus and Execution Layers, as well as the async nature of the Consensus Layer validator exit and slashing mechanics.
The Lido on Ethereum protocol team presents the proposed design for withdrawals feature. Weâre looking forward for the community feedback on the matter.
We are seeking the communityâs feedback to make sure that our proposal takes all important considerations into account and to identify any potential improvements. We would greatly appreciate your input on the following three questions:
Are the chosen decision drivers right?
Given those drivers, is that the best design possible?
What can be improved in the design or its presentation?
Your feedback is invaluable to create a proposal that is effective, efficient, and fair for all stakeholders.
The document in the post is focused on user flows, tradeoffs and nuances.
To dive into validator side of design, please, look into: 1) exit order post; and 2) automation discussion.
Iâd like to investigate the inactive leak case in more detail. Should we consider this scenario separately and not finalize requests if an inactive leak was in the reporting period? Oracles only collect reports for the final slot, so we exclude the scenario when an inactive leak occurs during the report. That leaves only the scenario when itâs completed at the time of the report. This situation doesnât seem much different from other penalties that validators may have accumulated during this period: the impact of a short inactive leak may be comparable to an unavailability of Node Operator validators for some time. And in case the inactive leak was significant, the common checks should enable the bunker mode.
So, I suppose this scenario could be handled by the common rules, which might help to simplify the implementation a little bit.
Iâd like to understand better the reasoning for proposing a market for the Lido validator exit queue rather than simply rely on the core Ethereum protocol itself.
Except massive slashing, there are two other scenarios that may cause negative stETH rebase: massive downtime and inactivity leak mode of the network. For example, while both scenarios happening within a short period (from several epochs to several hours) do not affect the protocol much and do not require withdrawal request freezing, downtime of more than 80k validators for more than 24h would cause negative rebase.
For these scenarios, instead of handling inactivity mode or collecting data on offline validators, we can simplify Oracle by estimating rewards/penalties accrued by the protocol.
A 12h delay in withdrawal request processing can be a solution. If massive downtime and/or inactivity leak mode are resolved by the time Oracle reports and there is a negative rebase, the âbunker modeâ is set up, otherwise there is âturbo modeâ. This solution also mitigates a situation when an arbitrager puts a withdrawal request right before the Oracle report and gets ETH immediately from the protocol buffer before negative rebases happen.
Iâd like to mention the recent edits made after getting the invaluable feedback from @Izzy and DefiScientist regarding withdrawals processing on the Ethereum network.
There is a withdrawals sweep procedure that puts withdrawal operations for the withdrawable validators into execution payloads, no more than 16 per single payload currently. This sweep is applicable both for partial and full withdrawal types without prioritization. Therefore, it leads to the increased delay for the validator that requested a voluntary exit to finally withdraw the funds (27h to become withdrawableAND up to ~4.34 days to become withdrawn or ~2.17 days avg depending on the validator index and the previously completed sweep boundaries).
For Lido it means that these timings should be accounted for when voluntary exits are performed to cover the requests if buffered ether amount is not sufficient.
Itâs not âLido validator exit queueâ but âLido withdrawal request exit queueâ â two very different things in nature. Lido withdrawal request concerns stETH amount put in the queue, which isnât tied to specific validator per se. It does, in fact, touch âvalidators in the Ethereum protocolâ set, as in order to fill the stETH withdrawal Lido protocol has to, in some instances, ask for exiting a validator. How those are chosen and what the actual process is â the question of another post Iâve mentioned in the first comments
So im by far not a tec-guy, but im interested in the section about the oracle-commitee, which is needed to fullfill a withdrawal request.
There are two approaches to using oracles: data can be brought on-chain and calculations can be performed there, or calculations can be performed by the oracles and the outcome can be pushed to the contract.
here are two approaches to using oracles: data can be brought on-chain and calculations can be performed there, or calculations can be performed by the oracles and the outcome can be pushed to the contract.
In general, these two approaches are equivalent in terms of the trust of the oracles committee, but the first approach would require performing the onchain calculations over unbounded data which is not practical due to limited block size and high gas costs.
For example, one of the proposed algorithms for determining the next validator to eject would require a loop over all active validators to find the next candidate. Unbounded loops will also occur when processing withdrawal requests.
Thus, a more practical approach here would be to perform calculations and data aggregation off-chain & make Oracles report the outcomes to smart contracts.
These oracles in the current state seem to bear certain risks of centralization.
As the authors state, the developers
considers this approach to be temporary and will work on a ZK-oracle that can perform the same tasks but in a trustless way.
What are the approaches to perform these tasks in a more trustless way? How far are these developements?
Anyone can elaborate on this?
For me, certain keywords immediately remindet me of Truebit. Would that possibly be capable of these tasks?
Interesting suggestion regarding the use of a âcommittee of oraclesâ.
Have you explored the use of Truebit style interactive verification as a trustless oracle? It only requires 1-honest validator, so has very minimal trust assumptions. You could either use Truebit directly, or fork the code and use your own validator network to run the nodes, similar to what George Hotz / Optimism did for Cannon OVM.
What are the approaches to perform these tasks in a more trustless way? How far are these developements?
This post should be relevant, but in short - thereâs a proof-of-concept solution for an oracle that solves a simpler problem (total value locked oracle), but the approach there is scalable to handle arbitrarily complex logic.
At a very high level the âwidthrawals oracleâ logic seems to boil down to âgiven the data about the WithdrawalsQueue, validator balances and withdrawal requests as input, determine if any validator exists are needed, validators to exit, and finalization time according to the specified logicâ.
This can be generally achieved the same way as in the TLV oracle example above:
merkle tree(s) (or similar techniques) to ensure that an actual and correct data about the queue/validators/widthrawals requests is used as an input via
implementing âspecified logicâ via a verifiable âprogramâ (TVL oracle example uses Cairo, but there are some other similar technologies).
Re: Truebit - probably quite close, but looks like it does not solve the problem of not having Consensus Layer data accessible to Execution Layer and smart contracts (correct me if Iâm wrong).
Gist is: weâre exploring the options & path forward, hadnât settled on the plan yet as full focus is to make Withdrawals & Staking Router work. Look for the post e-kolpakov shared on the state of current developments â ZK-proof Total Value Locked oracle
There are many (and counting) potential technologies around. Having to have at least one trusted actor sounds not ideal, but I hadnât had any deep dive in Truebit specifically.