Four Dimensional Blockchain Scaling with Adrian Brink (Cosmos)

Transcript

great can everyone hear me okay like in the back is this loud enough awesome okay so let's get started thank you everyone everyone for coming I'm Adrian I'm working on the cosmos project and this talk used to be called three-dimensional doctrine scaling with cosmos and tournament but now it's four dimensional scaling because I gave the precursor to this talk at HCC in Paris and then afterwards in discussions we realized that we actually missed one of the dimensions so now it's four dimensional scaling we may add more or remove them as we go along so if you have ideas around this let me know yeah so and like this talk isn't designed to

be like telling you exactly how to scale your block chains it's mostly to give you an overview of some of the possibilities around how you can scale and like that it's like everyone's responsibility to figure out how to scale your specific application it's like there is no one like solution that just works everyone magically all right so this is like a brief agenda okay all right so I will begin to like give a quick introduction of the problems around scaling and interoperability from then on I'll actually talk about the four very specific ways we can scale block trains and lastly I will talk about security models and security

models are really ideally we want to decouple the security models from how we scale box chains because that makes both parts much easier yeah so that's kind of the overview um and yes great oh yeah and in the end we'll do a quick recap so actually to start with I know talks are like hard to follow and I might skip over things so these are like the three main things I want everyone to take away so if you take it away nothing else from this talk just take away these three main points which is there are about four different scaling approaches to block change so four different levels

chicken scale so one of them the first one is content to scaling I'll talk a lot more about this and why it's cool so using tenorman consensus the second one is state machine scaling so how we can actually builds very scalable business at our application logic but then third one is interchange scaling how can we connect multiple heater genius block chains and the last one is social scaling how we actually build systems that aren't stuck at the Genesis state but can rather evolve through our time in like a non ad hoc way then the available security model so you can pick from

it's like sovereign hosted or Plasma style model and then probably the most important thing is you have to be an optimistic Tanner scaling is everyone's responsibility it's like every single one of you can like make a choice around how to scale the blockchain your blockchain your application and you really are responsible to make that choice don't wait for someone else to figure it out for you alright so quick introduction to scale in an interval T so why do we actually just get right so a theorem County supports somewhere between like 12 and 15 transactions a second Bitcoin between like three like five to several transaction transactions and really this is globally right so

like we can't have more than seven concurrent users at any given point in time sending a single transaction on Bitcoin like when you think about what this technology was try is trying to be this is a ridiculous number that needs to go up by orders of magnitude before this becomes relevant to anything in the real world and so on the scaling part like the interesting thing there from application developers perspective is that you are if you're building crypto kiddies you're competing with someone that just wants to do payments like you're all competing for the same computer resources and in my mind this isn't a great model where I we have to all bond essentially on the same CPU

like at much rather I have a very specific meet that are gonna like there solve a very specific problem that I want to solve and it much rather not compete with and everyone else on the resources over that over my application don't see yeah so that's pretty much like scaling is important we're currently in a state where this is a bit ridiculous then on interoperability and so when you think about how current block chains work right so like we have aetherium and you have a bunch of small contract to a Bitcoin with Bitcoin script but from a

user perspective it is extremely hard to actually use both at the same times like we have many heterogeneous chains that have no way to interact with each other except if you go through these central synchronization points which in today's world are really the centralized exchanges so I imagine if you are in a theorem user and your Bitcoin user and you want to use smart contracts all of a sudden you have to first go to an exchange wait most actually like 6 bucks like 60 minutes get confirmation switch it into theorem then payout to an ether address and then start using a smart contract so like super high latency and realistically speaking there's really no

reason why we shouldn't be able to use for example Bitcoin on a theorem directly over then your theorem smart contracts and lastly the problem with without interval T each one of the chains is a liquidity trap essentially or like liquidity isn't additive if you have interoperability interoperable chains the liquidity within each of those chains adds up whereas in current system it's mostly that liquidity is restricted to each chain so this is especially problematic if you like an application developer and you need some sort of liquidity mmm you can't really pick the one that's best for your

specific use case and you can't even deploy your own blockchain because you have zero liquidity on it so like in an ideal world you're gonna be able to deploy decent fair patience that can tap into the entire markets liquidity great okay now to scaling so the four dimensions in my mind of Charon neck of the layers of the stack and how we can scale Carib doctrines is so I consensus scaling state machine scaling interchange scaling and then also social scaling and

