All Core Devs - Execution #155

Transcript

foreign [Music]

Tim Beiko: okay we are actually live now um welcome everyone to acde155 um bunch of things today so um uh we'll cover some Shanghai stuff and I think mirrors you have some testing updates from there uh then Cancun we had a bunch of discussions

about zero blob transactions uh in the 4844 call this week and I think it made sense for some of those to be bubbled up here um so we can hopefully move forward on them um and then there were a few other Cancun related uh topics so uh one Reddit Guardian minimal presets of the beacon chain which um El clients uh I believe need to start caring about with Cancun because if the engine API changes um we also had a breakout about the SSD transaction format so you can sort of recap what happened there in the next steps uh and then there was uh there was another SSD EIP about uh the withdrawal

routes um and then finally uh something uh regarding the transaction pool API so I guess the start uh on Shanghai so we have sepolia plan for uh February 28th uh ideally we denounced that early next week um and and thus assumes clients put releases out for it uh that's it uh yeah I know Marius you ran into some issues uh when testing on on the latest test net you want to maybe give us a quick overview of what happened

Marius van der Wijden: yes so um full notes were not full synced notes uh were not able to to correctly sync to the test net um horribly butchering did this so I'm just going to paper over it um basically the um the issue is if we got a block that was empty so it had no transactions no uncles and no um no withdrawals then we would actually set the um the withdrawal hash to nil

instead of empty withdrawal sorry the not the withdrawal hash the withdrawals and we wouldn't download the product we wouldn't download the block because the block is we wouldn't download the block body because the block body is empty and we we would but we also wouldn't correctly initialize it um this problem we had a similar problem in the past already the thing is like we can only figure out these issues if we have empty blocks and so fully empty blocks they don't need

anything to be downloaded and um and we are full syncing so it doesn't happen on Snap saying it doesn't happen when you when you're not syncing when you're when you're following the shin so um yeah it's uh it's it's kind of a weird Edge case but given that we had already two issues there with uh with Geth it might make sense to um have this as a test as a sync test just syncing a full chain like aah full sinking a chain from another client that has empty

I have fully empty plugs and um yeah it's fixed now um it's not in the release but we're planning to do another release with this fix and another fix basically today or soon um yeah so people on people on sepolia can just use the normal version but if you want to sync up after the happened then you should use current master that's that's basically

Tim Beiko: thanks

um I guess I'd be curious are we aware of other time teams having this issue

Marek Moraczyński: so I uh haven't noticed any issue during the sink but I will recheck all the edge cases would be nice to have Hive test of course

Tim Beiko: uh anyone else

Marius van der Wijden: so this is this this issue these issues are us because of one optimization that we do if a block has no body we're not requesting the block body because we

know from just from looking at the header that the body is empty and so we're not asking the network for it I'm not sure if other clients have the same optimization but yeah

Andrew Ashikhmin: yeah we might have this optimization we probably do have it in Aragon so I need to double check our code and see whether we suffer from the same issue or not

Tim Beiko: okay uh Mikhail

Mikhail Kalinin: yeah quick comment on not having a body for empty block uh is we have these get payload bodies um methods in the engine API so just to be sure that

those are handled correctly even if body is empty um you're not storing it

Marius van der Wijden: yes those are those are handled correctly and we have tests for it so yeah this is not a problem it's it's really only during sync and also like if if someone like gives us a a malformed block either we uh now also via the East protocol but before before that via the engine API we would just reject it but now we also reject it on if someone gives us a telephone block on the on the East protocol

Tim Beiko: okay and Mario in the chat said he can

had sorry he can add in a hive test for this so we currently had Hive tests for both empty like blocks without transactions blocks without withdrawals but not the combination the fully empty blocks I guess I'm curious just to hear from teams do you feel this should change sort of the timeline for sepolia or given we already have it fixed in Geth and you know it seems like it's a pretty easy Edge case to describe uh you know our clients still confident in having you a release uh for sepulia or at least you know pointing to master for this bug fix

um in in the coming days

Justin Florentine: this is basically I think we'd be more comfortable with that second option there we're planning our release for Monday

Tim Beiko: okay and and the Monday release would would make sure to not have these issues all right

Justin Florentine: well we'll try to get it in there but if if we're open to the option of someone doing a build off of Maine instead that would make us a little bit more confident that we can sort it out

Tim Beiko: okay um sounds good any other clients

Andrew Ashikhmin: yeah I think we can do a release early

Tim Beiko: okay yeah the same okay uh perfect so what I'll do is I'll I'll follow up with uh all the El teams offline um and see you know whether they have a release or and or you know recommend pointing to master Branch and and we can use that for sepolia but I guess does anyone feel like we we should delay sepolia over this okay so yeah guess uh we're still on track for uh February 28th and if you're listening uh you should expect releases

uh from the various client teams or the Verdes um Master Branch uh commits that support sepolia um in the next few days anything else regarding Shanghai capella that people want to discuss oh uh Barnabas yes

Barnabas Busa: yes uh I could give an update regarding the virtual devnet 7 that we have just launched on to yes so this uh seven was basically a very heavy stress test and they meant to

test for the worst case scenario uh on the main nut uh what I did is a 600 000 validators set with 360 000 BLS key change happening during chappella with the deposits and withdrawals happening all at the same time with the field queues and uh this morning at 9 00 am UTC and uh we saw a huge uh fluctuation in CPN RAM usage during the fork transition which was expected due to the extremely high number of BLS messages got hit in the Eric

