Security & Interoperability in Disparate Scaling Topologies | ETHDenver 2023

scaling Technologies so one of the things that we first need to do before we get to the disparate scaling Technologies is to realize what a bridge is because all of the scaling Technologies need Bridges and we also have to appreciate the danger of bridging so scaling solution require bridging or trust but it has many challenges and we can see these challenges not even having to look at it on a technical level we can see it just by the amount of money that's been stolen in bridges in the last year I think at the peak there was about 14 billion dollars in Total Lock value in bridges and last year alone over two billion dollars was stolen and part of that problem obviously is mistakes with teams or contract code and some of those problems can be addressed but some of the problems are more intrinsic to the construction of a bridge itself and we have to consider these intrinsic security vulnerabilities when considering and designing scaling Solutions so what exactly is a bridge and how do they interact with scaling Solutions Bridges effectively allow an asset to be locked in one context and then used in another there's no way that I can actually send ethereum out of ethereum into optimism I am locking ethereum and optimism and then I am sorry in ethereum and then I'm using it in optimism and I have a large number of risks that will exist which I will discuss while I'm in that locked context and to start understanding the risks we need to First Look at the trade-offs in the different scaling Solutions so what are the current scaling Solutions and proposals for scaling Solutions and so if we go back in time with ethereum one of the earliest scaling solutions for State channels and examples of State channels are rated enlightening you know then plasma was proposed that hasn't really gone anywhere but we should at least consider plasma when we're looking at the trade-offs in technology of different scaling mechanisms uh side chains are scaling mechanisms so having something like BNB or polygon or technically a scaling mechanism for ethereum and we've seen a lot of that being used as scaling mechanisms with the popularity of moving contract and evm execution into an alternate environment Roll-Ups obviously are scaling mechanism like optimism Loop ring and most recently valididium has been another sort of Proposal with scaling and starkware has uh sort of an offering there the problem that we get to that all of these scaling Solutions have or the challenges that they face they have challenges with synchronization they have challenges with validity and then they have challenges with data sharing and the different solutions have different degree of challenge in each one of those areas it's high altitude up here there's a little bit of dry mouth so if we look at the scaling solution trade-offs we can actually consider the scaling Solutions and the trade-offs within that set of scaling Solutions um that I've covered really along two axes uh one axes being the level of validation that is taking place and the other axes being the level of data availability that's being provided by the scaling solution and we can see if we look at something like ZK rollups we have high day availability and a high degree of validity guarantees if we look at something like optimism we still have high data availability but we have less uh rigorous validity guarantees and then you can see plasma has really neither and validity of validium has low data availability but High validity so as we've covered kind of what the scaling Solutions are generally and what the trade-offs of each one are we need to start looking at the risks so one risk that we've obviously seen exploited in the ecosystem with hacks in the last year is contract risk so when I go from one state say the ethereum base chain into another state say BNB I am suffering contract risk in both the exit contract at the ethereum side and I'm also suffering contract risk on the BNB side now the cool part about that is that we can actually solve that contract risk through formal verification so there's no reason that I can't drive that risk to zero we also suffer from VM risk so if there's a bug say in ethereum or there's a bug in the ZK snark that's used in a ZK roll-up or there's a bug in you know B and B chain I suffer when I'm in a in a scaling context from the risk of that VM and again that's one of these easier things to solve because I can use formal verification I can use code audits to minimize my risk in both contexts now this is where it gets a little bit more interesting so when we look at validation one of the requirements of going from one context to another is that you need a mechanism of validation of the state transitions that happened in one context back into the base chain or vice versa and unfortunately for some of the solutions like side chain or plasma um it isn't easy or potentially possible to provide um proofs and that's one of the great advantages of things like you know Roll-Ups and validium is because I have these ZK mechanisms of proving I can prove those things to be correct without having to have a trust in entity or some set of exterior off-chain consensus rules to know that I have validity in the scaling context we also have an oracle problem specific to side chains and plasma so one of the problems if we look at the side chain we look at ethereum and we look at B and B how does B and B know anything about ethereum and how does ethereum know anything about B and B they're completely independent systems that have different consensus mechanisms that are progressing asynchronously so somebody has to tell me what the state of each thing is not only what the tip is what the highest head is but also what the actual say commitment to the state route is so to cross into sag chain or plasma I am necessarily going to need an oracleized validator set of some form that could be a single point Oracle that could be a many point Oracle but what I've done here is I've created an off chain consensus mechanism that has some set of incentives that is completely independent indifferent than ethereum so I have to understand the risk that I've just created in doing that and the security of that secondary mechanism so in some of these side chains doesn't require watching it only cries oracleization but State channels plasma and Roll-Ups all require some form of watching so if you are indeed in one of these uh scaling contexts you have to continuously monitor that scaling context to make sure that it is valid relative to the things that you care about now you could do that yourself so you don't need a trusted entity but functionally speaking most people want to delegate that to somebody else so that means that they're going to again create new incentives new consensus mechanisms and new processes that are going to live off chain and you must recognize what those are and what impacts that has on your security we have an ordering problem so we don't have any ordering guarantees when we're running in an off-chain context we can create mechanisms for ordering but what am I now doing I'm recreating the blockchain with a secondary consensus mechanism a sentence a secondary set of rules in a secondary set of incentives and then we have a data availability problem right so when we make a commitment back to the base layer if I ever make a commitment that becomes canonicalized and I don't have data availability that went under that commitment I could essentially lose State and lose my ability to further interact with that out off-chain context and then there's also the issue of synchrony the synchrony issue is most easily understood when we consider Two Chains so if I think about B and B and I think about ethereum there's a problem in BNB and BNB has a rollback but we already made a commitment on a B and B to ethereum bridge back to ethereum I've potentially released assets back to ethereum that were in BMB if I roll that back those assets are now gone so I have synchronization risk between the two changes that are running asynchronously and the only solution I have here is to wait but if we understand how chains progress regardless of the consensus mechanism being proof of stake or proof of work they never actually ensure finalization they only logarithmically approach one in the Assurance of finalization so technically you have to relate an infinite period of time to cross contexts and so the last one here is proving availability and most people don't realize that this exists but let's take optimism for example if I assume that optimism has state which has similar complexity to ethereum represented in optimism let's say I have a systemic failure and Trust in that system and everybody needs to create fraud proofs to exit that system and I have many many fraud proofs I have a two-week period to validate those fraud proofs on ethereum while I'm still competing with every other system that's using ethereum to run transactions so how many of those fraud proofs can clear within the the challenge window so I don't actually have a guarantee that I can ever redeem the receipt that is my guarantee of validity which is the fraud proof so what does this all mean we are introducing trusted entities and we are carrying Perpetual off-chain risks whenever we use one of these scaling Technologies and we have to always be aware of what these risks are and mitigate them appropriately there is one proposal that you could have for a solution and that is reciprocal validation so if I took two arbitrary chains like the ethereum based layer in any of these scaling Solutions a side chain roll up plasmas Etc if I have a periodic link which they already have but during that periodic link I also ensure reciprocal validation I can actually solve almost all of the problems that exist with every one of the scaling Solutions through reciprocal validation so what do I mean by that I mean that in this case let's just take ethereum and um optimism if I made it so that if optimism ever made a bad commitment to ethereum that ethereum block was also invalid based off that bad commitment that block got rolled back I could now solve of almost every single one of the problems that currently exists so that's reciprocal validation you're guaranteeing synchronicity and you're guaranteeing rolling forward and rolling backwards together with the solutions so basically what happens if we talk about reciprocal validation I can eliminate the last half of all of those problems and the only ones that I'm left with are contract risk and VM risk which I can solve through formal verification unfortunately reciprocal validation requires a change to the base layer and it also requires an ordination of what the scaling solution is so one proposal is that you change the base layer and that's effectively what why network is trying to do so you can think of quiet Network as a scaling solution where we have chains that are outside in different contexts but we enforce reciprocal validation periodically and asynchronously and what that ultimately does for us is it gives us guarantees of atomic roll forward Atomic roll backward it gives us guarantees of finalization in chain context which is exactly one after one block um and it also allows us to scale so we don't get any of the sacrifices of the other scaling Solutions because we introduce reciprocal validation so what exactly is Qui Network Qui network is a hierarchy of merge mine blockchains so if you want to think of that Prime blockchain as your base layer we then have subordinate chains which run independently and asynchronously but periodically get referenced back into the base chain through the process of merge binding what merge mining does here is it creates a hash link which is valid in multiple contacts once that reference is available I can use that reference to do a proof to all data transitions that happened prior to that reference so I don't need an oracle I don't need to wait because if if that block which created that reference it rolls back it's going to roll back in all state in which that block is valid so there's no synchronization problem there's no oracleization problem and there's really no data availability problem because each one of the sub chains has the same set of incentives to carry on data availability in their context and so what is that this actually allow us to do it allows us to create performance subnets this uses a variation of nakamotive consensus and this can dynamically and horizontally scale with demand so there's no limitation to this ontology or this structure this is just an arbitrary starting point but if the chain algorithmically decides that throughput is being reached it can add more chains horizontally and the only long-term trade-off that I get is delay in global settlement so in one of the subordinate chains I can operate on 10 second blocks and if I'm only operating in a single context I will get performance just like I would see in ethereum however let's say I want to go from one of these blocks to one of the far blocks the sacrifice here is that as that width and the number of chains increases the point the time to settlement over that ontology will increase so that's the trade-off we've broken consistency with global consensus which allows us to push throughput so this is an example of what it looks like to do an eventual reference so say I have this block and I'm looking at this context if I start mining blocks I'll eventually create what I call a coincident block which is creating a hash linked reference between the different contexts so now all contacts that are just highlighted are now referenceable in that subordinate Cyprus 2 context and if I keep progressing what we'll see is that I'll eventually start highlighting the entire entirety of the ontology so you can see there was a time delay between a transaction happening in paxos 2 and being re-referenceable in ciphers 2 but we've asynchronously guaranteed eventual referencing so what do we call this we call this proof of work 2.0 so the idea here is that we can get layer 2 speed with layer 1 security and we can also ensure reliability because this is based off a truly distributed work based mechanism we can transact without downtime we're secure because we are technically bridging but if you understand the risks associated with bridging we've effectively eliminated all of them and then we're also scalable so right our goal is that we can do 50 000 plus transactions per second and as demand keeps on increasing we can dynamically increase the number of shards which will keep increasing demand our throughput okay so I got 57 seconds for questions if there are any builders that want to work on Kauai or have applications that they want to deploy on fly um come talk to myself or Raleigh when I'm done but if anyone wants a question um we're open for it go ahead oh no okay well cool guys I appreciate you listening uh and I hope everyone has a good time at Denver foreign [Music]