EIP-4844 Breakout Room #1

Transcript

okay uh so we are live uh for the four eight four four breakout room um thanks everyone for joining i guess uh my main goal today is just to have everyone here on the same page around what the status of the eip is like what are the different uh tracks that are that are in progress um the two big things are obviously like the implementations across uh the execution and consensus layer clients as well as the work on the ceremony and then i think um what would also be useful uh to get out of this call is like figuring out what are the big open issues that we still need to fix

for this eip as well as like the the next steps uh in terms of development and and uh whether it is appetite by folks here to organize something in person at one of the next conferences um i guess to start uh i know mophie and um um my god i'm blanking on your name um michael sorry i have been working on implementations across death and uh prism you guys maybe want to take a couple minutes to share what you've been working on and and where things are at there

oh are you guys here otherwise uh we can we can flip it uh i see that trent and carl yeah oh michael you've come on camera come off you okay yeah i'm here um i think murphy had the demo um has some audio issues um okay maybe we can just swap that and start with the ceremony and uh mophie can fix his audio in the meantime um i see

trent and carl are here yeah do either of you want to give a quick update on on on the ceremony yeah sure uh can you guys see me all right yes you can fantastic um yeah so i think uh since lost most of you uh heard from me i've been commenting for what the ceremony should look like uh which sort of describes what we need from a cryptographic standpoint i mean that's relatively simple um it was pretty cool to see that uh there was a glass weekend

before um uh uh marius and friend uh hacked on that built after an implementation of the ceremony um so we already have some some piles lying around if people need some somewhat secure stuff for testing that's that's very exciting to see um in terms of the uh yeah it's surely not not translating um in terms of like what are the the next steps for the ceremony um we uh we we need to get okay uh we need to get it as if the cryptography implemented in a

sort of more auditable uh waterfall method uh we will have uh these two implementations of that uh one in rust and one in uh javascript but both of them are sort of just light wrappers of a bls library the actual cryptography happening is relatively simple and the way i've written the specifications on such that it's as easy as possible for others to implement themselves so anyone can participate if they want to be with their own their own implementation that is um so sort of uh moving on from that uh we obviously want as much time as possible to run the ceremony

but the longer we can have it running more more people can get involved and the better for overall narratives and security that is so uh my current thinking is to leave the uh try get the ceremony up and running as quickly as possible and then leave it running um until the absolute last minute so much like with uh gtd or something like that um where we throw that out uh just just before we we make a decision there i'd like to do the same with the final powers and use an intermediate output for testing before that point uh which function is the same for clients uh you can't make optimizations relative to the powers so there's

it's just a config file you should import um so i think that's that's sort of the best approach there so timelines in terms of when we uh stop running the ceremony are largely determined by when we need 484 um yeah so i think that's that's pretty much the highlights of what we have got it thanks and just i guess to clarify from what you said it doesn't seem like there's any like fundamental like research question or anything obviously it all needs to be implemented and audited um but there's no kind of

major blocker on that side is that is that right yeah absolutely um no major blockers there it's it's mostly just standardizing and agreeing on things at this point but uh if like if if you need if you need outputs for testing whatever we already have those for you give those two we have those sort of test ceremonies so that's nice that's pretty good thanks thanks for the update um anyone have questions or comments on that okay um

mophie can you hear us now oh we can't hear you [Laughter] um you're not coming through still nothing um i have one question about the ceremony just in terms of like where discussions are happening right now and if people wanted to follow along to the progress uh where where's the best place to go for that right now um the there's a discord from the uh youth r d discord there's a channel

for it that's probably the best point to jump on for discussion otherwise have the flag specifically related to the photography comments on the issues on the repo probably for this place and hopefully soon we'll be expanding out to a second retail for sort of standardizing the larger apis and how we do anti-dust protection cool i know aztec was saying also that they wanted to contribute um wondering of um how much to what extent have they been uh kind of looped in or have they been helpful um at the moment i'm not involved

