Validator Redirected Revenue

Transcript

Hey everyone or so. So today we're going to speak about validator staking reward for Ethereum ecosystem growth. So the problem. So the first problem is that Ethereum is massively underfunded. So we have $244 billion market cap, which is huge, but we only spend $145 million to fund Ethereum development and ecosystem. So the budget is only 0.06% of the market cap, which is almost nothing.

But as an ecosystem, we spend a lot of money on on validator rewards. Obviously, those are useful, but do we need to have such a disproportion between the funding for validators and the funding for development? I I don't think so. I think we should have more money for development. And also now we are getting a real competition risk. Now we have Solana with a way smaller market cap. They are able to overspend us with significantly higher budget both in absolute value and in percent of market cap, and that becomes a real risk. Even if you are efficient, are we six times more efficient than Solana? Maybe, maybe not. So that's something what that we

need to address. The second problem is that the current funding is not neutral. So the current funding comes from the EF, which comes from the 12 million pre-mined in the genesis block, which was given to EF and early Ethereum contributors. It's EF is a good actor, but it's still centralized. It's mainly relying on the goodwill of Vitalik. What happens when you retire, dies, becomes crazy. We don't know like we we want to to be more resilient. And also it doesn't represent the world range of opinion and desire of the Ethereum community. We saw that recently with all the debate towards the Ethereum mandate. I think the Ethereum Foundation

should be able to have their views, opinion and directions, but all their views, opinion and direction should also get funded. Yeah, so maybe I'll start over here about why other actors aren't funding it. I think the whole idea is that that like EF is just one out of many funders and there are many others in the ecosystem that can fund unlike other ecosystems. But I think the fundamental problem I've identified and I work at the funding coordination group in the EF. Um is that we are suffering from a prisoner's dilemma right now where we are stuck in this equilibrium where if one actor funds but the others don't fund, then the person who did fund becomes like the loser who's like over

paying and the others who didn't fund become the winner because they get the benefit despite not paying anything. And that puts us in this equilibrium where neither are funding, but we somehow need some sort of protocol level change to move into this equilibrium where both of them are funding. So we need a a situation where either everybody funds or no one funds in order to be sustainable and get the other actors actually paying money and not just the EF as the sole funder. Um so here's a very concrete example that imagine that there's some project where you need to pay $50 for it to have a upkeep like maybe say L2 beat for example and there are many projects which depend on them and they get $10 of value from that project. Um so overall there is a $60 gain because there are

six projects each of which are getting $10. The cost of the project is $50. Um so the benefit It but this actually doesn't happen because no one funds it in the absence of coordination. Um so yeah, in economics we call this a deadweight loss, which is the loss when parties are willing to make a trade with each other, but they still don't make the trade because of factors like maybe high taxes, lack of coordination, it could be any reason. And that's what we are seeing over here. There's a deadweight loss where uh right now EF, for example, is able to fund L2 beat and other ecosystems that uh people are relying upon. But um uh like economies with a higher deadweight loss usually get outcompeted

by those with a lower deadweight loss. So, if you actually want Ethereum to outcompete the traditional world, it's important to try minimizing this uh so that we get because it's a permanent loss to the economy. Like once it's lost, it's lost and you can't really get it back. So, hopefully I've underscored the gravitas of the issue. So, why previous attempt to do that failed? So, we had in 2019 uh two EIPs. One which was just about committing on using part of the block reward for funding, but this EIP was very undetermined. It was not saying how much and to whom.

Um and also back then we were in a different situation. So, back then we were competing with Bitcoin and even doing a token sale, even doing the ICO was something which was a bit controversial uh compared to Bitcoin. So, that's also why the EF got uh such a small part of the of the ETH. Uh but now it's pretty different. Now we are competing with other level L1 platform uh which are smart contract platforms. And um back in the day we had a lot of time ahead, uh but now it's like 7 years later and still nothing has changed.

And also back in the day it was very hard from a governance perspective because this would have been taken from miners and the miners they knew they were going to get replaced soon, so they did not have any long-term incentive in the Ethereum ecosystem. Uh now validator is pretty different. Like validator tend to have a lot of ETH and uh yeah, like you can also increase the value of their own ETH. So, they are better aligned. Um there was another proposal which in this case was actually a concrete proposal where they were proposing an amount and a list of recipient. Um but it was very non-neutral. Like it was just like hardcoding some addresses and it had huge opposition uh and I don't think it was a a good proposal. So, the idea is good, but I think we can do way better than what we

