Ethereum Singapore | Vitalik Buterin on State of Ethereum Ecosystem

Transcript

so um let's welcome vitalic here to Singapore once again thank you okay um okay next so um today what I'll be talking about is start off with a brief introduction to the progress that ethereum has made over the last few months but then I'll zoom in particularly on one of the interesting features of ethereum 2.0 that's going to come here up in when once we have a smart contract and state execution which is this concept of account abstraction and some of the interesting consequences and interesting things that you'll be able

to do with that um so to kind of put everyone on the same page um this is the of ethereum road map 2.0 Road mapap in one diagram um so the ethereum's appr of stake and charting plans are split into these four major phases where phase zero is what's called The Beacon chain which is just this proof of stake chain and for phase zero the spec continues to be almost complete and continues to be in kind of error checking debugging um and simplifying mode the size of the spec is actually decreased by over 10% over the

last couple of weeks um and um over the last couple of weeks one major piece of good news is that ethereum 2.0 um client implementers have been announcing test nets for phase zero so you can go to the lighthouse page and you can run a note and join the lighthouse test net and sorry was Nimbus the nus test that I mean Lighthouse and Prismatic and others are also in the process of releasing things very soon so yay um so after phase zero we have phase one which is where the sharting part of sharting comes in and here basically we have the

the 1024 Shard chains of um turn on but The Shard chains are not going to be completely active instead they'll begin by just being a kind of relatively D data layer and on that data layer you'll be able to just throw whatever stuff you want and it's about at least given the numbers we're thinking about somewhere close to 5 megabytes per second of kind of consensus guaranteed data availability but that data by itself doesn't mean anything um now that dat just the pure data layer is useful for a lot of applications and I gave a presentation actually the same presentation twice once in Tai once in Korea where I talk about applications that you can do just using a scalable

data layer and basically there's something called ZK rollup that you can do where you use ZK snarks on the1 chain with pointers to data guaranteed by the2 chain and you can get many many many thousands of transactions per second right so these are things that will become available fairly soon um phase two is when the system is kind of technically fully mature which is when uh it's not the shards are running and they're not just running data but they're also actually processing smart contracts executing code maintaining State maintaining accounts and all these other things so today I'll be talking about abstraction and abstraction is something that we've talked about in the context

of ethereum for a long time but it's going to be a major feature of this and phase three um Starks and further and um Casper CBC other fun features that's something that's going to come later but there was already specs for for example Casper Cas for CBC and there's teams that are looking to kind of formally verify different versions of CBC so this is well on its way and for phase one the spec is relatively close to done as well but it hasn't really started being implemented so what do we mean by this weird and magic word abstraction right um so basically the idea here is to uh we can

Define abstraction by looking at it in terms of things that it's not right so and who here has um watched me introduce a theum and talk about how before ethereum you had these kind of pocket calculator blockchains it's wasar blockchains where you define 10 different features and that's all you can do but ethereum is much more powerful because you have a programming language so basically that like that is an example of abstraction right and that's the application logic that's a kind of abstraction that ethereum already has and it's a kind of abstraction that basically is what makes the blockchain so powerful but really this kind of concept that instead of

defining specific ways of doing things in protocol we just make the protocol maximally open to doing whatever you want and letting more things be defined at higher layers is something that can be extended to other aspects of the protocol as well right so for example um tokens you can argue that they're kind of semi- abstracted because we're as saying Bitcoin there's only one token that you can use in ethereum well there's eth which is kind of a privileged token so it's not fully abstracted but you can make your own tokens you can have applications that pay in your uh that use your own tokens for payment you can do lots of things um signature verification so today um today

signature verification is not abstracted and when something is not abstract raed we often call it quote enshrined so basically there's these two kinds of accounts one kind of an account is this externally owned account where it uses a very particular digital signature scheme called ecdsa to verify transactions and if you want to use something else as I'll show you soon you have to go through a lot of pain and we want to um basically replace this with a scheme that says you can use whatever signature verification scheme you want and it's kind of just as easy as it is today um replay protection so for to prevent a

