All Core Devs - Consensus #136

Transcript

for [Music] Jesus [Applause]

okay we should be live and from here let me grab the agenda there we go it's there in the chat so yeah

Alex Stokes: everyone this is oh wow my computer is not happy there we go sorry about that uh call 136 and uh yeah there are some things to do first uh before we get into um Electra so let's just hop in the first one uh let's see is Yum here handle yeah maybe this is yeah hey if

you'd like to give us an update on your work that'd be great

Jorge Arce: absolutely thank you uh is there any chance I can share my screen

Alex Stokes: you should be able to

Jorge Arce: oh I can I can yeah I see the I see the I see it now thank you sorry let me it this differently okay can everyone see my full screen

Alex Stokes: I can yep

excellent all right

Jorge Arce: uh hello everyone it's a great honor for us to be here um my name is

jar I am a blockchain cryptography researcher at nerm mind and today we're going to be talking about our work allowing validators to provide client information privately this is a work supported by a grant by the ethum foundation uh first a little bit of background that we're going to be assuming in the interest of time and because I'm sure the agenda is backed also looking at the at the audience um we are going to be uh sort of like assuming the following uh points are familiar if not I would uh if there's anything you would like a quick refresher on regarding the things I'm about to say um we are going to be posting a link in the chat to the full

um research deliverable which goes into more detail into these things we're also going to have a QR code at the end for those watching this in in the form of a recording or on YouTube so we will assume you have heard about the current client diversity estimation methods things like block print uh ether nodes and surveys such as like super majority. info or so uh we assume you have some familiarity with uh their current uh limitations and weaknesses also um you might have heard of a proposal by E streamer which I think is also on SC by the way um to provide the necessary changes to the

protocol to allow validators to post their client diversity data on the graffiti field this is a solution that has already been discussed by the community it's sort of like a lightweight uh approach to getting having us get more client diversity data and so that one uh is also part of the background cool so in in light of those things um especially if you have heard about them before and you have heard about some of their limitations it might come as not surprise to you that we're interested in modifying the etherum protocol to allow validators to report this data in a way that is to say more canonical more direct uh of course without compromising the the the core

functionality of the protocol the performance of the protocol and so on moreover we explored the possibility of making such mechanism Anonymous that is making it so that the data is shared in a way that um is decoupled from the validator index and if we're able to pull this off can we maintain accuracy security privacy and performance and how much so this is what we're looking into today uh the results of the of the research and once again we'll be having the a link to the deliverable in the in the chat we'll be sharing a QR code at the end for you to read this in more uh I more carefully this is more of if

you're interested this is more of a sneak peek into the main ideas so for method one client diversity data on the graffiti field where each block proposer writes an encoding of the E plus combination on the graffiti field by default we're not going to discuss a lot about this here we refer you to the relevant e research discussion uh we will say that at least for the goals as we defined them before one challenge that this method has is it becomes quite difficult to anonymize such graffiti field reports because they are coupled to the identity of the validator and it's very hard to work around this using any kind of cryptographic building blocks because

you just have very little uh size or very little space in the graffiti field to work with so one of the first things we came to realize is that in order to use any of the let's say standard techniques for privacy or anonymity that would come to mind mind you would need a channel where you can uh share data that is uh allows for sharing for larger data blocks than just the graffiti field so how could that look like let's go into our second method um we're calling this share data through the gossip Network plus use nul thees for privacy what we're going to do here what we're going to propose here is a generalized crawler method of sorts so instead of using the

request response domain of peer-to-peer which is how cers currently work they query notes and they get back information from them we're looking into flipping that on its head and using publish subscribe um we'll see some advantages to this but H how would that work like how would that look like and how do we make sure we're not just breaking the network by proposing something like that well consider the following for iteration um have validators encode their client or be able to encode their client divers data into a client data object uh right now for just first iteration we won't consider privacy we will add it in the uh a few slides from now we will explain how the Privacy comes into the picture and have the protocol periodically and randomly select the

sample of validators that will be publishing their client data much like how the protocol currently chooses a sample of validators periodically for sync commun duties or for adastation agregator duties let's have the validators uh in the sample gossip this client diversity data on a dedicated client diversity topic through gossip sub if they happen to not be subscribed to Topic at the time they can use the fan out mechanism to share the the data and so for the notes that are subscribed to the CLI diversity uh topic they can gather this reports they can verify them independently aggregate them and publish them um on their own similar to how crawlers work nowadays in the

sense that every single crawler can provide sort of like their own uh dashboard their own uh visualization of the results and anyone else can can also play the role of a crawler and verify the the accuracy of this uh information so the object that we're looking to share uh this client data container so it would have the slot number the encoded client data let's say we're encoding the client data in 32 vites similar to the uh client data on the graffiti field proposal we're going to have a signature for the validator in order to see whether it actually belonged to the sample at the time or not and the validator index if we do it like this the container size is roughly

144 bytes which is about 50% of a current e theorem atation so by itself it's not a terribly large data object that it's being sent but we need to think about how many of those are flying around the network at a given time and we definitely want to use samples to avoid Network overload we don't want to have the entire validator said be send in these uh objects at a time we might want to be working with samples now how large should that sample be and this is a general observation that applies to uh we made in early in the research and hope it would apply to all the methods for assessing client diversity so if you consider in order to consider the statistical significance

