Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Dankrad Feist: Ethereum Foundation – An Eth2 Progress Update #2

Episode Date: June 22, 2021

Ethereum 2.0 is an upgrade to the Ethereum network that aims to improve the network's security and scalability. Recently, we chatted to Danny Ryan about the Merge and switch to Proof of Stake. As a follow up to that episode, we were joined by Dankrad Feist, who heads the sharding and statelessness research at the Ethereum Foundation.We dove deep into the technical infrastructure of how Eth2 addresses scaling through sharding, the pros and cons of data shards vs. execution shards, and how this links up with ZK-rollups. We also talked about the Ethereum state and how the state can be altered for protocol improvements.Topics covered in this episode:Dankrad's background and how he came to work on EthereumAn overview of potential protocol updates and where they’re at right nowData availability shards and the overall concept of sharding in the protocolHow shards are maintained with validators and Proof of StakeHow Rollups work and the vision for their futureThe role of execution shards and what they provide that data availability shards don'tComposability across data shardsStatelessness; what the Ethereum state is and how it is usedWhat is state rent?EVM and parallelizationDankrad's views on the future of Ethereum and what it will bring to the blockchain spaceEpisode links:Episode 393 with Danny RyanEth ResearchEthereum BlogEthereum CommunityEth R&D DiscordEthereum on GitHubEF on TwitterDankrad on TwitterSponsors:Exodus: Exodus the easy-to-use crypto wallet available on all platforms and supporting over 100 different assets. - https://exodus.com/epicenterParaSwap: ParaSwap’s state-of-the-art algorithm beats the market price across all major DEXs and brings you the most optimized swaps with the best prices, and lowest slippage - http://paraswap.io/epicenterThis episode is hosted by Brian Fabian Crain & Friederike Ernst. Show notes and listening options: epicenter.tv/397

This is Epicenter, episode 397 with guest, Dengrad Feist. Welcome to Epicenter, the podcast where we interview crypto founders, builders and thought leaders. I'm Frederica Ernst and I'm here with Brian Crane. And today we're speaking with Dengrad Feist, who is a researcher at the Ethereum Foundation and heads the effort into sharding and state business updates for Ethereum 2. But before we talk about Ethereum 2 with Dankrad, we'd like to tell you about our sponsors for this week. Paraswap just came out with a huge update. That's even faster and more liquid.

It's cheaper than Uniswap and comes with a new gas token that can cut your gas fees by up to 50%. Paraswap is now multi-chain and has expanded to Polygon and Binance smart chain. Start trading at Paraswop.io slash epicenter. And also by Exodus. Exodus is an easy-to-use wallet, which supports lots of assets and has native apps for all the platforms, including iOS and Android. It's a fully non-custodial wallet. they believe in, not your keys, not your coins.

And so, yeah, go to exodus.com and give it a try. And with that, yeah, let's hand over to Dunkrad. Thanks so much for coming on. Maybe you can start before we dive into all of the technical topics. You might introduce yourself a little bit and telling us sort of how your journey has come to working on Ethereum. Yeah, hello, thanks for having me. Yeah, my journey to Ethereum is, yeah, a bit different from probably most people because I came to it quite late, I'd say.

So I only started fully working in Ethereum Research around 2019. And before that, I worked for all different tech companies. I had a startup. And I was basically recruited into the Ethereum research team after I had solved some research problems earlier for them and worked on them. And yeah, so basically since early 2019, I'm working for the Ethereum research team. It has been like a very fun journey. And I'm really enjoying doing research on the future of Ethereum. Cool.

So we had an episode on Ethereum 2 recently with Danny Rye. and we actually ended up talking about the merge and the switch to proof of stake for the entire episode. But there's a couple of more updates that are coming with Ethereum 2. So can you give us a very brief overview over the potential protocol updates and where they're at right now before we deep dive into them? Right. So, yeah, I mean, there will be several more updates. I think like the really the biggest one that everyone is waiting for is the big promised upgrade of sharding. And so probably like a while after the merge, I don't know, I would estimate between

six and 12 months. We will activate data shards, which essentially means we are adding this very large data availability layer to Ethereum, which means that you might have heard of roll-ups, which are basically a system where you only post transaction data to the chain, and you don't actually execute them. You either use fraud proofs or zero-knowledge proofs in order to ensure that all this is actually valid. And the data charts actually allow us to, instead of posting that data on the current very limited, ETH1 chain that will be merged into the beacon chain with the merge,

