Ethereum Cat Herders PEEPanEIP, 3 Apr 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: PEEPanEIP #104: EIP-4844: Shard Blob Transactions with Terence & Kasey

Description

Topics covered
------------------------
0:43 - History of EIP-4844
1:30 - How did Terence join the Ethereum space?
2:44 - How did Kasey join the Ethereum space?
4:08 - EIP-4844: What & Why?
5:12 - Ethereum Today
5:36 - The rollup-centric roadmap
6:20 - Past: Everything happens on L1
6:42 - Today with L2
7:18 - Today L2 uses CALLDATA
7:24 - EIP-4844 L2 uses BLOBDATA
7:52 - Why is BLOBDATA a barrier for L2 today?
8:30 - Block vs Blob
10:17 - What is a Blob transaction?
11:30 - Blob transaction end-to-end
13:19 - EIP-4844 on Prysm
13:30 - What happens at every upgrade?
14:42 - Beacon API changes
15:20 - Validator changes
16:19 - Crypto library
16:45 - Block & blobs import
17:44 - Forward syncing
18:05 - Backfilling
18:22 - Prysmctl
18:59 - Devnets histories
19:37 - Where are we today?
20:52 - Q&A
21:18 - Why are we doing KZG trusted setup for 4844? (Terence)
22:00 - Dankrad on KZG Trusted setup & 4844
24:39 - Why Exec devs be excited about SSZ? What's upcoming work on SSZ?
27:00 - Is it correct to assume we are using the minimal SSZ for 4844?
28:00 - Risk of centralization with 4844
29:22 - Safety liveness concern
31:59 - Importance of Multi vary function in 4844
32:30 - Blob slashing for signing 2 blobs
33:44 - No. of blobs in a blob
34:29 - Implementation of SSZ on EL before Dencun upgrade
36:05 - Justin on SSZ at EL
37:05 - Explicit changes on EL & CL with 4844
39:30 - Longitivity of a blob
41:05 - Downsides of no EVM access to blobs
42:00 - How far we are from Full Danksharding?
43:55 - Plans to move from Devnets to Public Testnet
45:18 - Do we see 4844 on Goerli testnet?
46:10 - When 4844 on mainnet?
47:28 - Interaction with cross-layer teams
49:30 - Priority for Ethereum Roadmap
51:07 - Thoughts on the EIP process
52:05 - A message to community

Resources:
-----------------
Slides - https://docs.google.com/presentation/d/1j0hc8fFy4PuIDiKC79Uv77a2KtrOo9EG78aAqBEl9_s/edit?usp=sharing
Proposal - https://eips.ethereum.org/EIPS/eip-4844
Discussion - https://ethereum-magicians.org/t/eip-4844-shard-blob-transactions/8430
Website - https://www.eip4844.com/

Follow at Twitter
---------------------------
Terence @terencechain | Pooja Ranjan @poojaranjan19

4844 sorts
------------------
Something special about EIP-4844 - https://youtu.be/dL9IFt8EZVA
What's next in Ethereum after eip4844? - https://youtube.com/shorts/Sv4sKNjn3rE
Ethereum devs working cross-team - Kasey - https://youtube.com/shorts/6DCVmNSBADA?feature=share
A message to Ethereum community (eip4844) - Terence

PEEPanEIP - https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F

MEV Playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqntSgAaYHrV3NjAUMyzk7X

Shapella - https://www.youtube.com/playlist?list=PL4cwHXAawZxpok0smGmq-dFGVHQzW84a2

Questions for Guests - https://docs.google.com/forms/d/e/1FAIpQLSdsmujnH_ncIlSEJ23s9jzXAKwfpTGNeJqjREWPloBbkJVQTA/viewform

Check out upcoming EIPs in Peep an EIP series at https://github.com/ethereum-cat-herders/PM/projects/2

Contact Ethereum Cat Herders
---------------------------------------------------
Discord: https://discord.io/ethereumcatherders
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
Website: https://www.ethereumcatherders.com/

A

The ethereum community is excited about the chapel upgrade which, along with other improvements, will also enable each withdrawal for stickers. But if you are a curious cat interested in learning about the next big thing in ethereum, you are at the right place. Continue listening for the world of blogs,.

A

Welcome to Peep and Eve episode, 104 I am Pooja ranjan with two special guests with me to talk on the anchor EIP for tenkon upgrade. This EIP has an interesting history for people who aren't aware about 13 months ago in each Denver a few elclcl jobs along with Spec's help from shyway dankrad and vitalik act together, a full data block transaction prototype called mini dunk sharding eip4844 was documented a few days later on 25th February 2022. According to a tweet threat.

A

Data blocks are the first Milestone towards full ethereum sharding, enabling Roll-Ups like optimistic PVC, to grow 100 times in capacity. In the next hour. We will learn about EIP 4844 the concept of blocks and how it will improve scalability to provide an overview of progress and testing. So far we are joined by Terence and Casey. Welcome to p penny Terence and Casey thanks for having us. Thank you for joining. May we begin with a quick introduction of yourself and how you joined the ethereum space before we dive deep into the world of blogs. Sure.

B