behind this uh if you use the standard statistical theory for surveys like this is essentially where we're running a survey on the on the validators we find out that with a confidence level of 95% which is standard to these kinds of application the following error rates are going to hold or error margins if you choose a 9.6k validator sample then your estimations of client D diversity are expected within a 95% confidence level to have up to a 1% error rate if you multiply that by four that is if you run with a 38k validator sample then the error rate goes down to 0.5% which uh is not too shabby now if we let's say gather one client data object per slot um following

in the footsteps of the client diversity on the graffiti field method or you could uh rearrange it to be 32 per Epoch like uh sort of like batet like this to allow the clients or the validators time to prepare the data send it so on and so forth then you would be reaching these targets for sample size in 1.33 and 5.33 days respectively so this might be a bit counterintuitive until you round the numbers but thank the you can get to statistical significance pretty quickly and you don't need your samples to be huge to do that uh further supporting the point that we can do this without like imposing unreasonable demands on the peer-to-peer Network now let's talk about the Privacy

behind this all which we said we're going to leave for later uh let's go into how we're going to use NF firers for privacy and as a general observation if we want to make our data Cent a data private you can go about it in one of two ways you could hide the client data itself without touching the identity of the validator in the um let's say client data object or you could hide the identity but keep the the client data itself public if you do any of these two things you would be able to break this connection right between identity and the data that is being shared the thing is to do this uh to follow either of those two approaches you're going to be looking at different cryptographic PRI

so if you want to hide the client data you will require some kind of homomorphic encryption scheme such as the one used by uh private voting protocols that are known uh however using homomorphic encryption requires a trusted decryption Authority or trusted description committee for that matter the appeal behind going about it the second way which is hiding the identity instead of a plain BLS signature that you use to identify the uh validator you can use a zero knowledge proof of the validator identity plus a nullifier to prevent double counting of these uh client data reports if you choose the latter uh you would have a zero knowledge proof where you you're essentially showing that the

validator belongs to the sample that was chosen by the protocol without uh revealing the identity of the validator itself and the sample can also be kept uh the sample itself can also be kep private and not just be a list of validators similar to how happens with ad station aggregators nowadays this Anonymous client data object would be slightly bigger because of the Z knowledge proof would be roughly the size of an ethereum adastation like 296 bytes if we're assuming a growth 16 proof still given the number of AD of these Anonymous CL data objects that would be flying around the peer-to-peer Network at a time we think that the um requirements on the network would be uh minimal

now uh to disclose a challenge about using this technique uh it has similar weaknesses to many to those of many privacy uh blockchain privacy cryptocurrency projects in the sense that if a sufficiently motivated attacker is listening to the peer-to-peer Network and conducting uh traffic correlation analysis then they can use these realistics to get IP addresses for the node and sort of like triangulate and match a validator index to the client data if you want to address this at the protocol design layer you require further we would require further research into mixit approaches or specializ specialized routing strategies such as that theion Plus+ we know such initiatives have been undertaken uh

before and have been discussed need research and such uh some have also been adopted by other uh privacy cryptocurrency projects but going too deeply into this uh direction would be uh out of the scope of the of the current project this is more of a follow-up that would be interested in in looking into also it I think it uh backs the question of whether we expect these kinds of attacks to happen in the first place to for client diversity data that's a point where we would actually be very interested in hearing what the what the community has to say like how much of a concern would that be for method three uh three dedicated voting scheme for client data collection

let's take the other Road in The Crossroads I presented you guys a while uh some slides ago instead of hiding the identity let's hide the client data itself and think about this like as a generalization or a stronger alternative to the survey approach you're going to be leveraging a blockchain toage votes in a censorship resistant and publicly auditable fashion you're going to be needing a homomorphic encryption scheme and a committee of the cryption trusted the cryption authorities for decentralization and you can choose these building blocks in a variety of ways an example that could be pretty lightweight and leverage in existing uh infrastructure and design choices would be well we need a blockchain that is low cost in order to be published in these votes we don't want people to be paying

gas for publishing these votes so a proposal would be used in a proof of Authority blockchain for descent uh ideally something already existing like heski testnet could be a good solution here and as for a committee of the cryption authorities that would be in charge of gathering aggregating and Publishing the end result we're going to need some parties that are uh Trust Ed uh by the by the community at larer by the by the protocol so we could propose for example to have the etherum client teams themselves uh running notes for these encryption authorities uh with the understanding that this design would require custion of a super majority of these encryption authorities in order for any data to be

privately leaked now here's a rough diagram of the process we're still going to be using uh P to here for validators to publish this data uh through a dedicated gosip subtopic the reason for that is more direct Alternatives such as like using an RPC channel to send the data to the decryption authorities we think are not acceptable because they could lead to uh IP leaking of the validators so if we have the validators gossip the their data through the peerto beer Network as before the decryption authorities gather these votes and uh publish them and do the whole aggregation and encryption decry or decryption process on a voting smart contract on a low Co blockchain where here we propose the example of heski

testet for that now the object that you're going to be dealing with as it turns out is going to be a lot heavier than the one we're working with before because at least on a naive implementation let's consider that first you would require a homomorphic encrypt Cipher text for each of the different client choices that the validator can make each of the different execution client software choices each of the different consensus client uh software choices if you were to do it like that and you imagine you have 20 client choices in total then the cipher text would add up to 2 kilobytes the voting data would up to 2.4 kilobytes however we can use compression we can fit up to

