All Core Devs - Execution #154

Transcript

[Music] foreign [Applause]

thank you

Tim Beiko: hi everyone uh welcome to uh awkwardev's 154 a couple things to cover today so some Shanghai updates as we had a new testnet launch earlier this week and then um it sort of talking about how we go from here to the existing public test Nets and and where their clients are ready to start looking at that

then um on the Cancun side there was a lot of discussion around 4844 in the past uh week or two so there's a few things that make sense to um uh there's a few things that make sense to go over today um and uh oh I thought I had added this to the agenda so um there's three things there around the transactions uh with zero blobs transaction pause back blob block coupling and then there's something else uh we've had some benchmarks done for the pre-compiles um so we can go over those as well then Matt Haddon execution API PR has

been open for a few weeks you wanted feedback on and to wrap up uh We've also been discussing SCC SSD sorry quite a lot these past few weeks and there's a couple proposals there so maybe just to start uh anyone from the devops team want to give us an update on the new uh chappella testnet

Barnabas Busa: sure uh hi everyone so we launched the young uh that's not yesterday at 3 P.M Etc time and we have 61 000 visited the letter 58 000 of them is run by the EF currently and uh about an assassin is running 2000 more

and we have another thousand keys to allocate to different projects we still have about 400 kids to give up if anyone is any kind of team is interested just let me know and uh we have fully working faucets and Beacon chain and transaction Explorers so block Scout and you can chin both have a working store up and running and we have a Launchpad instant so and all of this information can be found on the link I posted below uh currently we are not able to process any new uh deposits because we have some trouble on loading uh

new deposits uh into the beacon chain but I'm sure it's going to be uh started out in a few hours or days and we will have a fellow on Tuesday at 3 pm UTC time

got it

Tim Beiko: um and then one question so you mentioned that you have about 400 validator Keys um is that the only way if if somebody has a validator and they want to run through the transition

Barnabas Busa: no so we we will have the launch pad and we have faucets also so you will be able to get some uh 33 eat at each uh faucet request and to have that you can go through the Launchpad uh exactly the

same way as you would for the main or for any other

tests

Tim Beiko: awesome um that's great any anyone have questions comments

on that

Marius van der Wijden: can you quickly explain what the issue is

Barnabas Busa: uh I can't I'm not really familiar with how uh new voting is taking place on the consensus layer but maybe one of the CL ient members can explain because we've been having some discussion in the interruption about this uh so basically we've been waiting for a long time to have some new deposits

included but they just seem to be more than the wrong head except the lighthouse

Danny Ryan: there's a mechanism that some follow distance they're following the El and vote on the deposit route and process deposits and it says definitely proven to be brittle especially when we're configuring new networks from time to time so I would suspect it's likely configuration given that all these clients handle this final minute but I don't have details beyond that

on the New Testament

uh not true we

Barnabas Busa: we had one in Short discussion about whether BLS changes should be uh allowed or not

many different tools but it's not great to awkward deaths

Tim Beiko: got it okay um did I guess uh you know I'd be curious to hear from some of the client teams how they feel about uh the general Readiness of their chappella code and um you know when it makes sense to potentially uh consider forking some of the existing public test Nets so whether Gordy or sapodia and if you know people have preference around the The Ordering

of those two not that we have to like make a final decision today but I think it'd just be good to like yeah put this in context where the different teams are at and and yeah how they'd like to approach uh the the existing public

test Nets

Danny Ryan: quickly on an ordering standpoint yeah um I think it makes sense to do sepolia before gorley given that gorley is used by much more uh validators outside of like a limited set and so that gives a bit more time for uh documentation and tooling to be more robust so just from an ordering standpoint that's my preference

Tim Beiko: yeah that would be mine as well does anyone disagree with that think that we

should do Gordy first okay so assuming we go safolia to Gordy um yeah I'd be curious to hear yeah from client teams you know is are you like close to a spot where you you could put out a release to Forks apolia um not quite um yeah any other concern about public

test Nets

Marek Moraczyński: so from another might site we don't see any major issues we have a few uh things to polish but I don't see any blockers now

Ben Edgington: speaking of techu we're good to go no

blockers

Tim Beiko: awesome

Gajinder Singh: same with Basu here and agreement on sepolia first is also good to go

questions

Tim Beiko: sorry uh you said also ethereum JS is that right

yeah

Tim Beiko: okay

we are not online yeah on the prism

Terence Tsao: side we're also good to go

um oh yeah please

yes guess

Marius van der Wijden: um is like I'm pretty confident in our code I'm I'm like I don't know having a test net a test net breaking this close to to the the test Nets is something that we should really look into and uh I hope that it from my point of view it looks like a consensus layer problem but would be really good to to look into um otherwise our our client should be

Danny Ryan: so to be clear this is the network has not gone through the Chappelle upgrade is that correct

Barnabas Busa: that's correct

Danny Ryan: okay

this is

Barnabas Busa: a configuration uh

so uh Chappelle is going to happen Tuesday next week so I'm if you can get everything up and running by capella I think we should be still very good to go

do we include yeah mentally in

Danny Ryan: towards calling this a configuration issue and not a Chappelle issue until proven otherwise but agreed that we need to figure it out

so

Barnabas Busa: I would now ask all clientians to try to give me a hand and try to figure out uh what kind of configuration that might be because at this point I'm not really sure

Tim Beiko: right and obviously you know if I think

it would make sense to see chappella work well on this test net before we put out releases and and set a specific date for uh for sepolia but um yeah assuming it's just to configure shoe yeah that that's obviously not the same as an issue with the actual Fork transition

Barnabas Busa: um I think next week Thursday we we will have a much better uh oversight on like how things are going

yeah

Tim Beiko: that makes sense um I don't know if anyone from Aragon wants to share their

you

Andrew Ashikhmin: um I'm sorry so what was the question

um how

Tim Beiko: how ready are you guys for uh

potentially 14 sepolia do you

you know yeah yeah

Andrew Ashikhmin: I think we are ready that's uh Shanghai yeah yeah

Tim Beiko: yeah

Andrew Ashikhmin: yes uh I think for Shanghai we have everything implemented

um let me talk about

Tim Beiko: this year so I think that's all the elf folks um and I think we're missing a lighthouse I don't know if anyone's on the call