I can go first, so back in 2018, I was really bored. I was working at a networking company, doing machine learning and then one day, I stumbled, Upon, A, ready thread from vitalik, asked him to implement scalability and working on sharding and back then shardin wasn't like shorting like today. Chardon was actually showing through smart contract, which you need to deposit a thousand five hundred Eve and um yeah. So it wasn't like we weren't sure whether that was the way to go so long story. Short, um perfect steak happening in parallel.

B

So we ended up working on proof of stages, because that seems more urgent and then fast, four or four years we launched the beacon chain and then we did a merge and now we're back to square one, we're better working and sharding, but this time with the different type of shorting, so yeah happy to be here.

C

I've been working in software for about 20 years on at startups, doing like data back-ends, so different kinds and uh didn't get into anything, blockchain related until uh 2020. When I started reading about the fact that ethereum was going to finally be um getting rid of proof of work um and that's kind of what. What motivated me and got me excited to read about how that was going to take place and and what the what the concepts were um and uh and I was thinking about.

C

Running a validator I joined, prisms, Discord um and then one day I think it was Raul, put out a message saying that uh they were hiring and I looked at the job description. It was a bunch of like technologies that I'd been working with a lot and so I kind of yellowed my resume and got an interview and I was lucky enough to join the team about two years ago um and I've been falling down the rabbit hole ever since.

B

Casey is our residential Golem Master, like he started, working on go before go was cool, so we typically go to him for all the goal. Questions and stuff like that, so yeah.

A

That's awesome very interesting. Well, thank you for the introduction um so I understand. We do have a presentations here um so without further Ado, let's beeping.

B

Okay, sure yeah I can't start and I want this to be open Forum. So if anyone to jump in say something just say, something feel free to interrupt me. Okay, so I will start so yeah. So um why why erp44? That's typically the first question and then the first 10 slides are um pretty I would say introductory so just bear with me uh and I will go to them very quick. The y44 well because of um the scalability for Lima that ethereum Community has been facing for the last 10 years right.

B

So we want something decentralized. We want something secure, that's part of our DNA, but on the other side of the spectrum, we also want some things, that's scalable, but we wouldn't. We would never sacrifice decentralization and security for scalability, because that's not what we do right. You have like chance. That's very high TPS, but with this with the trade-off, that's less decentralized and secure, and that's not what we what, but how do we like compete with like visa, for example?

B

That does like many many many many more times of scalability transaction PPS than what we do right. We cannot compete to that. Unfortunately, ethereum today does like probably 10 10 average transactions per second, probably more transfers, more erc20 transfers- probably a few exotic transaction here and there. So we cannot increase the block space. We cannot increase the DPS right so oscillator. What we really cannot compete with this, like Global Internet of value right. So um so then here comes the Rob Century roadmap, which we thought it proposed with bits.

B

So the Vitality proposed a couple years back that uh bing Angie thing actually has a good phrase for it. So I'm, just quoting him he's saying he said that um we're pulling ropes Rob puts skyscrapers on ethereum right. If you look at the picture on the right is the Manhattan some of the most expensive real estate in the world today right, but economic forces basically brings them together to build total tall buildings to essentially pack more things.

B

So you have more density per square feet right because of this type of economic force, and then you can think of ethereum like Manhattan in San Jose right layer, one is pretty expensive, it does 10 TPS per second, then you have D5 like nft Ico. They all share this layer, one then of course, then you, of course the guests will rise. People will pay more than what they intend to pay and people would get price out.

B

So what happens with layer twos so on layer, twos, essentially layer, 2 uses layer, 1 uses code data and then it separates execution, except for as execution by posting data on the Chain.

B

Because of that you can build um more, you can pack more things to it, because it's compressed it's optimized for throughput and user experience, and then so you can see that pictures title is skyscraper right, because now you can have more apps on it, but then the apps are more focused in a way versus you still have apps on layer, one that's more optimized for security and then today layer to uses code data, that's how that's that's what we know and with 444 there were use blob data right.

B

So the idea here is that okay, we're gonna spit there to a different type of data. Instead of using Code data, we use blob data and by using blob data, we're hoping that there too can Thrive even reward. They have more scalability on top, and the question is: why is that right? So why? So? What is this advantage of blob data? What is blob data better for layer 2 than code data? So that's really nice for that in the next few slides.

B

So the idea that we want people to understand is that the blob data doesn't increase the block size, so we're actually not sacrificing decentralization at all right. We're essentially putting the blob onto the block do through a commitment scheme which I will get more into later, but oh, but but all you have to know is that block increasing without increasing the block size here will not sacrificing decentralization we're just adding this new commitment onto the block, that's yeah and the commitment points to the blob so Block versus blob.

B

What is the difference right so block and blob are seen by all the nodes. So that means there is the bandwidth constraint, so they all have to download both data in terms of size, the block size, each single block has one megabit, one megabyte parameter limit. It gets very expensive once you reach that inmate.

B

This is the blob, has one hundred one twelve one, two eight kilobyte Target 256 kilobyte maps and then in terms of storage, the block, the execution user level, the trans nft unit, uni, swap related data are stored on the execution, client versus The Blob or store on the consistently claim. So that's the difference in terms of evm access on TVP cost. Those three are the biggest difference and that's what make pull up much cheaper. So um so for Block, there's evm access, you can access the blog, but for blob, there's no evm access.

B