three plane client data objects into one Cipher text such that when you add up the the votes when you do the voting aggregation you don't run into outof balance or overflow issues if you do it like this then this brings the data need down let's say to roughly the data objects are going to be a th000 bytes 1 kilobyte and the smart contract itself would be looking at storing something like 10 megabytes of storage we're running out of time unfortunately for our comparative analysis of the solution with regards to privacy trust assumptions and adding complexity I will refer uh you guys to the full report where we attempted to sort of like rank the considerations we have just made in terms of severity or or in terms of how easy they could be

addressed with further work so for example for the dayca of voting protocol there's no way we can see to remove the trust assumptions you're always going to be needing uh a trusted party to take care of the aggregation and decryption uh which is why it's highlighted in red and as a let's say conclusion we can see a trade-off between the highest degree of privacy guarantees in which not even a party that's listening to a appear top Network can de anonymize the client data this is the case of the dedicated voting scheme but it requires uh the trust assumptions on a on a decryption community so there's this straight- off sort of like between the highest possible privacy guarantees and the need for trusted parties to come in okay so let's wrap it up uh here's

the the QR code leading to the E research uh link where you guys are more than welcome to post any comments concerns um observations about what we have discussed working on this project we have ahed bitar and in no particular order we have aadar an ethereum core developer who is here in the in the in the call as well and Ahmed ramazan blockchain infography researcher and uh yours try so that would be it uh thank you very much for your time and attention we are never mind research not sure we have times for any questions or comments if we don't we can bring it over to e research where we will be very happy to uh continue the discussion if yes we're more than welcome to uh talk about those you

Alex Stokes: great thank you um do you mind

dropping a link to the E3 search post in the zoom chat

Jorge Arce: yes oh I'm very sorry I thought it was already dropped

Alex Stokes: I might have missed it if you did but either way just a place to uh continue the conversation

Jorge Arce: absolutely let me let me do it again or maybe Ahmed can oh there we go

uh yeah perfect yeah no

Alex Stokes: thank you that's uh yeah very interesting research um yeah there were some questions in the chat um but yeah maybe just looking at the time uh we'll move on to the next agenda unless there are any comments uh right now

yeah okay

Jorge Arce: thank you we'll look at

the chat and we can continue the conversation on each research thank you everyone

Alex Stokes: sounds great thanks next up uh Peter has an update he would like to give us I think Peter's on call

Enrico Del Fante: yes great hey

Péter Szilágyi: so I don't really want to drag this out um so uh basically the the reason I kind of posted the my proposal and the summary on the chat is that you guys are aware of it it's something that we've worked on but um so just to do a very very dldr um we've been on the GU theme we've

been investigating uh a possibility of U uh creating execution layer Witnesses and uh using them to cross validate executions basically what we are trying to figure out is um whether it would be feasible possible Etc to have one client run an ethereum block uh create a witness out of it and then have other clients uh cross validate the execution so the idea my original idea where I started from was this uh uh client diversity issue not necessarily the client diversity rather the slashing conditions that way back in I think end

of last year G had a much larger market chair and um there were these these really loud horror stories that if G were to do something bad meaning have a consensus faults then it could have dire consequences which are all true and uh back then what I was thinking about is um how could we solve this issue without necessarily forcing everybody to switch away to some other client and uh this isn't um basically my problem isn't necessarily people switching away from gu rather uh this whole client landscape is pretty Dynamic I mean we have clients for example ref is the Hot Shot upcoming

new client and uh but people have I kind of feel that people have weird incentives of choosing one client over the other client for example people might want to run bre however since it's new you the risk of a consensus fault is higher so depending on if you're a validator or you want to run it in production it's like are you willing to foot that risk or not what happens if basically you run an archive node breath and it just goes off consensus and you act upon bad data or there are a lot of different scenarios or if you're a validator and

all of us you start attesting and validating bad loocks Etc whether it's g w or whatever other client and and um basically what I what the idea was that obviously all such instances require a full node which runs the consens and runs everything but what if we were to actually also create the witness while running a block and have other execution clients just stateless validate it because in theory our hunch was that it should be very very cheap so once one of your nodes runs a block produces a witness it should be relatively cheap for to validate it with another client or basically validate it with all the

other clients and um the document that I posted is basically a summary of uh of our basically what what we arrived at specifically that we've implemented this whole witness Creation in G which is fairly optimized I can tell you a number that it's about a 20% performance hit to block import so if if your block Imports is about 100 millisec then aggregate creating the witness is maybe another 20 millisec extra so I think that's very very cheap uh and that's kind of the only component that we have optimized heavily

because it's something we need elsewhere too but we've also implemented uh running these Witnesses through G and uh basically having State having coding have to stateless to validate the witness and that code actually runs the exact same code that live validation runs so it's it there's no special black magic to to have witnesses run specially so basically we can guarantee that it's the same code and that part is currently basically takes the same amount of time so running um um a witness takes maybe again 100 120 millisec that is not something that we have op IED uh the

