EIP-4844 Implementers Call #21

Transcript

foreign welcome to 4844 implementers call number 21 um yeah like I was saying there's a bunch of spec stuff on the agenda today um and then after that uh we can chat a bit about devnet5 um uh quizu I hope I'm getting their name right uh share the Little tool on the agenda that was pretty cool as well and then if we have time at the end I might want to talk about the ready Dash checklist a bit especially in the context of like all the conversations we saw in the Discord about some stuff uh around libraries and just you know other tests we want to do

um to make sure that we're actually moving this to prod with uh all of the bases covered I guess this starts though uh so on the last call we discussed uh merging get payloads V3 and get blobs bundle V1 um I don't know if we ever got a PR for this the execution apis is anyone aware of one okay so it seems like uh no does I guess I'm curious in terms of just the

client implementations oh okay nice okay okay we got it okay I think it looks like it's emerged the one about the post four zero two yeah yeah okay sweet I I missed that one thanks for sharing okay great so um so we've merge shows we have the pr anything else on this and I believe we had this as part of the devnet five spec if I'm not mistaken yeah okay

okay next up then uh so on the last uh acde uh last week we discussed EIP four six four seven five which introduces the optionals SSD type um and then we uh agreed to move the VIP forward and make a couple small changes to it um to make it work with 4844 uh a bit better and um you can list those in each magicians I don't think Ethan is here today I believe it's a holiday where he is um so he listed all of these changes um there's been a PR as well that was

open against uh 4844 uh this is actually quite an old PR um but that would that would need to be merged now I guess so assuming the changes that are listed there um in Ethan's its magician's comments get done to the EIP so the the sort of three bullet points he lists um and we go ahead with this PR 6495 on eip4844 is there anything else that we'd have to do to kind of align um a line 4844 with the optionals uh EIP

I think that's the only optional there's only one optional feel on the Block transactions I think that's it yeah yeah I mean there's other things we need to do like around the um uh hashtri route um domain string that's the other EIP but I think you listed on the agenda already so I assume we'll talk about that next yes yeah that was the next thing but I just want to make sure the optionals were good all right yeah yeah I like that you want to make the case for getting rid of optional in 444 yeah I mean we talked about it a bit and I think we talked about it specifically in uh Austria and it's just one of these things that you know we add a new

transaction type we've tried to like retain all of the previous behavior of the transactions but in this case this is such a specialized transaction I don't know if having the ability to to create transactions from The Blob transaction is important and I don't know if it's something that's making things harder um I wonder if it's even necessary just to be careful you said create transactions from The Blob sorry did you mean create contracts okay got that yeah yeah I mean I I don't think that it necessarily needs to have the create Behavior I mean one might say that they

create behavior that we have is not really ideal I mean I would probably make the argument that it would be nicer to have a transaction that is a create transaction not the two address was nil or none and therefore it is going to create a contract I'm curious uh if anyone else has opinions about that I think sorry go ahead Alexa

oh yeah just wanted to ask her about difficult to uh how it makes more difficult in work pressure I mean we're spending time trying to figure out how to um you know serialize and miracleize the optional value I I think that this is supported by libraries I'm not really sure the exact state of the SD libraries but it's you know a one of these things that we're trying to specify and B some just additional code paths that we have to support in the the actual 4844 transaction and it's just like another thing that we need to think of and

I for a lot of reasons that I'm like forgetting all of them right now I mean if we think about like what maybe the future for eof is we're going to have you know more specialized create transaction types we already have create op codes for creating transactions there's a lot of ways of doing these things it just seems like this is a good time to try and show a little bit of restraint and um you know not have everything be like fully compatible with previous transaction types I think the one argument I've heard against this uh is uh eton's idea of having a normalized transaction so if we end up having this normalized transaction type then we kind of need to Define optionals anyways and so

um and basically the idea of the normalized transaction is that you have one format that represents all of the different transactions that are possible in the protocol so if that's the route that we end up going down maybe it doesn't really make sense to drop it from 4844 but I think ultimately this is a very specialized transaction and like I marginally prefer dropping dropping optional I more or less agree with like client in the sense that when we will actually Implement normalized transactions which is normal transactions SSD format uh basically we can enable at that time

I don't think for it for four transaction as of now needs an optional too but could in the current transaction become that normalized one right if you just drop the uh one blob requirement and you can represent everything right I I think the problem is with the men pools like we're building this a very specialized transaction type around the idea of blobs and the idea that blobs are going to be you know more challenging to propagate and share with peers so I like on a theoretical Point like yes that's probably the case but I think based on what Peter has said in the past and what it seems like the discussions

