sandusky - Scaling Ethereum: the power of UTXO

Transcript

thank you so much guys for being here thank you so much to the staff team for making this possible so scaling ethereum the power of utxo uh we are going to understand why we need to scale ethereum we are going to understand what's an utxo but um this is vitalic uh 6 months ago this is uh 2023 later two days in Istanbul uh bullet bullet proof vitalic did an amazing talk that date uh two key takeaways uh the first one is vitalic talking about plasma which is uh quite crazy and balica talking about utxo which is today's topic um so we are going to talk about the state blad and decentralization issues we are going to talk about race condition and execution

issues uh we are going to talk about utxo indeed we are going to have a quick view of the history of utxo uh by the work of hini um we are going to talk about the state minimized design we are going to talk about predicates and we are take a very quick look to some projects using uh utxos right now so State blow and decentralization um State blow is the situation where increasing state in the blockchain uh leads to increasing Hardware requirements for the validator nodes um basically increasing Hardware requirements thread decentralizations um because more hardw Works mean more money and not everyone

can run a note so so the network gets centralized um this is a chart uh portraying how ethereum Estates is growing nonstop since the beginning um but not every kind of state is the same kind of state so we can understand like basically three kind of estate growth issues the first one is estate growth which is new accounts new buy code uh new Sage we can see uh history growth which is new blocks and transactions and we can talk about estate access which is the issue of reading and writing operations for building and validating blocks today we are just focusing on estate growth which is new contracts buy

code and contracts um right now the ethereum estate is up to 245 gigabytes uh on a red note which is a lot um mainly we have accounts which is 14% then we have bu code which which is uh 4% and then we have contract Sage which is 81% uh a lot of of memory spent there um seems like it's fine but it's not it's strengthening uh the whole ethum ecosystem um and as you can see somewhere around 48% of current eum Sage is basically erc20 and ERC 21 transaction so it's like we are spending

a lot of resources just to tracking uh assets um so summary State blow is bad then we have another issue which which is the race condition uh some of the computer nerds out there might understand this concept which is this is like a block header for an eum block uh an important this oh an important ascept might be the state root which is the root of the Merkle tree of the state of the block um and basically AUM stage looks like this is a dictionary where you have account names and E balances and for the case of contracts you have like the E balance and you have another stage storage route representing uh the

contract storage which uh for year20 might be like just accounts and balances of that specific um token so the question might be why is not parallel like what what's the issue behind the account model to make the parallelization impossible well because of race condition race condition is a situation where two processes are threats are trying to access and update the same slot of data um looks like this but basically um an ethereum did some work trying to solve this issue this is a a screenshot from the eips GitHub um basically this is prop this is vitalic proposing somehow some kind of access

contract list for execution so basically the the node can know beforehand um which storage slot are being updated um that's that there's a lot of interesting information in this um in this uh issue uh one of the cool takeaways is that um accounts can have arbitrarily large EST trees and we can load that into memory and then we have another funny stuff which is we might require noes to have 512 gigabytes of RAM which is completely nuts um but basically the issue was closed when they realized that this cannot be

done like it's another bottleneck and the conclusion was we should move to stateless clients um or sharding basically so you can do parallel execution in ethereum um so stateless is the way um I don't dig into many of the available solutions to solve the state blow on ethereum just the state minimized design but right now I sck with account model is somehow bad uh then it comes utxo as a blessing uh this is how inventing utxos and helping us to solve uh these issues um and basically utxo is an approach where you don't need uh a root state so you don't have centralized state so you don't have

rise condition and so on um utxo look like this and they stand for unpend transaction outputs so basically this is how Bitcoin works and it's like you don't have a big spreadsheet of balances from each user but each user has uh some amount of money locked in some kind of program and then you have like a bunch of programs with money that is not spent yet um so it's like a piggy bank basically you put money into a piggy bank and then you have your account with a bunch of piggy banks with different amounts of money inside them and when you want to spend some of this money you just destroy as much as Pigg you need to fulfill the desired amount then you

create a new piggy bank with that amount of money and send that to the recipient um another analogy might be cash so basically when you pay with a $100 bill let's say you are willing to pay 30 so you have 17 change well the cashier might be burning that $100 bills and creating two new bills from scratch a $30 Bild uh for themselves and a $70 bills for you so it might look something like this a bunch of utxos are going to be merged into one transaction to create a new utxo a more accurate dep picture might be this one where you have 50 Bitcoins you send them into a transaction and

split them uh5 into another recipient and 49.5 for yourself another account might be the same so it's going to merge a couple of utxos in order to create a couple of new utxos so it's like an ongoing process process forever um so why is this parallel well because you remember race condition where you're are trying to access the same slot that in memory where you don't have that problem because of atomic State basically you are having spe H pieces of stage pieces of data flying around in the blockchain so beforehand you know they are not colliding together which is amazing UT EXO killing the root estate um wait a second I'm zosi I'm developer Rel

engineer at Fu Labs you can find me like this on Twitter um we are building the rollup OS for ethereum so it's pretty cool go to fuel. network to check it out please um skip the selling um we were talking about utx so so good right um but this has a history behind and it's a pretty Cipher Punk history um this concept kind of was invented by halin back in 2004 and basically comes as this concept reusable proof of work um this is an screenshot from the archival website which is started at the Nakamoto Institute website and they even have the slides so