reason why it matters is because it's the witness is a fairly dump format and uh so it's it's it's a lot less optimal than what G has at its U basically what G can do either way what we've what the document kind of details on the El side is how to create these Witnesses and U and how and that it is actually feasible to create these Witnesses fast and that it is feasible to run these Witnesses relatively fast we haven't optimized it I'm hoping we can make it even faster and then the question is that if El can create Witnesses and El can stateless verify Witnesses then what can we do with them

and um the first thing that came to my mind and basically that was my starting point is to allow multiple e to cross validate each other for a validator or for a production node and and um the question is then where do we integrate this and um I mean this infrastructure where do we take our witness and give it to other clients to cross validate and there's a lot of C possibility for custom infrastructure and pluggability everywhere but one place that kind of uh looked interesting to me is to move these whole Witnesses and cross validation into the engine API the reason I kind of thought about

that is because what the engine API currently does is that you have the payload method which basically gives El a block and El says whether it's correct or not so we could extend that method to also return a witness not just the response and then you have the fork Choice update which asks gu to or E to create a new Block in case you're the next validator sorry you're the next block producer there you can easily also add a flag saying that well get me the next block plus it's witness so it kind of naturally fits in creating these

Witnesses it really elegantly fits into how the engine API Works currently and then you would have one more method on the engine API which kind of would be similar to new payload but instead of actually integrating that payload locally it would be like I don't know a stateless payload where you just get this the payload and the witness run it and we can reply whether it uh it is valid or invalid without actually doing any modification anyway the tldr you have the details written on the both in in my doc and on the on the GitHub issue too so I don't really want to go into very very much detail but the idea was that the engine API seemed very very elegant

for two reasons one of them is that U this way cons we don't need to invent new infrastructure so all we have already have the communication between el and CLS done CLS many CLS support talking to multiple El at the same time so it would be fairly trivial to to just extend it so that the the CL sends uh uses one execution layer client as the main driver and uses others as uh the verification ones so it's fairly simple so to do the cross validation logic and the other thing that this kind of allows us to do is a very very big step towards stateless ethereum because if we think

in a veral world where you have veral trees and um some block producer generates uh not just the veral block but also the veral witness then you would have to use again a similar API where the block producer needs to somehow give the widness whether it's MPT or veral witness to the C the C is propagated in the network and then on the other side when the CL gets the block and the veral witness then it would need to deliver it those down to the El to verify so the infrastructure proposed for modifying the engine I mean my proposal for the engine API would be useful I would say probably 100% as uh as a a stepping stone towards the

stateless uh ethereum so that's why I was uh kind of um proposing this change to see how much against you guys are on modifying the engine API my proposal that I wrote up uh added new methods to the engine API simply because that way we can actually merge this code into gu and anyone can play with it without touching the production end points so that we don't mess with anybody's code and then any any exe sorry any conser client can actually try it out with get and see if it makes sense or not uh if it makes sense then we can think about a more

proper integration uh one thing that we've did notice is that uh the engine api's encoding currently is Json and we have huge hex blobs in it which for the witnesses the problem is that Witnesses are quite large and the Json encoding and hex encoding is slow uh this doesn't necessarily relate only to Witnesses so the same issue happens for blocks too when you transfer the blobs currently we have 1 Megabyte worth of blobs if we want to raise the number of blobs available then that number goes up and eventually the blobs themselves will hit latency issues due to Json and hexing coding so one thing

that uh in my proposal is is not covered but we should think about is also and that's independent of my proposal so whether my proposal exist accepted or not I do think another issue is we should change the the the transfer protocol for the engine API from Jon to probably SS or anything binary really I don't care and that would uh probably completely eliminate the the encoding latency for um for the engine API anyway so um basically that was just a really rough rundown of what we've uh worked on it's actually functional in G that's why I brought it up now the question now is

whether there's an appetite to to have it included in one way or another as for the performance numbers uh as I said witness creation is kind of final is as in we probably can't really make it a lot faster but um propagate I mean encoding decoding the Witnesses on the engine API and witness verification will probably I'm hoping we can make that faster so while looking at the numbers do consider them in that respect too either way so that's uh you'll find a lot more data and numbers and everything in my documentation it's just an overarching overview of this

thing yeah so that was a brain I didn't really prepare too much for it so hope it was kind of understandable

Alex Stokes: yeah thanks no super cool and I like how it lays the groundwork for stess clients uh G you had your hand up

Guillaume Ballet: uh yeah um I had a question because there's been a spec for Witnesses in uh in using the execution payload uh like that's been around for two years um I don't see an great PA from uh this system to to this and so that was my first question and the second question

is

Péter Szilágyi: wait so the witness format in in this spec is completely opaque so u i mean it's just a a binary blob of data

don't care about it

Péter Szilágyi: so changing one binary blob of data when running an MPT to workco blobs when running when passing the part for point I mean that should be fine

Guillaume Ballet: uh yeah but that's not what I was saying yes there's indeed the format uh type but there's also the way it's passed uh there are some assumptions in veral that are uh meant that like the block should be executed should be received at the exact same time as the as the witness uh from what I see this

is this is more of band and I don't think it can uh it's future proof over call is what I'm saying

Péter Szilágyi: what is off band

Guillaume Ballet: you have several calls right so no you could well you define three calls

Péter Szilágyi: well yes one of them is when you produce a block then you get the block and the witness together back or you when you currently in MPT world yes uh so the block production logic will be exactly the same for MPT or veral is the same thing just give me a block and you get the block back and the witness so that that's covered on the other side in

