The 8th instalment of the Lido Node Operator Community Call + special guests.

Tuesday July 25th, 17pm UTC.

Agenda:
- 00:00 Intro
- 01:11 Update on LoE Wave 5 Onboarding.
- 04:59 Sasha & Max present permissionless bond analysis.
- 35:32 Nethermind presentation.
- 57:08 Justin Drake presents MEV Burn.

So thanks everybody for tuning in to the 8th edition of the Lido Node Operator Community Call.

There was a bit of a gap in between this call and the previous call, but we're going to try to get back to our monthly cadence.

So kicking off, I'm just going to go over the agenda.

I'm a LidoDAO contributor working in the NOM workstream.

And today we have a series of guests as well as some presentations from fellow LidoDAO contributors.

So first up, we have Will, who's going to give us an update on how the fifth onboarding wave for Lido on Ethereum is going.

Then it's going to be followed up by Sasha and Max, who are going to do an in-depth presentation around the community staking risk analysis and bonding model that is being explored by LidarDAO contributors.

Then we have a presentation by Lucas from NetherMind that's going to tell us about the NetherMind execution layer, changes that have been made in the last couple of months, and things to look forward to in the future.

And rounding it off, we're going to have Justin Drake from the Ethereum Foundation that's going to tell us about MEVBurn.

So Will, please take it away and tell us about Lido and if you're in wave 5.

As Izzy mentioned, I'm Will, a contributor to the Node Operator Management Workstream at Lido Dow.

And I'll be talking about the fifth onboarding round.

So as a reminder, this onboarding round is being run in 2 stages.

Stage 1 had 14 eligible candidates that were assessed by the LiDAR node operators of governance group or the LNO SG.

And these candidates basically were all return applicants to the Lido on Ethereum onboarding process that had previously been assessed high scores by the Lido node operators subgovernance group in prior onboarding rounds.

So the LNO SG has suggested 2 of these node operators to the Lido DAO for onboarding onto the protocol.

There's currently a snapshot vote that is pending that closes on Thursday of this week.

So if you've not voted, feel free to do so.

And also feel free to participate in the discussion on the LIDO research forums regarding these 2 node operators.

Over the past week or so, optimistic onboarding and testnet activities are starting to begin.

So currently there is a process of collecting basically contact information, understanding the policies and procedures related to running validators for the Lido protocol on Ethereum.

And this will continue over the next few weeks until there's an on-chain vote.

Assuming that performance is solid and there's no issues, then mainnet onboarding is tentatively planned for these 2 operators by mid-August.

For the second stage of the onboarding round, there's an additional 114 applicants that need to be reviewed.

So in total, there's 116 applications that were received for the Wave 5 onboarding round.

The evaluation for these next 114 applications and for Stage 2 overall is tentatively planned for the final week of August.

So if you have applied to the onboarding round, expect to hear from the non-contributor workstream in the next week or so, basically following up if there's any additional information required.

In some cases, potentially having follow-up calls.

In other cases, basically just an update saying that the information that was received is sufficient to be evaluated.

This process will continue through the month of August, and additional details will come with the emails that you've provided and applied with.

So during the stage 1 LNOSG evaluation round, the initial discussion between the participants suggested that a total suggested shortlist to the DAO of 7 to 9 new node operators would be proposed.

Important to remember that the Lido DAO has the potential to approve new modules to be added to the protocol overall of the next 12 to 18 months where additional node operators will have the opportunity to participate.

But in general, again, this is just a suggestion from the LNOSG.

So feel free to join the discussion in the onboarding round thread that's live on the LIDO research forums.

Assuming all these timelines hold, mainnet onboarding is tentatively expected by mid-September, meaning that whatever the new number of node operators that the DAO decides to onboard to the protocol, all should be running mainnet validators by the end of September.

So with that, keep it fairly tight, but happy to take questions if there are any.

But again, I encourage you to go to the LIDAR research forums to join the discussion there.

So I'm keeping an eye on the chat in Zoom and on YouTube.

And since we are trying to stay on schedule this time, I think we'll just move on to the next segment.

So Sasha and Max, can you please present your analysis on risk assessment for community staking?

Hey everyone, I'm Sasha, a LIDAR contributor working on the community staking work stream as a product manager.

The second section of our today's call is supposed to be about the permissionless bond analysis.