just going back to very easy example of how theorem works right like if they were at the bottom is essentially just peer-to-peer networking then on top of this you have some for some form of consensus layer and then build on top of this consensus there you have actually have the application here so that's the state machine level here and the state machine in the theorem it's really the VM and then the inter chain so that this is kind of like how you can think about it in the ethereum stack and then the entertained part is all about being able to move for example between between being able to move tokens from for example theorem 2 theorem classic and the last part is around how can we actually foster large developer

communities and have an open process to do protocol upgrades in the future yeah so how do we move the decision-making process from like let's say it's ten individuals that really control most dock chains to make this like the actual stakeholders within the ecosystem have now the ability to come to consensus over upgrading the protocol all right let's start with consensus skinning so how many of you have heard about like how many of you know what B of T consensus is it's like 30% maybe great so currently essentially all block chains are running nakamoto consensus so

this is literally the simplest form of consensus the chain based consents as long as change but the longest chain is the correct chain so if you want to figure out what is the correct chain you just follow headers until you are on the longest chain well hopefully because you have no way of knowing whether there's a longer chain out there but that's the kind of I'll come back to this so the like the dark background here is the block time and so what you usually have to do like how Nakamoto consensus works is you have some amount of time for validation select validate the state transitions over the given state and then you have some amount of time for network propagation and mining and I'm really

going to leave out the mining part because it's like not as relevant but then you have all this extra time at the end and this is essentially Nakamoto consensus the safety buffer that you have to have in case you network latency suddenly goes up right because what happens if you network latency goes up so I'm currently this is my block time but most other people have and so I produce an X block most other people haven't actually heard about this block by the time I'm already selling the next one this leads to thinner walls to brain like a very pronounced example of this if you have network partitions and suddenly network latency jumps for small

subsets of the network but the real so first of all this leads to the fact that you need to have always a safety buffer so you block times aren't optimal and secondly it means that you have only probabilistic finality so you don't have actual penalty only assume that after a while you're not going to get reverted anymore and at the same time as an application developer you now have to deal with the ability to have like to handle reorg so this really when you look at it like this is an optimal like in the best case we need large safety buffer buffer in the worst case we go split brain and if this network latency goes up permanently let's say suddenly

the internet speed goes down by a factor of 10 for some reason whatsoever we will constantly be in a situation where you're split brain Nakamoto consensus completely breaks down in this case all right BFD consensus Byzantine fault tolerant consensus algorithms they actually go back a very long time so they go back I think to research from the 70's and the cool thing here is that you don't need the safety month a safety buffer you block time is literally just the addition of you of the time you need for validation plus to tell more than two-thirds of the network of the validators about that block see you never your block times are optimal in almost all cases and the coolest thing

about BFG consensus is that your finality so as soon as you see one block like if you see a block you can tell whether it's completely final or whether bookid reverted at some point in the future which is like a huge deal because now as an application like now we don't have to come up with this magic number of six blocks is probably okay you can say like I have a hundred percent certain that this block is final and if there should ever be a reorg someone is going to lose massive amount of stake due to that reorg what happens in the case that the coolest thing probably is that you're always safe so you're always safe and fully asynchronous networks meaning that even if you have an

undetermined amount of network latency you never produce blocks like you never lose safety your life Innes might go up so like your block time might go like start approaching infinity but you're always like if you have a block you always know that it's correct and not going to get reverted so the way that you know how I explained this earlier on the cycle if network latency suddenly jumps up that's just like bad and here it's still bad but at least we have an intro in consensus way to adapt to it so our in bft consensus the block time just automatically starts increasing until we eventually here for more than 2/3 here the votes for more than two-thirds of

the people so that's a in my mind BFG consensus is really the next frontier for how we're going to scale public blockchains because all of a sudden we can go from like block times of ten minutes and Bitcoin and then block camps of fifteen seconds in aetherium to block times of like one second like just like as fast as we can make it on the network on the network propagation level we can make our blocks and we have safety which is like a massive deal yeah great so there are currently not many implementations of actually beauty algorithms so one of them is called

tenement consensus and it's the one we've been building for for three years now and it's within an engine called tenement courts and I get for it is safety of aliveness essentially and some of the cool things you get it's like you get instant finality so like as soon as the application sees a block it knows it's finally the actually application object never sees anything that isn't final which means that from an application developers perspective you never have to deal with the possibility of ryoga's like the only thing you see are a hundred percent final you get extremely wet so I totally forgot to say this so I in BFG consensus one of the cool things is because you know who's supposed to be