were talking about in 2019. Yeah. Um so, maybe here we'll talk about why we are focusing on validators over here, which is that at a structural level they have an incentive to fund the ecosystem, which is that if they put money into ecosystem development, that creates demand for ETH and block space, which increases the value of the underlying principle, and uh that then again can can go back into funding new use cases and development and then again. So, that is a very nice loop and there is alignment between validators and Ethereum growth, but we need to make a couple of changes before we actually convert that into actual funding.

Um so, this is the proposal. All of this was just talking about the overview and the problem. Now, we come to the meat of the talk, which is um so, basically like uh it this is a lot going on here, so I'll break it down much easier, which is that the change we want is that validators right now only indicate gas limits that are they able to increase a higher throughput for Ethereum. So, they put up a flag showing I can put 45 million gas or 60 million gas. We are proposing that they also put up two other parameters, a flag indicating how much percent of their rewards they want to reallocate to the ecosystem, and they put up the recipient addresses which they want to send the money into. So, validate like under this change which you're proposing, they put

up three parameters, the gas limits they can handle, which is already existing, the amount of rewards that they're willing to part with, and if a majority 51% say that okay, we can part with 5% of our staking rewards, then all 100% have to part with it. So, we actually overcome the prisoners' dilemma problem that I pointed to earlier. And the third is which addresses. So, here they could say like okay, I want 60% to protocol guild or another guild. They want some to deep funding, futarchy, QF, a liquid voting DAO. So, they can all even like a different entity for that matter. So, they also put the recipient addresses and we use a version of Condorcet, which Clement is going to talk about how that actually gets allocated.

So, we want to keep the protocol changes minimal. So, what we propose is to use a king of the hill mechanism. So, at first we start with the recipient address zero and at each voting epoch, the validator can propose a new recipient contract. And during the voting epoch, the other validator can vote to keep the current contract or switch to the other contract. So, this is pretty interesting because it put all the heavy work in the client and not in the protocol. And it has some nice properties. So, very simple to implement. And if we have a Condorcet winner, which mean if we have a contract which will win the duel toward all the other contract, we're going to converge toward it and we're going to stay there. And in case of

Condorcet paradox, when there is no such a winner, we have what we call the Smith set. So, this is a set of contract which will win their duel against all the contract which are not in the set. We're just going to cycle within the Smith set. So, we made some simulation. So, here we assume we have three funding mechanism. And if you as a validator you say okay, my ideal distribution is 20 on mechanism A, zero on B, 80% on C. You're going to see a new proposal 50 25 25. You look at the distance between this proposal the So, this is the current contract and the new proposal 30 50 20, you see that the candidate contract is faster away from your ideal allocation, so you vote

to keep the current contract. Um so we made this simulation and we can see that sometimes okay, we find a point of sale winner and we stay there. Sometimes there is no point of sale winner and we just cycle around the Smith set. Um this is how we expect validator to aggregate preference, but validator can use any algorithm to determine whether one contract is better than another contract. So the other question is how much? So we start with zero and similar to the gas limit you can put a flag to increase the share going to ecosystem development and you can also decrease the share. So what's going to happen is we're going to converge toward the median. Um and at the Nash equilibrium we have the we have the

loss of revenue of validator should be equal to what they expect those fund will increase the value of their ease. So if they think that we are underfunded in this case they should increase the flag because that mean that the reward that they would wave, they would provide more value to their ease. And if they think that we are overfunded, they should decrease the flag because in this case they could get more money just by getting those ease for themselves instead of putting them for funding the ecosystem.

So okay, now how like what should be this mechanism? We can see for example liquid voting that would be the most simple mechanism. You just vote on funding proposal and you can also delegate and your delegate can delegate. Um it's not the most efficient funding mechanism, but it's the fastest and if we have something very urgent that we need to fund like yesterday we are talking about quantum computer coming way faster than expected. We can say hey like here we need to have a one week and we need to allocate 10 million dollar to make a team to make sure that Ethereum is going to become quantum proof.