instead of posting it on there, you can post it to these data charts and ensure like it's available and everyone can very easily verify that it's available, but it will be much, much cheaper because you have so much more space available there. Further to this, there will be a lot of work on the security of this. So we have kind of opted for this gradual rollout where we don't like do everything in one big bang, which kind of started with actually started last December with launching the beacon chain and will continue with the merge and then rollout of sharding. And there will basically, after that, there will be many further upgrades,

which are probably a bit less obviously visible to the user because they're more security upgrades. So we kind of opt for this way of rolling out features first. We start by like making the big rolling out the big features and then, we add everything that is required to get them towards the highest security. So they will basically be all the work around ensuring data availability. That's the proof of custody and data availability checks, which are basically further upgrades that are required to make data availability

basically fully incentive compatible, like to make sure that there are no incentive problems for validators. Before we go into, I think there's like so much already. I think that you should probably explore a bit more. So you mentioned that the first sort of sharding is this data. So data really charts. Can you explain in, so today, right, we have the existing system that we know and, you know, it's very much a capacity and the transactions are too expensive and it's a big pain

for the users. So when you have the state of ability charts, like how will they help scale Ethereum and you know what kind of parts that gets executed today on Ethereum will be moved there? Yeah, so that's basically going to be the roll-ups. So we already have several roll-ups active on Ethereum now. So for example, ZK-Synk and others.

And basically right now, the way they work is they post, so for example, Zika Roll-Up works by posting this blob of data on the chain that says like here are all the transactions. And then at the end there's a proof that says, okay, this is the new state route that comes out of it. So with data availability charts, you only have to put this very last part on the execution chain. You only have to put the part that says, this is the proof and this is the new state route on the actual execution chain. And everything else can just go on the data availability shots. So you basically save a huge amount of gas that you don't need any more to post this data. But actually today, I guess you don't have roll-ups taking up a big part of the block space. I haven't looked at the stats in detail.

but I would suspect that at least, I mean, they're still very, very new, right? Like, we haven't had roll-ups for a very long time. But I would suspect that they would very quickly dominate the block space because essentially they allow you to do things paying about 100 times less gas. So why would you do a transaction and pay 100 times more if you can do it for 100 times less? And of course, since it's much cheaper, will be a lot more transaction, right? I mean, it's a kind of obvious, like, consequence from having some sort of demand curve for transactions. So I would say the natural economic equilibrium

should be that almost everything happens inside roll-ups. Okay, so let's talk about the concept of a chart, right? So is the chart kind of like a second blockchain that runs in parallel with the first one, or how do I imagine this? So I will answer this question from the perspective of data sharding, which is kind of this goal that we're currently working towards. And there might be, or they will likely be in the further future, execution charts, which will actually also be, also execute code. But that is currently, like, that is several years in the future. And so I will not take that mainly into account because data charts already achieve a lot of what we want to do. So from the perspective of the data charts that we're

out now, you shouldn't see the charts really as different blockchains because they will not come, they will not kind of come with their own fork choice rule and build on each other and so on. It's basically just, you could say it's just additional blobs of data that you put on the chain, but with a special property and that property is that full nodes do not need to download these blobs in order to ensure that they are available. Like, we have a scalable solution that allows full nodes to know that they're available without downloading them. How does it work?

So this is, this comes from a very interesting technique that, that is called data availability sampling. The essential idea is that you, you can, you can sample, you sample small amounts randomly selected from the data, and thus you know that very, very likely, very large parts of the data available. So this is obviously not enough, because if you do that, then you notice that, oh, like, but 99.9% of the data being available is not enough because that 0.1% could be exactly where an attacker hides their malicious transaction that prints 1 trillion ether, for example. We need 100%.

And the way you do that is by encoding the data in a special way, that you know, that you're makes sure that even if you only have 50% of it, you can always reconstruct 100%. And that is the key trick towards data availability that allows it to scale. And that means that basically with a very small constant amount, so it does not actually depend on the total amount of data that we ensure to be available of these samples, you can ensure that the full data is always available for download. If you look at Ethereum 1, you have miners and you will have validated. after the merge. So how are the shards maintained?

Are there also validators who maintain the shards? Yes. So validators will be randomly selected, essentially. So there are committees. A committee is a random selection from the full validator set. And these basically validate the charts. They are kind of, I guess, the right thing to say with data shards. this first barrier, this first group of people who are responsible for checking that the full