very cool all right am i audible now you are awesome sweet all right so updates on the eip4844 so um i've been working with michael and david from coinbase to basically come up with like uh a simple um mvp that i was hoping to demo to y'all today um we have like a devnet that basically implements most of the spec there's still a few things missing like um syncing from

genesis and um the fee market updates to the execution layer uh we haven't implemented that yet but hopefully this would be enough to like demonstrate what we have and show that eip4844 is feasible and working um anyone wants to follow along i'll be posting on the chat um a link to our current setup for eip48 all right so let me share my screen to well before i start presenting the demo does anyone like have any questions about like uh where are we at okay i'll take that as a no

all right let me share my screen cool can everyone see this no difficulties all day today yeah all right the system's preferences thing and osx oh right so all right so i have to restart the

browser just for a bit and i'll be right back anyone have a joke in the meantime carl entertain us do you take these better jokes than uh the the youth frog livestream waiting for the hackathon announcements that was pretty painful okay we got it wilfy we see your screen all right all right on to the demo

so what i have here is the repo running on uh on a node in the cloud that um implements eip-4844 on prism and gaf those are the two clients we're using uh to demonstrate the demo um so the setup here kind of like looks like it's there's a beacon node and then there's like another beacon node that sort of like follows that beacon node all it's doing is gossiping blocks and side cars just to like illustrate that you know the gossiping aspect works and we have like an execution client that the beacon nodes uh connect to to um i guess like propose

um blocks and update for choice so there's also a validated node running um that's making these proposals um and as you see when you create like a blob transaction that gets included into a block and um you can download the site car associated with that transaction um even remotely all right so first let me run the uh devnet make sure everything is down and clear give it a sec

all right so this sounds a little bit peculiar because we're starting um pre-merge block so i'm gonna give it like a couple seconds for um the merge to happen and then we can start sending um um lobster's actions that would get included into an eib4844 block um so we have our node set up and um first order business let's check the logs usually the merge transition happens to

like slot 9 so we can like just monitor for that all right there we go so at this point um eip 4844 is in effect and we can start sending blob transactions um so i have like a little script that sort of like does that um this upload script it would basically take his input like a file in our case it's like a jpeg of like the ethereum logo and it will craft like a blob transaction and send that to geth and

a couple seconds later um the bq node would like craft a block with your gaf that includes that transaction and then we'll be able to like observe that transaction in the network so let me start with that okay so now the transaction's been submitted um and in a couple while we should be able to observe our robs that we just uploaded all right so i think there's enough time

so to observe those blocks i have like another script that does that we'll go over those the what the script does exactly in a minute and i can show you some code but right now i'm just gonna run it um this script download all it does is basically it takes um a peer-to-peer multi address as input which is the beacon node um the number of um slots well specifically the slot number that you want to download start downloading blobs from and the number of slots after that number to download the blobs so basically this is like mocking the what is it the blob sidecar by range

um rpc if you've read the consensus specs and for here to get the faulty address i can just easily hook this thing let me just look at the box without one sec so we're just going to set the count to

100 um we've only download we've only uploaded one blob via that blob transaction and this is just only going to return one blob even though the account sets it 100. just this is just so that i don't miss any slots um as you know the the validated nodes are proposed in the box so we start from slot five and let's write this to a file let's call it blob data okay so now we have the blob file and um remember that we just uploaded the ether.png image earlier we can verify that

the blob file that we just downloaded matches the image that we uploaded so that's pretty much how you would submit a blob transaction and retrieve the sidecar that got included into the beacon block or at least that side card into a beacon block um so next let me just quickly go over like the script that uh we're using for the upload um oh i don't have that installed in this computer let me try here this is pretty much a simple like go

script that uh uses like the guest libraries to like you know the same way you create a transaction on each one this is just using like the guest library to do that for convenience so here we are we uh kind of like take the file we read the file this is the blob data that we are uploading and we end up like including that we encode it as a blob so it has to like have like a certain format otherwise geth would like reject it and then we when we craft a transaction we sort of like create like a signed blob transaction add the wrap data containing the blobs

