Ethereum 1.x: On blockchain interop and scaling

Transcript

[Music] so welcome to uh day day number number four of death card we use zero in here we're a civilized company um yeah no the first day was Day Zero so the so so so today we're going to be talking about scaling and interoperability and well today in general we're going to be talking about ethereum 1.1 and ethereum 2.0 and uh and the general blockchain protocol related

stuff so first presentation we have is on scaling and interoperability so I guess to start off first of all what is you know what what is scale what what is scalability what do we want out of scalability sure so in an ordinary blockchain like how every node processes every trans transaction and updates every full node anyways processes every transaction and so uh the scalability system is kind of limited by the fact that every no needs to do everything uh so what we want to do is relax that assumption but still have the properties of consensus uh like you know non- repudiation like Source authentification of contract calls Etc uh and so scalability Solutions are kind of trying

to make it so that not every node process is every transaction but that we still have Security in some way so you know you know right now with uh just for for statistics right now Bitcoin we you know one transaction per second MasterCard processes 2,000 transactions a second if Bitcoin goes up to that level then we'll basically have full nodes processing 1 Gigabyte every 3 seconds so you know not ex not exactly sustainable for any kind of normal computer so we'll have 10 full nodes yeah 10 full 10 full nodes uh and they'll probably won't be run by blockchain that info and coinbase they'll be run by Amazon and Google who you know people seem to consider as

being more evil than than good local companies so yeah what we want is we want a we basically want a system that work we we you know as Dominique Williams from Pebble put it we want a system that works by scaling out and not by scaling up so instead of making these big instead of making the system continue working by having full noes be more and more powerful you figure out some way for it to work even if no single node processes more than a small small portion of all the transactions another way you see that is instead of just stacking blocks on top of themselves in one chain we we hope to maybe have like another architecture or not all blocks go in the same chain so so right now what we have as far as scalability goes is the scale up

approach which is you know we have like we say okay the blockchain is going to grow a really big but we're going to make sure that like lines can still be secure and that kind of works until of course it gets way until of course the whole thing just gets way too big and and it might not and there might not even be like it it might not even be possible for a single node to process all crypto transactions that people potentially might want to do especially if we start thinking about crypto not just as a payment system but also for a whole bunch of these DBS and also for like you know not just people but also for programs and Hardware um so there's basically three broad classes of scalability approaches there's building on top uh kind of

scaling one chain uh by sharting the state space and having multiple cons multiple blockchains and interfacing them to gain some of the properties of one blockchain so we're just going to kind of go through them and talk about kind of the state of the of research on those topics and what the tradeoffs are and maybe what the disadvantages and advantages of each approaches so start scaling on top to you want take it away so build the idea with building on top is basically you know keep the blockchain exactly as it is but we try and figure out some ways for as much stuff as possible to happen off the chain but still be secured by the chain in the long term in some fashion so this is one the the one sort

of the first practical example is uh this well I guess micro payment channels is actually one that you don't even need ethereum for you can do it on Blown Bitcoin and uh the way that works is you there's a sort of special two-party protocol that you can do use to create a sort of it's called a micro payment Channel going from a Tob and the idea is there's sort of two there's a two-party protocol for updating the channel so the channel starts off containing some quantity of some quantity of Bitcoin let's let's say 1 BTC and it and a initiates the channel it starts off with a you know a puts a Bitcoin into the channel channel starts off giving the entire Bitcoin back to AEG and then there's a sort of off offchain update protocol where the channel updates the say 99 to 8.01 to be 98 to 8.02 to be

and so forth and the idea is you have a network with a bunch of these channels and if you want to make a payment you just sort of find a path going through all the channels update all the channels along the way and you use the blockchain only for like eventual settlement when a channel fills up probabilistic payments yeah so probabilistic payments basically work by okay say for example for a CL storing application instead of pay making a payment on the Block chain for every file transfer that you do like every upload or every download what you do is make a payment with provably with some probability so that uh the people still have the same expected re return from sharing those files but you don't put as many things in the blockchain kind of

the isue with that is that increases volatility of the return but over time it should kind of be the same and there's much less stuff in the blockchain and just as a so that's so those two approaches work for payments um a third there's also a third category which is this idea of offchain auditable challenge response computation so just as an example of that there's in in some cases there's going to be a lot of computations that need to have the security of the blockchain but which which might be too expensive to do on the Block on the blockchain itself so what and so the property here is the so the data the data involved in the computation doesn't is not necessarily too large but the computations are very