Adrian Manning: yeah yeah we're good as well

Tim Beiko: okay and I'm missing one client uh anyone didn't go sorry no we got

Basu um oh

Tim Beiko: Nimbus Nimbus yes yes thank you

Etan Kissling: from what I've heard everything is ready um like feature wise we are still doing some optimizations on BLS to execution changes and I think then that's it

Tim Beiko: okay so I guess um assuming that uh this this work on the new testnet goes smoothly and we'll know that Tuesday but I think it would make sense on Thursday to agree to like a a fork Epoch for for sepolia um and and then if we could announce it you know like midweek the week after it gives people sort of three four days to put out a release um for for sepolia uh and usually you

know we can probably Fork zipolio like a week after that um just to give folks a some time to upgrade but it's a pretty small set of validators on the network so I guess just yeah from client teams if if you can be ready to put out a release shortly after next week's uh consensus error call I think that would be that would be great um again assuming we don't find anything going terribly wrong with this Fork on uh on the new testnet does that make sense to people cool um and then yeah I guess if you're a Staker node operator infrastructure provider listening um please uh this is the time where you

need to start paying attention so uh we'll have a fork on sepolia uh you can join this new test net if if you if you want to try things before um and I think once once the polio Forks uh we can start talking about uh talking about Gordy and and how we want to uh to handle that one on test Nets or chappella generally so uh Cancun lots of work has happened on 444 uh in the past couple weeks and

there's a couple things that sort of uh made sense to Bubble up here um and maybe first uh I don't know if radek is on uh to talk about the

benchmarks and yeah redneck oh are you kaitima but that's actually me uh yeah okay oh sorry uh I would

Jacek Glen: take for the benchmarks uh let me show the screen with you guys yeah first ah here we go can you see it

Tim Beiko: yes

Jacek Glen: um so uh yeah some time ago we got this

uh lovely little uh laptop the point of the slapper was to uh track some Benchmark data across different implementations and of course different versions so what was started off here let me just show you here well I'm not sure if you guys seen it or not but let me just go quickly for it so a different click on piles and tracking the times of execution on different machines here the point of executing pre-compiles was actually to receive the gas cost of it is accurate

how how do we know if it's accurate well we took or maybe let me show you the the latest uh Shanghai version of it uh no not this one standing upon maybe uh yeah I just wanted to show that to all the results are normalized to one of the pre-compiles which is a easy recovery

this is being the most standard one and if we look here on the last column this actually tells us what would be the cost of that pre-compiled execution if we normalize it to you see the cover the time right maybe this is going to be more clearly if we look at this uh work that we actually have so uh the problem with the the current state of the sleeper is that we only have a go aphidium as a client and we didn't really track all the versions and all

deputy compiles and there's no way to compare them and that's exactly what we did here so uh that's the selection of the pre-compiles but we decided to track executed them on some reference machine being my laptop it doesn't really matter what machine it is we all we want release to compel timings and the ecd cover pre-compiled is the basis and all the other pre-compiles I'll test it against the AC to cover

so the first Benchmark we've done is actually duplicating the world that was already done and that's uh something we call the direct execution so we take uh an upper page method in go ethereum execute it in case of helium this is a method called run pre-compile contract we execute it measure the time using some benchmarking Library we we got this and we did it for most of the pre-compiles calculate the times all normalized them to easily cover and okay let's take some examples here

the pading bn256 padding time that the nominal cost so the current cost is 113 000. and the calculated cost is 158 so close enough it's not too bad the same for more so the nominal cost is 6 000 calculated 6200 that's actually very good uh the point of the main point of the exercise was actually to try to estimate the cost of the new Point evaluation pre-compile so for the point evaluation we have two failed tests and one valid test

so this implementation uh uh all the all the pre-compiles for the point evaluation are valued at 50 000 at the moment the failed test actually in this implementation they complete quite quickly and the calculated cost is nine thousand uh the valid test is the 76 000. right so and now it's the decision whether we need to change that nominal gas cluster to adjust it to something more like uh 76 or the or leave it as it is but that was the first step with go

failure the Second Step was to say okay this executions are done in multi-directional direct way what we want to do is to run them in in more real life scenario so for all the pre-compiles maybe I show you here for all the precompiles we've created a simple contracts which all they do is they push some parameters known parameters and then called the pre-compile and when we execute fed bytecode and we Benchmark

the bytecode execution which something more deal life so for the again go aphidium case let's take maybe Point evaluation so the director that's a bad choice let me let me start with this one uh the pading one the dialects execution was maybe let's get a better game better choice because we have had multiple paintings you see the cover Ah that's the good one the dialect execution was 48 um milliseconds on my machine the bytecode execution was 70

milliseconds on my machine the point evaluation uh something similar I said it's a bad choice because for some reason the bytecode execution was slightly faster on my machine uh when the dialect execution execution it's um it's weird because in the bytecode execution we expect all the evm machine overheads to be also calculated but you know benchmarking is not a exact science it just measuring some timings uh but anyway having the bytecode execution now we said okay the same

bytecode we can execute against all other clients and that's uh and measure of the time and that's exactly what we did so we uh measured the same bytecodes against another mind uh erdegon and Basu and then at the bottom of uh the page versus more compilation between uh clients for the CAF we also got a different implementation of Point evaluation pre-compile I also measured that so well we can compare it of course it's

not a kind of a competition between uh clients it's more like uh to know what the gas cost estimation is uh is what we actually pay in terms of the computer resources uh in here you have also this being here the specification tells you exactly how it was executed and which version of uh clients we used and that's it yeah

Tim Beiko: thanks um and I guess do you maybe want to quickly go over the the cross client comparison for the point evaluation

pre-compile directly and then um then grad let's see yeah

Jacek Glen: let's go here so the top line is the the actual timing the bottom line is the calculated gas cost for that specific client

Tim Beiko: got it thanks thank God I see you've had your hand up for a while

Dankrad Feist: uh sure yeah and I just wanted to comment that I don't know why we're doing this benchmarks with

gold cases we're going to what we want to use the Smart cases

Tim Beiko: yeah we can definitely rerun the benchmarks with

an arc um yeah that would be good okay before we like wasting time discussing these results

Tim Beiko: um that's definitely something that's doable and we this is why we had like the the um the the libraries using the specs but now that we have the infrastructure it's I assume pretty easy to just rerun it oh it's already there actually with

