Sourcing Funding for Ethereum Growth - Devansh Mehta

Transcript

But yeah, like I think broadly I'm talking about the idea of how we can increase funding. Like so far a lot of us in the space have focused on once we already have funding, how do we best divide it amongst different projects or what we call allocation. But this talk is focused much more on where the money comes from in the first place and much less on how it's divided or who gets the power to which is the nerdy questions that we all like, but I think given the bear market vibes, this is what we need to focus on. Um so there's a lot of slides. I'm going to go through them very quickly. Uh but the first question is why is it important in the first place to try getting this sort of money for these like infra? So here I can I can tell you about six projects

and we have some kind of product which is giving value to all of them. So let's assume that it's giving $10 of value to six projects and it costs $50 to actually maintain. So um it's it's like economically rational to fund this project because there's a gain of $10, but it doesn't get funded because the six actors can't coordinate to each give $10. And no single actor finds it profitable to give the entire 50. Um so because of that no one funds it in the absence of coordination. So this is currently where we all are stuck and it's bad because economists refer to this as deadweight loss which means that even though two parties want to transact or make a transaction, they still can't

coordinate and make that transaction happen. Um and like and and like like most economists believe that uh economies with a higher deadweight loss tend to get outcompeted by those with a lower deadweight loss. And um and I think this is especially important for Ethereum because we currently only rely on donations and uh like in order to fund some of these goods, whereas the real world and the real economy has taxation. Um so we don't have anything better than that right now. So I don't see Ethereum outcompeting the real world until we can actually reduce deadweight loss in a in a more like structural way.

Um so yeah, enough of the doom and gloom and now we can move on to solutions. Um so this is like kind of a broad level the solution space that we can work within. So at the top most level is the application layer, then we move on to the smart contract layer and then the consensus layer of how we can actually get funding into into supporting the coordination goods that we need. Um so I'll start with the last one, the consensus layer, and then I'll move work my way up from there. Um so at a very structural level validators have an incentive to support Ethereum growth. Um because if they increase if they invest in ecosystem development, that creates demand for block space. And uh and the more demand there is, the more ETH gets

burnt. And because of that um their profits increase, the value of their ETH. They all have to stake 32 ETH. So that would go up and they can put that back into ecosystem development. So there is this incentive loop that exists for validators, but we don't actually see this playing out. We don't see any validators except for Octant, shout out to Octant, which is a great project. Uh we don't see many of them actually staking ETH and funding the ecosystem with the rewards, even though it benefits them to do that because the value of the underlying would in theory go up. And why is it not happening? I think it it resembles a classic prisoner's dilemma situation where you have two validators, validator A and B.

If if if both of them fund, then it's good for both of them, but if one of them defects, then it's bad for the one that funded and it's good for the one that didn't fund. Um so because of this, we get stuck over there, which is bad for A and B, like neither fund, because there is no mechanism to force everyone to fund or no one to fund. So that's kind of the theory on why. And like this is what taxation solves for. How much ever we all hate taxation, uh it actually does solve this problem that like everyone funds or no one funds. Um Yeah, so like how would we actually start like making an EIP to change it?

Um, so this is like the concrete proposal that we have for it. Um, so it would be a simple mechanism like similar to how validators put up a flag showing how much gas limit they can tolerate or how much they can increase. They put up a flag saying how much of my rewards do I want to reallocate into the ecosystem. Uh, so they put up a flag and it increases or decreases per block. And on a Nash equilibrium basis like they would put it up to a non-zero amount such that the loss of revenue is equal to the extra value to their underlying principle. Um, this is not perfect because um there are like all the people who are not staking ETH would still benefit from this. It's not just the stakers, but it would be at a non-zero amount is our

theory. Um, so it's very simple at a protocol level like validators just have to indicate increase, decrease. And that's it. That's That's happening at a protocol level. I think the more thorny question is like who gets the funds? Like it's easy to get money, but like figuring out how it's distributed is where all the problems arise. And um So the mechanism which we are proposing is like something called the king of the hill mechanism where validators list out all the addresses that they want funded and also by how much. And um And then after that like you know the execution layer clients can take those static preferences and come to some form of consensus after that. Um, so it's very simple implementation like anyone

