Not All State Is Equal

Transcript

Next, we'd like to invite our next speaker, Mr. Way. The floor is yours. [Music] All right. Um so I believe most of you would have heard of something called the parallel principle. The 80% 20% rule. Basically states that 80% of the outputs come from 20% of the inputs. So for example um a company's revenue 80% of it comes from 20% of its customer. And perhaps another example that's perhaps closer to you is like 80% of your

personal productivity comes from 20% of your effort. And magically this also applies to Ethereum. So we found out that 80% of Ethereum state hasn't been touched in a year. Meaning 20% of the current Ethereum state is considered active. So think about it. When was the last time that you transacted or when was the last time that you transacted all of on all of your accounts? And it kind of makes sense um based on this statistics because um think about it. The first time that you entered the Ethereum space, right? You probably wander around, you know, play around with some wallet on your desktop and, you know, you transfer some funds, play around with some smart contracts. And the more that you understand about this

space, the more that you figure out that, hm, I have better wallets that I can use. I have better alternatives that I can use. So, what you do is that you transfer all of your funds, your USDT, USDC, your ES, whatever, your NFTs to another um account. And what happens to your first account? You just abandon it. But even if you abandon it, the account still alive on chain but it's considered garbage. Right? So um when we figure this out, we want to take a datadriven approach on core protocol development or in particularly we want to understand more about the current state of um access patterns. How people um how does um access patterns work on uh in terms of like Ethereum state. So we actually

found out a few interesting discoveries and we also had a few ideas on how to improve L1 scaling and um improve the user experience on Ethereum based on the discoveries that we have. But before that let us um rewind a little bit and understand what exactly is a state. So when we refer to state on Ethereum we are usually referring to accounts. So accounts in Ethereum um has two types. One is externally owned accounts EOAS and another one is contract accounts. So for each contract account they will also have its own storage slots. So each slot is 32 bytes. Whatever you want to put um in the 32 bytes up to you. It's up to the app developers. And another one is also on the bite code. So every account would also have um its own bite code,

right? Which is basically your contract code, right? So one key thing here is that the number of accounts and the number of storage slots can grow infinitely. And it's actually not infinite. I mean the actual number is two to power 256 which is a very large number if you try to Google it. So um yeah that's why I say it's called infinitely um and so that's that applies to both accounts and storage slots. When you have this kind of scenario you will lead to something what we call as the problem of state growth. So currently as of right now um on Ethereum mainet we have about 300 million accounts um probably more than that already and we have about more than 1.3 billion storage slots. When you run a execution client

for example go ethereum or never mind this numbers would probably translate to about 110 or to 120 gigabytes only in terms of like account and storage slots. If you were to consider try Merkel parisha try data stored in execution clients that number will probably go up to about 300 to 400 gigabytes. And the problem here is that the numbers will only keep growing right when we scale L1 when we increase the gas limit where we increase the throughput that means that the state will grow right and it will grow faster than than ever. So um what why do we care about state growth?

Number one is the storage space. This is pretty obvious. So if you have need to have to store more state, you need to upgrade your hardware. That means you have to change your SSD every five years or every 10 years or whatever. So changing your SSD every five years or 10 years is not that bad because hardware will degrade anyways. But the another problem that is more important to solve in my opinion is performance because as the state grows the underlying structure cryptographic structure behind the state behind the accounts and behind the storage slots is mer. And to represent a merit trial or MPT in internally internally in execution clients they will have to store all of the nodes in the database. So as the state grows as the MPT size grows it means that the try

depth the try levels the number of levels in the try grows from for example five to seven or even to 10. Um so when that happens you will affect the performance of the execution clients. So that will also means that as the chain progresses assuming that you don't change your hardware um your performance of the execution client would be will get will be worsened right so that's another problem and I think the another um the third problem that I can see here is syncing right not right now let's say you want to sync a node um it'll take one day um on go ethereum or never mind or other execution client but what if um what if the state grows larger and larger then you will take more than one day maybe two days or depending on a

hardware I don't know one week two weeks or whatever. So this is the um general overview of state growth and um when when we want to tackle this problem we have a few angles and one of the angles that we want to take is on the side of data. So we want to analyze the state and the first question that we ask is ourselves is is all state equal and from the title of this talk you already know that it's not equal and let's look at a few discoveries. So the first question that um we wanted to know wanted to answer is EOAS versus contracts which one lasts longer right.

So um from from this graph right on the left side um bottom left corner I mean on the x-axxis is all the um activity span basically you have single block um less than one year one to two years two to three years so one and so forth I'll explain more about that later but first the first observation that we found is eas last longer than contracts right so this is a pretty interesting one and it kind of also makes sense because most of the users right now um they will have to transact using EOS not smart wallets or account attraction wallet yet. So naturally um I mean you will transfer um eaves or you would interact with contracts. So typically US will have more activity compared to contracts. But

here's the interesting thing right 55% of the total contracts operated for a single block. What does that mean? It means that um let's say you deploy a contract you execute it you call or whatever you play around with the contract. 55% of the total contracts only operate in a single block. Meaning you they only deploy and they only do whatever execution only in a single block and we have never seen any activities from them from um apart from that single block. Now this is um pretty stunning at least for me um when I when I first discover it. And the second thing is that most accounts operate for less than a year. Um so we have to

investigate why is that the case but there could be a few speculations so the first example is that uh for example if you're a user you first um you first have own a UA account then uh you realize that hm I want to transfer to uh centralized exchange then you transfer to centralized exchange and you know uh you start to transact there and not on your own chain EOA um another thing could be like for contracts um some teams some applications especially those who are successful um sometimes they want to upgrade their smart contract. Um so what they will do is that they can you cannot modify existing smart contracts. So you have some sort of like a proxy pattern like diamond standard uh where you can actually change or so-called upgrade your implementation