death for the knock we have for the gov yeah nice well that is

Tim Beiko: any other questions thoughts

and I guess that the the original kind of motivation to do this was to figure out whether the 50 000 gas price for the point evaluation pre-compile was reasonable it does seem

Jacek Glen: that's correct yeah

Tim Beiko: looking I don't know looking at this as a non-expert it seems like none of those and none of the clients have like an execution time that that would imply a gas price of higher than 50k is that is that correct

Jacek Glen: that's correct yeah

Tim Beiko: yeah yeah so I guess uh yeah I I don't know my takeaway would be that like we've probably priced this correctly but does anyone disagree when looking at this um well yeah thank you for for walking

through this the repo is obviously uh uh available so I've linked it on the call agenda and shared in the chat here um if any client teams have like small tweaks they'd like to see or or whatnot uh yeah let me or or yeah no and we can um yeah we can look into getting those done

Jacek Glen: okay cheers guys

Tim Beiko: yeah thank you okay next topic uh also 444 stuff so the zero blob transactions um so the idea here is you know should a transaction a 444 transaction that does not contain uh blob data be valid um and basically should it and if it's

not where should the the sort of blocker be do we want this as a consensus rule do we just want clients to disallow those in the mempool I know Peter had originally kind of uh came up with a transaction pool spec that had some implications there um then yeah ends guard then crad you both have some comments on the agenda so Ansgar let you go first

Ansgar Dietrichs: um so yeah I think basically the concerns were that uh on the mempool side it is pretty hard to have logic for zero block transactions because a couple assumptions that otherwise you can make public transactions uh basically no longer valid the question is just what we would we simply want to exclude them from mempool could still have them be

valid in that case they could still be included by a safe a a relay spot like system or not um I think there was some disagreement my personal preference would be to still allow them on the consensus rule side and only bend them from manifolds but at the same time I think just given that I think our priority is just to make compromises and get four out of the door as soon as possible I think there wouldn't be any big harm in restricting them on the consensus roads uh level as well for now we could always lift that band later on but yeah I prefer to only do it on the mental side if possible

um yeah I pretty much agree with that

scoundus okay uh Lucas oh sorry thank God please yeah

Dankrad Feist: yeah no no

yeah

Łukasz Rozmej: so from my side I don't okay but the potential problem is that we would have to have um specialized logic if we will want to uh include them in case of reworks uh which we now have there's a question that we want to keep that logic in in general that we uh we add and reorg the transactions back to mempool and then we have the we come to the same problem

of having specialized cases in mempool in my opinion there is also a question mark on the general like ux user experience and usability because if we Mark those transactions as blob transactions they have in my opinion a special domain meaning and they are easier to reason about in in all of the cases if they went to block if they are in mempool etc etc that they have blobs and they have special treatment because of this and if we allow zero blob transaction this reasoning is broken and then you have to also inspect how many blobs they have in terms of the rules that was used for this transaction

so in my opinion it's just clear makes the clear boundaries what is what and that's why I'm or Banning those kind of transactions

Tim Beiko: thanks uh vitalik

Vitalik Buterin: yeah one thing just uh worth mentioning is that this does kind of intersect a bit with the discussion that we're going to have later in the call on changing CSS Z because like my proposal for example does end up Banning zero blog transactions as a side effect but uh introducing a new transaction type for those

uh Danny

Danny Ryan: just a quick comment on like the ux that we necessarily want to provide with the

mempool um you know I think providing if someone's blob transaction was in the mempool uh providing them with the faculty to have it be back in the mempool Upon A reorg is probably a reasonable ux whereas I think if they bypass the mempool um and are using special faculties and have zero blobs or blobs I've never seen in the middle pool reorganizing and thus putting those back into them pool is kind of requires a number of like abstraction breaking changes to the engine API and also seems like um an extension of the like what we actually need to

provide you know there's not enough like these people are bypassing them pool in the first place so I don't think we should design our systems to um put them into the mental in the case that there's a reorder nonetheless I know that's not the direct comment the direct point of what we're talking about here but it was brought up

perfectly thanks uh Lucas

Łukasz Rozmej: so but then you have special cases right the sum of things you now put to mempool some you know down so it's uh it's fine right but it's like why so um if I can reverse the question and why zero blob transactions are helpful and useful because that's that's unclear for me why it would be good to have

cerebral transaction

Dankrad Feist: so first I mean you'll have special

cases anyway because you also don't want transaction with several blocks in the network at least I think we should have them and why do you need them I don't think there's any strict case for needing them but I also don't think there's a good reason to extrude them and it might simplify someone's logic say if like a um roller builds a pipeline that handles one type of transactions for everything and maybe there are some cases where they just want to push a new state route and no blobs or something like that so I I can see I I can't see a good reason not to have them because everything just works like it's simply a case of like executing everything with silver blocks um so my opinion is it's fine

Tim Beiko: but say

just in your example of like the roll up infrastructure um I understand they might want to use the same address right like the same signing key basically for those transactions but why why couldn't they sign like a type 2 transaction instead of a Type 3 transaction to do this

thing right

Dankrad Feist: now that would mean they would also need infrastructure for LP transactions and all that so it is a difference I don't think this is a very strong argument right I also just don't personally see any argument for not allowing zero

got it uh the topic

Vitalik Buterin: yeah just uh wanted to also point out that in the case where we do not end up

accepting like either my proposals or some of the other more detailed proposals that include a new SSD transaction type we would if we get like if we don't include those and we also mandate that Bob transactions have to have at least one blob then we lose an opportunity for regular users to kind of get acquainted and set up their infrastructure and then start using SS transactions more quickly

right

Łukasz Rozmej: yeah my understanding is that we will go with uh with the having another type of this is the transactions so that's why when it simplifies for the users right they just specify different type and it

works mostly the same

great

Tim Beiko: okay I guess I feel like it probably makes sense to have the SSD discussion and then come back to this does anyone feel like we need to make a decision right now about this um so before okay so make sure to come back to this after z um there were some more uh there were just some more uh four four things before I think it makes sense to talk to talk about so um something that came up in the 4844 call this week is that uh with um with the the zoo blob transactions uh

