All Core Devs - Execution #237

Transcript

Gary Schulte: Good morning.

David (dionysuz): Hello. Good morning.

Justin Traglia: Good morning.

Nixo: Morning.

Okay, I think we are good to get started. David, are you streaming today?

David (dionysuz): To my knowledge, it was Josh, but I could. Just, I'd need, like, a minute, yeah.

Nixo: Okay, that would be helpful, because it doesn't look like Josh is on. Thank you.

David (dionysuz): Okay, yeah, give me a sec.

Nixo: No, we're, we're waiting just a minute, to get streaming going.

David (dionysuz): Yeah, sorry, just give me a sec here, this setup has changed for me for some reason. Yeah, maybe, like, 30 seconds, let me see here.

Nixo: No worries, thanks for stepping in last minute.

David (dionysuz): Okay, I think maybe this stream… I can't set it up for some reason. Maybe we'll just record this regularly with Zoom for this one?

Nixo: Okay. That works, and then we'll just upload it afterwards.

David (dionysuz): Okay.

Nixo: Okay, let's get started. Welcome to ACDC… ACDE237. It's May 21st. We're gonna start with Glamsterdam, DevNet updates. Barnabas, do you have, DevNet updates?

Barnabas Busa: Yeah, I've been looking at, answering DevNet 4 launching, We hit a few bugs here and there. I've been, reaching out to the different CL teams regarding that, and hopefully everything will be ironed out by end of today, and we can launch DevNet 4 today. We currently have only 2 years, ready to go. That is, Nethermind and ethrex, and on the CL side, we have Prysm, Lodestar, and Lighthouse. And, hopefully Nimbus as well. I haven't tested Nimbus yet. That is about it for Glamsterdam Telescope.

Nixo: Great. Next up, we have a BAL spec update. Tony, do you want to talk about the 7702 delegate inclusion on failed calls?

Toni Wahrstätter: Yes, happy to do so. Let me quickly post a link into the chat, such that everyone has… And kind of look at the… update that we did to the EIP. So the TLDR here is we clarified one edge case around 7702, and basically, it's about, the delegation address is only added to the bar once. We pass the gas check, the value balance check, and the stack-too-deep check. So… Otherwise, like, if those checks are not passing, then only the original caller Or the call target, to be precise, is added to the ball. And if those checks pass, then the… The delegation address is added to the ball, too. And… I think Ignatio brought that up, so thanks a lot, Ignacio.

For bringing this up? No, I think someone else, sorry, I'm now confusing names. Maybe someone can correct me. But anyway, this is the new, spec update. Maybe Felipe, if he's on the call, or Rahul, they can tell us if all the clients are already passing the new tests that we rolled out together with this change. But it's a… it's a small change, and should be fine.

Felipe Selmo: Yeah, I can… I can, I haven't checked against all of the clients, whether they're passing or not. I'm running locally right now just to check, but to answer Karim, in the chat. It was already merged in and updated in a test. I can put the… the test name here, so, yeah, so basically, the… The edge case this created was, mostly for the value, so if this is a value call. We don't have to load the 7702 delegation, stack-too-deep cannot be reached with the… Transaction gas limit. And so this… this would have been another edge case, but we… we would… we don't… we can't really test this, this boundary. That wouldn't really, be a case. And so this is mostly for a call that doesn't have enough funds

For a value transfer. We used to touch the account anyway if it had enough gas for it. But now, if you don't have enough balance, there's no use in touching it. And so… Yeah, I want… I guess we wanted to see, like, where clients stand on this, and if this changes… if we have a consensus on it.

Nixo: Ben?

Ben Adams: Depending… So, I, I'm for it, but, depending on if everybody passes, then it's fine. If they don't, then I assume it would have to wait till the next cabinet to be included.

Felipe Selmo: Yeah, that's fair. I don't expect everyone to pass this. To be honest, because… We had… this… I believe this test was added recently? and then the spec changed, and the expectation also changed. And so if clients were aligned already, and I know, I think, Reth was… was one of them. then this spec change would have… would have broken those assumptions. So yeah, maybe we… we should put this in the… in the next DevNet. Dragon?

Dragan Rakita: Yeah. We are probably going to have, clients failing this, because it's, like, it's a bigger change. Depending on implementation, I think all clients should check that. Basically. It makes a difference if you check the… if the caller has enough balance to transfer account. In this frame, or the another frame. And basically, we did do this, in second frame, not before. So, plus, it becomes slightly… Unnatural to do it in, like, to check if the coal gas is consumed, then load the account later down the line. So, yeah, I would like to have it as the previous, like, when we spend the gas for the loading of the count, that is the place where a count needs to be loaded.

This… if we delay this for another frame, that's basically what's assumed here. We are basically breaking that notion that spending gas, it's going to, like, trigger the action that needs to be done. It… yeah, I think the client should, like, take a look at their code and check how they basically do this.

Nixo: So is the consensus that we are not going to have this in the next DevNet?

Dragan Rakita: That's, I think, definite, yeah. But I think even, like, do we want even to include this? This is basically the question. I think, decision is, do we want to include it in… I think next DevNet's going to be Glam DevNet 5. If you want to include there or not include it at all.

Nixo: Felipe, do you have, Yeah, do you have any, like, resources or write-up about it? About the necessity of it?