contract. So there are a lot of um reasonings that we have to find out and um the other ones could be like spams you know mess boards or whatever. So the next question that we wanted to answer is how unique are the contracts? We have about 50 million contracts contract accounts right now. But it doesn't mean that we have 50 million applications. In fact, one contract does not equal to one application because um in fact contracts reuse existing code implementation. So it's split into two categories. We have something called template bite code which is basically code that is being deployed by more than one contract. And we have something called uh what what we categorize as unique bite code which is

bite code deployed by exactly one contract. So first thing majority of the bosses are unique. We have 50 million contracts but yet we only have one point around 1.6 million unique code implementation. Right? So that's number one. And um number two is that template in terms of the template bite codes it only makes up um 9% about 9% of the total um total bite codes that we have. So but yet um most contracts are deployed using templates. So remember the number just now 9% we only have 9% of um template contracts um which is about 150k but this 150k code implementations are being

reuse by se 97% of the total contracts on the team right now meaning most of the contracts on the team right now just reuse existing code implementation so again there are a few speculations we have to um still still continue to investigate but a few that came into my uh obviously is spam tokens. People just deploy tokens to spam or to fish or you know to scam people whatever. Uh another one that I I think I'm speculating is also on me site. So um maybe reuse strategies or whatever. Yeah. But this is uh something that is worth to um find out. And the next one further solidifies that um why I think most of these are

spams or scams uh is that when we look at the activity span in terms of the median um level the template contracts um I mean the unique contracts operate two times longer than the templates right so it kind of further solidifies that the template contracts contracts that are deployed from existing code implementation they are mostly scam um spams or scams yeah right Next thing um similar to the accounts we want also wanted to know how actively used are the storage slots and the first immediate observation that we have is 63% of the slots only operate for a single block.

So it's the same thing right it means that somebody has written um storage slot and or read or read from read that storage slot only in a single block right it could be offchain um rep or offchain yeah offchain rep but we don't know we only know about onchain but 62% only operate on in a for a single block and most of them perhaps more than 80 80% of them operate only for under a year right so to conclude I mean this the the findings most accounts last for less than one year most storage slots less than last for less than one year and most contracts we use the same bite code. So when we have this findings how can we utilize this information to come

up with some solutions or ideas to improve the Ethereum protocol. So there are a few ideas. The first idea is stay expiry. So this has been in ongoing research and development for a long time. So um it started in almost like 10 years ago. So the core idea of stay expire is simple is to expire now and revive later. We know that there are a bunch of garbage state on Ethereum right now. So we want to remove all of this. But let's say if users want to revive it or want to restore it, they can submit a transaction with the proof and yeah the the state is back on chain. So by doing this we can um stop or even slow down state growth. Yeah. So we did a very simple analysis. Um we so we compared um

for full state versus one year state on um one of the execution clients go Ethereum and we we managed to see like um like that particular execution client um or GF Gaff node which only stores like one year worth of state it managed to save like 80% of the storage space in terms of state. Um so that will also help with performance. Next, um we also have another idea of introducing something called temporary storage model where it's basically the same as the permanent storage model that we have except that um every six months or every one year let's say um it will be automatically emptied out. So uh what happens is that why why would contract developers want to use this use this?

Well, if you are fine with your state data being deleted after six months or after one year then you can use this. Why do you want to use this? because uh most likely the op code of storing this um the state in the in this temporary storage will be cheaper, right? So maybe that's one good incentive. And then the next thing that I want to do is also to make contract deployment cheaper. So when you deploy a contract um there's bunch of things that you need to need to calculate when it comes to the calculating the gas cost of contract deployment and one of it is code deposit cost which is 200 times code size in terms of bytes. So again from our analysis most contracts you reuse the same bite codes and bite codes are dduplicated in EL clients meaning when you have two contracts which shares the

same code implementation when you actually store it in E clients E clients wouldn't store duplicates of them you actually store a single unique implementation of the of the bite code so why is it that users when they deploy contract they have to pay this code deposit cost as well we can actually make them cheaper So there are a few solutions that we can have. Um the first variant is what I call a sim block duplicate discount where in a block let's say if a bite code appears more than once then the first one would um pay the full gas cost of um contract deployment I mean code deposit cost and the subsequent ones doesn't have to pay the code deposit cost. Um one immediate disadvantage is that um it's unfair for the first one

and since it's unfair then it becomes like a ordering game where people fight not to become the first one and the second one is what I call as um global code hash registry. So you basically introduce a system contract storing all of the code hashes that ever exists. So all contract deployments first check if um the the bite code exists. If it exists then you don't have to pay the code deposit cost. If it doesn't exist then you have to pay it. So um pretty straightforward and so we basically have like some of the findings that we have um most accounts last for less than one year story slots as well and most contracts reuse the same bite code and from that um kind of like a datadriven approach we managed to come up with a few ideas and this is actually not all we'll be publishing u an article on if

research um later on on all of the findings that we have this is just like uh perhaps like 50% of of what we actually found. So um but the point here is that um when we this is only the t tip of the iceberg. We don't fully understand um everything about state access patterns on ethium right now. So um so if we can understand more we can come up with better solutions that can actually help to scale our one and also to improve user experience on Ethereum. So ultimately um this is my belief. I believe that not all state is equal and I also believe that our protocol shouldn't treat them as if it were and by doing so um I believe that um we can make Ethereum cheaper, faster and more

sustainable. So thank you