large so zero knowledge proofs one example so something like you know verifying verifying skip takes 6 millisecs inside inside of C or C++ might end up taking you know 60 Mills inside the ethereum J jit VM another exam truth coin is actually another really good example because what they need to do is they Bas truth coin is like this decentralized Oracle that like does sort of shelling coin like stuff but for many bets at many decisions at the same time and the way it works is you actually is that it uses these Ma algorithms to try and figure out who sort of which voters are more sort of globally compliant with the entire consensus so they can reward them more in order to and doing that Matrix math

as you know takes uh o of En cubed operations which you know for fair large matrices is pretty expensive Yeah so basically the idea there is that the blockchain ACT has a something for punishing these oracles if they uh don't come up with the right result then you can basically check it on blockchain and like remove a security deposit from them uh and if they do then you don't need to do anything and and the computation happened off chain so basically on chain everyone does everything and so you don't you only really need that for when things go wrong that's kind of the Paradigm there yeah so by so it's sort of by default by default you trust but you have some period during which anyone can challenge if someone Audits and they find something wrong they can sort of pull the computation down on the

blockchain and if that ends up being wrong security deposit was lost cool yeah so we're going to move to um sharting sure so sharting sure so uh one idea for blockchain scaling is to take kind of one blockchain and take this state space and split it up into subspaces uh still have the same digital asset on all the subspaces and have a protocol for moving funds and doing contract calls between the subspaces as well as a protocol for making sure that all subspaces have enough nodes in order to not introduce any bti state transitions so the general sort of intuition is that if you you could have [Applause]

make a new pad so the to is you have you have a bunch of a bunch of sort of substates you can think of them as being vertices and they're arranged in this in this some kind of you know dense graph structure so you know we talked we talked a bit about graphs yesterday but and uh then you have a sort of a sort of header chain in the middle and so the idea is is that you as if you are a miner on this kind of system what you're actually doing is you're mining an edge so so when you mine an edge what you what it means is is that you can process transactions that happen inside of here you're processing transactions that happen inside of here and you're also processing the movement of messages going from here to here and from here to

here so let's say if you have a sort of multi-chain dap or if you that that has some state in this in this little sector and some state in this little sector then it sends Alpha message and the message gets stored in in the outbox here eventually someone mins this Edge when someone mines this Edge it gets kicked out of the outbox here it gets moved to the outbox here when it this Edge it gets moved from the out box here the out box here and eventually sort of makes its way over here and then for the header chain here the idea is that basically all of these sort of Mind edges all make their way into the header chain and the header chain just sort of maintains the global order of what or order of the of the entire thing just by keeping track of all the headers yeah

and so the reason that the header chain is really important for this type of Architecture is that because everyone uses the same digital asset uh if you were to have say one of these uh one of these substates not really coordinated with the other ones you can have one substate that has much lower security than the other ones and then you would basically by introducing a qualy state transition in that substate uh impact all the other ones because they're all using the same digital asset so uh the the fact that everyone shares some piece of consensus is important because that's what you use to make sure that kind of all your checks to make sure that you don't have insecure substates uh occurs right yes so we call this kind of like the fragility problem if something goes

wrong in one substate and not every node is processing everything so for any given noes perspective you'll never know 100% that something didn't go wrong in one of the substates that you didn't process yes what you can do is kind of challenge response protocols right so that's the first approach so the idea behind challenge response protocols is that if you think about a block a block you have a header then you have you know some set of transactions and then you have a state tree over here then there's some subset there's going to be some subset State nodes that the block ended up ended up modifying while while processing or processing each one of these transactions so what you realize is that if a block is invalid then what that means is first of all you know it could be just be that the block

is badly formatted which is just very obvious to detect but it could also mean that one of these transactions at some point has has some State transition that's invalid and so the idea is that if an attacker makes or if an attacker makes some kind of a makes a block on one chain and that block and that block is invalid so first of all if the block is actually invalid then what you can do what the some good guys can do is they can Pro they can basically provide a miracle tree proof of the exact set of changes that transaction was supposed to make and people can re can see that the changes that the attacker made are not the same as the as the changes that the attacker was supposed to make now the other problem of course is well what if the what if the attacker just publishes