Felipe Selmo: Yeah, no, there's not really a necessity of this. It came about, like, more recently in… been another implementation, so, I think Ignacio opened the PR to our spec, but, there was another implementation recently that, Kind of wanted to go this route, and it kind of made sense, but Yeah, I don't… I don't really have, Like, any… I don't… I think I can see both sides here. I don't really have any write-up for any necessity or anything like this.

Nixo: Tony, do you have, a strong opinion for this, being… necessary?

Toni Wahrstätter: No, I don't have a strong opinion on it. Yeah, I mean, if we… won't find any agreement today, I would just propose we… I open, like, a thread on the Block Access List Discord channel, and we move the discussion there, and we come to some agreement. I… Don't have any opinion on it. like, when to best do it, and I would let, clients decide. What they think is the most efficient thing to do here.

Nixo: Okay. Great. If there are no other opinions here, then I think the move is, this is not going in the next DevNet, and whether or not it's going in, any future DevNet should be discussed in the block-level access list channel. Yeah, and if all of the clients can take a look at that. Thank you. Next up we have an update on 7904. Maria, are you here?

Maria Silva: Yes, can you hear me alright?

Nixo: Yes.

Maria Silva: Right, so, I just wanted to give a quick update based on, the latest numbers we are seeing from benchmarking compute operations. So for context, 7904 is the compute reprice EIP that is Aiming to reprice all operations that are performing worse than 100 million gas per second. And… up to this point, all clients with their current block-level access list optimizations are already performing at these, targets. So this means that likely we won't need to do any repricing for 7904. The reason why I'm not doing any changes yet to the EIP itself is because, Specifically, Nethermind and Geth have a different codebase implementation for balls between BAL DevNet 3 and BAL DevNet 7.

And we've only started now to do benchmarks on BAL DevNet 7. We have early results for Nethermind that are looking good, but we still miss, Geth. And so before, just making sure that all the clients with their most current implementations are performing at this target, which is very likely, but we need to double check. then the likely scenario will be that we don't need to include this EIP anymore in the fork, because essentially all clients after the optimizations are performing at already the desired target. So, I don't think there's any to-dos now in terms of, moving the… the status of the EIP, because again, I would like to beef… for sure that this is the final resolution, but I just wanted to highlight this, because it's the likely scenario at this point.

Nixo: Wow, removal of an EIP, that rarely happens. Okay, so, 7904, likely not going in, but not moving status right now. So, clients should not put effort into that at that… at this point.

Maria Silva: That is correct, and I think for the community as well, because we already had some people looking into, how their contracts would break with these repricings, it maybe should likely put a pause on that work. But yeah, likely the final EIP status will only I be, certain after… at the end of the month, most likely. So, yeah, just to be double sure.

Nixo: Got it. Might be worth it to put a notice on forecast for that, just a note for the protocol support team. Okay. Any other… Glamsterdam topics. Great. Then we will move on to Hegota. We have 3 EIPs being proposed today. We'll start out with, Weihan. Do you want to start with the 8188?

Wei Han Ng: Yeah, Holwood. Present my screen, so… Wait, just to double check, can you see it?

Nixo: Yes, looks good.

Wei Han Ng: Cool, yeah, so it'll be a quick presentation. So, today I'd like to propose, EIP8188 state tiering by write age, for Hegota. So, hopefully this proposal helps to solve some of the problems that we have, for state growth in the short to medium term. So, yeah, let's get into it. If you are not already aware, right, you should. Basically, majority of the state right now is inactive. It's about 80% inactive state, and only 20% active state. So, ideally, we'll want to, deal with this inactive state, as early as possible, and carry of it, which is… which would help with, the problems that we have, with state bloat, in the long run. So, the gist of this EIP is actually very simple.

So, basically, we will add an additional signal, or additional metadata. So, the first step is that we introduce this new concept called period, where it's basically… it's derived from blocks, so you can think of one period as… for now it's 6 months, but it could be 1 month, it could be two months, depending on how we change the parameter. Then the second part to that is to add this period metadata for accounts and storage slots. So for accounts, the RLP changes because it's already a list, so, adding an additional field is simple. for storage slots, it's slightly inconvenient, because you have to change the encoding format for RLP from byte string to this, but it's not… it's not gonna break anything, it's just an additional check when you decode these two different versions of storage slots, so I wouldn't say it's…

It's an impossible task, or it's something that is going to affect performance. Correct me if I'm wrong. And then the final part is to have, different, state. tiering of different gas costs, particularly for writes, when, basically, when you write to the inactive state, it will cost more, and then when you write to the active state, it will cost less. So, some form of hot-cold storage separation. So, yeah, that's basically the… really the summary of the EIP. So, what, increments the period? Basically, write operations or any state modifications, would increment the period of the accounts and storage slots, so it doesn't affect reads. In terms of the gas cost, it's also… it will only affect, writes as well.

So… Yeah, because if we do consider reads, then reads I mean, if reads bumps the period, then it effectively becomes a write operation, which would have different edge cases and also cause, more write amplification for the… for… for some operations, so that's why, we wanted… wanted to keep it simple and just do it for writes. So, why do we want to do something like this? Well, having the… this signal, or this metadata, would allow different, things for the EL clients, but the foundation is basically, hot-cold storage separation, or separation between inactive and active state. So, for example, in LSM clients, Geth, Nethermind, Besu, and ethrex, you can extract out your inactive tries to an immutable flat file.