obviously uh you need to do some different logic in the transaction pool um and it was unclear what's the best way to test that or to um to have clients know that their implementation works uh in that like um we obviously say that zero block transactions are blocked at the consensus level that's that's fine um you know we can test for that but um there will be like degrees of freedoms that clients can have to test a transaction pool and or to implement the transaction pool and is there like something like a test Suite or something like that that we'd want to have uh to make sure that even though all the El clients might have slightly different uh transaction board implementations

um they know that it meets like whatever uh sort of requirements they should have um and this feels like a bit different than all the other testing infrastructure we've had before which is more focused on like consensus so yeah I don't this any anyone feel like it's there's value in having like a cross-client thing for this or um and if so what what do you think that would look like

Danny Ryan: this kind of thing is hard to test in a cross-client manner because there are it's very non-deterministic as to like it's very

stateful for each client and what they're going to do um so I would I don't know there might be some like kind of test net scenario stuff that we can do like you know in a given amount of time under certain scenarios transactions are included thus the mempool must be working but other than that I don't think it's an easy thing to test in a germanistic way

Tim Beiko: right then maybe it's more a case of just having a setup where we can run you know spam the transaction Bulls many times over and almost more like fuzzing the transaction pools

and could we

Mikhail Kalinin: probably have a high test

on that because we can use engine API and just a network of real clients that we are exchanged with these kind of transactions and that we then after some time that we expect this transactions should be included in the payroll which is called the process to build the payload and check whether they are included or not and probably this kind of approach could work yeah but we need some strict rules that we can enforce in this test and which may come out of the specification of this

tool I mean

Tim Beiko: another option is also to say like you know obviously clients will have unit tests and and like we'll test their specific implementations

um but you know maybe it's fine if there's like discrepancies and behaviors yeah it just feels like it is kind of is something out of protocol which we're adding some sort of design constraints on and it would be good if there was a way to know that like the implementations roughly worked maybe Shadow Forks are sufficient for that

Danny Ryan: it's also unclear to me how much of this design document makes it into like a must on specification right some of this is just like the quality of service you want to provide to users and your

various scenarios that traditionally hasn't really made it into specifications so I'm hesitant to put it into joint testing

Tim Beiko: fair enough does anyone disagree with that

Danny Ryan: some of the like the Dos considerations and other types of things clearly are uh put in his text but like how to handle rewards and stuff but I don't know if there's precedent for having that

in specification yeah

Mikhail Kalinin: this approach definitely has its own restrictions yes so it it also it's already only could be tested up to like some limited extent

Tim Beiko: I agree with them I mean Mary Esther your comments about

not accepting blobs I guess you could do just today with not accepting 1559 transactions as a client right you just provide like a worse product

Marius van der Wijden: yes yeah but like this if we were to not put it in in the spec and this would be something that clients could do and I think they might actually be value and not having this not

accept employ

Tim Beiko: why so like obviously they still have to

execute like this will have to process those transactions as part of the chain but you're saying like there would be value in them not having to handle the member part of it and you just can't submit your production through that clients is that right

um just

Tim Beiko: okay um yeah I guess it doesn't seem like anyone is strongly in favor of having like some cross testing for that then that it's fine if if if there is some some differences in Behavior so um I think we can just leave it at that oh sorry

Lucas oh

Łukasz Rozmej: I would potentially be in favor and I think if those transaction type and this is a very special transaction time isn't spec manports should generally handle them at

least they should be able to if if they are not maybe explicitly configured not uh but I have no idea how to design this kind of test because of the mempool implementations are so different and I have yeah it's like no idea how to do

Marius van der Wijden: so we have a few um oh like kind of a big suit of uh transaction pool unit tests but they look very deeply into the transaction pool so it's like we cannot really spin them out into

something that that's available for our um unfortunately like we I think we could but this will take a lot of

Danny Ryan: well and it would probably take a lot of modifications on other clients to be able to have similar structures or similar formats or be able to ingest whatever you

upload

Marius van der Wijden: yes exactly well um in ingesting isn't isn't really the problem it's just it's Android transaction the problem is more making sure that the rules are followed and like

verifying this state from the client and it's like like getting the the state back out of the client to see

inward so

Łukasz Rozmej: I think like the test could like even use the fp2p right and the state to verify would be the produced block that it has those transactions right that we expect them more or less to have

Marius van der Wijden: we could do that but that would be even more complicated and more brittle

Łukasz Rozmej: yeah yeah so yes like I said it's quite hard to do that

Tim Beiko: Okay so

I feel like yeah this is here not like the most urgent thing we can discuss it I think if there's yeah if if there's uh test Suites we want to come up with but um yeah I I would assume that Beyond just some basic like pest cases uh a lot of the functionality will just be tested by the clients themselves for now anything else on this okay uh the other big uh for fourth thing uh was uh blob and block coupling or decoupling uh in terms of sync uh

there was a lot of uh conversations about that as well a couple comments on the agenda ensgar is this what you want to bring up

yeah sure but if you have anything else no

Tim Beiko: no no do you just want to give yes you want to give it just a quick background and then go into your comments

good

Ansgar Dietrichs: so basically I think the idea is just that um uh clients want to expense help that um having the the content this block include being the blob section B1 contiguous peer-to-peer message um had some issues some inefficiencies

and wanted to split that up um and as part of that split out there several different credential designs and in some of these versions We would also do slightly just the photography and just given that the cryptography libraries are pretty pretty close to kind of audit so so there's like urgency with any changes there I think um and and given some people are skeptical but whether we should do this change at all because it's just something we should make a decision along soon um Mike I I just wanted to briefly say a business from my perspective um I I just to basically classify uh the different types of obstructs we could do um so so basically there's uh one version where we only split Bob section um as one continuous chunk

um from from the rest of the consensus block and in that case we would not have to adjust it probably but also we only get some of the benefits because that would still be a pretty big chunk one other alternative that's the third one that is proposed right now would be to split it on a per block basis so we can each prop individually and there I think there would be a pretty strong desire to adjust the cryptography otherwise it's a bit silly we have a like subnet where you can download individual blobs but then they come without individual proofs so so you can't really validate them um so so that would indeed need competitive adjustments and then I think there's a third option that was also discussed um that I personally am in favor of that would be to basically just tweet the collapse section as a opaque