veral you can if you want I mean I Define this I don't know execute stateless something something if you have a stateless client then that is what you would use and you that's that's all and that stays the same thing whether you verify MPT stateless or verify veral stateless that's still the same thing I give you the block and the witness and you run it done the third is just the new new payload with witness which which is the the way well if you have a full node where you want your own node to verif to create a witness that you can cross validate with other client that might be something that won't be needed for work that's the cross validation thing that

we can use today but we we would just get you would just delete that

Guillaume Ballet: but what so from what I understand you're not forced to produce that witness during produ uh block production you could use the old uh the old call instead of uh like producing a block with the witness

well yeah

Péter Szilágyi: the idea is that if you want do cross validation currently then you would make a witness if you don't want to do it that you won't make a witness because it's pointless to dump that on your Noe so it just gives you an option maybe in veral if you always have to do you always need a witness then in

veral you would just say that while you will always make a witness

MH

Péter Szilágyi: so I don't think this the methods I I think the methods will mostly stay the same thing I don't really see them changing at all just maybe before veral it makes sense to call one method and after veral that method just loses its point but otherwise it's the same thing

Guillaume Ballet: yeah okay um I guess I have to dig a bit bit bit deeper but yeah I in any case it will it will require a lot of changes compared to the actual implementation of arle but okay

thanks

Péter Szilágyi: I guess all in all um here the question is um whether there's anybody seeing anything super obviously wrong with trying to get it through the engine API and the way the engine API proposed methods look like definitely we can go with a starting point where the methods are separate the way I suggested just so that we can merge it in and we can iterate on it and then if it turns out to be valuable we can figure out a tighter integration if not then not uh as for the performance issues raised and the sizes those are valid that's we need to look into how we can optimize them I

think it should yes we need to do uh we need to see what the worst case would be and how how expensive that would be yes it's definitely something that needs um a bit of work both in in G itself to make the missing pieces fast and uh but still uh the engine API should be should be turned into a binary one that's I would say that's mandatory long term whether this thing gets in or not

go you your hand up yeah

Mikhail Kalinin: just a quick comment uh on how the engine Epi speack could be handled uh we used to have an experimental

uh folder in in this back and uh usually we just um if we need to extend if if it is supposed to be an extension of say new payload method uh then just this back can be created in this experimental folder and uh the version of this me could be some arit really high number uh so not to clash with uh the ongoing work on the um current hard work yeah and this probably if it's used better so you can just by leveraging this um this this approach just extend the existing

methods and experimentally Implement those in in different clients and after this uh is scoped for any hard Fork we can move this back uh to to to to the U to the hardw back so that's one of the ways to handle this on the spe level but yeah we can iterate on this um uh in the in the pr that L has created

Péter Szilágyi: so just to add a quick memo none of this requires a hard Fork so basically adding U at least the way I designed it with a couple new methods those methods can be added to Els

whenever and they can be used by CLS whenever and there's no synchronicity requirement across them

Mikhail Kalinin: yeah I see yeah um if yeah okay let's just discuss it

yeah sure my

Łukasz Rozmej: my main concern is prioritization because prag we already made it very big and there's a vericle coming uh that would kind of make this partly obsolete so the part that uh where definitely worth investing is the C logic of supporting uh working with multiple clients in this

way and the other part is definitely working on removing Json from uh as a uh layer of Transportation on engine PI right to move to something faster but other than that I kind of have a concern that until this is implemented in in enough clients and like um have good enough tooling for people to actually run it and there's also concern of late increased latency that would it be acceptable on average machine uh which is not obvious um then we will be already shipping prag and focusing on

veral which should be our priority in my opinion bigger priority because it comes like uh this this setup can be cheaper on verle because you don't need a leading client you can do cross verification in parallel which basically you avoid the additional latency um you still have to wait for the slowest client but at least uh it's not uh serialized uh waiting on on two client so that's my question is it is it important or urgent enough to focus on it as Beyond parts of it this is a stop Gap solution that will be Obsolete and

we know it will be it will be obsolete so that's the question

Péter Szilágyi: so with the obsoleteness I kind of both agree and disagree uh so the reason I kind of tried to spec it to fit into the engine API was specifically to make it as make as little part of it as possible obsolete so basically updating the Eng API to Binary will be needed anyway the updates to the engine API to be able to pass Witnesses back and forth will be needed anyway uh clients supporting running stateless execution and Gathering Witnesses will be needed anyway the only thing that's um that

would be different is what the content of those Witnesses are but you still need to be able to gather trodes whether they are veral MP is not doesn't matter and the other thing is you still need to be able to execute a block based on a soup of trodes whether veral or empt it doesn't matter so I'm not so sure that there's relevant amount of data that's going to get thrown out or work it's

Guillaume Ballet: uh sorry the super try note part um do you assume the same format of for MPT like the same storage format for MPT and

because we had this conversation

Péter Szilágyi: no no it does no I'm basically what I'm saying is that basically just have a a partial subset of the try so in mpt2 you will an MPT witness will contain I don't know a thousand trodes it in no particular order because MPT doesn't require it for veral if veral does require it then you would have it in some specific structured format but it's still just a bunch of trodes that the witness contains so it's you still need to while executing the block us to gather that and uh put it into the witness so I I don't really see that much