data is available. And they need to do nothing else because there is no execution. So they do not need to do anything except for knowing that the data is available because that's all the data charts do. And the validators, they are, but they only validate on the shots. They don't validate on the main chain. They do. No, no, it's the same validator. So the same validator. So So it's only one set of validators. It's all the same. And they both validate the beacon chain and they validate the shards. And this is essential.

Like, I mean, this is one of the, I mean, this is why sharding is so important in our terms. Like, it's this notion that we call shared security. So like the essential part is we don't want, I mean, you could ask the question like, well, can't, can't you just have like many different blockchains communicating with each other, and you get the same as shards. Problem is that you don't. You don't get shared security. Like each of these blockchains only has its own smaller validatorsets

and so has much less value securing it. Whereas like in a sharded system, the essential thing is that it's always the full value that is securing the whole system. There's no like subset that is responsible for one chart. Okay, so basically say I'm a validator now on the main chain. And I also then have to validate the shots.

Do I have to validate all of them or do I get a subset? Basically, you get randomly assigned every epoch to one of them. So basically you have like a completely, a completely random one that you have to validate. So you don't have to validate all of them. You will be on, you will be validating all of them. But each epoch, you only apoc, you only validate one of them. And that is random. So you're basically, you're basically.

Basically, you're only doing the work of validating one of them. Okay, so does this also mean that proof of stake is a prerequisite for sharding? So the answer is yes. And the reason is that minors don't have any sort of identity. So you cannot, the notion of assigning like a minor to a random committee and telling them, like, you need to validate the chart now. It doesn't make any sense because they don't have any, the only thing that identified them is how much hash power they have.

Whereas validators and proof of stake, they have to pay this deposit, and after that, they have a public key. And we can say, like, this is the public key that is now in this committee. So in that way, it is essential to have proof of stake for sharding. Okay. And are all data shards created equal, or are there different flavors? And how many of them will there be? So they are exactly equal.

There's no difference between them. The only way is how applications use them. So there could be roll-ups which basically decide, I only accept blocks that are submitted on a certain chart number, which makes sense for them because then they need to check less data for whether it's relevant for them. But from the consensus layer, they are exactly equal. And how can I make sure that my transaction gets sent to the right chart?

So this would only be relevant. So I mean, this is an application specific detail, but the answer will depend on what kind of roll-up you use. And I would say it's very likely that in most applications, a user will not usually, at least, directly send their transaction to a chart or like to the validators even. And they will rather send it to,

to whoever is responsible for creating blocks of this roll-up, and they will then put it on a chart. So if I understand correctly, the data shards are mainly targeted at roll-ups. Can I use this to store other kind of data? So kind of, say, for instance, Oracle data that kind of clogs the blockchain currently. Yes. I mean, I don't see why it couldn't be used for, or oracles.

Yeah, I mean, you have to think about, basically, the only thing is, it would still be a kind of roll-up oracle, I guess. So in a way, in a way, it's all roll-ups. Yeah, but, but, I mean, you can have many different kind of roll-ups. Like, you could have, like, a contract-specific roll-up. Like, I mean, actually, many roll-ups right now are very application-specific, right? For example, they only do transfers, which is, in essence, one application. So I think the roll-up notion is not restrictive.

It can do everything. It's just a way of implementing what you want to do. When you want to trade tokens on Ethereum, make sure to consider Paraswap. Paraswap is a decentralized exchange aggregator so that you can get the best price across multiple Ethereum Dexes. And now Paraswop has just been integrated in Ledger Live. This means you can swap tokens using your ledger tag. directly from the Leisure Light app. No third party is involved.

Peresrop is also multi-chain and available on Polygon and Binance smart chain. Give Peresrop a try at Peresrop.io-slash-Epresenter. We'd like to thank Peresrop for their support of Epicenter. Maybe it would make sense to spend like a few minutes if you could explain a little bit, like how do roll-ups work and what do you think the role of roll-ups is going to be in the future? Yeah, roll-ups are essentially the, this notion that you use the chain only to ensure that data is available without itself computing the correct execution of the data.

So most obvious way, this is when you use, so there are two flavors of rollups, right? They're optimistic roll-ups and ZK roll-ups or zero-neudge roll-ups. So the way ZK roll-ups do this is maybe the more obvious one. like you put all the transaction data on the chain and then you have a zero knowledge proof that says this is the result of the execution of that and here is the new state route. Now you could ask the question

why do I even need to put the data on the chain if I know that the computation was done correctly, right? Why does that matter? And the reason for that is that you need to be able to reconstruct the state as well as just the root. Like if you just have the root, the problem is that the root is not enough

