DappCon 2023: Towards Secure, Trust-minimized Optimistic Rollups - Ye Zhe

Transcript

hi everyone I'm joia I'm uh cor contributor of specular and also a PhD student in Berkeley RDI so today I'm going to talk about to World secure trust minimized optimistic rollups uh so uh like this is the overview of uh today's talk so first we are going to review the current optimis rollup and I'm going to talk about the uh security and decentralization challenges in the current uh today's rollup and I'm going to talk about our solutions to solve these challenges including the methodology and the system we're building specular and and evm Native Optimizer rollup and then I'll share some development status CH uh updates of uh

specular uh so first uh as we all know is R does not scale well so it has low throughput and high gas fees uh and most of the time so the question is how can we scale exem throughput without compromising decentralization so optimistic rollup is a uh like today's uh successful scaling solution to ethereum so uh instead of executing the transaction on chain uh the sequencer will sequence the transaction on chain but uh like the executor will execute them of ching and after execution and the executor will Pro uh will uh uh like propose uh a new state rout of L2 on chain and other

can check this uh State Route and uh if they find this state route is invalid uh this uh the executor can uh submit a pro proof to reject this uh State Rule and if no no other uh there's no challenges uh uh after uh the challenge window the the state rule will be accepted so in practice uh there's a massive liquidity in op robot that that's so that's why the reason we want to make it more more secure and more decentralized so in more than optimiz rollup they tend to achieve these object objectives so first they want lowc cost normal execution uh when the sequence only sequence the uh the transactions

and also uh they want uh reasonably uh low cost and bonded disputed resolution and most importantly they want identical developer experience to L1 this includes first same exclusion me and instruction level so you don't want a custom VM that simulating the uh the evm and uh second you want minimal to no changes to L1 contracts when redeployed on at L2 so these property are often referred as event re equivalence uh so both abrum and optimism today takes a approach called compiled approach which perform interactive FR proof over a compiled L2

a client binary where the the client consists of a custom L2 specific consensus client clients which in charge of a derivation pipeline Etc and the existing but modified is execution CL layer client implementation for example G so in case you don't know the interactive fra proof it's a interactive protocol for the Challenger and Defender to narrow down the dispute uh into a single instruction uh depending on the compiled VM so more concretely uh in this compiled approach uh they uh compiled L2 client into lower level Target VM for arbitrum is won and for

optimism is mips and they commit to uh to the result uh resulting binary on L1 using a vector commitment like for example the merco tree and therefore they can enforce the execution of binary at Target instruction level with the intive fraud proof so the key observation here is that the interactive fra proof verifier is enforcing the uh client uh uh execution logic so it's actually uh like uh like for example it's actually uh a guess compiled to wassom equivalence uh as uh for for the ariton Arron so then we notice that the the verifier

is strongly coupled with a specific client binary so so uh next I'm going to talk about the security and deenal challenge based on this observation so we actually found out that this observation is the root cause for the following challenges so uh the uh so first uh this architecture cludes uh permissionless trust minimize client diversity and second um the the trust trusted Computing base of this architecture is very difficult to audit and even invisible to formally verify and third and there are huge governance burden on frequently triggered upgrade process so next we are going to dive

into these challenges so so about client diversity so we uh we don't want a single client to dominate the network because it limited defense against multure failure and a bug in death a single CL uh client can bring down the entire network or cause invalid State transitions so why this architecture Clues uh permissionless Tres to minimize uh client diversity because uh on on chain the verifier is strongly coupled with a specific client so imagine uh that you compile gas to Wason and arogant to wasm the two resulting binary are completely different and their

execution traits are very different so if and the vifer is enforcing uh the exclusion of gas you cannot let Aron to to participate in the challenge and uh maybe uh so this is uh solu uh partial solution proposed by optimism is a k majority scheme so if we com instead of committing one binary we're committing n binary to unchain and if uh there's a k of n majority of uh uh clients pass the verification then we uh we say uh the the the pro fraud proof pass the ification so does this scheme help uh the answer is no because uh