You can not access the blob data, but you can access the commitment. That's all you need and then in terms of longitivity blog store forever. That's why it's expensive! This is blob. It can be pruned up to 18 days right so in terms of the cost per block. If you want to store code data on a Blog, it's 16 by per guess versus blob space is fairly cheap, which we can run some numbers later and then another question is okay, like what good is it used for if the pull up?

B

If we cannot access the blob to evm, where you can only access the proof, you cannot access all the data if something will get into the next few slides. So what is a blockchain session, so a blockchain session? Is you first, it's a think of just like random raw data, like opaque data, you submit it to the execution, client mempool and that's gossip among other execution clients, and then the blob transaction consists of new transaction part 0.05. It has all the usual data fields and it has this new field. It's called blog version hash.

B

So this is the magic right. This is the commitment scheme that which I talked about earlier that to ensure that whatever commits on the blob also basically like align with each other, so your blob Alliance commits to the blog. So that's how the commitment works by having this new uh blob version hash. Also, it's worth mentioning the blockchain sessions encoded in SSC, it's a new, more modern hashing, marginal martial algorithm. That's that's developed on the consensus layer, but we're gonna start bringing that to the execution layer as well to um revamp rlp.

B

So that's something very interesting. As well, this is the first time we're doing this. So a question here is that you might ask right: how does the layer 2 use the blob transaction? So this is a very over simplified version of it. So accelerator 2, your sequencer, you get the transactions from your layer to users, and then you essentially compress them in a batch and then today use code data, but in the future use blob data, and then you essentially compress them. You submit that block transaction plus some regular session.

B

If you wanna, like some ebm changes, you have to do to the accession clan mempool and then the educational layer client will gossip that among each other, so everyone has it okay and then, as a validator right, so you're proposing the next block you use. Typically, you will get a Blog. You will sign the blog, but no you have to do more. You also have to get a blood bundle if you're on this validator, if you're, rational validator, you would do that.

B

So you get the blog bundle from the execution layer, climbing pool you sign that you sign the blobs and then you gossip, the blobs, among all your uh consists of their client peers. So all the peers have the blobs. They verify it blah blah happy and then the possible up transaction to their local client to validate it, because if that's invalidate, if you're just as invalid, then the blood will become will become invalid as well and sometimes later, the other. There are two nodes: the other Layer Two validators on the same layer.

B

Two chain will also verify those blobs are indeed um correct. Basically, so they will basically read The Blob not through this get um Beacon 8 gear block, Beacon API, so you can get the blobs from the consensus layer appear, so I'm gonna quickly in the next few slides I'm gonna quickly go do like about. Are we thinking about EIP 4844 um prison just because um yeah? How are we thinking about that right?

B

So I think it's worth noting that, like um what happens at every upgrade, so at every upgrade, we always have to change these things. We have to change our P2P stack because the way we gots it um will cause a new object like we can block, will change. There's some object that will change typically at hard Force Therefore. Your P2 will change then, because of that, your state transition will also change as well, because at every upgrade.

B

For example, we draw your add new station station rules and stuff like that, and then your your stay will always always be different, so your stage transition will change and then your engine API will likely change if there is changes on the El side. So if your your ER changes, then you have to propagate the changes to the CL, so engine API will change.

B

And last but not least, your validity will change because it likely will sign different things and then you, your beacon, API, will change because speaking API is the Gateway between users and then the and then the node right, so big and APL will provide um new endpoints So. Based on these principles like these five changes are typically had to change every upgrade and hard work.

B

So for 4844, the beginning, API changes will add new endpoints to sign the blog and to download The Blob right and then there's this new paradigm that we're talking about about signing blind block. So this is kind of independent with 444, but people are constantly making Improvement to the beginning, API endpoint, so that's good to see and then in the back end. We're also thinking about like this prison, validator, 2.0 I call because currently we use prism API but it'll be nice to switch that to the beacon, API use the official API.

B

So we're thinking that how do we like intersect with that f word as well? That's what we're thinking on the validator side now, instead of signing block we're, also signing blob as well, and there's no slashing equipmentation for signing duplicated blob.

B

You wouldn't do that because if you do that, there's a risk of your blood, your orphaned, because of people receiving like um incorrect um infrared blob that you sign, then your blog will not get imported later and then, but not having slashing publication, does make things a lot easier to implement and then in terms of outdated what we care is of a latency because we want. We don't want the block to be gossip, sorry to be or reward. So it's important to have your latency on that and another thing to think about.

B

I, don't have an answer to this. What does it mean for like this? This distributed validated technology like Oppo, for example, right because they have this like threshold um key signing mechanism. So now they have to apply that for all the blobs there's some very interesting and open questions. There I encourage people to think of so crypto Library. We were switching most of stuff to ckcg and then there's an update starting April 17th. So we're finalizing the polynomial commitment related interfaces at the on the back end. We want to improve security, ux right, for example.

B

Open question is like: where does the user host the trusted set of a file and stuff like that? So that's very interesting, which we haven't done much before. That's something that's worth thinking about, and then the block and blobs import. So here's the thing right: we we cannot import the block unless you have the blobs. So essentially it's like what do we do with it right, so typically, people client will kill them in the PDP package until they have everything before they import them. Now the question is okay, when you're queuing them like.

B