to access your account. You always also need a proof that shows that your balance in that account is X, right? You need this as well. And you can only generate that if you have the state. So that's why it's essential for preserving this trustlessness that you also get all the data that's required to reconstruct the state. This can actually be less than all the transactions. So you can also, in a ZK roll-ups, for example, it can also just be a diff of the state.

It can just be literally like the difference in the state that you need to put on chain. But that part is essentially. An optimistic roll-up does it slightly differently. It puts a list of all the transactions. And in this case, it has to be all the transactions, even including signatures, on the chain. And also adds, like, the new state rules says, like, this is the reason of executing this. And then anyone can, if there was an incorrect one, if there was some incorrect execution, and this is not the correct outcome,

then anyone can post a fraud proof that reverts this block and resets the chain to the previous state. So that ensures that a fraudulent transaction can never be included in that roll-up. To get some more background on ZK Sync and ZK Roll-Ups, last week's episode was with Alex Kukowski of Matter Labs. So you can also go back one episode and check that out. So Dan Krat, can I ask.

ask about this switch from full charts or execution charts, as you called them earlier, to data availability charts. Because if I recall it correctly, a while ago the idea was to actually have full execution charts that would not just make data available, but also be able to execute smart contracts and then loop back into the main chain. Why was this abandoned? Or at least, if not abandoned, then kind of split it. into a journey of two parts.

Right. So to be actually clear here, I think doing these data shots first has always been on the roadmap, but it was probably less emphasized. I guess several years ago, it was thought that this is like just a first step to kind of test the whole system out

and test it under load. And more and more, it has become clear, I would say, how awesome roll-ups are. Like how, what's, because they on their own already provide this 100x scaling, essentially, if you do them well. So in the end, you could ask the question, like, why would you do, why would you even

do, like even on the execution charts, why would you do anything other than roll-ups? So this is, I would say, why it has more and more converged towards this notion of, well, actually like the main the main advantage like the the huge scaling comes when you have the roll-ups and and and maybe execution in the end won't even be necessary but the factor of a hundred i mean that's still not enough right i mean basically if you look at the adoption of ethereum right now and the potential adoption of ethereum and if you if you then also look at what the what the gas prices currently are, it seems to me that a factor of 100, yeah, it's something, but it's not a lot. Oh, right. Absolutely. Oh, no, no. But I mean, the roll-ups can scale the current system as it is pre-sharding

by 100x. Now, once we add sharding data shots, just data shots to that, then you get another like 100x of the data availability roughly, like order of magnitude. So now we add 10,000 X. So that is a series amount of scaling to start with. And that is not an absolute limit. Like we can add further shots. So the 64 shots is according to that is just a constant. Of course there are tradeoffs and like it depends on how much value we have at stake and also importantly how many users there are, how many shots we can support securely.

But it can be scaled further from that point. So that that 100x is not the limit that we are. Let's go back to the execution charts. So I now understand that the data availability charts were always part of the plan. But what do you gain from execution charts that currently data availability charts cannot give to Ethereum? So I guess this depends. So basically this depends on how far zero-energy proof technology, will develop in the future.

So I think the main downside, there are basically some downsides of optimistic roll-ups in terms of their finality. Well, I mean, yeah, so basically they need this very annoying, too-week withdrawal delay that you can kind of work around

for small users, like that don't have too much value, but it's always going to be a problem. Like the solution is great for many things, but it's not perfect. So now if you have very good, if we can get a very good zero knowledge virtual machine, basically, a complete virtual machine that you can run inside a zero knowledge proof within the next few years, then theoretically you can already with that, like build essentially what are execution charts from,

from what we have now. And then potentially at that point, getting execution charts might just mean nothing more than enshrining that ZK roll-up that is doing that. So that might be like a very simple step if we get there. Well, I mean, I'm very interested to see the progress on this.

Like the zero-nurtch proof space has like made really amazing progress and almost every year like delivered more than I would have expected. it. So I would not say it's impossible, but it is still a very, very difficult thing to

deliver the full kind of everything that the EBM does now in a ZK roll-up. If we don't get that, then execution shots might basically special kinds of shots where you essentially get much faster finality because the

difference to like the problem with the optimistic roll-ups is that you have these kind of finality delays. And if we do make validators responsible again for checking execution, which is essentially what an execution chart would mean, then you would basically get another settlement layer on top, I would say. Oh, that's super interesting. Actually, I would love if you can speculate a little bit on how do you think the sort of supply

