Mikhail Kalinin - EIP-6110. Deposit reform

Transcript

well thank you very much for staying in here and thank you very much to our next presenter here for offering to speak earlier here so we could all enjoy a little bit longer lunch so with without Much Ado let me introduce Miguel who's going to talk about a new EIP that I'm not familiar with and so I'm looking very much forward to this thank you for the introduction hello everyone again so we'll talk about deposit reform uh which is a fancy term uh denoting the EIP 6110 proposal which is in one sentence can be said as an optimal way to deliver a vol deposit to the consensus layer a quick reminder of how depositing is happening in ethereum network a Seer prepares deposit data then it submits them to the deposit contract in a regular uh transaction on the execution layer where

it's been processed uh after that happens the eth1 bridge takes this data and put them into into the bacon chain uh where this deposit data is being processed by the consensus layer and the new layer is created so uh this this proposal does not affect the deposit contract logic it also does not affect the consensus layer logic uh including the activation queue so the huge activation queue that we observed recently would not be affected by this proposal if it were in place uh so this proposal is mainly about the replacement of the Ethan Bridge um and a fair question to ask here would be why do we want to replace the um the thing that already Works um yeah and next slide

during the next slide will figure out why um actually we should we should do this okay so um yeah let's examine the design of the bridge um a bit uh so we should step back a bit to the premerge time so what you see is the um actually the outline of the mechanism that uh uh this how the bridge basically Works worked before the merge uh it is implemented as a proposer voting proposer submit eth1 data into every bacon block that they propose uh e one data includes deposit tree root deposit count and block hash obtained from the proof of work block or from the

execution layer block um at a certain follow distance once proposers come to agreement on the eth1 data they start to include deposit data into the beacon chain uh fetching them by uh gar pcpi from the execution layer clients that's basically how uh the merge sorry the bridge looks like and what happens with the bridge during the merge um actually nothing has happened we still have uh this bridge in place which maintains the same logic uh but there is one major difference uh it is that uh the bridge fetches data today that are already secured by the beacon chain so it means that this bridge is entirely

redundant uh so we have the bridge so what um yeah first um what do we know about Bridges bridges are insecure in general I would like to emphasize that eth one bridge is probably the most secure Bridge uh in the entire blockchain world um because it's ruin by thousand of nodes running a variety of client software uh with a rich client diversity um and yeah even though this bridge has own um issues for instance there is the um design flaw uh that undermines the security of the core protocol an adversary controll in a slightly less than half of wers in the network uh can basically induce validators uh from the deposits that

were never submitted to the execution layer then these validators can be uh withdrawn illegally printing a decent amount of e or other nasty things can be done with them um but this this issue is more on the theoretical side of things because it is really very very unlikely that that on the main net there will be a party that controls uh half of others um yeah aside of yeah aside of uh theoretical there was a practical issue what you see on the slide is basically the incident happened about six months after the Bon chain launch um this what you see is a prism client fails to propose

blocks uh cing a mass uh empty slots on the bacon chain main net um and the reason behind this failure was the bug in the deposit caching which is a part of uh Ethan Bridge implementation in the prism client and I believe in other clients as well um yeah fortunately finality was not affected uh that time uh thanks to client diversity and thanks to Prismatic team who fixed this issue quite quickly um yeah also bridges are complicated uh the E1 data voting B basically is a quite complex mechanism so it's can it description it it

specification is quite complicated and uh yeah what we see here is basically uh the issue appeared in one of the uh merge prototype Dev Nets te um stopped in this devet te stopped produce correct E1 votes uh which actually prevented new deposits from being processed and new validators from being created yeah this issue never appeared on the mainnet because that devet run ran completely different uh configuration than mainnet runs but uh uh nevertheless uh it highlights the U potential bugs that uh that caused by the engineering

complexity of of this construction and also um who knows uh what potential bugs we may still have today in the clients that can appear later on um yeah so and Engineering comp complexity is not uh the only kind of complexity that is related to the bridge inside of that there is a not operators complexity uh various situations where consens layer client uh is failing to fetch deposit data from the execution layer client keep securing today uh which is especially maybe especially annoying for home sckers who when setting up their nodes has to deal uh with the something like that instead of

