Pectra and Fusaka | Marius Van Der Wijden

Okay. Now, okay. Oh, wow. Okay. Cool.

Okay. Okay. Awesome. All right. Um Yeah.

So, thank you so much, Mario. Yeah. Uh I think you could go ahead. Yeah. Cool.

Yeah. I hope you can see my screen. If not, scream at me. Um uh as I already said, my name is Marius. Uh I work in the Go Ethereum team and today we are talking about deciphering Petra and Fusaka.

Um and uh some some of the slides are old slides. That's uh that's why the title is wrong. But yeah, we're going to talk a bit about uh the next hard or the the coming hard fog and the the hard fog afterwards. And uh Pectra kind of is the biggest upgrade uh that we will that we probably ever had. Um has 11 EIPs in total.

Uh four on the consensus layer, five on the execution layer and two uh kind of between the layers. And um you you usually for this for this uh for the hard fogs you have uh meta eips um and these contain the um the hard fork uh basically what the hard fork contains a list of all the EIPs that the hard fork contains and you can see here the meta EIP uh for PCRA is 7,600 and within 7,000 600 you have this this list of EIPs uh that are in in uh in PCRA and um I wanted to go through some of the EIPs. Um by the way if you have questions I cannot see the uh uh I cannot see the if you have questions meanwhile feel free to raise your hand or write to the comments and uh I will let you know. Perfect. Exactly.

Um yeah so we have I I kind of categorized uh these EIPs into like minor and then execution layer and consensus layer EIP just to um put them in a in a bit of perspective. uh we have uh 7549 uh which is an EIP on the consensus layer uh which moves the committee index out of the atestation and um that's a change that will allow you to or the consensus layer to uh combine attestations better um because you can take uh different attestations from um uh from different uh sync committees I think I don't know I'm not an expert on the consensus layer uh but what it will do it will reduce the number of pairings needed to verify a block quite sign significantly and this benefits um uh zk proves um that uh uh that prove the the cl um there aren't any CK circuits currently around that proof CL blocks. But um hopefully in the in the future especially with this like new idea of the beam chain uh this will be something that is uh that is probably going to happen at some point that we are uh ZK proofing CL blocks. Um, another benefit that this has is or another change that this has is it removes the number of uh attestations that are in a uh that you can put into a block and they were removed quite signific uh uh they were reduced quite significantly from 256 um to eight. Um, and I don't know.

I don't like I personally think eight is kind of a bit too low. Um, but uh, yeah, time will tell if we are going to increase that in the next half fork. Um the problem that we've seen with uh these eight attestations per block um or per slot um is that uh when we have very little blocks being produced for example on hleski we had this problem that we couldn't include enough attestations into the block um because we could only include eight um like at a stationation aggregates. Those are not like single attestations. Those are aggregates of the atistations.

Uh but we could only put eight and that means if you only have like I don't know like five or 10 blocks in an in an epoch because there are very few nodes actually producing blocks. Um then the uh amount of attestations um that you can uh that you can put in this uh is kind of small. So the network deteriorate deteriorates uh even more um and it might lead to loss of finalization even if enough even if enough uh nodes are online only because you cannot put all of their votes into the blocks basically. Um so yeah this is 7549 uh 7840 uh add blob schedule to the execution layer. Um we previously had the number hardcoded 236 um which means uh on average like the like the the block mechanism uses 1559 mechanism.

Um basically you have a you have a target and you have a maximum. Um and whenever the number of blobs in the block is greater than the target. So if you put more than three blobs in a block um then the fee will rise and if the number of blocks uh blobs in a block is less than the target u then the fee will decrease and uh so yeah this PR allows the e to specify how many blocks can be put in a block. Um previously as I said was this was hardcoded. It's it's not really it's more like a like a tiny change.

It's not really important. Um uh but sometimes we bundle these changes um with hard fogs that are not technically part of the consensus. Uh just because the hard gives us a a great chilling point like a point where all of the network all of the nodes on the network have to update. Um, so we can put in stuff that um is not absolutely necessary for everyone to up update to um but it's very nice if everyone would update to it. And then uh we have 7691 which is the blob increase.

And in this PR in this EIP we increase the uh amount of blobs per block from three target of three maximum of six uh to target of six maximum of nine which allows for more two transactions. So basically we increase the amount of blobs that can be put in a block on average by two times. And the maximum just only goes up from 6 to 9, which is in order to uh in order to be sure that uh people are not uh uh not spending the network with blobs uh while the blob fee is low and and shutting down nodes or nodes running out of bandwidth, all of these things. Um and then we have uh some execution layer EIPs uh EIP 2537 uh which are the BLS pre-ompiles. Um we use BLS on the consensus layer for for signatures.

Um and this EIP you can always see uh see based on the number how old this EIP are EIP are. So, for example, like here, all of these EIPs are in the 7,000s, and you can see the 2537 is in the 2000s. Um, so this EIP is like five or six years old at this point. And, um, it was postponed. It was scheduled a few times.

It was scheduled even before the merge, I think. Um, but it was postponed m multiple times. Um uh because there were just there were questions around whether we can do what this EIP does in a different way uh with EVM Max. Uh for example, oh it was it was I think EVM Max was called differently back then. Um but basically if we have um uh good big number support in the EVM then we could have we could have thought about implementing these pre-ompiles just as smart contracts.

Um but yeah in the meantime we launched the beacon chain. The beacon chain uh runs on Okay, that's extremely loud. uh the beacon chain uh runs on um uh runs on BLS and so we need a way uh that it's just normal that we need a way to verify BLS uh signatures in uh the EVM. Um but this is al this also um this is not only for the uh for signature verification um but there are actually like six or seven B comp pre-ompiles added with this and uh or even more and they can be used to um to do other stuff on the BLS curve um and uh that's pretty cool because you can for example a few Um uh uh KNS I think ZK snarks are built on the BLS uh curve and um and that means uh some of the ZK U L2s can also use um uh use this instead of a smart contract uh for their BLS verification on on mainet. Um then we have EIP 2935 the block hashes.