I'm going to reuse some of the slides um this is based on top of hash cash hash cash was built in 97 by Adam bak and basically is proof of work they invented a way to tokenize uh expensive computation in order to avoid email spam um the issue with with this is like you cannot exchange them and Hal had this theory that uh If you're receiving a lot of hash cash proof of work means that you're a real human being spammers often don't receive emails therefore they don't have uh proof of work uh related to their own account so they say if you already have a computation proving that you are a real human being you should be

able to spend that tokenized computation in order to perform perform other actions um and this is basically the utxo model you have uh proof of work tokens you don't have uh you have a data structure that allows you to spend that um uh tokenizing uh Computing and then you have a network on of decentralized uh protocol and servers uh willing to verify that information this is basically Bitcoin um almost 10 year uh almost 5 years before of the white paper um so thank you so much hini for building um this technology that makes us so happy um now we go into a state minimized design where basically we are

trading off bandwidth um with the state in ethereum we have different kind of uh stage information we have like call data and memory which is like uh emal information uh memor is like the scope variable tables you are using within a function and C data is read only information that comes as form of parameters within the transaction and then you have a storage which is permanent information um storage might be like going to a restaurant so you are like walking so light way you go there they have the food you eat you live and then you have C data which is like keeping your own lunchbox wherever you go so basically for a storage based uh

execution you have all the information in the contract and then you send lightweight transactions to avoid um taking so much band with it and then you have call data where actually you are sending big transactions to pretty stateless contracts that's why it's called Uh State minimized um Unis swap B3 is doing this actually um this is like the Staker a section of the Staker contract and basically you see that they are just starting a derivation of uh some data structure and each time someone is willing to get information from that incentive they are basically Computing back again the information um and seems counterintuitive because we learn that we want to avoid Computing

things many times so we build H caching and all of these of stuff but actually for blockchain this makes sense um and it's called State hydration so basically you are uh keeping track of a small pieces of data in the blockchain and then using computer power to rrate that data and have meaningful value um and then is where pranes come into action basically this is a stateless account abstraction uh it's a new kind of primitive built- on the fuel Network and it's something really cool that I would like you to see um so we began talking about utxo and we end up talking about predicates but in the middle there's pay

to a script hash this is something coming from I think it's B 16 by Gavin Anderson uh so what the is um P2 pay to script hash well you know the standard kind of accounting Bitcoin and everywhere else which is private key elliptic curve and then a public key so you deposit money or associate money to that account and then a private key um is able to like spend that those resources where in the case of um pay to script uh hash you have like sign atures and you have a redem script which is um some some kind of puzzle uh designed to define the conditions whether a utxo can

be spent or no so basically you are having a public key that doesn't come from a private key but from a script so that's like the uh idea um you can imagine that as like the log boxes you use for airbnbs so it's not a person giving you the asset but a device in the world having some kind of uh P puzzle and then having some kind of asset that you can unlock so if you know how to solve the P the puzzle you know how to get the assets that's the whole idea um but what's the issue with uh P script has why is not like so widespread use well basically because Bitcoin is dump

like you can do almost anything with Bitcoin so far uh that's why we went into ethereum decided to go with the um account model rather than utxo model so that's where predicate uh become so useful because predicate so powerful so good so gentle um are some kind of mix between the utxo standard approach a powerful VM s such as the fuel VM a high level expressive and useful language such as sang which is uh a DSL built BAS on Rust and the philosophy behind pay to a script hash that's where you you get

predicates um a predicate is just a pure function uh that you hash and get a public address so it's like the source code is the private key and this is basically stateless acon abstraction why because you are not studing this code in the chain you are just keeping track of the hashes and whatever who has the input script is a able to spend the money that is there but uh not with the code only you have to fulfill the conditions of the code so a predicate may be basically a functor this for the computer nerds um so predicates are like wallets they can receive assets they can hold assets and they can spend assets um

predicates are like wallets so they can be deployed and they cannot be deleted um so yeah so they are pure functions with a Boolean return and if the result of the predicate execution we call it evaluation if the result of the predicate evaluation is true well you can unlock the assets within that predicate um a slide about reusing proof of work but I'm reusing the slide um spending predicates so basically you need the predicate code as I told you you need a transaction that fulfills the condition of the predicate you need the full client and the F utxo set this is basically like the blockchain and then

you have a new utxo so it's basically it it's like uh utxo sending transaction between them but adding an additional step which is solving a puzzle so you don't have to keep the money yourself you can keep the money in a stat less abstracted account and you can spend that by fulfilling the conditions of the predicate differences between contracts and predicates are predicates won Access onchain Data why because they are pure functions um they can read data from a smart contracts they are not aware of time and they can read hash numbers or block numbers um but they can read input and output coins of the transaction they

can they have access to transaction script and transaction transaction bite code this chart is coming from um our own guide on predicates which is predicates 101 building stateless defi applications um you can check it out just right here um but I'm getting the QR again um bonus track LMS and utxo this is another projects right now uh leveraging on the utxo approach we have Aztec uh privacy Solutions we have nervos nervos which is like intent based network uh we have fer which is some kind of ethum side chain uh we have leum and only one of them has powerful

predicates which is fuel Network so summary and a few conclusions um state blo is bad for decentralization um account model can be parallel um utxo is so good um how thank you so much uh and prates are so amazing um so if you want to start building a stateless defi applications you want to mess around with predicates you want to build this crazy offchain onchain secure funs well come and join this QR code I promise that it's not a security threat for you I just need a tracker for the event so I can show it to my manager um but yeah that's it um thank you so much do we

have time for questions we have time for one or two short questions are there any questions is there anyone however uh we can meet outside and keep talking about uh computer science staff uh however thank you so much for attending and hope you have a great time time building with predicates thanks thank you