signing these blocks you can construct extremely efficient light tank proofs so in traditional like a motor based consensus you saw that even as a light times you still have to download every header and verify every header which means like realistically your phone has to come online and do like a update every 15 seconds roughly here we can say that we know who's supposed to be signing these blocks and we have a reference to the current set of signer assigning excite us of the of the block clean and as a lifetime I can take any block and just see if more than two-thirds of the people that I already trust have signed this block this means you can build mobile phone apps that

have to synchronize with the chain act once every three weeks it sort of depends on how you take you cannot like how you put the economic security guarantees so if you're very long on bonding periods this could even go up to like six month or but occur also so it's like it's a variable parameter like how often you need like chance to come back online to synchronize you always save in a synchrony and your life and partially synchronous networks and this always sounds scary that like there are cases where couldn't where you might not be necessary life but realistically this only happens if more than one so this happens if more than one-third of the network goes offline if more than one-third of your community goes offline

you probably should stop and figure out why that happened and use social consensus to then figure out how to fix it and also by day so if it just like if if the network latency just increases a lot it doesn't like you'll still be life it's like you only have to use social consensus if for some reason more than two more than one-third of your validators got nuked essentially so if you it's only not recoverable if more than one-third goes offline forever and yeah so some like transaction throughput it's like roughly on 64 validators across the world you get like 2 4 thousand transactions per second so it's like a massive speed increase right like if you can now write

fast state machines you get 4,000 transactions per second and in an always safe network that has a 15 like 10 screws like I think like honestly BFG consensus algorithms will be the future one of the downsides is that you have quite high network overhead so I every validate I need to talk to every other validator so you have like N squared network overhead but some of the cool feature improvements are actually are using BLS signatures to to resolve this so that we can do signature aggregation at the p2p layer so instead of me having to receive signatures from let's say 67 people in the audience these like people

can always start aggregating these signatures while they talk to each other so that in the end I might only have to receive that say 10 like 10 transmissions actually where I where the signatures are included we can do something around optimistic pipelining and to get block times even faster and then using decody constructions to actually fully prevent minor front like validate a front running and so that you encrypt the transactions before you send them oh yeah so practical takeaways for this there are currently two implementations in the world there are no of one is called tenement consent a tenement core and it's the one we've been building it's been pretty stable for the last year or so the other one is by parity they've done implementation of tenement

consensus as well you should probably talk to the perigee people about this I haven't looked into it recently but it used to be that it be like it'd be great if Rock was here because he actually brought most of it okay so there was consensus gating so we there's all be a lot of things we can do at the consensus level to make block chains massively faster the next lay out the stack as you like if you think about like I do it's like it's state machine skinning so everything that once you have consensus now we have a bunch of replicas of like transaction bytes and we running them against some deterministic state machine so generally we should be spending more

time on making state machines faster when you look at the comparison of parity against Jeff parish is about two and a half times faster right now and just like being able to execute EVM transactions but this leads me actually to another points like currently most projects are building around or on top of the EVM and in my mind this isn't a great way to build decentralized applications like most applications do not need the full feature set of the EVM there is if you building if you want to build in exchange there's no reason why we would need user level script ability within

your application like the EVM is great if you want to build if you want to write contracts like smart contracts actually things that are very low volume and executors maybe once or twice but like isn't a consistent volume transaction throughput and the other thing is if you need user scripting abilities at the application level so if you want your users to write smart contracts that directly interact with you set of smart contracts if you users never write smart contracts themselves there is very little reason for you to build a smart contract for you users to interact with you may as well build a specific application like build an application specific state machine that

is just for your use case and this gets massively faster because instead of running a virtual machine you compile everything down to like oh yeah this is maybe another interesting point like most people say like oh but yeah if you're like Bitcoin isn't turing-complete but its theorem is and so it allows me to build turing-complete like it allows them to build any sort of application top of it that is true but every blockchain you build every single state machine you build is turn complete like if you write your own state machine it is fully Turing complete you can build it and go you can build in rust you can build in Haskell it doesn't matter but you have before like available like all your creativity that