um kind of if you think about Ethereum, if you think about the execution layer, you can think about it as a state transition function like you have a pre-state uh and then you have a transaction and this transaction gets applied and then you have a post state. And um the problem right now was that this function wasn't pure because you needed like in in in the EVM there's the block hash up code uh which gives you access to the last 256 block hashes and in order to do that uh we need in order to execute a transaction not only the pre-state but we also need the last 256 six uh blockages. And that's kind of a pain um because that means in order to verify a transaction you need to have access to the pre-state and the header chain uh and the current header uh and the previous header and um like the current header and the previous header just for computing the um uh uh the 1559 values. Um but for um but you also need the last 200 at least the last 256 headers and uh that's kind of ugly and it's not great for proving um again doing CK proofs over this um and uh this EIP kind of puts the block hashes from this kind of extra thing that you need to maintain. into um the EVM and because it's now these block hashes are now stored in in in the uh sorry into the state and because the block hashes are now stored in the state uh we can actually extend it we can put more and uh so we decided to extend it to 8,191 hashes and uh with this the state transition function is at least in theory pure uh which is quite nice.

And then we have uh EIP 7623 the call data cost and um this EIP kind of increases the call data the cost for call data. Um so call data is the data that you are sending in your transaction to a smart contract. Um and this uh call data was used for example by by L2s before uh before 4844 in order to post data on onto onto L1. U but um the problem with this is that there are two problems. It kind of blows up the history.

Um so uh call data is not like is only available during that transaction in the EVM afterwards it gets kind of forgotten from the point of the like it's not stored in the state but it's part of the history and so that means that during this in initial phase of L2's rolling uh ramping up um the amount of history that the nodes had to store increased kind of uh kind of exponentially And um what this call data cost increase does is in it increases the amount that call data costs um but in a very interesting way so that most of the transactions are actually not going to be more expensive. Most of the use cases are not going to be more expensive. Only if you have uh very little execution and a lot of data um then you are going to feel the cost in the cost increase. But if you have like most of the transactions you put some data in some call data and then they're doing a bunch of execution and then they're storing something or um doing a swap or whatever. So there's very little call data uh compared to the amount of execution that you're doing.

And in this case um this this increase will not affect you at all. Um yes, but it also reduces the worst case block from 7 mgabyte to 2.8 mgabyte. And that is also something that um we need to think about now that we have these big blob transactions in every block. Um, we need to kind of think about how big are our blocks going to be.

Um, and the size of the block um is uh uh directly uh tied to the gas limit. So the gas limit kind of gives you the upper uh upper size of what a block can be in the worst case. Um, and if we want to increase the gas limit, we would also directly increase the worst case block. And that would mean that uh we could see like 10 megabyte blocks or something. And if you think about it, uh, if you have like a I don't know like a 10 megabyte connection and you get a 10 megabyte block, then it you need uh already one second just to download the block.

And then you also need to send the block to your peers. And you might have only like a five megabyte upload. That means you in order to send the block to one peer, you would need uh you would need two seconds. And you're usually sending uh the block to like a logarithmic amount of the number of your peers. So usually like six or seven peers.

Um so yeah this is kind of what we always have to balance is like the worst case um um when we when we think about stuff. All right. Uh now ELIPs um we have EIP 7685 uh E requests. Basically this introduces a new mechanism uh for the E to notify the CL of events. Um so we have the engine API is basically the mechanism for the CL to tell the EL what to do and uh these requests they give um they give the EL kind of a mechanism to notify back the CL about stuff um that is happening on E.

Um then we have 6110 611 which is uh deposits on chain. Um previously the CL nodes would just listen to the events on the deposit contract. So if someone deposits the CL would uh would listen for events on this one contract. the contract would emit an event and then uh the CL would know okay there's uh someone just deposited into the deposit contract but for that to work you would have uh need uh logs to work so the the CL nodes would continuously um scan the logs of the E uh which is uh which is a very brittle mechanism ISM um and it's also not great performance-wise. Uh so with this, this is both an increase in performance and it makes uh makes the whole thing less brittle and we have uh we can uh way quicker include deposits on on onchain.

And then we have 7,0002 which is execution uh execution layer triggered withdrawals. Um, this EIP allows for smart contracts to trigger exits on the beacon chain. Basically, before you would need to send a message on the consensus layer to trigger an exit, and now you can do that on the execution layer. And this allows for building uh trustless there's an S missing uh trustless staking pools um where you can stake into a contract and um if you don't want to stake anymore, you can this contract can trigger uh the unstaking mechanism and you will get your money back. And there's not like no central uh entity involved.

instead of the operator that you have to trust. But um that's that's another story. Um and then we have a a couple of bigger bigger features in um in Pearra. Uh we have 7251 max EB which increases the staking limit from 32 ETH to48. Um and it also allows for consolidation.

uh which means you can take multiple validators. So um in Ethereum you can previously you could only stake in multiples of 32 and so we have a lot of active validators 1 million active validators but way less nodes because you can run multiple validators on one node. Um but you can also now uh consolidate them and that means you have way less networking overhead. You need uh you have uh way less cost for running your hardware and Mex also allows for automatically compounding stake. Um, previously you would need to uh you would need to wait until you have another 32 ETH in order to create a new validator and now your your validators become autoco compounding.

Um and if uh the um if everyone uh would take advantage of these uh of these consolidations, we could see the number of active valid active validators go from 1 million down to 17,000. Um, in theory, uh, I don't think that's very, um, uh, I don't think that's going to, uh, going to happen. I think that's very unlikely that we will see everyone consolidating their stuff. Um, but I hope at least we will not see an increase in active validators. Uh, which would be really nice because active validators means like all of these validators have to sign attestations.