transaction that's valid from being included twice um currently we use this very specific scheme involving nonsense where every transaction has to include a number that keeps on going up but this is something that we can kind of abstract a way and leave as a responsibility to the user as well um transaction fee payment mechanisms they're currently kind of enshrined now in the form of the gas and gas field PR the to a transaction and we can abstract those and give the user the choice and the responsibility to figure that out as well so what are the goals of all this right one of the goals is consensus ler simplification we want to reduce the number of um lines of code lines of whatever um in in the consensus layer that all nodes have to agree on because

that's code that has to be written many times it has to be tested a lot it has to be audited and if it breaks the protocol breaks so we want to shrink it um increasing flexibility or Freedom or optionality for users you as a user should not be stuck with one way of doing things you should be able to kind of upgrade um to your own way of doing things on your own schedule um Quantum security um so with abstraction Bas upgrading to Quantum secure algorithms becomes easier because each individual user will be able to upgrade on their own schedule instead of having to coordinate a hard fork with one Flag Day where everyone is forced operate at the same time so signature abstraction right so

today the top bar is what we have today so in a signature scheme you basically have these four components private key verification data or public key signature and a verification algorithm so your private key today is a 32 by number yay your public key or verification data is your address which is 20 bytes yay um now the signature is these two values R and S that are each 32 bytes and the verification algorithm basically just says that you do the CC recover operation on the signature and on the message hash you recover an elliptic curve Point hash and take the last 20 bytes and check that it matches your address right so that's how it is today

now here's how we might want to do it tomorrow right so private key could be anything depends on the algorithm public key your public key is now a piece of of code your signature is now a piece of arbitrary data and the verification algorithm is you just execute the code using the data with the message hash prepended as an input so if you personally want wants to keep using ecdsa you will just have to write a piece of verification code that says hey there like run this exact MTH that I that I put up in this in this top right square and do this exact same check that we were doing before but you don't have

to use ecdsa you could use ecdsa multisig you could use Shor you could use BLS if you want Quantum Pro this you can use Lamport you can do all sorts of crazy stuff so to give a concrete example of how this improves things this um chart on the left is um how you have to do a multi today right so um if anyone's used a multi who here uses mul to hold their money not um specifically in ethereum yep okay it's pretty good um but the reason why not more people are doing it a big part of it is just

because it's annoying and hard right so here is what a multi looks like from a kind of code point of view your transaction goes into an account and it has to be the special type of accounts called an external a account which is not a multisig it goes in it goes into that account then that account itself makes a call to the multi-state contract and then the that call itself contains signatures from um other public ke that need to be verified the multi- contract verifies those signatures and it passes on the call to the recipient and then it sends some e back to the back to the account or possibly you have to do it you have to do it yourself um to make

sure that this account continues to have enough ether inside to P for Gap so who here agrees that this looks needlessly complicated well it is so here is what multi will look like after obstruction who agrees that this is simpler okay so signature abstraction right this is actually pretty simple to implement and it's by itself it's a very high value kind of abstraction so the main restrictions here is that we need a gas limit on execution so and this can be basically to prevent um miners or block proposers that receive a transaction

from having to just run a huge amount of computation and not know whether or not it'll even give an answer at the end um and the execution needs to be a pure function right so signature of a forication cannot be State dependent so one challenge here also is that um in ecdsa like this verification data the public that we're talking about is really tiny so we just use it as your address but here the verification code might need to be stored separately um and so we would basically need to have extra logic that says if the verification data has not yet been published it has to be published in the first transaction so that's signature

abstraction but we can go even further right we can go to full transaction abstraction so in full transaction abstraction the core idea here is that a transaction is just a function called right so the kind of logic for processing a transaction and the logic for processing what's called a contract called today can just be exactly identical to each other the only difference is that with a transaction the sender is some standard dummy address like the number minus one that just represents that it's coming from the outside now what's difficult to build this right there's three challenges that we need to solve here one of them is kind of block proposer do resist so this basically says if you are a block proposer and you're thinking about

