Scaling ethereum 1.x with WASM precompiles

Transcript

let's suppose it okay thanks for coming yeah I would like to talk about an optimization that I've been working on in the past couple couple months this follows a presentation I did that at Def Con so it's about how to use whatever compiles to try to reduce part of the state of like an East one at least one chain okay so yeah as a quick reminder the state is mostly made of blocks of accounts and the accounts have the

classical thing nonce balance code and the data storage so that data storage is stored as as a hash of a tree and of course you have the receipts and the indices which also make for a lot of a lot of this the actual space so as a quick reminder it's less colorful than what LXE did but I'm sure a lot of you had plenty of time to to know how to find out how the account try work so I'm just going to focus on the on on the account and you can see you have the storage root here and if you want to expand that the way Alex C said he was doing it actually this is what you get so it's just completely hypothetical but

you can see it gets very very big very quickly so if you perform a sink like a fresh sink this one dates from from last Sunday you can run this comment guess inspect on it and you can see that well most of the state is indeed made of headers of bodies but the Tri nodes you know it's starting to get to get pretty big as well and there's the receipts as well who are kind of something would be that would be nice to get rid in the future but yeah so far they're they're being kept so yeah there's this problem in economics that I'm sure is

well-known is called the tragedy of the Commons and in this problem the state effectively comes as a bargain because yes you pay some gas to store some data but the recurrent promise in the protocol is that it will be there forever and because it's there forever dividing any cost by infinity is still zero so it's you just store and you forget about your data and however if you are someone working like working a full known maintaining a full node you have to keep that data forever so yeah that's that's the problem there's no so you already have efforts trying to

address state scalability you of course have stateless clients you've you've heard about that for for the last two hours the thing is the biggest problem I see with this approach even though it is necessary because you want to be able to access is there EMA from your from your mobile phone you still need to rely on full nodes you need full nodes to still be around to produce proofs so that you can get the data you need get the proof that this is actually necessary and and yes someone will have to do this this is gonna come at a cost and less and less people are going to be incentivized to provide this so you will have I mean at least there's a risk of having some

centralization and of course in long term you have East too but it's not quite clear yet how the the eighth one shard which will which will be part of the whole system is going to be handled and because of that the in there still merited trying to keep the state as small as possible so what I'm looking for is just a short-term method to keep the states to reduce the state to you know make it a less of a burden as possible and yeah so the basic solution to the problem of the tragedy of the common is to privatize the Commons so in that case you privatize parts of the state it becomes somebody's responsibility for example if your

crypto kitty you can't be dumping cats all over the all over the place it's your cat you take care of it and so yeah you take the idea is to take something out of the like domain Shane what the note is what the full notes are are handling and move it to like let's say more of a community approach where if you are part of the crypto Kitty community well you are collectively responsible for handling the state and only the the route will be saved on the on the on the chain so this is the current this is a simplified version of how the current system works you have the chain here and the chain points to the root hash of the of the tree and so

the in blue this is the the account the account tree and yes the the account points to a root and the root is so the first DAP has its own root and and they have the tree underneath and same thing with the the second well in in this approach you only maintain the roots and everything like you need a special node to actually take care of the states for for you so if if you're a crypto kitty you will have to run your own nodes if you're any anybody else if you have an A or C 20 well at least you have an explanation for at least a justification and economic justification for the existence of your token so the

advantages of this approach well it started can basically implement it be implemented right now you cannot really hack like get the state route but you can just have a state of just 32 bytes to hold the hash so you have like a very simple tree that contains the root of an offer of chain tree and then you can start experimenting with every change you want like that there are currently being discussed for stateless and and for East too so if you want to use binary trees if you want to use fancy signature schemes you can and if you want to go the other way if your state is only or your storage is only one bit well why do you need a tree right you can just you can just store that bit in

in the 32-bit byte reserved for the hash and yeah what's nice is that you can all it will affect full notes so we will be a way for full notes to to reduce their sizes of course that wouldn't need a for that part would need a fork you would be able to reclaim yet to garbage collect literally garbage collect all those all those cats but yeah it could be it could be done fairly easily and yeah the last advantage is indeed that I'm not pretending to come up with any new idea it's already being discussed for East too so doing this thing can be done but on a per contract basis and paved the way for whatever is to execution engine

turn out to be so I come up with a very simple model here it's not a functional one but it's just to explain the way things would work so you know it's like any RC 20 except instead of having a map with a list of of accounts and their balances and instead of having a function like transfer thing and and things like that you just reproduce you use the storage tree or just storage try as the token token account try and you can use a binary tree or not sorry binary and yes you have this model which is balanced nonce signature and you just pass like

