Lately, there's been a buzz surrounding concerns about Lido's decentralization. To address this issue, several liquid staking protocols have sprung up, attempting to challenge Lido's dominance. However, this proliferation of solutions could lead to fragmented liquidity, leaving users in a quandary over which Liquid Staking Token (LST) to opt for.
To tackle this issue and explore potential solutions, some have proposed the concept of an "enshrined" LST, effectively integrating liquid staking directly into the Ethereum network. Surprisingly, though, I haven't stumbled upon any concrete ideas on how to execute this concept. So, despite my non-developer background, I decided to roll up my sleeves and brainstorm some possibilities.
Before we dive into the details, I must emphasize that I welcome any feedback or corrections from the community if they spot any issues with my approach. Let's get started!
Note: This design is very similar to RocketPool’s current model, there are lot of ways to go about an enshrined LST, this is just how I would imagine one. And I’m not at all an expert in this suff :)
The current scene in the liquid staking world doesn't quite cut it in terms of competition, security, and decentralization. In my opinion, the ideal path to build a robust liquid staking protocol is through permissionless node operators similar to RocketPool. But this approach comes with its share of challenges, especially when it comes to withdrawals.
Enshrined LSTs aim to tackle many of these issues right at the protocol level. While maintaining decentralization and eliminating need for any middleware solutions.
Let's break down the step-by-step journey for users, starting from their initial deposit to the eventual exit:
User Deposits: Users kick things off by depositing their ETH into the "staking" contract, which in turn grants them a rebasing token, lets call it “eETH”.
Waiting for allocation: The deposited ETH remains in the contract until it's allocated to a node operator in the “allocation queue”.
Allocation to Node Operator: When a node operator comes around, the protocol selects a node operator with the lowest commission and assigns the ETH to them.
Reward Accumulation: All accrued CL rewards are split and skimmed back into the "staking" contract, alongside any tips and MEV earnings. These funds are then restaked, ensuring that the rewards are compounded.
User Exiting: When a user wants to exit, they lock their tokens in the "staking" contract. The protocol retrieves their stake from the node operator with the highest commission. The wait time is determined by the exit queue length.
Now, let's dive into the perspective of node operators:
Node Operator Deposits: Depositing is the same as with current solo node operators, the operator deposits 32 ETH and waits in the deposit queue
Enabling Stake Assignment: Not all node operators are required to accept external stake but if they want they need to turn on the external stake allocation option
Stake Allocation: As soon as there is ETH in the “staking” contract and the validators commission is the lowest from all the other validators it will get stake assigned.
Reward Accumulation: Rewards are split based on how much ETH got allocated to the validator, the share of CL and EL rewards are sent to the node operators withdrawal address.
Node Operator Exiting: When a node operator decides to exit the assigned ETH is sent back to the “staking” contract and the rest is withdrawn to the withdrawal address of the node operator
When it comes to determining how much stake should be allocated to node operators, I don't have a precise number yet. But let's keep things simple for now and align their allocation with their initial stake. Now, to supercharge scalability, we could even consider boosting this allocation, maybe 2x to 5x, but we'll need to crunch some numbers to ensure it's safe.
However, before we get carried away, we need to bump up the MAX effective balance for validators to at least 64 ETH to accommodate this extra stake.
Alternatively, we could lower the MIN effective balance requirement to 16 - 8 ETH. This move could entice smaller players to join without the need for the full 32 ETH. But beware, this might lead to new validators potentially bogging down the consensus layer. This also lets node operators run smaller stake nodes without opting for additional stake allocation, which will be handy for handling withdrawals.
To tackle the load on the consensus layer let's blend the best of both worlds. We can lower the MIN effective balance and crank up the MAX effective balance, maybe even to 128 or 256 ETH. This combo allows larger node operators to consolidate their ETH into a single validator, lightening the load on the P2P network.
One more important point to remember, no matter how tempting it might be, we can’t skip the deposit queue when adding extra stake to a validator. This precaution is vital because bypassing the queue could open the door for malicious actors looking to exploit the network.
When it comes to adjusting the MIN and MAX effective balance, we have to tread carefully, considering the complexity of Ethereum's consensus system. We aim to maintain security without overcomplicating matters. While these changes are essential, we need to keep an eye on several factors like:
Validator entry and exit queue length, depending on their stake.
Proposer luck.
Slashing parameters.
And there's a good chance there are plenty more intricacies that haven't crossed my mind! :)
Here is a link to a research post to increase the MAX effective balance of validators.
For the safety of LST holders, we've got to consider the not-so-ideal situations too, like the possibility of downtime slashing and more. Let’s go through these scenarios one by one.
There are already existing measures in place to discourage validators from experiencing downtime. However, to safeguard the yield for LST holders, we should consider additional mechanisms.
To address this concern, we can introduce a system where network participants monitor each other. They can report instances where a validator remains inactive for an extended period, let's say, 15 days. Once this threshold is reached, the assigned stake will be exited and returned to the "staking" contract.
Should the validator rejoin the network, it becomes eligible for stake assignment once again. However, if it remains offline, the inactivity leak will gradually erode the validator's principal.
When it comes to slashing, the natural instinct is to put the validator first in line for punishment, ensuring innocent LST holders remain unscathed. However, navigating slashing is a bit tricky. The amount at stake varies depending on the validator's total stake. If we base slashing on the total stake amount, the higher the ratio, the more significant the potential loss for the validator if they happen to get slashed.
Another thing I was thinking about is whether it's necessary to penalize LST holders if a validator gets slashed multiple times. However, I'm still in the process of dissecting the potential attack vectors that such a thing might introduce.
This topic is an issue for all permissionless liquid staking protocols. The stakes are high, especially if a validator manages to snag a MEV-rich block, potentially resulting in significant opportunity costs. Naturally, we'd want a system in place to deter validators from stealing small MEV amounts by “slashing” them. However, this approach doesn't entirely resolve the problem of infrequent heists of MEV-rich blocks.
As for monitoring and slashing validators for this kind of misconduct, that's still a riddle I haven't quite cracked. To truly put this issue to rest, implementing ePBS (enshrined Proposer Builder Separation) might be the best thing.
First and foremost, with the enshrined LST concept, we wave goodbye to a primary source of fees, the middleware protocol. In this setup 100% of commissions would go to node operators. Since node operators don't take on extra risk when they receive additional stake assignments, commissions are poised to become fiercely competitive. Imagine, anyone who was solo staking before is now eligible have external stake assigned to them.
The smartest move here would be to allow node operators the freedom to set their commission rates, with the lowest rates enjoying priority when it comes to stake assignment, and the higher rate ones being first to be withdrawn. This approach, over time drives fees down as more participants join. It's a win-win scenario for everyone. Solo stakers get extra yield, while on-chain LST holders get exceptionally competitive fees, all without the need to place their trust in some external protocol.
And for those who prefer simplicity, we could even add in an automatic option to EL/CL clients that vaults you to the front of the line, so node operators don't need to check on the commission market.
To make this system more fair it makes sense to envision an enshrined adaptation of RocketPool's "smoothing pool." This concept involves pooling and evenly distributing MEV and tips to validators. The rationale behind this move stems from the fact that median execution layer rewards often lag behind the average due to outstanding blocks.
This approach not only ensures a more equitable reward system but also serves as an incentive for smaller players to partake in running validators, as their yield becomes more stable and predictable.
Let's take a stroll through both sides of the exit process: the user's exit and the node operator's exit.
In the current permissionless landscape, withdrawals can be a bit of a cumbersome ordeal. Let's use RocketPool as an example. When an on-chain user decides it's time to exit their stake, and the deposit pool happens to be empty, they're forced to sell their LST tokens at a discount. If that discount is juicy enough, node operators can swoop in, execute their exits, and arbitrage the price difference. This inefficiency occurs because Ethereum doesn't support partial withdrawals and forced exits.
Now, with an enshrined LST in play, things get a whole lot smoother. When a user initiates a withdrawal, the protocol selects the validator with the highest commission and initiates an exit of their external stake. However, here's the twist: the validator isn't fully exited. With their principal, they can still continue solo staking, and receive external stake in the future.
It's worth noting that the exit queue is still present in the process. Much like with deposits, a user's stake must wait this queue. Only upon successfully passing the queue can the stake be sent back into the "staking" contract, where the user can subsequently claim it.
It's quite straightforward; there's none, or at least, not in the conventional sense we're accustomed to – no on-chain voting mechanisms here. Upgrades and other alterations take place through forking. This stands as one of the most significant advantages of enshrined LST; it remains relatively impervious to many on-chain attack vectors.
Of course, there's a trade-off. It may not evolve as rapidly as its counterparts, but does it even need to? The essence of an enshrined LST lies in its security and integration within the protocol, not in its lightning-fast adaptations to market demands.
There can be a scenario where established protocols like Lido and RocketPool might find themselves building upon our enshrined LST framework, offering users a superior yield, which encompasses the original yield along with commissions. Initially, this might lead to a concentration of stake that remains relatively unchanged.
However, I hold the belief that as node operators fiercely compete on commissions, these rates will plummet to a point where staking through middleware, for a slight uptick in yield, becomes an unjustifiable proposition. Why expose yourself to smart contract risks and governance vulnerabilities when you can enjoy the enhanced security of an enshrined LST?
Furthermore, when staking with an enshrined LST, it acts as a diversified basket, distributing your stake across every operator. This approach is substantially more secure than relying solely on a single LST.
In wrapping up this article, my intent has been to shed light on the potential avenues for constructing an enshrined LST and to advocate for its development. There are undoubtedly numerous technical intricacies yet to be explored. However, I'm content to leave the exploration of these challenges in the capable hands of brighter minds than mine.