of Ethereum block space and throughput is going to develop, you know, over the next year. So, and how much and when do you think those different technologies will start to have an impact? Right. I mean, I think my intuition is that we can see the impact of roll-ups right now. Like, we have seen this huge crash in gas prices, essentially. And I think that is probably partially because a lot of people have actually moved to roll-ups now for some simple applications, which is amazing.

I don't think the gas reduction on the main chain is going to last, but the reduction on the roll-up is going to last. So that's pretty great. So there is basically right now, at least for simple things, there is already this pretty much 100x increase in supply as long as what you'd want to do is transfers of ether or ERC-20. And then the next very big thing from that will essentially be sharding. So when we activate the data shards, then for everyone who use roll-ups,

there will be another 100x increase in supply in block space. Let's get to our sponsor, Exodus. Exodus is a fantastic cryptocurrency wallet that strikes a right balance between ease of use, security and great features. You can get Exodus on the iPhone, desktop app, web app, Android, whatever platform you use. It's a non-custodial wallet, and that is so critical. Because what's the point of crypto if you don't control your own assets?

With Exodus, you always do. They're old school, and they've been around since 2015. Over 1.2 million users rely on Exodus, so you know that they've stood the test of time. They have support for over 100 different crypto assets, and from within Exodus, you can easily change one different asset to the other. They also allow you to buy crypto with Fiat, and they even have a great offer where you can buy up to $500 worth of crypto through their iOS app and pay just $1 in fee.

So go to exodus.com slash Epicenter and check out their wallet. We want to thank Exodus for their amazing support of Epicenter. One of the problems that you also get with execution charts, if you were to introduce them, right, is cross-shart communication and composability and the consequences of this on finality. Do you think this is such a hard problem that it won't be solved? Or do you think if we need to, we can solve this? It's not so much that cross-shart communication is not an unsolvable problem.

It is just a difficult engineering problem to get all that. details right at least for asynchronous communication for synchronous um then then yes you have you have a very difficult problem at hand not an unsolvable one again but i think that that yes that essentially my guess would be that's not going to happen um that you will do synchronous communications across shards or in data charts world you actually have the same problem it's basically cross roll-up communication in this case. Can you just explain synchronous and asynchronous communication

in this context? Yes, so asynchronous is basically without like without a certain delivery guarantee. Like you can't, you can't so synchronous communication

would be what enables composability directly between charts which I think is not a very realistic thing to expect in this sense because it would mean that anyone can lock up resources on the blockchain. Like, I mean, essentially what composability means

is that you have this lock on the whole chain in a way, right, where only you get to determine what happens. And I don't feel like this. is likely to be a thing across charts, although very theoretically possible. I mean, in computing, we have all the models to do that. It doesn't make that much sense to me. There are all kinds of ideas to get around this, but I think the more realistic thing of how that will work out is that you have certain ecosystems in certain charts or

certain roll-ups that care about composability internally, but are more loosely coupled to the other systems around them and are okay with asynchronous communication, which is you send a message and it will be delivered at some point, but you don't have any guarantee when, like any absolute guarantee. In practice, it will always be very, very fast, but you have to consider this very worst case that it could be delayed for a very long time. Okay, so let's talk about composability across data chart. So basically, if I have data within different roll-ups, are these still available after the fact or is that a problem?

Can these be accessed by other applications at a later point in time? Yes, so that is basically the way we've designed it. It's instantly available to everyone. So there's no delay in communication between the different data shots. There is a limit in, I don't think, I think it's theoretically possible to have some notion of composability between ZK roll-ups. I don't know if that will be built.

It's pretty much impossible for optimistic roll-ups to do anything like that. However, I think maybe one notion we should, we should correct here that many people have. So one roll-up doesn't necessarily have to be only on one chart. So you could have a roll-up that basically takes up 10 chart blocks like in every cycle, right? And essentially that roll-up internally can provide full composability. So it is not like we are limiting any sort of composability

between the data charts as long as there's one roll-up And at least for ZK roll-ups, we can in theory build these big roll-ups. It's a matter of optimizing everything enough that provoers can handle this and are not too crazy expensive. But you could have these huge roll-ups that provide internal composability at least. Cool. That's super interesting to hear. And I think this kind of clears up most of our questions around charting.

So I'd kind of like to switch gears and move into. the second topic for today, which is statelessness. So statelessness is another big issue that the Ethereum Foundation research team is working on. So can you explain what the Ethereum state is and how it's used? So the Ethereum state is essentially, it consists on everything that is stored on the Ethereum blockchain. So it would be, for example, for you as a user, it would be the balances of your accounts. it would be the balances in ERC20 tokens that you have,