chunk of data and just split by some fixed cutoff and in that case we basically we don't have this individual access to the Buffs but you you basically still get the phpm benefits and you could potentially accept that later on to the normal consensus problem available as well um and it would not require changes to the cryptography so basically I think for today's call we should just talk about do we need this change at all um again this is mostly something control teams strongly about and I think that's what people if it's typical and then if we wanted this change which version do we want to go with and but mindful that some of these do requires photography changes and they are the timelines I'm pretty

sure

Tim Beiko: got it um I guess

there were a couple comments on the chat like from you and and Scar about like not necessarily separating them does anyone want to make the case for why we should split them out and we can go from there

Danny Ryan: I'm Pro splitting but I can make the anti-splitting argument

Tim Beiko: I was gonna say do you want to start with the pro splitting

Danny Ryan: okay Pro splitting so essentially um by using separate subnets and separate meshes uh for these individual slice messages we can probably leverage more efficiency across the network and essentially more parallelization uh in propagation of these messages

um this is there's a lot of intuition around this that this is likely the case there's especially given our understanding of how Acquisitions and other things work on real network but uh whether this is a 20 gain 80 gain in terms of propagation times uh whether this helps in the normal mode or only in attack modes like there's not as clear exactly um you know the benefits that we're buying other than like a notion of this is a more resilient design so there's a bit of uh work being done by Anton on txrx to put this into a simulation framework as are a couple of people

looking into simulations on load analysis so hopefully get some experimental analysis but I would say that after gossip did propose this seemed like the the networking experts the gossip sub experts on the various teams were convinced by the arguments

okay

Jacek Sieka: I can add to that hey um there's actually a bandwidth reduction as well um so there's what Danny mentioned the parallel sending there's some parallel processing to do inside the client that is attractive with this proposal and there's also bandwidth reduction due to a

technique I tend to call Lazy sending in which you simply don't have to send the data to some clients thanks to a gossip sub trick and that trick becomes a lot more viable when the pieces of data are smaller which is what we're doing here we're basically taking the Block in lobs and and lining up the gloves each on their own subnets making them amenable to this kind of bandwidth reduction and what we've seen on attestations when we implemented this in Nemesis like a maybe 30 bandwidth reduction um so it's really attractive from from

that point of view as well

Danny Ryan: and another argument here is that although at the current proposed amount of blobs and blob sizes uh sending fully might be sufficient um for our propagation time and bandwidth needs that if over the next 18 months we want to turn up that data gas limit that we're likely going to have to employ more sophisticated means like this maybe episode and other things both to help propagation times but also to help with the bandwidth loads

George Kadianakis: um to get these benefits how important is it that the isolated blocks that fly on the network are verifiable in

isolation because that's what causes the cryptography layer changes the fact that now we are asked to be able to verify individual blobs whereas in the previous design the status quo we're only verifying all the blobs together with an aggregate proof

Danny Ryan: so generally the proposer signature the proposer being a bound unit of one actor is sufficient for most of our Baseline anti-dos measures anything on top of that that you verify that you can verify cheaply on each hop is good it's nice to

have you know for blocks we don't execute everything but we do verify the proposed signature and then we do pretty much all the like constant time checks I'd say all the constant time checks are nice to have it's really that proposal signature that's the core of our anti-gust so again that late crypto check if you can do it cheap um it's it is a nice to have but I wouldn't say it's critical the

signature is critical

George Kadianakis: I see okay because one of the arguments during the presentation in the interrupt was that you're able to like verify the blobs as they come so you basically parallelize the band with with the computation but yeah I guess that's

Danny Ryan: a potential argument there but I

I don't think it's the most critical

George Kadianakis: okay I mean in that case I I'm I'm I'm I'm I'm I'm I'm closing towards not changing the cryptography and and just using the signatures for for authenticity and then doing the blood verification up

on the receiver of everything

Jacek Sieka: I don't have a strong opinion either way there's some minor performance benefits to having the blobs very viable individually in terms of pipelining in the client because now that you're receiving blobs uh you know right at random times it's it's good to get them verified as much work

done on each blob individually as possible before you aggregate them um but it's not a strong opinion the other one was that it was slightly more easy to specify what the message should look like when they're individually um proven because we don't really have any natural place to put the aggregate signature anymore like it's not a like it could go in the block but then it has to stay in the block forever and

then or you could send it

Jacek Sieka: zero which is kind of ugly and you know

George Kadianakis: interesting you mean they have to get proof yeah that's a good point yeah

definitely not put in the block please yes and we've been in favor of separate proofs weekly but but I'm still in favor of them

Tim Beiko: uh vitalik you've had your head up for a bit

Vitalik Buterin: I also just wanted to make the brief points that splitting is probably more future compatible with more radical ways to verify blobs more efficiently down the line like such as Erasure coding in the medium term and like actual data availability sampling in the long term it just makes it so that any portion of the network would be able to do it passively on its own without interfering with the rest of the protocol

George Kadianakis: uh what's the Erasure coding thing

Vitalik Buterin: oh this is this is the thing where like if

if let's say a particular block has like seven blobs then you actually brought like you Erasure extends them and you have 14 blobs and you broadcast to 14 pubs and then whenever you receive the first seven of them you can immediately regenerate the other 14 and broadcast all of them it's uh actually is similar to a technique that's been used by peer-to-peer networks in non-blockchain contexts that and you know it can increase the speed of propagation significantly and probably also increase like General deficiency because you have less redundancy or less overhead for the same redundancy in terms of safety

I see so it's not there for it for four thing it's a four eight four four point

five thing

Vitalik Buterin: right exactly the point is that like this style makes it more future compatible with doing that because uh that could be done without um changing consensus or an equally catching probably possibly even part of the network could do it without the other part

Tim Beiko: just want to get back to a comment in the chat as well so Terence you asked uh uh whether we had a timeline for the simulation result I don't know Mikhail if you have some thoughts on that okay maybe in the next next week's call

yeah yeah yeah yeah that's that's probably we'll have like clear understanding when we're finished like

not there but some you know progress towards the goal right

Tim Beiko: okay and I guess one of the reasons why it was you know somewhat urgent to to move this conversation forward is the audits if the if the crypto libraries and um I believe they're scheduled for about a month from now and so if we need to change how we view verification of the blogs um that's that's quite a short notice and we should do it now um but I guess from this conversation it seems like even if we didn't do individual verification of the of the blobs we might still get some benefits out of this um so it probably makes sense that yeah wait at least a week until we have the simulations results but from the