All of these validators have to send these attestations over the network um aggregate the attestations. There's a lot of work that needs to be done for the for this um for this network to work. And um basically if you if you think about it at some point your node needs to hear from all of the active validators. So you will get every node will get at least in some way a message from 1 million other entities and um so that's kind of it doesn't scale that well and we are currently like very close to this limit where it just doesn't work anymore where it becomes kind of brittle. Um and so uh yeah hopefully a lot of these bigger operators will take advantage of this consolid consolidation feature.

Um and then we have uh EIP7702 uh set EOA code. Uh basically we have this idea of uh account abstraction which means that um you're not really uh you're using basically a smart account or smart wallet or basically a smart contract as your wallet. Um but it's very hard it turns out it's very hard to get people to switch over to these uh smart uh smart contract wallets. um with their uh with with their accounts. Um and so one way of doing it is allowing your external owned account to act as if it was a smart contract.

And that is what 772 does. Um it allows uh and and this is kind of cool. Basically, your EOA is now both an EOA and a smart contract. So it has some code so it can do interesting things. For example, it can do um can do batching.

So um I don't know probably most of you are aware but in ESC20 the token standard you have to send in order to send a transaction uh to uh to a contract um you have to um you have to do two uh transactions. you have to first approve um this ESC20 contract and then you have to transfer or transfer from um and uh this is something that you can do now uh in these EOA uh in your EOA with these uh 7702 contracts um within one transaction uh which is nicer. It also allows for sponsorship. Um, so basically someone else is paying for your gas. Um, or you can pay uh you can send an ESC20 token and someone else uh is paying for your gas or you and they get refunded with this ESC20 token.

So you do don't really need to own any ease to interact with Ethereum. Um, and it also allows for something called privileged deescalation. So you can sign sub keys uh that only access a percentage of funds or you can say okay this key is on my hot wallet so it can only transfer I don't know 100 bucks every day and this other key is my memecoin key so it can only uh transfer meme coins um and so on. So, uh, when is those are all of the features of, uh, of PCRA? When it's when is it going to happen?

Uh, it's scheduled for May the 7th. Uh, but it's already live on Hoodi, Supoleia, Hleski, and Ephemory. Um, so if you uh if you want to check it out, um, you can do so on the test nets. Um, and there's also like a buck bounty happening right now. So uh you can also like try to uh um try to get the bug bounty.

Oh yeah. Uh yes. Uh I don't know are there any questions yet about maybe take a minute uh to see if there are any questions? We got almost 40 people so there might be some. Um yeah folks if you have any thoughts any questions feel free to raise your hand right in the chat Joshy.

Yeah. Yeah. Hello. Um I wanted to ask a little bit about the um 6110 deposits on chain. So I understood the mech the old mechanism that you described where CL nodes basically scrape the EL logs and watch for contract events.

And I understand why that's not efficient. It sounds clunky and clumsy, but I'm not really clear on what the new thing that they're going to do is. Could you briefly describe that? Yes. So, um, basically the E note, let me let me go.

You can, you guys can still see my screen, right? Yeah, we see your editor now. Yeah. Um, where is it? Um so basically after you execute the uh consensus misk no um I'm not really sure where they put it.

Um basically after you execute the transaction after you execute the block uh you will uh collect all of the yeah pass deposit logs. um after you execute so this is the code um I don't know if it's too small but this is basically the code within G uh where where you execute a transaction you you just iterate over all of the transactions you you execute them in the EVM and uh you collect all of the receipts and all of the logs and afterwards now in Prague here you can see it uh you have these uh 6110 7002 and 7251 one. Um, and uh, basically for those you just take uh, all of the for for 6110 you pass the deposit logs. So, um, we go through all of the logs and see are they coming from the deposit contracts, uh, contract and if they're coming from the deposit contract, uh, we make sure that they are from the right topic because that is actually one of the problems uh that happened on Hleski. No, was it?

No, it was on Sapoleia. the deposit contract uh is golden uh is token gated. That means the deposit contract itself is an ESC20 token. And whenever you deposit into this ESC20 token or into this deposit contract, it will emit two events. It will emit the deposited event and it will it will emit an ESC20 transfer event.

And the problem was that this uh this code here would just error out because we're not we're not able to pass this this ESC20 transfer event. Um and so we would not be able to create a block with uh with those events in it uh which was uh which was bad. So there there weren't uh any blocks created because basically we would create the block we would fill it up with transactions and at the end we would uh do the same step here pass a deposit logs and then um that would error and we would just not produce any blocks. So all of the blocks on would be uh empty. Yeah, this is kind of how the how the how the mechanism works.

uh basically you go through all of the logs from that we have and you put them into these requests and the requests are part of the block and uh are returned to the CL. Okay, so that makes sense basically. So it sounds like in in the old days the CL nodes were basically act just like any other DAP front end and read the logs the old school way. Now we're shifting that burden of looking through the logs and finding the relevant deposit ones over to the E itself and then the result is that like that data is part of the block now. Is that right?

Yes, exactly. And and so then and it's also it's kind of better because uh uh previously we would we would need to like you would do it via RPC with the get logs and you would need to go through uh through all of the logs and filter them. And here uh we we like we have the logs available because we just produced them and uh and so we don't need to pull them up from the database again and and all of these uh things. I see. So there's still what this function you're showing here is running on logs that are like freshly generated in memory because we just built this block.

So it's like pretty efficient. Is that the idea? Exactly. Okay, cool. Yeah, I was wondering because I'm thinking it is actually more like onchain computation on the E, I guess, right?

But is it just not a lot more? It's like negligible or something. It's very Yeah. Yeah. This is uh this is very very quick.

Thank you for showing me that makes a lot of sense. Yeah. Very well. Um thank you so much for elaborating on that. We have some more hands up here.

Uh Samarat, you have a question. So I wanted to ask you said that the number of validators won't go down that much because they won't consolidated consolidate their hardware but why would it that be if they are incentivized like their hardware requirements would decrease. Uh yes. Um but I think um there is there's a tiny bit of risk, right? Um if you get slashed on 32 ETH, you get slashed on 32 ETH.

