Yaoqi Jia (YQ) - MACH: A Fast Finality Layer for Rollups Leveraging Restaking

Transcript

okay well welcome back everybody sorry about that it was we were switching um platforms here um our next speaker here is yq yq is the founder of um alt alt layer and uh he's going to be speaking to us about um uh mock a f a fast finality layer for rollups leveraging reaking like you thanks for the introduction yeah uh great to be here and um yeah today we just introduce our latest research around this faster finan layer uh especially for the ethereum rollups and by leveraging the risk taking so this is a collaboration together with igon layer

and also risk zero team so later I will show you how this magic uh achieves um so why we talk about F fast finality for especially for ether rollups because uh earlier we are building this orchestration layer basically for all the different rooll apps we help our partners like games and social application and also def applications during this perise by setting up all the Rolla for them right we figure out okay there are lot of requirements and demands from them to really build a faster finality layer for bridging services and sometimes and also for their defi application services so on top of the layer we're building right as

you can see it's very straightforward you can quickly launch your roll up where the dashboard so I I think um when we get into this faster finality we need to know what's the current status of the finality on ethereum and also the Rola space I believe most of the audience here right you are quite into this ethereum stick staking space so as we all know typically we call ethereum as the settlement layer so as a settlement layer basically we have uh some very important functionalities the first one that we all know that we we have lot of this verification Logic on ethereum for different rabs for example optimis rabs and also ZK rabs typically ethereum

really handles all the verification for both um sort of f proofs and also validity proofs this make ethereum really as a settlement layer uh beyond that we all know that right now in crypto space we have most of the liquid assets on ethereum not just about ether but we also have the r BTC and the various the stable coins in total like all the assets make ethereum as the sort of source of liquidity so either for different rollups or different l1s typical they borrow the liquidity from ethereum it also make ethereum as the importance of this settlement layer and beyond that as I just mentioned right for the other layers like raps or

alternative A1 they borrow this liquidity basically where the decentralized like messaging protocol or different Bridges just to really uh try to guide this uh source of fund from the ethereum and uh typically when we see the finality this word there's a proper definition for it for example when we send a transaction right typical we say uh there's a finality for the transaction that so basically the block that includes this transaction can't be altered or reverted or modified without having the control of super majority of the network so then I have a quick question like for ethereum right now after this um post right so you feel

like the finality for ethereum is 12 seconds can you raise your hands or the finality is over 12 minutes can you raise your hand yeah so I that that's why I say like most of our audience are the experts in sticking right so um I will show you that because right now even after post actually the fany for ethereum is Du over 12 12 minutes or 14 minutes so the the if you look at the details right right now in the ethereum system as we can see uh there are multiple blocks and within a block we have 22 slots and typical for each slot you can see that it includes like sort of the transactions within that that

block and each slot is 12 seconds it's precise or accurate 12 seconds so it's deter M stake not like before the P it's p right will say it's roughly 12 to 15 seconds but right now is exactly 12 seconds and after that within one Epoch we have 32 slots and typically when we say a block is um Justified is when there over two3 of the validators in typical committee attested okay that block is fun and we sign the signature so we call it like sort of Justified and after that right after typically one

block one OC we can see most of the I mean honest or good validators they will just um like continue sending the um like sort of the slots and confirm that okay the for the past lot of slots they are fun um and after that when we say uh slot is final ANZ typically it's after already after two EPO and when we see two EPO right as you can see one Epoch 20 uh sorry one Epoch 32 slots right two Epoch typically it's 64 so after two Epoch we can really confirm that I mean with super high probability that uh the

block the slot or the block is the finalize so in that case we say this is the final finality on E typically it takes like uh uh 12 minutes or even longer like 40 minutes in that case with the latest consensus protocol of ethereum FFG so basically it's um really really confirmed on ethereum so that's why um sometimes if you Lo uh if you use exchanger right even after post we can see that okay uh a transaction or uh already included into a slot into a block then it should be fine right but at the same time uh for most of the central exchange this still wait for over like 15 minutes if you really look

at the like s of number but this finality time is quite crucial to rabs um why I mention about this um because like for most of the rollups right as you can see typically we say the finality for rollup is not like the sequencer uh sequence of transaction or execut transaction T takes like U one to two seconds but that's not the real finality for rap we call it a soft finality so when we say there's a finality typic we say the transaction or the block uh from these l2s or the rabs can be finalized on ethereum then we call it like sort of relatively hard finality for a RAB so in that case if