perspective of the the kcg libraries not uh not make any major changes now does that make sense to people

George Kadianakis: it does and we also got um we really we we asked the auditing people about the potential to push the date forward and they said that it should be okay but we should give them um some heads up before so yeah I think next week is that totally uh nice to have results in this

Tim Beiko: uh Mikhail you see how your hand up yeah

Mikhail Kalinin: question why why is the audit of crypto libraries

um it depends what else it depends on this um decision

Tim Beiko: because if we change lab verification to be for individual blobs rather than in aggregate I believe that was the that that requires changes

yes exactly

Mikhail Kalinin: so there is the kind of going to be a different uh verification function and we'll do it in this case

George Kadianakis: yeah right now we are verifying all the blobs in aggregate to get some speed boost uh because we have them we we get them all in one point but with this new design we would be getting blobs incrementally so there is um benefits to to to to to be able to

verify the blobs as they come

Mikhail Kalinin: okay I see probably we can chat about this

I'm applying

Tim Beiko: okay yeah let's let's do that and let's uh bring this up on the on the CL call next week um once we have uh also some more uh they landed simulations um anything else on on this um next up uh like client you've had uh this on the agenda for a couple calls now so I wanted to make sure we got to it but uh it was adding a new eat

accounts uh endpoints do you want to quickly walk us through it

Lightclient: yeah sure uh just this is pretty quick but um Martin actually wrote a request into the execution apis Repository uh in November to add this new method eth get account and the reason is we've had a few users requesting this type of functionality basically what it does is it takes in some address and it Returns the tri-leaf definition of the accounts which is the balance the store the nonsta storage route and the code hash if the account exists I just sort of want to get a feel for if clients are okay to add something like

this we kind of want to make sure we're moving the Json RPC forward together in unison with all the clients so unless there's any strong uh fill-ins against it then we can work on finalizing the spec and merging it

in

Tim Beiko: okay I need comment starts does it make sense to give people just uh today and tomorrow to review this and we can merge it Monday if there's no new objections I saw a Justin uh had left

like a review yesterday so like maybe giving people a couple days from from here but yeah merging it on Monday if there's no issues

Justin Florentine: yeah yeah I was just gonna say basically's pretty happy with it honestly

Lightclient: is anyone from Aragon here I feel like there yeah you guys tend to have different ideas about maybe what the RPC would look like or or maybe this could affect how you retrieve information does it seem okay to you

Andrew Ashikhmin: um no I think this is a simple method that should

Define

Lightclient: okay sounds good I'll give people until early next week and then we'll get

emerged and yeah cut a release for the apis repo

Tim Beiko: cool oh yeah does this cause issues with vertical tries to ski up on the call

uh what

Vitalik Buterin: What's what was the exact proposal again

Lightclient: um it takes a request in which is the user's address and it returns whatever the trial definition is which right now is balanced non-storage root code hash I don't know exactly how that would we changed

Vitalik Buterin: wait so what's the purpose

Lightclient: it just allows people to request the

account information

Vitalik Buterin: right I see like requests to Header information the advertal trees have a concept of a header so which is not super different or rather they like they don't necessarily have the same house structure but they do have the concepts that like there is a field for the knots there's a field for the balance there's a field for the code hash and so on

Lightclient: okay then it's forward compatible this doesn't have any hashes or so I mean doesn't have any proofs or anything so it

should be agnostic okay cool uh Lucas and then

Łukasz Rozmej: so other existing methods like that have this block

parameter parameter that allows you to get the value not at the head as that considers here

Lightclient: yeah sorry that is that is here it's the same format as for the other state retrieval methods so it takes block tag number or hash

Łukasz Rozmej: okay uh I need to dig deeper because uh it wasn't just on the pr conversation it's not obvious maybe it's an actual files

Tim Beiko: um Andrew

Andrew Ashikhmin: uh yeah uh I think that we in Aragon it's might be difficult or impossible to return storage route for

um historical uh snapshots so we don't store we only have uh for the current state we don't have historical roots

yeah

Lightclient: yeah I mean we also don't have all of the historical ones either so I think they would just return an error like missing try note or something

Andrew Ashikhmin: yeah we we can return balance nonsense uh code well Code test doesn't change ever but

unless it's recreated with grade two uh but we can simply omit storage route if it's not the current state

Łukasz Rozmej: it could be Mark as optional if it's not in the node right

Lightclient: yeah it's possible I think we should just take this conversation to the pr but I think it's a possibility thanks

okay

Tim Beiko: yeah so yeah let's discuss it in the next couple days ideally we can merge it uh if yeah there's no strong objections early next

week um next and last big topic uh for today uh is SSC um vitalik you had a proposal and then Ethan you had like a a EIP that was in draft about this um so maybe it makes sense um metallic do you want to start and then Ethan you can kind of walk through your your EIP draft

Vitalik Buterin: uh sure so what motivated this whole uh research direction is basically the uh realization that the kind of current eip4844 design puts the um eap4844 transactions in this weird

halfway house where they have SSD serialization but they um but or they're SSC based but then they're signing brood and their history route are still based on a serialization encoding and like this seems like obviously not what we want in the far future right because there is a goal of eventually moving things over to um SSC in some backwards compatible way and you know unifying things under one framework um and so the proposal that I had was basically like we're starting to think through like how we can kind of tweak the current uh EIP in order to achieve that

um but then a lot of people at our discussions in the research Retreat last week were of the opinion that it's uh it might actually be possible and even better to kind of do a more radical reform more quickly basically because this would uh reduce the total amount of work that would need to be done and the radical reform uh what it does is it basically does like three maybe three quarters of the work of moving the transaction part of ethereum over to SSD right and over to a pure version of SSD so where the uh the DX ID of a transaction actually would be the hashary root of a transaction which

is uh compatible with what the consensus lawyer does and then the signing root of a transaction would be the hash true root of the message part which is also what uh the the consensus layer does for blocks and attestations and all the other structures um and so it introduces two new SSD transaction types one which is a basically the existing for it for blood transaction except the txid is a hash tree root and the signing hash is a hashtag root of the message part and it introduces the second new transaction which is basically the same thing except it's allowed to have zero blocks right so one of the things that people seem like generally more in favor of work