this is like the network variant of the blob transaction in the spec and then we uh we send the transaction as usual and in the end it just prints out transaction submitted so this is all pretty familiar as like before the only difference is now we're adding blobs oh and the kcg commitments right that gets included here as well and this also works even if you use like the public um json rpc api um where you can just set like the blob data and in that case you don't need to compute any kg commitments yes would do that for you and just add it to the transaction pool um

the download script this script is kind of like a bit peculiar because there isn't like an easy way to like observe um blob sidecars and in the beacon chain so what this does is it acts as like a as like a beacon node it connects to another beacon node and the peer-to-peer network it's just using liquid appear to connect to it and it interacts with the beacon node via the vrbcs that are specked out to download the blobside cars so kind of like what's going on here we create like a blobside cars range request and we send that request to a beacon

node and then and hopefully it will just send back all the side cards that we just got and all this does is like print it out to standard output so that's almost all of it the last thing i kind of like want to highlight is the pre-compile right um i have like another um handy test to kind of like demo that out of elevation so with this one um all it's doing is um sending a transaction that um uses the that basically uses the pre-com

the new opcode for the point evaluation pre-compile and uh just for this test i have like a it can pre-compile inputs data that's invalid and another one that's valid just to show that the pre-compile works um and yes can like figure out which is valid and which is invalid so let me go over those scripts just a little bit first um this is the one so basically here we're um we're connecting to the execution node we uh deploy a contract that contains um code that hits the pre-compile and um we deploy it and then we basically make sure that and in the

contracts constructor it will use either the valid point evaluation input or the invalid one and then geth will like you know as as it touches the opcode geth will basically either revert or not revert if the input checks out and let me quickly go over the contract as well so here um this is basically just assembly um because we don't facility doesn't support eip-4844 obviously um it's basically using the new opcode that we introduced and just it reverts if um you know death um returns zero per the spec because if

it's zero then um the um the input is valid and if it's not then it's invalid so when i run this right here so that's expected at first we want to

like try sending bad input to see if get um reverts or returns a non-zero error and then if that happens then the contract reverts if we send the valid input then it returns zero and the contract uh gets deployed um successfully and that's pretty much it so yeah to recap we basically just highlighted that the point evaluation pre-compile works um were you able to craft a blob transaction containing blobs um have that included in the beacon block and download those blob transactions uh from the

network via peer-to-peer so uh yeah that's pretty much it and i also want to shout out to uh michael and david again for um really helping with uh all the uh helping like build this together um they're like pretty keen like working on like the solidity part for the pre-compile evaluation um making changes to geth and prism to like make sure that blobs works and uh yeah so really appreciate it yeah this is very cool thank you for sharing this um and yeah i don't know if you managed to open the chat but it's a shared

sentiment um anyone have questions thoughts about the demo uh this is very awesome thank you for sharing it i had a question i believe i've tried implemented this in prison i'm not sure if it's working or anyone's using it um does it validate the kcg commitment right now i'm sorry who's talking uh this is terence from prison sorry oh hey charles oh you're still sharing your screen mophie by the way oh yeah sorry about that yeah so it it does validate the uh kcg commitments um in prison yeah it does validate it

okay awesome thank you yep so one thing i want to like point out um the kcg the kcgs themselves at least when you like get the kcgs and you like try to computer proof um and use the point evaluation pre-compile with the commitment and the proof it doesn't quite work yet but the commitments work fine um the current implementation um with prism yeah got it i guess i have a follow-up question like what is the next step for this in terms of client implementation yeah the next steps is to pretty much um complete the implementation um a couple

of things that are missing like i mentioned the the proofs are not quite working um when you you know generate them um that needs to be fixed it might be an issue with the kcg format i'm not sure another thing that needs to be um implemented is syncing from like the initial sync in the prism client um i haven't added that yet so for the for the demo that i just highlighted the way it syncs is basically whenever the bknowledge gets a block and a sidecar it would like immediately just gossip that to broadcast that to the network and the the other peers can like download the blobs um directly so if you're if your node

