 The titles are doozy, it's very long, but what we're going to be talking about essentially is scaling and There's some lag, but basically there's two kinds of scaling vertical scaling, which is when you have a huge Machine and horizontal scaling when you spread the load between multiple machines So yeah scaling so basically I mean I can wing it without the slides by the time they come by so In this talk, well goals great. I want to conceptualize You know vertical and horizontal scaling I want to show you a cool new idea for a sharding scheme which has Atomic cross-shard transactions and we're going to explain exactly what that means and But more importantly what I want to do is demonstrate some research process or like hey, can we do this? There's a problem. There's a solution. Maybe it's at the dam that we need to go in our direction So can I restore the process and Generally what I want is to foster interest in this kind of research And I want I want people to collaborate with and and to work with me and with us optimism on this stuff because this is the kind of stuff We care about this is not something that's really on the roadmap It's a complete side quest and so like I said, this is a nerd snipe Like this is supposed to be brain candy super interesting stuff, but if you want to work on it, you should talk to me So like I said vertical scaling big machines horizontal scaling many machines spread the road and In terms of ethereum vertical scaling has been done by roll-ups right rope enable vertical scaling Because if you're valid here, you can validate the roll-up by validating the interim main chain There's only one extra assumption is that there is one honest L2 validators That can also supply data for the roll-up But the question is okay We can scale vertically and we can probably scale ethereum 10 times Maybe 100 times if we start pushing some buttons like scale database and things like that. What if we need extra scalability? And and there's multiple reasons we might want that so one is that Sure, we could like require a data center for L2 sequencers, but we want to have a healthy Validator network and not everybody can get a data center not even not even every company or every DAO So we might want to spread the road so that you can validate a subset really of the chain Our thing is that we might want many different roll-ups This might be roll-ups with different security assumptions and different parameters like different fee different pay tokens in a different Pay fees the different token increase the trial put change the value rules Maybe use a different VM all that stuff You might want to do but you might still want to have multiple roll-ups talking to one another Okay, so there's two main approaches to horizontal scalability one is prioritization and that approach You're gonna have a big blockchain lots of states and you can spread the road between machines Two options to do that Optimistic you just try to do things in parallel And you hope they don't touch the same state if they do you just throw away one of them and you start again if you do this the pitfall is that you can increase the throughput because Basically can't charge more for transactions are not parallelizable That's because you don't have a clear criteria of what is parallelizable and what is not Our option is to use what strict access list Some fancy people call this UTXO, but I think strict access list is clear and so basically That's shipping every transaction with a list of either all the contract date touches So you can have a lock on the contract or all the storage slots that touches so you can lock these specific storage slots the prioritization approach still assume that you have one entity that Validates everything Just now it's spreading things across cores and across machines So it's still a high cost and validators if you want to Reduce the load and validators you may want to do sharding and then values can value a single short So a short is basically a small sub blockchain The only thing with that that apps now need to think about On which short they want to deploy which might not be great But the great thing is that we can do it Eterogeneous roll-ups so like I said you can customize roll-ups to have different VMs different fee models and things like that And they can all talk to each other The problem with shortings that if there is no way for Shards to talk to one another in a way that is effective. This is a bad solution So I'll explain what you know an effective way means but as you guessed it from title. This is about atomic composability So this is an example I will use for a cross-shard transaction It's a transaction that swaps Bitcoin for either on chart a then bridges the ether to a short B And I'm sure be will buy an FT for either So this specifies a single transaction that you send either to a system or to short a depending on your architecture So one very desirable property is atomicity If any part of this reverts everything reverts and in this case in particular if you come by your NFT for either Then you also don't want to swap your Bitcoin for either Sometimes you can achieve this via application level atomicity but in this case it doesn't work because Sure, if you you know if you can't buy Your NFT for either you could swap back your either for Bitcoin But now you've paid to swap fees and you've been exposed to Bitcoin either volatility But there are sometimes cases where you can revert the action on chart a and if you can do that then you can do Okay, I Was standing in the wrong area so Yes, so in some case you can do application level atomicity if you can roll back the thing on chart a So what do we have today today? We don't have atomic composability, but between pretty much any pair of chains you can do Eventual delivery of messages. Okay, so imagine you have a chain a that chain be you can use systems like layer zero I think wormhole does this now mat to exchange messages between chains and What you you have is that the guarantee that if you do the action on chain a eventually you'll do the action on chain B Action on chain B can fail and there's nothing you can do about reversing the action on chain a That's what we have today. I just implemented ideally with lack lands and ZK proofs, but maybe you'll suck with all the multi-sig that happens so Getting to the fractal port of the talk we can do a little bit bearish roll-ups and especially with ZK roll-ups We can at least ensure a bound on this, right? This was eventual delivery could mean if I go back to a previous slide Could mean many blocks Sorry Didn't mean to do that. You could go back like many blocks in the future. Go forward my blocks What you could do is say well, we're gonna do this on the next block. Okay one scheme to do this use ZK roll-ups and so basically you have this architecture where You have a parent roll-up here ZK roll-up one and as child drops you keep up 11 and 12 and basically it's a fractal structure because the roll-up one rolls up to the layer one but the layer 11 and 12 they roll up to the to the roll-up one and If you assume that there is a ZK proof posted every single block then now what you can do is do Instant delivery transaction between Say this one 11 and one so for instance you could do your swap here and then buy your NFT here It's still not atomic because you can't reverse but now at least you know it's gonna be done like in the next block or one block apart That's good, but that's still not what we want So what about crush our atomicity? So I'm gonna propose a solution for this And then we're gonna assume that we're slicing our system into one blockchain block Which is gonna comprise one block for every chart so every chart advanced at the same rate and We want to have some form of atomic crush our transactions to enable this shard need to be able to send messages to other shards So let's just take the most nice possible idea which is eager interchart blocking So you just process all your transaction at some point you hit on to a transaction I want to send a message to our shard you just literally call that shard you wait for the answer and then you continue so This is Less crazy than it sounds and it's somewhat equivalent to what strict access list do because I do in the worst case You have the same throughput as a synchronous blockchain in theory But you can charge fees because you know exactly which transactions are crossing the shards The great thing is you don't need to specify the access list But the really really bad thing in practice not in theory is that you're assuming that all these shards are being validated by different Entities and so the latency to for one chart to talk to one other is really high And so in reality, there's not feasible because the latency will just kill any throughput that you might have Let's try to instead reduce the number of exchanges between shards Let's try to bound this very tightly And so the idea would be to divide the the block time into multiple slots in the first slot Every shard executes its own transactions and also collects messages to send to other shards In the second slot All the shards exchange the messages and then they run the messages that they receive Optionally, you can keep this going so you can have many many slots. You could say well messages can send our messages Etc etc. I think in practice, you don't really need this You can have a lot of expressivity with just like one hop just one short talking to one another short So this is still bounded message delivery though. You can't revert You can't revert part a if port B fails and that's because other Transaction rely on the result of the a part. Okay, so this is very unclear. So there's a graphic here So say I'm chain a I'm doing my local transactions I'm doing the a part of a cross-sharp transaction and let's say that's you know, that's a swap So both of these will be swapping and then on B. They will be buying an FT So this transaction here the a part depends on a part of the first one because the first one swapped Save it coin for either so it moved the price. So this one will use the price from from that was moved here So there is a dependency link and Because of this dependency link, you can just revert You can just revert this transaction if this one fails because this one uses the result so this is the problem that we're dealing with and The general property is that atomicity requires synchronicity basically Local transaction can still be processed separately, but we would like all the crushing transactions to be Executed as though it was a single person executing them right So we have a problem which is we don't want Chart to talk to each other too much so you shouldn't do that is to create a special shard I'm going to call it the atomic shard That will execute all the cross-sharp transactions And we have a second problem is that To execute all the cross-sharp transaction you need to state from all the shards, right? And this is this removes one of the big point of sharding which is that you can separate this the state between all the shards so The solution to that is to make the execution in the atomic shard stateless And that means you will supply all the state that's being accessed by the the transactions for that make sure So this sounds too good. So where's the poop? The poop is that you need to simulate transactions on on each shard in the early so In general in EVM given that you're not sure the state. It's impossible to collect all the storage slots accessed by a transaction You can approximate and the easiest way to approximate is just to run a Transaction against the current state and just assume that the transaction before it will not revert So, you know here It's easy. You just run the state of the first transaction against the state after all the local transactions for this one You just assume this wall this one will revert and execute and simulate But maybe it will revert. So maybe your simulation will be incorrect Our thing you can do is anything so you just Tell the shard well This transaction is gonna touch this slot or you can give him some logic to find all the slots are being touched And there's many ways to do this that can be explored it could just be some EVM code that just touches the slots It could be some kind of in protocol information or even out of protocol information That is not being validated, but that's being sent to the to the sequencers So I want to make things a little bit more clear. So here's a cross-shard transaction very abstract It computes things be on some state and the state might change, right? We're not exactly sure what is Then it's gonna send a message to short be and this message is gonna depend on the result of the computation That's message will have a result We're gonna compute something based on that result and we're also gonna send the results to start see and then do some more Computation, so this shows you like sort of the dependency we have right? We can depend on the results from one chart we can send to a short things that have been computed And so this will be important to understand there So to rephrase what I'm proposing Before we dig deeper into the problems like I've showed you only a small part of the poop a lot more poop coming up But the scheme is this phase one The short execute the local transaction and they simulate the cross-shard transaction When they do this, they will collect all the cross-shard messages and all the access storage slots in the face to we do the exchange and The short simulate the messages and similarly they collect all the storage slots in phase three all this In phase three all this stuff that we collected here and there we ship it to the atomic charge and This will atomically execute everything and normally it should have All the state needs and if it does and it will just basically fail to execute transactions So the big problem with this scheme is That the simulation restricts the expressivity Right, so we can only safely express Transaction where the simulation will be deterministic in some ways Because otherwise you you know the state might change and you might not be able to execute things So you might sometimes take the risk That transaction won't work say well, I'm gonna try if this says doesn't change is gonna succeed But if the state changes it's not gonna succeed We'll see that sometimes that doesn't work By the way, this is exactly the same problem as building strict access list or UTXO for slots Same thing you need to collect all the storage slots that have been accessed. So this problem is a pretty similar So the prime you know what it gets worse is that cross-shard messages may depend on uncertain states and We to derive all the messages during simulation and this way we want to be deterministic We can also Want an answer for a short and so we absolutely need to have a hint for the answer So let me illustrate because this is very abstract. So what I was saying was that this parameter here x Depends on the result of computation. So we need this to be always the same. Otherwise, we're just Asking the b-short to compute something that might not be what we want. So we absolutely need x to be to be known and You know that the message sends an answer and we're gonna send this answer actually directly to C So we absolutely need to know the answer already also I've actually illustrated this constraints. So Here we need the computation to be deterministic in the storage slots that accesses Here we actually need the computation to be deterministic. So they always return the same results Here if we use Y just in a computation We need to hint the results Approximately just to get a question, but if we send it to another chart, then we need to know exactly what Y is like no No guessing. Otherwise, we're just asking C to do some bullshit and we don't want that So open questions Is this reasonable? Is this a good idea? Are these restriction? Feasible, do they give us a powerful model that is useful in practice? Our question is can we statically guard against some some some cases of the non-deterministic execution that we want to avoid? Or do we just say well, it's a user responsibility and maybe some people will build some tools to detect some of these cases This is for sure a foot gun, right? Like if you're gonna make a crush our transaction and You don't expect it. You expect it to be deterministic, but isn't there's definitely there are lots of possibility to make bugs But is it worth the cost? Our question is what is the correct? Abstraction level for all this if we don't enshrine static checks We can simply add like a cross-short call opcode to the EVM and then just On the back end it will do what I explained But from the point of view of the EVM, there's just a new opcode This has been my presentation We have five minutes for questions. I'm sure some of you have burning questions You should have a lot of questions because this is very questionable And yeah, do you think sharding is maybe just fundamentally kind of impossible and like Kind of like when you're trying to do us like you have all these different systems It's almost like they shouldn't be able to interact in this way. It's a really dumb question I mean in a certain way you're right like we're Yeah, the idea is like you can parallelize what you can but then sometimes you don't want to parallelize and you're just trying to build This abrid like a synchronous synchronous system So yes and no Someone else someone's come to come to some walkie idea. There's not a dumb question. Yeah in your model the Regarding the new opcode that is aware of sending message cross-sharding Does that mean like smart contracts need to be aware of calling another smart contract that is in another shard Yes, how do we envision those things and also in sharding without the new opcode our smart contracts being aware of Calling something that is in another shard because that brings Friction to smart contract developers So yeah, the model I've been assuming is the model of sharding as like small sub blockchains There are some proposals of sharding that I would classify under Paralelization you just pretend you have a big blockchain and then on the back end you just put things in shard and you move things around But for the user they don't see that here the model is explicitly you have multiple sub blockchains and they talk to each other This I think simplifies the implementation a lot, but not everybody agrees Actually my good colleague car does not entirely agree with that But that's at least my point of view and There are other advantages which is that you can have multiple roll-ups that do things slightly differently as I mentioned So that's an advantage Does it okay? So regarding the sharding in itself Is it possible for instance to imagine a system where the accounts would dynamically move across the shards to try to reduce as Much as can be the inter-shard Exchanges on so to simplify the whole process Or is it that completely different use? It's possible. I know there's research on this. I don't really know anything about it But yeah, I think this was more related to the models where you just like rebalance the shard and like you wouldn't necessarily be aware of the shards Yeah, it exists. It's definitely feasible. It wasn't really thought through here in this simple model Yeah, I think this sort of needs some like Like a balance chain where you have all your coins that will probably or at least have your balances be accessible by every shard I would support a simplified design a lot and in practice when we see Things like avalanche they have like a special like chain for like payments because it's so special and so important So that might be one part of the answer Hey, my other question was some could we use things such as like AI or sort of predictive behavior in Combination with this to sort of like just automatically optimize or is somebody working on on stuff like that to Sort of predict the interactions between the smart contracts and how to kind of optimize across charts I'm sure so people are working on it. I know I Know there's a bunch of research with that even on payment chains so things like Bitcoin and stuff I don't know why it was very hot academic like academics are like lagging behind the stuff We do a lot and they've been like very like I've been to a workshop this year And I'm very interested in exactly this problem, and I'm like does this change the smart contract or like no I'm like what's even the point like just put it on a big server and be done with it But yeah, you could do it sort of didn't assume that model here, but Okay, thank you very much