first it is a permissioned client diversity so you don't want to uh want a malicious attacker to submit arbitrary uh binary commitment uh on train because it can allows the the attacker to Al to to change the L2 semantics so it uh so first it is on permission and second uh it uh uh it is operation complex because all the validator needs to run all types of clients to participate in challenge since the execution traits of gas and Aragon are different you can now let them to do the interactive fra proof and and like convince a single verifier that

who is Rong and who is right so the Valor has to run all the nodes and thirdly it does not scale um so as we know the current Ro l uh clients uh consists of consensus layer clients and excution layer clients uh but in this compiled approach these two clients are compiled together so for example if we have three types of consens layer clients and three types of execution layer clients uh the like there are nine combination of the binary so the the operator has to maintain the nine binary commitment on chain and all uh and these validat need to run nine different types of uh uh clients just

for the challenge so this is like kind of like unacceptable unacceptable medication to the client diversity so the second problem of this architecture is that uh The Trusted Computing base uh is too large and parties must trust the correctness of the entire stack uh including the client uh to implement the evm correctly and the compiler to compile it correctly and and also other components why the TCB includes the offchain components because the offchain components like the offchain clients are committed on chain so this huge uh trusted Computing base

is difficult to audit because like you need to audit like for examp every changes to the uh guest clients every lines of the consensus clients and also maybe the uh the compiler or like like your your make file to to make sure or like the compiler options to make sure you are compiling correctly so this TCB is difficult to audit and INF feasible to formally verify because once again the TCP is too large and the third problem is that um it has governance burden on uh on the frequently triggered upgrade process so uh ideally we want to ship like uh we

want like ship the uh performance patch and the vulnerability patch of offchain components without touching the onch components but in this architecture you cannot do so uh because every option component uh touch uh upgrade touches the TCB and this put the L1 governance on the critical path so if you change one line of gas code uh maybe the the the compiled wasn't binary or the maps binary is is different right and the commitment of the of the binary will be different so you have to upgrade the unchain commitment um so this governance

dependent upgrade prevent uh the possibility of filary of upgrade keys so uh now we know the challenges uh in this uh in the current optimistic rollup let's talk about our solution to solve these challenges uh so we know the root cause of these challenges are that there is a uh binary commitment that make the verifier coupled with a specific C uh client so uh we need to eliminate that uh binary commitment right so the op reservation we have is that we must

decouple the protocol from implementation so to decouple them the proof system must natively Target a higher level L2 semantics instead of uh uh targeting a lower level VM semantics so this uh semantics include both uh consensus layer uh semantics and execution layer semantics so more concretely um just like their approach uh our solution also uh reuse the existing uh eum clients on L2 however we are going to uh design our interactive FR proof system to enforce the evm semantics directly instead of like enforcing the Wason semantics with

the binary uh commitment so we are going to uh construct our one step proof over uh evm State transitions at evm instruction level so and also the consensus uh level State transition uh so sorry the this architecture seems simple but it has uh a lot of uh nice uh properties that uh that solve the previously mentioned challenges one by one so uh so first it has intrinsic client diversity because like your verifier is not coupled with a specific client uh binary anymore and um so for like for

example for for on the execution layer every clients uh uh despite their difference maybe they they impl differently or they are using the completely different programming language they have to implement the evm state translation exactly as the is room specification which is uh the yellow paper so in this architecture any clients can uh that implements the EVN can be used to participate permission l in the dispute resolution and we only need to trust one of these Implement correctly to make sure the network is secure and also like in this architecture it uh allows like it has uh low operational complexity and scale

with diversity and the validator can run whatever node they want and they only need to one run one node uh second uh this architecture has M trustworthy uh uh TCB the and the T TCB is only the untr verifier the option components are not not in the TCB anymore and this TCB uh first it is very small uh it's just the smart contract so it improves AIT auditability and also it is uh formally verifiable because we have existing formal specifications of etherum such as stepan evm or KVM we can use them to uh to uh to formally verify