a block but does not publish all of the data so that's going to be it's going to be very very obvious to people on that chain but the problem is if the data is not there then there's no way to come up with a with a with a direct proof that it's invalid because there's just sort of no data like theoretically you know theoretically if Bill if Bill Gates turn out to give the to be generous and give the attacker $100 million there could theoretically be something legitimate that happens to give the attacker $100 million but if the attack doesn't Supply the data then there's sort of no way to know so that's where challenge response comes in yeah and so the idea be that if you issue a challenge of some particular State transition and the response is never provided that you kind of would

assume that that state transition is uh not valid yeah but kind of the issue with that is that uh you basically require people to be giving these challenges and looking looking for where uh where it went wrong but if there's no cheating then there's no incentive to do that uh so kind of an ends up being that there's a non-zero amount of invalid State transitions that's one problem the other problem is this sort of fragility issue which is that if an attacker DSes the network then the default default state is is for blocks to get processed and therefore know blocks might end up might end up Surviving whatever the entire challenge period is without without getting challenged even if

there's actually something wrong with and then if you have an invalid transition that's only discovered much later then the effects of that transition could have propagated to many many things and you know we might have to roll back like 100,000 blocks if you want to uh kind of fix that uh and so that's kind of like bad yeah so somewhat the somewhat more stable algorithm for dealing with this problem is this jury selection approach so idea behind jury selection is that let's say that okay I mind this Edge then what the header CH so then what the protocol says is okay from every from from randomly from all of these all these little substates together I'm going to randomly select you know 200 noes Bas B weighted by stake so this is a proof of stake

mechanism there's actually no way to translate it into a proof of work Paradigm which which is actually by the way another reason why proof of stake is superior but so the idea is you weighted by Stak you randomly choose some 200 nodes and th and those two and basically a majority of those 200 nodes have to sign on the ass sign for the blocks validity and the way that the and the way that those 200 nodes know if the block is valid because you know there might be a node from here and that and that node might not be keeping track of the state at all the way you do that is that the voter provides the block you know with the state route transactions but you know right now in ethereum when over the network the thing that gets sent is block header plus transactions

but here the thing that's going to get plus the whatever subset of the state ends up being manipulated during that block and then this whole chunk by itself can be Val can be validated even by someone who has no prior information at all yeah and kind of theoretically that has like no cheating in the National room because it's basically like foring a challenge response on every block kind of yeah so like the idea is you have in order in order for an attacker to be able to successfully cheat on this thing just purely by statistics the attacker has to have something like you know 30 or 40% of the entire the entire active stake in the network so you have sort of the benefit of you know only 200 nodes validating each block but without the cost of their only being sort of 200 nodes protecting

the system because every node is like statistically protecting the system even though it's not actually protecting each and every time yeah so we have like a probabilistic rather than deterministic guarantee but it's still quite good because you can increase the number of nodes required and that will make the amount of stake required to to attack it lar basically the probability of that things growing up is like is negatively exponential in in the number of nodes involved yeah yeah so that's one of so that's the sort of so the last thing was the hybrid ke approach which is need a protocol for growing and drinking the thing so you know you could fix you could just fix it to 12 dimensions and say okay there's 496

substates but the problem is that you know what have first of all initially that 496 is might might be way too sparse but and then eventually it might end up not being enough and so you need one thing that needs to be figured out is some kind of mechanism for growing the graph so one option is to just you know if it gets big enough then eventually you add a dimension so then if you're if you just sort of keep on adding Dimensions the choice that you have is first of all when you add a new dimension do you just do you make the new cubes empty by default and sort of just use inceptive mechanisms to to to try and subsidize new people being on those cubes instead of on other or on those vertices instead of on other vertices or you could wait for the each

each substate to have twice as many nodes as necessary and split each one into two and basically uh add another dimension to the hyper he yeah yeah so the choice is you know do you start a one empty or do you actually try and split them in half um problem with split so splitting them in half feels more elegant and automatic in some respects the problem with it is that you might have daps that you know were very tightly connected but now they're suddenly much less connected and so their gas costs suddenly go way way up which is kind of annoying for if you're if the because the contracts are kind of stupid autonomous agents and might they have no way of you know figuring out how to deal with the problem cool so we're going to move to multichain Sol so the idea with