whether or not to include a transaction in a block there needs to be some procedure you can quickly run to determine whether or not the transaction will pay fees currently that procedure is simple right you basically just check the trans check the signature check the kns check that you have the account has enough money and you know that regardless of what the execution will be at the end the thing still pays its gas so with abstraction but with the dumb way that's not solved Network do resistance um so how do nodes on the network on the peer-to-peer Network determine whether or not to really a transaction and what you want is for them to only really a transaction if they determine that the transaction actually has some significant chance of

having to pay a fee so you don't want real activity Costless and a third or sorry you don't want spamming the network with transactions that will be relayed to be costal and the third problem that you have is basically that if you abstract everything then there's no rule anymore that makes it illegal to just have the same transaction appear in a block five times and so you'll need some new kind of transaction identifier some replacement for transaction hashes so let's think about this more concretely right what will this look like Yay code um so this is an example of roughly what a piece of account code might look like

for an account or for a contract that is representing a user account right so basically what we're going to do is um this is a piece of code and it's going to um interpret the it has access to the B to the body of the transaction and it's going to interpret it as an object that has a bunch of parameters so it's going to just treat this as an object and have DC realiz it into this class um and now we're just going to do a bunch of checks right so it's going to interpret say the first eight byes of the transaction as a Nots and it's going to check that it equals the NS in the storage it's going to um interpret part of the transaction as a signature and it's going to check that the signature

of the transaction is valid then it's going to send the fee to the proposer then the nons is going to go up by one and then the transaction will just kind of pass along the call that it was meant to do right so basically what we're doing here is we're taking the logic that already exists currently kind of enshrined in the eum 1.0 protocol except in ethereum 2.0 we can just move it inside of account who here is following along so far okay so this is good I see I see nothing right so abstraction basically says you take one kind of code software logic that is currently part of the protocol rules and instead you just make the protocol rules much more on a general purpose and so instead like that

logic still has to live somewhere but then users just implement it ins or like realistically kind of software developers writing software that users use implements it themselves at higher layers to implement the same functionality in a more kind of voluntary and modular way um now um You might notice here this is um what's on the left is basically what a transaction looks like from the point of view of the consensus layer right so from the point of view of the consensus layer a transaction actually needs fewer parameters than it does now because the parameters are no longer kind of enshrined in the protocol right instead the parameters will live at this lower

level that that's just voluntarily decided by individual accounts so what the consensus layer see is is just three data fields now there um the serialization algorithm that we're using for ethereum 2.0 has this really wonderful property that if you don't fully know the structure of an of an object that you're dealing with with then you can just treat the parts that you don't know as just being bites but then if you do know the structure then you can also just interpret it as an object where all of the that actually kind of expands out into what its parameters are right so from the point of view of the consensus layer it just sees this and the kentus layer doesn't care what's in the body from the point of view of code in the account that's

execute that's being executed then it actually does kind of decompose the body into these parameters that we saw and it does kind of interpret them own specific way now different accounts can have different logic they might have these things in different orders but what matters basically it's the same sort of stuff that was kind of forced to be done the same way by everyone now can be done different ways by different users so now let's talk about safety a little bit right so what I just showed is not very safe for Block proposers basically because a block propos has no way of knowing of verifying

before it runs through the complete transaction that the transaction actually is going to pay the gas and that it's not going to revert revert at the end and just the end up not paying a fee at all so here's one proposed approach we add this op code called breakpoint and the breakpoint op code just has one rule that says if a transaction exits with an error after a break point then it just reverts to the last breakpoint and so now what we do is we just say after the logic in the transaction that the very small piece of logic that just verifies the signature and the Nots we set a break point and so if anything what regardless of what happens after that if if even if it reverts it'll only revert back to the