have been that if we do want to have a normalized transaction we are going to create some other transaction type with a more clear discriminator that this is not a blob transaction I guess uh Roberto and Mophie you know from base and optimism's perspective like are you fine with that you're you're sort of the the users of this right like so I don't have a strong opinion I mean yeah I I like simplicity so kind of narrowing it down is

preferential in that respect but um I I it's hard to predict you know all the use cases of this so uh there's a natural reluctance to start constraining things um but yeah not somewhat ambivalent about this I guess right yeah I mean fortunately you do have the ability to still create contracts via the op codes really the only functionality you miss out on as if for some reason you have some piece of your designer architecture that relies on creating contracts from um EOS either you own the private key of and I'm guessing it's just probably not the case for anyone yeah it seems like we'd go back and

forth on this a bit about you know whether it would be more specialized versus General I just I I just like a decision to be made I guess do you think there's anyone that that's not in this call that might have a strong opinion about this time so I think Matt and Eaton are the two people with the strongest opinions as far as I could uh yeah probably it would be good to get Eton to say what his thoughts are okay so I guess

yeah I guess maybe let's chat about this I think on the on on the Discord and see yeah see what what he thinks we're going to have to do another dead man so I think we have a little bit of time to figure this out yeah yeah yeah I just want to make sure that like yeah we we don't sort of circle around this over and over uh again um so I I I feel like if we can get like his thoughts in the next day or two then you know by like the ACC call this week we can just

oh I've agreed and you know potentially just remove the optional from um remove the optional from uh 4844 and I guess if we did that then it's not clear that we even need the EIP is part of Cancun generally um because it's the only the only use of SSD I believe but anyways we can have that discussion on unlock core devs as well yeah I mean I think if Eton agrees that if we do do a normalized transaction type it would be a distinct one from the existing blob one then perhaps we're all aligned that we

should get rid of it and I think it's not clear to me yeah it's not clear to me that there's consensus within the client teams that like a generalized transaction is a good idea uh transaction type is a good idea um yeah yeah yeah no definitely not consensus around that but if we were to pursue it and it would be a different transaction anyway then we may as well constrain The Blob transaction now I guess right yeah yeah okay so um let's assume that you know unless Ethan has like a strong objection uh we move forward with uh removing the optional uh field from the 4844 type

transaction and obviously we're not going to change that on devnet 5 but as we get that uh as we get that ironed out um that would be that would be what we would do on them at six okay and I guess uh relatedly like the the next thing I had on on the agenda which we covered on the the HTC sde uh last week is um the eip6493 so the the signature scheme for SSD um and there's uh comments in the chat about that already

yeah I'm curious what are people's opinions about that and how we should move forward with it uh I was wondering why add four cash to the transaction domain I think Eton left a comment that that's how it's done in a defensive layer I'm not familiar with that though but um we asked the same question in the chat I mean okay um so he was asking what the motivation that was and I don't have the answer hopefully someone here does yeah I don't know exactly what the forecast looks like for the CL but in this case

it looks like the forecast only protects it you know sorry the forecast in this proposal that Eton has whatever the zip is uh it only protects it against a world where a competing chain has the same Genesis and introduces the exact same transaction type in a fork later than canonical mainnet other than that I think it's kind of a moot point what I sort of agree uh in the sense that uh basically this transaction is not ready for dependent so it's not that you know

there needs to be an expiry of the transaction when a new Fork will come on uh yeah okay okay [Music] I guess that's why it's on the CL right yep sorry I didn't follow I'm trying to get in the notes what was what was the reason it's in the seal so in the CL basically when a new Fork comes on uh some messages become old and basically new messages are required so sort of you sort of expire them and this is the prime this is the mechanism to expire those messages

yeah I don't think that we have that problem on the El and if that was something that people wanted then you know it's something that would need to be thought about a little bit more because we go from a world where your transactions don't expire on Fork boundaries to a world where they do I'm sure there's some unintended uh side effects there also uh enshrining the crc32 checksum into the con into the protocol is probably not something that we want to do because right now the proposal just says use the 20 the EIP 2124 for cash specification which was designed for Dev