And then you can leave, references, to the inactive subtree or inactive tries in your main LSAM database. So effectively, your main 7 dB would see a much smaller DB size, and which would help with overall access, performance, and also compaction time. For Erigon, I think this EIP fits very well with what Erigon 3 already has, because Erigon 3 already has some form of hot-cold storage separation, where the entries in the database are actually moved into immutable snapshot files periodically. So I would say it already fits what this EIP wants to do. for F, I think with the modular architecture, it should be simpler to do some form of storage separation. I also see comments that you guys are experimenting with, or not really experimenting, but already have it in production, I'm not sure, with RocksDB.

So you could, for example, just an idea that you could put the active state into RocksDB, and then put the inactive state into MDBX, because theoretically, MDBX is… better for reads. So, this is an idea, but the foundation, again, is to have this storage separation. So, just to elaborate on the point, on the LSM clients, because that's where I did the prototype. So, on the left side, in today's status quo, you have… you store all the tries in the main LSMDB. So. effectively, you can separate them out, where in the live… in the main LSMDB, you would just store the references to the data in… in some immutable snapshot file. So that's one of the ideas that

We have, and that's also why, what we did for the prototype. So, in this prototype, we basically see a 78% of data reduction. Yeah, after running… after replaying, one year worth of Minet blocks. In terms of performance, the final numbers are not, out yet. We are still ongoing, but for now, we are looking at, overall speedup across… all across the benchmark metrics, which is expected, because the main database size is smaller. So, that's that, and then, some… questions that some people might have. So, in terms of metadata building the state. In, with the given state size that we have right now, the worst case is about 3.4GB, if you consider one period as just storing as 1 byte.

So there's only 3.4GB, which is not a lot relative to the state size that we have. But in terms of real world. I mean, in our prototype, it's actually… we only see, like, 300 megabytes increase in state size, because only the state that, got touched or got modified would actually add this new period. So, yeah, in real-world scenario, we… the metadata blow is actually negligible. Why not state expiry? state expiry is good, but… It's blocked by… mainly because of UX, mainly because we need a decentralized resurrection infrastructure where it can guarantee all users to resurrect their data, which doesn't exist yet. So this EIP is somewhat a compromise and helps to solve some of the problems, but without the,

the cost of user experience that state expiry has. It's also compatible with future tree migration, because we are adding the metadata to each of the accounts, and also the storage slots, so that means, if we move to some sort of page-based layout, then it will aggregate to the page. So the final, I guess, pitch is why Hegota and not later? So, first, it's a relatively small EIP in terms of the, changes to the state. We are… we are changing the RRP encoding. so there would not be any tree migration, there would not be any resurrection, and no whatever networking layer changes. So, yeah, so I think it's a really, really simple change to the state.

Second of all, we would like to have the metadata accumulated as early as possible, because we don't expect that clients already have the database optimizations ready when we have this fork. Clients can work on the database optimizations while the metadata accumulates in the protocol. So, so, yeah, that's… that's that. And if people are concerned with the pricing complexity. We… there is an option where we can defer the pricing to a later form, depending on the parameters that we set for period. For example, if we set periods as… one period as 6 months, then the… this entire active and inactive state separation will only kick in after one year, for example. So, we can actually defer the pricing if… if that's people… that's what people want, and we can also do more accurate benchmarks to set the parameters right.

So in regards of that, there is one possible alternative. to this EIP, which is just… we can just record the metadata as block number in Hegota, and then we can decide the gas pricing mechanism later on. So it would cost four times more, in general, 4 times more bytes in general, than just storing periods. But it allows us to be more flexible. So one example is that if you store the metadata as bulk number, then we don't do any gas changes. later in the future, we say that, oh, if, we decided… we decide that if some state hasn't been, modified for, before this block number, then we consider it as inactive, and then we charge some number of guests. So…

Yeah, that's… that's one flexible thing that we can do. So, yeah, that's pretty much it for my presentation, and… I'll be happy to discuss more and also answer some questions if anyone has.

Nixo: I think we have a few questions in the chat if you want to address them now, we have time.

Wei Han Ng: Let me see, I think the reason why is from Barnabas, I think Guillaume really helped me to answer that, Would reading pricing change? No, because it only affects writes. I think it's also a debate, like, whether we want to have reads also modify the metadata, or whether we want to also include metadata for reads as well. In the initial design of this proposal, we did consider reads, but considering all of the edge cases that we have, ultimately went with writes. But if people are willing to accept the trade-off that reads also updating their metadata. then we can go with reads as well. Yeah, it's a different set of trade-offs.

Nixo: Andrew?

Andrew Ashikhmin: Yeah, I think it's, it's a move in the right direction, it just, aligns with, you know, with Alex's thoughts on three-prong scaling of Ethereum. So, we are scaling EVM execution with ZK, EVM, we are scaling blobs, and we are scale… and we need to scale state with new forms of state, and also optimizations like this one. So yeah, I think it's a good idea.

Nixo: Peter?

Peter Miller: So, a couple of comments. You've mentioned that you are changing… that changing the, structure of the account structure is simple. I think it is worth pointing out, that, no one has ever changed the tree in any way in the 10 years that Ethereum has existed for, and so I would want to, like, be a little bit thoughtful about whether that might break things in ways that, we haven't anticipated, because unlike a lot of things in theorem, we have never changed this. I'm also a little bit curious about your thoughts on, recording how long since… Something was red. Because if we had some data that we knew, hadn't been read in ages, and we were going to charge a first read fee.

