# Understanding Pectra & Fusaka - Channel: [ETHCluj Meetup](https://streameth.org/ethcluj-meetup) - Date: 2025-10-07 - Duration: 1:01:47 - Watch: https://streameth.org/watch/yt-WrCpCoEPa6w - YouTube: https://www.youtube.com/watch?v=WrCpCoEPa6w ## Description In this talk we will examine the coming Ethereum hardfork (Pectra) happening on May 7th as well as the next hardfork (Fusaka). We'll dive into the technical details and the background about the changes coming to Ethereum. Join us and bring all of your burning questions to Ethereum’s short-to-medium term roadmap. Speaker: Marius Van Der Wijden Marius joined the Ethereum Foundation in 2021. He's working in the go-ethereum team and he has been working on moving Ethereum forward with the Merge as well as the London, Shanghai and Cancun. He's also been focused on making sure that Ethereum is secure and stable through fuzzing and test coordination. His newest focus is on implementing some of the changes needed for Fusaka. ## Transcript Hi everyone. Uh this meetup is part of road to youth series. The talks in this series lead to the first Ethereum conference in Cl Romania. And uh the conference will take place uh at the end of June. All talks are Ethereum related and especially focused on uh the future of the ecosystem and the developments ahead of um uh for on both onchain users and builders. Sibana has prepared a discount pop up that you will be able to meet and uh get a discount uh for a ticket to the conference but that's going to happen a bit later. And uh now let's get into the main part of the meetup and that is the presentation prepared by Marios. So, uh, Marius has joined EF in 2021 and has been working on some important Ethereum upgrades like the merge, London, Shanghai, and Cancun. And he'll give an overview related to Pekra and Fusaka upgrades. Um, Pekra hard fork is scheduled for next week and Fusaka maybe sometimes later this year. I don't know. So, uh, Marius, over to you. I'll stop my uh screen share and you can uh share your screen. Perfect. Thank you very much. Uh I need to find the button. Um enter your screen. All right, let's go. Yes. Uh before I start, maybe I'll I'll just quickly introduce myself. My name is Marius. Um as already said, I joined in 21. uh the foundation but I've been working in uh Ethereum related or cryptoreated stuff uh since 2017. Uh I work on the go Ethereum team uh which is uh one of the one of the clients uh in Ethereum. um we are kind of responsible for verifying that all of the transactions are correct. Um that no one steals your money and uh so uh yeah and today we will uh we will go through the PCRA hard fork and um then later on we will also discuss the Fusaka hard which is the one coming afterwards. Um I kind of messed up a bit and I uh I thought that the presentation is in two hours so I didn't uh I didn't have enough time to like uh kind of finish my slides. Um but uh we will we will get to them anyway. Um if you have any questions uh I will stop after the Pectra um uh uh stuff and we can have some questions about that and then uh later on we will uh have a longer uh session at the end where you can ask ask me anything. Um yeah uh and just to just to set the expectations uh the talk is going to be pretty technical um but I hope that's that's okay. Uh yeah let's start. Um, so as you probably know, we uh do hard fox always in um or we do up up updates upgrades to Ethereum uh always in these called hotfox um and they happen every 6 to 12 months. And um the current the the one that we've been working on um recently was the PCRA hotfog and uh the PCRA uh is one of the biggest upgrades that we ever did. Um and we have 11 EIPs in total. Uh EIP um stand for Ethereum improvement proposals. Basically, if you want to change something about Ethereum, uh you can go to this website and you just uh create some document there and um and then uh we will discuss uh your ideas about uh about the changes to Ethereum and uh if we like them, we will schedule them for hard and then they will be included at some point. Um and uh in Ethereum we have the consensus layer and we have the execution layer. So we have two different kind of uh layers to different clients and um so we have updates to uh to both of these different layers. We have four EIPs um that uh that are on the consensus layer. We have five EIPs on the execution layer and we have two EIPs kind of touching both. Um and then we usually create these so-called meta EIPs. Um the meta EIP for 7 uh for PCRA is 7,600. Um and uh that contains all of the changes uh that are going into PCRA. So it's basically a description of all of the with links to all of the descriptions of the individual features that we're doing. Um in Petra we have some uh I I kind of structured this I'm going through all of the improvements and I kind of structured this in a way um where we have minor EIPs we have EIPs that uh that that concern the execution layer concern the consensus layer and the others. Um so for the minor EIP we have uh EIP 7549 uh which moves the committee index uh out of the attestation. Um basically this allows um this allows us to uh compress the attestations better. uh which means uh you need to do less uh verification work for for a block. Um that is uh it's a it's a tiny improvement on the on the consensus layer right now. Um but what this uh especially unlocks is it re reduces the number of of pairings needed to verify a block. Um and uh this is really cool for ZK. So in the future we would like to move the beacon chain uh to zero knowledge and um in order to do this uh we kind of need to make sure that the beacon chain um uh uh can or that that we can prove something about the beacon chain in in zero knowledge proofs and uh for that we need to think about like what are the operations that we need to do there and so this It reduces a bit of um this EIP kind of reduces a bit of the traffic and a bit of the uh the overhead that we have in the network right now. Uh but it's also kind of forward looking. Uh then we have EIP7,840 uh which uh adds the blob schedule to the execution layer. Um and um so last year in the last hard fork we introduced uh 4844 uh which added blobs to the network and um the number of blobs was uh hardcoded to uh six. So the maximum number was hardcoded to six and the target number was hardcoded to three. Um so with the blobs we use a similar mechanism to 1559 uh where we have like a maximum number of blobs that can be in included per blob uh sorry an maximum number of blobs that can be included per block and a target number of blobs. And if a block includes more than the target number uh then the fee for the blobs will go up. And if it's less than the target number then the fee will go down. And um previously this numbers 36 was hardcoded. And this EIP um gives us the ability to to not do that to change this this uh these constants. And with EIP 7691 we changed these constants. uh we increase the number of blobs uh per block from 36 to 69 which allows for more L2 transactions u because we've recently seen that basically this this uh three target is hit almost constantly um and that kind of signals to us uh that the L2s need more blob space and so we need to increase uh the amount of blobs that we are we are we are giving to them. Um yeah, coming to some of the execution layer changes. Um we have uh EIP2537 which is a really really old EIP. Um I think it's it's it was proposed before I even joined pretty sure. So it's like at least five years old. Um and um so on the con on the on the uh on the consensus layer we have we're using BLS which is a signature scheme. Um and on the execution layer we are using uh ECDSA which is a different signature scheme. Um and right now on the execution layer you can so in your smart contracts you can only use this uh um uh ECDSA SECP 256K1 curve um to verify your transactions. So you can only use these the this certain type of transactions. And um now with this EIP 2537 uh we it allows us to work with BLS signatures in smart contracts. Uh which is really nice because a lot of people want to do different things with uh BLS either for verifying stuff from the consensus layer or for uh some of the L2 some of the snarks use uh based on BLS. Um, so yeah, that's pretty cool. And by the way, you can kind of tell how old an EIP is um by the number. So the number are kind of consecutive. Uh so you can see we have on this slide we have the EIP 7,623. Uh that is kind of a newer EIP and you have 2537 which is a really old EIP. Um we have EIP 2935 uh which adds the block block hashes to uh the state. Um that one is kind of um that one is kind of a weird EIP. Um basically you have in in your smart contracts you have the block hash up code which gives you access to the last 256 block hashes. Um the problem with this block hash op code is in order to execute this you need the block hashes of the last 256 blocks. Um, and so the way this was done was kind of in order to execute a block, you need the state and you need this different like 256 hashes and then you need the transactions and then you can execute the transactions based on on these two things, two inputs and then you get a new output. And um that is that is kind of bad because it means if you want to prove something about your execution, you always need to potentially input these uh these 256 um block hashes um and the state. And uh this kind of means this EIP 2935 means that these block hashes are written into the state uh which is which makes the state transition function pure and uh that's pretty cool for proving stuff. Um then we have EIP 7623 uh the call data cost increase. It's also uh like kind of a minor EIP. Um, basically whenever you send uh data to a smart contract, uh, you kind of pay for that. Um, but we noticed that the price that you're paying it's it's kind of underpriced compared to what you're what you're doing to the network. And that means um you can send theoretically right now you can send um if you're if you're if you're creating a um a block full of uh full of call data uh you can send up to 7.15 megabytes. Uh which is a lot in the worst case. Um and uh this reduces this to 2.86 megabytes. Um the problem with these the problem that we always have in Ethereum is uh we always need to look at the worst case. Uh so if you if you um if you think about it like we can never really optimize for the like we can do some optimizations for the average case. So when the when the chain is working normally but we always need to make sure that if there's an attacker that is attacking the chain then the chain has to be stable enough and um so this is one of the EIPs that allows us in the worst case uh that kind of like addresses the worst case and uh what this allows us to as well potentially in the future is if these if all of the worst cases are addressed uh we can increase the gas limit and we can uh uh make it cheaper for people to transact on L1. Um then there are some uh some EIPs that I in in PCRA that I kind of um classified as ELIPs. Those are EIPs that live between the execution layer and the consensus layer. Um and the big one is 7685 and uh 7685 gives us a mechanism for the EL to tell the CL something. Uh basically the way the relationship is structured is that the CL node tells the EL node what to do and the EL node responds. And um so there wasn't really a good way of passing information from the execution layer back to the consensus layer. The way um that was done was through logs and uh the consensus layer would just scan the logs that the execution layer would produce. But that's a very inefficient way and it's a very brittle way. Um, and with this new EIP 7685, uh, it introduces a nice way for the execution layer to tell these consensus layer about something. And, uh, then we have to tell the consensus layer about stuff. Um, so we have two EIPs that, um, that do so. We have, uh, EIP 6110 um, which uh, which returns the deposit contract events. So if you want to create a new validator, you deposit to the deposit contract, it would create an event. Previously, the consensus layer would listen to all of the events, see that there's an event, and uh and then add it to their queue, which was extremely brittle and extremely inefficient. And with uh 6110 um the EL kind of notifies it the notifies the CL um that the deposit happens uh through one of these E requests. And then we have EIP 7002 which are the execution layer triggered withdrawals. Um this EIP allows for smart contracts to trigger exits on the beacon chain. Um so if you have a staking pool and you want to exit it uh previously you would need to uh pre-sign a message you need to uh uh send like some message to the operator and it was a it wasn't really trustless and it was pretty bad but this EIP uh really allows for trustless staking pools which is which is a pretty nice use case. Um and then we have uh uh the big change on the consensus layer for this fork. So usually we we kind of write um we uh we we create these forks around one or two big features and then we add some smaller features that we would like to uh add as well. So we call these big features headliners. Um and in PCRA one of the headliners was uh uh 7251 max EB and uh this increases the staking limit from 32 E to 248 ETH. So right now if you stake uh you can only only um stake in increments of 32 ETH. Um but with this EIP you can add more and that means you can automatically compound your stake. Uh right now you would need to you would in order to create a second validator you would need for your validator to um to have another 32 ETH profits and then you could take them out um and then create a new validator. And with this they are autoco compounding. Um and we allow for the consolidation of multiple validators. Um so if you send a special messages uh if you send a spe special message then uh you can take if you have 10 validators running on your machine you can combine them into one. And that means you need to uh you don't um need uh as much resources because you don't need to send uh you don't need to verify the same stuff 10 times. You don't need to create attestations for all 10 validators, but you only need to create attestations for one one validator. And um this will potentially decrease the number of validators on mainet uh while keeping the same amount of stake. And that is really good because um our networking overhead kind of grows uh quadratically in the number of validators. And uh right now we have over a million validators. Um and kind of like as an intuition um every six minutes a a message from every validator has to reach every other validator. Um so if we in if we decrease the amount of validators um then uh this is a much better for our networking it will mean Ethereum uh will run um much faster and so we hope a lot of people uh will consolidate uh their stake uh their validators. Um and on the execution layer kind of the headliner feature for for PCRA was um EIP or is EIP7702 uh the set code instruction uh set code transaction and um basically allows a normal account to act as if it was a smart contract. Um, and so we've had um we've had uh something called uh smart accounts or account abstraction um as smart wallets for a while. Um the problem was that people usually start with an externally owned account and have all of their assets in it and they want to use it as an externally owned account, but then they want to add some smart contract features. That wasn't possible. And uh with uh 7702 that that is now possible uh which uh can improve the user experience uh significantly for for users. So you can think about batching multiple operations together. So right now if you do a if you if you do an ESC20 swap, you need to first send a transaction to approve that you that the contract that you're swapping with can swap your transaction and then you need to send a second uh transaction for the actual transfer. Um and that is uh that is just extremely wasteful because it means you need to sign two transactions, you need to distribute two transactions. It's just a it's a really bad user experience and um this will be solved with 7702. Um it allows for sponsorship. So basically um you don't re you don't really need to own ETH anymore. So that is kind of uh one of the one of the problems that many people have with L2s is kind of if you want to if you have some coins on some L2, you also need to pay for the gas on this L2. So, um, for example, you got an airdrop on, I don't know, um, L2X, um, then you need to send some ETH there to claim your airdrop, um, to to pay for the for the fees. And, um, that is pretty bad user experience. So what you in instead can do with 7702 um is someone else can sponsor you for a transaction and you just pay them back in the token that you have. Um and it also allows for something called privilege uh deescalation. Um, basically if you have like lots of funds on your on your account, uh, you might want to say, "Okay, I have uh I have one key that can access all of them, like your normal EOA key, but that one is uh is in storage. I'm not going to touch it." And then I have like two or three keys that I can use for for um for different purposes. For example, I have like a key on my phone um that I can only use to buy um to buy $10 worth of coffee every morning um or something. And then I have a a key in in Metam Mask that I can only use with a certain asset, for example. Um all of this is possible with 772. Um yeah, now the big question is when? Um, and as already teased, uh, it's the update is going live on the 7th of May. Uh, but it has already, uh, gone live on all of the Ethereum test nets including Hudi, Sapoleia, Hleski, and the Femory. Um, so if you want to change uh if you want to test some of the features, for example, if you're a staker and you want to test the consolidation feature um or you want to uh you're you're a smart contract developer and you want to test 7 7702 uh then you can go to one of these uh networks and test them out. All right. Um that's it for the first part. Uh I don't know if there are any questions. Um otherwise we will jump into this the second part. I have a question. Uh yeah. Yeah. So why the 32 minimum staking amount was set in the first place? Do you know? Do you have any historical? Yes. So, uh the the problem is um um the problem with this uh 32 ETH is like as I as I said before I'll stop sharing my screen for a bit so you can see me. Um in the beginning like it it it's clear that we have to limit the amount of um of validators. Um that is kind of as as I said before because the amount of networking kind of depends on the amount of validators. we have have to have some way of limiting uh the the amount of valitated data that there can be there can be. Um and so these 32E were kind of chosen in a way um that like they I think they they made some calculation that said okay like if we expect 30 20 to 30% of all of e all of the ETH to be staked at some point if we do this we will have 600,000 validators or 800,000 validators with 32 each Um and this is kind of manageable by our networking. Um so the number that they kind of chose was um is kind of below what we have right now. So I think they expected something like 600,000 or 800,000 validators. As I showed, we have over a million validators right now. Um so we kind of went above what they expected when they set the number. Um but uh- which is which is a bit scary because the networking wasn't wasn't uh created with this in mind. Uh but since then the networking has uh has improved sign significantly. Um which is uh uh which is uh which is pretty cool. And so we can support 1 million uh validators. Um but uh uh and it it's also like a testament of how much people kind of believe in Ethereum is that they are willing to stake their money um into Ethereum at at this high rate. Yeah, cool. Thanks. There's another one in the chat. So for uh EIP7702 does it mean that all existing UAS will automatically gain the benefits of smart contract wallets or is it more in conjunction with the deps that should somehow support this? Yes. So um your DEP doesn't need to support this. Um like most DEPs should work out of the box. Um but you don't get these benefits like you need to create a uh a uh something called an authorization where you're authorizing um a a certain smart contract to act as if it was you. Um and there will be uh certain contracts that are whitelisted by the wallets that um uh that are kind of trusted by the wallets to perform uh reasonably well. Um and the um the dep should kind of work out of the box, but you would need to sign this special authorization and then you someone would need to put this authorization on the chain. It can either be you or there will most likely be services where you can say okay I have this authorization please put it on chain for me. Okay cool. Uh, another question from me or us. Uh, for EIP7685, um, so beyond block proposals and and validator exits, um, what are some other examples of future events or communications that could happen between the execution layer and the consensus client? Um right now I don't know like we have we have the the uh the exits the um um the uh the the exits we have the deposits and we have the consolidations um all of those are are triggered on the on the execution layer and and like communicated to the consensus layer. Uh one thing that we are thinking about right now with um with um with the blobs uh with uh pia does is that um there will be blobs communicated between the execution layer and the consensus layer. We kind of have that already but it will be much more in the future. Um so uh basically the consensus layer will on some level depend on the execution layer for the transaction propagation uh of blobs. Um so if we have like a lot of blobs like I don't know 30 40 50 blobs per block. Um so like kind of like 10x of what we're doing right now. um then it's very important that these these blocks are like continuously sent around the network and everyone kind of has them in time and so there will be um there will be more of these interactions where um we are utilizing both the networking layer of the consensus layer and the networking layer of the execution layer uh to do jobs. Yeah. But um like within within the ex within the execution layer, I don't know what what else can be done there. Um but I'm also not a not an expert on the consensus layer. Uh I don't really know what like what what kind of info or what kind of actions they need from us. Um so whenever they whenever they come up with anything, we're we're always happy to implement it. But uh yeah, nice. was just curious to see if there's already something, you know, to keep in mind. But yeah, thank you. Makes sense. I think we can, unless anybody else has any questions or maybe just have them at the end, I think we can uh move forward with Fusaka. What do you guys think? Cool. Right. Um let's get into uh the the interesting part now. Um so FA um I I don't know if if you guys know but probably um these fork names are kind of weird, right? like we have Pectra, we have Fusaka, we had Glamsterdam or we we're having Glamsterdam at some point and um they are always like um the the because we have this EL and CL uh we we have kind of different names for the execution layer and different names for the consensus layer and um so on the on the execution layer we are naming the forks after the cities where Devcon has happened. Um so for example, Fusaka is uh Defcon Osaka pre uh Prague is Defcon Prague. Um and uh sorry, Pectra is Defcon Prague. Um and we're combining the city name with a name for a star on the consensus layer. So on the consensus layer, all of the forks are in alphabetical order different stars in the universe. So for example, for Fusaka, it's the Fulu star. Uh for Pectra, it's Electra. Um and for the the fork after pectra which is called glamsterdam which is a combination of cladios or something I don't know I don't know I don't actually know the the star name and Amsterdam because uh we had dev connect in Amsterdam so yeah sorry I kind of got sidetracked there. Anyway uh let's go into Fusaka. Um we appreciate it actually. This is something that we had no idea around. I personally do. Yeah. So, yeah, as I as I said before, it's it's it's fulu in a sucker. Um and uh yeah, as you can already tell on this slide, I have not had had time to update this uh because yesterday we had a big discussion and we decided not we decided to remove EF uh from Fusaka. Um, and we can talk a bit about that later. Um, but it's still on the slides. Um, so yeah, anyway, the big feature that everyone wants to uh focus on with Fusaka is uh Pas uh Pas uh DAS. Uh well, I I I I'll go into that later. Anyway, um and then we in addition to Pas um we will have some smaller EIPs um and it will also hopefully act as a as a shelling point uh for some of the the other things that we we're planning. So um in Ethereum we kind of have we have EIPs that change the consensus. Uh we call them core EIPs. Um, and then we have EIPs that don't really change the consensus, but it would be really nice if all of the clients uh upgrade at the same time. Um, so for example, uh, E69 is a change to the networking protocol. Uh, we can just change the networking protocol in theory. We can change it whenever we want to. uh but it it is always really nice to take these hard forks as also a point where uh all of the clients ship a certain feature and so uh for Osaka or of for Fusaka will hopefully be the shelling point for EIP 444 which is history expiry um where we can where we allow users to forget about certain parts of the history. Uh right now running your full node takes you roughly 800 900 GB um on the execution layer plus the consensus layer. It it uh it goes um it's it's very close to like the two terabyte mark. Uh and that means um a lot of people are worried about their nodes overflowing. Um and they don't really need to store like most of the validators most of the nodes don't really need to store all of the ancient history um that they don't really care about right now. Like most of the like you really only care about the like what is your account right now. You don't really care about like what is your account five years ago. um in most cases. Uh so uh what what 444 allows us is to uh remove some of the history from the nodes and that will mean that um that clients will go significantly below the two terabyte uh uh line uh which is which is nice because then uh users don't have to uh buy new SSDs to upgrade their nodes. Um, as I already said, E69 removes a bunch of uh legacy stuff from the networking. Um, and uh, yeah, it's it's a it's a great EIP. I it's it's my EIP. U, but it's also a really a really good one. It's just an improvement to the networking and make makes networking much nicer. And then we have EIP 7892 uh which are BPO Fox uh which means block parameter only. Um I don't know if I actually have a slide to that. No, I don't have a slide. So okay then I'll I'll explain it here. Um for BO forks um those change the uh the parameters uh for the blobs. Um, previously I I I I told you guys that um like we're changing in in PCRA we're changing from 36 to uh 69 and these fogs uh will change that even further and that allows us um very quickly to update the amount of um the amount of blobs that we're having in a blob in order to scale the L2s. Um yeah, but the big feature that allows us to um to to do that to scale the the networking um is called Pas. Uh DAS stands for data availability sampling and um basically you're there are very great presentations about it. I'm not I'm not really good in that cryptography part. Um, but right now when you're sending out a block with uh five blobs in it, you need to send out the block and all five blobs to everyone in the network. And um that's uh kind of wasteful because all of the nodes don't really need the blobs. They just need to make sure that the blobs are available. And what Pas does is um we are not sending these block proofs uh but we're sending something called uh cell proofs KCG cell proofs and the blobs are one-dimensional erasia encoded and um so you the network does not everyone on the network needs to see all of the data. Um, you will pick some of the data that you want to see and will ask other nodes about it. And if everyone does this or if like a good majority of the of of the nodes um do this sampling step, then we can sure can be sure that all of the data was a available and was sampled. Um and uh you will be able to run a super node and sample all of the data and be sure and we we are expecting like big staking operations um and and other big entities like big L2s um to do this. Um but uh you don't really need to do this uh as a as a homestaker. Um there are some changes um on the execution layer. On the consensus layer um on the execution layer we have a new blobs uh v2 wrapper. Um basically the the transaction type kind of changes but it doesn't really um it's uh you in instead of sending the normal plop blob proofs you will send these KZG cell proofs and um we will have an update to the get blobs endpoint. the get blobs endpoint kind of like the consensus layer can ask the execution layer, hey, do you have these blobs in your um in your transaction pool and the execution layer tells it either yes, we have it or we don't. And if it has it um then it's great um then we don't need to fetch them from the network anymore. And so that reduces again reduces the amount of of of traffic that we have to fetch from the network. Um on the consensus layer uh you have to now subscribe to multiple subnets basically. Um on the networking it's it's kind of like this. You have you subscribe to different like subn networks that have different data. Um and you can choose which of these networks to sub subscribe to. Um and you will verify random portions of the data. And if enough people do this with very high profitability um all of the data has been sampled and that means the data is available and that that's like that's the only thing that uh that we need for the security of L2s is we need to be sure that these L2s actually publish their data and that is yeah called data availability. Um and uh yeah, Pas actually allows us to uh to massively scale the amount of blobs um that we're sending that we can send per block, which is which will like mean that the fees on L2s will go down. Either the fees on L2s will go down or more likely the amount of activity on L2s will go up um because transactions will just be cheaper. Um yeah uh this slide um is kind of obsolete as of yesterday uh when we removed EOF uh from the fork. Um so I will not spend too much time on it. Um basically it was a change to the EVM. Uh it was removed um because it was it became kind of controversial. Um it's oh I'm pretty sure there will be some questions about it so we can we can just discuss it later. Anyway, uh there are some minor EIPs that I wanted to go through. Um BO I already kind of talked about it. It's a new mechanism to only change the block parameters. Um we have EIP78 uh23 which is the upper bound for the modx pre-ompile. Um it again dresses addresses one of like these worst cases. um uh that we're that we're looking uh that we're looking into in order to increase the gas limit is uh we need to make sure that uh if someone sends uh a lot of calls to the med modx pre-ompile um then it will not create blocks that are too too long to execute take too long to execute. Um and then we have uh something called uh RIP 7212. Uh as you can see this is uh this is an RIP uh not an EIP which is uh RIP is uh stand uh RIP stands for rollup improvement proposals. Basically, those are those are changes that um that are decided between the L2 teams and they've come up with this proposal. Um and it adds the SECP 256R1 pre-ompile. Uh right now in in Ethereum we use uh the K1 curve. Um it's just different cryptographic curves. Um the difference is R1 was uh standardized by NIST. um which means it is um it is implemented in a lot of hardware. Um so for example in your phone you most likely have a secure enclave that has these uh that supports R1 but doesn't support K1. Um and that means uh now uh with with this change we can verify the signatures from these secure elements uh on chain and together with account abstraction. That means you can now uh you can now be sure that no one can extract your keys anymore because they are living inside of your um inside of the secure element on your hardware. And um that's pretty cool and it allows for like incredible user experience because you can just sign a transaction uh with your like I don't know with your normal face um in uh in in in your iPhone or or whatever or with like a like a fingerprint print sensor on your on your computer. Uh which is really nice. Anyway, um yeah uh that was it. Uh thank you very much for listening and um I'm open to questions uh of any kind. Um yep. So, I'm sure people are uh going to wonder about the EIP that uh got stripped out yesterday from the from the pack upgrade, right? Yes. Want to talk a little bit just touch upon it? Um I can talk about it. Um yeah. So uh the problem that I see is um so what EF like UF is the the the the EIP that was dropped. Um the idea was that it would create basically a new EVM that is that runs in parallel to the old EVM and that has a bunch of um a bunch of uh advantages. Um the problem is like the big problem is you cannot get rid of the old EVM because there's just too much depending on the old EVM. Um the re but that was kind of a drawback from the beginning that everyone was aware of. Uh the reason it was kind of dropped so late in the process was that um people became aware that they would need to rewrite a bunch of the contracts that they've written for for the normal EVM in order to move it over to this new EVM. Um and yeah, people especially smart contract developers, especially maintainers of like big libraries like um Open Zeppelin or or like uh I don't know what what are these other big smart contract libraries that people use. um they were not uh they were not super um happy about that because that means like these libraries have to have two versions one for the EVM one for this efm and then if you have like if you build your project and you're depending on li on on some libraries like all of the libraries that you're depending on and all of the libraries that they're depending on all have to work for for EF and um that means a lot of the ecosystem has to change. It I don't know I I I implemented EUF in in G. Um so I um a lot of my code is now kind of obsolete. Um, but I'm also not one who uh who thinks that like uh who's very attached to his code. So I'm I'm in the end it kind of came down to we there were so many people against it and um there were like probably equally as many people for it. Um, but we kind of like in in the past we never shipped anything when there were a lot of people against it. And so, uh, I think it was the right call in in in the call yesterday to to pull it out. Um, because, uh, yeah, we we kind of always error. we kind of always have to error on the side of caution. Um and well that that is at least like that's my my personal view about it. So yeah. Yeah of course makes sense actually. All right. Thank you. Um there was there was a question about uh security critical stuff. Um uh EIPs um except for the call data one. Uh there wasn't anything included in Petra that I would say is like in the like security category. Um uh the call data one is 7623 I think. Um uh other than that there was like there wasn't there wasn't uh anything big. Um is there a date or um what's was the speculation related to rollout date for Fusaka or That's a great question. Um that kind of depends on the scoping of of it basically. Um we we kind of have the scope down like I think most people kind of don't want to increase the scope even now that we pulled something out of it. Some people are arguing okay we pulled something out we can like replace it with uh something else. Uh but I don't think we should do that. We should um like restrain ourselves and be very mindful of everyone's time and just ship the things that we committed to and then um and and hopefully ship a bit faster maybe and then we can we can discuss for the next up upgrade what what we're going to include uh there. Um I hope I I'm I'm pretty confident that we can ship um uh Fusaka within this year. Um yeah, but again like the dates it's it's uh it kind of depends on like how much can the how much uh can implementations prioritize like working on these new features over kind of maintaining their own client. Um yeah cool thanks uh Maris I remember in at Bucharest you do after your presentation or during your presentation one of them I don't remember which one you mentioned two resources that people can follow in order to understand better what happens in yes in um we have uh epf.wiki wiki um which is um I put it in the chat. Um if you are like interested in in in like core development or like these kind of things um you can uh and and you would like to maybe join us uh to work on these things. Um then you can start with a with the EPF the Ethereum protocol fellowship. It's uh I think a four month program and um we will uh we will pay pay you some money so that you can survive. Uh you will not get rich during these four months but you will um like we we don't want you to like starve to to work on the protocol and um that's it's been an incredible uh program. A lot of the people that went through it are now working at um places like I don't know like Lighthouse like um like the Ethereum Foundation a lot of these uh Nimbus a lot of these uh client teams are actively looking at people who are who are going through the EPF um and uh yeah but the people in within EPF they also maintain a lot of resources regarding the protoc which is really nice. Um so uh if you have like specific questions about uh about the protocol uh you can always go to the epf.wiki wiki and um they maintain like a like basically like a like like a glossery or something to where you can like look up uh certain things and um yeah if you want to engage in the conversation uh you think you have I don't know you have some uh some EIP you have some improvement that you want to discuss uh then you can go to the uh Ethereum R&D discord Um, and the link for that is on the ethereum.org website. Um, but yeah, it's it's kind of hard to find intentionally, but this is where we uh where we discuss a lot of uh a lot of the stuff uh that we're working on. I'll paste it in the in our chat in Ecl. I think I'm already on the group. Yeah. Okay. Thank you. Actually, I think we have somebody in our community that has gone through the fellowship program already and I think he's gonna be a speaker for you close this year as well. So, that's great. Forward. Yeah. Cool. All right. Um, if there are no more questions, guys, anybody? Okay. Uh so if there are no more questions I I guess we can move forward with uh you know scanning your co-ops for this this session. So just like a brief introduction for anybody that isn't yet familiar with our initiative which is called road to eat kluj. So this is an initiative that we've taken on uh in anticipation for our main event for this year which is the kluj conference happening in kljnapoka romania between the 26th to the 28th of June. So we want to give a chance to everybody to attend for free. So if you guys attend online sessions uh in person uh get togethers as well and meetups uh we set up co-ops for each of of these sessions that everyone can scan uh or mint and uh you basically benefit from a 25% discount uh for conference tickets this year. The aim here is to to gather as many people that are curious about Ethereum that are willing to contribute and or just you know willing to just find out uh what we're building here. So uh this this po can be uh besides you know like the let's say cool artwork right and proof of participation um the 25% discount can be accumulated to one free ticket. So really inviting everybody to to scan mint the pop-ups and you know hopefully we'll see you guys at the next session as well. I'm just going to share my screen for this. All right, just give me one second while Simona shares the screen. Uh the next session is going to be in May 15th and is uh we'll have Bianca from Devil Union. She'll be talking about oracles and what various available categories there are and how to choose the oracles for your deps. All right. So, uh the popup should be up for everyone to scan. Just ah sorry I have the wrong one up. Just one second. I think I have a Just give me one second. Okay. In the meantime, Myers just wanted to thank you for the nice and really understandable presentation. It wasn't that technical if I managed to understand stuff. So, yeah, thanks for it. Thank you. Yeah, thank you guys for for coming and um for listening to me and bringing a bunch of bunch of good questions. And now I'm I'm ready to skin the pull up. Hopefully it's the right one now. Sorry, apologies for that. That's the thing, right? Uh so yeah, just take a moment. It will uh automatically refresh after you scan. So take a moment, scan it and hopefully we'll see everyone include in June or at the next section next uh next session. So either one or both. Okay. Yeah. And in the meantime, yes, thank you so much, Maris, for for taking your time uh to talk to us about the upcoming upgrades. I'll be honest, I'm not the most technical person similar maybe to Bogdan or maybe even less. So, but uh it's cool to learn uh from people who are actually leading in this field. So, um yeah, we'll make sure to to keep an eye on on what's going on with the upgrade and hopefully do a wrap-up afterwards as well, maybe. Right. I'm I'm so I'm so sad that I cannot be uh at ETH Clush. I I really wanted to go. Um but unfortunately I have a scheduling error. So um I I really wanted to go but I I hope that I I could help in in in this way and um Well, definitely. We really appreciate it. Next next year I will I will I will go I will be there. Yeah, it's just the first main event and either way we have plenty of others during the year. So if you want to just visit Cluj and you know pop over for for a nice Ethereum event as well even though it's not the main one please feel free to to reach out to us and yeah definitely welcoming you for for next year and next years to come right so don't worry about it it's all good we actually we actually appreciate that uh we have also you know like a bit more knowledge sharing uh happening even before the conference event because In the end, I mean, we're uh we're having initiatives all throughout the year, and I think it's important to to not put the pressure all on on the main event and make sure that, you know, we're building brick by brick. So, all good here. All right. All right. Has everyone managed to to scan the po? Yeah. Good. All right. Well, thank you so much again. Thanks everyone for joining, taking the time to to talk to us and ask questions. And guess we're going to see you on the next one with Bianca. Yeah. See you in a few weeks. Bye. Bye. Bye. Bye. Take care.