When do you become nervous? When do you? um When do you request the missing object when like when you know it's missing and then and then another question is a hello hello, how long to keep the uh objects for if they never get the complete pieces of them right? There's some those factors involved. So this requires a really really good and clean design, and then he plays a very critical role in validated performance.

B

So I made this like um diagram. Just all the possible scenarios. When you have objects without each other, I mean I'm, not gonna, go through them right now, but um I'll share the slides, I'm very just happy to take a look in terms of Forward Thinking right so in syncing Remains, the Same. Basically, but now you have to also sync the blob as well, so client may get stuck.

B

If you don't, if you, if you don't, have a blob for some block, for example, and then you have to design peer scoring a rate limited and stuff like that. So that's another um things to think about and then in terms of back feeling, so unfortunately prism doesn't do bad feeling. Today um it's a shame, but we'll do it now I think now we have to delete, because now we have the backfield pull up as well. So we need to implement that feeling.

B

So that's so that's very exciting something to watch out for and then let's find out this in terms of ux right, we have this prison CTL, it's a utility that we use for a lot of things for downloading the state for checkpoint syncing right. How so we would love to extend this prism. Cto to do more things with blobs, so you can download blobs. You can verify the option sections.

B

Maybe you can send blob, maybe not I mean still thinking about whether that's like something that we want to support, but thinking about what to support yeah with those skills are useful. So where are we today so today we are so we have multiple devnets. So far, it's just like you said this thing started at eat Denver last year so like. Why are the people actually have been working on this for a year? It's crazy to think about.

B

So there has been many spec iterations right now we are on devnet four we're moving to 10.5 that net five has these new radical designs that were decoupled, the blobs and blood um all together and then the El client team are working on the TX mempool hardening. So hopefully they will do the V5 soon and uh let's see so. Where are we today? Sorry I skipped this slide, so we have consensus back execution, spec engine API, spec, they're, all pretty well defined, I would say a lot of.

B

It is just on client implementation to catch up to the specs, so there are actually. This is incorrect and bus is also ready, so I'm gonna remove that yeah. So we have all the client implementations as far as I know they are already. They are all working towards step by five and then in terms of two. Then we have this wonderful um forks with this wonderful team.

B

That's working on blob, skin 4844, that's another area to watch out for I think that's very useful to have some sort of tooling that you can watch the blobs and kcg ceremony. I. Think this just ended as well. So this is. This is also slightly incorrect. Oh this is outdated. Kcg ceremonies um has been done and yeah kudos to everyone participating on that. That's very um exciting, so yeah I think that's it from the slice perspectives. So yeah like we can move to um open, QA and stuff and just open discussion.

B

So I want to correct myself the kcg special. This is kcg. There's two faces, there's one just more General audience that part ended by now is kzg special control so still happening. So thank you. Justin for the correction. Thank.

A

You so much for the presentation like it is really interesting to look into of from the beginning like how we started conceiving the concept of blob and all about it and till today's progress. Okay, uh so yeah I have a quick question related to KGC. Can you maybe briefly talk about the importance of it for 4844? Why we are doing that to have a trusted setup here.

B

The way for kcg to work is that you need to try to set up. You need some sort of Randomness that such that, like no one knows the final answers, because if someone knows the final answers are the entropy people can ideally like like craft like signatures in a way that just pick all the notes to do like really bad things right.

B

So how do we generate that trust is set up, and then we want to be as pretty Central as possible, like ideally ask as clean as possible that when people generate some entropy people through it like through a way that entropy after and there has been many creative ways on people doing that, such as making like cat toys and then and then stuff like that so yeah, it is very important. So.

D

uh Just quickly would I was your question about uh the setup or why kcg is used um 44844.

A

So uh y or 4844 would be the first one, and why do we need a trusted setup in the first place, for there.

D

Okay, so I think like yeah, so for the trusted setup, so basically the the kcg scheme. What it requires is um a so-called uh structured reference string and what that means. It's it's Randomness that um has internal correlation and the the way that works. So like so some some uh say: cryptographic schemes just need random assassin input and that's easy. You just like say like oh yeah. We all agree that we take the output of this hash function from this input as our Randomness that you're done. But what?

D

But here you need correlated randoms and what that means is basically in elliptic curve, there's a way where you can put um a secret uh into a black box, basically an elliptic curve element.

D

So that's, for example, your uh your public key when you you have your private key and when you generate a public key using elliptic curve, you basically put your private key into this black box and you can't look inside, but you can still use it in some ways, for example, to encrypt messages to you, and what we need here is that we take the powers of one of one number and put all of these Powers into this black box.

D

So that's the correlation, that's how they are like related and uh and so like for this, you basically yeah. You need to do this in such a way that nobody knows the secret and that's what the trust is set up.

D

So we compute the series of powers inside the elliptic curve um uh in such a way that nobody, no individual and even even no, like large group of individuals, can know the secret unless every single person who participated in this trusted setup um treats and makes their brandness available, yeah and the reason I I guess, like the other question, is: why do we need this kcg scheme like?

D

Why can't we just use something uh that that would um not need such a trusted setup, because there are many like other commitment schemes, for example, Market trees do not need trusted setups, and uh the reason for that is that in, in fact, we don't actually require this, for what we want to do with 4844 like implementing, for for it for four would be possible with a different commitment scheme.

D