We'd… you could then potentially store it on a hard disk drive. Which would be considerably cheaper. So… I wondered when you'd consider that optimization. Which would be the other possibility, rather than this system where you just record rights.

Wei Han Ng: Yeah, thanks for the point on the… on the, like, the security side. I think, definitely, we would have to do more investigation on… on whether just changing the account RLP or even the storage would break other things, because on the… at least from the client codebase level, I don't see it yet, but on the other parts, maybe there are things that would break. I think on the part for reads, again, I mean, I'm happy to see the debate here on reads. But in essence, if reads update the metadata of a state, then ultimately it becomes a write, because it will also affect the state root. then it cascades into, like, you know, you have to charge… because now it becomes a write, you have to charge the write gas costs for reads. Then there are a bunch of other… other consequences as well, like, every period or every… every cycle, people have to pay this expensive operation. Like, some guy would be very unlucky to pay this.

So yes, it's nice to have, if we can consider both reads and writes, and then if… because then they would truly be inactive and not just writes, then we can store it in the HDD and archive it and, you know, compress it or whatever. But, Yeah, I think, like what, Lukash said, turning HV into Write will backfire, but, you know. Yeah, it's worth exploring both. Scenarios, but yeah.

Nixo: 8. Thank you so much, Han. Okay, we're gonna move on to, EIP8182. With Tom.

Tom Lehman: Hi, everyone. Thank you. Oh my… Okay, sorry about this, my Zoom for the very first time. I have to quit and reopen, sorry, I'll be right back.

Nixo: No worries. We'll wait just a second to see if this is fast, and if it's not, we'll move on to the… Next EIP.

Marius van der Wijden: Yep.

Tom Lehman: Okay, my apologies. Let's do it. Okay, so, I'm Tom Lehman here to talk about EIP8182, which brings private transfers to Ethereum. Okay, so why do we need private transfers? You know, I'm deep in this. To me, this is just, like, staring me in the face every time I look at Ethereum. We are in a crazy situation right now, which is Ethereum is settling hundreds of billions, trillions of dollars worth of stablecoins alone. And everything, basically, is public, right? So, if you have a financial system, and I think, you know, Ethereum wants to be a leader, right? A leader in terms of infrastructure for global finance, it's like. no financial system has everything, public, and this, to me, makes Ethereum even hard to explain to someone.

hey, you've never heard of Ethereum. It does all this finance stuff, but everyone knows how much money you have and when you get paid. Obviously, many people have called for this to change. Vitalik is one example. Last year, you know, let's just make it easy to send money privately in wallets, and that has not happened. And so, why, and then what's the solution? So. Why? Why is the app layer not going to solve this alone, in my opinion? So, the big issue is that you have this notion of an anonymity set, which is like, you know, everyone here understands, it's like who you're hiding among when you're transferring. So, the more, value and the more people in the anonymity set, the better your privacy and, you know, the less, the worse. And so you have this chicken and the egg.

issue, which is you need users to offer privacy, and you need privacy to attract users. It's very, very hard to build an anonymity set, and it is extremely sticky, and so it's hard for competition over building an anonymity set to produce the best product, because it's hard to, you know, build this anonymity set, and so even if you have the best features, you might not be able to compete with the incumbent, and also So competition is bad in the sense that the more competition happens, the more the anonymity set is split between different products. Competition, overbuilding an enemy set isn't good, it's not going to yield the best product. Also, we have a trust issue here, which is, since we depend in a privacy context on this big pot of money, it not only has to be built, it has to be governed. And there are two approaches.

make it immutable, Tornado Cash, but then when quantum risks happen, you can't upgrade the cryptography. Everyone there on Tornado has to either withdraw or lose all their money once Q-Day happens, or you can make it upgradable in the Railgun model, and then how do you governments, maybe you have some token, and how do you, you know, get wallets and, you know, big financial players to evaluate the security of a token? Very, very hard to do. Ether has a very good security model, and sending Ether privately should have the same thing. So, the split here that I'm proposing is you get apps out of the business of building anonymity sets and governing them, and competing on this basis, and you let them build the stuff they're going to be good at, which is UX compliance, proving, relaying, and all these kind of things. So this is how 8182

approaches it. So what literally are we talking about here? We are talking about a system contract. Okay, a lot of different ways you can do privacy. and even a lot of different ways you can structure, you know, the anonymous set and the storage and your actions, but this takes a very pragmatic and very simple approach, which is one system contract, the entire EIP is about taking some state and some storage and putting it in this account, right? That's it. There's no other… there's no pre-compile, there's no change to the internal logic of the client, nothing with, You know, the protocol-level store, it's just changing one account. This is a UTXO-based shielded pool, not so different from something like a railgun. This is not trying to be massively innovative on the side of, you know, cool construction. It's trying to innovate in terms of building and securing the anonymity set. So we're doing something reasonably straightforward.

