J3 PAIN 02 Adrian Brink Scaling with Cosmos, Tendermint and Plasma

hello everyone today I'm going to talk about three-dimensional blockchain scaling with cosmos and tournament it touches on some parts that Kyle talked about earlier but it also introduces some new and maybe slightly different concepts unlike possible solutions to scalability within blockchains oh and yeah I'm also very sorry for like the click Beatty title we thought of it last week and to us it sound very funny and I still stand by it it's like it kind of describes what I'm going to talk about because I'm going to talk about three different things we can do to scalability oh yeah so I'm Adrian and I'm also working on the cosmos project right so today I'm going to talk about three dimensional blockchain scaling and you can already see the three dimensions here so I'm going to talk about consensus scaling state machine scaling and interchange scaling and just as a brief recap of what a blockchain really is like when you look at the theory I'm a Bitcoin for example a blockchain is like not this monolithic stack we implement it as a very monolithic stack up until now but really a blockchain is that you have peer-to-peer consensus or peer-to-peer networking at the base layer then you have a consensus layer on top and then you have a state machine layer on top of that so that's really what a theorem like what a blockchain is so in the case of a theorem you have lip p2p as a networking stack you have proof of work as a consensus layer and finally you have the EVM as a state machine on top of all of this and so users it's like if you and developer you can either the choice of building on state machines or building on top of existing state machines and then interchange scaling is all about how do we have multiple heterogeneous block chains and how do they interoperate and lastly I'll talk a little bit about the modes of security the block chains can operate in but it's like the main thing I want to convey today is like I'm not telling you exactly how to scale like I'm just like explaining a bunch of options that developers have in order to scale the decentralized applications yep yeah so these are my three main goals for the talk and like I know it's early in the morning some people might have not had a second coffee by now so it's like if you only take something away like only take away these three points it's like the different approaches to scalability we can either scale at consensus at the state machine level or at the interchange level well and I'll go into much more detail on all of them and for the security modes you can either choose a sovereign model so something akin to a theorem or Bitcoin where it's a completely independent chain a hosted model where you share the security with some other chains so you'd share a common validator set but you still have heater genius block paints and a plasmid chain oh yeah and lastly and I think like if you are currently writing dissenters applications it's like I would recommend that you don't just like sit around and hope that someone else solves you scalability problems it's like you as the developer it's really your responsibility to go out and see what are the potential scaling solutions that I can use right now to build my applications so I don't just hope that someone solves scaling eventually actively look for solutions that you can use today to scale your applications so I will briefly yes so I'll start with the consensus scaling mmm so Nakamoto consensus like traditional proof of work chain base consensus where the longest chain is the correct chain the reason why we need to have quite large block times is because we need to have the safety margin where the propagation so like generally speaking the way block chain works is that now you start with a block you validate the block and then you kind of try to create a new block on top of this and then once you have created a new block on top of this you need to propagate it to everyone else in the network so all the other participants know about that block the reason why we have to have quite large block times and Nakamoto consensus is that in order to be safe we have to give this leeway that we might have very long Network latencies because if there's very long network latencies and they overtake the block time we come into the scenario where you start having a split brain scenario so that's a fork right it's like if it takes you longer to propagate a block to the network then it takes you to produce a new block the network will have start we'll start off diverging opinions on the block and realistically speaking diverging opinions like Forks within the blockchain are a terrible user experience it's like the like no user expects to press a button and then to find out 30 minutes later that this got reverted like this is not how anyone thinks about how the internet works how any sort of application works so like this is build to never go split-brain is really important and so this has been tradition the traditional consensus layer so Nakamoto consensus BFG concerns is Byzantine fault tolerant consensus it's a quite old research area but it has been applied to blockchain as much as of late the nice thing about it is that we're always safe so we know never go split brain due to that we can push block x massively lower they can just be optimally larger than network propagation takes and even if the network latency becomes higher and instead of producing forks we just start slowing down the network so network latencies increase across the network we just become slower producing blocks so our block terms just increase but in the normal case this allows us to drastically reduce block times and so bitcoin is at ten minutes to give you the safety margin that you're not splitting too much and that the current miner doesn't have too much of an advantage over everyone else and if you're a miss at like 15 seconds you know a long time seems reasonable all right so I won't talk a little bit about tenement consensus and tenormin consensus is a BFG algorithm it's like from 2014 we've been developing it since then and it has a bunch of nice properties so it has instant finality as soon as you sign a transaction and it's included in a block this transaction is considered is completely final there will not be a fork at which point the user will be presented different state of the network then you saw when you saw the transaction for the first time so complete finality within one block the other nice thing is that you have extremely efficient light clients so in traditional Nakamoto consensus you can have to keep up with with the headers to verify you that you own the longest chain in BFT consensus and telemon consensus you have to be able to update your validator sets so the the people validating the network and you have to be able to update them like once every three weeks can depending on your security something around on bonding and prover stake moreover it's safe in an asynchronous network so we never we never become unsafe so it does it prioritizes safety of aliveness and we have lifeless and partially synchronous network so if you have the assumption that eventually we will have these messages will get delivered and we will always make progress the incredible thing is that with this as a consensus scaling solution we can have block times of one second so we can have let's say a hundred values around the world and I'll come later back to like how these value does get selected but it's not as bad as it sounds like not these hundred authorities but rather these people are elected through economic stake and so like everyone in the room that has powered a tiny amount of this economic stake is able to vote on who these felt is able to delegate the economic stake to someone else is able to delegate the economic stakes to someone else and participate in the content I participate in the consensus at the same time this gives you like at the peak if you have 64 Val days like beef data centers this gives you about 4000 transactions per second so I think about the scalability increase that you get that you get from switching to be FG consensus like one of the downsides is you have quite high network overhead and like some future improvements we're working on it's like BLS signatures and so we can aggregate votes on the network on the network stack or the peer-to-peer network layer and so that we reduce this network overhead optimistic pipelining to get even higher transaction throughput and dkg constructions decent rest key generation which would allow us to like prevent validator front-running and maybe the last place like this is available right now so we have an implementation called tenement core and if you want to build your own blockchain on top of this consensus you literally only have to write the state machine and even that like is much easier with the tooling we've developed it's like instead of having to worry like Oh fork some other code base the only thing you do is you take tenement call and you say this is the exact application logic I want to build and then build it on top of it and you get all the and you get the consensus in the network of a free but of course in usually so if using tenement consensus actually the limiting factor isn't the consensus anymore the limiting factor it's a state machine right select the EVM or some other the you take so said that you've built on top of the consensus and like what we can get in terms of state machine scalability like you can simply look at parity versus gap so parish is about two and a half times fastest like there's a lot of room for optimization than state machines and I'm also going to make another bold claim I don't think most people should build like super specialized application directly on the EVM the EVM was designed for smart contracts not for smarter like it's a it's a great use case if you need to deploy low transaction volume one of things like actual contracts if you want to build a decks or something like that you're most likely much better off building into specialized state machine because you have all the optimization and like you can do whatever you want to the state machine so you can design a complete protocol and you have complete freedom in how you built this you're not constrained by some docas limit all the gas cost so like and I think for most applications there's a real downside with like the EVM is great if you need user level scripting so if you need to use eleven turing completeness i imagine if you are building an application that requires the user to deploy their own smart contracts to interact with that application the EVM is amazing but if the only thing your user does is like send a transaction and there's no reason why you need to carry all this extra cool stuff with you to just build this one specific application and like rid you and removing all this cool stuff around you like rude reduces the attack surface massively that you have to face and it's much easier to reason exactly about what your state machine does and at the same time it's more scalable because you don't have to run all this extra code so yeah in conclusion the EVM is amazing if you want to deploy contracts if you want to build X's I don't think it's your best bet so but even the EVM like we can scale the EVM quite a lot so we've built something called a Thurmond which is essentially an EVM put on top of tenement consensus so right we have now these 4,000 transactions per second that we can have on the consensus level and now we have the state machine as the EVM and it's fully web 3 compatible it's like all the existing tooling work it's already fully proof of steak so it's like it's something that you can try it today the cool thing that once you put the evm on like a BFG consensus algorithm is that it gives you first of all much higher transaction throughput and secondly extremely efficient light shines so if you want to build a phone app that is that securely interacts with a with ether meant for example you have to come online once in like every three weeks so you have to do like one header update once every three weeks that's it you don't have to constantly keep up with all the headers which for mobile devices is massive so due to the fact that Ethan Zuckerman content supports about one document one second block times this is roughly fifteen times as fast as currently theorem and so at the same Gaslamp block as limit we have about 15 X of throughput and like there's nothing it's like this is a different kind of assumption that like if you remember that triangle from yesterday that was all about how we can a fewer notes a lot of notes and so the argument determine consensus is that you can have fewer notes in the hundreds but these nodes nodes are fairly selected through economic majority votes or delegation by the entire stakeholder system in the chain yeah so that's a Thurman that's a quick introduction psych essentially if you need fast like fast smart contracts this is a good bet but I was talking about how we should make it easier for people to build their own state machines and this is really what the cosmos SDK is Kosmos SDK you can imagine sort of like NPM but for blockchains so it allows you it's a bunch of mod but by the way it's not that nice yet it's like NPM is pretty awesome it will take us a while to get there but you can imagine it as being able to pull different modules that you need so for example if you want to build approve a stake system you pull in the staking module if you want to build a governance like if you need governance you pull governance module if you need some way to like to do signatures check checking so authentication you pull in the auth module and if you need to EVM you pulling the EVM module it's like it really gives you this ability in very few lines of codes code to build your own state machine previously this was extremely hard right like most projects that are currently active essentially ended up the Bitcoin C++ code base and she's like yeah I'll just modify it a little bit like we've modified the state machine a little bit to do exactly what we want but they still had to fork the entire code base and now I have to live with like it's not a nice development experience it wasn't something that everyone could do with the cosmos SDK you can literally build Bitcoin proof of stake and mostly like 200 lines of code of course the SDK isn't dunya's like we've written at this and go and in the future we're hoping to add multiple languages to it and also at different VMS this module so that instead of having like that you just have the choice act there can be an EVM module that can be wasn't module different VMs can all like you can decide which ones you want to pick of course state machine scaling doesn't give you full vertical scale like it only gets you so far right because we're still talking about scaling one blockchain so and I personally don't see a future in which we will have one homogeneous blockchain that runs everything most likely what will happen is that will have application specific block chains where for example like we had this example of visa I don't think visa will build their payment processors within the VM I think they want something dedicated that they fully understand that they fully built no matter whether the open source didn't have a decent result layers and running it but in my mind we are moving we will end up moving towards a world of heterogeneous block chains oh and also like things like state channels totally work with both either of these concepts so because state channels are amazing so it's like this doesn't limit you so now I want to talk a little bit about interchange scaling and interchange scaling is really we have a future of hitter genius blockchains how do we make sure that these block chains actually are able to talk to each other and again like this is most likely we won't have a homogeneous future like different developers and different projects will want different trade-offs and they don't want to be restricted to the same platform it's like yeah so what I BC allows you to do is to do secure transfers between different block chains IBC relies on this notion of finality that like we don't get reacts or like there IBC relies on the fact that your blockchain needs to have deterministic finality so you can't have this Nakamoto consensus finality where we say it's probabilistic and like eventually nothing will get reverted anymore we actually need true finality and then the way it works is that both these chains are like lines to each other so let's say you have chain a and chain B and both of them are tracking each other's validator set so that they can receive messages signed by the other chain and verify the authenticity and like again this sounds crazy right because light lines generally still require a large amount of headers but again like if you have like written proof of stake and with finality you can forget away with like doing a validator set update every three weeks roughly like every one bonding period improve a stake and so then the way it works is essentially on blockchain a you lock some tokens to the consensus of blockchain be constructive Merkel proof over that fact and then send that rocket proof or some real a process consent like anyone in the world can send that really that packet to blockchain B and blockchain B knows about the valid a a set of blockchain a so they can verify the authenticity of that message and now the hunt wasn't certain that there are some tokens locked on blockchain a that block can be controls so they can now generally like give these tokens to other users so currently this supports tokens we're hoping to extend this I like extending this to n of T so later this year and the ideal world once we get there is that it supports complex objects so that we can take for example blocks and a can issue alone and you can move the entire loan with its complex internal stake over to blockchain B and then interest payments can happen on block can be and now so but of course we don't live in a world yet where every block transfer nullity so like Bitcoin and also theorem and like all proof of work chains essentially have this probabilistic finality and this is where Peggy comes in Peggy is an adapter that essentially enforces finality over probabilistic chains so it says that let's say Peggy supports so it listens to the blockchain and finalizes those block like after hundred blocks after digging a tree but it's essentially the validator said says ok now I trust that this block is finalized and this allows us to bridge proof-of-work chains into this finality ibc ecosystem where we can for example we can send tokens between a theorem and Bitcoin given that we have two adapters for each of those chains because and like the reason why like the scariest thing here is that we have to enforce this 100 block threshold and a lot of the questions are like what happens if there's a reorg after hundred blocks in my mind this is not a huge issue anymore because I thought about it some more and like if we actually have a hundred block deep hot fork reorge within aetherium we will most likely have two theorems like mo exchangers use the confirmation between like six and twelve blocks by the time a hundred blocks of past they've moved millions of dollars and they're really massive major economic incentives to like maintain to Fox so like that's like even though it sounds scary it's like in reality this will probably fine but given this scenario of a lot of feature genius chains one of the problem become like one of the nicest ease of having like one chain is that you have a lot of liquidity within that chain because everything is within that ecosystem so once we start having this world of heterogeneous chains we need some way to provide liquidity to people and this is really what the cosmos hub is about it's like it's a liquidity provider for connected blockchain so that they can all tap into the same liquidity pool at the same time it's sort of it's a double spent protection mechanism between dock chains so a theorem has this cool property that users can't double spend each other right it's like I can't send my coins to like two people and not like those two transactions won't end up in the same chain so I can't generate money out of thin air the hub has exactly the same job but between block chains so the hub maintains that two block chains can't double spend each other and so now we're moving into modes of security modes of security is really you as an application developer you can like choose what kind of security model fits you best it's like this is not about describing which one you should pick there's like these are the different options that you have and depending on your use case one might make more sense than another so the first one is sovereign right so sovereign is like the basic defaults probably the hardest but it also gives you in the most control it allows you to change it allows the stakeholders within that chain to change everything they want about how that chain operates so this is kind of like the theorem foundation running the IP process and upgrading theorem at the like doing the heart Fox 4 theorem it gives you the ultimate control over your developers so for example if you want to build a true decks and by the way I'm just using Jack's as an example because I think the exes are pretty cool and they will be very big into that like considered and they we know recommendations here guys so but given that like you want to build the decks right so you have this yeah maybe I have some staking like you need to come up with some staking token that defines who the stakeholders are within your system and then these stakeholders get to vote on every single aspect of that decks wares and like this is the major difference to the hosted model as in the hosted model you kind of assume it may be a good comparison psyche you own your own servers or you running on like virtualized instances in Amazon datacenter like host it is more like that where you have to trust that the opera that the stakeholders of that the validators this yeah this the economic stakeholders the people running your underlying security mechanism are doing the right thing and are doing protocol upgrades that aren't breaking to you and maybe your use case might be too niche actually so it doesn't fit within and then eventually yeah so I'm a big fan of the sovereign model but like host it is like the nice thing you share the security like you can share underlying security assumptions with the other validator set and lastly plasma and so within plasma right Kyle talked about a bunch like you all have the same security like in every single child train you have the same security assumption then in the root chain which is great and honestly like most a lot of things should possibly be plasma once we have generalized like general state transitions for plasma because like building things within EU ticks the model is very hard but once we have general state transition like general for proofs of every state we can like use plasma a lot yeah Oh actually I like that so this is actually I getting very close towards the end of my talk I just want to quickly recap the goals I talked about earlier so like understanding the like understanding the different approaches to scaling so we can either scale consensus and that already gives you a massive improvement and like one of the nice thing is it's out there right now there's an implementation of tournament consensus within tournament call and within the parity client and so I if you thinking about building a major application you should really think about building it directly on top of a very scalable and very safe consensus algorithm oh yeah and one of those things I actually forgot to mention I think it's like tournament prioritizes safety over liveness so like boom like it never Fox it just halts until you can figure out why you would have forked which like in my mind for most financial applications is probably the preferred mode of operation that instead of oh we have some sort of network we have some sort of network level attacker and now we just start walking when if two competing histories and I will throw one away it seems to me much safer to figure out what's going on and then resolve that problem and then your life again the second thing is state machine scaling it's like it's getting much easier right now to build customized block chains it's not as hard as it used to be like that's the main thing like building your own application specific doctrine is getting massively easier right now and it will continue to do so over like the course of the coming years so if you some sort of like heavyweight application it makes a lot of sense to start looking into building your own application specific blockchain and then picking a security model that's right for that and the last part is even in a world of heterogeneous productions where everyone starts building their own chains we still have the possibility to communicate between those and we serve the possibility to access a lot of liquidity yeah so again no the available modes of securities so sovereign hosted or Plasma and like I really want to drive this point home it's like scaling is everyone's responsibility there is like if you're writing a silly smart contract and you just hoping it's scales like I don't think you're doing you use us or your project or service like really think about what is my application and how can I scale this to potentially millions of users it's like you should be actively looking for design patterns that allow you to build scalable daps decent rails applications yeah scaling severance responsibilities don't wait for someone else to solve it for you and then that's it thank you very much so you discussed many anticipated scaling challenges that deuterium is going to face and how these methods can solve them however there's an actual like painful scaling challenge that we have which is that the state itself is growing massive and therefore the validation step validating transactions has become a insurmountable burden for the little guy simply because if you want to become an ethereal validator like your hard drive can't write as fast as the state grows so have you considered the like this particular bottleneck the top eight is growing yes so we can still do everything like shouting into this model so you can still do state charting where we select different validators to validate each chart so there's like everything it applies to theorem writing will also work here any other questions up there very nice talks thanks what give some perspective also with comparison to MPN very quick question yeah you have those arrows going out from NF T's to cops right so any of this is a bit of an interface can you give a concrete example what a complex object what the heck is complex yeah so a complex so an example so by the way these arrows just meant like we'll start with tokens then we'll do NF kiss and then we do complex objects because increases in difficulty complex objects are things like loans are back with collateral so that on chain AI say I put up some let's say ethers collateral and someone gives me alone and I have to make regular interest payments on this otherwise the loan defaults and the people can claim my security like my backing security being able to move this object to another chain let's say it's called the loan payment like the interest payments chain and be able to pay interest on the on that chain and only in case that the loan has expired so I paid all the interest I move it back to the original chain or I default on the loan I move it back to the source chain that's kind of the idea with complex objects and how that works wait what's the question more technical on how to build this or we are working on those standards it's like if you're interested in collaborating on these standards please let me know yeah so that's like generally we're trying to get as much input in on all of this stuff you can actually learn more about this is cosmos store network it's like if you want to like participate in the standards building please feel free to do so down here you talked for a few seconds about liquidity that customers can bring to the system can you just give us a couple of words about that yes so if you so you have multiple chains and now like let's say there's like a base amount of liquidity within the blockchain ecosystem right like if you start splitting us across multiple chains and we started using the critique of every individual chain but the hub essentially works its liquidity aggregator for all those different block chains so that if you need liquidity you don't need to curtain you don't need to be able to connect to all the different chains to tap into all the liquidity of the blocks and ecosystem but rather that liquidity can flow through the hub so like if you want to tap into liquidity you have to establish like one connection instead of 100 your presentation you mentioned 4,000 TPS r64 validators how did you guys choose that number and how does that scale to say like a thousand validators so I don't know how this so as like until we have Bill s signatures the network overhead will grow massively up to that but if you have a thousand validators maybe can be expecting a I don't know this like total guesswork like maybe 200 maybe 500 it's like but it will go down hmm oh it was just a test we ran like three years ago this might have gone up by now it's uh oh yeah the test was run on 64 beefy instances in AWS data centers around the world any other questions okay great thank you very much guys [Applause]