multi-chain scaling Solutions is that instead of taking kind of one consensus group with one digal asset and trying to split it without losing the properties of it what we do is we take many consensus groups with many different assets and trying to interoperate them in order to gain some of the properties of scalability um so basically there's different types of interoperability you can have this type of interoperability called uh Atomic interoperability um which is basically uh based on this tier Nolan primitive um which is this a really cool idea where oh no um You' basically make a contract on one of the chains that says if uh X such

that the hash of X is equal to some y that's in the contract is provided uh then you would do something and then otherwise if some time pass time passes uh then do something else so the idea is that um so if Alice and Bob want to exchange tokens between two blockchains uh and they kind of know each other and they know that they want to do this uh but they don't trust each other so much that like you could you would just send Al would just send Bob tokens on her chain and then kind of

trust that Bob would send her back tokens on the other chain uh this kind of forces either both trades to go through uh or neither so the way it works is basically Alex will make a contract that says if the pre-image of some hash is provided then send money to Bob uh and she she makes that hash so she knows the preimage otherwise if some amount of time passes it'll send the money back to myself and then Bob will see this contract and make another contract on Bob's chain chain B uh and do use the same hash he do another pre-image send money to Alice if if that pre is is provided and otherwise uh it'll send money back to B so basically what will happen is if Alex wants a trade to go through she'll provide the

pre-image of the hash and to take her funds on B chain and then Bob will therefore have the pre-image of the hash and be able to take his funds on Alys chain so basically without having to either of the consensus groups know do kind of any svb proof so the other consensus groups uh we were were're able to to do kind of functionality that will only happen on one if it happens on the other by using this kind of common secret uh that if it is provided some functionality in the contract is unlocked so this type of interoperability is called Atomic interoperability so the other kind of interoperability is uh is uh the protocol level interoperability so the

difference is with atomical level interoperability the things that you're trying to do is just trying to like mediate sort of cross Gene interactions between users so decentralized exchange is one example or potentially like cross chain operations where something happens on this chain only if something happens on that chain a protocol level interrupt is where you would have some kind of Proto some kind of dab or some kind of protocol that actually on one chain that actually needs to get services from the from the other from the other chain as as a protocol on the whole so one example just uh one example of that is uh let's say that you would have some let's say that you have some kind of you know you have ethereum on ethereum you

have a contract and then that and that contract tries is basically is a stable coin and it tries you know uses some the sort of contract for difference interest whatever interest rate target mechanism to try and keep a keep a dollar value of one problem is it has no idea what the exchange rate of a dollar to you know any to whatever to its volatile coin is so what it does is first of all would maintain an internal decentralized Exchange to figure out the exchange rate of it its own volatile coin to Ether and then you need the exchange rate of ether to the US dollar but because let's but the situation is let's say that you over here you have truth coin and Truth coin just happens to be a decentralized Oracle because it's the decentralized

Oracle Network and it has you know a much larger set a much larger set of users to to vote so it has more more security so this little this app over here might want to ask truth coin what is the price of what is the price of ether us and the idea is that this chain needs to have a way of sort of directly asking this chain some question so the way that you generally do that is you would have you would have the ethereum here maintain basically a white actually maintain internally inside the chain a light client of Truth coin and then in truth coin you would have in truth coin you would have some active you know set some active set set of Voters that are

vote that are just Contin ously voting on on the question of you know what's the what's the value of ether and dollars then if the truth coin blockchain records some particular result then a light client protocol of the a light client Pro the light client protocol can determine what the result is so the result would be stored in the state tree and then basically the the like line protocol would ask some node to provide a Merle tree proof of you know what is the value of a dollar and uh this and this Merle tree uh ins of transaction data the like client protocol would reward whoever provides the proof and then that's how it would know what the value of you know ether ether tover is and then the other thing that you can do is is that based on

based on Who provided the who set the transaction or rather based on uh so the other thing you can do is you can also peek into the truth coin blockchain and you can determine who contributed to this particular vote and then you can give them ethereum assets inside of ethereum so you sort of you're just you're sort of buying service is from truth coin users inside of ethereum and you're also and you're getting back this truthful feed of what the result is and then given the results the daap would be able to do whatever it needs to do with the price of the dollar so that's kind of an example of um so that's kind of an example of subprotocol level interoperability where