But what we want is that we can seamlessly upgrade this to full sharding, which requires data availability sampling, and for that we need a polynomial commitment scheme and security is the best one that we have available pretty.

A

Interesting, thank you so much Dan Craig uh Justin. um Please go ahead with your question.

E

Hi Terex um I have a question so I'm coming at this from uh an execution developer's perspective where we use rlp for everything all the time right and working on 4844 we're introducing some SSD, so I have kind of a two-part question for you one.

E

My understanding is that we are fairly minimal in the requirements for ssz with regard to 4844 and that's a good thing, and we like that, and it's going to give us the opportunity to add more SSD later on follow-up question, sell me on why I should be excited about SSD when I look at my code base and it's just rlp all over the place like get me. Can you get me excited for the uh the upcoming work that I'm gonna that.

F

I'm gonna do here because I think in my heart, at hearts of like.

E

I, like SSD on paper, it's good. um Can you kind of maybe elaborate on that a little bit and sell me on that migration.

B

Casey you want to take that since you work on SSD the most or um yeah.

C

um One nice property of SZ is just from like a um a hashing perspective. uh Is the kind of recursive nature of it? So you can tell me if rlp already does this, um where um you'll see in the consensus spec, there are a lot of types that have like a um a header variant so uh well, which kind of allows you to substitute uh an entire data structure for the root of that data structure.

C

um And then, when you compute the root of the outer container, you wind up with the same values if you would inline the entire data. So um uh that's neat to me, but I, don't know if that was property was also present in rlp.

E

It's not no there's no native, merkelization or hashing. Anything like that I mean ROP is intentionally very. You know primitive, it's it's! You know, recursive lists.

D

So so, basically, what SSD does well is uh efficient marker proofs so like, if you know, I want element X from the status structure. It's very easy to create a marker proof for exactly that point. I think that's uh hard in rlp, because you would need to iterate through all the elements before so it wouldn't be efficient as far as I understand, because each element comes with a length right.

E

Sure so am I am I right. My assumption that or my impression, rather that there is a minimal requirement of SSD 48444 like.

B

C

Just using a little.

E

Bit of it on the from the execution layers perspective, because I know that it's been everywhere on the consensus layer like forever.

C

Are we just Computing the root of the of the byte encoded transaction, or is there an entire transaction structure? I can't remember how it looks on the El, so I guess the answer question would be like. What's what's you know uh how many of the types of the SSC uh spec are? Are you using um otherwise I think you'd implement the full marshalling on marshalling and Ash tree root.

E

F

I guess the the other question is like I mean I. Think SSD itself is just fairly simple like yes, you are using like it's not complicated, but the whole thing is also just not very complicated.

D

As well, which I think is also not very complicated,.

F

Problem is just that it's not suited for uh for efficient.

D

E

Cool. Thank you.

G

um Hi um I've heard on like some of the quote: I've called that, like um after 4844, homesteakers or stickers, who have sort of lower bandwidth and equipment requirements wouldn't be able to produce blocks anymore, because um I think Computing kcg commitments to the blobs would be too much. um I just wanted to check. If that's the correct understanding, and if that is like what is what do you? What do the core devs think about the risk of like centralization that 4844 may bring.

B

I, personally, my personal opinion, I, don't think this is the eip44 problem. This is more like a post, PBS and uh more than sharding problem. Just for 444 the size we're looking at the Target is 256 kilobyte and then the match is 512 and based on our initial Benchmark, even to P2P, latency and stuff. Like that, it's well um it's it's!

B

It's well within the scope for the homesteaker and then sure for the future say if we move to like the 16 megabit setup, then yes, home Staker uh may have problem, but that's where there's parallel: research on decentralized blood, building and stuff, that's also on growing.

A

Thank you so I see a question is here in the chat. uh If anyone from the panel May would like to respond to it it's about, could you talk about the dissenting argument from Individual, ecds or other client times against four eight, four, four from a hardware bandwidth, full node requirement standpoint, as well as a safety liveness concern.

B

Yeah sure So, like um so like I, said right, like we have the reason why we keep going back and forth with coupling and decoupling and blocking blob yeah raise up a concern such that that the we want to reduce um bandwidth, consumption for individual Staker, low power, um low band with Note as much as possible, and um that's the probably the main reason why we went on this decoupling approach and based on the initial study that um I forgot was the thing that we do see some pretty good Improvement.

B

So I would say that the bandwidth itself is no longer a concern, and if there is a concern, the client teams are also actively looking into um episode as well. That's one: that's one good mechanism to reduce um Ingress and and the egress bandwidth and uh I would say, like the blobs are less much less than the artistic bandwidth that you are getting as as a no-runner. So I don't think that's much of a concern in terms of um the storage right. So we are estimating.

B

Assuming today, all the blobs are full so, which is impossible like the eat would be burned through the roof. Assuming everything is full, it's about three point something gigabyte per day, so the max of that so the max the match, the the so the upper Bond will be like 63 gigabyte per year per node, like I, said very unlikely, and the thing about blob is it's it's a very different type of data than say, State and block. You don't really need like a very you.

B

Don't really need like like a very expensive and SSD for that you can put it on the hard drive. So, ideally, we'll probably give options to know operators to essentially throw the blob as somewhere else. That's where like where they feel comfortable with. As long as you can retrieve it and survey to your other peers.

A