can propose a contract saying that this best fits the preferences indicated by all the validators. And uh and that becomes the contract. And anyone can propose a new contract saying that hey, I think this better fits the preferences stated by validators. And if it does, then it it replaces it. And if it doesn't, then we keep the original. So again, like the thing is at a protocol level if you're making an EIP, we want to be very careful of not adding complexity. So the first part is just increase or decrease. Like am I willing to increase if I'm earning $100 in yield today? Am I willing and have to give $5 to reinvest it? Uh do I want to increase it from five to six or decrease it? So that's all that's happening at a protocol level here. And the second one

is that do I keep the existing contract that's dividing the money between different addresses or do I replace it? Um so that's all that this is happening at it. So this is like a brief on how the actual implementation would look like. So you have stakers, they can signal the amount whether increase or decrease. And then uh we use a method called Condorcet. It's like an adaptation of the method in order to get consensus of okay, this much percent to a token voting now, this much to QF, this much to deep funding or protocol guild. So that's kind of how we think funding should work at the protocol level. Like if you actually want an EIP to allocate funding uh from block rewards into the ecosystem, we think this is the most credibly neutral way to

do so. It's my personal opinion. It's not like any anyone else's. There are definitely issues and I'm not going to spend too much time on this, but um I think the biggest issue which we are seeing in staking generally is uh the principal agent problem between staking operators and um and the people that have delegated their ETH to them. So like I give you my ETH and you stake it on my behalf and that's caused issues because um the people who delegated just want the value of their principal to go up, whereas the people who are staking it for them care about the issuance being high because they get a percent of the staking rewards. So we've seen like a very rooted like principal agent problem crop up in Ethereum because of

this reason. And um So and given that staking operators are the ones who will indicate how much percent they want to reallocate, who gets the money. So this kind of can accentuate some of the principal agent problems. Um yeah, like I mean the thing which we are looking at is now whether to pursue this as an EIP and actually file it. So, if any of you are interested in this aspect of the work, like please come and talk to me. So, I'm going to move on to the other layers of the stack now. Like this is what we think at a protocol level which can solve the free riding problem because if 51% indicate yes, we want to part with 5% of our staking rewards, all 100% have to do it. So, it actually solves free riding if we if we go ahead with this

approach. Um so, yeah, smart contract enforce dependency funding. So, um So, I think like we all know that DAOs have kind of a long way to go. Like having direct democracy is not the best system where you ask people to vote on everything. Um and especially if you look at some of the other mechanisms like quadratic funding or others, um the biggest issue is that there's no incentive there's no penalty for being wrong and there's no reward for being right. Even if I voted well, it's not like I get rewarded for it. And even if I voted for a wrong project, it's not a bad proposal, it's not like I get penalized for it. Um so, this is kind of one of the methods that we've done. It's what I've worked on over the last year where you take a repo and all of its

different dependencies. So, here we've taken Helios' dependencies. Like it's like a large market. We created a 3,677 dependency market. And people are building AI models and other machine learning models to try predicting the value of each dependency. And then we go ahead and ask some humans, like some experts, "Hey, what do you think is the value of this dependency?" And then the traders in the market earn a profit or loss depending on how close they are to human judgment. Um so, this is something which can be encoded at the smart contract level that this is my smart contract, these are all the dependencies, and whatever revenue of fees are being earned by the smart contract can programmatically be

channeled to some of its dependencies based on the market trading and the people who vote well or trade well, they earn a profit because they are trades move the market price closer to the human judgment and those who do it badly end up losing money, which is exactly what you want. Yeah, the markets for this are live. You can check them out at deep.cr.pm. They're live for another month. So we have like a bunch of cool projects and all of their dependencies. It's a really fun competition. $20,000 in prizes as well to build models and submit and be close to humans. Like the data scientists are having a blast with this competition. So definitely like check it out.