But if you get SL like if you get if you have like 10 validators and you get slashed on one of them, you're only losing losing 32 ETH at maximum. You won't lose that much. Um but if you get slashed on the consolidators uh like 320 ETH uh you will get slashed much more. Um and uh I think some of the people are thinking this way is that um uh this consolidation there there is an incentive to do it but I like from from what I kind of know about the Ethereum stakers most of them are uh kind of timid when it comes to these kind of things, they don't really want to change their setups. Um, and uh they are also lazy and they just don't do it because if they like you can run multiple keys on one machine, right?

Um, so you can run roughly I don't know a thousand keys on a machine. Um, so there's not that, yes, your machine might run a bit cooler, but there's not that much of an incentive to um to consolidate. Uh, very well. We have one more question from Shane. Yeah, just about the uh set EOA accounts EIP7702.

trying to um understand how to think about it. So if you are an externally owned account and you now have set a code that allows you to point at another smart contract to execute code. um is it that uh like the code property of the EOA now has some pointer to that other smart contract and if you now um send a transaction to your EOA then it's going to just autoexecute whatever uh smart contract it's pointing to and do you now lose your like privileges to just do like the easy transfer is it always call this other trans this other um smart contract every time you just try to hit your EOA so you you you you like uh really correctly described the mechanism. Um basically we put into your um into your EOA uh we put this uh we put this um we put the 0x EF and then the contract address that you're pointing to. Um, and this is like where you're delegating to.

And then, um, uh, you can remove your delegation by sending a transaction. Uh, well, no, I think that was changed. That might have been changed at some point. Uh I think you can you can set the nons of your delegation u so that it can time out at some point if you're sending another transaction or a few other transactions. Um because you you might want to send a transaction from your EOA without delegation going away.

Got it. It's It's this uh I don't know. It's the the EF stuff. Sorry, the the the AA stuff. I'm I'm I'm not super deep into that.

Yeah, it seems like you would um want to switch smart contracts that your EO is pointing to at some frequency. And I don't know if that takes additional transactions or if you can do say one transaction that you know sets the code uh to new smart contract and then executes it um all in one and then if you want to switch to another uh smart contract that you're pointing to same thing just like send another like uh update to the code and then into the code property to get new pointer and then it'll execute it automatically. Just trying to think about how to like save gas for multiple transactions. That's kind of most of the point. Yeah.

Yeah. Exactly. Exactly. This is Sorry. This is the code that resolves the the delegation.

Basically, we're uh we're looking up the code on on on the address on uh where where you're where you're sending to and uh if it's before Prague um then then we're just returning the code and afterwards we're calling this pass delegation function which will take the code and uh it needs this delegation EF 01000 prefix and afterwards it as the address that you're delegating to and uh so you will just return the code of the target where you where where your contract is pointing to basically. But if you like if if if you if you are pointing to a contract that is pointing to another contract um then you we will not resolve the second delegation. Okay. Uh, we have one more question from Justin. Uh, if you can make it quick, Justin, if you have a question.

Hello. Could you move your slide three step back? I want to ask question from there. This one? The next one?

Yes. Yes. All right. on EIP 610 6110 deposit onchain. Okay.

Previously C would listen to events from deposit contract. Now that happens automatically please could it throw lights know the mechanism? I don't understand the automatic approach. Yeah. Um basically I I already showed that uh uh bit ago.

Um this is what we did here with uh in the state processor. Um uh previously you would you would execute the block where and during the block execution we we uh save all of the receipts and then this other node would ask us for the receipts. give me the receipts of the last block. And then it would go through the receipts at this block and see, okay, there was a deposit to the to this event to to this um there was a deposit to the to the deposit contract and we're going to take this deposit and put it into the queue. Uh and now we're doing this is this used to be done by the consensus layer and now it's done by the execution layer.

After the block is processed, we will go through as I as I said here, uh we will go through all of the logs and see if there's any that are coming from the contract deposit contract uh with this deposit uh uh topic uh which would say someone deposited and then we will um we will add them to the uh to the requests and these requests are uh are now uh part of the block and they are returned to the um to the consensus layer. So the consensus layer would get would would get a list of all of these um all of these events that happened from the execution layer directly when it when it also gets the block. And previously it would need to ask for all of the logs. All of the logs would be returned and then it would do the filtering. And this was kind of horrible.

All right, thank you. Okay, thank you guys. Uh let's move on for now. Let's uh uh jump into Nosta and we can take some more questions after. Cool.

Cool. Um let me quickly uh get uh I need to charge my laptop. Okay. Fusaka. Uh Fusaka is a combination of Fulu and Osaka.

Uh Petra is the combination of Prague and Electra. Uh basically we have two different naming schemes. uh I don't know if you guys know but on the execution layer we uh use uh cities uh where defcon has happened and on the consensus layer we use the name of stars and on the consensus layer we the the stars are alphabetical and on the execution layer the cities are just uh by like when uh defcon has happened and so after defcon Prague We had Defcon Osaka and um Osaka has a few goals. Uh it aims to give more scale uh to uh blobs with Pas. It aims to improve the EBM with UF and it might contain some smaller EIPs.

Um but uh the discussions for that have not uh concluded yet. Um but it also might act as a shelling point for for uh for other EIPs. As I said um we typically have EIPs that are consensus critical. So they every node needs to update at exactly the same time and that those need to go into hardox. But there are also EIPs where it's kind of nice if everyone updates at a similar time.

And um these EIPs uh they get sometimes bundled into a hardfork um in order just to make sure that everyone implements it by that time. And uh so the EIPs that the Fusaka is hopefully like this this kind of shelling point is uh is EIP 444 uh or for4s which is history expiry. Basically you don't really need as a as a note you don't really need the old history. Uh you need the the header chain and you need the current state. Uh but you don't need all of the old transactions.

Um the old transactions are only really needed for for syncing a full node. Um but uh you could also get them from somewhere else. And so EIP 44s is about uh not requiring every node on the network to have these all transactions. Um then we have EIP7642 uh which is ETH69. Um basically they made this great decision back in the day to call the networking protocol uh of Ethereum uh ETH.