um within a few days we will see exactly how many messages have been lost or get a better estimation and uh what we also noticed is uh we realized that there was a bug in the zoo and prism where this pair did not discover new deposits and we haven't noticed this issue before because we didn't make this amount of deposit in other networks but maybe someone from Badoo can explain this bug a bit better

Tim Beiko: and is it sorry is the issue they could not see when they were overwhelmed with

deposits they they missed a large share of them or they stopped processing them

all together

Barnabas Busa: so they stopped processing and also there were some blocks missed uh block proposals missed and we figured that it was possibly due to some uh RPC batch size issue

Tim Beiko: got it anyone on the base you or prison team have more context

Terence Tsao: um I'm not aware of this issue so so that uh so that I will follow up right now

Matt Nelson: yeah I can this is bad I can provide

some more context uh we recently limited this RPC method intentionally to a small value to kind of avoid uh some dos vectors stuff but we realized that you know in the case of prison they expect the round of a batch size of a thousand so you know we're providing a much much smaller batch size I'm not sure why it would completely stop the process we need to probably investigate that but we will reevaluate this this value uh and we we're aware of the issue specifically

got it uh thanks anything else on chappello so in conclusion that

Barnabas Busa: we have lost one

Epoch we went down to 62 percent uh doing for transition due to the extremely high RAM and CP usage but we recovered within uh three epochs afterwards and uh I think it's expected it to have a lot uh smaller case and may not because we don't expect this amount of BLS ghosts coming and we're gonna have a lot more nodes so this is really just the weird case scenario

Tim Beiko: um and then what was the split of the different validator combos on uh the devnet was it like matching mainnet or was it uh like an equal split

Barnabas Busa: not equal and it also doesn't match I I can get you the number

Tim Beiko: sure yeah if you want to post it in the chat when if if you don't have it off the top of your head yeah that'd be great

Danny Ryan: and will we run the um boost circuit breaker test on this test net as well

uh no we'd be running that on um mainnet Shadow form 2. okay cool that's still in Partners though

Parithosh Jayanthi: uh yeah I had some issues syncing up the nodes before starting the shadowfuck so it's a bit delayed but we get to that soon um and math boost has been deployed on as well uh but I think for now it's just

returning 204 as Builders are coming online but the relay is set up so we could do a circuit breaker test on as well but I think the idea is that we don't because we want to keep it stable for public testing

Danny Ryan: yeah that's fine

thanks Perry

Enrico Del Fante: which version are you running for for these tests

or else map boost or no

Parithosh Jayanthi: clients at the moment it's the latest releases so there's uh it's still waiting for the relays to come online before I go asking around for which versions to update

them

Enrico Del Fante: okay so you you were not planning to use the upcoming CL release

I

Parithosh Jayanthi: I will once the releases are done but we haven't started the shadow Fork yet so once it's done then I would reach out to get the latest images to run

now

Enrico Del Fante: cool thanks

Parithosh Jayanthi: yeah

okay anything else on shapella

Łukasz Rozmej: I want to say that we just I just confirmed that we already handled this uh empty Body Issue correctly

in another mind

Tim Beiko: nice

okay and yeah for people listening uh so expect a blog post uh it's early mid next week with this and also keep an eye on the different client repos um as they put out releases or announcements uh for their sepolia uh shapella versions um and again this Fork is scheduled for February 28th which is uh Tuesday about uh 10 ish days from now yeah anything else okay uh otherwise uh let's move on to Cancun

um so we had a 4844 call this week and I think one of the big uh I think things to agree on to move forward is what to do with zero blob transactions um so there were a bunch of mempool designs that relied on the ability to discriminate uh between blob and non-blob transactions um and an assumption there is that this sort of eip44 type 5 transactions have blobs and therefore are bigger um and the other ones don't um and so there was discussions about whether we should allow zero blobs

transaction um in protocol but ban them from the mempool so that the blocks are created with them it's fine but uh clients don't process them in the mempool directly whether we should just straight up ban them in protocol as well at least to start um and if we do it all these zero blob transactions and then what's the right way to discriminate uh you know between uh blob and blah blast transactions do we want to look uh at basically the length of the blob list that the transaction type that we want to gossip this information in something like 868 um and basically I think aligning on all

of this allows us to get to a transaction poor design which uh hopefully is more efficient and can can handle the actual blobs in a way that's different from transactions that uh don't have any blobs um so I don't know if anyone uh I guess from the El side wants to maybe start and chime in here my feeling is most of the yeah folks were leaving on the not allowing zero blobs but different sort of uh variations of

that um yeah Lucas

Łukasz Rozmej: so I was thinking about this quite a lot and uh while I I settled down that I don't like any any solution but what I'm leaning to now is either

having some additional metadata for transaction for example transmitted into ETA 68 or just using the size of transaction to determine the rules of how to how we behave with this transaction so for example if we have a big size transaction even if it's like whatever if it's a blob transaction or not it will go into this large transaction pool right and this also resembles to me a bit how for example some managed languages like dot net or Java handle uh big objects that for garbage collection they have separate

object keep for that with special rules so kind of makes sense for me and it's like it is the elegant solution from from the design perspective and you know from implementation perspective like trying to think about that it's not about type of transaction but the size of transaction also makes some sense to me so I'm not entirely convinced like I said I don't like any of them all of those things kind of like creep issues into implementation to make it more complex but maybe that's what I would suggest

Tim Beiko: got it uh okay yeah Peter why do you disagree

Péter Szilágyi: I think it's a horrible idea okay uh the theory is super nice super elegant and insanely complicated so the fact is in order to differentiate so the whole point of block transactions is that you have behavioral limits on it it simply behaves completely different with a large transaction you can have a lot of large transactions in the block but you can only have one or two block transactions in a block that's a huge behavioral differentiation if I can have zero block transactions and it's gone hacking e68 to transmit the block size that for the transaction size that's