but also any other kind of data that is necessary for, for example, a smart contract to know whether something is valid. It's the code of the smart contracts and all of these things. Those are all part of the Ethereum state. And at the moment, every node in the Ethereum network has to store this because the only way to know from whether one block is valid is to have the state and execute all the transactions in that block and update that state and know that this was all done correctly.

What's the current state of Ethereum, so the size of the state? And is that in itself the problem? I don't have the very best idea of the numbers here because they also depend on implementation details. It's somewhere in the tens of gigabytes as far as I'm aware. I've been quoted numbers between 10 and 100 gigabytes. I believe it really depends on how exactly you store it. And you can do that more or less optimized.

It is a problem in the sense that already that makes it necessary because each block does a lot of state accesses, right? like each block, each single transaction already accesses like at the very least two accounts, like the send and the receiver. And so you have these hundreds of transactions and potentially like thousands of state accesses in them. And if you know anything about disk I.O., then like you know that, for example, normal hard disk, like you can't really handle that.

Like each axis costs already like on the order of 10 or more milliseconds. So like that is a very long time to wait. And that is why right now, Ethereum nodes basically need SSDs. There's no way around that. So it is a problem right now. It is also a much bigger problem is that you can do a dose attack against this and blow the state up relatively cheaply to an even much larger size. And so like a lot of our gas costs have to be structured around this, making this so expensive. that it won't happen.

So basically the goal for statelessness is to kind of go to a version of Ethereum that doesn't have this humongous state, right? So how would that look like? Yes. So to be clear, the state will still be implicit. And some people, and this is something to be discussed further, some people will still store that full state. the question of statelessness around who needs to store that state.

And so one thing that you can do basically with statelessness is to structure everything so that you can validate a block without needing the state. Like if I just send you that one block in isolation without anything else, you can just from that information decide whether it is a valid Ethereum block or not. You do not need any other context than that. That is what statelessness does. So how does this work technically? Wouldn't I have to have like some sort of representation of the entire state for that to actually work?

So it works because we have cryptographic techniques that allow us to commit to states in very succinct forms. And like basically everyone knows about these, they're called mercilaries as for you. example, one of these. So basically it gives us this just 32-byte, what we call state route, that is a commitment to the state in the sense that you cannot find any other state that would allow you to compute this commitment. And what statelessness does is it gives you all the data that has been read by the transaction, including so-called witnesses. And the witness is a prove that this is the correct data given the state route. And you have the state route, like you know that because it's only very short, so you can just

have that. So that's the only thing you need to store as the current state. And the witness tells you, yes, this is the correct data given that state route. Okay, I see. You said earlier that some people or some validators still have to have the entire state. Why is that? Well, I mean, this is a design choice. And there are different potential designs here, but the design that we are aiming for now

is what we call weak statelessness. And weak statelessness means that you do need the state in order to produce blocks, but you don't need it in order to validate blocks. And that is a very good trade-off in our opinion, because it's okay to limit somewhat more the number of people who are able to produce blocks and that is in practice unfortunately in some ways going to happen anyway because of the whole MEV thing but as long as you have the ability to very easily verify it by everyone that is okay that has that has some very nice implication in terms of the design space like it means that as a user for example you don't

like if you don't have this weak statelessness, if you want like strong statelessness in quotation marks, then what you would need is that every user always keeps the witnesses for their accounts around. And I don't think that is a very practical design. I think like from the UX point of view, the weak stateless statelessness is really like a sweet spot that is a very like kind of nice spot to live in. Okay. So this would then not reduce the size of the. state, but basically it would reduce the number of people we acquire to actually keep that state.

That's right. Another idea that's been thrown around is state rent, right? So basically, so you don't actually pay to store some sort of data on the blockchain once when you send it in your transaction, but you actually pay continuously until you need it no longer stored or your money runs out and it gets deleted automatically. Where's that at? Do you think that's going to happen? Do these ideas work together or is there something else entirely?

We had these discussions around state rent. And in a way, so statelessness alleviates this problem a lot. Because suddenly instead of like, I mean, we want a very large number of full notes, right? In the ideal world, everyone who works in any way with these things. and blockchain would run their own full node. For several reasons, that's not really completely realistic now, but this is the future that we are working towards that in some notion that this is possible. And therefore, like statelessness really, like, reduces this problem of, like, having the state a lot.