Yeah, so like this is the larger approach. You're just creating a market from a dependency graph or an S-bomb. And I'll give you like since we are in Prague and Europe, I mean I'll give you like a quick like the open source I've been spending a lot of time with the open source community recently like general open source non-web 3 and all of them are very excited about this act in the EU called the Cyber Resilience Act which kind of just to quickly summarize it every digital product whether open source or closed source has to now reveal all of its dependencies. It's what's called a GitHub S-bomb software bill of materials. So for the first time we'll actually get to see what are all the dependencies that X is X is using or that Facebook is using or Instagram is using. And that allows us to create

these sort of dependency graphs and we can then also start channeling money through these dependency graphs. So that's kind of the larger idea that you can start creating markets from So it's not just like X is revealing all of its dependencies. If we also want them to start funding their dependencies, we actually have a method to get weights which is not just equality sort of nonsense. You know, everyone gets the same amount. Like it's going to be weighted based on the market trying to predict what the expert is going to say. Um Yeah, and like we've actually run a couple of these iterations and there's massive volatility which shows that this works. Um so like this was a repo called act and like someone put a lot of money trying to manipulate the market. It went up a lot, but the best part of these

markets is that um your attempts to game the system are my profit margin. So the moment this went to an unreasonably high amount, everyone shorted it and it quickly went back into its original place. Um so I think that's like the biggest advantage that uh we are using traders to try to uh stop the uh the manipulators from actually trying to get a higher amount of money in this mechanism. Um yeah, so I think now we're at the last part of it which is the app layer. Um so like at like whenever people ask me like developers ask me that why should I build in blockchain and I think all of us have got this question to some extent. Uh like the common answer I give them is that blockchain is the only one

that allows you to separate the back end and the front end. So if I'm building in web two, my front end is the only one with privileged access to my back end. Uh but in blockchain, I can focus on just the back end and then anyone in the world can build a front end from my back end. Um so I think there's a lot of opportunity there. We've not really seen this play out. Like even Ave uh has only like one front end really that people are using. There was a governance dispute some years ago sorry some months ago for people who remember where um the DAO was saying that oh Ave owns the front end, Ave Labs, and because of that they were upset like you know saying that no, it's actually ours and we should own it and we should take it. But

if there was a situation where there were multiple front ends, the governance dispute would have been much less heated. So I think there's an opportunity here that with AI, we have all of these different back ends and we can create front ends which say that hey, a percent of fees should be routed towards uh reducing dead weight loss in Ethereum. Um And then users can vote with their feet whether they actually want to use these sort of front ends or they want to use other front ends. Um so that's at least at at a theory level how the app layer would work. And the second aspect, so this is a proposal we made to Arbitrum DAO. Thanks Arbitrum DAO for funding this proposal, but it's the wrong way to make funding requests.

So we asked for This is some years ago. We asked for money to support an attackathon where we tried to test the Ethereum resiliency. And and and Arbitrum did fund it, but like the problem with this approach is that we have to keep going to them every time and ask for funding. That hey, we have this new initiative, please fund it. Hey, we have this other initiative, please fund it. Whereas what we are now trying to focus on is more embedded mechanisms that if like Arbitrum DAO is earning yield, like I think they're they've earned 3.3 million of in yield in interest. So we'll basically instead the ask would be that hey, out of all the yield, can you allocate 1% of the yield towards funding the ecosystem? And then it takes a vote

to turn it off. So rather than having to constantly go and ask for votes, you just have to get it passed once. They agree, like okay, 1% of our yield. And then after that, if anyone wants to reduce it, they actually have to turn it off. They have to put a vote and then say off. So that's much more sustainable than going every time and asking it, which is what our theory is around embedded mechanisms and embedded flows. Um Yeah, so this is the last slide and I'm done over here. Um so this how is how everything would tie in together. Um you would have a user who submits a $100 swap. The application layer would redirect some into the PG fund.