completely moved because I still can have really huge I can have a two megabyte transaction plane transaction that would be transmitted to one mechanism and block transactions will be smaller and so I think it's just the whole point is with block transactions it's something very very specific that we can we can use those specifics to make optimizations and I get it that from a research perspective it's super nice to make everything completely generic and then the whole thing will go all apart just like the work of Patricia trifold apart this piece of and same thing will happen on transactions we just make this

meta transaction and then we'll just say okay screw it uh we sure hope that immediate boost and all the others can handle it because clients sure as I won't be able to delegating everything out to somebody else who has the infrastructure to handle all that

graph I

Dankrad Feist: I didn't get your argument there you said like you can have a two megabyte bit transaction and a block transaction and what's the problem there

Péter Szilágyi: my point is that I cannot differentiate it so the currently the idea about the block transactions we transmit the transaction IV in the transaction announcements on the network so I know what which ones are block transaction which ones or not a new

suggestion was to forget that and just transmit the size but then I just get one big super transactions again

Dankrad Feist: right

Péter Szilágyi: but how like because I still don't understand Lucas only the transaction

ID is uh Alexa you've had your hand up yep uh since

uh another idea would be uh to encapsulate all these

separate Logic for handling big transactions or block transactions or whatever because it's just one or two cases maybe we will have more in the future and uh we can announce not size or type of transaction or we can just share a flag that says uh you would not like to download this transaction like that I mean uh transactions will be well different of different I mean if you uh will load

a transaction and the size is not um uh like um is not uh past uh the correct size is not passed you will verify it that it is too big and you reject this peer uh probably uh you want it you want to reject the person that send you big block transactions or just big transactions uh at the end and so instead of sending some details so about the transaction we can just send like enumeration that says it is a big

transaction that's why you don't want to load it or it is block transaction and so on and add more reasons why you should not download it um and it can be like the solution

got it uh Andrew

Andrew Ashikhmin: um I think for simplicity's sake I agree with Peter I think the simplest thing to do is just to introduce a new transaction type for the non-blobe SSD transactions and it it already chimes in nicely with uh is 68

it has nice semantics uh I I think like for total simplicities to my mind is the best solution I I don't actually see what are the drawbacks

Tim Beiko: and the the reason for adding this extra type of transaction is so that you can only using like SSD supporting infrastructure sign both blob and non-blob transactions is that right

Andrew Ashikhmin: uh well and going forward I mean I think going forward we want to move to SSD but so the the new the new type S is z without blocks will probably be our preferred transaction type for no not

only for for L2 Solutions but essentially for uh for for everything and uh this like clear differentiation between non-block transactions and block transactions by by their type I think it plays nicely with the semantics because you you yeah you kind of they solve different purposes uh rather like a be as a your run-of-the-mill transaction or be or carry blobs so got it I don't see a problem with it with two types I think it's it's a benefit that it just highlights the semantical difference

Tim Beiko: but we yeah and so uh this means that we'd have like effectively five transaction types right like or maybe six with the pre eip151 or whatever but you would you would keep the existing Legacy transaction types introduce blob transaction and then uh blob transactions which require a blob and we can have this hard limit there and also kind of separately introduced an SSD zero blob transaction and this means that uh like mirrors is saying in the chat uh we we can do things like

add more restrictions to blob transactions like for example not having access lists not allowing contract creation and so on

Andrew Ashikhmin: right yeah that makes sense

Tim Beiko: and I guess you know with regards to the transaction pool we don't actually need all the clients to have the exact same implementation like this is not the case today um so say we went down this route of having two new transaction types one that is like both of them being SSD transaction types one of them being a blob transaction which requires having a blob um and potentially uh has some other uh

other restrictions and then another that is uh SSD no blob transaction which is effectively the equivalent of like a type 2 transaction today how did people feel about that um Lucas

Łukasz Rozmej: so uh while we don't have to have the same transactional implementation historically I've seen that we Converge on the very similar implementations due to security reasons and second thing we still need to agree on eth68 if there if what's how it should look like because this is what we all need to be support

Tim Beiko: right that makes sense yeah

Danny Ryan: uh Danny you see there's gonna have to be conditional objects somewhere around number of blobs around size or transactions Etc and I think ultimately uh you know if Engineers think that is embedded in the type is going to reduce complexity then that's probably just what we should do um and and move forward

uh Lucas

Łukasz Rozmej: the one the one good argument uh that I heard about allowing zero blob transactions is that

when if we want to upgrade our transactions to I don't know have a new field and this new field will be for blob and not blob transactions then we have to create two transactions right and this kind of complexity might increase if we like introduce uh something else that will have a separate transaction type so this kind of is some kind of metadata if this transaction has blobs or not it doesn't have to be a transaction type um but yeah we need to we need to have this logic somewhere so I agree but not sure if the transaction type is the best thing I was thinking about think thinking about transaction type as a like some of its last bits as flags

but then we only reserved 127 transaction types which is a bit uh not enough so for example last if it was like 32-bit if the last bit is set then it's uh it has blobs if it's not set it doesn't have blobs it's robots we can probably either duplication right so in this case or have a separate metadata filled with some Flags but that's it

Péter Szilágyi: so one thing that I mean kind of wanted to add is that I we very very often fall