break point and so after that point there's no way to kind of stop the payment from happening and so a block proposer can just execute the transaction and if it and if it sees a payment and then it sees a breakpoint after payments it knows that that transaction is going to pay them the money that they deserve and so they can just they can include it and fully executed and they know they're not going to get dust so now the main challenges that we have is this doesn't solve Network leer problems and we don't have a notion of gas refunds at the end right so if your transaction uses some uncertain amount of gas it still just has to pay for the maximum it doesn't get refunded so Network layer issues um

Network nodes can get dossed too right and the problem with a network node is basically that Network nodes need to be sure that a transaction is costly that a transaction has some chance of being included in a block and having to pay a fee like basically regardless of what block he gets included in because otherwise you can just do weird attacks and you can spam the network with transactions that look valid but actually stands no chance of actually costing the send or anything so there's a kind of multi-part solution to this um one of them is to add this pay gas off code that basically is an explicit op code for just paying the transaction fee to whoever the block

proposer is um and we can just in in this pay gas off code we can just throw in Logic for refunding gas at the end right so the so that solves two problems at once so that basically means that instead we have this um mechanism where you can actually check for the psop code and you can make sure that whoever the block proposer is they'll get paid um Network nodes can also do some additional checks so they can basically check that a transaction will not access external state that it's not going to access the environment um that the account itself doesn't let external things access in except for sending it ether and so if you do that then you have this invariant that basically says if I see a transaction then and to me

right now it looks like that transaction is going to get in and it's going to pay fees then I know for a fact that that transaction will keep being valid and will keep paying me fees um un until or unless either that transaction or some other transaction from the same account gets included so we can add kind of some more structure and basically there's a tradeoff here right the more structure we add the more and the more structure be kind of enforce at the network level the more guarantees that we can get um and the less structure we have the more optionality there is but the more difficult it is right so strength here is that the abstraction model remains super simple there is some more complexity but it's kind of at the

network layer rather than being at the consensus layer so let's talk about one very specific use case of abstraction right mixers yay who here finds mixers more fun than looking at code okay so mixers in right so you have a smart contract and people are using it to anonymize their coins right you have a bunch of people sending coins in and then you have people providing proofs and they get their coins out and you're not supposed to tell which input corresponds to which output yay you're anonymous now let's look at reality right so this is what happens if you try to implement a mixer on ethereum let's

say I have some money and I'm going to try to mix it so I'm G to send my money into the mixer contract now how do I get it out well to get the money out I need to send a proof into the contract to send a proof into the contract I need to send a transaction to send a transaction I need to already have transaction fees that get charged in an inrun way in the protocol to do that I already need to I need to have some money H let me send myself some money oh wait I de anonymized myself so abstraction can solve this right so basically um abstra with abstraction we can just have logic that says instead of

the fee being paid through this enshrines mechanism the the mixer contract itself pays the fee after it figures out that that that the proof is legitimate and so you can do the proof checking first if it's if it's fast enough and then you do and then you pay the fee afterward um and you're all good and you and you don't have this data leak yay more privacy so um transaction IDs this is kind of the last issue right so basically notice that in the mixer use case we've kind of introduced a new way of using accounts right we've basically introduced this new use case that says instead of an account representing instead of a top level account representing a either a a

user um it's one of these top one of these accounts that get access directly from outside the system represents a multiple users and the users might want to do withdrawals in parallel and so you can't kind of enforce a common non scheme because if different users are coming in and trying to withdraw in parallel they have no I no idea which one of them is going to come first which one of them is going to come in which order so basically um because of this we can't have kind of enforced in protocol nonsense and so because of this we have this problem that it might be possible for a transaction that has the same hash to be included multiple times so here's the problem this is obviously uning