Because from, like, tens or hundreds of thousands of parties or millions who need to have the state around all the time on their own SSD, you suddenly reduce it to like, say, hundreds of parties who are actually producing blocks on ECRO, who have very large incentives anyway to keep the state around. I mean, yeah, they will need it to produce the blocks. So it alleviates this problem a lot. It is a debate, I would say, whether with that state rent is still necessary. I would say if it comes, it will come in a slightly different form from what people consider state rent now. So it won't really be a notion of you continuously pay in order to have your state alive.

It's more that your state will be, will after some period, say one year, if you didn't do anything with it, it will become part of a kind of old state where it can be re-eastern. activated at any time for like maybe paying slightly more gas. It's not you you you can't work with it anymore. So basically there's there's no continuous payment. There's just like probably this is at least the most likely version of state rent that I see would be that if you don't use your state for a very long time, you will pay slightly more because you have to pay for a slightly larger witness.

Okay. So I see how the size of the Ethereum state is a problem for some users and that it requires SSDs and so on. But in some sense, an even larger problem with Ethereum is the fact that the EVM doesn't allow for parallelization of computation, right? So basically you have to do everything in a certain order and always look at the entire state, where some other blockchains have taken a more advanced approach. I mean, they were also related to the party. So basically for them, it was easy to see what the problems are. So I'm not taking sides here.

But how do you feel about this inherent inability of the EVM to allow for parallelization? Yeah, I mean, I think that's a good point. and that that that's very interesting. I honestly, I'm not only VM engineer, so I cannot say in detail if it's impossible to change this. I think like one large part of that is actually related in some way to statelessness in that one thing you would need in order to parallelize things is to know what state each transaction access is.

And in a way, we are starting to do that. Now, I don't want to say we have a complete way to parallelize things. But, yeah, I mean, I can see that that is definitely like a very, very important part and that would allow for a certain amount of scaling if you paralyze things. And I would say, like, it's certainly a very good decision to design around that. And I would encourage people who design roll-ups to do exactly that, to think about that as well. and maximize the parallelism they can get out in order to be faster. Well, let's zoom out a little bit and talk a bit about, you know, Ethereum and where this project is going.

Like, what makes you excited and what do you think is the impact that Ethereum will have on the world? Wow, I think like that is, it's still, I mean, it's very, very hard in our time to make predictions about things further than five to ten years out, I would say, because there's just too many things that are on exponential trajectories. I'll settle for five to ten years out. I think Ethereum can provide many, many different things for different users. It's essentially this coordination layer that allows you to make certain parts. of course it doesn't replace a community in any way, right?

Like it's only a technical layer, but it allows you to solve some of the problems of getting communities aligned on certain goals and turning things into positive some games. I think that is the amazing thing that this technology allows. And we have seen that around the resurgence now after I guess the initial shock of Daos, like where many, many people have started creating DAWS,

and they seem to work in some ways, at least for now, which is great. This is amazing. Communities have found together and have found a way to coordinate around certain goals without having to go through the traditional way of doing this via a cooperation, for example, which would have been the old way, which has, like, other costs associated with it, essentially. You said that it turns things into positive some games. So let me ask you for the metric. So basically, what's the metric that you think is going to improve for the average Joe using blockchain technology?

I mean, the average Joe right now doesn't use blockchain technology, right? Basically, nobody does that. And I think the question can be on many, many different levels. And I think we're already seeing it, surprisingly. Like, it essentially, it changes the game of finance at the moment, mainly, because financial applications are what comes first, just because they just have just have, the most money, the most willingness to pay. But this permissionless ecosystem that allows anyone to just go there

and create something and deploy it without having to ask anyone for permission, allows people to just play with it a lot. And I think we are right now, we are already seeing the effect of that in terms of all the fintechs. I mean, my online banking apps have improved, like tons. over the last years. And I think this is obviously not based on blockchain technology, but it's based on the pressure that these companies now see

where the competition will come from. Like, you don't have to be a blockchain user in order to see the improvement. It will come to you anyway, because the others have to keep up. Otherwise, we're coming for them. So you mentioned finance as this kind of first area that's getting a lot of traction. And then you also talked about how, you know, on a high level, you see Ethereum or blockchains as this like coordination layer that allows, you know, allows

people to accomplish things more efficiently together. To what extent do you also think that blockchains will kind of financialize a lot of things around coordination that are today don't rely on financial incentives directly? Well, this is a difficult question. I'm not, I'm not sure what you mean. Like, do you mean your local sports club is? going to become a DAO and suddenly everyone has a token or something. I'm not sure what that question refers to.