token transactions which has which are effectively layer two transactions you pass them you don't even need to persist them on on chain before you actually before you really need to before you detect there's a problem with with the way people are dealing with you so in practice this is I realize I forgot to add the signature here but this is this is a like and traditionally theorem transaction you have the data feel and in that a field you have the proof and the list of actions and those transactions are layer two they are represented here so just announce the value from two and because it's moto inspired from ERC 20 you don't

even need the signature here because the signature from the sender address has to be the same as the one here so it will be it will be validated once again the field is missing sorry for that but it should be here so the way the algorithm works while you just check the proof and then you apply transactions one by one and at the end you recalculate the update the updated account account try and you you put the hash back into into the contracts storage so yeah just going through the steps you start from the from the root and worse then you start from the root you use the proof to rebuild the the try that has just this recipient state and

in the sender state you just verify you do the usual verification so signature and that you check that the balance is correct then you just transfer the balance from one account to the next and you recalculate the hash and and that's updated yeah so one remark that is fairly important there's a double spence possibility in that model it's just an example because there's a known there's a nonce and if I want to give the nonce if I want to for example if I give someone a transaction that has the nonce

they can check that at the time I give it to them the nonce is the correct one but then when I see they publish it on the the embedded in a an East one transaction and they publish it on the network I can create cross my own transaction that has gonna have that will have a higher gas price and therefore my transaction will go first and by the time it gets to their transaction the proof will be invalid so they will be rejected but you still have a lot of nice things you can pack several transactions because for the same proof so in the same each one transactions you can pack several token transactions that's because the proof in that case

like you need to spend gas for the length of the transaction but if you all start from if you have one starting point the same starting point and then each transaction is applied in sequence you don't need to save the intermediate proofs you don't need to pack them and reuse them and unpack everything so you can just share the cost basically between between several people and at this stage where we're effectively just like a state channel system but yeah with with a big book and yes it's the problem I already alluded it alluded to it when when I spoke about double spans the thing is you need to have a hash that's going to be up-to-date so if you

have a low bandwidth application if there's no kitty craze and you're the only ones in you're the only one in your block you will go through otherwise you need to use for something that in these two parlance is called a relay err so it's some kind of node and that you give your transaction to and they will package it for you they will create the proof they will collect like gather all the transactions they will embed them in one is one transaction they will create the proof for that so just to extract all the needed accounts and of course they they usually do that for a fee presumably paid in the ERC to token itself and yeah you can do that and this is already something that is pretty much very close to what is easy to is

planning to do so implementing all that could be done right now except yeah EVM code is a bit is a bit too expensive for that or so this is where precompile come in so the way instructions are prized their price for any task possible so usually the way the price got got decided was by running a lot of a lot of code and trying to see what the average price is but in the case of pre compiles you know what this is for so you can try to pay for just the task so based on the input you know how much running this specific algorithm is going

to cost you and in that case we spend our time rebuilding the try and hashing to try so it's going to be to be very very repetitive and if you implement it in you know as you pre-compiled you have plenty of options of optimization options like caching like like paralyzing if you want that is not so easy to access from from the evm why wasn't because that was in the title well there's been a lot of there's been a lot of push back trying to add a new pre compiles introduces a risk of breaking consensus because every single clients implementer has to to

reemployment it in their own language it's you know it's risky if there are differences if there are disagreements if there are debates so usually historically it's been very hard to to add pre compiles so wisdom is like a blob that can be it's it's something that goes that is interpreted by a virtual machine and because of thanks to that you can just add a virtual machine interpreter to your to your sorry an interpreter to your clients and you can drop the blob and you need to do the validation once and you know everybody will behave the same and then you're free to do optimize like optimize it rewrite it in your native code but you have something to compare

against all right I'm running out of time so there used to be some improvements that yo hei and I worked on who to basically it's improving the previous model by adding smart contracts and you can solve the double spend problem but yes so it's I have to skip it and I will point you to this these repositories that do implement part of it I will I call it oh yeah I I forgot to say I call this pro pro this project Jupiter because it's a shameless copy of Raiden which is a god of thunder so I say why not name it after a god of thunder that is also a shameless copy of

of a Greek god of thunder and yes that's pretty much okay we can do one question but only one so maybe okay how do I spell my name yes so thank you very much young and [Applause] [Music]

[Music] excuse me okay [Laughter]

[Music]