Thank you. My next question is about the importance of KCC multivariate function and why that is included in 4844 specs.

D

Yeah, so it's it's! uh The batch verification allows like to slightly more efficiently verify the proofs for several blocks, rather than just one block.

A

Yeah, that's pretty interesting, of course. Yes, we are trying to get it done in batch. That would be faster, um I, see a hands uh Ray Benny! uh Please go ahead with your next question.

G

Hi I guess this is more of a clarifying question. um What I saw that on the slides that it said that you guys are not doing slashing for equivocation? Is that correct.

B

That's for blob! That's that! That's that! That's not for block for block! You will get slash! That's for blob! Yes! So.

G

Why are you guys not flashing for signing two blobs, because.

B

There's economic rationality: for someone not to do it, because if today say you, you sing duplicated blob, you can only commit to one blob in a blog say today. If you send duplicating blog that the node receives the blob that you didn't commit on the blog, then the note will not be able to import your blog, so your blog will essentially be orphaned right now. The question is: okay: whether there is some like those concern for not doing that because of like, usually when people we think about equivocation.

B

We worry about consensus this, but we'll also worry about dust on the P2P layer and we don't think there is, but, like I said, it still needs more thinking around that those topic.

G

A

Thank you. So there was this question uh for including the number of blobs per block. I'm curious. uh Do we have a consensus on on that and what is the number if there is any decided number for it right.

B

Now it's too targeted is two blocks, meaning that if you are around two blocks, the data gears will not change and then the max is four below. So if we go through the max, then you have this excessive data gas field and then it's like eip1559 style, essentially increase its financially at 12.5 percent.

F

I think it should be higher than that, but yeah. That's the debate to be had that's.

B

A fun debate against.

A

Interesting and right, um my next question is about SSD. You did mention that uh some of these packs are like the blob transaction executed, are written, necessary and currently Els do not have it. How important do you see to have SSD on El before the implementation of this proposal, or maybe before the Dan can upgrade.

B

I can't speak on the El, but I'm kind of like a schedule, maximum this I kind of prefer to repeat at the safest, but also the most timely timeline per se right. So, if the, if revamping the entire El step to SSD will take longer, which I think it will then I kind of prefer just get the minimum it's done but, like I said, I have a very little knowledge on the year. Also I shouldn't be speaking but yeah like for those guys. Well, do you think Justin or anyone that's working on the El side.

E

um Sorry, could you repeat that.

B

Question um the question is that so there's so there's two screws of thought: there's one single thought is that for 444 we Implement whatever is needed on the EO site for SSD and then shift 444. The other school of thought is just revamp. Everything in on the El side to using SSC then go from there.

E

That's what I was trying to trick you into answering earlier.

E

um Personally and I don't know, there's other some other El folks on the call to let them weigh in I'm I'm, an iteration guy, um so I I like to I like to make something small ship it get it out. There learn from it and keep doing it. However, you know I appreciate um you know, there's a lot of people that take the other. The other argument, which is like look, this isn't um an Enterprise. This isn't a you know, product from the Silicon Valley sense like take your time design it you can.

E

You can iterate on your test Nets you can iterate in Dev and then ship it all at once. So you know, I I see both sides of it, but the amount of work involved I would rather I would rather get something out there with 4844 that was minimal and then iterate on it.

A

That make a lot of sense, so we are, we can safely assume that there could be a minimal implementation of SSG uh on El client so before tan con or maybe at the time, barely all right. uh My next question is also related to this plcl I think 4844. That is a one of a kind proposal that is going to affect both layers. So, as a quick note, can you maybe on High level, mention what are the explicit changes on execution layer and on the consensus layer that are being introduced with this proposal?.

B

Sure so the biggest change is that we're adding blobs right and then so by adding blocks. We also need to verify blobs and then to verify blobs there's like consensus rules, you're checking the slots you're checking this the blog root, blah blah blah, but the biggest one.

B

Is this: we're introducing a new crypto library, for example, for the kcg stuff that allows us to batch verify like you said earlier, you allows us to um I'm not sure what the right vocabulary is, but like um trans um um convert blobs into kcg, commitment and stuff like that, so to I. Personally that to me that's the biggest change as well. That's the biggest! um Luckily I'm, not the one! That's doing most of the work I'm using like this multiple, like very small people behind me.

B

That's working on the crypto Library side so definitely makes the client team's life much easier. But as a client team I was a consensus layer, client team that this change are on the net or on the networking stack since we have decoupled the blobs with the block. So now we have four uh Gossip subnet for blobs, because this match four blobs per block and then that's pretty tricky in terms of just like.

B

How do you optimize your um bigger, node and validator, set up to ensure that um you can either receive block and block also glossy blocking blob at the most timely fashion, because what we don't want is that we don't want blood to be orphaned and it's pretty easy to often block if today there, if student, there is a missing blob somewhere at some at Sun gossip subnet that you just didn't get and then you forget to request it or your peer. Just ignore you right so to me.

B

That seems, like the trickiest part, that we have been thinking a lot of yeah I. Think on the El side, there's probably the tricky part is more like the El membu design, which, like like I, said I mostly spend my time on the CEO. I can't really speak on them, not.

A

A problem, um one question that is on the longevity of the blobs: um we are having it for 18 days. So what is the reason that we are going with 18 days? um Specifically, it.

