Less State, More Logs: Scaling Ethereum With Stateless Parallel Transactions: Zsolt Felfoldi

Hey everyone, good morning. How are you doing? Great. Thanks so much for joining us. I know it's early in the morning uh but we have a full day packed of really exciting uh technical and nontechnical talks from the Ethereum Foundation.

And we will start with Fali from the GU team. uh he's been with the foundation for a very long time and he will be talking uh about the new approach of scaling layer 1. So please give him a an applause. Okay. Hello everyone.

So uh what I'm going to talk about talk talk about is uh uh an uh engineering uh project that turned out to be quite quite an uh turned in kind of turned into an R&D project and uh now uh I would like to make the case that it might even be relevant for uh for scaling Ethereum uh with with with new with the new storage architecture. So um so this is uh where the story started. Uh last year I uh started working on a new API. So this is one of the uh coerium team projects. Uh so uh the old JSON RPC API is very obsolete and also uh actually it has never meant to uh be used the way it is used.

Uh, so I I the so the what I want to what what what we we started to work on is a is is is is a new REST API that is similar to the beacon chain API and uh and provides all the responses with with Merkel proofs based on the latest uh execution block hash and uh yeah so uh so this is this is this is where the whole story started but Um unfortunately um there are certain things about the the chain that uh are not so easy to prove in an efficient way. Most prominent is the logs. So uh originally we had the bloom filters and headers but that wasn't very effective to begin with and now it's practically useless. So right now if you if you if you really want to prove the uh uh results of the lo query that basically takes the entire uh receipt rece like it's prohibitively expensive. uh also uh there is no easy way to prove that certain proof old canonical uh block hashes and and then transaction inclusion or more more or or more notably uh the exclusion proofs are very hard so it's really hard to prove that something is not on the chain so yeah I just wanted to uh uh make make everything everything trustlessly provable So yeah, this is this is where it turned into R&D.

Uh actually this did the trustless log index project. It started out so now actually this is what I have now is is the third iteration. uh the first the first EIP7745 uh that's like very complex and and um yeah now I I explored like uh different paths and and this is this is this is what uh I currently have. So it's based on uh what I call index tables and and these tables are generated from uh generated for every block and and then these tables can be merged together to bigger blocks. It's basically a sorted list of of events and uh yeah it's just don't have a lot of time and just quickly show how it uh works.

So uh so this is this is the most typical thing is an ex exclusion proof. So if something is not present then there's a sorted list and there's a position where it should be. So proving the two adjacent entries proves that a certain like in this example a certain transaction hash doesn't exist. And yeah, there's a more complex example which I really don't have time to uh talk about now, but it it's also it can also prove like complex lock pattern searches and uh and the way these tables are handled for like an entire chain history is that uh uh one uh one table is generated for every new block and then uh then uh these tables are merged together. It's uh merging sorted list is is is an easy task and u uh and and only the only the single single single block tables are uh are uh generated during block processing.

The bigger tables are all uh merged asynchronously. So it's it's it's a really efficient thing. And uh and so in this proposal the the uh the block header includes hashes for for like uh uh 1 4 16 and uh 64 block tables and bigger tables can still be generated and and the proofs get more and more efficient if we have bigger tables. Uh but these can be generated with ZK proofs so that uh this this whole process is not a huge burden on the on the block processing. Yeah.

So this drawing is kind of similar. It just shows like like a comparison of of log and state as like general uh storage architectures. And so the state is state is is is one huge tree. And uh and it has a big advantage that uh the uh a weakness of a certain item in a state is is a has a logarithmic cost. But uh also it it's uh it's it's already uh big and and and kind of hard to synchronize and if we seriously want to scale L1 uh 100 times or thousand times then even with this state expiry and and statelessness uh it's it's going to be a challenge.

So what I started to explore is whether the trustless log index could be used as a as a contract uh storage architecture. The uh the advantage is so so the the main advantage is that it's very cheap to add new entries because basically uh what we uh process during block processing is is is just the events of a single block. So this can be that can be sorted in memory and hashed in memory. So uh uh so the like like adding a state entry is already five to 20,000 gas and uh and and and uh it's pretty clear that uh if we if we scale the execution so that can be scaled many times with block level access lists and and uh so that there there are good plans for scaling the compute but uh the state uh cannot scale at the same rate as a compute. So, so the guest cost would probably increase even more.

While with the logs and the trustless log index uh a log costs like it depends on the number of uh topics but a typical log topical log like like a transfer which has three topics cost 1,500 I guess and it's easily maint maintainable with when we generate the trustless log index. So uh on the flip side uh the uh the the witnesses are are more expensive. So uh so we merge these tables uh to bigger tables and then even bigger tables. So we have a roughly logarithmic number of tables and all the individual proofs are also logarithmic. So the witness cost is more like a log squared.

So uh but otherwise it's it's a really convenient data structure. Uh it's it's much easy. I I I I would say it's much easier to uh synchronize than the state because uh the uh historic index tables. The the bigger the table, the longer time it it is unchanged. So once it's generated, it never really changes.

It just gets merged into a never began table at the certain point. But uh for the big tables this means that they are uh they stay the same for a very long time and and there's we don't have all the challenges that we have with syncing the uh constantly changing state. Also uh we have time information. So uh they can be looked up uh in a way that so the contract can uh have kind of the expiry uh enshrined enshrined by uh in a way that it just doesn't uh uh look very far back for the for the in the in the in the history and uh yeah okay it's sorry just go back a minute so uh but yeah so uh I Uh yeah uh if we really want to consider it uh for for uh for onchain use then we have to do something with the log squared witnesses but uh the thing is that uh this might not be a problem in the future because uh we already have an account abstraction API by vitalik which uh separates the uh pre-checks and uh from the from the main transaction processing and it is possible to uh uh yeah proc like like a do do the the the signature authorization and witness verification offchain. So basically there are transactions with separated witnesses and they can be batched together with the zk proof and and uh so the uh so the witnesses will never actually reach the chain.

So yeah that's uh I think this something like this I I I can't can't say this is exactly how it will look in the future but something like this will probably be necessary for for postquantum signatures also because they are big so yeah and uh yeah so uh so uh in the future uh if if if uh this becomes realistic then uh then we basically have we could have the advantage of very cheap rights as opposed to the currently uh expensive and uh increasingly expensive state rights and uh yeah I don't have time to go into all the details but uh but uh so so uh I actually this could be used this whole structure could be used just like the state as a key value store but I I I think that uh the logs uh they they are just a more flexible more flexible data structure. They uh uh they are parallel execution friendly like sets and lists can be can be represented in a way that there are no right collisions. It's also multi-chain friendly. So uh it's uh yeah it's it's just because because it has a time information. It's easy to uh prove the the relevant events since the last update.

So uh yeah and finally so this is this is how I think this whole infrastructure could look like. I won't say it's a simple thing but yeah maybe maybe at at the point something like this will be possible. So uh so we have we have we have uh like like transaction batching provers which uh help with the big witnesses and also maybe with big signatures. And then there are the uh logs the the the very recent logs can be visible by the the uh EVM directly. And then we have these uh tables that that the protocol generates and we can have further zika provers which generate even bigger tables from that.

And yeah this this can go back to the witnesses and the the the the table merging proofs can also be merged with the with the other ZK proofs recursively. And yeah, so that's it. Thank you for your attention.