difference

Ahmad Bitar: yeah um so I have like two points here I want to say that um first in this approach uh that Peter is suggesting uh you provide a false sense of security to the network uh because like in the case that a Dos uh attack is done on um majority client then uh the liveness of the network is still affected uh in a in a severe way um of course my assumption was that we introduced multiple clients just for to guarantee the liveness of the network so this

basically goes against the whole principle of multi-client network because it it it it just deletes it whereas a solution like utilizing a multiplexer something similar to vouch or something like that would uh actually guarantee that livess uh even without stateless execution and if this is aimed for um smaller operators or solo operators then in the chat we already like kind of uh device that the latency from this will Ender this uh very not profitable for the solo Staker whereas

large operators can easily utilize something like a multiplexer to run multiple clients concurrently uh without um enduring the latency issues so another thing is that when verl is coming up like ler said I don't see why um we would invest time into something like this at the current stage

Péter Szilágyi: uh so thanks for those I have to answer to try to answer them so one of them was the Dos so the Dos is uh relevant but uh in my opinion uh

ethereum Network being DS and losing um liveness is the smaller of the problems uh consensus fals are much bigger problems that's where the the nasty stuff happen so the the fact that ethereum doesn't finalize for half an hour or an hour is a lot less of an issue than uh basically having two chains so um for sure if uh it's um it does affect a bit um anyway period um so that was the D issue uh the the latency issue as I kind of mentioned the problem is that basically the engine API is basically

most of the latency currently in this whole cross validation is the engine API encoding so passing the witness back and forth to G will consume 200 millisec of latency just to pass the thing basically it passing the witness through the engine API back and forth takes more time than running the block twice so it's like um as long as that's not fixed it's uh it's kind of unfair to say that this is um this the latency is too high because it's this is not the fault this is not the reason why the latency is high the engine API is the reason and the with regard to U small versus large validators uh yes I kind of agree that

if you are a large operator then you are expected to run arbitrarily many nodes but uh if you are a smaller operator I think being able to run one node and whatever that is your preference and cross validated with the other kind of let people to CH let people choose noes that they like for example I can easily run a w archive node and know that even though it's a bit problematic because it hasn't been battle tested if there's another mind not cross validating it you have much higher guarantees whereas if uh if I'm a home Staker maybe I will just be too afraid to run a w node

because yeah what happens if it goes bad

yes G

Guillaume Ballet: uh yeah that's uh I mean I'm changing topics a bit but not completely uh in case the engine API doesn't um like this proposal does not get accepted to go through the engine API is there a backup solution to propagate the witnesses uh somehow like let's say only only guest wants to do it would you do you have a backup plan to propagate those Witnesses

Péter Szilágyi: not that I would prefer so

basically the this whole thing just if other Els decide that they want don't want to do it then I mean G playing by itself doesn't really make much sense however uh being able to run with stateless and generate Witnesses does have a lot of potential use elsewhere too so it's I mean it's not really thrown out work uh as for creating another Channel outside of the engine API I that one kind of really feels like wasted effort so I I probably wouldn't do that

Łukasz Rozmej: so my suggestion would be uh let's start with changing ngpi to Binary

format and see when we deliver it see where is vericle if it just around the corner or further away and I think just doing that will take us quite a long time so that's problem for me

Péter Szilágyi: I mean I I completely agree that we can uh definitely focus on that on that part I don't know honestly uh converting the engine API to ssz seems like some body has to go in and define basically just annotate the those five data structures with the SSD magic numbers that are needed there the max sizes and whatnot but after

that's done is there a lot of extra work I don't know I'm just questioning it basically I'm just saying that I don't think that if there is a legitimate effort to make it happen I don't think it should be that complicated trademark

well

Etan Kissling: last time that SSC um like something simple there was proposed to align the withdrawal routs in Capella um there was like more the problem that people wanted to go farther than that so with SSC the problem is that um if we are changing the engine API to SSC don't we just also want to transform de block headers to SSC so

that we can just send them natively like do we want these intermediates I guess on engine it's less of a problem because it doesn't go on chain but uh yeah that's one of the aspects like you can choose how far you want to go there

Péter Szilágyi: no don't open that kind of forms basically keep everything as is currently just replace the the Json with ssz anything else basically that's how that's why uh the previous effort to get SSD into El got shut down because basically just BW up into less SSD this and that and that and that and then it just became a monstrous monstrous effort so my two sense would be just replace the Json itself and the binary encodings

themselves with ssz and leave the the way the headers and everything are formatted the way they are currently changing head to SS that's kind of a consensus change that that gets complicated

Ahmad Bitar: um one suggestion is to go gradually with something like message pack because uh actually the Json RPC 2.0 spec actually supports message pack and message pack actually sends all bytes um as row without uh hick or base 64 encoding that adds overhead so uh I I don't know if there is any reason why not to go with something like message

pack which is um already has libraries to cover all programm languages

Péter Szilágyi: I just don't see the reason why that's a good idea uh it's probably a bit simpler than ssz but longterm I mean we want e to speak ssz long term if we want to switch if you want to move more e consensus types to ssz we need to leak SSC somehow into Els and this seems like a doing the engine API seems like a very trivial thing because it's it's a very simple just a few things and then that's that's a nice gateway drug to have e start