um starts much later it would have to like sync from genesis and the stat sync it wouldn't work because it hasn't implemented yet for blobs got it that makes sense thank you yeah any other questions i think someone was trying to say something was that yeah i i was gonna say i have some if if no one else has but just wanna make sure um

cool uh yeah i i guess um from my perspective it seems like the two big things that we still need to figure out are like like sync like you mentioned and um the other thing that's worth noting is the fee market like uh i believe the demo just uses like the naive constant uh price approach um i'm curious like hey like if everyone here like agrees that those those still need to be fleshed out and be like is there are other big things that we need to get done um to have this this in a spot where it's uh the spec is a bit more complete

and yeah just just i think like we should have like um at least for the spec um with regards to like syncing it there should be a little bit more detail on like how that would work because and not just syncing but also like even just for the regular gossip because one thing that i kind of noticed that is that when you like um when you build up you can block and you know broadcast that and you like also broadcast the the blob site cards so that you know people can um um include that other peers can include that one issue is that it is possible

that there's like a race condition where the validating a sidecar occurs um before the beacon block is uh received and um applied onto a beacon node so that sidecar validation would fail because it's unable to like associate like at least retrieve the associated beacon block needed for that validation so i think some more work needs to be done to like flesh out a little bit you know how that's supposed to happen also i can to consider like you know do you want to like flood the network um or repeatedly um broadcast these uh cycad blobs whenever that happens or as a solution

to that right so i wonder if it's almost like something like optimistic sync uh post merge where like having some spec that's kind of shared across clients would be helpful um i don't know proto terence do you have any thoughts on that i'm picky on the two of you because i know you were involved in like the merged specs um right i think my naive understanding is that we're basically treating this like an optimistic object so which is quite easy to implement from the client

perspective because we kind of have this concept of of an optimistic block and we can further extend this for for this use case and yeah do you think then it would make sense to just perhaps have a pr to this uh to the optimistic spec sync spec which extends this and then we can get some some feedback from the different client themes on it yeah and obviously you can prototype it and make sure that like it you know it works yep i do got it i guess another question i forgot to ask

is that um does it like prune the db for a sidecar after i guess one month that's the current time frame [Music] uh the current implementation does not do that yeah i guess that's another thing that would have to be added at some point right like how do we delete blobs yeah i think it's in the spec it's like a month or two um but yeah we need to also fully flesh that out in this part

but how'd that go about okay so yeah terence from like your side basically flushing out the sink fleshing out the blood deletion um are like the two big things you you see as uh yeah that's missing sorry yeah and i don't think that should be like that bad like the blogger probably takes like a week or two to implement those yeah cool um and then i'm curious on the el side uh i think the big thing there uh is like the fee market and as i understand it the more complex proposal for the fee market would require

taking a variable from the current state in order to uh to to know if things were priced correctly and that was uh quite different to how uh transaction pool verification happens now um i don't know has anyone like had time to look into that and yeah i'll start there okay if not um i'm curious yeah marius i'm gonna pick on you because you're on the guest team yeah like which which uh what what would you want to have from

the state um let me just pull up the ep anyone feel free to jump in so this is the simplified um okay so if you click the link that michael just posted in the chat and you scroll down like two lines um so basically i guess it introduces a new variable um in the state and then needs to use that to calculate the gas the the gas price for the for the blobs

so the gas price for the blobs would be dependent on the current state of the network correct and the idea there is you do something that's kind of like eip 1559 where like if there's more demand for blobs on the network you raise the minimum price for them and then if there's less demand you lower it but because the demand for uh blob data is uh independent or at least decorated from the demand for uh execution gas um yeah you can price them differently this way that has some really weird implications all over the place right during sync and stuff

can you expand on that i'm curious well if someone gives you a chain and you you you verify the sidecast but they they're actually not uh not priced correctly and you don't have the state to verify that then you can either optimistically accept them or reject them yes you don't get that you don't get the full blobs on l1 right um yeah i see proto and scar you have some comments in the chat you want to check in oh hello