Um Then it would go to the smart contract layer, which would again give it to its different dependencies. And then it would move to the consensus layer where the validators are able to redirect some portion of it. So this is how we see the entire vision playing out in the long run. But, um this is the like one proposal. Like, it's like how in the internet the best way to get an answer is to give the wrong answer. It's not to ask a question. So, you should also treat this presentation similarly that like we have there is a genuine need to reduce the deadweight loss. We don't know how to ex- how to do that, but this is our wrong answer. And like, if anyone wants to work on another wrong answer, like happy to talk. Yeah, that's the presentation. Thanks.

>> Thank you so much. Thank you so much. That was fant- and so interesting because I think that civilizations have been trying to figure out how to fund themselves and sustainably for millennia. So, I think this is an age-old question that you're trying to crack. And I don't understand half of it, but it's beautiful. Ladies and gentlemen, any questions? Please use the opportunity. And not all at once, please. Yes. Gentleman in the back. >> When it comes to like validators kind of like giving funds throughout the ecosystem for their own economic benefit, how do you like remedy the problem of like if it's a really efficient market

and a lot of validators are contributing these funds, how do you solve the problem of like validators giving funds to optimize for variables that are good for them, but not for the whole ecosystem? Like, if they just want to increase, say, the the gas limit so that they can get more transactions in and more ETH burned, but maybe that scaling leads to more centralization, how do you kind of eliminate those kind of problems? >> Right. Um yeah, like I'll tell you one example which we did discuss, which is that a lot of the validators wanted to improve what they call um validator UX or the user experience of validators. But like, a lot of Ethereum doesn't care about improving the

validator UX. A lot of solo stakers don't care about improving validator UX. Um but in this proposal like the validators could easily get together and say that hey, let's fund this developer team to represent validators and improve validator UX at the protocol level. Um and that's again like going back into the principal agent problem where a lot of the people who are uh staking are like you know, they operate on razor-thin margins staking operators. So, they don't have a lot of money. So, this proposal would let them use the user money in order to fund improvements that can improve their own margins. So, that's like the kind of I think that's the main concern that you're raising that they're not doing things which are

useful for the ecosystem. Um we don't fully have an answer on that. I would be lying if I say that we do. Um we have done some mathematical analysis showing that uh a cartel can't be formed. Like it's not like no Nash equilibrium cartel can be formed because every time someone tries to form a cartel, like it's always profitable to remove them and share their money amongst each other again. So, there is that kind of optimistic mathematical analysis we did. But I think the larger principal agent problem like we don't know and it's a bigger problem than just this proposal.

It's like a larger problem that we all are trying to figure out now. Yeah, go ahead. Thank you. >> Thank you very much. Yes, I think the problem of humanity, how do we stop people taking money? Um again, something that has not been solved. Um any other questions, ladies and gentlemen? I think we have space for one more. Yes sir. >> So, this is about the dependency graph. Um if you go back to that slide. Do you think that having this information fully public would actually create further risk vectors and that people know where the bottlenecks lie?

>> Like would they create further >> like risk vectors because now it's more obvious where bottlenecks lie in our system? >> Oh, right. >> Like because everyone is now forced to reveal all of their dependencies, that decreases security of the ecosystem and of that app. Um yeah, I think it's like a graph where if you're closed source, you're more secure than open source. But if you're open source for a longer time, then you're more secure than closed source. Um so I think the principle is called Shannon's principle in cryptography where um uh security by obscurity is not a valid security model. And so I think that would be the answer that

yes, we would all be more insecure in the long run in the short run, but in the long run, we would be more secure because then we are like not relying on security by obscurity, but the only ones who have access are the company itself and the North Korean hackers. Now everyone has access, so I think that's kind of the good part of it. But yes, in the short run, I expect a lot more security issues to arise. Yeah. >> Thank you so much. Ladies and gentlemen, again, if you want to carry on having this wonderful conversation and this wonderful topic, please uh do ask questions in the foyer. Thank you so much for a great presentation. Round of applause. Thank you.