into that uh I know fault error whatever we try to make things super insanely generic from the get-go and we have absolutely no idea why and from my perspective that feels like a bad thing to do for example saying that well we shouldn't uh the students introduce specialized transactions because we're going to run out of 128 transactions I mean that's a very very big a very strong argument so it's I mean we have absolutely no idea if we will ever introduce another transaction or or transaction with another field so it's you know

I mean can in my opinion I personally prefer to go with the Simple Solutions try to figure out or try to make it more generic for when when there's actually genuine need for it and yeah that does mean that we it might happen that in the future currently you make a decision that's not the best in the future and the future will go on a bit of complexity but the problem is that if we make it super generic just for reasons and then we have to Picto around that forever and there will never be actually another field ever added it just feels weird also this kind of ties into what

Murray's suggestion was that he suggested that we could even cut down more features under the blog transactions and I don't know personally I prefer you have transactions that are have very very dedicated use cases so this whole 4844 has a very very strong design a very very strong use case and in my opinion we should try to just focus on that use case a lot making this super set of everything I mean for sure it's elegant to make it a supersuit of everything but is there any legitimate reason to do so because currently apart from saying that it's elegant from a theoretical

perspective there's no reason whatsoever that anybody can come up with

tried

Tim Beiko: to think what's like the best way forward here um I don't feel like I don't know from the El side like having this be like yeah having this be more tailored around

the current use case seems like it's simpler um there's like some value both in terms of like making a generic framework and and uh yeah base and and also like ease of use for like ltus if if we allow zero blob transactions but it seems kind of marginal so yeah I guess you know does anyone on the El side feel like we should like push forward for like a zero blob and sort of more flexible 4844 uh transaction type otherwise we could at least make the call that like

the zero blob transactions shouldn't like be possible um and then you know there's this whole address is the discussion about how we want to approach that we can we can go to that after um but I think if if we all agree that like we shouldn't do zero blob transactions uh I think the other thing uh the other thing to figure out is like do you ban those in the med pool only or do you ban them in protocol as well and Dano has a question about like what wallets and uh

chain infrastructure tooling project things I I don't have a great view does anyone on the call have one

Danny Ryan: I would suspect this is currently a very domain specific debate that most people don't have a perspective on

Tim Beiko: I think the optimism folks seem to like think this was fine and generally on the L2 side my feeling is that whatever gets 4844 ship the quickest uh assuming it you know is like a small technical change like they would probably prefer

to work around that and have four four a month third year then you don't have 444 be delayed because um yeah yeah because we're not uh sort of aligned on the transaction times and yeah Alexa has a comment in the chat as well like you know uh there's also a world where like say we just shipped this and only l2s used this and we sort of don't have the whole SSD move happen in Shanghai um so that I'm sorry in Cancun so that's that's possible as well

um and if if you went down that route um it's basically only l2s that have to deal with this new SSD transaction type maybe it's very limited and then maybe you know in the fork after we can like come up with a with a broader SSC scheme so it's um yeah it doesn't have to to all happen at once so unless someone wants to make like a strong case for zero blog transactions now I feel like we should ban them um and then the question is you know should we ban them just in the mempool

or in the mempool and in protocol for um does it make life easier if you know we just assume they never happen versus we just assumed they don't show up in the

mempool

Danny Ryan: I believe the zero blob transaction Camp generally is assuming those two things happening simultaneously especially due to the reorg considerations

Tim Beiko: okay uh Andrew

Andrew Ashikhmin: uh I think we should ban them in the protocol um and it's it's easier to start with the with some restricted functionality and uh I I agree with Peter that we should move in the direction of uh more

generality uh actually driven by concrete use cases rather than just some some philosophizing and also Banning them both in the protocol and the mempool makes things consistent and easier to reason about

Tim Beiko: okay does that yeah that would be my assumption as well and it's easier to relax that constraint in the future than to start without it and want to add it afterwards

gar you know

Ansgar Dietrichs: just very much to say um just because I think in general I would have preferred to basically not bend them in the protocol I think it's fine but I think we can go ahead and depend on the

broker for now but just kind of philosophically I would say that over time at least maybe now isn't the time but over time we should be willing to move more and more towards the world of uh specialized mempools where basically not having all the functionality Buffet at all times by the kind of incline members would be fine so for example kind of at riox not being able to reinsert some transactions into the mempools and whatnot these kind of considerations I think I know that kind of hesitant with that I think philosophically of the long term we could move more towards being willing to have more specialized out of protocol mempools but for now I think just Banning but zero transactions everywhere

I think that's the

problematic choice

Tim Beiko: okay does anyone disagree with Banning uh zero blob transactions across the entire protocol

Péter Szilágyi: so both on chain and in perhaps one note the stand for the Banning is that uh I do agree again that it would be an elegant for us to to say that well if you use some weird combination of the transaction and your transactions will not get re-included and you have to go through

whatever route you went through the first time to get with me good but I think that kind of uh that sets a strange president of this for me that's actually the only way to improve certain transaction is to go through some mining pool or some some flashbots bundling service and essentially the only way to re-add it is to monitor the chain and then go through the same bundling service once more and if it kind of gets into this weird place where people will just not use normal clients everybody will use the bonding service because it can bundle stuff that the normal client cannot or

will know so I'm not sure that it's uh I mean even nowadays you can see that people are using uh all these works of of so many other clients to them because you can get some MVP funds I mean every bonuses for mining and I think it will just every single opportunity where they can make more money they will just more and more people will switch over I mean that's kind of fine if you have a

good enough and fair enough infrastructure built out but I don't think we have it yet so I don't think we should push too many people the words that that basically every validator having to run flash plus because otherwise it's just not working right