you look at this um diagram right um as I just mentioned for R typically there are two finalities one is like softer finality we know like for optim arbitrum uh or even like latest polygon zvm and screw uh they all have this um rely uh single sequencer to basically precise all the transactions and after the precise uh precising uh like sort of the transaction you generate the blocks on the L2 and after that it depends on the mechanism they use either they post the St hash to ethereum First and after that they post like sort of the com price transaction data to ethereum or

like for examp polygon ZM they prefer post all the like sort of data to ethereum first after that they generate proofs uh for that with their proof and after that s they put the proof to ethereum again for the final verification of the proof so um in whatever Cas is right as you can see the soft F mostly is on the sequencer side uh since right now most of the rabs they're using a single sequencer is roughly like trm BL model and uh if if for some famous project right like this optimism or base or even like a different Zab right we know that they they won't leverage sequencer to do

malicious stuff like reordering or front running or even double spin so in that case the soft finality should be fine like two seconds but for most of the rollups for example we help them to set up right there are some gaming companies the there are basically nobody in the crypto space or some social application there are new companies they don't have that kind of reputation like like you to really blindly trust them so then how we solve this um issue about the faster finality of course the soft confirmation won't be enough for them and uh but at the same time if we really wait for the hard finality for example uh the sequencer post the data to the L1 like eum and then do the verification it

typically already takes U um a lot of minutes right and if it's a proper proof system like ziky proof you need to with the proof to be posted on ethereum that typically takes like half to one hour to generate the proof and for optimistic rollup typically it takes seven days for a challenge period um but for lot of these rollups or the customers we are serving right they want something really fast ESP special games right for the fine game project they want to have the similar experience like a web tool like 100 millisecond latency or like roughly like that so in that case um how like basically we handle the treat off uh for

different uh projects on the finy requirements um typically especially for the general purpose r2s or rollups right um we are sort of okay with this relatively uh slow finality or confirmation um thing because as I just mentioned right for most of the general purpose l2s we know their brands we know that they don't do malicious stuff with high probability but for some of the new projects the they don't have such high reputation in that case we need to find a way to provide like sort of a faster finality for that so that's sort of like we come up with the idea okay we should build this uh uh new sort of like

mechanism to really uh provide this faster fin uh for the zabs especially the rabs don't really have a very strong brand like people don't really trust them it's sort of like the slogan we already say that don't trust just verify um and designing this F fan rabs right typically we have a bunch of U uh like these requirements or goals we want to achieve like sort of like uh we want to have this kind of uh fast confirmation for rooll up transactions without much uh Trust on the uh entity itself beyond that we want to leverage some cryptoeconomic security to handle the different malicious vectors and since we

already have very uh Diversified uh landscape of rollups like of op um stacks and also some various ZK rollup Stacks we want to basically handle all of them and also for different runtime beyond the evm we also have wam meeps and res five or different run times we want to handle as many as possible so that sort ofice I just mentioned right with all these background so that's the uh real rationale behind this m protocol basically we want to have like sort of a uh you can treat it as middle wear layer or something to do this uh uh provide this um fasy for different rollups at

the same time just want to ensure that we have enough verification resources can provide the trust for uh different parties without really have the Trust on the single brand and uh and how about the basic idea the basic idea as we can see right uh if you don't uh have all the Trust on the like sort of single sequencer typically the best way for a third party I okay I can run the full node I just reexecute all the transactions and to reproduce the state transation for it so that's sort of the very basic idea but but as you can see right um if you want to run a full node for optimiz arbitrum tal right now takes

you a lot of resources like even for the sinking it's like over two terab data so it's quite like sort of difficult and beyond that what are the servic on top of it you can provide typically as we can see right uh most of the bridges and the cross chain messaging protocol can be on top of it because once you have the fany on the RAB a with proper verification and also on the r b so then the external parties can build protocols on top of it just to like sort of okay we already verified the uh State transitions on RAB a and also RAB B so we can just pass a message with a lot of confidence um in the real like sort of design the implementation we sort of um

uh categorize um the modes into three different um and uh categories one is the permissive note and then is optimism uh optimistic uh mode and also the validity proof mode um for the pessimistic mode right as uh I mentioned it's sort of like a little bit stubborn way uh you just reexecute all the transactions and uh just reproduce the state and just make sure like uh the MPT TR and also the like State transitions are correct so in that case um the most like sort of stabb way is like to run the full no for different Ro laes but it's not the ideal case because it's too