instead of having one a new SSE transaction type and allowing it to either have zero blobs or one or two blobs you have one type that is specifically four blobs and it must have at least one blob and then another which is which does not contain blobs but that which allows you you to basically do everything purely with SSC and rely purely on SSD libraries and hash three encoding and all of those things to create and sign transactions now for the three existing transaction types uh we so this is uh Legacy which based on the V value covers both kind of like Legacy Legacy and chain ID based dip155 it

covers EIP 2930 which added the access list and did Cover zipp1559 which added the new gas gas pricing Mechanics for those three transaction types it basically stores them in the Block in an SSD way but at the same time it's still used like essentially can use as a pure function to convert the transaction from SSD to rlp in order to confuse both the signing hash and the txid right so if I send an old style transaction whichever one of those three types it is then I could still use old ROP Library

rop-based libraries I don't have to upgrade and I would send my transaction then when the transaction gets into the mempool it would get select converted into the SSD format it will get a good and a block in the SSD format and then when it gets that confirmation as the TX idea I would still see the same kind of ROP constructed txid that I'm used to and and so like even as a dab user I you know would not need to upgrade anything on chain or off chain in order to uh continue to be functional um so that's based that's basically it right so defining five transaction types three of which are basically Legacy

backwards compatibility wrappers and uh two of which are the 4844 type with blobs and the 484 Ford type without gloves storing them in the SSC in the Block in as a z and converting the transactions list in the execution payload away from being an opaque bytes object and into being a uh an actual SSD list of SSD objects and of course creates these backwards compatibility functions for older transaction types so people who use them can still continue using them this the same way without changes

questions

Tim Beiko: or comments on this

Łukasz Rozmej: so I'm very proud of this proposal I'm not entirely sure if I'm not missing something there but uh about this conversion how it will work but otherwise uh if it if it does work as intended it's like a silver bullet to have like both compacted backwards compatibility as well as go forwards very quickly so

Vitalik Buterin: there is a uh the the conversion function in both directions is a pure function and I wrote a python implementation that even has a test case to confirm that if it works it's in the it's in the dock that's looked in the EIP

Łukasz Rozmej: um for example like uh thinking um on the possible practicality of

storage uh storageing retrieving those transactions indexing them like internally and because now we have like both SSC and Patrick all right to identify them in some ways and so like is there a problem there

Vitalik Buterin: I guess like many index strategies are possible Right including the very late the very lazy one of like just uh adding a conversion to rlb layer before you do the you do the index step the though it would require a new one in usse based Logic for the two uh and you

as a purely SLC based transaction types

Łukasz Rozmej: also like this conversion is like fairly

intensive in terms of both especially like CPU memory a bit right so for example

Vitalik Buterin: I would say it's not

yeah like I said

Vitalik Buterin: it's basically like I think in total it's like less than a hundred just like bits bit twiddling operations if you include um you know all of the different things that are happening which is like way less than like even a single

a cryptographic thing

Andrew Ashikhmin: and uh does it mean that we have the same transaction route between CL and

DL

Vitalik Buterin: well okay actually there is one kind of

nuance here which is that if we want to uh temp like support backwards compatibility even for applications which do Merkle proofs that go into the historical state where you like actually have Merkel verification in rlp then I proposed one modification which basically include like keeps a transaction uh it keeps an MPT transaction route that contains only the old style transactions and that's something that could could be deprecated in extra one or two versions in the uh in the future but like aside from that you know I think there's no reason to have different Roots because uh like

they are both they do both become a Pure ssed from any coding perspective

Andrew Ashikhmin: because I I think if we introduce this transitionary period with the two Roots then it will be very difficult to get rid of the second route and my preference would be not to introduce like a special transition period and just switch to the

Seattle route

Vitalik Buterin: that's uh understood and I personally have no opposition to this but that requires the kind of standard I think you know back um backwards compatibility audit procedure of uh like making an effort to

go through which uh important applications do you use those kinds of mechanisms and you know whether or not they can be until um you know we can make sure that they upgrade fairly quickly I think the one that might be the most um the the highest value I believe I'm not sure if anyone from optimism is on the call but I believe it's the case that Bedrock which is their new uh their newer version it reduces gas costs for submitting a roll-up by or but for submitting a batch by allowing badges to be regular transactions and then in fraud groups allowing you to make a Merkel Patricia proof of the transaction but like even that like like I guess like number one optimism is a

yeah highly capable of team that's very involved in this discussions um including views and number two they're I think their fraud proofs technically haven't even turned on and they declared an intention to switch the blobs as soon as blobs become possible anyway um so that like that's the main case with the significance amounts of value that I know about but uh otherwise I think uh like we have been signaling for a long time that the data structures and that in ethereum blocks are going to change and people have had a lot of warning

yeah

Tim Beiko: uh Proto for optimism is here so you want to give some context on that

Protolambda: so like any roll up you do have to be able to prove data is included in the

transaction or received to really verify the availability we do survey for our transaction data so we prove that the transaction is indeed committed to as part of this try reference than the blockadder but B do not strictly rely on the transaction hash micro petition try overlap thing that happens in ethereum we can just do the proof we're not

married

Vitalik Buterin: but I think I think the issue is uh what if what happens when a uh future and possibly near future a version of ethereum doesn't even have an uh MPT route so it just has an SSE route and

that would

require you to be better to be honest that's easier less yeah less error code

Vitalik Buterin: right okay so let's error prone code and I guess uh like you guys technically have not taken off training wheels at all yet so it's very possible for you to upgrade so like a code that handles dealing with blobs or with

uh SSH

Protolambda: for Roll-Ups in general I think we should consider the upgrades but at the same time a layer 2 does not upgrade at the exact same time as layer 1. for each layer to two functionalities it's only really the block transition and we're getting

it's fine to change the behavior like even if if you have default proof or secret proof ready you should be able to prepare the new version and then based on block number yeah right you just deploy both

Vitalik Buterin: okay any other um I guess questions comments I mean I know I'm using how to uh like had his proposal but but that kind of gets into the weeds of how things are serialized which uh I'm not sure whether or not we want to necessarily get into into the next 12 hours 12 minutes because it is a

bit of a rabbit hole topic