P2P and then enshrine that into the protocol so I don't think that we really want to add more cryptographic functions into the so we might consider it a different option otherwise maybe just set you know to be compatible with the co set for cash to some static value and then one day in the future maybe we change it or you utilize something different but I don't really see the point of it for the transactions right now yeah it's similar to how BLX BLS BLS change execution execution changes messages are sort of

formatted with just a fixed uh fixed forecast fixed uh fixed folk so uh I mean nothing really changes so those messages can live forever so yeah as of now it doesn't make any sense to bring domain work domain into uh into the earland to sort of expire the messages okay I link to the youth magician's question that you've done raised maybe we could continue the discussion there I mean it sounds like we should get rid of it though yeah sounds good so aside from uh basically the the

the fork version the the Genesis like I guess yeah aside from continuing this conversation on each magician is there anything else we want to figure out with the signature scheme on this call I mean I guess like maybe just more of a broader question but um does it make sense to really bring the same signature scheme that validators use into the El because right now we kind of have these two worlds yell you sign your messages with ecsa over the um you know signature hash and in the CL you have a very specific mechanism that

has like the domain and the forecast and all these things does it make more sense to try and Define some sort of signature scheme that's more aligned with the El because I can imagine a world where we don't really ever add any more transaction types and we have like three transaction types that are implemented in this very specific way and then we have this one special for for a transaction type that looks more like a consensus signature and that just doesn't really seem like uh something that's really ideal from the perspective of like execution layered developers to have like a totally different format they have to learn and for all the hardware providers to support this like stranger signature scheme

isn't the idea to like swap over all at once once you're ready to see everything no we can't ever swap over the signature hashes because we kind of have the assumption that we're not going to force all the hardware wallets to upgrade and all the users who have Hardware wallets to upgrade their Hardware wallets people do update those though so it's not impossible yeah but we've like debated this a fair bit in the past and I don't think that people are going to be supportive of a change that makes it impossible for

someone who has a hardware wall from 2017 to sign a message without updating their Hardware wallet yeah and I think in the past we've even had more extremes version of this argument which is like you've already signed the transaction and you threw your Hardware right away right right you're just waiting to broadcast the sign transaction I think like maybe it's possible to have some pre-compile or some specialized operation that takes an old signature hash and instantiate a transaction based on that and then switch all of the transaction signature hashes over to some as a z thing but I think like the most likely situation is that we just never are able to fully move away from the ROP signature hash oh yeah I guess I don't know I mean what

would uh and I think one of the problems that I guess this proposal is solving is the the chance for collisions across chains I guess there's probably a simpler way of achieving that objective is that kind of what you're thinking or I don't know I think that you already um actually I don't know I I kind of forget the exact reason um Eton was explaining this that it didn't quite understand 100 um but I think there are simpler things that we could do so in you know a silly example I thought of earlier was imagine that you just compute the hash tree root of the the um sign that and then to get a

transaction uh let's see you can sorry you compute the half Street root and then you change the upper bytes to the transaction type ID so now you have like domain your um signing hash to that transaction that's kind of what the domain is doing like there's a lot of this Machinery that's happening if we drop for cash really the only thing that all this Machinery is doing now besides like making it look like a CL signature is that it's adding the transaction type information to the signature and so like there are simpler ways of doing that yeah so I think the the case he was explaining was that there might be another change that introduces an rlp transaction of the same type um and introduces potential for

collisions that way which is obviously quite remote but yeah I mean if we're introducing ROP Trends actually the same type then we've made a mistake yeah I mean we I think he's saying another evm compatible chain or something might do that right beyond our control for sure and yeah I mean there is this this issue I guess which I guess is that's what the Genesis route is avoiding yeah it's not here to me what the

Next Step is here or I guess how yeah how how much like how valuable it is to uh keep yeah I guess yeah it probably makes sense to keep discussing it are these magicians but um I am a bit weary of like yeah sorry go ahead I mean I guess I I hate I almost hate to say it but I mean maybe we adopted SSC to premature earlier I mean I hate to even back back up further but yeah I mean if we're kind of half

adopting it does that even make sense should we just stuck with our LP until we kind of figure out this broader story I don't I don't know I'm starting to have concerns but right so we refactor all of 444 to use rlp all right just ignore that please Andrew go ahead uh that um well we and now we include the chain ID into the transaction so maybe we can if we want to achieve this to solve this more limited problem of avoiding glass between