But Firstly, it's worth providing a bit more context why we are going to talk about such kind of things.

So, several months ago, we have presented the Community Validation Manifesto where the LiDAR contributors gathered a common understanding of why solace-taking matters and what we want to achieve as LIDAR contributors on our way of evolving the LIDAR node operator and validator set.

Within these goals outlined in this document, we have committed to increase the number of independent node operators and to lower the barriers to becoming a node operator.

Since those days, when we established this manifesto, a lot of work has been done.

And the most significant milestone was the deployment of the Staking Router smart contract, sorry, which basically opens up the opportunity to modularize the LIDAR validator set.

And it means that the LIDAR DAO can switch from the monolithic node operator set structure to the modular 1.

So that's why we've started working on the development of different modules which aim to onboard new node operators.

But if we do a step back and look at these goals once again, we can see that there is a small node that these goals must be achieved without compromising on quality.

And it means that while increasing the number of independent node operators, we must always think about risks and implement such mechanisms of risk mitigation that remind the overall protocol stable and secure.

And I myself can say that it requires a lot of effort.

So, bonds and dbt are considered as crucial risk mitigation mechanisms in permissionless staking solution.

They can be combined in various ways within different modules.

For instance, a module might utilize the bonds without DVT, or it can be a combination of bonds and DVT, or whatever.

And the most interesting fact about bonds is that the required amount of bond should be enough to cover the risks for the lightest takers.

And at the same time, it should be affordable for node operators, because we remember that our another goal is to lower barriers to becoming a node operator.

So that's the question that Max is going to talk about.

I'm also a contributor, part of analytical stream.

And with this explanation, I'll talk about what we're going to do.

We're going to drive some details about the mechanisms of The first thing is evaluating risks involved in running a validator and ways to mitigate it.

Of course, there are multiple ways to mitigate it and we're focusing specifically on both within this talk.

I will be talking about risks and mainly about risks involved with validator malfunction, whether it's going offline or slashing or the risks of EL reward stealing by malicious actor rewroting the EL rewards to different addresses.

Of course, all of these risks could happen unintentionally or intentionally and all of these risks should be mitigated to facilitate all the needs and all stakeholders expectations not in terms just the in your community but also stakers and and there are different ways of mitigation of risk mitigation, like bonding or reputation based mechanism or explicitly reducing risks with dbt.

But for all of this, the first things we need to handle is the way to evaluate risks.

And then try to build a mechanism that would reduce the risk exposure of our protocol.

We would go by each of these risks provided here.

Talk about how we can relate the effect, how Bound can mitigate the effect, and then talk a little about the complex risk of these damaging events realizing at the same time or consequently.

So to model the risks and damage and the evaluation we need some assumptions on mechanics which is basically that the operator fully controls related behavior, and all the rewards and validator balance after exiting would end up on the protocol vault.

And we need a crucial assumption that at some point in the future there would be technology providing smart contractual exits which is more of a reality now but still not within the spec.

And also we to provide risk valuation we need to make some assumptions on the market, which is basically what situations or scenarios we are considering in terms of the damage to the protocol.

During the whole of this presentation, we will be using risk-averse approach, which is basically could be formulated as taking numbers representing as much data as possible.

And for market assumptions, the most crucial parts are the level of tail rewards and the level of yield rewards, which we've taken to some generous numbers, and also yield reward structure, which impacts the amount of risk damage that could be provided.

And for our approach, we used the assumption on consistent nature of the yield, yield-reward structures in terms of distribution and median radius.

Going straight forward to the risks provided above, the thrust in validator going offline for some time.

There is some assumptions should be made, the period of offline, the APR on consensus layer and NPR on execution layer.

And basically what we are presenting right now is a framework that can put these assumptions to the numbers of possible effect on the protocol.

For validator going offline, there is a part of missed rewards, the rewards that the validator didn't get for this time, and it's basically validator balance multiplied by period, multiplied by APR on CL on PL, and penalties that is accumulated on this level, which could be measured as missed rewards on consensus layer multiplied by 3 quarters.

The gist behind this coefficient is the structure of penalties.

They are going for SYNC committed, not going for proposal, not for all the attestations.

More precise number, given the whole spec is 65%.

But adding up a little bit more on this is based on the risk averse approach with penalties, for example, for swing committed being like exactly the same as missed rewards.