Um we have quadratic funding. I think it has been one of the most explored funding mechanism and the basic idea with quadratic funding is that you have a bunch of project. Anyone can leave donations to them and we have matching funds. So the idea that one big donation should impact less the matching than lot of small donations. Um the funding so that's what we are working with the bench. Here it's a retro funding. So this means that you don't need to ask permission for anyone to start building for Ethereum. So you build your project and after the fact we're going to evaluate what was your the contribution of your project to Ethereum and this contribution can

either be direct or it can be indirect. So you are library which is used by a project which contribute to Ethereum. In this case you should also have some funding. Um and then futarchy. So we mainly have two kind of futarchy. So you have asset futarchy. In this case we want to execute proposal which increases the value of ETH compared to not executing them. So what we can do we basically split the universe into one universe where the funding proposal is executed, one universe where the funding proposal is not executed and we allow people to trade ETH in those universe. So you can say okay if this proposal is executed that's a very bad proposal. It's wasting

money. I want to send my ETH. Or you can do the opposite. You can say oh if you don't execute this proposal to make a Ethereum quantum proof well ETH is going to go to a zero so I want to send my ETH conditionally on this proposal not being funded. And so now you have an ETH price in both of these universe and obviously you want to pick the price the universe with the highest price of Ethereum. So if the past price is higher you go in this universe and you pass a proposal. So, this is great, but it's mainly great for a very large proposal. Otherwise, the difference of price in both universe is going to be pretty small. Um so, what we can do, we can also do metric futarchy. So, in metric futarchy, we pick a target. So, for example, we can

say, "Oh, we want to have the highest TVL of on Ethereum, total value of stable coin, DeFi protocol, everything else which is not is." Or we can say we want to maximize the fees which are paid. Uh because obviously the fee is the lower bound of the value that Ethereum is providing because if the value provided would be lower than the fee, people would not execute the transactions. So, we take those metrics. Uh you make a prediction market on those metrics. And again, you split the universe. One universe where the proposal passes, one universe where it doesn't. You trade that, and then you look which universe will maximize uh your target.

Yeah, and then um I see Peter in the back. Hey, Peter. He's with Protocol Guild, which is also one of the most uh battle-tested mechanisms that has actually worked well. Um where depending on how long you've been contributing to Ethereum core development, you get money uh based on a time waiting formula. So, they've actually created a lower bound for how much you can get paid as an Ethereum core dev. Um and also you can get outsized returns because a lot of people donate their tokens to Protocol Guild. And if those tokens go up a lot in value, they can also retire their next two or three generations. So, they can capture the upside from the projects building on Ethereum. And even in the validator proposal idea, like when I yesterday I was at the Ethereum Validators Association, and something they complained about was the lack of

operator UX. That is actually very difficult for operators to invest in developers who can make the who can advocate for them at the protocol level and make changes that are easier. So, by actually having by actually giving validators the coordination tool set, they can invest in developers who to operator UX and will make Ethereum better. Um and that would again happen through a guild sort of structure where you're contributing to that and then based on how long you've been contributing, you get more money. And next. And yeah, like there are many other mechanisms that we can do it. I think what's nice is that this is set and forget voting. As a validator, you just put the flag, you just put which recipient address, and then if you want, you don't need to edit your preferences ever again. So, it's It

doesn't suffer from the problem of voter apathy, people stop voting. Here, it's like just set and forget voting. And if you If your preferences change, you can go back and edit it and change it. But like otherwise, we don't require your continuous involvement. Uh next. And um yeah, so these are maybe the biggest issues right now. And we've floated this idea with a lot of the uh core devs. Um so, the biggest issue are the first two. Uh the second one I'll start with first, which is a basic principle-agent problem that is there at at in Ethereum, which is staking operators are incentivized to keep issuance high because they get a percentage of issuance rewards.

Whereas the people giving them the ETH care about their principle going up. Um so, sometimes these two objectives are actually not in concert with one another where operators care about getting higher fees. And whereas the people giving it want the ETH price to go up. And that leads to the second issue of staker cartelization. Luckily, we're in a pretty good scenario over here where um like 30% we don't even know who the operators are. Um and like you know, 23% is Lido, which is decentralized. It's the It's the It's the uh vault managers who actually decide on the gas limits and other things. Um so, this is also good. So, but in a future scenario where we have daps that are doing the staking, then would they be able to like put the flag up to like 10% and then they put