um like the same transaction ID but different format and different chains maybe we can serialized like like prefix uh transaction civilization with the chain ID instead of like genesis hash or or Cache doesn't the transaction serialization already have the chain ID yeah but I think uh Ethan's point was because like you can you can have uh SSD serialization and rlp sterilization and what not civilization and even they all use uh they all include chain ID but then

because they are in different format there is no guarantee that the same binary civilization would be different or like they they potentially like a single binary representation can still be reinterpreted on different chains with different changes IDs that use like different formats but if we kind of include so we we have this uh transaction type prefix uh and then maybe we somehow add chain ID to the prefix in some similar format like big engine zero script or whatnot

then we can exclude chain ID from the main civilization and solve the problem of like clash between different chains but then wouldn't we have to ensure that it's serialized at the exact same point as the rlp encoding is that or is that what you're proposing so uh yeah how the how type transactions work we we prefix so we first for the existing say 15 59 transactions we serialized them into ROP and then we pre-prefix the transaction type byte to the rlp

serialization right so I'm thinking what if we've like so we have this uh transaction type prefix and then we have another prefix with the chain ID outside of the SSD serialization and then we have the like the following will be SSD serialization and or our rlp serialization and whatnot and we can promote that as a among like evm compatible blockchains as a way to avoid clashes and and we also can make sure that the special prefix for chain ID doesn't criticize with any valid ROP civilization and things like that

I'm just thinking of a way to solve the more limited problem of avoiding like clashes between different chains how it is different from a case when chain ID is the first field in SSC I I when you have the first field we will be the first if it's fixed size

okay so I guess if it does not even and for rlp to be like uh you know okay maybe maybe a but then can we reinterpret the same thing AE in in rlp as ROP you'd have to put the endess of it my My Views we we can because uh right now I'm in the signature is uh composed after doing a hash of the serialized transaction so basically if there is an

rlp that is same as the current transaction and the signature matches that means that we have a solution to finding a pre-image problem I mean if it feels like that to me I mean the hardness of the problem I mean it's very hard and sorry we're at uh hash of what so to compute the signature we we hatch the serialized transaction which is prefixed with the transaction type so I mean to find uh to find a rlp

transaction that matches with this as well as the signature also works out I mean the problem I'm it feels to me that is the same problem as finding a pre-mage of a hash function well it's I think it's it's a weaker problem because uh like theoretically you know how s is z works and how ROP work so like you can potentially uh the the potential attack is that you can find identical uh SSD and IOP civilizations

uh well it is mostly theoretical I guess uh what would the signatures be valid I mean both in rlp and SSE domain I thought etan actually had a demonstration of it my recollection could be wrong but anyway is yeah unfortunately he's out today but but yeah it's unfortunately it's not as difficult to do as finding a hash Collision for example but I can try and look that up and add it to the notes I mean I think the X type should take

care of that but yeah I want to see what return has come up with okay I'm not yeah I'm not quite sure where this puts us I think this is an example of a

different thing that we're talking about here though this is an example of getting two hash tree roots being the same value just due to the fact that the first example doesn't have a power of two items and we're talking about um rlp versus SOC so maybe there was a different example but this was the one that I was remembering yeah I might have to have them confused as well I don't know I I don't mean to like throw a wrench in in things but

I feel like we're putting one foot in the door of soz and we're not going the full way in some cases and so I'm just trying to think like what is the best way to ship 4844 where we ship it quickly we do the things we want to do and we don't do things that need to change in the future and I think transaction signing is I don't know maybe one of these things if it seems like this is a big enough change that we're always gonna have you know some problem like this though so either we don't do it or like and wait how to do it all at once

or we do kind of possibly make some compromises today so that you know it lays the groundwork for the future and I think realistically though when we say we waited we do it all at once this is like we delay like doing it all at once will not be the top of our priority list for like the next few years at least right um so it's like is there what's the cost of waiting you know say three years for this to happen all at once or having something that's kind of an in between

in in the meantime and potentially also having to deal with it again in like three years yeah but I guess it seems the main goal that Eton was trying to solve was to try to get us to 6404 where we eventually have a a fully mercilized um transaction route in the block header and you can access pieces of transactions um so maybe we should strive kind of the minimum change that achieves that this is kind of like in a weird space though that's separate from that because the this is more like signature hashes and it's not really seen by the protocol other than whenever you verify the