heavy um so that's why on our side we're building the St list clients for different uh Ro laes and um we already have something for op stat so soon um we can provide for all the audience here just to run uh the noes as part of the network to really do the verification and provide the FAS finity layer for the public and beyond that we also have some interesting uh tricks on it right uh instead of re-executing almost everything for the existing transaction and blocks um you can have some optimistic way similar to our optimistic rapse you can do this uh we can assume the sequencer somehow um they always behave uh like normally right um there

typically um you are running your own project right you don't really have the intention to ruin your own product right except you are doing you want to do the scammer at the beginning so in that case we assume the sequencer somehow um wants to really perform the correct State transition since the beginning so in that case we can uh sort of run these nodes in the mark Network right to monitor these State Transitions and we don't do the active like sort of um uh like re execution it's just like sometimes if something wrong and then we use method called is um optimistic mode basically it's a BSE section protocol

between the sequencer and also the nodes in a mark Network so we will identify um sort of which like uh transaction or even the instruction level um is behaving wrong so in that case we do the B section across different blocks and identify the block further identify the transactional instruction inside that block to basically um like figure out who is behaving wrongly so that's a way typical we used for the fra proof or fall proof in the optimistic rap and beyond that um with the collaboration with res zero we further develop these called ZK for proof U models um instead of doing this um uh bsection or the

fraud proof very complex protocol between uh several parties we sort of like uh generate the ZK proof for most of the uh precise in the in the middle just to remove as much interactions as possible but the cost of the treat of D and to generate the proof right typically it takes a longer time for example uh for one block it takes like over 40 minutes and the cost around like uh less than $100 but still um compared to the previous model it uh it's very costly but at the same time you can reduce a lot of these interactions uh between different parties and then uh this is the last

mode and this mode is very heavy somehow as I mention right uh since we already have the ZK proof uh in place so in that case uh we can always generate DK proof for the past Ste transitions as much as possible in that case instead of posting all the proofs on ethereum you can treat Mark Network as a middleware layer or you can you can treat it as a virtual layer you can can put most of the proofs on this MK Network or replace it with some other l2s or l1s just to make sure like can you can always get the proper verification from this proof about the state transitions so with this um let the three different modes uh for uh the

faster faner right it really depends on um the application of the project purpose for different purpose you can leverage like sort of different different FAS finality mechanism and at the same time I just mention right um there's a tradar between the cost and also the security guarantee you want uh of course everyone want to see that okay Z proof is always the best right so we can do all the like sort of proof generation and verification just make sure everything is executed correctly but the treat of that the Pro cost is very high like U every month probably just for approver you need to pay like um around $10,000 something like that

but at the same time if you want to um like reduce the cost you can L some optimistic like sort of verification mode right uh the in that case the cost are very low you just need to run some normal validators and for it but at the same time you don't really have the same guarantee of the ZK proof um so as one of the first implementation for this fan layer we leveraging like sort of the um IG layers design by running some of the um Mark Network notes like the ABS operators basically we borrow the security guarantee uh from the IG layers um and then use the security guarantees

as the bond for these EVS operators for the mark Network so in that case um as you can see right if you if we put these EVS operators back into the mo three modes I just mentioned right if uh typically their behavior cly right if they are behaving wrongly uh you can see there is a slashing mechan so with a proper proof um like basically can show that these guys are behaving wrongly and we will sash this um uh sort of the bond from the borrowed from this I res King side um the existing status I show to you right we already have this proper fast finity implementation for um some of the RO apps which we can compare to

wasm and uh and some uh some of them actually like this op stack and some other roll up Stacks so in that case um for the audience here if you would like to try out this um kind of um fany uh operator right um like very soon I probably next month we will roll out some uh detailed tutorials and instructions for you to register as this uh operator as you can see right and um and after that you can opt in where the platform and by running uh some of these operators and to do this either um the optimistic way verification or do some like very um heavy uh ZK proof

Generation Um and as the conclusion right um for lot of um existing general purpose L2 rollups um they are probably fun with uh the very big brand and basically people really feel like we don't need to do extra verifications for um the sequencing so in that case like the soft confirmation from the sequencer should be okay but for the longtail rooll apps which we don't know they brand very well and also some new project right so in that case it's better we do some verification instead of blandly trusted them in that case um we need to leverage some fasy mechanism

like the MK system to really provide this extra confidence in sort of the transaction they executed um on the RAB side and beyond that with this F finy layer we can definitely have lot of interesting Services built on top of it like this bridging across chin across roap messaging protocols and uh yeah so that concludes on my talk if you have any question feel free to ask thank you [Applause]