B

Just start well, so if, if we don't do 18 days right, then the question is like: do we keep it forever or do we have a duration? That is longer right? If you keep it forever, then it becomes another code data scenario which you'll be slightly more expensive, which is what we don't want right and then another question is okay. What is the duration? You want right, so we look at who are the consumers for blobs? Are the biggest consumers? Are there too? Okay? So um why? So? Why do there to how long?

B

So the question is: how long do layer 2 needs the block for for their job function to work so layer 3 uses to essentially submit um post their data post their compressed batches data on the Chain? That's for um to for optimism, I'm talking about for optimism. That's for challenging is essentially, if there's a dispute, then people can challenge and enter this dispute game and then, as the current tyranny that dispute game, the trans duration is set to seven days.

B

So the logic is that you'll be very nice to have it for seven days in a way right. So then we come down to 18 days where it's like a pretty good trade-off. It's like 60 gigabyte Maps per year, but there's long enough for layer 2 to play out the to play out their challenge game interesting.

A

And another question is about uh the uh from the same slide of blob and blobs. uh You did mention about EDM access and there is no EDM access for blocks. Do you see any downside of that I mean like? Are we making any trade-off by not having it over there.

B

No, like I I, I, I, I I think it's. If we decide for Layer Two, that's the perfect layer to use case right, but yo depends on who is using it for right. I, wonder if anyone has any input on this.

C

Yeah I think, obviously it makes things more complicated for Layer Two. They need additional infrastructure to index blobs and resolve the transaction hashes to like the blob free image, but uh they have the resources. I. Think the uh the assumption is the people who have the resources to use the The Blob Market will have the resources to build their own custom infrastructure to leverage it without needing to access it through a smart contract that.

A

Makes sense all right? um My next question is about the preparation, so we understand that this is uh not the complete sharding and uh it suggests that uh the proposal suggests that eap4844 prepare ethereum for full tank sharding. Can you briefly talk about it like where we are and how it is leading towards the full tank sharding.

B

So thanks for pointing out right, the cryptography library is there so that it's nice we can use that, for we just need to apply Erasure coating on top of it. That's one thing we're not doing with 4844, which we could do in the future. If you want to right and then the whole notion of is data available, that is there. That's also black box right. If the data is there, you can proceed into your stage transition.

B

If the data is now there, you cannot do anything so that whole notion is nice, so I would say, like 444 set up a really really good footing like for 10 sharding. A lot of people actually don't talk about this I do think it's really good to apply than chardine data available to the same simple Network on top of grossip. Now so imagine you have your 444. You have your blobs everything's gossip, but you apply you make this this another type of note.

B

It's it's not like a beacon note, but it's it's like a data available sampling node, they basically States all the blobs and then and then it does like you can. Like does all the data will be simply installed on there, such as the Erasure coding, such as, like constructing missing columns and rows and stuff like that, that's another thing: that's like very powerful to do I think shortly after 444. That's something to look into.

A

Interesting and I don't know at this point when we have, we are three or four definite tasks. Making changes before the upgrade is like how comfortable the client teams are with that, but yeah. That's that's interesting. To know um in this slide, I could see five devnets mention of five devnets. Probably we are internet four and we'll be going into internet five.

A

Do you think there is need a further more devnets, or is there a plan to move towards a kind of public test net like we have it for zeeshan for uh shape, lab and yeah.

B

I think the terminology between Daphne and Tasman are pretty blurry, I. Think they're. All the same to me, right, I, think like to me, like test name, maybe meant that okay, like um some other people, can try. It versus devnet seems more internal and I think yeah. If definitely fine girls well, I, don't see.

B

Why wouldn't do a test now, I think like what we really do want is more like inputs from the layer, two teams right, because it's useless we're just doing this by ourselves, so um our backhand I'm also pushing arbitrum to start like implementing Nitro, for example. So once we have that five states go well, we can apply our operation technology on top of that and we can have an arbitrant devnet. That's operate from test net, that's on top of yeah before, for that is using the ip4 for right and start testing that.

A

That is good, so we are very close to public yeah I mean obviously devnet means it is like by devnet people assume it. It is only for client developers to maybe take a look into and when we want to have it for Layer Two, it's a good idea to engage uh layer, two products sooner rather than later.

A

um My next question is also related to test net, but I am not sure, and that's why I'm wondering do we see um Dan con or probably 4844 on Godly test net depends.

B

How long we're gonna keep it grow the test now? Isn't there thoughts to like shut it down, I'm, not sure.

A

Yeah I mean obviously we are planning to have another tested. But my guess is there its launches somewhere in September, but I wasn't sure that if we are going to continue um Godly for uh Duncan as well.

B

Yeah I'm not so sure, either I mean you wouldn't be hard to like it wouldn't be hard to hard Fork it to then cool it's at the end of the day. It's a community decision, there's 12 other client teams other than us, so yeah, well, yeah, yeah well,.

A

I was trying to reach out to my next question, which would be like. When can we expect a 4844 on mainnet, basically venden.

B

Spicy question all right, so I would say that you'll be very surprising to me if we don't have it by the end of the year. It would be very surprising to me, but I don't know when, before the end of the year, like I, said right, there's 12, other client teams and stuff like that. If today is based on prism and and some other client team that may be faster because, but at the end of the day, right ethereum our superpowers, that we have multiple client implementations.