you would build in an ethereum contract an SPV client of some other chain so that people on ethereum will be able to know some facts about people on another chain but if you wanted to have chains actually share security you would need to build that in on the protocol level where not just kind of NOS who know what these subcontracts are doing would know what it is but the actual consensus level protocol would know so the idea uh with protocol level security sharing is that uh you would you would build the consensus of another another chain into your own Chain's consensus so that you could for example buy checkpoints buy time stamps buy uh you you you could use another chain of services in order to well so the general idea with sharing security I think is more is more that

let's say you have 10 chains chain C1 through C10 you know each each one of those chains has 500 has 500 users and 500 millions of capital the problem is how do you make each if you just do this multichain approach by default if you you know if the whole thing has $5 billion of capital then or if the whole system has $5 billion of capital then if you have more applications if you go from 10 to then each of them is down to $50 million of capital each of them is down to $50 million worth of security and so forth so problem is how do you have chains that are only processed by a few that are only processed by relatively few nodes without having this problem that each chain only has a small amount of security right but also so one thing that we haven't mentioned yet with

one of the benefits of multichain scaling is that um if a chain is compromised it won't necessarily affect other chains as much uh so and you can provide chains at services on chains at a given level of security which means that like lower cost to some users who don't need as much Security on that chain uh so what you can't if you want to provide at a lower cost and still have high security what you can do is basically buy security from other chains um and so and to do that you would basically need to interoperate your chain with other chain at the protocol level and basically have uh kind of like clients and full clients agree that they'll use some checkpoint on some other chain in order to authenticate the point on the um well the general so

challenge response toy selection we already we already discussed those in the context of hypercube um in the context of of multichain actually well challenge response in my opinion does not nearly as go as jury selection we'll probably talk more about how jury selection Works in multichain so the idea is you would have a big a chain and then on that chain you would have so you would have this kind of you know shelling coin consensus thing and you would have and you have a and you have a bunch of users that have some that you know that participate in it and by participating we basically just mean having a security deposit on here then you have some you know some chain X and that chain X wants to wants to leverage this little contract for its security because X isn't big enough by itself so

what it would do is basically this is this consensus contract it's kind of like truth coin it's this decentralized sort of shelling coin massively multi- shelling coin type Oracle except the thing that it's voting on is it's voting on the first oh so what it provides is it provides a block and the block provides you know State it's got a state route it's got transactions and it's also got a time stamp and it's and from the transaction tree you know it's got a meracle tree here and it's got a Merle tree here so the question that this thing is voting on is uh it'll take it'll take the and of three things number one is the does the

time does the time stamp on the Block equal to the actual time number and um number two is uh number two is that available so by is that available do we mean if you descend from numerical route is is there data floating around somewhere in the network corresponding to all of the all of the leaves of this going all the way down on the bottom level so the the idea is that this big this big thing uses votes on on this statement is did the block come at the right at the time that it said that it came at and is and does the block have that available and so then what you have is you would

have you would have a trustworthy a trustworthy source of blocks that have data available and that came at a particular time now given that if you assume that that mechanism is trustworthy then it turn Z consensus becomes trivial because your consensus algorithm basically is that if you imagine blocks that are at some particular height your algorithm is a block at a block at a particular height is only valid if it is the first block at if it is the first valid block at that height so you know if it's over here and then some new one comes along this one automatically gets rejected even if it eventually grows longer and the way that you defend that is you well the way that you deter the way you sort of make this work is that first of all

you know that so the way you determine the time is by checking the Oracle to see if in a time stamp M if to see what the time stamp is the way that you the way that you determine validity is first of all if the data is not available then you say it's invalid now it could be that the data is available but the block is invalid but then because the data is available anyone can audit the block and anyone can come up with a oral Tre proof that it's invalid if it if it is invalid and so this is kind of like full client security this does like all of the security needs of a blockchain right one thing to not is that full clients and light clients have different amount of information that they can use to authenticate different things and so that you could if you have security for

full clients but not for light clients then you can do something kind of much less than this in order to help the like clients find the authentic chain um so basically uh one thing that's important for multi- Chain Solutions in my view and uh this is kind of like my vision for ethereum 2.0 is that we would have like one like client protocol at least for all of these chains so that a single light CLI can access services from all these chains and so for example if we had uh if if we have some chain that's kind of secure as far as all the full clients are concerned but the light clients can't tell whether some Fork came later or not because there's no cryptographic proof of that uh what you what you could do is basically have the