Well, I guess that sort of ties into like, I think Gnosis, especially has done like some work around ideas like this too, right? Where you use like prediction markets to have, make decisions as organizations. I think, I mean, I can see this fear, but I think like mainly it provides new options. I don't, I don't think nobody is going to force you to use. a financialized prediction market. It is still like, it is still your choice. So I don't see why it would become like a forcing function for average people to just

financialize everything. You can, but this is your choice. And I think like many, many, blockchains will provide things that are not financial in nature. Like systems can be built on top of them. Who says we can't now already, for example, build a Twitter? Twitter, a decentralized Twitter, for example. I think that would absolutely be possible. People are already building decentralized messaging apps.

That doesn't have to be financialized. So I don't see that automatically everything has to be financialized. So you think the fact that open finance has moved in first is just because of ideological proximity or, you know, being tech adjacent. And the more social apps are going to come at a later point in time, but they'll come. I think right now, I think it's just that the more social, for example, apps, as you call them, are just priced out of it. And that is a natural consequence of finance just always, like, being there and being just a very valuable application. Like, let's be honest about it, finance is a very valuable application.

but it means that it prices out a lot of things, which is kind of a shame from the development perspective because obviously we are losing kind of important time where these other systems could bootstrap themselves and could start providing valuable things. But I mean we are now building the rails that will allow this in my opinion. I think like when we have sharding, when we have this,

people will build all these other systems on them and they will come, I think. And I think I'll end on a divisive question here. Do you think the applications that will need less economic security because they will not be securing the values that financial applications inherently do will actually need Ethereum as a base layer? I mean, could they run on any number of other protocols that don't have the economic

guarantees that Ethereum currency has? I think there are different questions here. I mean, I would say probably, yes, if you expect that the decentralized Twitter will just put its data on the charts, I don't expect that that will be the case. I think what it will do, what many applications might do is use some blockchain and maybe Ethereum because it is the settlement layer, but who knows whether that is necessarily the case in the future. and we'll use this. For example, any of these applications, right now, let's talk about tour, for example, which is concrete, decentralized applications that's out there now.

But it has huge problems getting people to actually run nodes, right? We do need some sort of payment for this. We do need some way of getting people to, like, run the infrastructure and so on. And I think that is more important. Like that is where blockchains like Ethereum come in. Probably not for the data itself. You don't need. But it could be for some sort of commitment to the data.

That makes a lot of sense, but not for the data itself, I would predict in the long run. But the economic incentive there, surely the economic securities that should require, depend on how large the incentives are, right? So basically if the incentives are minuscule compared to the security that Ethereum affords you, then using Ethereum as a base, there may be overkill, right? I expect that Ethereum with roll-ups and charts will be quite cheap. So I do not think that you expect to pay. Well, I would say it's in the cent or sub-send range,

what you would expect for normal transactions in that future in Ethereum. I think a lot of applications will be able to pay that. I think this is actually a super nice closing statement. So sub-send transaction fees. You heard it here first. Dancrat, thank you so much for coming on. It was pretty technical, but I think there was a lot there. So if people want to dig into this somewhat,

where can they go and find more information on these topics? This depends obviously on the technical level that they want. to get into. There are a lot of people trying to write blog posts about these things. I can certainly collect some resources and we can add them to the description of the podcast. Honestly, we could do better in that respect. I don't think we're like we're and I would encourage if anyone's to come forward and is good at digesting the information writing it up. We need more of that. It's way too little in the whole space and I know many people have trouble catching up. If you really want to get into the tech, then I think

research, the forum is an amazing, like, a resource that has a lot of stuff. And it's usually not super difficult to understand. People try to make it somewhat understandable. But the main problem is just a huge amount of information to digest that most people probably can't completely catch up with. Okay, we'll link to these. Thank you for joining us on this week's episode. We release new episodes every week. You can find and subscribe to the show on iTunes, Spotify, YouTube, SoundCloud, or wherever you listen to podcasts.

And if you have a Google Home or Alexa device, you can tell it to listen to the latest episode of the Epicenter podcast. Go to epicenter.tv slash subscribe for a full list of places where you can watch and listen. And while you're there, be sure to sign up for the newsletter, so you get new episodes in your inbox as they're released. If you want to interact with us, guests, or other podcast listeners, you can follow us on Twitter. and please leave us a review on iTunes.

It helps people find the show, and we're always happy to read them. So thanks so much, and we look forward to being back next week.