speaking it whereas if we go with message pack I mean you still need to add message pack and all the encodings and whatnots to Els so SS or message pack doesn't really lower the effort but it doesn't get you fur it doesn't get you further to um having consensus SSC stuff

Alex Stokes: cool thanks for that Peter uh is there a place people should go to continue the conversation I see you linked tojust from the GitHub comment

Péter Szilágyi: so I would probably um I in that GitHub comment there's the

proposal and I would probably go there as a starting point or if if somebody wants to do a more live discussion then we can maybe do discuss one aspect or the other on on Discord or wherever so probably to just do a brain dump of ideas I would dump it belong uh below the proposal just so that it's kind of there and to go back and forth I wherever you guys prefer

Alex Stokes: okay yeah Discord sounds like a good place for that great thank you thank you okay so next up uh we will turn to Electra and the main thing here is DEET

one um I believe it's targeting Alpha 3 of the specs which has been cut and yeah I guess I'll just open it up is there anything anyone would like to discuss with respect to DEET one I think people mainly are heads down implementing the spec uh is there anything anyone would like to discuss in particular otherwise we'll move to a few other updates for future Dev nuts okay Perry has a comment that they're waiting on E

Readiness so great I assume that means everything's progressing smoothly okay uh Mel had a PR I believe this was to follow up from some changes to EIP 6110 uh following the work of interop M do you want to give a few words about this

Mikhail Kalinin: yeah thanks Alex yes so this is the follow up to the breakout session we had during the inop um and yeah this PR basically um implements the the logic we discussed there um and uh yeah just just go

quickly through the mechanics so the ethon bridge deposits remain the same so they are pro processed instantly and if there is Q are there created instantly um and uh yeah the balance is c c to be processed later and to be passed through the actuation Shor uh on the depos it the deposit requests which are new deposit uh which a new way to um actually deliver deposits to the consensus layer they are um um added to the pending deposits Cu uh they are not processed anyhow and then this uh this queue is being processed on the processing uh this actually done for the

main reason was to rate limit um the deposit processing during the um aook so we can put a limit which this PR does there is the max vand in deposit processing um and yeah if number of deposits exceed this limit it just you know breaks aborts and yeah the rest will be processed during the transition uh it also ensures uh the the logic implementing this PR ensures that e one Bridge deposits will be Pro test before deposit request so uh no from no withdrawal credentials from TR attack is

possible uh so there is a strict order of uh new valers uh that are created um and yeah it also waits for deposit request position to be finalized in the queue as we discussed this would be easy to implement uh if we already have a queue and yeah to prevent some complexity and potential blgs around managing The POP key cache um in the implementations so what else it yeah refactors uh do the refactor of the process band and deposits um method because it get more complicated um and uh well it this this refractor

actually adds uh one computational inefficiency uh the look up of a validator index in the validator set is happening twice for each deposit uh this is done for uh spec readability to improve the spec readability but yeah if if this going to be a concern um we can do something about it and do it once and yeah do some work around but I I just thought that probably uh all clients will use uh the cach uh to do this look up so it will be really cheap um also uh the other thing to probably think about is whether we

need Max fending deposits per EPO processing to be even to to even exist because we have a natural limitation which is the CH limit um yeah and there is the potential worst case scenario attack that is described in this um in the description to PR so just if you want to take a look please take a look at it and yeah probably it would be great to not just introduce another uh constraint um and leverage on the CH limit um yeah that's basically it about uh the the logic that this PR introduces uh yeah and it would be great to to get

as much feedback till the next week probably because uh I'd like to start working on tests and yeah if anyone wants to help with the writing test to this uh functionality this new stuff so yeah please welcome yeah that's basically it

cool thanks

Alex Stokes: okay uh we'll move on to the next agenda item then uh thank you for that Mel so right

um yeah if anything we will time box this but I was going to ask if anyone wanted to review uh The Blob basy Spike that I believe happened last week I think it led to some turbulence uh with rollups and kind of touch many layers of the stack not sure if there's anything we want to discuss now if not uh we'll handle that in other places okay sounds like

no in that case uh let's move to pios so uh I guess first off I don't know if anyone here was uh on the Breakout um I'm not sure if there are any updates from that call that are worth sharing with the group here we have a p have not won online now with three different C clients okay awesome does the network look healthy

Barnabas Busa: we had some uh blob spamming uh and some tech noes were unable to uh produce blocks all the blocks that

they produced were orphaned so I think they're already taking a look

Alex Stokes: okay great there was a comment to look at essentially these two PRS let's see let me grab the link so essentially this was to UNC couple how we communicate the blob limit between the El and cl there was a PR that I opened that would basically have the CL Drive the max Bob count um for example over the engine API I think one open item there was to consider including the max Bob count in the E

header to facilitate optimistic sync um I haven't added that to that PR yet or added anywhere else but that was an open item that I think we kind of agreed we needed another thing was uh this PR 3813 to think spe repo uh I don't know if Den's on the call I don't see him uh but essentially this was going to go even a step further and take the essentially the the base fee calculation um away from the e and have it handled all in the CL I think this accp poates things quite nicely um yeah so I guess for now I'll just call those two out um um I think

ultimately we want to do something like this for pectra so yeah please take a look if you haven't and yeah I just consider this a call for review