B

But unfortunately there is the trade-off that, like it tastes slightly longer because of testing because of yeah because of books and stuff like that. But what do you guys think there's other teams, client teams on the call so I'm curious. If anyone has a different timeline, I.

E

Think um we want two hard Forks a year right, yeah.

A

Okay, yeah I mean uh by this answer, like we can expect it in 2023. uh That's that could be a guess on a broader level, but that does not answer my previous question, whether it will be Godly or whether it will be Holland. So we'll uh look uh whenever it is planned.

A

um A few last question I want to quickly touch on uh because this proposal is actually touching both layers. So obviously uh you are interacting with both teams, anything specific, any challenges issue or any success story that you would like to share with us. Well.

B

I think like 4844, is cool for me per se, because it was an initiative that was not provided. Not. It was not like driven by select right. It was the the initiative was starting to say: let's eat Denver like Puerto land, I dunker and my client and like so it was a very so it was a very like like a it was. It was like an organic idea. They just came to fruition and even though there was the merge, there was withdrawal, but people were still working on it on the back end.

B

So therefore, the train has always been moving. It's not like we're working on 444. We just started working on it right. We've been working out for over a year, so to me, I thought was really cool to have like Parable momentum, even though you're very busy on one thing, but there's other people, that's pushing the other um effort. So with that I I do think like it's reasonable to think that's how we can have multiple hard forks for a year, but yeah I don't have much input to say other than that.

C

I also want to jump in and say: um I've been working with uh Marius and Peter and Felix on the get team on um uh sharing a sec code, generation, Library, um and so that's been really nice uh side benefit of the layers. I think working together a little bit more on on this Fork um that we're actually getting to kind of collaborate across across layer themes a little bit so shout out to Marius, Peter and and Felix for uh for the contributions. Thank.

A

You so much I can understand the introduction started with the merge only, but it is always interesting to learn more about it already. I see, uh there is another question that you would like to go ahead with.

G

um Yeah thanks um also like thank you for all the work that you guys are doing. It's wonderful, um I, just wanna one I wonder if there's like any sort of rough discussion about sort of the priority for ethereum roadmap like is after 4844, is the priority going to be PBS, or is it going to be full, dank sharding or what's what's yeah.

B

Yeah um I, don't know honestly, like I think my personal view is more like a reactive approach depends on what is needed at the moment. Right, for example, if Mev becomes bad and maybe we want to go slow finality. Maybe we want secret single leader election. If, today the state growth becomes unbearable, then we can focus on Virtual tree and stuff like that. But of all the the good thing is that lots of these efforts can happen in parallel in a way right.

B

So it's like I mean there's like so many people working on this research area right now and just like yeah I think when we're ready to deploy something, we should be fairly close to deployment versus minus some testing time, but yeah I'm curious to if anyone on the call has impulse on this.

A

Last week we had a chat with Alex Stokes on Mev boost and he obviously shared some of the uh upcoming roadmap for PBS. We don't know about the timeline as yet, but it would be interesting watch for people who want to probably learn about PBS and mme boost now all right. um My last question to you is about the EIP process.

A

um I mean it can be for anyone. I I, really literally checked the proposal and I don't see the name as an author, so I'm not sure how much pull request uh um effort you have put in, but any thoughts on the current EIP process. Anything that you would like us to improve.

B

I cannot say much because I'm, mostly on the CL and like to be CL, doesn't really do EIP. We have the wonderful requests and consistently respect which I mostly operate on I know: El people does more EIP I mean I, am a reader of EIP I like reading it, but I don't really work on them so but yeah anyone feel free to jump in.

A

Well, hopefully, we will have a unified process for both El and cl, and that's why we are trying to collect all these input we process. It's it's to know that you are at least reading eib, so we can add the structure of eaps alive if that's helpful, for people all right, it's time to wrap up any final comment or thought that you would like to share with the community any message to the community.

B

um Let's see I just wanna like I know me and Casey are here presenting answering questions, but there's like in fact, like literally like hundreds of people, that's working on eip44. It is uh probably the most important thing that we should address as ethereum as of today, right and I'm really happy to see like everyone is working on it and shout out to them as well and yeah.

B

If you're interested to contribute, um there's many ways you enjoying the ethereum Discord r d, there's a channel there eip44 for testing and there's also the bi-weekly implementers called erp44 um Team Baker's running that so yeah we're always looking for help and oscillator I. Think, like don't wait until the end like now is the best time to jump in right, provide your feedback on like gas mechanism and stuff like that and yeah the sooner we can I'm answering those questions. The better.

A

Thank you and Casey now time to provide an overview of eip4844 I feel like it's a revolutionary proposal for ethereum blocked in. We look forward to follow the progress and ultimately seeing the proposal on Main net, but Dan couldn't upgrade Dan Craig, Justin, Winnie and others. Thank you for joining us for question and answer. I hope this is going to be helpful for our listeners. On this note, thanks to all our YouTube viewers and ech podcast listeners for following this special episode on jankun upgrade, don't forget to like And subscribe cat Harris channel.

A

Should you have any question on this or any other topic? Let us know at IKEA business card next week, we'll be back with another interesting talk till then keep sharing your love with ikedum Caterers cheers.