sender of the transaction so we can kind of do whatever we want here I guess you know maybe we're spending too much time thinking about what the right thing to do is but ultimately we could some we could just simply rlp serialize the 4844 elements and K check hash them with the type prefix and and sign that message and and that would be the like most parallel with what we already have not affect our ability to do any 6404 related things in the future whoa how is that much different than what's currently implemented I think it is pretty much what's

currently implemented in terms of Sig hashes but we're not right now talking about changing the way that we do the Sig hashes to be much more similar to the CL which we're not really trying to be CL compatible as far as I'm aware and it doesn't really affect our ability to do 6404 so we're kind of like trying to figure out a new way of doing execution layer transactions transaction signatures which is fine um but I guess the question is should we just do it exactly like the CL does it just for compatibility for that reason or should we think of a better way that fits better within the design scope of the EO right so I guess I was asking if we

don't want to pursue uh you know if we decide to keep it simple what we have implemented now in devnet5 or hashes you know does a hash of the serialized form with the type bit using ketchak where does that break I guess does that is that not an adequate solution I think it's an adequate solution I think the only thing that's a little bit weird is is that it's not the it's not really the way that we hash SSE values so it's kind of unique in that sense and so if we're going to make this an SSD object and then we you know calculate the rlp values of these things this sort of

breaks the um assumptions that you might have around an SSD object I don't think it really breaks anywhere because you don't creep proofs against a signature hash uh it's really something that's not seen by users in any meaningful way so I think it's okay in this case but the like most correct thing to do would be to calculate the hash tree root of the SSD object in some way and then um you know compute a signature over that in some mechanism and I think that's what this EIP is like really going for the problem is that it just directly takes what the CL does and applies it to the El transactions and there are things that we don't care about like the forecast as we're finding out and was it uh is there indifference on

how to cite whether to create blob transactions uh with um SSD or with the ROP I didn't catch the first part so for you know for L2 is there a preference of uh ROP versus SS Z for blob transactions I think the only thing I've seen raise in the chat is what what uh mophie's specif mentioned which is the one nice property gives you is you can get at the blob version hash without having to know the entire transaction schema uh but that's a consensus layer Advantage not any yell advantage

yeah so if we're not for example taking advantage of the um you know full mercolization seems like the SSC isn't buying us a whole lot many you know we're yeah we're almost through the entire call another proposal a simpler proposal discuss that I think right now I'm marginally in

favor of I guess what we have like I would have to look to double check but I think that if we're Computing the ROP some ROP list of all of the elements prepending the transaction type and then k-check hashing that to create the signature that's probably the best and simplest thing that we have at the moment I guess yeah and what would how big is it to like write that spec basically or like I guess the pr to 444

do we actually change the signature hash at some point to something else or was it something we were just talking about doing originally the signature hash was hash tree root and then it was changed to just catch that got the serialization to sort of be more compatible with the way the Yale's already doing it but I don't think it was ever rlp based Mophie I don't remember that reading from the chat Mophie says it was rlp based but right now it's on devnet it's not rlp based you guys are competing the

hashtri root uh no it's Computing the um ketchek hash of the SSD serialization not the hash true root I see yeah I I would be against doing the K check of SSD serialization just because this is something that is not done anywhere else and it just seems weird like that is one of these examples where I feel like we're like stepping partially into snc but not like the full correct way so I would rather do kind of what Eton is proposing with a full SSD signing mechanism uh with the hash free root or falling back to doing what kind of already exists which is the ROP list

um the next day oh Andrew okay oh yeah I just wanted to say that yeah I agree with the Lite client so we either should revert back to ROP or go on the uh the whole way and like to think about the SSD like a proper path to SSD everything and investor more time just making sure that things like like 6493 is actually a good way forward but this kind of the current approach

which is half man and half measure doesn't seem to be a good approach yeah it would be probably good and uh helpful if uh final uh scope of SSC transition uh uh existed and we could at least understand uh which part we can deliver with without a lot of remake after that uh what is the final answer the game like that

uh Justin you also have your hand up yeah just real quick I kind of wanted to I think I agree with everybody um but I do want to point out that the intent behind um the SSC adoption erps as they're written right now is for incremental adoption um so if if we are I think it would help us to say that we want to abandon that approach and pursue a big bang knowing and accepting that the trade-off is significant delay in adopting SSD so I think I think that's one thing to keep in mind it's that these this these half measures are by Design yeah but what what what's the and what