Tim Beiko: and I guess by Banning them at the protocol level today we keep this a bit more fair with regards like the public mempool where you you just don't get this functionality by rallying around guest or

never mind all right I'm

Péter Szilágyi: I think it's uh it's more

of a generic note that right uh so what I wanted to say is that this reasoning that there will always be some operator which will be able to re-include something that clients cannot is a dangerous uh line of thought

it's

Péter Szilágyi: so that's the only thing I would like to do I would like us to keep this in mind to that for sure we can Outsource certain functionality to other actors in the system but we should we need to think it over carefully as to what the implications will be

Tim Beiko: yeah I think that that makes sense

okay anything else on the Zero blob transactions um if not then I guess in terms of next steps uh could one of the 4844 authors just make uh the change to the EIP to say that uh basically type 5 transactions need a blob okay uh Ansgar says he'll do it in the chat uh so thank you um and then obviously the the sort of ripple effect from that is like uh as we're continuing like implementing these these transaction pool designs uh we can

now take for granted that uh blob transactions or type 5 transactions will come with a blob and separate those uh from the rest of transactions okay and I guess on a like similar note it might be worth uh going into the broader SSD conversation so we had a call about this uh I think it was literally yesterday um do you maybe want to give a quick recap of the SSD call

Etan Kissling: sure so we still have uh like first of all this is not about the blob SSC

transaction and also not about the zero blob transaction um yesterday's call was uh for the representation of transactions as part of the transactions route in the block header um so there are two approaches there one is based on using a union that is using the transaction type um to create separate objects underneath depending on that type the other one is the superset approach um where we use the same structure as you have on Json RPC where you essentially have a generalized transaction that can be used

to represent all of the transaction types and yesterday um we could not really decide which one is better both of them have advantages and disadvantages so we decided that we simply create a couple prototypes so that we can actually see in practice on concrete examples how big are the differences between them when they are actually used like is a union really that ugly to implement in a zero knowledge circuit stuff like that so I will be working on creating those prototypes and benchmarking them against each other to be included in about two

weeks so then we will take another session to decide whether we want to use the union approach or the normalized transaction approach to represent those on transactions route um there was also a discussion about the fp2p networking whether we want to upgrade those as well so that when historic blobs are with historic blocks are downloaded whether this reduce the original encoding based on rlp or whether we should use the union or normalized transaction um that that was also an open discussion point but still undecided as well

um yeah that's a summary from yesterday

Tim Beiko: thank you any questions comments

Łukasz Rozmej: I have like a Time timeline question um is this being considered in Cancun right because it makes sense to be considered Cancun because we are already adding SSD transactions so we can like have a full move to SSD on the other hand if it will be considered in Cancun it will definitely take longer time right

Etan Kissling: so yes the idea was to including it uh into

Cancun and also to if it makes sense to align um the common part of 4844 with it um but complex Parts um like adding the SSC support to the Els is already done as part of 4844 so um regardless of whether this is a union type or a normalized type that will go into the transactions route um it it is the same complexity I mean right now we are just having rlp there that also works fine but yeah and about bankrupt's question uh to Benchmark there are things like

um when you when you get approved from based on these three how expensive is it to run a verification of a proof in in a smart contract for example how big is the call data how expensive is it to the place deploy such a contract mainly focused on consumers of the proofs exactly

yeah

Dankrad Feist: so it's about about gas cost of verifying um like proofs on a union field or a an optional field

Etan Kissling: of the Union transaction or the um normalized transaction

essentially and also about the different network encodings um just a byte length for those right

Tim Beiko: yeah so what and so yeah we have the breakout for this uh two weeks from now and we're using the type transaction channel to chat about it in the meantime um I think also on the question of like um it would be good to consider this alongside like all the other potential things we can do for Cancun so we haven't quite like made a call for

people to come and shell their various proposals uh for the upgrade yet um so I think we we probably want to do something like that just so that we have sort of a full picture of what uh you know what we're trading uh off against um so I suspect in the next couple calls it probably makes sense to to try and get a list of like what are the things people would like to see in Cancun and then um this this will be one of those items but yeah at least we'll have a full picture for making that decision um and if people I guess if for people listening if uh you already want to

start sort of signaling what you'd like uh included in Cancun uh there's a tag on East magicians uh Cancun candidates so if you have your EIP there um you can just add the tag and then there's also like a a thread about the entire upgrade um for folks even like if client teams you know you have already strong preferences of stuff you'd like to see um it makes sense to just share those there and we can start discussing that in the next couple calls any any other questions about uh SSE transaction types

uh if there is a comment about the theory of magicians being done it's not down for me that's weird we can look into that uh okay next up uh I believe eaten uh and Mikael you had another SSD related topic so basically uh moving the withdrawal route from uh uh from the MPT commitment to SSD uh dude or if you want to give a quick overview of this

Etan Kissling: uh I can do that as well so thank you um that's mainly the follow-up from what we

discussed for Shanghai um and also postponed explicitly so that we can make sure that these withdrawals will follow a similar scheme that we have for transactions and receipts um but conceptually the withdrawals are separate so it could be that we want for example the withdrawals and the deposits from another EIP um to to be included earlier than the transactions and receipts so that's why I'm bringing them up separately and the other thing that I noticed when I wrote the EIP is that the dev P2P specs for how withdrawals are exchanged

I couldn't find them so maybe that spec is still missing or I didn't check at the correct place but I wasn't sure if right now with Shanghai we are exchanging withdrawals in mp in rlp or in um or in SSC format on the wire and if it's rlp I'm not sure if it has a version byte in it yes it's in the bodies and in in the block header there is also

