Design Choices in Eth2.0

Transcript

No hey guys I'm gonna start with my presentation it's about design choices in each 2.0 and this is basically to inform smart contract developers on each one today about what changes they can expect going forward with eath - my name is Aditya and I'm a researcher at the theorem foundation so let's start with what were the design requirements of this new scalable sharded blockchain system called eath - and how you know the specific implementation achieves

this and what this means for smart contract developers so the two basic requirements are scalability and security and the specific requirements for scalability is superlinear sharding which means that the total throughput of the system is super linear with respect to the throughput of a single node so if the capacity of a node is C then the capacity of the entire system should be like more than ofc there were some like issues with this definition so I kind of changed it to this which is if the capacity of each node increases k times then the capacity of the total system

increases super linearly with K so you know K log K or K squared something like that what this means is even if what this means is basically there is no node which which that linearly affects the throughput of the system so there are no super nodes there are no sequencers there are no linearizes there is no one point where you know most of the computation in the network is happening which would manifest in this linear dependency and the second requirement is of course security and we want that the security of the system is uniform in all parts meaning all shards or all partitions or whatever parts you have

and it it should correspond to consensus safety across all nodes in the system so not just that specific shard or that specific partition but across the entire number of nodes across all parts and to achieve this goal of shouting what we do is take the entire state space and cut it up into partitions and call them different shards and we also do that with the entire validator set we form subsets of this validator set and assign them to specific shards to you know be responsible for those shards in some sense and for security we have something called the beacon chain and the beacon

chain is basically the source of of consensus safety in eath - it's the only place where consensus happens and since we had this requirement of the security of the system is uniform and is equivalent to consensus safety across all nodes if this is the only place where consensus takes place all nodes must participate in it so all notes form consensus on the cumulative state of all shards which is you know some accumulation of states so that accumulation will see whether it is just like plain you know concatenation of state or some other type of accumulation which compresses it and if you combine this fact of how the beacon chain works

with the scalability requirement of super linearity then this immediately leads to do conclusions the first is you can't the data consideration so the beacon chain can't contain the entire data of the system because if it does and everyone is validating the beacon chain then each node in the system is going to contain the entire date of the system which breaks like this super linear data throughput that we want and the other is similarly the execution consideration where if if everything in all charged all transactions from all shards get executed in the beacon chain then all nodes in the system are executing all transactions in the system and so this breaks super linear like execution throughput which is not what

we want so what we do have is the beacon chain where all call validators participate and form consensus but they do so on like a compressed accumulation of the state which are which is Merkel roots of the sharp not entire chart blocks not entire like transactions from shards only Merkel roots and as far as execution goes you don't execute anything in the beacon chain no transactions are ever like seen observed or executed inside the beacon chain and within shards you don't have any consensus because well you already found consensus in the beacon chain and there's no point to like forming consensus in the shards but since you know the beacon chain doesn't

do any other type of validation doesn't check but whether transactions are valid if like users are doing something nasty we need that shard committees validate blocks which means they verify transactions propose blocks accumulate transactions and propose blocks stuff like that and well if you aren't following consensus and charts then how does a shard chain growth so what we do is sample validators from the entire validator set and assign them to specific shards and instead of forming consensus in charge they just vote on blocks so it's not a like consensus algorithm as such it's just voting and if you have a some sort of a majority

then that block is considered like good and is included in the beacon chain so roughly it looks something like this so you have all validators on this top left corner you sample them get a shard committee which is responsible for Wixom shard then that shard committee does two-thirds voting on blocks in that chart you get a shard block that block is good then you cross link this block in the beacon chain which means the block is like included in the merkel druids the mercury rules of the shard blocks are included in the beacon chain and then all validators form consensus on it so as you can see no consensus in

short blocks no execution in beacon chain execution in short chains and consensus only in bacon chain so that's that's roughly the design the point of this is showing you I mean okay how many smart contact developers in this room and how many each two researchers are like blockchain researchers in general okay cool so the point of this is showing you roughly how the system works and what this would mean for smart contact developers and why we can't provide certain things that you would expect that you see in each one so there are certain changes to the developer experience for example static state

access this is something that the quill team talked about yesterday but I will elaborate on it later and there are so these are just new changes to the developer experience and there are some things that were possible in each one that probably won't be possible in each to something like synchronous calls to any other contract in the system so think about contracts in one shard time to talk to contracts and some other shard in some other part of the system conceptually this means like you have a big network you have partitions in the network the partition the partitions are in some sense disjoint although like they have some point of coordination which is the beacon chain but like intuitively since there is no