Uh so all lowercase ETH and then slash a number that is usually the networking protocol. Um and uh we're currently uh using ETH68 and the next one is uh ETH 69 and E69 removes a lot of uh premerge fields. Um and uh yeah, I don't know. I'm I'm one of the authors of EU 69, so I don't want to get too too deep into it, but it's going to be a a cool improvement. And then we have um EIP7892 uh which are the BPO only forks or block and and BPO stands for blog blob parameters only.

Um so uh I will talk about this later. Uh but we have like usually we think about these folks as having like some headliner some feature that we really want to ship and other features that could also fit into this. And uh one of the headliner liners for for um for Fusaka is definitely Pas. Uh DAS uh stands for data availability sampling. Um I don't know if you guys heard about how 4844 works um in this in this uh study session yet but basically we send these transactions that have like a lot of data with them but this data can be forgotten after a month.

Um and but now the problem is that everyone has to download all of this data keep it for a month and then uh and then they can forget it. But it's not really needed to be like that everyone downloads everything. What we can do is something called data availability sampling. Um where like everyone who's who's an honest actor in the network uh downloads some parts that they randomly choose and if uh sufficient enough people do this uh we know that with high probability uh someone the data wasn't withheld. So the data was actually published and that is what data availability is is all about is that you need to guarantee that the data was published and um otherwise that's the only thing that that L2s can can actually uh do is just withhold the data and not publish the the data.

Um and uh yeah so it's kind of this is the security mechanisms for your tools. Uh sorry um uh Pas is a one-dimensional erasia encoding. Uh basically we take take the blob data and uh we um extend it and erasia encode it and then we take uh uh 128 proofs uh called cell proofs and um and and send them and send some like some pieces of data on uh on different columns. Basically you uh you have different subnets in the consensus layer networking. Um subnets basically means one topic.

So in this topic you just send all of the the the columns um from from like like the first column you send to this subnet, the second column you send to this subnet as you can see on the right on the on the on the picture on the right. And um now the consensus layer nodes uh will uh need to subscribe to some of these subnets. And you can kind of decide based on um on uh your bandwidth if you want to describe to like 10 subnets or 20 or all of them. And we expect people that have a lot of stake, that have a lot of uh bandwidth, that are not homestakers to subscribe to just all of them and make sure all of the data is available. Anyway, um yeah, there are uh changes both on the EL and on the CL.

On the EL, the changes are kind of easy. uh you need to implement uh this new blobs v2 wrapper which is basically uh the the the um the new way of proving these uh these eraser encoded uh blobs and you need to have this get blobs v2 engine API endpoint and u and a bunch of like smaller things and on the CL uh they need to now subscribe to to the multiple subnets and uh verify random portions of this of this erasia encoded uh block data. And uh so this is basically the second step. 4844 was the first step. uh Pas is the second step and the third step is uh fully uh uh full DAS with uh two dimensional um uh erasia encoded um uh uh erasia encoded uh data.

Yes. Um the next um the uh the the next big feature in um currently uh slated for for circa is eof. Um it introduces a new more structure into uh EVM bite code basically. Um it introduces a header format that is similar to uh ELF. Um and it defines a code and data section sections.

Right now uh EVM smart EVM uh EVM contracts have um have uh the data and the code in the same section uh which is um for security purposes. It's it's not super great because uh you cannot prove that you um that the contract was correctly done and um EF also introduces a bunch of new checks. Um and these checks they uh they happen at compile time. Uh basically you can you you you you make sure that the contract works as expected um when you uh sorry not at compile time at deploy time when you deploy the contract. So right now you can create a contract and deploy it that just has a jump that jumps into uh like after the contract into nothingness and then the EVM will just stop and and return uh an error and that the transaction failed.

Uh but with EF uh these checks will be done at the at the deploy time. um which means you don't need to do this analysis whether a jump lands in some data section or lands uh after the contract at uh at runtime. Um, and so this kind of uh means that um uh we could remove some of the checks from the EVM because they will all be done or at least from the EF EVM because they will all be done uh when the contract is deployed. And um another thing that that EU also does is uh it removes the uh the the dynamic jumps um because they are not really needed but they are kind of uh um kind of a pain in the ass to work with. Um so for static uh an uh an analyzers uh you kind of want um uh you kind of want only to have static jumps.

Um it adds some op codes and it removes uh gas and code observability. Uh right now you have uh the gas op code which tells you how much uh gas you currently still have left. And there's a bunch of uh other op codes that kind of depend on how much gas you have left um like that that uh that kind of lets you interact with the amount of gas that you are sending to somewhere. So if you're doing a call, if you're calling from one uh contract into another contract, then you can specify uh how much gas you want to give to this call. And uh all of this is kind of gas observability.

Uh so if we would ever change uh the gas cost of something, it's uh it's uh it's kind of hard to do uh because we need to think about like how are people using this and are they only like sending X amount of gas to this contract under the assumption uh that it will just work and all of these things. And the other thing is code observability. Um basically one contract can observe the code of another. Um and uh that is not it's not really it's not really bad but it's also not great. um because uh we could think about ideas of just modifying contracts and uh that wouldn't work if we have code observability but I don't think we will ever find uh create a way of like modifying contracts anyway.

So it's it's a nice neat feature but it's not really uh not really needed and uh uh eof also improves the uh proving efficiency of C ck proofs uh over the over uh EVM uh contracts um because you remove a lot of checks from the runtime. So basically when a CK proof if you want to like do a CK proof over the execution um of a of a EVM contract for every op code you need to prove that it doesn't underflow the stack it doesn't overflow the stack um and a bunch of other things. Um but because these things are all checked during the um during the deploy time uh you don't need to check them uh during the execution and that means that um that ZK proofs are much much faster uh and and and uh uh need less time to to uh to to prove and less space. And then we have some uh minor EIPs that might or might not make it into uh Fusaka. Uh as I uh said, BPO, the blob parameter only.