right we're kind of used to going to etherscan.io TX whatever our client gives us and just refreshing the page over and over again until we see the transaction confirmed right who here has done that so we want people to be able to keep from uh spamming an ether scan page over and over again because it's like a pretty user friendly workflow compared other things so the problem is well here one transaction might correspond to 10 different to 10 different or one transaction hash might correspond to 10 different transactions and when you send a transaction the transaction could potentially be modified in transit because we're not we're not enforcing what the signature scheme is and so you

might choose a signature scheme that lets other people modify your transaction in transit so um here's the proposal right instead of go having this transaction Centric workflow we can try to have a receipt Centric workflow and the receipt centc workflow basically says when you create a transaction the use instead of just generating the transaction hash you generate an ID or possibly a list of kind of event IDs that represent the of hash of things that you want to have happen actually happening and then it when a transaction gets executed it makes a log that and that log publishes a receipt ID and so instead of spamming ether scan for a transaction hash you

would just Spam ether scan for a receipt ID so now it just keeps on working very similarly except it works the same way even if you have one transaction included multiple times or your transaction gets modified in transit so hibernation and waking there is some some um this is the mechanism for kind of how rent in ethereum 2.0 Works um basically uh one of the one of the annoyances of a waking right is that let's suppose you have you have an account and then you receive some tokens then your account is forced to go to sleep because you haven't paid rent then while your account is asleep that same account receives more tokens

and then it pops into existence again and so you have some tokens over here and some tokens over here what am I going to do so basically to resolve this problem well we need to start thinking about either we forbid sending to accounts that don't exist yet or we have some kind of abstract notion of merging the contracts have to specify so these are just this is just kind of some of the examples of challenges that that abstraction involves but and hopefully as you can see right this is this creates a really extremely powerful set of possibilities right it basically means multi sigs can be as easy to use as single Sig accounts yay security um it means that you can finally have

mixers that work yay privacy you can have Lampard signatures yay Quantum proofness so we can have lots of I you can even have a utxo system be be built on top of this yay being more like Bitcoin so right this is the power of abstraction you can be whatever you want to be now how do we make the C fici right so basically instead of 10 lines of C or 10 to 50 whatever number of lines of code being in one place um in a piece of cons um in your client software basically all of that code ends up going into accounts and those accounts get

copied over a million times so spacewise this seems less efficient so how do we make this efficient um so this is one problem and then the other problem is interpretation efficiency is basically instead of this these pieces of code being optimized code they just become virtual machine code which might need to be interpreted and interpretation has a fact about a factor of 100 overhead so how do we solve the space efficiency and the complexity efficiency issue right so a solution that we're seriously considering for this um is this kind of make your own pre-compile approach and the make your own pre-compile approach basically relies on this idea that in for web assembly which is the VM we're

you the virtual machine we're replacing the evm with in Serenity you have you web assembly code can be executed either with an interpreter which means you can just grab any code and immediately executed or a compiler which requires a lot of pre-process processing time but once you're done compiling you can just execute that code and on average it's about 90 times faster probably actually very close to native code possibly less than a factor of two overhead over native code so here's the idea um on the beacon chain so on the proof of stake chain the central chain of the system that every user has to keep track of um you can pay one eth and if you pay one eth you have the right to push a pure W

function a pure piece of code and everyone is required to compile it and anyone in every Shard can kind of just call this like they call like they call a precompile today so this becomes just one of these special functions that you can call so now we have a way of doing libraries that's really really efficient we have a way of basically making your own precompile that's really efficient um and you can use this to store account code you can use this to store cryptographic verification code you can use this to store a whole bunch of things right so basic um basically you can just make accounts themselves just be pay points to this thing except here

is the kind of 32 bytes that actually are my particular cryptographic key and you have about as much space efficiency as he had before yay um economic abstraction so this is the kind of last thing I wanted to talk about um there's this common desire to of let people pay for transaction fees in tokens um if block proposers accept them so let's say for example you are some token issuer I don't know you even let's say you're you're trying to issue digit um Vietnamese Dong and you want to have um a and you're just sending this