what uh what are the goals of adoption SSG what are we trying to achieve it's like like like bringing and this is the library into in in in the into El is not worth a goal so you know what what are we trying to achieve yeah and and honestly I agree with that um I'm just kind of bringing up the other the other end of the argument from from my understanding which is limited is that what we gain is a generalized upgrade and Adoption of what we broadly think is a superior serialization format that's all I don't have a strong argument in that I agree with that as the goal but I guess what I'm what it seems we're

starting to realize is are these half measures really even getting us there um right I mean hey look again we're talking about mostly right now it's the signature signing scheme which I don't think really matters all that much at the end of the day um when we start talking about 6404 and how are we gonna what like what is the actual transaction hash what is the value that's going into the transaction uh commitment tree whether it's Merkel Patricia or SSE that's where uh that comes more into play I think um but uh specifically something that SSD helps with is being able to um in a smart contract in some sort of fraud proof be able to

um create proof to specific pieces of the transaction without having to put the entire transaction object on chain that is I think like the major thing that I heard from l2s that they wanted to be able to prove a certain piece of the transaction and right now it's not possible because you have to compute to like to get the commitment against the header in some way you have to compute the k-check value yourself which means you have to have the entire pre-image of the transaction with SSD you can just use the hashtree root prove like one specific Leaf of that transaction so basically the transaction signature

can still be computed like Giga cough uh SSG serialize but the final transaction identifier could be the says SSD history route of the sign transaction type yeah and that's what 6404 is all about it's about getting that um fully mercilized SSC transaction written header to allow for those kinds of proofs so I I I think that is definitely a valid valuable goal um especially for L2 Developers I guess I'm not

sure which way best gets us incrementally towards that or if if this is helping at all I guess I mean maybe we need to see some use cases I think that would sort of bring and conclusive and discussion what we need oh I think for that for that particular case there's use cases and in fraud proofs for example being able to single up a specific part of the transaction so I think there's known value for having a um you know SSE with them with a miracleized root available for for um proving over parts of it

but how do we I guess the path there right these decisions we're making now hindering or helping our path there I think that's that's what I'm a little fuzzy about I would like if anyone has a strong argument for adopting this as a z Bay signature scheme to you know try and flush that out because if there's not a strong argument and we're just doing it just to do it then to me that doesn't make a lot of sense and it might be better to stick with the formats that we have uh it was sweet it can be a good tool

for health tools to look some partial calculations parts of the transaction of the should be transcript but the signature hash isn't available and the consensus make any consistency mechanism like it's totally opaque uh so these parts uh partially calculate the truth is not used in contract like that it can be it is needed just in communication with answers there by Atlas

great I'm not sure if I'm following I'm talking about the message has that the user ends up signing to create the signature and I don't think that that value is propagated anywhere it's reconstructed every time by the consensus nodes or the execution layer nodes to validate the sender of the message but it's not something that's communicated to the CL or l2s I guess okay so we just have five minutes left

um does it make sense to pause this conversation here obviously keep chatting on The Magicians and Discord um and aim to like a line on the overall SSD approach for devnet6 uh like obviously we shouldn't you know change if not five overnight with this but it does seem like a significant enough thing that if we make this our focus in the next couple weeks um we could hopefully get to a spec we're happy with and uh yeah have the the next Dev not to implement that does that make sense to people yeah I

think this is one of this as well as I guess the um um blob transaction rebroadcasting on reorgs are sort of the two main open issues that I'm aware of anyway um but yeah I guess we should probably move on given a limited amount of time left yeah right not on the Discord for now I'll try to lay out a few points and options that were discussed awesome yeah that would be that would be amazing thank you yeah okay I think those were all the spec discussions uh that we had so there was the pr I guess Ethan had a small PR to uh

4844 uh that just changes the the limits on yeah it's just about I think it's just he's just fixing up yeah yeah exactly yeah so that yeah okay okay I guess uh that in terms of devnets uh it might be worth yeah just getting a quick update on devnet 5 where different teams are at and um and yeah obviously for devnet6 we can uh we can discuss that once we have the SSD figured out yeah yeah one last spec thing uh I mean the same argument that we sort of made against

doing the cage hack of some s s z serialized value for the signature hash is the same argument for doing it for the transaction hash that goes into the Merkel Patricia try right now so like I am again like very against doing this like half in half out where we kind of introduced as a z but we don't use the um you know correct way of hashing the SSD object which is the hashtree root and we're just plopping that into the transaction try so I would rather again go the full length or only go um you know not do the SOC yes