you can use all your creativity to build an application-specific state machine alright and I'd like to talk about two examples that we currently I'm currently helping build and so the first one is a Thurmond and a Thurmond is really it's the EVM because the EVM has amazing use cases I just think that most people are currently abusing those use cases and either man is an implementation of the EVM put on top of tenement core so it's a it's an EVM that runs at about two and transactions a second said about roughly 15 times the speed that is with the same document block as limit it has very efficient like change proofs like

everything works as you'd expect it to work except that it's fully proof of stake oh and the coolest feature about it is it implements the entire web 3 spec and so like all the existing tooling works it's like you change the URL the other more involved part of the stack is the Kosmos esta Kane like the SDK is actually how we build a Thurman in the first place the SDK is a framework to building block chains extremely easy it's like you can write - you can write Bitcoin and like 200 lines of code with it it is like the same way that if there are made it extremely easy to write

smart contracts the SDK makes it extremely easy for you to build your own doctrine it's like finally we right now we have the freedom like everyone has the freedom to just like be able to essentially like in the future will be that you sense you just install a bunch of modules and these modules can interoperate so like you know how NPM does it with JavaScript and the packages you do npm install and suddenly of this whole bunch of functionality that you don't really understand how it works but like you understand the input and output it gives you and it's essentially the same thing for the SDK you plug in a bunch of modules that do things like staking and that giving account structure that give you governance and you just focus on writing like you the tiny bit of application logic that makes

you unique instead of having to build up everything from scratch right instead of having to write your network Millea are your own consensus there and then your own application layer plus your own tooling like you own CLI tooling around that application you can pretty much offload most of this to an existing library ecosystem and just like write what makes you block like your application or like just write your business logic and for example one of the cool features of the sdk is that you have like an AVM module so like if you want user level scripting abilities you just plug in the evm module of course this doesn't like there are other solutions eggs eco snacks

which you heard a lot about this morning and state channels and so those are very valid like awesome things for their specific use case as well and we're hoping to integrate them eventually as well great ok coming back to the third one interchange scaling interchange scaling is all about the ability for heater genius blocks chains so block chains with different application states written in different programming languages written with completely different protocols to be able to send tokens from to each other and back I can

actually I walk you through how the hard legwork some conception level it's like it allows you it sorry in the beginning it's an open protocol standard that we're developing and everyone is like very welcome to give us input on it and to collaborate on developing the IBC standard but in the beginning it allows you to move tokens then we'll extend it to non fungible assets so like I actually don't like to call them tokens because tokens in my mind have attract this notion of fungibility so they're more like nFA's and like lastly complex objects and at complex objects things get really interesting because all of a sudden you can have a scenario in which blockchain a is like a loan blockchain and people can like collateralize the

house or the assets on that blockchain but now you can if you once IBC supports complex objects you can take that loan object from blockchain a and move it to blockchain a and so the interest payments could happen on doctrine a or they can the loans can be actively traded on decentralized exchanges and whoever controls that loan object on another chain once interest payments for example start failing they can click they can bring back to the original chain and claim the underlying collateral so once you have the ability to move complex objects a lot of financial applications get really really interesting here and so conceptually the way it works is that I mentioned before

you have X with P 50 consensus algorithms you're able to build extremely efficient like tines so all these chains are like tines to each other so let's say you have Bloch in a and blockchain B and blockchain B has an account that only the consensus of blockchain B can unlock on chain a it's like when I want to move tokens from train a - chain B I essentially lock my tokens on chain a to the consensus of chain B and so once what and then I sent this prove that yes you like you consensus my destination chain consensus now controls these

tokens so it knows that it can then give me those tokens on its own chain because we can always go back we can always say oh like someone some other person wants to move those tokens back and then they go to option B and say hey I want to move those tokens back and dr. B says oh yeah right I have actually the exact equivalent amount of tokens locked like my consensus can expand those tokens and like the way you do it is that the each chain essentially keeps track of each other's vowel dataset so it always knows who's supposed to be signing packets and then we have a special transaction for like transact it's called a BC packet which the consensus of one change signs

and then some relay a-- relays that packet to chain b and chain be all they knows who's supposed to be signing it so it can then authenticate that packet and see whether it's correctly signed and if it's correctly signed it knows that this was not is now final on the other a chain and can release the funds oh yeah so by the way if anyone so this is like high-level overview of how IPC works we currently working on the spec further and the implementation it's a lot of fun to like start thinking about how block chains can have accounts and other block chains so if you interested let me know after however there's always this problem with like legacy systems right