The one twist here is that the pool does not prescribe any specific authentication method. And the reason for that is that's really hard to do, to say, hey, on a protocol level, here's how everyone must authenticate. People want to authenticate in different ways. And, because of that, users are allowed to bring their own authentication, and so this keeps the, protocol-level proof or a verifier, quite simple, because it's only enforcing, you know, things like value conservation, whereas authorization happens, through per-user chosen, verifiers. So anyway, quickly, not to go through all of this, but, like, this is the basic idea. So this illustrates one particular case, which is, using an EIP712 signature as auth. So, you know, one question with, ZK stuff, right, is like, how do you do a proof on a hardware wallet? And so this is how we, solve it in 8182. You have the hardware wallet sign, create a signature, you know, via EIP712, or whatever you want. You take that signature, you send it to your computer, your computer constructs the proof.

But the computer can't actually… the computer's private key material can't actually, spend the money. So the authorization happens on the hardware wallet, the proof happens, and then when the proof is verified, you have two proofs that are verified. One that verifies your signature through your chosen-off method, and then the other is about the, single global pool. verifier, so… can go back to that if people have specific questions or want to get through it. So, what do you got? Okay, so for one thing, it's very, fast, to prove. This is, something that's gonna work on mobile, but it's probably not gonna work on a hardware wallet, which is why, we have this, credential-proof separation, where you don't have to, create the proof on the thing that authorizes the spend.

You get the synchronous L1 composability that you want, which is the ability to shield, swap, and reshield automatically to make decisions, and decide whether to shield based on EVM execution, and so forth. So this flexibility, you've probably seen this in something like a Railgun, you get this. And then you get a minimal core, which is basically as little as possible is enshrined In the protocol And then, here are some risks. So, the pool, proof system, Groth16, BN254, so… This is a very pragmatic, simple, fast, cheap choice. It does require a trusted setup, as I note below, but it's not post-quantum. And so, the, this will have to be swapped, and we've planned for this because the,

the bytecode for the verifier is within the system contract, and so you can swap out the code of that system contract, create a new verifier, and in doing that, users aren't going to have to migrate or do, anything. This is just a one-time swap, and, you know, don't want to downplay the seriousness there, but I think the architecture is well set up to minimize the… The pain. On-state growth, of course, this is, standard stuff, right? Each transfer, you get, unprunable state nullifiers. And so, you know, one question is, should this be stored in some other place, right? And, I think maybe, down the road, once we, have a better handle on situation, but I think that, for the moment, I don't think that's such a good idea, because I think if you keep everything

in the EVM as the place where, you know, value transfers happen. You get compatibility with, you know, existing tools and mental models of people, but you also get this nice synchronous composability functionality. It's not clear exactly what you would use from taking it… what you would lose from taking it out, and so this is kind of, like, part of my overall thesis here, which is we have to worry about scalability, and dealing with tens of thousands of transactions per second, but we also have to worry about getting people to actually create a ton of transactions, and so making the feature, you know, as simple and intuitive will help with that. But this could be changed.

In the future. There are… there is the potential for bugs, so this is scary, right? Like, what if there's a soundness bug? the mitigation here, to the extent that you can mitigate this, is A keeping the circuit simple, the single circuit simple, and then B, using this contract setup where we can just guarantee that any problem is going to be scoped to the money in this particular account, this particular smart contract, which is still very bad, because losing all that money would be extremely bad, but it's less bad than, you know, printing unlimited Ether, for example. And then there's gas costs, which are, you know. basically similar to, you know, something like a railgun, a little more expensive, and could be mitigated if we want with a pre-compile on Poseidon 2, but I don't think that's really necessary. The gas limit's going up a lot, and I think the costs are currently

Very low. So… this is the big missing feature, in my opinion, but I think it's, you know, and Barnaby had a nice tweet about this, I think if you look at the straw map. what you'll see is a lot of supply-side work, right? As I mentioned a moment ago. How do we deal with incredible growth in usage of Ethereum? And, I just want to put out there that we should also really think about getting that growth, about getting the users, about building stuff that will make a lot of people use Ethereum. And I think this is one of the best things that we could do to do that. We are already doing a lot of stuff to be better supportive of privacy. I mentioned some things here. Let's not stop before we do the thing that will actually literally enable it to work, which is a private transfer protocol itself. So.

that's 8182, and my ask is, Hegota, or whatever's the soonest possible, for, because I think this is a big emergency in terms of, increasing the value of, of Ethereum, and also giving people, you know, the ability just, you know, to, to… do a very basic human thing, which is send some money without having everyone know. So, So that's 8182, thank you all, happy to take questions.

Nixo: Any questions? Feedback? Peter?

Peter Miller: I want to understand why you want What you want from, like, the protocol on this? Because what you seem to be saying is that you want to deploy a special contract at a system address. But even when we want a special contract, like the deposit contract, we just use the, normal mechanisms of… Contract deployment, and then go, this contract is special. So, couldn't you just achieve this by deploying this contract, using a standard method of Making a contract appear at the same address on every chain. And then just get everyone to agree that it's the special default thing we use.

Tom Lehman: Sure, so there, I think… part of the literal mechanics of that decision that you mentioned is, if you deploy it in a standard way, you can't get a super, pretty-looking, all zeros, leading zeros, address, which might sound like a small thing, but it comes together with a lot of other factors here to produce a, a standard, a shelling point where the Ethereum protocol can say, this is how you do it. Hey, apps, don't worry about building your version of this, because this is… this is how you do it. And so, you know, an app could emerge as the shelling point, and that's another strategy. EF or CoreDevs could take is saying, hey, everyone, Railgun is the official one, use Railgun. And so that would be another option, but then Railgun has this issue with the token, which is, you know, hard to say whether it's, you know, how do you know whether that's, like, a safe arrangement or what the risks are, exactly. So part of it is creating a standard and a shelling point, and that is, I think a very valuable thing, even if the literal technology of, like, what goes in this contract could be.