um I guess yeah okay quickly any very quick updates on devnet 5. nothing for instance Thursday I would say um and then I guess okay so as we wrap up uh we're just highlighting there's this tool that was uh shared in the uh in the agenda so if people want to check that out I don't think the author is on the call and then last thing um so Roberto you just mentioned you know SSD the reorg stuff are like the two biggest open issues obviously Peter's had a bunch of comments about the state of uh the crypto libraries uh

on the Discord as well um I'm wondering do people think there would be value in trying to have a more thorough like checklist to track all these issues um oh sorry I just saw your message uh okay we can get back to that right after um but yeah the people think there's value and sort of revamping the Readiness checklist we we had this like much earlier on um last time I updated it was right before Austria or do we feel like you know there's sufficiently little issues left to deal with that like you know obviously the actual edge cases gets tracked in the tests and then there's you know a

handful of other implementation issues but it's not worth maintaining your whole other whole other tracker for that I don't think it trans a specific tracker for 4844 would hurt um okay I mean I think last time we were here it was you know Danny had to remind us that this was an open issue around the blobs for example um which is okay become top of Mind perhaps we've been tracking that we've been more on top of it I guess um it doesn't need to be super detailed but yeah just sort of a list of remaining things to resolve to make sure we're making progress with I think we know okay I'll I'll take a sub at uh updating the the one that's there and kind of

yeah bring it up to the switch um right but like the crypto Library issue um I've been following discussion around that I believe Kev is working on that at least in the go library but I don't know like someone on the ckz side is without those concerns okay yeah okay so perfect I'll update it I'll share it uh once I have uh something and obviously anyone's free to open a PR against it the the uh to tweak it as well but I'm happy to own the bigger updates that since January okay and uh yeah I guess uh we hopefully that's your name right and do you want to take a minute to talk about your tool

oh yeah sure so uh via experiment the VIP forever.net and so uh especially from Smart contract side to see how to use it and also test it in a smart contract um so one thing I'm I just uh I found maybe missing is like how to support this new update code in the uh in a developer friendly I mean especially from Smart contract developer from your way um so I searched the uh basically the implementations course and I'm I'm not sure there's any other two that helped to support this new OPI code and also definitely will takes time to for the cities to to support that and if something someone have more information

of what their plan to support this opening Optical and we have to learn um so uh let's just start a quick uh a small like salinity library that is able to deploy a customized assembly code to a Smart contract and be able to and so that we are able to retrieve the corresponding data hashes um and then using the data hashes and storing the for example uh like for example in the lower contract to experiment all these ideas of eip544 um so this is basically what we have

have done and all the color is in the in the Ripple and we have uh done the experiment test test test on the uh that following the gym is notes and happy to learn if there's any uh feedback or perhaps there's also other tools to solve the problem yeah uh there's a question in the chat can this become bind oh sorry can be date code core combined with Point evaluation the current course that uh I'm not sure that the date code call

is I think is that the data hash will be called oh I'm not quite sure uh combined with no there are separate things so uh data hash or because zero X for the 49 um that is uh added in the the list of the uh ethereum ebm LP code to retrieve a uh the data hash corresponding to a block index um and the point evaluation quick compile is a separate uh pre-compile that is added to support the uh polynomial evaluation of uh corresponding uh data block given the a

list of data like uh kcg version hash um energy commitment and also proofs uh so basically uh in terms of the for example rural especially in optimistic contact um so I I believe that it has is used to back to batch upload the data and while if someone founded the transaction but the execution result in on layer 2 is wrong then they will call Point evaluation pre-compile to upload a Blog and then say hey there's some issue of executing this blog on layer two and one to challenge so this is basic to two different steps used in grow up setup

thank you uh it was interesting how this pieces of course can be used to incredible for actually it was not clear cool anything else oh anything else as we wrap up we have a couple of small um updates from testing vectors I don't want to share is that fine or yeah yeah yeah yeah yeah go ahead okay yeah so I shared two links on the mini chat uh the first one is the execution factors so there was a new

release guys uh specifically helps out helped us out to to attack yesterday basically it contains the Cancun um vectors and you can use this on the uh forever for uh any any client any execution client that supports 48.4 for all the execution clients who want to run this if you need some help to uh run a specific Docker image uh of your execution client please let me know I can help you out to run any of these vectors yeah that's all cool thank you

okay well thanks everyone um yeah talk to you soon thanks Tim thank you guys yeah hey guys