like most documents right now and you like on finality based chains they're probabilistic finality so that we have eventual finality what we have to kind of follow the chain all the time to figure out which one's the latest date with IBC Plus adapters essentially means that we write some sort of finality threshold around an probabilistic blockchain so in the case of aetherium we read an adapter that follows the etherium chain and falls normal protocol but after a hundred blocks said she signs a message saying I seemed like this block is now 100 dogs deep so I'm guaranteeing there will never get reverted and I previously used to call this piggy or pic zone but

really it's just an extension of IBC to non finality chains or we need some extra way to enforce eventual final I to guarantee finality even over non finality chains so in the case of aetherium this that she works by saying we run the theorem protocol all the validators of that chain run the theorem protocol they all see some blocks some events and then they witness those events and they only witness them after a certain amount of time after which they believe that those will not get reverted if they could revert it they're punishable as non prove a stake so they have intended to figure out what is the best finality threshold to use for

theorem and then after that step it's just normal IBC where we just send like lines prove that time proves between chains because now we have this finality R&T again and the last thing about like interchange scaling is how the hawk works so it's a cosmos hub it is essentially a liquidity aggregator os/2 functions you know how in theory like theorem enforces this ability on the user level that users can't double spend each other so I can I can't send tokens to you and you because the protocol

enforces that that doesn't happen once unison area where you have multiple block you have many many block chains there's no way for like block chains could double spend each other because there's like no one enforcing this invariants that you can't spend more tokens than you have and that's really where the cosmos hop comes in that it says this in like the hub enforces the invariant that I can't create like if I'm locked in a I can't just create tokens for block chain be out of the now oh and yeah the actually the other thing is it's a liquidity provider so if you build an application do you need liquidity you just connected to the hub and all of a sudden you can

tap into all the connected all the connected ecosystems so instead of having to connect to every single chain in itself and figure out how to do secure connection against a theorem against bid coming in Zika against whenever you connect to the hub and the hub gives you like gives you access to the liquidity pool of all the other chains and like liquidity is a major problem if we move into a direction of multiple heterogenous block chains yes all right social skating so this is like super fast this is like the addition that I made after each CC because people brought up that point or just say it's fair so we really have to as a community

we have to figure out how we can grow the amount of people that understand how these protocols work it's like we have to learn how to write good readings we have to learn how to onboard new people and say this is not it's not a good idea that only like 20 people in the world understand how these systems are built it's like it's a recipe for failure essentially it also helps you add options security view code base yeah so like develop like social scaling of development is I think huge role that most projects kind of like ignore the other thing is governance and this is probably the most crucial part it's like

we have seen repeatedly in the recent ha in the recent forks as well in some recent hacks that we need a way to evolve the protocol or to even come to agreement over state changes we were making that protocol so imagine a scenario in which we could have had governance to decide on what to do with the dollar it's like and by governance I mean we don't have let's say 50 people in a room they can't decide what to do but it's rather everyone gets an equal vote or like you the economic majority gets a vote so that in order to do protocol upgrades you need to have more than two-thirds of the economic stake behind you and suddenly it becomes actually a

feasible option to do long-term evolution of these protocols and say what currently happens is mostly you have this rapid development phase where you try out new ideas and then once your life you like you really start to slow down because you it's like it's hard to say who is the right now to make changes to that protocol is it the developers that push new code is it some other people is the - that decide like it's very unclear of who is responsible for this and by social skating I mostly mean we need a long term ability to evolve protocols because otherwise you're always in this pickle where the next bit like a new competitor will come up every five years and who have learnt everything you did wrong and upgrade put

it into their protocol maybe for key distribution and then run with the improved protocol whereas if you actually have the ability to evolve your protocol you have much better chance actually I changing the world okay this is like I think my last slide around so that was scaling the for the different stages of scaling so we can either scale at the consensus layer we can scale the state machine layer or we can scale at the inter Train layer where we yeah and what kind of - this we should always think about social scaling as for the different security models um and I think

this is very important to realize like you can pick whichever security model suits you best and like a lot of applications have very different requirements for the security model for example the first one is sovereign so like your own doctrine you have to figure out how you do security yourself you have to get some sort of distribution of economic value that is willing to secure your blockchain in like the proof of stake way and it gives you the greatest flexibility it's like great model if you want to build a core level protocol like an infrastructure because it gives the stakeholders complete control over how to evolve the protocol it's like if you build directly on