Applying this pretty basic calculation, we could end up with some amount of ETH that protocol didn't get as a result of this risk realization.

This is important to mention as the penalties is straightforward decreasing the amount of ETH within the protocol and validators.

And missed reports is something that didn't landed comparing with situation when validator ran as usual.

And transferring this risk is another option it could be compensated by the bond as a whole.

It could be compensated by the bond, for example, on penalties part.

And for missed rewards could be shared between all the participants.

Again, this is the framework just to assess the numbers, the decisions on how this risk could be transferred or handled is the next step on this research.

But getting the number is a pressure part to this.

For the slashing thing, the situation is a little bit more complicated.

Again, we need some assumptions for this exit period for the validators getting slashed.

We don't need forced exits here as it would be exited by the beacon chain itself, but it could be a line, a queue on exits that will and lengthen the time that it would be not generating rewards and getting penalties.

The logical missed rewards is basically the same with the different exit period.

There is initial penalty, penalty, there is attestation penalties for being offline during the validator exit.

Nevermind it's offline and not, it would still get the penalties.

And midterm or correlation penalty is a little bit trickier.

There is a formula here but the basic logic behind this formula is again simple.

For each 1% of network slashing at the time of midterm penalties, 3% of validator balance would be slashed as correlation penalty within the integer mathematics behind, that means rounding down to nearest integer.

The idea here is as a correlation penalty, you can get as high as possible in terms of the validity rewards, but building additional assumption on the amount of network that is slashing at this moment, we could limit this risk.

of network is in ongoing slashing, the correlation penalty wouldn't exceed 2 ETH because of this math with multiplier by

So the framework here adds additional assumption on which risks in terms of the ongoing slashings within the network, we are trying to protect for and we are trying to transfer the risk on the bond.

And for this particular example this would be

So the recap on assessment of first 2 type of risk is pretty simple.

There is some assumptions that should be made that outside of the framework, that is a question of what risks we're trying to prevent and what risks we would take if this happened.

Then there is an assessment part when we could calculate, but based on the assumptions, the level of exposure to risk, and then there is an application.

For example, this is the thing I've told before, with a pretty generous level of sale rewards and EL rewards with an assumption that there would be no more than a year, at least the technology for trigger deliberate exits, that there wouldn't be an activity leak for substantial amount of time, and that we are not protecting from the case of more than 3.13% of network slashing within the same period.

4th bond is enough to compensate the risk of going offline and slashing basically for any amount of validators.

Going next for the third type of risk, which is quite interesting in terms of this approach, the possibility for changing recipient address and basically stealing yearly rewards brings up a tough question.

First of all, and the main major difference is Yale stealing is directly incentivized.

If you are trying to slash your validator or go offline, you don't get the rewards.

It's basically rewards missing and damaging the ETH.

For this situation, Yale stealing is an opportunity for a malicious actor to perform this attack and get more rewards that he's risking.

And due to high variance in the amount of yield rewards.

Basically, no amount of bond as a mechanism could prevent this situation purely on economical science sense if we're speaking about entity controlling only 1 validator and providing only 1 bond.

As like, if we have the block worth 400 piece, like no phone of 16, no 32 bones would economically prevent the actor from stealing it and losing its bond.

But the good news pretty simple which could be formulated like that.

There is very very very very very small amount of blocks that worth so much ETH.

For example only 0.28% of the blocks worth more than 4 ETH.

And if we assume the worst case scenario, when all the actors act maliciously and steal them, the amount of blocks subjected to this attack is pretty low, but the amount of cumulative EL rewards is pretty high.

If this 0.25 of blocks would be stolen, we would lose as a protocol basically

of all EL rewards, which would be socialized on all the stakers.

So we couldn't with no amount of bond prevent this situation, but we could limit it.

And the basic idea is the more bond we have, the less effect on EL rewards, supposing that all of the actors would be acting purely economically malicious, stealing the bond, stealing the EL, if they face the block that was more value than the bond they provided.

It could be combined with this graph, which is basically the mobile bond you have.

The less decrease in EL rewards we would observe in this situation, but there is a significant element of chance within this model that is inherited from that significant variance of EL.

What if we would face more high worthy in terms of year blocks through the year and hence more intentions for actors to steal the bond.