sending this as an erc20 to people in their wallets and you want people to be able to send this to each other but you don't wants to also have to deal with the you user experience headaches of having to give everyone eth and forcing everyone to keep a balance of eth right so a an idea that people have brought up is this concept of kind of quote abstracting ethereum basically making the platform currency neutral and basically letting people pay fees in whatever currencies anyone accepts I would argue this is a very bad idea and it's a bad idea for a few reasons right so one of them is that it just makes dos resistance harder because you need some it basically requires some form of governance to determine kind of which

coins are actually legit which coins are actually worth something you then have to do this really ugly thing where you have the NK the peer-to-peer Network layer kind of poke into UNIS Swap and ask Unis swap what the exchange rate between your Vietnamese Dong erc20 and ethereum is so it just gets really complicated um also the platform the ethereum platform depends on the value of e specifically to ensure Pro of stake network security um finally um transaction fees that are not going to a block proposer but transaction fees that are going kind of directly to the protocol so this would include the one if you pay for Brian plows it would include the base fee for VIP 1559 it would include storage rent all these fees that don't go to anyone that just

get destroyed have to be charged in some standard currency and the pay gas approach that I talked about can't be extended to tokens easily right so we can't re I it turns out that abstracting away kind of ether as a currency introduces way more problems than it solves but how can we give people what we want anyway right so um Auto pooke mechanism so here's the idea right so first of all if we add EIP 1559 which is this wonderful transaction fee Market reform proposal that I am um that I'm going to be presenting about at at the magician meeting in a few days then you have a kind of reliable in protocol feed of what the current gas prices and so you

can tell inside of a Proto the protocol whether or not an account has enough e to send one transaction now we have a poking mechanism and a poking mechanism basically says if your account has not enough e to one transaction then you you authorize anyone just anywhere to poke the account and that just means sendy transaction targeting um that account that just basically call automatically calls Unis Swap and converts some of their tokens into ether just enough so they now have enough ether to send one transaction and whoever pokes this get a reward account abstraction makes poking really cheap because poking transactions don't need to have a signature so it's

literally just like 20 30 bytes that potentially even less that you would just throw into a block and it would just get processed right so um let me just skip over some of these more comp um the last section so basically we don't need economic abstraction because it turns out that with other kinds of abstraction that we have we can kind of really nicely get most of the same benefits that L your to so longer term ideas so this is just kind of very far off um one of the previous slides I had also talks about how you can extend abstraction so it's

not just abstracting things at the user level but it's also abstracting the aggregate signature algorithms that are used for at the Beacon chain and it turns out that that's possible in a way that we did we didn't realize initially so that's something that we might want to introduce in a few years when we wants to go Quantum proof fully um in the future possibly reduce the role of gas in the protocol so this would basically mean that if we have a protocol where State transitions just get proven through Starks through zero knowledge proofs then it doesn't really matter how complex the computation is because only one guy needs to do the computation once they do the computation they prove it everyone else verfies to

proof and so if you switch over to this Paradigm then the only real externalities are bandwidth in state storage and with rent State Storage just becomes a kind of bandwidth and so everything can be kind of measured in terms of bandwidth which is just economically really elegant um we could write some of the kind of system components so things like hibernation weaking some of these other features that we talk about in weap BL code and we can try upgrading them over time we can try giving users kind of more choice of which of these kind of extra level layer utilities they use abstracted this ler even further so there's definitely of more ways over time to try to kind of remove some of

the assumptions that we currently have inside of ethereum that reflect how ethereum is kind of supposed to be used and instead make it be this uh something much closer to this kind of General economic Computing platform where you just all of the other logic itself can just be built as these kind of programming languages in a higher levels on top and what this means is basically that it just becomes much easier to upgrade the technology without having to make kind of frequent changes to the protocol without having to rely on things like govern things like governance to decide exactly which option to use because well you can have both options on top of the same protocol

um and basically you can continue to have kind of high rates of protocol on Innovation on top of a more and more stable layer one so thank you [Applause]