people on this chain whenever there's a fork or every so often buy a checkpoint from a shelling coin game on another chain which would basically instead of going on this walk and checking the time stamp it would it would basically just ask you know what is the consensus block a thousand blocks ago because you know that's kind of longer than the fork length and so basically it and then and then like clients who are on who somehow manag to get on here can find a checkpoint on this one which you can then use to authenticate the current state there so uh in in this kind of model we can make like a a a tree of checkpoints so that like clients who only has one or a handful of checkpoints could U authenticate the current state of of other chains um and even though if

those chains are secure for full clients just by themselves yes so yes the point is here is there's a bit of a trade-off between to what extent you support white clients and what level of standardization do you want so the nice thing about this kind of data availability protocol is that here you here you actually need to standardize almost nothing for all these chains to share security the only thing that you need to standardize is the Merle tree protocol because you need you need to have a way of voting on data availability everything else is potentially completely open like this this might you know this you're not standardizing whether you're using proof of work or proof of State you're not standardizing whether it's uh whether you're using ghost or or some other mechanism you're not standardizing any

kind of state transition rule but if he wants to go into supporting you know more more sort of like Clin functionality then you might need to end up standardizing more things like checkpoints yeah so for example if uh if you wanted like kind of ultimate like client functionality uh what you would do is have all of the chains be evm and have the consensus algorithm be embedded in evm code so that all the like lines can just use dbm to authenticate the St State Transitions and to authenticate kind of anything that they need uh and basically that makes their code base smaller than say if they had to interoperate between chains that have different protocols right you had a like client to interoperate you know Bitcoin and some other chain who P that services from both it will need more code than if Bitcoin with VM because then it would

just could kind of use the same code base to authenticate transitions on both chains so the more you standardize the more lifetime friendly you can be um we already yeah yeah so I guess the so the last points here are first of all this idea of checkpointing and so the question is uh in this multi in in this multi-chain context can we come up with some kind of light client protocol that allows proof of stake clients to still be secure or to still securely determine the state of sub the current state of sub particular chain ideally with a very low amount of information yeah um so something else that we haven't talked about yet is

uh so uh like one one cool idea is uh is that you might be able to use not the checkpoint between the chains at the protocol level uh to to to satisfy the to do the light client protocol but actually uh the the interface chain that's on top actually have we talk about no so basically if we want to do atomic interoperability between two chains so basically those two chains have the Cher noing uh primitive uh what you can do is you can make a third consensus that consensus group that includes is basically a side chain for both of those consensus groups and that can be used to pair up different people who want to do interoperability using this tyal imperitive and so one I'm basically thinking and hoping that we

can use the exchange here to help like clients figure out uh where to go because light clients are going to in a multi-chain context will probably not keep their tokens on all all of these chains you keep your tokens on a small number of chains which are more liquid more stable and then you kind of sell them for the tokens that you need in order to purchase services from some chain um and you have to go through an exchange to do that anyway so you need to authenticate that exchange and so then you might be able to use that exchange which isn't even on the protocol level in order to authenticate which Fork on these chains to choose as a light clim um so basically if we build proo if we build an interoperability kind of on top using Atomic Atomic uh inter cability it's less fragile than if

you were to extend one of these consensuses to include the other one because if this chain died in this case it wouldn't affect this chain this chain doesn't know about this chain it just knows about some tyan contracts that it has on itself and it doesn't know what that what chain that's interoperating with but if this Chain's consensus was actually extended to that Chain's consensus and this chain died this chain would now have to switch from buying services from this chain to buying services from another chain which is kind of a whole other problem um one way to handle that that I've kind of thought of is um if if you don't have contract creation on kind of evm chain and all the contracts are in the Genesis block then two chains with exactly the same contracts in the Genesis block um are going to be providing the same service

and so you would be able to switch from asking a for service from that chain to another chain that's has the same contracts um kind of another Paradigm with this multi- chain stuff is that instead of having kind of ethereum like general purpose chains you'd have ethereum like application specific chains where basically only some contracts would be there you wouldn't be able to create contracts uh and the idea with the application specific change is that basically you know if you know that your application doesn't need any more interoperability with anything else then you could have consensus groups just around those contracts and you don't need to have the same consensus group do all these other contracts um yeah yeah I think that's basically all that we wanted to discuss so questions yeah