For this case the approach could be transformed a little, basically adding multiple dimensions of simulations and selecting some pointile again using the risk averse approach in which we get the worst luck in terms of 90% of confidence interval, we get the worst luck on actor behavior in terms of everybody who can still economically, who can still getting more ETH than the bond provider would do this and create this basic curve which transforms to which amount of year rewards would be stolen for different levels of bond.

This is again a framework that could be used to assess the impact of this attack existing on the protocol And elaborating a little bit on this, we could challenge the last assumption of percentage of node operators or validators that are subject to stealing.

In terms of community staking, we're not going in with distributing all of 100% of stake on permissionless node operators.

So applying the curve above to the percentage of node operators that are considered and subjected to stealing, we could calculate the most possible amount of impact on protocol in terms of drop in APR and in terms of relative drop in APR within an assumption on which part of the whole APR yield rewards are providing for.

Again, using risk-reverse approach, the more yield rewards are responsible for APR, the more prone we are to this attack as its effects on the Yale-rewards.

Basically, this is a framework to validate this.

And the useful, the case for using it is making some assumptions on the yield-reverse structure, on share of validators that are subject to sterling and level of risk tolerance in terms of confidence interval, using risk assessment and evaluating which risks the DAO and the stakers and the community is okay to take if we don't have any additional mechanisms apart from bond, which is of course not true as bonding is not the only 1 mechanism.

And yeah the example here is based on graphs above for 4-ith bond decursion appear would be less than 0.027 percent with probability of 90 percent if only what 5 percent of validators would perform if attack if opportunity occurs.

So at this point we've built the framework for evaluating 3 types of risks in terms of impact on protocol, in terms of how Bound could prevent it or limit at least.

But bringing this to mid space and evaluating a little bit more, these risks could happen at the same time.

So we should consider combining the risk scenarios and validating what would happen in this situation.

And the basic gist is you can't steal EL if your validator is not running online.

And validator being offline is worse than Yale stealing on general level because impactful Yale stealing is really, really rare and validator going offline is rewards not generated and penalties acquiring for the whole amount of time.

So creating this the most dangerous scenario is the simple idea.

Permissions join, going offline until the time trigger exits are arrived and slashing at the moment they are just around the corner.

So again, this is a framework that could provide you the instruments for evaluating this type of combined risk.

And the first 1 is apocalyptic scenario when all of the risk are going together with risk averse approach on each of the assumptions.

It's again assumptions on IP error, on time to triggerable exit, on the possible level of ongoing selections, and times in exit queue and the validators that are affected.

With different levels of bond, we could receive the situations when the bond covers all of this damage, for example, 7 is for this, or the situation when bonds don't cover all the damage, and in that case, we face a decrease within the missed rewards not compensated with the bonds, which could be treated the same as increasing fee just to put the context.

Again this is an instrument that could provide this valuation but basically this assumption are as I ordered them apocalyptic.

None of them each of them are really really rare and with low probability to happen and happening all of them at the same time is basically an existence.

Protecting from this type of risk would cost us too much in terms of market affordability.

A more realistic approach is getting to a more realistic amount of APR, getting for more realistic amount of ongoing slashing, which is basically cap at 1%, which is huge, We never faced it in the history.

And if ongoing session is less than 1%, the correlation penalty is 0 ETH.

Adjusting a little bit time and exit queue for validators.

And for this situation, the bond would cover all possible risks.

And this assumption on the share affected basically doesn't matter because if it's 1%, 10% or 20%, when the bond has a mechanism of risk transferring cover all the losses, there is no impact on protocol.

There are multiple different scenarios with tweaking some parts, for example, if triggerable exits would come up only in 3 years and it's really impactful, or when the midterm penalty would actually appear, for example, some sys if we want to protect from some civil attack.

Even we could consider this effect if we go with a 0 bond, because, again, It's a framework, a tool to evaluate the risk, but I'll move to conclusion.

If that is pretty simple, risk assessment is a framework tool that could be provided to evaluate the different scenarios.

And then the decision should be made not on the amount of bond we should provide in terms of risks, but in terms of scenarios and actual risks that we as a DAO want to mitigate, and which we are willing to take because consider them non-existent in terms of probability.

And of course, I'll say it again, the bond is just 1 of the multiple options that could be used to mitigate the risks analyzed within this framework.

If any questions in the chat, somewhere else, I would love to answer them.