a root okay and any thoughts comments on this

Andrew Ashikhmin: uh we exchange withdrawals as ROP in Block bodies in El peer-to-peer

Etan Kissling: okay so just at least no version

byte or no version there

Etan Kissling: um is there a problem when we later transition to SSC or can we like just bump the East protocol version for example is 69 and then use SSE and if it's like eth68 then it's rlp or how should this work

Andrew Ashikhmin: uh well I guess it has to be it doesn't

strictly have to be but um and it's nice if it's consistent with the transactions and currently blog bodies we use ROP for both transactions and withdrawals so I would actually if if we are changing that then we should change that like the the marshalling for transactions as well

the effort

Etan Kissling: transaction it's a mix it's rlp for everything but type 5 and if it's type 5 it's a SSC actually not yet that's for the other question whether this should be bundled or

whether we should transition withdrawals earlier there is one thing to gain with withdrawals namely that right now there are there is no seeing a client that depends on this rlp based Mercury Patricia try root in the header and the longer we wait the higher it may become probable that someone is actually starting to use that route for for example rocketpool could use it for some rewards computation or something so not sure if if that is a point that we should also consider not

Tim Beiko: and I guess what's the best place to

continue this conversation the it magicians thread or is there a channel in the Discord as well

Etan Kissling: magician's thread exists I think that one is all right I'm not sure about the channel

Tim Beiko: okay so let's use that and um hopefully people can review it in the next couple weeks so that yeah we basically can make a call on this um as we're looking for other

Cancun's stuff um next up uh so there was a comment

about the minimal presets um which I believe are like the test net configs for the consensus layer and that uh with 4844 an introduction of blobs this uh becomes part of the engine API and therefore El clients should be aware of it um does anyone want to give the context on here a per second

Dustin Brody: yeah oh sorry yeah Apple so so first I will just sort of introduce very very briefly um the idea of the mid open Fake is yeah probably it's meant to be used um it's for test Nets also the consensus spec tests use them for various things where

um it would be infeasible or just slow to run a certain set of tasks on in mainnet presets functionally they they change a couple of things they change many things one of which I'll mention but a key thing for there is they use um uh six second slots and and eight final box and then there's some other settings but they you end up with 48 second pucks and it's quite a bit faster so but the relevant thing here from for the most part these have not um reflected the execution layer um and through capella and Shanghai that remains as far as I can tell true however in Cancun um that will start changing because

they're with the plots there is now this blobs fund will be one structure which in the engine API is currently specified is hard coded to um number it's the number of field elements is 4096. this is consistent with the main net preset but not the minimal preset which means that uh a minimal mode CL attempting to use the engine API will be just speaking in incompatible engine API protocol when it tries to use the engine get Blob respondently phone call sorry P1 call now this is on the one hand you can say well this is a very this is a specific call and specific data structure but I I think it's worth

bringing up here because I think it's the first time as far as I can tell that the idea of this minimal mainnet preset has kind of encroached on the engine API on the eels and so the question is kind of at some level what to do about it um one and so I'm going to present I mean obviously part of presenting it here is I want you know so if other people have options that's great but but like some options to start with um one is we can just decide that well um it is in details for testing I'll present four options to start with that and are meant to be sufficiently or let's say a reasonable granularity um because subdivider combined them as desired one is like so basically we decide that well

the engine API is only for mainnet like that's and if the consensus back test want to do some minimal thing but they don't actually use the edge API because they don't do any networking things then that's fine we allow that to break and anybody running an actual Network now Ron's main net regardless I would say one downside and that has obvious upsides of um there's no uh there's there's no uh changes required at some level of the engine ape guy um and so the status quo continues working the downside is it effectively starts deprecating the minimal preset for anything but pure consensus that test and they become even more this

artificial kind of thing that that can't be used in practice so that's for due to another number of considerations would actually propeller exacerbates so that's option one option two you can have the El somehow configured at startup because there's nothing fundamental about this number I mean it's specified in the engine API but you can just say well the in-state API specifies some kind of preset and you can the next most General when I'm ordering is an increased generality uh or or we specific approach is to say the engine set says uh um that's why the Els are given some configuration parameter that's basically very specifically this number of billions and

there and either it's a Boolean or it's an integer or something and then you can just make that compatible with the CL that's option two option three is there is an attempt to align things more broadly with the sort of ideas so don't specify this particular field number field elements say that oh well the El now knows about this notion of uh a preset for minimal or mainnet preset um so this is a little bit more elegant for what it is but at the same time like

it's something that yells haven't had to care about and it's kind of strange in some ways that they should have to um and the fourth is a much more general purpose thing um that and people have at some level the argument here is this call already starts existing on people are proposing for capella and API call that will sort of do a kind of a configuration exchange essentially not the large one um where it was just what it are regretting for merge but just a more general purpose um what what methods are supported and things like this so those are some for for um sort of example options and um and doing nothing is also a choice so that that's what I wanted

Tim Beiko: um yeah Mikhail you already have your

map

Mikhail Kalinin: yeah I feel like the last option where the configuration is exchanged in runtime can you know create additional complexity of changing these parameters at the runtime so basically one cl yeah theoretically can connect to El and set one number for this particular config parameter then the other connects to it and the album yeah in the general case have to support you know switching it over to a lower number or whatever so that's definitely a complexity on the engineering side yeah the pre like

having this as the command line parameter I don't know or haven't pass and full specification of of the CL you know um chain two three l probably doesn't make uh sense because yeah really has nothing to do with most of those parameters and I would say that this this particular case is rather an exception than the common thing that we would like we will see in the future because here we have what transactions on El side which then including propagated on CL side