yes camera sorry hold that thought thank you for understand okay so in the very important special case where the state is just a bunch of account balances uh there's a common and very old idea to uh for scalability is that instead of atomic uh transactions which take you know some value from here and uh credit some other

account you split these transactions into two into a debit and a credit transaction and whatever service needs need needs providing in exchange for this transfer you make it only conditional on the debit transaction and then you settle the the debit transaction the credit transactions later when you have time and this way you can do interoperability between different chains because on one chain you if if you compartmentalize by accounts then you can basically generate debit transactions as fast as you need to and then you can you can do the deits and the genius one of the genius ideas of

Bitcoin which I think didn't receive as much attention is that what they did is that they put together the credit and the debit but the other way around so it's not Atomic in the sense that the something is taken from here and deposited there but the other way around that they notic that uh you know you don't need the you don't need the credit transaction before you actually want to spend that amount so what a Bitcoin transaction actually does is that it deposits the amount and immediately takes it away so uh they don't even have the explicit balance state so in the Bitcoin

Network you don't have in the state you don't have the excit balance and I think that in in ethereum since the balances are part of this state maybe we should consider you know splitting up transactions that modify more than one variable in particular in case of transfers they modify two Balan is to to split them up into two transactions and make one transaction conditional on the balance and make the other transaction condition on the success of the first transaction so so that that is kind of what the atomic protocol does it basically makes sure that one transaction can only go through if the other one can go through but it does it without requiring any information from one consensus group in the other

consensus group except for the prage of hash which is kind of more light weight than having this chain check if some transaction went through on the other chain because all you need to know is whether or not some something the has is provided oh but that's interactive but here you can carry the proof with you so basically if you have a successful deposit uh a successful uh successful uh debit on one chain uh if if if it gets confirmed it's a finite package of information that you can carry away and you can present it at that chain and it gets deposited without so so that's either a subprotocol level or a protocol level thing that's more that's more likely sort of chain scale charting type approach but you can do that also by

extending consensus in between between chains yeah you could but yeah so but it fits more in the sort of single chain Paradigm yeah so that's a yeah it's a sharting approach it has I guess similar similar properties Ty of sharting approaches the main the main issue of course is that what if you have what if you have a de what if you have a debit somewhere and then you try and use that as as a proof to generate a credit twice or or know what if you what if helpable spending and so forth but that's a local thing right so if you want if you want to debit twice using the same you want to credit twice using the same debit transactions the you know

the debits of that Target account they're on that chain so you prevent double deposits and there you prevent double withdrawals instead of you know globally globally preventing double double spans you prevent double withdrawals and double so what if I what if on some local chain I I make a withdrawal and then I immediately double span that withdrawal locally well for sorry we we haven't even talked about for in so Forks always basically lead to you having to wait for interoperability functionality um because you know anything can be roll back in a for yeah um so that's why non having non for chains of would really help

interoperability Solutions and blockchain scaling Solutions um one thing I haven't mentioned yet which I really like to mention is this idea that uh one of the things that I find really helpful for thinking about uh blockchain scaling is that it's so the client is serving the user and the client uses chains to serve the user it's not that the client is serving the chain and so uh if a user has a consensus grp here I think they would prefer to not have SPV proof so some other consensus group they're not interested in be ejected into their consensus and and that's kind of why I prefer this idea of um Atomic level kind of interoperability on top rather than interoperability in protocol because it

kind of lets the client have more specific narrow consensus that it's keeping uh and it it is kind of more restricted there's less you can do if you don't have this kind of uh proof of information about what happened in other chains but the Insight is basically that clients can get SV proofs from both chains without having to get them from one chain right um so any any client that's looking at both chains will know whether something might thre on the other chain but that doesn't mean that you necessarily need to force every client that's on one chain to know about what happened on the other chain um so the the ide's inter interoperability kind of interface chain that know about both chains is that those clients that

are watching for both chains can form their own consensus group in order to inter operate these two chains without actually injecting information from the consensuses into other consensuses which I kind of regard as inconsiderate unless it's necessary um I haven't found many people to agree with me on that though in particular in light of the kind of like you know block stream two-way pegging stuff which we haven't talked about yet y um that I is it the side chain discussion supposed to be later oh okay how do you see the upgrade or migration path from ethereum 1.0 to 2.0 specifically in regards to original blockchain and so etherum two so from 1.0 to 1.1 first of all 1.1 is just