so the question is when do we need to sync sidecars as a layer one nodes correct it's more like if if there is this rule that's dependent on the states to price it and you are sinking you don't have the full current state yet does that cause issues where somebody can send you like a blob that's valid but mispriced um and you you can't know that because you haven't like read the states to know what the the pricing should be so you need to price from the states and the states in evm updates only using

previous adjustments to [Music] the fee right and that's all just part of the block transaction so you don't need side cars to verify the fee changes however you do need to download the sidecars to be sure that they are available and they are valid otherwise you're still in the wrong chain but you can definitely verify the ethm chain and the block transactions without the sidecars just during sync so it's a lot like optimistic sync where we verify the pikachu independence of the

ifm-10 here we can verify the evm chain independent of the chain of blobs that are becoming available oh and then maris what do you mean by who decides how to update the gas pricing yeah if it's um like do you guys already have a formula on how to how how this uh so the erp defines two variants of the fee update mechanism one simplified variant so that we can work on the other parts of the erp in

parallel and one more complex variant that is a spec and it's a lot like eip1559 to adjust the fee based on the blocked throughput however this one is not final yet and we're looking to improve the v update mechanism i guess i'm just oh sorry go ahead and scar no i literally just wanted to say that um this is also like one area where i'm just about to start kind of looking into a bit more again so if anyone else is also working on the specifically on the pricing mechanism

please feel free to reach out yeah and i was gonna say uh marius like just from your gut feeling like is it a deal breaker for an eip like this to like have to require the state to update the the blood pressing yeah i don't see it as a like i i really i really don't like it because i think it mixes a lot of different concepts and makes the transaction pool very stateful

which it wasn't before and so things like i don't know aragon will probably protest very heavily about that because they cannot just run the transaction pool as its own module anymore so marius the only reason the fee data is part of the state it is because we're trying to minimize the changes to the block header or to the other parts that are more readily available than state if we were able to fit in fee data into the execution payload locator just like we are fitting in the base fee then it wouldn't be a problem

and maybe that's the right path to think what is the argument against that well just just to briefly make the argument against it because i think initially that just came out of the idea that um over time we would probably be moving to like more higher dimensional pricing so right now if one-dimensional like with this we will have two-dimensional pricing um just two different resource types we priced basically like imaginable like in a couple years we might have five six seven different prices and so the question is just will we be okay with just forever growing the header fields like is it okay if in a couple years we just have 10 different header fields maybe we have like a tip and a base fee for each one of these dimensions at some point so like is it just okay to have like at some point 20

different header fields related to pricing or not because if not then it might just be more more forward-compatible and a more principled approach to to go to the state if we have to do that at some point anyway yeah i will hopefully oppose this where if we are looking at time spans where right now we have like one maybe two ethereum maintenance upgrades per year if we add one base fee type of fields every upgrade then it still grows very very slowly though like i i guess just practically are there like obviously this is like we're pricing data separate from computation

but like are there i guess maybe stateless like in vertical tries would be the other thing that might bring something like this i don't think there's any any other big upgrade right now pending that would in itself bring a new pricing i think it would be more like a new like basically a specific upgrade just to to to do to introduce multi-dimensional resource pricing specifically so that could still be a couple years out um i really think it's more about are we in general okay with expanding the header a little bit if the answer is yes then it might just be the easier path here i think the the intention and i think i think initially vitaly kind of came up with doing it with the with the state um with the storage um instead

and again this was just because the idea was over time we'll have just more of these cases it wouldn't even have to be pricing just in general more of these um configuration um related values that over time we might want to move to like a system contract um approach anyway and so this might just be a good good starting point for this but um if people in general feel feel uneasy about the whole system contract idea then it might be better to just sidestep this for now how does this make i mean i i understand there can be objections to this but how does it make a difference to the transaction pool logic like in both

cases you have one variable um that determines what transactions are acceptable um and the only difference is where that variable is uh like well stored in a way so like i don't see why what the big difference is there data locality is a big engineering thing where the transaction pool can be much more encapsulated and independent of these statements yeah but yeah sure but i mean like you have you have it in both cases like why does it becoming a block field uh make it more independent than it becoming a state field doesn't the transaction poll already