eeehm yes you have the ability to evolve your specific smart contracts but you have no control of the table network layer or the state machine like or the EVM the opcodes that you're running if you are actually using sovereign security model you're completely independent so you're completely your own community and you do whatever you decide is best interesting enough I think like one of the major things that Tripp Kirby's sovereign are like Texas because they probably have very specific requirements that we haven't completely figured out yet the next part is like the next model is hosted so that's very similar to like polka dot all right this

is like what Paul is doing it's like that I can write arbitrary application state within web assembly but I can upload it and then I don't have to worry about how the security is determined so a bunch of people just get a bunch of L they just get selected to be running my application at this state then they run it and if they actually fault they're punishable on on the polkadot chain on the relay train I think it's called and so this is a great model if like yeah I think this is like if you don't want sovereignty and you don't have to deal with the own security host it is pretty good idea the last one is plasma and plasma is a very loaded term so a lot of people

understand very different things about plasma in my mind and so plasma is the whole idea that you want to be able to delegate the C key that you make zero security assumptions on all the child chains and that all the security lies on the route chain I think it's a great model for certain use cases but I don't think it's a great model for like building X for scaling the future alright for scaling the future of block chains because the main issue with plasma like around plasma is that if you trust your entire security to plasma you might end up in a situation where

a lot of people will want to let's say like one or two of the plasmas change start failing and now everyone has to like now think about whether they need to exit to the root chain but the root chain of course has limited throughput so like unless and so now I as like an unaffected plasma is I have to think wait if another chain fails can my plasma operator start cheating me based on the fact that I can't get my exit transaction into the root chain so like you might see like a bottom-up collapse of the entire because I got the entire chain system due to the fact that you get market panic and everyone tries to go to the root chain but you have limited throughput on the root chain and all of sudden like where plasma is excellent is like for as a security

model around IBC because it allows you to even if I move tokens to another chain I'm still able even if that chain fails I'm still able to submit the proof that our own tokens on that failed chain back to the second chain and be able to reclaim our tokens there so like yeah I think a planked plasma is like a general security model it's risky because like you might get like catastrophic failures that's like catastrophic cascading failures but plasma is great too like for multiple different block chains to connect to each other and I'd be able to deal with the failure cases in of certain block chains generally what I

really want to say with the slide though is like we shouldn't be building a future in which everyone uses exactly the same security model it's like using exactly the same security model it's probably not a good idea and eventually that security model might be proving insecure and we get massive fader seg we should always go for like a diversified approach to most things like not everyone should be building on the same software stack not everyone should be using the same security model hmm I think that's like a general rule of thumb it's like if everyone is using the same security assumptions is very risky because that assumption might be wrong or might fail on expect

sir SEC depending on your application like those are kind of your options right now but it depends on your application all right I'm very close to the end actually I fixed this okay yes so this is a quick recap so I hope you remember the three things I said you should remember like the only things that are actually important to take away from this talk those are the same things again so we talked about the different approaches to scaling so we've content to scaling and ideally we want to use Byzantine fault tolerant algorithms there because they give us masses like they give us massive amounts of benefits to give us efficient light lines they give us much higher

transaction throughput they give us close to optimal block times then it's a state machine scaling so the ability to actually be building your own blockchain without a lot of hassle and the fact that most people probably want to be building their own blockchain interchange scaling that can actually move tokens between chains that we don't all have to live on the same chain but like it's okay if you all live on a different chain because the chains can still talk to each other it's like we don't have to pick this is the only thing we want to support and because this is where the greatest amount of liquidity is we can pick whatever software stack is best for us whatever security status best for us but we can still all talk to each other oh and the lasting social scaling around like

actually think about how you want to evolve your protocol then I talked about the know the available modes of security so sovereign hosted or Plasma and lastly scaling is really everyone's responsibility so I don't wait for someone else to solve your scaling needs like think about it like Netflix if Netflix is writing software that can only serve a hundred users worldwide at the same time they shouldn't be waiting and sitting around hoping that Amazon builds better service they really should be figuring out how to build applications that actually scale to the user base they're intending to have the site it's everyone's responsibility you can't just hope that some imaginative

solve scalability for you you're actively look for design patterns allow you to build scalable depths yeah again I'm very like assistance on this yeah so thank you very much this was pretty much it