# Sharding an EVM Chain: The Pitfalls Nobody Warns You About  - Aleksa Opacic | Nil Foundation

- Channel: [ETH Belgrade Community](https://streameth.org/eth-belgrade-community)
- Date: 2025-10-07
- Duration: 23:04
- Watch: https://streameth.org/watch/yt-rqBMwzpODEk
- YouTube: https://www.youtube.com/watch?v=rqBMwzpODEk

## Description

Sharding an EVM Chain: The Pitfalls Nobody Warns You About  - Aleksa Opacic | Nil Foundation

## Transcript

So, hey, thank you all for coming. I know it's the third day of the conference and that all of you are either tired or hung over. So, I'll try to make the next 20ish minutes as chill and as fun as they can be. So for those who don't know me and I see many familiar faces in in the crowd. So my name is Alexa and in the past couple of years I worked in various blockchain protocols. I started my career as a blockchain protocol engineer and slowly pivoted to more integration solution roles. And when I was preparing this presentation, so yeah, something that you need to know about me is that in the past year and a half, I worked uh well, I worked on a protocol which was sharded uh we try to shard an EVM and something that I wanted to do today. So basically to when oh let's start again. So when I started preparing this presentation, my initial idea was to use it to hype the project to tell you about all the architectural issues that we had as well as all the brilliant ways how we solve them. But then I realized that for this crowd something that may be a bit more useful is to go over all the hidden pitfalls that we faced that we didn't that we wasn't prepared on and that at the end kind of extended the the building and preparation and we had to do a many refactoring. So to shake things up a bit so now I'll make you to raise the hands. So to fill the crowd I want to know who is here an engineer. Can you guys raise the hands? Good. The next question is who here worked or is still working or want to work in a blockchain company? Come on. It's a blockchain. Nice. And the last question I have is who here heard about the sharding and EVM? And who here heard only about Ethereum 2.2? Put 2.0. Good. And who here thinks that can explain well what the sharded EVM is? I will try to find someone to do the slide for me. So basically to understand what is a sharding I think the simplest way is to first understand what is one execution environment. So almost every blockchain especially the EVM ones they have couple of key same components. So every blockchain has an RPC. This is basically something that we expose to the users and users use these RPCs to query and send transactions. We need to have a TX poolool. This is where transaction goes. We need to have a VM. It can be many different types of the VMs. And we the VMs are taking these transaction and executing. And at the end we have a state and state is the place where we keep the accounts as well. We keep all the changes that happened. So to explain what is the sharding it's nothing more than just m like having multiple of these environments. So as you can see in the picture now we don't have one execution environment we have multiple them running in a parallel and each one of these environments all of them they have a TX poolool they have again the VM and they have a separate state and something that you need to know about the shardy chains is that they also need to have a way to communicate one with each other. Basically this is something that we call a crossshard communication protocol and if you want to think of it it's really bridgeless bridges. So in current road in current ecosystem of the ethereum you have more multiple rollups they all communicate with the bridges. And in the sharded system you don't need them because they can send the messages around. And now if we go a step further and we go finally to what is the sharded EVM chain, it's nothing more than having multiple of these instances of executions. And each one of those are running the Ethereum virtual machine. And this means for any DAB developer that you can take the existing dabs that you already have, you can deploy them to any one of these shards and it will work. But you can go a step further and you can take your deps split into multiple services similar to what we have in web two microservices put these contracts around multiple shards and then basically have the parallel execution and the good example for this something that we used a lot on many different conferences is basically the unis swap. In unis swap we have a different pools and these pools are trading pools between the two players to two tokens and if you check on a dune you can see that there are couple of these pools which are highly used you have many transactions changing like know transferring these tokens and if in this sharded architecture we can basically take these pools and spread them across multiple shards and by doing that if I'm using one shard someone if I'm using one shard and one pool on this shard someone else can without the issues just utilize the other one. So this kind of covers the idea of the sharding but it also opens a lot of the UX issues that we need to acknowledge. The one being that if we imagine that end user needs to use the RPCs to individually query each one of those the whole system would be semiscalable scalable but wouldn't be useful but how we can solve that is that we can introduce this main shard in the picture and this main shard can be nothing more than a router. So when me as a user when I want to deploy a contract I can specify on what shard I want to deploy it then the contract would be deployed on one of these shards. So this is the only time when I need to think about the shards. Then when we construct them the the contract address, I would basically just put the first two bytes to be the shard ID. And then when someone wants to interact with any contract on any shard, it just gives the address to this main shard. And the main shard knows how to routt everything around. And if we are talking about the benefits of the sharding, I would say the few of them are quite obvious. And the first being that we increase the true and this is something that in the past couple of years from when we decided to scale the Ethereum we started doing we first tried to do it with the side chains then upchains rollup optimistic roll-ups EQ roll-ups native roll-ups now even ultrasound roll-ups but basically here the the throughput is how much transactions your environment can handle and we have a parameter called TPS transactions per second which is how much transactions your VM can take from this pool and execute ute and here as we have more executions we can basically process much more transactions because we have more blocks built in the same time. The second little less obvious um benefit of the sharded system is that it resembles the current L2 ecosystem but without the liquidity fragmentation. What I mean by that is that when we scale the Ethereum using the roll-ups, we basically have a lot of these execution machines and these chains don't really natively talk with each other and we have tokens spread around everything. And here if we build the protocol where we can share this liquidity easily using this cross shard protocol, we basically solve the issue. But as I said, this presentation is not going to be about hyping the sharding. It is going to be talking about all the pitfalls that you may not see on the first you know site when you're explaining the the architecture and I want to start with something obvious and this is the ERC20. I think that everyone in this room knows what the ERC20 is and I want to take couple of seconds to see how the ERC20 would work on a sharded system. So just a small recap, DRC20 is nothing more than a standard of how we are defining the tokens in Ethereum. And this this standard basically is just creating the centralized registry. What I mean by centralized registry is that we have a single place where we keep the mapping of all users who are holding these tokens as well as how much tokens they use. And whenever I want to do something with my tokens, I need to send the message directly to this contract. And we have these me these these uh functions for example transfer, balance, approve, fetching the total supply and so on. And we also have a role of the admin and this is someone who created a token who can mint and burn. And all of this looks and works extremely well in Ethereum mostly because if I want to interact directly with the ERC20 token, I can send the transaction and execute something. But also in Ethereum the contracts can talk one to to each other. And how I can do that? I can do that by having the sync calls. What this basically means is that when I start executing the transaction without stopping the execution, I can call another contract. then call something else, call something else and at the end I have this chain of basically sync messages around and if I have a contract which is some D5 app and it needs to interact with the RC20 it doesn't need to stop the execution it can directly transfer and do everything needed. So if we now go back and start seeing what's happening when we add the sharding in the picture, the first problem that appears is that when the year we need to put the ERC20 contract somewhere and whenever we decide to put this ERC20 contracts, we also need to think about all other deps that are deployed on all other shards. In our case, we can have the shard one and three having great deps and the shard 2 having a really popular ERC20 token. And something that is going to happen in this case is that these smart contracts now if they want to interact with the ERC20 token they cannot now just synchronously send the messages they need to do these async calls and these asin calls are nothing more than these crossart calls are nothing more than asing calls which means that the transaction will be sent for example on a shard free it will go to the message pool it will execute something on the contract there and Then it is going to create a new transaction that needs to go to the message pool on the SH 2 and when the transaction comes to the message pool SH 2 then it executes something on ERC20. So now we created this as in hell that first we have a delay and the second and the bigger issue is that we are filling one me pool and in all the sharded systems something that you need to think about is that if you slow down one shard you're basically slowing down the whole network and did you really scale if we have these bottlenecks and also the other issue that may appear is that uh we we will start having the concentration of the deps on the shards with the popular things because everyone Everyone wants to use these sync calls. So one solution when we started designing the solution of this problem was saying why do we need EOAs? EAS are you know the past now the smart contracts and account abstraction is becoming sexy especially with the pack fork. So we said let's try to think can we remove the EA accounts and we found the obvious solution which was to basically just have the account abstraction natively. This means that with your account is not just an address. It's a smart contract. It has a bite code, some logic how to delegate this and pay for other execution. It also keeps the balance. But besides balance and the bite code, we can add another attribute which is basically how much money I hold. And the simplest analogy that I can use to explain you how all of this work is to imagine the cash. So every country is printing the money. The mant is money is printing in one contract. It can be your C20ish like with similar interface for minting and burning. But then once the tokens are minted and sent to someone else, the real accounts same as my real wallet is holding the money. And then when I need to pay a beer, I don't need to go again and ask the the the contract which holds and created the tokens to allow me to pay and to transfer. I can directly send from my uh from my wallet to someone else. And we did this and we talked on dev connect in Thailand about this. I got a round of applause about great way how we solved it. But something that nobody warned us and I said initially this presentation is going to be more about the pitfalls was how this affect everything else. And from my experience, the first thing that we started doing is starting talking with different partners. And we realized that people are used to your C20. And when they you tell them that they need to change the concept, they're really slow on moving. And also when we open the open zeppelin, we figured that there is like 30 something different extensions. Now, uh this change that we did introduced removed the EOA accounts, introduced account abstraction, changed the transaction type. Now we need to audit these extensions. Features for stable coins, for example, some stable coins requires you to have a way to block list specific addresses to maybe pause the transfers. All of these things now need to be thought through. And this requires a lot of effort both on the engineering side and something that I will start mentioning from now. It's money. Something that we need to be realistic about that when you're building these things, it costs a lot to on board and change the concept that people are used to. The second topic that I would like to cover is losing automicity. So basically in Ethereum something that we are all really used to and something that we basically created a whole DeFi ecosystem around is being able to send these sync calls from one to another contract. And something that we also introduced, it's similar like in Chernobyl, they had this a5 button is if you're not happy in any in any step of this chain of execution, you can just do the revert and everything just reverts and you go and basically you pay only for for execution. So this opened a lot of possibility for different type of attacks. We and not only attacks but also like flash loans, flash swaps and the whole DeFi is around all of that. And now with the sharding we completely broke that because as soon as you send the asyn call around you basically need the transaction is there you cannot easily revert it. And something that we learn here is that ah yeah this slide I forgot about it. So this this topic was really popular when ETH2 was around and there were many people saying that the sharding cannot work because it can kill DeFi. But then also Vitalik and others tried to defend it. It's a really good thread. So if someone is curious can the cure code and basically something that we learned is that Vitalik was right but he was right in the sense that if we want to have a sharding we need to change how people are thinking. This means that we need to completely change how the DI currently works and adapt it to work differently. And this requires us hiring the teams. And the last topic, and I'll try to be quick as I'm getting warnings that I'm over the time, is that when you're building a new protocol, especially the custom protocols, we are all thinking about the protocol itself. But people often forget about everything else that needs to be built around of it. And whenever you're starting from scratch, especially something custom, there are four ways of how you can introduce the deps to your system. The one is you find the blue chip deps. You pay them a lot. You get the users from them if they want to come. But the issue is that you need to adapt to them that they're not willing to change a lot of the code and spend engineering efforts. The second one is you can find the smaller teams who are willing to do these changes but they're not bringing any users and you still need to pay. The third one is you need to pay someone to build something custom which can be really good if they create these new protocols and new values but usually it's really hard to find these teams and the fourth one is the favorite of my friend Milos is to build everything from scratch and if you go with this in ideal world that will be kind of the the pick that I would go but as we are not living in ideal world and we don't have infinite resources usually that one is the worst and the last pitfall that I have on this topic is that People often forget and this is advice for me as someone who works in integration team is that besides the deps that we want to build we also need to have all the services they need to to to well we need they need to exist for them to deploy on us and the list of these services is really big I will not go over all of them but you have the same thing as we have with the deps you either need to find someone who who can deploy and change or you need to pay someone or you need to do it yourself And at the end all of this costs a lot of money. So the closing thought. So I know this presentation was kind of anti-sharding and this was not the purpose. So my idea was to use this time to basically show you that whenever that this industry is driven by engineers and we as engineers we really love to build the complex problems to solve you know the complex issues but at the end of the day every decision that we make is it a BD decision is it engineering decision is it a product decision and however small the decision is at the end it can completely affect the product and change our road maps and how we build and and do that's it. I hope it was fun and I hope you guys like the talk. So, is there any questions? [Music] >> Hey, thank you for presentation. Can you return to the slide with like new architecture of your C20? So basically the main idea that the charts will make a single transactions yes to the like different chart but how it will how it will help like to lower down the uh load to the main charts where where like for example your C20 contract or smart contract is being deployed on. It is like there's like we we we are we will have like the same problem as you mentioned before that some sharks will be overloaded some of them not. So the point that I wanted to make is that when you have a standard ERC20, this ERC20 is basically keeping this mapping. And this means that if I want to do anything with my token in this ERC20, I need to send the message directly to the contract. In the new design that we proposed, you still have this currency contract and we didn't name it TRC20. And the only responsibility of this uh this contract is to mint, burn and track total supply. This basically means that you don't have the load that every time when I want to interact with this token, I need to send the message. And the reason for it is that if I have a tokens on my wallet on my smart account, I can without referencing send this tokens to someone else. And basically this is solving the throughput of having everything on on a single place. >> Am I correct that like this smart contract uh and like your C20 contract they will be like merged into one. So I like have my smart contract and it will already have all the balances I have. >> Yes. So this is the change needed to be done on account level. So in Ethereum any account which is smart contract it has basically two attributes. The one is the bite code and the balance. But in the protocol we can add additional attribute which is tokens which keeps tracks of all the tokens basically these addresses which minted the token and how much I have. And if we again go further and change how we are sending the transactions also in transaction besides sending the value we can also have a field tokens that when I'm interacting with you I can directly send you the tokens from my account. >> Thank you. Thanks. Any more questions, guys? >> Running. Hi, thank you for the presentation. So uh in the new uh design uh since you have a array of tokens is there a possibility that you can send uh from the same address and receive to the same address different tokens. >> Uh I I'm not sure I understand the question but yeah. >> Yeah. So uh can you get to the slides? >> Can I change >> the previous >> this one? >> Okay. Yeah. So um in this model uh you have different array uh array of tokens, right? So do you have a possibility to send from the same address to the same address uh different token? >> So you don't like if we are talking about your account which is now basically a smart account. It's smart contract. It keeps track of all the tokens and everything that we have here. This is yours. And when you want to interact and send them around, you just need to specify. For example, in transaction object, I would say I'm sending to someone else. I put the address of other smart account. And in the tokens field, I would specify the address of the tokens I want to send. And basically, how much tokens I want to send. It's the same way of how we are sending in EUA. If we are talking about EUA, EUA is just the address and the balance. And when you're sending from one account to another, you're saying I'm sending from this address this much value. Imagine that you're doing the same thing just you're not setting the value, you're setting the tokens, the address and how much you want to send. >> Okay. Thank you. >> Yeah, we we can discuss more after the Yeah, >> great great discussion. Any more questions? One, two. Cool. Thank you all. Thank you, Alexa.