Um EIP that is basically a new mechanism to do forks that only change the blob parameter uh which allows increasing the blob throughput uh quickly. Um I think that is just an artifact on how uh the CL teams kind of structured their code. um because when they want to in implement a new fork hard fork uh they are duplicating a lot of their code and now they don't want to do this uh for like these minor hards that only change one parameter basically or two parameters. Um, and so this is a way for them to kind of make a hard fork that is not uh really a hard fork so that they don't have to copy these hundreds and hundreds of files. Um, but I don't know.

I think they should my my opinion is that they should just fix the software and not do this weird forking thing. um but like implement their software in a proper way so that they don't need to do this every time we do a hard foc upper bound for the modx pre-ompile and there's another one that is like repricing the modx pre-ompile um basically mod the modx pre-ompile is one of the worst pre-ompiles that we have it just does um mod x modular x pronunciation x to the power of y modulo p. And um the problem with this is uh I think I've seen like five or six consensus bugs with this already. Um every new client kind of has a bug there. They they're they're making some some things wrong.

um with this very very easy pre-ompile like it's not a complicated thing. Um but also for example we also had a we found a bug in the um in the Golang standard library um because uh because of this um because it turned out that like it's unbounded. you can just put very very big numbers in as much as the um as the as the gas limit lets you. And um so uh someone found out um Guido like one of the one of the great security guys um found out that if you put in a really really big number with an even modulus um then the the thing takes ages. And so uh I went into the standard library and looked like we were using the go standard library implementation of this um and looked in and what was happening and they were just they were doing using a different algorithm for uh even modulus and odd modulus.

And if you know a bit about cryptography, uh in cryptography basically everything is a the modulus is usually a prime and the prime is always um uh is always odd. So every one that was testing it was testing it with an odd modulus because that's just like we didn't even think about using the modx pre-ompile with an even modulus. Uh but it turns out if you have like an even modulus that is 600 uh 6,000 digits long um then it would use this other algorithm which was really really slow. So we implemented a new uh algorithm for the standard library and um yeah that that fixed it. Um but anyway, the ModX pre-ompile is still one of the things that is kind of holding us back from increasing the gas limit.

Um because it's just a bit underpriced and it's unbounded. Um, and so we need to address this this this edge case of like putting in like no one needs a the ModX pre-ompile with a 6,000 byt long uh modulus that's just not needed like in no cryptography is this needed. Um, so we are just going to hopefully limit this at some point. Uh and the other one is RIP 7212 and you can see that this is an RIP not an EIP. Uh EIP are Ethereum improvement proposals and RIP are rollup improvement proposals.

Uh so this uh this RIP was first implemented on rollups. um and it adds the pre-ompile to verify uh SECP 256R1 uh signatures in Ethereum. We used to uh SECP 256 K1 uh which was the uh the original signature scheme and this kind of changed it uh or productionized it standardized it standardized the R1 version. Um and uh this is also supported in all of the uh all of the hardware uh uh secure elements. Uh so you this would allow us to do smart contract wallets where the keys are in your um uh in your phone's uh uh secure element.

So it cannot be extracted. Um, and that's it's it's really really cool. Um, and uh, yeah, I hope it will go onto mainet. It will go onto mainet at some point, but we don't know if it's going to be in Fusaka or in the hard afterwards. That's it.

Uh, thank you very much for listening to me. Um, I'm open to all questions um, about Fusaka, about uh, anything else in Ethereum. Um and yeah, go ahead. Lovely. Thank you so much, Mar.

It's amazing. Uh yeah, very well. It was a really great insight. And uh yeah, please ask questions. Please raise your hand and uh we have some questions in the comments.

Uh but because of the jigs, we don't read them. So if you want to read out loud the question that you shared before, please do so. Please raise your hand and yeah ask thank you Marius for that presentation. This isn't technical but I'm more political. Uh the eof update has has been subject to like a lot of controversies with many diverging uh opinions.

Uh people complaining about the complexity, people saying that included are not necessary. Uh I'd just like to get your thoughts on what you think about uh the UF update in general. Yeah, that's a that's a great question because I I also wrote a long blog post about um about the potential dangers and the the potential downsides of uh of EF. Um so I was a skeptic for for a very long time. Um I'm at this point where I kind of I don't really want to argue anymore.

I think uh um I think it's fine either way. Uh the EOF uh yes, it will add a bunch of complexity, but it's still manageable. It's not too bad. Um we have tested it uh quite well already and it's not even like we don't even have the final version yet, but it's uh there's a lot of test cases for it. Um, and uh I think the the one argument that like I kind of I I wouldn't say like uh didn't really like uh fully convinced me but um it made it like easier to accept was that if we were to uh if we were to implement the EVM right now uh it would probably look uh from scratch, it would probably look a lot like uh EOF is is is.

So um yeah, I think that that was the argument where I was like maybe we should provide this because uh uh most languages and uh most L2 teams would would like to have this. Um, so yeah, that was that that was kind of I'm I'm at this point where I'm like I don't I don't want I don't really want to be involved in the in the in the discussions anymore. Uh I'm I'm fine with uh shipping it. I'm also fine with not shipping it. Um I just don't think at this point that um that the the discussions are very productive like um the epsilon team that that like proposes uh ef is also part of the ef um they uh they are kind of I think they're they're kind of tinkering too much with the specification where like they they're adding or removing features um based on a whim based on like what the what makes it more likely for for it to go through.

And I don't like that. I think it should just be uh the best version that we can ship right now. Um, and not really uh think about these think only think about these uh these features in like are they useful or are they not useful and not is it like uh um is it politically better to add this feature or to remove a certain feature. Um, so yeah, I think it's fine either way, but I'm Yeah, I a lot of people have uh have stronger opinions about this um than I do at this point, but it's a great question. Yeah, it was a it was a tough question.