I have a couple that I'll try to go through quickly but also in the interest of time.

Maybe we don't spend too much time on this but looking forward to like seeing this fully fleshed out and posted perhaps on the forum so that people can like dig into the math and maybe ask specific questions when that's available.

So 1 of the questions that I have, and actually I think like Dimitri brought this up in the Zoom call, and maybe Dimitri even wants to talk about this himself.

I'm going to wait to see if he's going to unmute or not.

So the important addition here is that the risk assessment is done in the assumption that each validator has its own bond and there is no connection between validators.

But the actual situation in most of the times is that 1 operator runs multiple validators.

And if we're speaking about MEV stealing, 1 way to mitigate risks even better with keeping the same for each bond is to associate the bond not with the validator but with the all validators of the node operator and then make this combined bond a subject of a penalty application in case of huge MEV stealing.

In this case, we are like assuming that the node operator has, let's say 10 validators, we will have 40 ETH bond.

And in this case, this case covers like literally 99.9% of the scenarios.

1 side, I would add a bit, like piling up together all the bonds, not only the way for DAO to build a new level of risk protection, but also could be used to lower the entry limit because if the DAO is more protected against the risks with some technology like piling up different bonds for an operator, we can lower the bond per 1 validator because we could share some of this risk premium of doing this, requiring less capital for protection to the stakers.

So it's technology that's good for everyone, basically.

So Torsten, in response to your point, Dimitri, brings up a good point, which is where if there's a node operator who is likely to steal or it's within their game theory strategy to potentially steal, why don't they just Sybil, i.e.

Pretend to be multiple node operators instead of coming, like being truthful, let's say, and grouping all of their validators under 1 entity.

And that's the point that I was talking about.

If we have an incentive for the node operator to show that he has 10 validators of 100 and could provide the bond in 1 pool that could be used for protection.

We could lower the bond to incentivize this, like kind of, I wouldn't say good, this risk-based behavior when there is no like intentions for attack.

And if there is an intention for attack, of course, it could be like 1 entity controlling

validators pretending to be 100 solar stickers.

But for this situation, the bond would be higher and different technologies, not in terms of bonding could be applied to provide some incentive incentivization against that behavior.

And there's a bit of a difference of approach, I guess, that we're exploring.

Like, do we do nonlinear bonding or do we offer some sort of like performance bonus, let's say, if you've been successfully running validators for a large amount of validators, and large doesn't need to be hundreds, right?

If you're a solo stake or it might be low tens or something like that, to incentivize operators to self-group, let's say their validators.

Yeah, definitely more carrot than stake as Torsten says.

So there's another comment in the chat, and this is the last 1, and then we'll move on to Lucas and Nevermind.

Large MAV profit isn't necessarily going to be captured by node operators in that sense, if the MAV takeaway is large enough that the attacker will set up their own validator set.

So it's very possible that modules that allow for permissionless entry into Lido will basically, may potentially be used by these actors, right, to increase their chances of landing a proposal.

But that's why, in theory, you need at least a decent amount of bond to begin with.

And it's also why the permissionless entry into the LIDAR operator sets is envisaged to occur through multiple channels and not just like a pure play solo staking module.

So in dbt, depending on how you do cluster selection, it may be a little bit more difficult to get a complete sibling, let's say, of the cluster, such that the operator could maliciously take over the proposals.

Yeah, the reason really, sorry, there's a question.

If you think about why risk hacking or getting front run and ensure no leakage or detection outside of Lido, indeed, really like the only thing at risk there is the non-productiveness of that ETH that's sitting in the queue while you're setting up the validators or while it's getting exited when you want to wind down the validator operation because nobody's going to trust you with a block going forward.

Feel free to throw them in the chat and we'll send them to Max.

When the presentation and the analysis is available on the forums, we'll welcome diving into this in depth because there's still a lot of meat to uncover.

You mentioned that we're planning to publish this research on the forum with the base math behind.

And all the comments, all the ideas is very, very welcome.

So up next we have Lucas from Nethermind.

So, I'm Łukasz Rozmaj from Nevermind Ethereum client.

I'm also Ethereum core developer and thank you for having me.

So I will start with a very brief history.

So you might see Nevermind popping out in different places.

See all Lido Finance transcripts on Youtube

Node Operator Community Call #8