Ethereum Cat Herders Breakout Room, 17 Jun 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: EIP-4844 Breakout room meeting

Description

Agenda: https://github.com/ethereum/pm/issues/543

Notes from the call: https://docs.google.com/document/d/1KgKZnb5P07rdLBb_nRCaXhzG_4PBoZXtFQNzKO2mrvc/edit#heading=h.c0273egri56a

A

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.

A

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.

A

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.

A

Oh, are you guys here.

A

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,.

B

Yeah, I'm here um I think murphy had the demo.

B

Has some audio.

A

A

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.

C

A

Yeah do either of you want to give a quick update on on on the ceremony.

D

Yeah sure, uh can you guys see me all right? Yes, you can fantastic.

E

D

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.

D

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.

D

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.

D

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.

D

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.

D

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.

D

um Yeah, so I think that's that's pretty much the highlights of what we have.

A

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.

D

Yeah absolutely um no major blockers. There.

D

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!.

A

Thanks thanks for the update, um anyone have questions or comments on that.

A

Okay um mophie, can you hear us now.

A

Oh, we can't hear you.

A

um You're not coming through.

A

Still, nothing.

F

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,.

D

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.

F

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.

E

um At the moment, I'm not involved.

G

G

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.

G

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.

G

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.

G

To well before I start presenting the demo, does anyone like have any questions about like? uh Where are we at.

G

Okay, I'll take that as a no.

E

All right, let me share my screen.

G

Cool, can everyone see this.

C

G

Difficulties all day today.

C

G

All right, the system's preferences thing and osx.

C

G

E

G

All right, so I have to restart the browser just for a bit and I'll be right back.

A

Anyone have a joke in the meantime.

E

Carl entertain us.

D

Do you take these better jokes than uh the the youth frog livestream waiting for the hackathon announcements? That was pretty painful.

A

Okay, we got it wilfy, we see your screen.

G

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.

G

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.

G

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.

G

E

Make sure everything is down and clear.

G

Give it a sec.

G

G

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.

E

First order: business: let's check the logs.

G

Usually the merge transition happens to like slot 9, so we can like just monitor for that.

G

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.

G

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.

G

So let me start with that.

G

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.

G

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.

G

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.

G

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.

G

Let me just look at the box without.

E

G

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.

G

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.

G

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.

G

The image that we uploaded.

G

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.

G

um Oh, I don't have that installed in this computer. Let me try here.

G

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.

G

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.

G

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.

G

So this is all pretty familiar as like before the only difference is now we're adding blobs, oh and the kcg commitments right.

G

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.

G

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.

G

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.

G

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.

G

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.

G

um This is the one.

G

So basically here we're um we're connecting to the execution node.

G

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.

G

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.

G

So when I run this.

G

G

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.

G

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.

C

So really appreciate it yeah. This is very cool. Thank you for sharing this.

A

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.

H

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.

G

I'm sorry who's talking.

H

uh This is terence from prison. Sorry.

G

Oh hey, charles, oh.

C

You're still sharing your screen mophie by the way, oh yeah, sorry about that.

G

Yeah, so it it does validate the uh kcg commitments um in prison yeah it does validate it.

H

Okay awesome. Thank you. Yep.

G

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.

H

Yeah got it, I guess I have a follow-up question like what is the next step for this in terms of client implementation.

G

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.

G

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.

H

Got it that makes sense? Thank you. Yeah.

G

Any other questions.

G

I think someone was trying to say something was that.

A

Yeah I I was gonna say I have some if if no one else has but just wanna make sure.

A

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.

H

A

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.

G

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.

G

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.

G

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.

G

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.

A

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.

A

I'm picky on the two of you, because I know you were involved in like the merged specs.

H

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.

A

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.

H

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.

G

uh The current implementation does not do that yeah. I guess that's another thing that would have to be added at some point.

A

Right like how do we delete blobs.

G

Yeah, I think it's in the spec it's like a month or two, um but.

G

Yeah, we need to also fully flesh that out in this part, but how'd that go about okay,.

A

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.

H

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.

C

um And then I'm curious on the el side.

A

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.

A

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.

I

uh What what would you want to have from the state.

A

um Let me just pull up the ep: anyone feel free to jump in.

A

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,.

A

So basically, I guess it introduces a new variable.

A

In the state and then needs to use that to calculate the gas, the the gas price for the for the blobs.

I

So the gas price for the blobs would be dependent on the current state of the network.

A

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.

I

That has some really weird implications, all over the place right during sync and stuff.

I

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.

I

Then you can either optimistically accept them.

J

I

A

Yes, you don't get that you don't get the full blobs on l1 right.

A

um Yeah I see proto and scar. You have some comments in the chat you want to check in.

J

Oh hello, so the question is: when do we need to sync sidecars as a layer? One nodes, correct.

A

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?

A

um And you you can't know that because you haven't like read the states to know what the the pricing should be.

J

So you need to price from the states and the states in evm updates only using previous adjustments to 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.

J

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.

J

Here we can verify the evm chain independent of the chain of blobs that are becoming available.

A

Oh and then maris, what do you mean by who decides how to update the gas pricing.

I

Yeah, if it's um like, do you guys already have a formula on how to how how this.

J

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.

J

However, this one is not final yet and we're looking to improve the v update mechanism.

A

I guess I'm just oh sorry, go ahead and scar.

K

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.

A

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.

I

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.

J

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.

L

What is the argument against that?.

K

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?

K

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,.

K

J

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.

M

J

It still grows.

M

Very, very slowly, though, like I, I guess just practically are.

A

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.

K

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.

K

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.

K

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,.

N

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.

N

Data locality is a big.

J

Engineering thing where the transaction pool can be much more encapsulated and independent of these statements. Yeah.

N

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?.

L

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.

J

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.

N

That are spamming.

J

N

Argument because for spam filtering, you also need to check the sender balance yeah.

L

N

L

That's our our number one way we protect against spam is center balance.

N

Yeah, arguably more important than base fee, so I don't.

A

See how it was.

N

A

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.

A

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.

O

F

Really sure, like.

O

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.

O

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.

N

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.

A

Okay, I guess that it seems like it's at least worth investigating, like how can we put this in the block header and.

N

Yeah I mean we can definitely.

A

N

It in the block header, I think, like I mean that's- definitely possible.

L

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.

O

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.

L

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.

L

So if you do append only it doesn't break much.

J

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.

A

Does that change with withdrawals or.

L

I believe withdrawals the attempt to plan for the trellis is to handle them through just all right.

A

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.

O

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.

A

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.

A

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.

P

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.

P

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.

N

F

So what was the name that library I just didn't, get it glassed or blasted.

P

F

P

It's basically the bls library that I think, all the consensus, clients.

F

P

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.

J

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.

J

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.

P

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.

I

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.

J

I

uh Speculate on what the what the functions do and um yeah and okay, this.

P

I

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.

P

Okay, this is definitely good.

I

P

I will let them know.

J

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.

J

So due to memory problems, I gave up on trying to extend the bindings, but maybe the others can properly extended bindings.

A

Any other big just like concerns or thoughts people have about the eip.

A

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.

A

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.

A

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.

Q

Sorry, what was the question I kind of.

A

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.

Q

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.

A

Q

Of months and then we'll we'll begin.

A

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.

A

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.

F

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.

A

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.

A

I did not know that east palo alto- I don't know if you're trolling, but.

F

A

I'll say really.

F

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.

F

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.

R

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.

A

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.

G

P

E

Thank you thanks. Everyone.

P

Thanks everybody.

E

P

E

Much everybody.