execution in the beacon chain it's kind of hard for synchronous calls to happen through the central point of coordination so though these are hard to do and I'll depict why so first actually let's let's dig into a static state access oh it's Sinclair okay it's big into a synchronous cross short transactions so the basic problem is if you send some like transaction from chart a into short B what you want is transaction is included in shard a block then shard B validators or block proposers see that there is a transaction that's incoming and then they apply it and and then do whatever they have to do the basic problem is how

do you make the other validators on the receiving shard aware that there is something that they should look at because what we said initially was in order get scalability we separate committees of validators and they are responsible for entirely different shots so validators from chart B are not supposed to look into data from charity so there is one like cheap hack that we can do just put these transactions into the beacon chain what that achieves is since all validators are part of the beacon chain so everyone on sharda and everyone on short B is always a part of the beacon chain they can always refer to it as like the coordination point and if

you include these cross shard transactions into the beacon chain then well everyone is aware of it and you don't have to worry about this problem of you know how to make it available to the receiving shard so it seems like it's kind of impossible without including more information than only Merkel rules as we do right now in the beacon chain so you would have to include like the entire image of that transaction not just Merkel routes because Merkel routes don't tell you what the transaction is and basically this breaks super linearity right because now you're putting plain old data into the beacon chain not Merkel routes which means everyone like bears the entire burden of that data which is

not good for super linearity so that's that's like the basic problem with cross card transactions static state access this is something that probably might not be aware of so I'm sure you guys know what stateless execution is so nodes in the network don't hold any state state storage is probably the biggest pain point of e-m1 so a theorem 2 and 1 point X is moving forward with stateless execution where each transaction provides the state that it needs so all the data that you need to execute transactions is provided in the transaction itself just like think of it

as like what light plants do when whenever they see something they want to execute they ask for the data so nodes in the network don't need to be aware of any other data except the state rule they only need the state route to execute transactions by verifying witnesses to the data of the transaction so the transactions must include witness data for all parts of the state that they access so now the it introduces some problems and let me depict some situation that might occur so this is not static state access this is dynamic state access and I will show you what it means so you have this transaction one

here and you have some stuff going on there then you have this instruction which loads a pointer from an address in memory in storage so you do s load address and assign it to this variable called pointer and then your actual data is at the location at the memory location of the pointer so first you load the pointer from from storage and then you load the data from storage from the address of the pointer so if that's the transaction the witness data should be the the the myrtle branch which links the state route to the storage location at addr which is the pointer and it must

also provide the merkel branch to the store the storage location at pointer which contains the data that you want to load so you have this one such transaction which you submit and what happens next is you have this other transaction transaction to which updates updates what what exists at memory location addr so the pointer that you were trying to load from memory has now load from storage has now changed which means that the address from which you'll be loading your data is going to change which means that oh so this is this is all if transaction 2 is included before transaction 1 so if

if the the storage at at slot addr changes it gives you a new pointer then you have to then the data that you are trying to access is from a different location basically your witness is invalid because it is it doesn't have a Merkel branch to the new pointer so transaction two is updating the pointer that you are accessing and since that's up your witnesses don't contain this storage location and so now block producers have this big dilemma of how to alter transactions and it's super inefficient to you know go through each and every transaction and find out like

what order works what order doesn't if something you know doesn't work then fetch new witnesses from users or other parts of the network so this is very inefficient so what static state access does is you you let transactions only touch predictable locations in the storage this means that block producers can easily update witnesses without fetching data from the network so ideally what would happen is block producers infer this new witness branch from previous transactions that they have seen so if a certain transaction touches a state that you were Austerlitz law that you were

trying to access and it's in the previous block your transaction is included in the next block block producer looks at the previous block says oh there's a transaction that updates whatever you are trying to access and I know the post state for that so I'll just use that instead so I don't need to fetch anything from the network I'll just use that so this this kind of gives us a lot of efficiency gains block producers don't have to you know do as much work so these are like some of the changes that you can expect and as the quilt team demonstrated yesterday there's there's a few things that uses start dynamic state access today so the point of this talk is that the primary objective of each two is

producing a scalable and secure blockchain system and it's only a secondary objective to you know produce execution behavior that is that each one devs are familiar with that is not the main point of eath to yeah and don't freak out this is okay you'll be all right it's not that bad and the model of the story is there is no other blockchain that provides the same strong security guarantees and super linear scalability that offers like synchronous crosshair transactions or dynamic state access for example and this is actually a point of contention so I'm going to give you a trigger

warning these are my opinions there is no other blockchain that I know of that provides the same strong security guarantees and super linear scalability which offers these things such as synchronous crosshair transactions as the end of my talk thank you reach out to me on Twitter at at the rate ID asked if you have any questions and I'm open for questions for the rest of my time [Applause] we can adjourn if you don't have any questions that's fine yeah sure that

works