Etan Kissling: not really um main question is when we process 4844 transactions as part of a block like uh not the block transactions that we have from the network that have the block so the ones in the block they don't have the blocks anymore and I was wondering are we processing them in any different way still like do we still care when processing blocks if if there were originally some blocks attached to a transaction or not and if they if they are processed the same then we can actually make one normalized transaction type

that we store as part of the block and this essentially guarantees that anyone who wants to do proofs on will be able to use stable generalized Indica for any field within a transaction so for example the transactions value it would always be at the same index regardless if it's a blob transaction or anything else

exact time yeah I

Lightclient: just wanted to say I assume a lot of clients do this where they end up creating some sort of normalized transaction once they actually get into

the transaction processing uh but I do want to push back a little bit on using that as the rationale for creating the overall transaction object as in like the normalized transaction the reason being is that there's still a lot of processing that happens that's transaction specific whether it's you know on the network level in the mempool or just setting up the state uh the state processor these things do need to exist like we need to know how to Hash different types of transactions that like the transactions still exist and so I think that it's just much clearer to reason to think about these things whenever they're actually separated and we can Define all the methods in a more generic way rather than having to do it

switching on pipes constantly

Etan Kissling: um you would still have to switch on the type even if it's side by side right it's just that instead of having the type on the entire transaction the type will just be a something that's used for hashing because that's the only part where it matters right so so there would be a number that tells you hey if it's three then it was originally hashed like so for the purpose of signature verification and transaction ID I think that's the only part that cares about but yeah um yeah I mean it's the only

change really that I had on top of vitalik's document is combine combine the different transaction types so that the proofs always have the same shape um there is also one concern I had with the hashtri route being the thing that's being signed because they can conflict with each other for example if we have this Legacy transaction container in bitcoin's document and then we add another field to it that can have a zero value that means something different than it being absent it will hashed to the same rule

so maybe we will still need for the signature purpose to add some version identifier that is not necessarily part of the

SSC tree

Lightclient: and to be clear we can have proofs that go that you know have the same generalized index for each transaction element if we use a different mercurization scheme like this onion format um and if we

Etan Kissling: if the onion format different fields and at the same field ends up at a different index

Lightclient: okay maybe I misunderstand but I don't

think we should go into too much dubs on that here

Tim Beiko: yeah I guess what is the best next step for you know just getting a general roadmap for SSD um I know we've been discussing this in the type transaction Discord does it make sense to just keep the conversation um is there anything else we should be doing beyond that in the next couple weeks

I think when there needs to be

Lightclient: some discussion about these changes to SSE because I think that even the proposal that Ethan came up with there is a new

type of like container where you specify the maximum size of the container and so this is a this would be a change

Tim Beiko: does it make sense to like have a separate call just for this SEC stuff I'm a bit hesitant given we have a lot of parallel calls going on right now but maybe that is the best way to make progress on it

Etan Kissling: probably yes I mean there is also other discussion like um whether we can do the entire Block in one go instead of this gradual process so that only the state tree would be the final Merkel Patricia tree

but yeah separate call is probably best

Tim Beiko: okay so let's find the time uh let's use the type transaction channel to find the time to do this um and then yeah we can we can sort of share updates uh on this or the CL call us as we have a better spec anything else on that topic okay if not the last thing uh Marius you wanted to talk about block benchmarking

Marius van der Wijden: yes so in um in Austria Marek from the Netherland team had a really good idea

um and uh the idea was that we create bench uh blocks and um and and some kind of benchmarking infrastructure on the clients so we can feed them these blocks and they will execute them verify them and spit out the time that it tooks for it took for them to to execute and um so we kind of uh started a bit with the EF security testing team and these blocks were most likely not be publicly available

but I will provide them to all of the client teams directly so that we don't leak any weird information um yeah just as a heads up to everyone that you might receive a bunch of funny blogs in the next couple of weeks

that's it sounds good uh funny blocks by Marius uh Lucas I have a

Łukasz Rozmej: few questions so um will there be some base State these blocks will be executed on how it will be this from this point or is it like don't have this block sort of first block after

this right now

Marius van der Wijden: right now the

idea is to to base them on on Genesis um just because it's easier and we will like we we will probably create a bunch of blocks so that we can set up uh State as we want to

Łukasz Rozmej: so what do we want to measure right because um uh going through like the op codes and executing the blog most of the time is accessing state right at least for another mind and this also is dependent on the storage model of the state that different clients are using and I think um we are working on on optimizing our

one but it so that's one of the

things

Marius van der Wijden: yeah State access is only like one part of the equation I I think

yeah but

Łukasz Rozmej: for example providing never mind State access is like seven at least 70 percent of block processing time and this scales with the um how the big state is right the bigger the state the the longer the axis yes uh so if we have like a small Genesis what we can really measure correctly is only the actual opcodes time State access being irrelevant right

Marius van der Wijden: kind of yes uh but uh yeah there might

there might be a future version where we start from a specific state but uh like setting this up is not as easy as uh just giving the clients a bunch of blocks

Łukasz Rozmej: yeah I mean state is Big right so it's not easily uh okay okay yeah cool it will be cool to have have this one uh will this be like um really makes blocks or like each blocks will focus on some on some uh op code and we will just stress test the clients based on

the sub code

Marius van der Wijden: um I think

it would start out with specific tests for specific things that we think might be might might be uh a very heavy

Łukasz Rozmej: problematic

Marius van der Wijden: yes

okay okay

Marius van der Wijden: thanks

Łukasz Rozmej: cool

Tim Beiko: anything else uh as we wrap up okay uh yeah thanks everyone see you all on the CL call next week um oh actually like client is there an eof breakout next week are these still going on

Lightclient: yeah it should be one Wednesday

I think it is

Tim Beiko: okay so yeah Wednesday 15 UTC there's an eof breakout uh and then there's a 444 call on Tuesday 15 30 UTC CL call next Thursday at 14 UTC and we'll see about

all right did

Lightclient: we did we say we want to do an SSD call too

Tim Beiko: we said we yes and I think the question is when we'd want to do it so we can talk about that on the Discord um but yeah looking at the next week it's already pretty pretty packed

yeah yeah all right let's talk on the Discord then thanks a lot everyone thank you thank you thank you bye

words Jesus

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