Yeah, thank you. Um, but yeah, feel free to ask anything else, any any other spicy questions or anything technical about the upcoming forks or Yeah, Sam, you can also ask me nontechnical stuff by the way if you want. Yeah, thank you Marius. So yeah, I have noticed some RAP is basically on Yeah, which is coming on CCP 256 R1 and we know that ACCP 256 K1 and R1 like have some vulnerabilities in the context of quantum computing. Yes.

And it look once quantum computing quantum computers become practical I think it would require reworking quite a bit of the existing infrastructure of Ethereum itself or G itself. Yes. Yeah. in your opinion, how do you see like G and the Ethereum ecosystem preparing for the transition towards quantum resistant cryptography? Yes.

Uh that's that's also a great question. Um so I at some point I implemented or like I I wrote an EIP uh about adding BLS uh signatures to Ethereum as to sorry to Ethereum in order to sign transactions. Um, and this was like really it wasn't wasn't really like a wasn't really like a really useful EIP, but it was a it was a nice idea. And um uh BLS BLS signatures are also not quantum uh secure or quantum proof or uh quantum resistant. Um so uh we need to change so basically we need to change two big things.

We need to change how the transactions are signed on Ethereum and we need to change how um how the uh the transactions are signed on the consensus how the consensus layer works. Um and then we also need to change how the how we're proving the blobs because KCG is also not secure uh quantum resistant. Um the try itself is actually quantum resistant. Uh but if we're moving to vertical uh which would be not quantum resistant, we would also need to move the try to another quantum resistance scheme. Uh so basically there's like four or five places where we need to change.

Um we're currently in the in the we're currently working on writing an EIP and uh I also already wrote an implementation of using um uh Falcon signatures. Um, basically we what I noticed during the EIP that I wrote like a like a year ago is that it's really easy to add a new way of uh signing transactions to Ethereum um because um like it's impossible to sign to to create a new smart contract with this new uh sorry a new public key with this new um new signature algorithm that matches an existing public key um uh because otherwise one of the signature schemes would be broken. Um and so what you uh what you can do is just add basically add a new transaction type with this new signature scheme. And so we have an EIP proposed, I don't know if it's proposed yet, but we think we're in the process of proposing it. And an implementation to add the Falcon signatures um to to Ethereum.

And uh this would be basically one of the first steps to make uh Ethereum uh uh quantum uh quantum resistant. And then of course if we're adding the the transaction type that is signed by by Falcon we would also need to add falcon verification into the EVM. So uh if this is the problem with these with these postquantum uh signature schemes is um they are not very well understood yet and so it needs they kind of need a bit more time to to develop. um and to be standardized properly and to be understood properly uh because they're based on very different assumptions than uh than our current uh uh signatures. Um so yeah, it takes some time but we are already working on it.

Thank you Marius. Yeah, thank you. Thank you so much. Um, any other questions? Any more thoughts?

We have maybe a couple more minutes, maybe one more question. Anyone? And, uh, yeah, feel free to be non-technical as well. Uh, Shane. Yeah.

Hey, um, Marius, one of the aspects of the study group is the potential to do a project for Ethereum for say five months. And I'm curious if you know if you were to select your own project um would you think you would want to do something that's for soccer is that a bit short because I think that's more maybe eight months out or maybe something more gladam related just curious how to think about uh timelines these types of things you know you don't want to block teams by you know building this kind of like side project for example but also do something meaningful yeah exactly so um I think like what what would be nice to have is uh like there's usually when you when you build out these these new hard forks um there's usually a few tools that you kind of need. Um, for example, for for for Fusaka, uh, it would be really nice to have like like a networking tool that like has an overview of where are all the shards and and um like how is propagation going and we kind of have these tools already or they're being developed uh for Fusarka. So I think um and these these these tools are usually like quite nice uh uh um nice tasks for the for the um for the EPF um what's the the normal program or whatever the six-month program um because they're kind of like a task in itself and then you learn a lot about this this upgrade. Um, so yeah, I would uh I would suggest uh working on um on on Glamsterdam or Amsterdam um because there's a lot of there's a lot of unknowns there still uh for for um for Fusaka.

We kind of know the potential EIPs that are coming in. I have an implementation for for most of them. I have an implementation both for Pas and for uh EUF. Um so those are those are kind of already covered and I think most clients have covered them. Um but for for uh for the next one for Amsterdam um it like there needs to be a lot of work done in this more exploratory phase of like yeah you have an EIP and research uh researchers are as you will notice great at coming up with EIPs um but they usually miss a lot of the like real world um constraints that we have sometimes.

Uh so um yeah, it would be nice uh if uh if if those researchers could have a helping hand from from the EPF that are working on these uh uh on on getting their ideas that they might have already proposed or are looking to propose soon into a more uh realistic and workable state. And often during implementation or during like building tooling for them, you will find out that like maybe something about them feels a bit off and maybe you would structure them a bit differently or you would do the interface a bit differently or or whatever. So yeah. Yeah. Um Barnaby had a call I think last week or the week before where it was kind of about uh scaling Ethereum and the future research and just at the end he had a slide about what likedam could entail and uh it included like block level access list which in my understanding I think would just be that you have the block level you can tell what are the like accounts that are going to be touched like up front and then the EVM could probably do some optimizations uh no like before actually having to execute.

Uh, and I'm curious if that would maybe lead to like something like parallelization. So, if you know up front that say like in one block uh two accounts aren't going to be touched, then you could potentially run those in in parallel. Yeah. Um, I I'm not a I'm not a big fan of these block level access lists. I think they they are okay.

Um but uh I think the uh in general the researchers have a they have a very optimistic view of how much this will improve things. Um and uh my view is bit more and not to say a lot more pessimistic than theirs. Um, like I think they're they're kind of like they're thinking about like orders of magnitude and the way I see it, it will be like maybe 30% improvement, maybe 50% improvement. And this is like that's not a lot. This is not like this will not bring like the the the big like uh L1 throughput uh uh that we want.