Mel

Mikhail Kalinin: um I think that uh for both PRS whatever we do on this CL side uh in terms of that effects the El block validation uh we will have to to include this into the um e block because as you've said because of the optimistic sync because it's not always the case where every where a pay load is uh sent by the CL new pay load so um yeah will need to be self-contained in terms of

validate in the block uh and uh the other thing uh is that uh we have this target parameter as well and uh if we don't want to uh to to make this target parameter a product of Max like say um Target is um half of a Max uh then we would need to include it as well into the block header and if it is the case then Pro probably it is better to um yeah in my opinion it would be better to have a couple of parameters like in the D cross uh PR having this uh base fee comp computed by the CL and validated by the CL and uh the

basically blob uh gas limit uh one one potential problem here is that El will not be able to compute the uh the base fee for blob gas and if if this is required by like for you know to filter out transactions in the M Pool uh then it could be a problem but yeah could use this parameter from from the Block uh from the parent block of the block it is uh yeah from basic the block it has as the head so probably it's not that bad it's not a problem yeah that's just my my thoughts on those two

Ys

Jenner

Gajinder Singh: yeah my opinion is uh that solution one is more simple in terms of it is keeping uh you know uh is keeping SE maintaining separation of concerns in the sense that CL is only telling what the blob limit is and the pricing is calculated by El and now in future we can have for example a contract like 7702 which to which transactions can be sent and that can itself decide what the pricing is so there are many ways you you can uh enhance this further uh further in future uh using El rather than having these calculations being

done at El and for rather than these calculations being done in CL and also uh updating the formula in El is not really difficult uh and the only thing uh only thing that that is relevant is that okay Target we'll have to assume is half the maximum blob limit but I actually don't see that you know how fancy we are going to go with respect back to Target and the max limit and uh most probably you know things uh are good to be kept simple and straightforward

Alex Stokes: yeah I tend to agree um

I think I will wait until dun's here and he can maybe motivate his PR a bit more uh but yeah I do I definitely see this like violation of separation concerns across the layers which I don't like I do think his thinking was essentially that uh there's like at the fork boundary so if we change the Bob count uh there's like this weird discontinuity in the Bas Fe calculation and like the CL then would have more context to be able to like you know compute the fee change smoothly so I think that was one important point there but yeah that all being said uh this will be an ongoing point of development so yeah please take

a look and we we will revisit in the future let's see anything else on pios otherwise we'll move to an SSC update okay uh done I think this is you would you like to give us an update on ssz work

Etan Kissling: sure um so there are still these two eips one is on the consensus side to uh update all the ssse container

definitions that frequently change such as Beacon State beacon block body and these um to a format where the generalized indexes um no longer change uh for a for any given field across future Forks um just for context this is used by smart contracts that rely on EIP 4 788 and pull in Eon data right now they need a redeployment whenever a gex changes and with the CIP it's no longer necessary um we have full implementations from loadstar Nimbus and te that have a DEET running in cortosis um CR and prism are still

implementing it but there is no no real opposition at this time to give it a try for inclusion into Electra so I would just like to um ask one more time if there is any opposition still against EIP 7688 in

pectra devet 2

Alex Stokes: well I think right off the bat at least I can say say Petra is quite big so we need to very seriously consider making it even bigger but yeah

under go

Enrico Del Fante: yeah just one comment on te Readiness uh so we took a short path to be able to

be compatible with the death net just essentially be compatible with profile definition but being fully compatible with the entire new this spec of the stable container turned it out to be a little bit more complex uh still working on it on full compatibility and um yeah just say that one thing is being compatible with the devet um for switching to profiles and another thing is to have a full uh implementation of the ssz library fully compatible with the specs

Etan Kissling: sure yeah I mean for this EIP like the stable ginit say for the beacon State struct for the consensus structures um only profile support is necessary so um like what you did for the devet um I'm talking about including this scope only this scope into the

devet to yeah

Enrico Del Fante: but incl including only that it anyway tricky for us because the implementation is still undergoing and uh we normally go with a master Branch

with devet so I'm it will force me to um merge to master an incomplete implementation which is still working on so my preference at least will be to complete the implementation and then uh and then have have everything ready for full support

Etan Kissling: uh what is the timeline on devet 2 like uh we are still ahead of devet 1 so for devet 1 it's definitely too early right so two or three would it like could it be a good Target

Enrico Del Fante: yeah that's a good point I don't have an

idea but yeah so maybe def two could be good defit three would be safer

Alex Stokes: okay and in any case I think people are mainly focused on Deet one DEET 2 will probably be some time off uh so yeah again this is a nice update uh it sounds like we can make a call on a ACDC

Etan Kissling: okay yeah and for the SSC transactions like that's the elip um ethereum JS has a prototype now and we are working on making a client

demo as well um that consumes that data so that it verifies for example transaction inclusion proofs um so that if you have a wallet and it shows you a transaction history that you know that it's accurate um that one I posted into the light client's channel on Discord let's still early access

Alex Stokes: okay thanks okay

cool I think that was everything on the agenda for today uh is there anything else that we would like to discuss otherwise we'll go ahead and wrap up okay cool thanks everyone uh let's go ahead and call it

thanks bu thank you thank you thank you

Speaker names adapted from ethereum/pm, CC BY-SA 3.0.