the recipient address as a contract which gives them the money. And then the big guys can take the money from the solo stakers. So, that's maybe the dystopic scenario here. Um the other two are um that we would essentially be formalizing the amount being overpaid in issuance. That if we if they if they put the flag up to 5% it technically means we could reduce issuance by 5%. I don't think that's entirely valid because they can have a longer time preference. They can fund operator UX which reduces their cost. So it is rational for them to put some money towards it. Um but I think the bigger question is do we want to enshrine validators as governance actors or is it just a service that they're providing the network? Um and but I think like just to conclude on a positive note, I think like the best uh

the most unanticipated consequence of pursuing this direction is that now we can actually put our ETH not just on a financial basis that they give a high yield, they have low risk, but we can actually put we can stake our ETH with operators who resonate with our values that okay, this operator has put 10% and I think 10% is the right amount and they're putting it to protocol guild as the recipient address. So I'm going to stake with them and not with Binance which is maybe putting it in a different way. Um so yeah, like we are looking open like please talk to us if this is interesting. We're looking at whether to pursue this as an EIP. Anyone wants to help out as well that would be more than welcome.

Is there question? Maybe we have two three minutes. Hi guys. Uh thank you. One of the issues that we've seen with other funding mechanisms is some of them just turn into a popularity contest which I haven't seen mentioned here. How do you handle that, right? It's kind of seems like it's prone to happen. Like whoever has the better marketing is going to get more funds somehow. Thanks. Yeah, maybe I can take this because I worked on funding mechanisms and and that's how I entered the blockchain world as well.

Um so I think the biggest issue is the lack of evaluation that I got a lot of money from Gitcoin in the 2021 era, but there was very little evaluation of follow-up done with me, which is why I think that even these mechanisms have to have a an organization behind them. Like it would be like, okay, I'm giving to Gitcoin's matching fund, which means Gitcoin is responsible for communicating the deliverables, and if they are not doing it well, then you change it. So, I feel like at some level, yes, in an ideal world, we would just be giving to funding mechanisms. I don't think the state of the art is perfected over there enough, which means you would have to give to an organization, and that organization can choose to give it through through funding mechanisms, or they can

choose to give it through committees. That would be the realistic outlook, just having been in that funding mechanism space and knowing the majority of it. I'm very interesting. I like it a lot. Have you thought about adding some sort of delegation mechanism for the validator, so that they don't have to specify an address themselves, because I could see maybe a risk there that we lock in some mechanism, because we'll and then people won't change away from that anymore, because it's very difficult to do that.

Yeah, so all the decision on whether to vote for the new contract or keep the current contract is something which is at the validator level, at the validator client. So, we expect good validator client to propose different ways for you there to express the preference, either by hard coding it, delegating it. So, that's really up to the client, and we really want to keep the protocol changes very, very easy. It's just like up, down, and keep change. Thank you for the presentation. I think the question is around bringing impact assessment on chain as well. So, I think the focus out here is to bring funding

on chain, but then if the validators aren't aware of the impact that let's say these projects are bringing to the ecosystem, how do they decide what percentage of funding should be going towards such projects? So, is there any thought process behind bringing or quantifying that kind of like an impact on chain so it's easier for the validators to make this decision or does it make sense to just go to the 50% big shops that we have in terms of validators and just funding through an off-chain process in itself? I think the off-chain process doesn't work because then you again suffer the prisoners' dilemma where I convince 50% of fund but the remaining 50% aren't funding and then the people who are

funding feel like they are like being the patsy. So, I think that like that's why we needed to be at the protocol level and in terms of evaluation, I think the good feature is that they are spending their own money. Like if I'm spending your money, I'm going to be more liberal with it, but if it's my own money, then I'm much more careful. So, I think here it's validators choosing to part with their own money which means that they will they have a direct incentive to keep up to date and see that it's actually being spent well. So, it's not a perfect answer, but at the protocol level, I don't think impact evaluation can be hard coded because like Clement said, we have to keep it very bare-bones like up down change keep. That's it.

Okay, thank you for this great presentation. Congrat. >> Woo!