so that's kind of like really uh looks like an exceptional case for me so if we are about to do anything with that as you've said there is an option to do nothing I would choose less invasive and less engineering complex solution as possible so yeah that's kind of like my initial opinion on that and also I have a question what kind of devnets or test Nets are we running with a minimal presets as far as I know we have all of the devnets that we have for I know Fortune high for immersion for other probably

um upgrades they are running with the correct me if I'm wrong so kind of like minimal presets more sounds like for the local machine setup or a small that would definitely not that you know have in your testing you some features and all this kind of stuff and probably it's not that bad to have field elements uh set to like you know a mainnet number in in that always I don't know so that's kind of like

Miley shopping around um I I

Dustin Brody: I would probably agree um I'll say that

um certainly once we get to uh yeah I see Barnabas has indeed what what partner has said uh also the but it is true that by the time we get to and certainly anything publicly visible the public test Nets are all um mainnet fakes and I will just take it I mean it's like anecdotally runs the CIS often with with minimal um just in case but the other maybe what I'll say is this the other um uh aspect and you know another option actually is to change the this particular field and it I think you mentioned this as well or this is one of the things you say but to kind of pull this out maybe we used invasive slash

fix is the issue in a lot of ways have the minimal presets um just say that um this this particular parameter is the mainnet Predator so that we um ensure that the engine API at least is not affect it this affects minimal presets to some extent yes it makes them a little less minimal but it also means that this issue just goes away um another thing this has come up and I don't think Hyatt uses it and this is different than what modern just mentioned but like you mentioned Hive and uh Hyatt is certainly looking to run for example six second slots when they can now there are different ways of doing this one of them is you can take take a tweaked mainnet uh preset and just change seconds per slot to six and

that does work but we also have it for the existing preset which is tested um you know that we have consensus tests and everything for it that had is designed exactly to run quickly and so hype has found this idea useful as well so I I think there's some utility in the minimals presets enough to not completely not to want to get rid of

the kzg libraries have hard-coded values for mainnet I guess from this El

teams does anyone have a strong opinion about this

Justin Florentine: for basically it's actually a little less work for us to only support the 4096

else and there's a oh yeah Alexa please don't mind uh these two things

that it is a fixed number and we will probably

change only block count uh possible in the block uh no no settings for that and ckg Library does not support people right

Tim Beiko: yeah I I don't know uh maybe Dan crowd their Proto is that a right correct assumption that like will only ever grow the number of blobs per blocks but this the 4096 field elements per block blob will stay constant

Protolambda: yes

um I I would not that that that's I mean what do you mean like forever

I don't say two years two years is my forever right right

Dankrad Feist: in this case I mean I would not want to make this commitment I mean it's certainly like an option to long term also grow the grow The Blob size I mean that's why we're doing four different versions of the ceremony so that we can increase the plot size

Tim Beiko: okay so I guess and there's some comments in the chats now but just saying we can change the minimal preset value of just this for now um there seems to be agreement on that so does anyone disagree for this specific preset value

um to just use the same as

your main nut

Dustin Brody: I mean I'd be okay with that personally

Tim Beiko: great so let's let's do that um if someone can do a PR on the CL specs to update this that'd be great

Dustin Brody: okay I'll I'll make that PR awesome

okay next up uh there was a discussion around uh standardizing the transaction pool namespace Wesley are you on the call

yeah okay yes give some context about that

sure yeah uh I dropped a proposal for standardized the Expo API or execution clients um or we spoke to some folks that each of the client teams as most already have some endpoints and custom implementation for it but uh proposal is a way to hopefully find an agreement on a more common subset which would be great for interoperability obviously but also allows hopefully for more reliable Integrations for example CR or inclusion lists that are being discussed at Meg boost for example um not too familiar with how this process work or how to best approach it

but uh you sh I think you shared a link already in the chat it's also in the agenda from today's calls

Tim Beiko: um yeah I guess has any uh El fine Dev looked at this and have any opinions they want to share

uh yeah all right

Marek Moraczyński: I like all standardization efforts kind of however I'm wondering if it is worth to change method names probably people who got used to previous methods names and we could potentially break lots of tooling because of

renaming

yeah the Russian for for changing it was actually Four backward compatibility because each client currently has their own implementation and changing that would more likely change existing Integrations or just setting up something new would at least avoid those those issues

Tim Beiko: can we do something like just deprecating the yeah we can like Mark the old names as deprecated have the clients Alias you know both behind the scenes and then eventually just remove the old ones from this back um and I think there is precedent I

think there were some Json RPC calls we did markets deprecated in the past um I'm not quite sure which ones but I remember having this conversation a while back I guess uh probably in terms of next steps uh if client teams just want to review that PR and you know leave any comments or leave like a thumbs up on it that would be great and then yeah maybe we make this change just to deprecate the old apis uh and or mark them as deprecated in the spec does that make sense to people any

objections or other thoughts okay so yeah let's do that um anything else Wesley

no that was it

Tim Beiko: cool thank you um and then okay so that's what we had already on the agenda but uh Jared you said you wanted to chat about self-destruct

Jared Wasinger: uh yeah hi can you hear me yes great um hey yeah so yeah so we had uh I guess where I left off uh on self-destruct was a last piece of analysis around the potential impact

of EIP 4758 which was the approach to just uh turn self-destruct into send all and uh kind of the the nuclear option if you will um that would uh potentially uh well not even potentially uh that would have backwards compatibility or would cause uh contracts to break um and since then it kind of seems like there hasn't really been a proposal that's come forward that has seen seemed or to me at least seemed actionable to pursue um so I think that