our TCB to make sure it is correct and third uh like it it has infrequent on TR upgrades so uh it only needs to be upgraded when the semantic change like for example when there is a e help work that adds a like a up code a new up code and if you have like performance improvements or vulnerability patch in the in the option clients and that like for example you change the gas without touching the ethereum uh semantics you can and this uh patches can be shipped without arain upgrade so in we claim that this architecture is practical to fulfill the upgrade key so uh so this is uh how we designed

the uh EDM native inter fraud proof verifier so basically the verifier uh like during uh when when when the dispute goes down to the onestep uh evm instruction level uh the def either defender or chager uh re partially reveals the evm state to the verifier so the verifier can simulate one evm instruction on train and compare the final evm state with the assertion to uh to decide the winner so in order to partially verify the EVN we uh designed some uh data structures for different evm components like for example we merized the memory we use the hashing to

model the stack and as we all know like the the world State like the the storage or the account is already uh merized by the mer merco Pat Tre so in this uh St structures allow us to par reveiew the uh the the the evm state to to make sure the verifier knows the enough information to simulate one uh evm uh instruction so uh in uh in specular we implement this uh intive FR proof uh verifier and also the prover and the the peripheral features to make it a uh a complete optimistic rollup in the current uh

implementation uh we support all the semantics depend defend defined by the uh etherum spec and we only modifies 200 uh lines of code in gas to make it possible like in comparism optimism has 3,000 lines on changes and opum has even more so um in specular we have this uh design philosophy to guide our future directions of uh of implementing the uh and the optimis r up so on the security side we want trust minimization that is a bug or exploit in one client software stack uh have should have negligable impact of the systems overall security

and on the decentralized side we want the credible neutrality that is a valid uh validator should be able to just uh uh just in the case of uhan operate a premission l use any client software Stacks existing or new of their choice of their choosing so you are not limited to a single client that you uh that an optimistic roll out project provides so before I go into the development updates uh uh this is a takeway chart uh for for the previous sections uh like for uh for specular we have minimal minimal client modification we have small TCB we have intrinsic client

diversity and our upgrade uh is infrequent so next is the development updates uh beside the uh Novo uh evm Native interactive fra uh fra proof we also uh Implement a client agnostic uh L1 to L2 message Bridge which does not uh require a new transaction type or any other further modification to the client so that's the one reason why we can uh make our uh uh like client changes so minimal and also we uh in the implementation we have uh demonstrate uh our uh prodical client diversity so when implementing the optimiz LA we decouple

the consensus execution uh in a modular way in both normal operations and dispute resolution and for execution layer diversity and beside the gas we also implement the interative fra proof approver in Aragon and and in CL in consensus layer diversity we are trying to transition to a new rust based client by extending new optimism uh client called Maggie which is built by a16z so um so that's the work we have done and next we are going to to deploy our first test net uh like uh very soon maybe end of uh September or starting uh

the start of October and we also doing the formal verification of our TCB which is the unchain verifier so we are verifying it against the existing formal spec uh called dafne so basically we strike the semantics uh from this smart contract uh and we compare it with the Des spec and we also we're also doing the sensorship resistance mechanism by first inclusion so in the future uh we want to explore the sequencer decentralization uh with me resistance uh resistance so we want this decentralization to be first permissionless and also uh um me resistance with u like proposal Builder

uh separation like approach we we want to improve the normal execution gas fee by uh introducing uh snot friendly batch comp uh batch data compression and we also want to improve the dispute resolution gas fee by maybe implementing the one step proofing snark and this is not conflict with the uh uh with the with the verifier we already implemented because uh this not is hard to form verify so we can maybe have uh two verifier both on train and let our current verifier to have higher priority because it can be formally verified so that's my talk today uh you can find me uh find us on Twitter

and website and feel free to reach out if you're research or engineer interested in collaborating or you are application that is interested in uh like uh participating in specular ecosystem thank you thank you yeah we have about five minutes for questions all right if not then we'll we'll wrap it up there uh yah thank you so much for your talk today and we'll get started in about five minutes