Rethinking Ethereum’s account model by Will Villanueva | Devcon SEA

[Music] [Music] quick talk I think it shows expert I'm actually not going to go that deep um so I am a actually let me go back okay so I think we should uh rethink some concepts of the ethereum account model and also the account models that we're using on l2s specifically to scale this is a forgotten mechanism to scale I'll go into some things here really quickly I think deterministic State addresses and state access is really important in order to accomplish this um I think uh there has been discussions of access lists in the past that didn't necessarily get enough traction um but this actually can uh provide significant scaling indexing uh improvements and security improvements to ethereum as a whole um so with access lists or account lists um you know the state ahead of time that can touch this allows for uh being able to uh do things like uh execute concurrently um since you know the different parts of a graph of nodes that you are uh touching this can be enforced by the runtime it prevents any overrides um for example if two swap transactions are happening through the same protocol um but the same token this can actually happen concurrently so I I sort of think of this as another mechanism for Mex uh multiplexing spawning parallel processors um another way to think about it is um knowing your IO ahead of time um and or having a uh essentially a built-in mechanism for um for sharding as well I think this also works really well for multiple concurrent uh uh proposers um this kind of go hands in hand it's really great um again I I'll go into erc20 as an example erc20 um sort of represents a massive Global state that everyone can touch and anytime anyone touches it this sort of creates a global lock on the system um and so uh you know I I sort of mentioned this so um you know I'll go ahead and skip this part um so this is like I got this silly graph here but you can see there's different parts that are being touched um and in this case you could split this up into three different concurrent um uh processing um or execution which um can actually make things really interesting uh from the side this is really helpful as well um I think security and the data side like once we're indexing and once we get things to scale and get really really fast these are things we think about we don't think about this a lot currently um in the ethereum ecosystem I I think there's maybe some exceptions tjs here um but as as things scale really big and we get to the point that we're dealing with like hundreds of thousands of transactions per second across all the l2s um actually having mechanisms that inherently provide better indexing uh via the account model can be extremely helpful um but again approved pattern on erc20 is I'm just giving specific concrete examples obviously we all know it's a disaster um you don't know ahead of time when you look at the shape of a transaction um you don't know what uh what accounts will end up being touched you don't know where the funds can end up being spent um you don't have a deterministic way to know what reads or writes are going to happen if you know this ahead of time um then this actually prevents a lot of safeguards that you have to do on the contract layer um and this is what I call an account Centric model um I think we've seen this in uh some of the concepts of like uh move ecosystem um I think svm has has done this there's been some experimentation with other models as well um and varying parts of them are are um are interesting so um this also helps for things like memory Pro programmatic ownership patterns memory ownership patterns across different um levels of the stack when we're calling um when we're uh calling between different contracts so um yeah so uh also it's really fast pre-processing level from security perspective um I think what's going to happen is we're going to have a lot of wallets that are going to look at the fingerprint of a transaction ahead of time and let you know without processing on chain um or simulating on chain um what are sort of security uh aspects that that could be uh vulnerabilities and so this actually makes this really clean this is where you can have like a easily readable format of what your transaction is about to do um yeah that's uh that's sort of the the thing I I'm all for State access lists again um I'd love to see this come back and have this as part of um mechanisms to make things run concurrently on ethereum and the l2s and scale that um that's all any questions okay okay thank you L um do we have questions okay I saw your hand so that was good so yeah I have this question like there was a paper published maybe last year about uh like access list by uh some people at it and the outcome of the paper is essentially uh the discount is not high enough many people who are using access list are misusing it many clients are implementing it incorrectly and so on and so forth so what steps concretely we should take to solve those problems increasing discount or what yeah I I think in general you need to enshrine more into the actual consensus on rules on how access lists can be used um different different aspects like that and then also from the security side it's it's really important and then I I also think um I I think that particular study um looked at it comparing to what the current patterns are on chain um I think if you make the changes to have have a model like this um some of the programmatic patterns will change and therefore will lead to scaling uh naturally but yeah next question okay beautiful so the eth research post or discussion that was talking about State access list way back in the day is cited by Fuel and there's been some extra thought on that and some developments are there any differences between your absolute dream like you know Pie in the Sky perfect if you a dictator model of State access and what fuel is currently running I think what fuel is doing is elegant um so I think it it follows a more account Centric model it's like sort of like an a utxo model is the way that I see it and with utxo style models um you have better determinism around accounts and it's much easier to see what you're going to touch ahead of time and what you won't um so I think with regards to ethereum um it'll never go to that stream um but I think there's good balances to where we can sort of keep some of the beauties of the current account model but also have additional speed and security thanks last question okay TJ hello um can you just Define these lists and then how do you calculate this list prior to the transaction happen I never understood that how do you oh okay um so basically any state that you access you can deterministically write you can have a hash that represents that state that you're going to access for example um and so uh anything that you touch any of those um State locations would be referenced via a list of hashes essentially um that's one mechanism to do it there's a bunch of different but yeah how do you know that without running um so you have to how do you sorry how do you get that without running the transaction um yeah so the user would run the transaction ahead of time right um or may run the transaction ahead of time uh before they form that and then um it's then it's enforced um in the consensus protocol if that makes sense so that means people who are listening for transactions that are coming in wallets that are um trying to validate the security of a transaction ction things like that um know that these are the things that are going to be touched and there's no like bit flip that might happen that might suddenly have it touch like 10 other accounts that could end up siphoning funds or do some type of bridge attack mechanism if that makes sense okay thank you so much let's talk later thank you so much guys let's give a hand of Applause for Wales and thank you for your amazing questions like I said it's going to be interesting this morning our next speaker is