uh what I'm wondering um to get a read on from people in this call um is whether we think it would be valuable to uh put more resources towards analyzing uh contracts that would be broken with uh for eip4758 uh under the understanding that we probably won't be able to find every broken contract but the uncovering more could be valuable I'm just not sure if we have decided that 4758 is completely untenable and to not pursue

it or it just is not very clear what the what direction to take here so I just wanted to get a read from the community if anybody has any opinions

Tim Beiko: yeah thanks uh Andrew has his hand up

Andrew Ashikhmin: uh yeah I think there was another development there is this eepa 6048 proposed by exec which might be less backwards much not not as much backwards breaking competition okay so yeah it's more backwards compatible than the nuclear option 4758 so I would

I don't know the details but I think we should contrast the two and uh yeah have a deeper look in we haven't exhausted the uh all the design options yet

Tim Beiko: right so I've posted the EIP at 6046 I've posted it in the chat and the idea was that um when you uh when you solve this track a contract you just change the nons to basically the the upper like the max nonce value um we don't delete the storage Keys we transfer out the the funds which is

basically um like send all and then there was this I I guess the biggest addition was that you would modify create two um you you would modify create two so that uh you can actually redeploy a self-destructed contract uh but uh at the same address with different code um but basically uh the check you do there is checking that the nonce is equal to this like Max dance value so yeah I guess and there's a couple

comments in the chats about like we do have to disable self-destruct and we sort of announced as part of Shanghai we're gonna do it so I yeah I don't know if people have thoughts about this uh 6046 approach or otherwise we could maybe discuss that in more detail on on the next call

Jared Wasinger: uh yeah I I uh it's been a bit since I looked at 6046 but I wrote in the chat um that I at least as I recall last time there were last I read There were some concerns around uh by not removing storage slots you're creating

uh avenues for malicious behavior and I think the example cited in the thread was uh uh genosis safe um but yeah I I'll have to look back into that to remind myself right then this is different than self-destruct now which clears all the storage

Tim Beiko: so it's like you're resetting exactly new code with the old data and yeah that could any other thoughts and I guess yeah and back to maybe

Jared's original question is it worthwhile to try and like do a extremely thorough analysis of all the contracts that would break on chain with like the 4758 proposal um given we already know there are you know several that would break and they're you know not trivial um it's not like two random contracts with less than one each it is you know there's a fair amount of contracts that that would stop working I'm not sure what the exact number is but it's um more than just a handful okay so I guess uh not a ton of demand

for that for the more thorough analysis um so maybe yeah if in the next like few client teams can look at 60 46 or potentially you know think about different ways to approach it we can continue the conversation um in the next call or two but yeah I think it's fighting what's the least worse what's the least worse option anything else anyone wanted to bring up

yes please yeah

so I think we've discussed it in the 444 breakout before the reason why we have this preset is because the price back and python implementation is very slow compared to the production height so yeah so we have for example we have a basic polynomial condiment both generation and verification test and he took like less than one minute to with

minimal presets but it takes like 28 seconds to run this test case so that was why I really want to keep the minimal presets and right

Tim Beiko: yeah so it's like a 30X difference

I don't know does anyone have thoughts about it

Mikhail Kalinin: is this 28 seconds just for one test case or there are like hundreds of cases

uh so it's only for this test case but uh it's the pie test

uh wrong so the test generator will be faster than this but still we uh currently you have the we use the minimal preset in our CI so you will take this 28 seconds in this year minutes right yeah 10 minutes

and

Tim Beiko: no I think it's seconds so it goes from less than one seconds to 30 seconds yeah

yes and that's only one test case one blob one yeah one block

Mikhail Kalinin: to be honest 30 seconds is running once

I mean like even if it's run on CI 30 seconds doesn't sound terrible I don't know if if we have like a hundred test cases which uh yeah and multiple n times 30 if we are jumping from minimal to main net preset yeah that's something to worry about but 30 seconds I don't know

yeah to be fair we don't have many test kits I think probably less than 10 test cases uh take the football proof generation and the

verification but I do expect that we will add more test cases after the iterations and

Tim Beiko: okay so I guess given the small number of tests should we just keep it this way or do we want to discuss this more maybe a sinker on the consensus specs on the CL call or I'm not quite sure yet what's the best approach

Dustin Brody: I mean I have to discuss it in general elsewhere um I guess we'll

know without trying to get into two I mean sort of expectancy of the execution like that just in general the fact that this this occurred how much I guess for one question would be uh for how much of this an artifact for particularly slow um kcg implementation in in the test Runners and how much is it really intrinsic to kzg that is to say how much is it fixable on a purely engineering side as opposed to a

specific thing

Dankrad Feist: this is purely due to a slow implementation like this is because Pi ECC is like 100 times slower than like efficient implementations

Dustin Brody: right I think this is an ugly enough problem to to shunt into because uh they both because it would immediately become both an engine and an uh execution layer problem or immediately you know during the testing um if it's if it's a question of this can be optimized in some way on the test Runner side I that seems like a better overall investment in for the ecosystem

Mikhail Kalinin: I think that we should start from setting the minimal to mainnet Value as discussed before and see if it becomes really annoying then reiterating that and think again

probably we'll see some opposition in the pr

Tim Beiko: okay yeah I think that makes sense we can just yeah we we can just make the pr for it and continue the discussion there oh and Dustin already has a PR amazing great anything else to cover before we wrap up okay well thanks everyone um and yeah talk to you all soon

thank you bye-bye

thank you Jesus

everything [Applause]

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