need access to state in order to identify balances to know if the signer can actually pay for the transaction it can check the balances independent of the just sanity checks of the transaction validity and the idea here is that the checking if the base fee is accurate and like filtering spam should not be an operation that needs to access external states that are spamming a weak argument because for spam filtering you also need to check the sender balance yeah exactly like that's our our number one way we protect against spam is center balance yeah

arguably more important than base fee so i don't see how it was uh i guess i'd be curious to hear in practice like and guess how it it works i i agree in theory that makes sense but it's like if it's all separate in the gap implementation and even more so in something like aragon um yeah yeah i know marius or matt why is it possible to check that people have ease when they send their transactions um and how is that different from like checking if the fee is discredited in the base fee i'm not really sure like what the

numbers would be but these are in different parts of the try like the balance for an account is going to be in the like upper level of the try and if we have storage for a system contract that was going to be on honest the second level of the storage try so these are places where this could could be different like we don't have that assumption right now that you're accessing contract storage within the transaction pool and so adding that assumption you know there just could be downstream things that that we weren't anticipating or we need to rethink got it so i want to bring another argument that

actually points in the direction of it just making it a block header which is in statelessness uh it will become one anyway like if we have statelessness then making it some contract storage doesn't really make that much sense because you would be accessing it on every block okay i guess that it seems like it's at least worth investigating like how can we put this in the block header and yeah i mean we can definitely put it in the block header i think like i mean that's definitely possible from a design standpoint the block header feels more appropriate because

that's where the base fee is as well like it feels like we should keep the block related fee things all in one place and so either we move the base fee into contract storage or we add this to the block header i feel like splitting them up and doing like half and half is just going to confuse future developers significantly so is there like what's the biggest argument against doing this like you know fun functionally adding something to the block header is not hard to do we've done in the past are people relying on the exact structure of the header in smart contracts yes though append is generally safe ish because you can

when validating a block within the evm you can stop once you reach the piece that you're curious about and treat the rest of it as opaque and you can still get the correct hash for the block so if you do append only it doesn't break much another thing that changes is not just the header and the execution layer the execution padlet header on the consensus layer so that type will change as well does that change with withdrawals or i believe withdrawals the attempt to

plan for the trellis is to handle them through just all right there's system uh or sorry no system operation yeah so when special transaction yeah yeah okay yeah so it wouldn't change that okay um all right another mine says plus one for the heather um i think vitalik has been a person who's been a proponent of using system contracts i don't know if he has a strong feeling either way he's on the call i i don't think he is anymore okay i miss i i don't see him yeah okay it it it feels like yeah it's

definitely worth uh considering like the the spec to have you know there's already two proposals there um to have at least one which uses the header um we only have like uh yeah five ten minutes left uh so i want to make sure are there like other parts of the eip that people have concerns about so like we talked about sync uh this fee market there were a bunch of comments in uh in in the chat about uh the specific libraries for kzg and how they work with go so tim perhaps uh one thing i would like to

point out about the library jcg library thing is that it hasn't been decided which library should be used for the kcg stuff um in all the clients however we recently started discussion with the supernational team that have been writing a blast and we gave them a list of like methods and functions and types we need them to expose to make 484 possible also with the advanced blob verification logic and so we gave them the list last week they told us they're gonna pass it to the right people and get back to us so i mean i think it would be a strong win

to have good 4844 support in blast and after that it's unclear like what each individual client should be doing whether they should do everything converged blast like now or i don't know use other libraries potentially got it so what was the name that library i just didn't get it glassed or blasted clsc okay thanks it's basically the bls library that i think all the consensus clients are using right now for uh bls aggregation and stuff

um and they expose some functions that are useful for 484 but no definitely not all of them so one note about the libraries also is that the current prototype uses a library like the original library that gathered onboard forked and copied into their code base for the support of the bos pre-compounds so it's not that exotic that we would like to unify the libraries that the exclusion layer uses for bos with the one that the contents layer uses