Put there by anyone. And yes, I think there is a meme about unifying standards, but it is not guaranteed that… I mean. the current approach is not guaranteed to work, is kind of my, other argument here. So if you think the current approach is guaranteed to work, then that is a good argument, but if you look, you know, if you look at it from a pure philosophical standpoint and say, well, you know, an app could, accomplish these things if it, you know… I think, A, an app can't accomplish what we're talking about when it comes to security. An app cannot be, something that is changeable and also not subject to the governance of some, token or otherwise small group of people. And B, on the standardization front, I don't think… I think the argument is it's not going to happen the way we want, in the timescale that we want. So, depending on the priority here, which I think is very high, we should consider, you know, other options, and then, you know, the safety factor is just

One thing on top of that that apps can't, provide that the protocol can.

Nixo: Enough.

Milos: Yeah, so just a quick question. Does this allow withdrawing, ETH to a brand new account? In that case, who pays for the gas? And how would that work with a public mempool, and does it work with a public mempool?

Tom Lehman: Right, so good question. So, right now, keeping things minimal, not trying to, like, innovate tremendously, although we could change this and do that on that, the way it's set up now is that the protocol has an affordance for a fee that gets paid, optionally, and so the idea would be App Layer would provide a relay-type service, and then people would be able to compensate the relayer using, the, The fee output of the, Of the transfer, but this could be… optimized and, and tweaked also. It's not… the proposal right now is not trying to, do anything, tremendously out of the ordinary, with respect to, like, the relaying question.

Nixo: Come on.

soispoke: Yeah, I mean, I said it in the chat, but… and we've already had, like, some discussions with Tom, but… Yeah, in my opinion, I think it's, it's a bit too much too soon, and I would worry about, sort of, like, enshrining this big pool with one single design, with, you know, I don't know, one of the questions, for example, is, like, the cryptography, right? Like. if we're saying we are using Poseidon, like, do we risk, enshrining something with cryptography that's not secured enough? And so, I don't know, it comes with, like, a lot of questions, so my… take is that it's a bit too early to enshrine the whole thing, and I'd rather, like, enshrine primitives that let, you know, privacy transactions be trustless and native,

But still allow for, like, different apps to come up with their own design, until, you know, we get, a lot more confidence on, like, what's the right design. Otherwise, we're gonna have to upgrade ourselves, via ACD governance, and we know it's not the most, let's say… A quick, way, to, to just, like, upgrade and iterate and sort of, like, innovate on, on, on, on… yeah, a bunch of parts that compose this CIP. So, yeah, I think the intent is really good, I think… I mean, I believe as much as Tom that we really should sort of, like, accelerate on making privacy, transactions, like, a first-class citizen on Ethereum, but I… I just feel like that EIP,

Tries to do too much at once.

Tom Lehman: I think it's a fair point, you know, I would just say two things, like, one is that it is… the benefit of this is very hard to see, because the benefit relies on, like, increased usage and new people using it, and we can't go out and meet those people right now, because they're not using it, we don't see the transactions. The costs are really easy to see, right? Which is all the costs that you mentioned, like, what if there's a literal cryptography issue in the actual cryptography here? And so I just would say that it's… there'll always be more straightforward reasons to delay this, and I would just say, for everyone, if you're thinking in these lines, at least force yourself to put a cost on delay. Don't put yourself in the position of, like, a delay is… is super low cost, because I think a delay is high cost, and there are also risks. And then in terms of, like, the,

the making decisions, I think. you know, I think the Ethereum Foundation, at least, is in an interesting position because, you know, Kohaku is being developed, a lot of pro-privacy stuff is happening. You, yourself, have tweeted a lot of very important, you know, pro-privacy things, and so I think if the punchline of that is, here's all this positivity around privacy, but use this app layer stuff because we don't know what is secure, so we can't be responsible for it. It's like, if the answer is we don't know what's gonna work the best, then we should be telling users, don't use any of these systems, basically. Otherwise, you are going to, you know, end up in a situation where maybe these

bad things come true, and all we can say is, well, users lost a lot of money, but at least it wasn't, you know, our direct fault. And so, another thing to think about. But yes, this is a, certainly there are risks with this. I appreciate it.

Nixo: Okay, Ben, and then we'll move on to the next EIP.

Ben Adams: I'd just like to point out that I think the difficulty of doing an upgrade via ACD, and it being a complex and… long-running process with forks and so forth. It's almost a feature, because It will need to be upgraded at some point to, like, a post-quantum scheme. And the alternative would be, alright, well, it's got to be a proxy contract, and now you need the governance, and if… you don't want everybody putting all their money in something with weak governance.