just enjoying running their wellers at home um also um yeah so also this is like uh yeah I would I would like to say that uh this complexity comes from the relies on the Json RPC API and different clients different consensus layer clients use different uh Json RPC API methods to request uh this deposit data so it's like it could be misconfiguration ation it could be an interop issue between the client and server implementations of the jsonrpc API so yeah but this issue occurs today which is quite annoying U this not yeah that was not the only complexity that operators are suffering

from there's also the data complexity um uh this because the PCH and the entire history of deposits is quite annoying and quite P painful today because it takes a lot of time and uh thanks to e dreamer who came up with the The Proposal of deposit contract snapshot uh which basically allows for a consensus uh for a consensus client to be bootstrapped with a snapshot of a deposit tree instead of spending the time and fetching all the uh entire history of deposits um yeah but to my knowledge not every um uh consensus client actively uses uh these snapshots today so some of them are still uh

requesting and historical deposits VI CPI also uh because of this historical data complexity uh this deposit contract snapshot proposal is kind of a requirement in the context of the bridge it's kind of a requirement for uh blockchain data X proposals like for fors so it's kind of like a requirement and all the critical path to that um and uh yeah um the right request from node operators just to disable uh deposit thinking entirely for nonv validating noes because nonv validating noes does not basically need this data at all and consens to their client doesn't have this option uh yet so um yeah Bridges can be slow I don't claim that every

bridge is slow but e one Bridges uh is slow it takes 12 hours to deliver a deposit from the execution layer to the consensus layer uh and uh in the current design we basically can't do much about it so reduce using this number would undermine the security of the bridge hence the uh entire protocol uh so we would probably need to change the design of the bridge but why would we want to change the design of the things that is already redundant so we went through the complexity in security that might be or related to eth one Bridge uh and basically uh now um let's talk about the solution so this this solution is simple

let's just deprecate it let's just get rid of it so how can we do this so what we basically do as I've mentioned previously the Bon chain already secures the data the deposit data it which means that it has a direct access to those data uh with kind of one problem um it can't ensure validity of deposit transactions and it can't parse deposit transaction logs to uh extract deposit data and uh what we do is basically defer these responsibilities to the execution layer clients so execution layer clients becomes responsible of two things um during creating a block during building a block um the execution layer client will have

to scan through uh the transactions that are supposed to be included in the block uh in order to find uh those transactions that that produce deposit data uh pars them pars these deposit data and include them as a separate list into the same payload uh when a node receiv receives the block from the network uh the execution layer client of this node uh will basically validate um this deposit list verifying proving that this deposit list is correct with respect to the transactions included in this block and after this validation passes uh consensus l a client can take this deposit data uh and process them as

it basically does today so uh no security checks on the consensus layer side is required uh the security check happening on the execution layer side it means that the deposits will be processed in the same block uh in which in the same block uh where deposit transaction is included so it's kind of instance processing of deposits it benefits many um participants of um of the ethereum community um all with the ethereum network protocol uh Network stack uh first of all IT addresses the design flow in the core protocol making deposits as secure as uh the core protocol is um it gets rid of the eth1

bridge code from consensus L client significantly reducing the complexity of these clients um it also the new proposal does not rely on Jon orpi which means that node operator complexity will also go go away once this uh lands uh once this proposal lands the main net um and after all it improves uh the deposit process in ux uh cutting the time to process deposit roughly by 60 times which is just nice um yeah of course as other other proposals this proposal um comes with its own complexity there is a negligable chain data growth it's roughly about uh

100 megabytes per year uh which can which is actually nothing uh it opens up a potential dos Vector um this is because an adversary after this proposal uh is activated an adversary will be able to include uh up to a thousand deposits into one block uh delaying the processing of this block by a second this happens because uh uh processing of every deposit involves signature verification which is computationally heavy operation but this attack VOR is kind of not not considered as a sustainable uh because in order to make this in order to induce such load uh an adversary will have to spend uh quite uh high amount of uh value uh so uh which