especially if the consensus layer version blast is a lot better tested than first um marius i see your comment about last documentation and i think i think i didn't know about that because i haven't had to use it but if that's actually a concern i we should let them know and perhaps put more time on documentation if this is an actual like concern from implemented uh yes so we've last weekend we implemented the kzg ceremony right and um the go wrappers have no documentation

whatsoever you don't know like there's nothing there and you always have to uh speculate on what the what the functions do and um yeah and okay this is this yeah it's it's really bad and they have like two two things at two uh uh two examples for signing and verifying but if you if you use like some more advanced stuff then there's no examples there's nothing there so okay this is definitely good but i will let them know for go kcg the go library

generates proofs it previously tried to support blast it has an option to switch between different bls libraries and extended the blast bindings to do so but that didn't work as they didn't have a documentation of the memory management like how to represent those type of things with sql bindings so due to memory problems i gave up on trying to extend the bindings but maybe the others can properly extended bindings any other big just like concerns or

thoughts people have about the eip if not um i guess in terms of next steps here it feels like sync on the implementation side it feels like getting a specification for sync um that's kind of well documented and and ideally has some uh some buy-in from like multiple client teams feels like a good next step uh on the eip itself um basically making sure that we have this proposal for the for the uh pricing of the blobs that's using the the header rather than the state uh seems like a

right next step um and i'm curious i guess there are other client teams here than like at prism and guess um does anyone want to like does anyone have the bandwidth to start prototyping this as well i know there's obviously a ton of stuff going on with the merge um or does it make sense to just continue with death and prism now and and um and try to move those implementations forward and i guess that's like teku and nethermind are the two that i see here so either of you uh or either of you planning on on uh on digging into this or

sorry what was the question i kind of know yeah yeah uh basically now we just have a guest in prison prototype is it worth starting to like involve other client teams or are you all just too busy with the merge now which is also fine and we can we can continue working on just kept and present the prototype stuff so generally yes but i think we don't have the manpower right now at this moment but in a month or two we should be better with on that matter but not yet yeah that makes sense ben yeah tech is probably in a similar place

um a couple of months and then we'll we'll begin yeah okay yeah i think that makes a lot of sense so it means we can keep uh obviously like ironing out these details on the spec um making sure that they actually work in clients oh then are you on a kind team or just unmuted we'll go with unmuted um yeah we can keep working with guest and prism um and and uh share some uh yeah share some updates and then the last thing with just a minute to go um there's hcc in like a month and there's eat berlin later this summer uh did anyone want to do like a face-to-face

like workshop about this at either of those conferences um we do have time we have it slot ecc that we can um use for anyone that is there if they want to dive in together during a one-hour workshop okay it seems like there's more people at least saying like they'll be in berlin so like for sure oh there will be people at ecc okay so maybe we can just coordinate both those things offline i suspect that you know if there's some folks at ecc and some

at berlin it's probably worthwhile to organize at least something for a couple hours at both places um i did not know that east palo alto i don't know if you're trolling but um cool well i'll say really quickly is um there is this note stock i'll just paste it one more time um if anyone wants to just kind of do a quick read through and just double check it was accurate um has like attendees call outs next steps uh concerns i tried to document as best i could um yeah and otherwise um yeah thanks so much tim and everyone else that's here i know it's been said in the chat like

there's a bunch of people here from like the ethereum foundation for optimism coinbase arbitram death prism consensus another mind like um thanks everyone for taking time to talk about this and if your name if you're from a company that wasn't in that list that liam just shared please add the name of the company or the organization or the software project you're at in the note stock so we can keep track we're trying to make sure we can kind of bring everyone in to ensure everyone's on the same page cool um yeah yeah thanks everyone for for showing up i didn't expect this many people so uh and i guess once yeah once we once we've made some progress on the spec on the implementations we can

schedule another one of these for whenever it makes sense probably at least a month uh from now uh just because there's all these other calls for the merge um but yeah once we once we've like moved the needle we can uh have another call thanks everyone thank you thanks everyone thanks everybody thank you very much everybody