Tom Lehman: Yes, I… 100%, and that's… kind of where we are now with Railgun, the closest thing, it has a token, and what is the security there? But yes, just to be clear, maybe I glossed over this, but the idea would be, if you want to upgrade this thing, you can, but you have to go through what we're talking about now, a hard fork on Ethereum. And so, not to say that a hard fork on Ethereum is, like, easy, or good, or gonna, you know, get the best results, but it's just an already built-in assumption that we have for upgrading, where if you want to change the way public ETH behaves, you have to do a hard fork if you want to change the way private ETH behaves. You should also have to do a hard fork. It's, like, kind of this parity thing. Not to say it's absolutely best, but it's about, you know, parity and doing things people are, you know, understand, and risks that people are already… relying on risks people are already taking… taking.

So yes, appreciate that comment.

Nixo: Thank you, Tom. We will move on to EIP-4758, Deactivate Self-Destruct. Peter, are you here?

Peter Miller: I am here.

Nixo: Great.

Peter Miller: Can people hear me?

Nixo: Yes.

Peter Miller: Okay, good. Hello everyone, I would like to, say we should get self-destruct. So, a little bit of history for people's reminders. Self-Destruct has been deprecated for a long, long time. We decided ages ago, that we didn't want it around, that it caused annoying problems. And… It was a mistake to happen in the first place. So over the time, all of the main, features of self-destruct have, been neutered, and indeed, a while ago, we disabled self-destruct, unless it's… in the same transaction. So if you create a… if you create a account in a transaction, you are then allowed to, break… you are then… you will self-destruct during the same transaction, the account will be self-destruct at the end.

Which, is a lot simpler than the previous version of self-destruct, because this means you only… You don't… it never gets written to the DB at all. The remaining users of this, like, there really aren't very many. And self-destruct, like, is one of these things that it just turns out to be really quite annoying. So there was a bunch of discussion during 8037 about how do we handle self-destruct during 8037, and similarly with 7708, there were some edge cases of transfers involved with self-destruct. That, again, just turned out to be annoying and creating complexity. I'd… Then there was a discussion about, do we want to change self-destruct further? And I'm proposing that we CFI the deactivate Self-Destruct EIP. VATIP says.

that we take self-destruct, we remove all the self-destruct functionality, and we retain only the send all function. So when you call the self-destruct opcode, it does two things. It marks the account to be self-destructed, and sends the entire Ethereum balance of the contract somewhere else. We get rid of the first one of those, and we retain only the sendAll function. This is currently the case. If the account self-destructed wasn't created in the current transaction. So we are literally taking an if statement, and we are deleting it. and now you… it always is the sender. It's an extremely technically trivial change, it's only going to make things simpler. The problem is… that there are a small number of users who still use Self-Destruct.

And those users, we don't really know very much about them, and It's possible that they will experience breakage. Now, and, last ACD, we had some data from PAL, who looked at, the last 5 million blocks Worth of self-destruct data. And he discovered, that the vast majority of self-destructs the account self-destructs. It's created in a transaction, it's self-destructive in the same transaction, and then it's never touched again. This won't break anything, because it just… the only difference is that now. That account that's been created will sit around forever, rather than being deleted. And that's fine, it's not going to break anything. There are a small number of, of contracts and transactions where The account gets destroyed in the first

In a transaction the first time around, and then someone creates it and re-self-destructs it again, potentially multiple times. These transactions, if we were new to self-destruct, will fail. But we think that based on the complexity that self-destruct is causing, and, like, the level of Nuisance, that we should neuter it, we should neuter it anyway, and we should try and find out whether we can persuade the people who are relying on this functionality, to stop using it. The problem with this is that we really need to, like, signal a long time in advance Because, you know, we're potentially going to break things, we're also gonna have to do a whole bunch of investigation to work out, you know, whether the amount of stuff we break is acceptable.

So what I'm suggesting today, is that we, PFI, propose for Inclusion, this deactivate self-destruct EIP. With the goal that we will, then have a long time, both, to signal to people that if they're reliant on this functionality, that it's going to break, and also to free up people who have to go and consider in the EIPs, what do we do about self-destruct? To, not have to think about it. The other… I would also be interested in hearing from people who have opinions about this, of what level of investigation they think they would need to be satisfied that neutering self-destruct is safe from a breakage point of view, as well as, like, getting it PFI today.

Thank you.

Nixo: Thank you.

Guillaume Ballet: Yeah, so, a lot of to unpack here. In answering the last question, there's, like, there's no investigation to be, to be made, really. It's a fact, it will break some use cases. I am aware of two. One of them, I don't remember their names, but it was found by D-Dob, so, when we did 70… sorry, 6780, I think that was the one that deactivated self-destruct, except in the creation transaction. DDOP did an analysis, and they found someone, a second project that was doing this. I have no contact with those people, but I can try to see if DDOP does. Regarding the second use case, this one is called… there was an NFT project called Rivest, or Rivest, I'm not sure.

I talked to the guy in 2022, so that's pretty old. I have been trying to look for them before ACD. I couldn't find any mention of them, so it could be that the project is dead in the water, and if that's the case, then it's excellent. But, I mean, sorry for them if that's the case, but I mean, it's good for us, because we don't have to worry about this use case. But, yeah, like, what the guy was telling me, back in 2022 is that their contract is not upgradable, so you will never get them to, to agree, to completely disable self-destruct. Now, yeah, the question is, do they still exist? But I can confirm that, this contract still exists, and potentially some people

rely on this to, to spend their NFT. It's a very convoluted, process where, I mean, the guy explained, and honestly, I don't remember, it was very convoluted. But the fact is that, yeah, there are people depending on this, and it's going to completely break their use case, if that's, if that's the case. Now. Personally, I'm happy to deactivate it, but, yeah, we need to talk to those two people, and I think that's whoever manifested themselves last time we tried to deactivate it.