Um I think there are some other things that are that are way more promising on that front like delayed state execution uh delayed state root computation but even that is like delayed execution delayed state root computation itself is is probably is also nothing. I think that delayed state route uh the delayed execution is something uh that will probably bring uh significant benefits in in throughput on the other one. Okay, folks. Um, we have another uh couple of minutes maybe for one last question if anyone has any thoughts. We had some great questions here.

So, we can keep it going for a few minutes. Yeah. Hi, this is Kenn. I just landed in Singapore. Oh, nice, nice.

Uh, back from the East Taipei as well as the web pref festival in Hong Kong. So, I have one question. Uh, I have uh it might be out of the topic uh but I just like to ask in the in in in a hackathon I tried to make a centralized database for the different meu transactions. Mhm. And um my thoughts are to actually uh probably have a some sort of mechanism to actually authorize uh validators uh uh including their slashing or maybe waking uh uh waking kind of mechanism to actually uh allow them to insert the vampoo into decentralized database so that uh any that the builders can be decentralized and the layers can be decentral much more decentralized uh and everybody can actually pull the data from there and start building blocks.

But when you just mentioned the uh state uh delays uh then it came to me where some of the transactions in the man pool might already be confirmed and some might not have it uh have already have it in their blocks, some might not have it in their blogs and do you have any way that I could actually manage this or any kind of additional data that I could manage this? That's a that's a that's a very complicated question. um because I don't like I don't I don't really I don't really know your system, right? Um but um in general uh so usually transactions don't really live in the in the me pool for long. Um if you look at at ether scan you you will see that like most of the blocks are not full and so there's a lot of like most of the transactions will make it into the chain quite quickly.

There are only very few transactions that are not staying in uh not staying in the meool uh um for a longer time. And these transactions uh sorry that are staying in the me pool for a long time. And these transactions are are staying in the in the me pool for a long time uh because of two things. um they don't pay enough uh for the base fee um or they or if they pay enough for the for for for the base fee um then they are not valuable enough to be included by uh by builders. So, um, you really only need to be a profitable builder or to be someone like a builder that actually makes makes any sense.

You you only need to take care of these um uh you only need to focus on the transactions that are really at the at the tip of the chain. Um your kind of system does sound interesting. Um because um the the transactions that are executable uh pay enough and stay in the meool for the long time. Um those are transactions that are being censored. Um so basically what you what you've built if you notice it or not is basically a a database of sensor transactions and um that is something that we need to build anyway for fossil um because uh we want uh uh the we want um validators to be able to specify speify a number of transactions to the builders to say, "Hey, I'm I'm the validator.

I'm going to produce the next block and I want you uh I'm going to like like sign the next block and I want you to produce a block for me that includes those transactions or you have to produce a block for me that includes those transactions and uh then the then then the builder has no um cannot do anything else but to to mine those transactions. And uh so what you've been building is kind of uh a database for um for for uh solo validators to see sensor transactions on the network. Um and uh yeah, but you will always have the problem that most of the transactions that you're recording are going to be included in the next block and only a very few uh will be uh will live longer. And so uh and also everyone has to create these databases by themselves otherwise it would be kind of centralized and it would defeat the purpose of Fossil. Uh but you if you're interested in in like solving like playing around with these transactions and solving the kind of the censorship problem then then I would encourage you to look into fossil.

I I will write it into the chat how it's spelled fossil. Okay. I cannot write anything into the chat. Anyway, it's fo c i l. Uh other questions.

I got a question for you real quick before we wrap up. Uh uh so we have Fusaka coming up. Uh F Star in Osaka. Then we have G Star in Amsterdam and then H Star and Bogota after that. And then finally I star in Istanbul.

But there's already been an Istanbul fork. Yes. So what are we going to do about that? I have no idea. I have no idea.

Probably we're just we're just going to find another name for Istanbul. Uh like Constantinople or Bisantium or like previously I don't know. Yeah, most people are probably not aware but um a lot of forks were actually in in the beginning most of the forks were names other names for Istanbul like historical names for Istanbul and uh so uh yeah that of course like we had to make much more folks than there were names for Eastern Bull. Um, so if uh if the eastern boot fork comes up then uh we kind of don't probably will just skip it or we'll call it the boot 2 or something. Great.

All right, we still have some time for this. We do probably a few years. All right. Uh I hope you guys liked it. I hope you guys could take something away from this.

Um, and uh, as I said, I'm I'm uh I'm always trying to be um, I'm always trying to be like, uh, close uh, close to the community, try to help people out. So, if you ever want to just I don't know whatever chat um you can you can find me uh hit me up and uh we can talk about cool stuff on Ethereum. Thank you. I found the site uh focus. [Applause] Cool.

Perfect. Perfect. Thank you very much, Marius. And uh thank you everyone for being with us here till the very last session of the study group. Amazing.

Yeah. So yeah uh thanks a lot again uh everyone Mario especially. It was really great uh great insight there. We um learned a lot once again. Um but uh we need to wrap it up here.

So the original plan was that Mario's will have a short talk and we are like one hour over what we planned already. So we wanted to do some extra session for like the study group wrap-up uh office hours feedback and so on. Uh but we will do that in a separate session. So this is more of an organizational thing. This is not our last call.

It's our last lecture but we will have one more call uh for the study group attendees to chat with us to somehow reflect on the study group experience and uh uh also we will have some announcements there. So stay tuned. We will announce another call in the discord soon. Uh but for for now uh it's over and it's been a great ride with all of you and u uh I hope you enjoyed. I hope you learned a lot.

We will chat a little bit more next week and again thanks Marios for a great uh finish to our to our two months of uh protocol learning. Yeah, thank you. Thank you so much, Mario. And also thank you uh to you and Josh for organizing the study group which I think was uh I only heard good things about it. So um yeah, thank you for for for doing the organization and uh for making everyone uh interested in the protocol and if you are still interested in the protocol then also join ETF.

Yes sir. Awesome. Thank you for for the shout out there, Marius. That was great. Awesome.

Yeah. Yeah. Very well. Um so I think that's it, guys. Um it's been the last lecture and uh we'll uh please keep an eye on the discord.