going to introduce some moderate things like grou of stake and event trees for that the approach is to have a uh is to have a sort of uh mechanism of of voting on voting on protocol upgrades so if you so it's not going to be a minor based that ISM because it's not because you know it's not it's going to be in minor interest to keep proof of work forever but something you know stakeholder driven where if you have your coins in a contract that has some a state at some par A Storage at some particular key correspond to some particular value then you're vote basically voting for you know the vertical to get upgraded and once there's some majority in favor of an upgrade then the idea is that that the original chain was sort of suicide after

some particular amount of time so all blocks after block number say 1.3 million will just be invalid and the new and then clients would have time to download a new client and that new client would support the new chain in some fashion and so that would work for ethereum going from 1.0 to 1.1 and 2.0 if we're using sharting yes but if we're using multichain in if we're using multi-chain intop then ethereum 1.1 will be etherum 2.0 the only difference between 1 one and 2.0 will be just a set of tools for yeah and also kind of like client protocol or full client protocol that you uh you know uh Serve All These Chains or buy services from all these chains so then basically you know that's the direction that we're going then ethereum 2.0 is kind of an interface layer between all these blockchains kind

of imagine you know if the if the Miss browser let you buy services from a whole host of chains uh where most of those chains are actually application specific as in you know specific sum out um rather than being this kind of general purpose where you kind of put everything yes um is the uh chain sharting and the atomic um is that Atomic multi- chain um are are those are those two um they're sort of competing approaches I would say can can you could you have both yes you could could you have the sh sharded chain and then use this for

yeah a as an interupt thing yes you could okay yeah um yeah and I think that that well would be a good idea because uh if clients are going to want to keep their digital Assets in some stable token then we're probably going to want uh them to be able do a lot of transactions on the Chain where they hold their tokens right if we want if you want to have a a stable currency across the entire system the other approach is that we don't necessarily need the units to be actually be transferable we just need a whole bunch of a whole bunch of stable coins and we need to keep make the stable coins all target the same standard and then they'll just be an exchange it'll be a floating exchange rate but the floating exchange rate will

just always happen to be one but then like some we kind of have have any more stable than those yeah and so people will tend to keep their money on those right true yeah because most like clients don't want to be exposed to speculating on the success of some do they just want to be using it uh and so they can another nice thing about EIC that we have mention is that you could pay for a contract call or some functionality on another chain using fees on one chain so basically you know someone would see that you want to call some contract and they'd be like yeah okay I want tokens on the chain that you're paying me on and then they' draun the contract for you and exchange for those tokens so you might not actually need to change to buy tokens on some daps chain

or if you use the D you could just pay for it on your chain and have the contract happen on the da chain which is kind of neat can people running CH provid that service for you basic they would have to interact on your chain as um they would just have to the clients would have to watch it the consensus wouldn't necessar so only the clients that are providing that service would have to watch it basically because they have to like get the hash value when they provide it but they have to want your your your change currency that's right yeah or you can even do something more primitive uh for example if you you you

you form a special contract where as soon as uh it gets deposited the right amount then a new chain is started uh where you know there's no mining you're you're just using the the deposit and you can only unlock that contract in the original chain if all the tokens are destroyed in the in the first chain in the small chain and how would that other CH know that well there's a proof that you can and then it have to wait for confirmations have not it which is okay so I'm not sure that's necessarily

more primitive this seems a little bit more sophisticated well it doesn't require an exchange this kind of approach is nice because it's it's also a way of doing cross chain exchange without ever having actual basic without ever actually like having an exchange of different tokens that are that's across different chains at the same time is you can expect onchain exchange to be very efficient but then interchain interchange stuff will probably have higher fees but here it's between the same currency and here it's the same currency so because the rate will always be like one the spread will probably be very low soorry you said the same same

currency well no so I'm saying you have a here you have B here right and you have a here here exchange between these two is just onchain so it's very efficient here the exchange rate is always one so there's there's an opportunity for like varable Risk garbage charion same here another thing you can do though is just do have security pro and maing here and basically require people to be online when they do the exchange so you can do atomic transactions here rather than Peg transactions here well you can do security deposits for everything can't you yeah you can so uh security depos are the best because it lets you make an a really strong because you can basically say that if you deviate from it in a detectable way your security policy goes away which is NE MH and we'll probably

talk about that during the approv state panel y definitely okay anything else with that said cool e e