Peter Miller: Yes, you've reminded… so I've actually had, a look at, the data, so I've been looking at the CSV that Powell produced. I… I have identified, over the last 5 million blocks, there are 162, contracts that recreate a self-destructed account. Multiple times, and thus, might be broken. The vast majority… the most common one of these appears to be one, that, transfers… that calls, does an ERC transfer from init code. So they have an address, they want to transfer away stuff from that address, and so they, call it in init code. So yeah, but I agree with Goo that we definitely will break stuff. And,

You know, these people who have these contracts that are repeatedly self-destructing will only be able to execute that transaction one more time after this goes live, because the next time they try to create the contract, it won't have been destroyed. And I would be… Yeah. I mean, is this something we're prepared? Because if the position is that we're never prepared to break anything, then this can't happen. But what is the threshold for, breaking stuff?

Nixo: Spencer.

Spencer Taylor-Brown: Hey, yeah, I think, I'm definitely quoting others here, but my understanding is that self-destruct has been marked as deprecated, like, 5 years ago, so… People that are still using it? Like, why are they still using it? so, like… I tend to be quite trigger-happy in general. And… So my gauge would be that we just… Yeah, remove it. And if people… that are still using something that has been deprecated for so long are upset. Like, why have they been using something that's been deprecated?

Guillaume Ballet: I mean, the contract itself is pretty old, the one I know of, so… you know, those people, they signed up into this NFT program, they still want their NFTs to work. That's, That's why they still use it.

Peter Miller: Yeah, the problem here is that people, built weird things. With self-destruct. And, you know, now… they, you know, we want to change this, and their things depended on self-destruct working. I mean, historically, people used to, have upgradable contracts where the contract was, you know, could be created with Create 2, and then could later self-destruct and be replaced with a different contract? There we had, I think, a clear upgrade route, because people could switch, could upgrade to a delegate called proxy. Yeah, like, is it worth going and invest… so my feeling on this is that we should go and investigate. whether there's enough TVL in the stuff that remains. That it's worth continuing to support this. So as an example, I also looked at whether we could get rid of the call code opcode.

And I very quickly concluded that the answer to that question is no. Because call code… Because call code… there are some call code proxies, so call code is a broken variant of, delegate Call. And there are some call code proxies, that have existed since the beginning of time, and, like, one of them's still in use and has 55F in it. And I'm pretty skeptical about doing that. But if… But the question here is very much one of, like, how much v- you know, how much is destroyed that people still care about and still using? And if it's below a certain minimal threshold. Then… let's get rid of it. But if we're going to get… think about getting rid of it, I don't want to do… because you could say, well, go away and do the analysis, and if your analysis comes back good, then PFI it.

But especially for something like this, where the issue is entirely social and community-driven, I'd be interested in PFI-ing it now. And then that puts a big sign up that we can point people at, saying, if you're affected by this, you need to complain.

Nixo: Okay. Thank you, Peter. Just as a reminder for anybody who proposed an EIP today, please open a PR against 8081, the Hegota, meta. In the proposed for inclusion section. It's also helpful if you go on Forecast afterwards and add the EIP, or update the EIP on Forecast, so that the community can see what it's about. The next, next thing, last thing on the agenda is, Mercy, do you want to, talk about getting client feedback on execution API cases?

Mercy Boma Naps-Nkari: Yeah, good afternoon. So, I have to, issues. One is the CPR. And then, we talked about, this PR on Monday, and we agreed to drop the raw field from the result, and that was due to a security concern, never mind flat. So, I would like other teams to weigh in on it, so that we'll be able to move forward. Then, secondly. Let me grab the link. Is this hackMD? So, in here, I've put together a cross-client matrix of every JSON ROPC method against the spec. For example, we have about 15 meters implemented by 6… 5 or 6 clients thereabouts that are not in the spec at all. So, instead of us to guess which one to standardize, I would like each client team to look at the metrics and flag what, they actually want to be spec'd.

And if, if there is not… if there is some methods that shouldn't be specced, we'll have to drop it. For example, Felix did, point out about, debug standard trees. He said it shouldn't be, spec'd at all. So, for cases like this, we would want to know what we… Can actually specify, and what we shouldn't. Thank you.

Nixo: Great. Thanks, Mercy. That's all for the agenda. I just want to add, two logistics notes. There still is no closing date for Hegota proposals, but, we will make sure that there is adequate notice, either two weeks or a month before closing that. And there was a poll on Allcore Devs, the AllCoreDevs channel, about canceling this upcoming Monday's ACDT, because it is a public holiday in a lot of European countries and in the US. It looks like the, consensus is to cancel right now, but, if you feel strongly about that, please go over there and… Emoji, react to that poll. So, right now, tentatively, ACD… the upcoming ACDT is canceled, but check the All Core Devs channel for any updates on that.

If there's nothing else… Thank you, everyone. That's everything on the agenda.

Toni Wahrstätter: Thanks, everyone, bye-bye.

Pooja Ranjan: Thank you.

Andrew Ashikhmin: Thank you, bye-bye.

Louis Tsai: Bye.

Transcript adapted from ethereum/pm, CC BY-SA 3.0.