means that the potential outcomes of this attack for adversary uh are outweighed by the cost of this attack there is also the execution layer CLI complexity as I mentioned uh there will be a couple of responsibility that execution layer clients will have to handle but this feature uh the implementation of this feature on the execution layer client side is kind of self-contained it has high testability because it does not involve any networking uh networking stack stuff it's just basically block creation and block processing which can be pretty well tested and once it test tested in the clients and implemented they would not require any attention uh on Words

there is also the CL uh client complexity which is about managing um the while POP key cache so after all yeah there is a transition period also um why do we need transition period in this case is because um because of the huge follow distance that Ethan Bridge has which is about 12 hours uh and once these onchain deposits are activated there will be a gap of not processed of not yet processed deposits last for 12 hours worth of uh block space and we'll have to wait uh for eth one bridge to cover this Gap uh but once this happens uh the E1 Bridge can be

deactivated uh without any uh additional coordination so it's like transition period is definitely a complexity uh and consens that client and blockchain data services will have to support two machineries at the same time uh but this is kind of like onetime complexity we don't have to deal with it in the future future once the transition is over I want to talk a bit about of the 6110 status uh the design and specification are pretty much uh solid um there's also consens test vectors which is nice um there is a working prototype uh built on with the lighthouse and bazu um during this type project we ran multiple Dev Nets uh we

testing the core logic testing the transition period logic also we were doing stress testing uh there was devnet producing a blocks with eight about 800 deposits each we were measuring uh the performance of clients um under this load uh many thanks to everyone who made this project happen I I was really enjoying to being a part of it this QR code would lead you to the U detailed report uh of this project also uh there is a lar implementation which is near to be finished I also know that t is doing looking into Implement in 6110 and I would like to encourage every other uh especially execution layer client to implement this feature it

could be a really nice project uh really nice starting project for one of your external contributors or for a new member of your team because it's like uh it's it has moderate complexity and on the other side it goes deep into the um block processing and block building stack which is kind of nice it does not has any doesn't have any uh networking specifics uh so yeah please consider this for U for the kind of like really a good uh first project for everyone is coming to the team or starting to collaborate with it yeah so uh this proposal is kind of like strict Improvement to ter network security and

ux which makes me personally pretty confident that eventually it will be on the main net uh just a matter of time um yeah thank you for your attention I'm happy to answer questions any any questions from the audience here perfect so um 6110 basically relies on all the consensus layers to have uh deposit snapshots enabled uh implemented is that correct sorry Sayes e 6110 require all

of the consensus layers to implement uh deposit snapshots oh no no no no sorry if I messed that up so deposit contract snapshots is required for uh blockchain data exper proposals like 44s if we will if the bridge will uh if we retain the bridge so we'll have to do something with the historical data we have to produce you know snapshots uh to put strap nodes because this data will back expired basically but with 6110 you don't have to do anything about that you it actually 6110 makes no use for for 48 881 for this deposit contract snapshot

EIP sorry e dreamer cool it seems though that like um 61 would be for new deposits coming in how would we get if we're not using Json RPC to get to parse deposit logs how do we get the pre-existing for a new for a newly syncing node how are you getting the uh deposits the existing deposits oh you you didn't have to uh get the historical deposits once this is activated and uh the Gap is filled because all those deposits are already uh on the Bon chain so the see consens slay clients fatch deposits because they they need to propose new blocks this is why they doing this um if we replace the

bridge with uh with like on chain deposits uh this will no longer required so no uh no jsonp requests anymore will be needed yeah I forgot to mention that it produces sometimes enormous amount of Lo on y clients which is really um not good all right any other questions from the audience here okay well again a round of applause for our speaker please thank you that concludes our morning's um program here it is now time for lunch

which is just right outside the doors we will resume uh back on schedule which I believe is 1:35 check my math on it but back in the room at 135 okay