EIP-7793: ASSERTTXINDEX Opcode & EIP-7843: SLOTNUM Opcode

Transcript

short-term road map of Ethereum. The three most important things we're aiming to do are scale the L1, scale the L2 and improve the user experience. So 7843 say can help us to reduce the slot length and 7793 add support for encrypted mem pools and front running protection which I would say is a big UX upgrade. So that's going to actually prevent the proposer from reordering it and placing at a different place cuz it's just simply going to be invalid if they were to try and do that. We need to give people a way of doing it properly that's not going to break and not kind of you know force them to do it in kind of a dodgy or brittle way which is going to break in future. And I can [Music] imagine. Welcome back to Penney, the

show where we dive deep into Ethereum improvement proposals and network upgrade. This is episode 150 brought to you by ECH Institute. I'm your host Puja Ranjan and I'm joined by my colleague Akash and Wayin. On this special episode, we have brought not one but two new core proposals for your information. Today we will have an overview of EIP7793 assert transaction index op code and EIP7843 slot pre-ompiled. As we are past Spectra, we

hope these proposals are for Fusaka or a future Ethereum upgrade. To help us unpack these and share what it will bring for Ethereum ecosystem, we are joined by Mark Hill, a developer at Nethermine and author of both of these proposals. Welcome Mark. Hello, great to be here. Thanks Mark for joining us here. As a process, we try to understand the mind behind these proposals as well. So before we get into the proposals, will you please share a little bit about your professional background, how you find Ethereum and your experience in working in this ecosystem?

Um yeah, so I've been working for Nethermine for about a year and a half and in that time I've been involved in various things. So my first big project was around encrypted memples. Uh but I've been working with implementing various EIPs like the BLS pre-ompile fossil. But kind of before that, I've always just been super interested in cryptography, like building stuff. And sort of at uni, I got more involved in like kind of looking into crypto and like I implemented a consensus algorithm and that was just kind of always saw Ethereum is like this really cool project that I aspired to be involved in. And yeah, I just think the whole kind of ecosystem like kind of drew me in like I'm a big fan of like the sort of open source philosophy and the kind

of feels like a really good space where you know you can um kind of share your ideas and and help to build something which really appeals to me. Yeah, pretty interesting ecosystem is continuously evolving. So we love to have new people in, new minds in and new proposals in. I understand we have got two presentations or perhaps one presentation with two proposals. So without further ado, let's just peep in. So yeah, today I'm going to be presenting EIP 7793 and 7843. So these are the assert TX index and slot num op codes. So firstly, I'm just going to give a bit of motivation. So why should we actually care about these two op codes? So we know that the sort of short-term road map of Ethereum, the

three most important things we're aiming to do are scale the L1, scale the L2, and improve the user experience. And I would argue that these two op codes can actually help us with achieving all three of these. So 7843 I would say can help us to reduce the slot length, which kind of applies to all three of these things. and 7793 add support for encrypted meles and front running protection which I would say is a big UX upgrade. So first off we're going to a little bit about the IP 7843 which is a slot num op code. Yeah, it was recently changed from a pre-ompile but I won't talk about it too much now but yeah so basically this is a new op code which returns the current slot number on chain and currently today there are two different ways of doing

this. So we can calculate the slot number from the current time stamp or we could pass a slot number on chain and prove it using the beacon block route. But there are problems with both of these approaches. So if we calculate from the time stamp that actually requires hard coding the slot length on chain. So what we do is something like current time stamp minus the genesis time stamp and then divide that by 12 seconds. So that's actually hard coding that 12 second constant in. And the other approach is just quite expensive in terms of gas. So I think that would lead to people actually using the other approach. And the problem with that is it's quite a brittle approach. It means that contracts will break if the slot length changes. And so I kind of see this EIP as like it's quite simple,

minimal, but it's just kind of taking this lowhanging fruit which can basically like clear the way for changing the slot length in future. I mean, of course, there's a lot of other things that go into changing the slot length. This isn't the only thing, but it's just one sort of barrier that's out of the way. So now we're going to move on to 7793 which is the assert TX index op code. And what this op code does is basically it checks the index of the current transaction within the block. So when I say index say like index zero that's the top of the block and it's going to compare the current index the actual index against the expected index which you pass the op code. And if they don't match each other then the op code will revert. So what this actually allows you to do as a user is send your

transaction and control where it can be executed in a block. And the big application of this is encrypted meles. So I'm going to give a very brief description of encrypted meles. Excuse me. If you want to kind of dig more into this, I I gave a short talk about this which you can see here and I'll share these slides afterwards. Yeah. To briefly explain. So as a user in slot N you're going to submit your transaction but in encrypted form and then all of the your transaction and all of the other users transactions which are encrypted are going to be ordered in one constraint like while they're still encrypted and then in the next slot slot N plus one then we have this entity called the keeper which we don't really need to understand in detail but we can

think of this as like this entity which is basically going to magically reveal the secret key just before slot N plus1 and And then that's going to allow the proposer for slot N plus1 to decrypt all of those transactions that were posted in that constraint and put them all at the top of the block. And basically the way this provides front running protection is because these transactions were ordered while they're encrypted. If the proposer follows rules, includes them at the top of block in the order that they should have been as they were ordered, then there's no way that they could actually frontr run you. But the key thing there is, let's just zoom in on this bit. So this is the proposer including the transactions. So you can see sorry on the left there's the constraint and then here we have the transactions which are decrypted and

included. But the problem is here we're actually trusting that the proposer is is following the rules of the mele right and including them in the correct order. So we can see here imagine this is my this blue transaction here is mine. It should be in the top of block because that was where it was in the constraint. It should be the first transaction in the top of block. But what if the proposer is malicious? they might actually not respect this constraint and they're going instead put my transaction index one and then here they've just kind of added some other transactions around which are going to sandwich in front of me. So that's kind of the motivation here for this assert tx index. So what we can do is in my transaction itself I can call this instruction which is going to assert that my transaction the transaction

index I want is zero. So that's going to actually prevent the proposer from reordering it and placing it at a different place because it's just simply going to be invalid if they were to try and do that. There's actually another problem here. So in this example, my transaction was the first one. But what if it was the second one? So that's index one. So we're going to see that here. So my blue transaction, that's the second one. Is it index one? And the proposer has actually included that index one. However, they've just not included the other encrypted transactions from the mempool. So, they still haven't respected the constraint and they can still frontr run me. So, it's actually not enough to just have the index. And the kind of solution here is to use a bundled transaction. So, we can see here we have this transaction at

the top and that is actually including all three of those transactions within it. So this is a bundled ERC 4337 transaction and basically what that means is within this bundle we can assert that the index is zero and then all of the logic for checking that these are in the correct order within can be handled with a a smart contract. So specifically this is like the 4337 entry point contract and we can modify this so that it's going to actually enforce the rules of the men pool. And here basically what we have is a way that I can get very strong front running protection guarantees without having to trust the proposer. I know that if my transaction is included in the wrong place and it's simply not going to execute. So it's actually impossible for me to get front run. And I have a link

to it here to a post I made which goes into a bit more detail about how this sort of smart account approach would work. So one kind of caveat here is like what if we're thinking about introducing some limits on the transaction size. So what if one bundle actually isn't enough to fit in all the transactions and that's where you can actually split it into multiple different transactions. So we can see we have now two bundles and we can assert the first one the transaction index is zero and the second one is one. Um so we still can have multiple transactions and have this strong front running protection across all of them. I think the biggest benefit of this approach is we can just implement this simple op code and the rest of the sort of encrypted mele logic is all out of protocol and I think this

is really good because sort of the core developers have a lot of things on their plate a lot of priorities and yeah so kind of doing everything in protocol having some kind of complicated encrypted mele solution is probably off the table certainly for quite a long time so I think it's quite an appealing design that we just add this sort of simple op code and the can still be handled out of protocol but in a way that still gives good protection. And yeah, with this approach, we can also support different encryption types. We can have different types of the keeper that reveals the keys on time. So we could use like threshold cryptography, which is what the shutter encrypt does.

We can use some kind of commit reveal scheme. But basically with the smart account approach, what we want to do is have some kind of shared standard for these smart accounts. So we're going to have this modified ERC 4327 entry point contract which is going to be shared between any different encrypted meles even if they have their own keepers or or different various things. You can also use a smart account modules here to implement some of the functionality but as I say more of that is in the other post. And now just a final bit on how this op code actually works. So before I kind of introduced it at first as as simply the TX index op code and this was kind of a lot more flexible in the way it works. So this op code would just return what is the current transaction

index. So you could kind of call it anywhere in the block could like then check and revert. But the problem with this is it's just very hard to reason about. So with the assert TX index op code, the difference is you have to basically you're forced to just say what you want the index to be up front. With TX index, you can have any kind of like dynamic condition. So you could make up some really complicated constraint like if the TX index is a multiple of seven or XY Z then execute otherwise don't. And the problem with this is if you're a block builder this could get really complicated. So you could have all these different weird TX index conditions that clash with each other. But basically by enforcing these rules so the assert TX index op code has to happen right at the

start. The argument to it is in cool data. So it's a constant and basically this means that you're just declaring everything up front and you can't kind of do these create these complicated conditions and yeah that's it for the presentation. So yeah if you have any feedback on these EIPs then yeah please share on eth editions and it would be great to hear from you. Thank you so much for the presentation Mark. We would take some questions here from participants here. I see there is a question already by Justin. Justin if you would like to read it for Mark here. Hi Mark. Yeah. So the bundler is interesting. Do you imagine that as being a system contract that gets deployed at the same time or you know around when this op code goes live? So the bundler is kind of it's already a

thing in in 4337. So the bundler is the entity that offchain is going to accumulate all of these different transactions and bundle them into one user transaction, one transaction which they post on chain. So there's no system contract there. What I was referring to is the entry point contract. So that's where they would send this bundle transaction. And actually the way I expect that it would work is that the bundler and the proposer would actually be the same person. So the proposer who's who's proposing the block is going to act as this bundler who's going to look at the encrypted mele and like get all these decrypted transactions and bundle them and put them at the top of their block with a proposal builder separation. then they would have to bundle this and then tell the builder basically to put at the top of their

block which is possible to do. Okay, thank you. Um the other thing I wanted to ask is like how do you imagine L2s leveraging this? Do you have any scenarios in mind for specifically in the context of encrypted mess, right? Do you have any use cases or scenarios in mind that kind of demonstrate them leveraging this to get more onchain security than they have today? Yeah, that's a good question. I haven't thought as much about L2s. I mean, I guess they operate in a kind of different model where you have a centralized sequencer which you're trusting. But yeah, to be honest, this is something I need to kind of explore more. But yeah, it would be down to them like whether they think that it's something worth implementing if they want to retain the up code or not, if it

kind of makes sense in the context of their own like model. Thanks. Thanks. I have a few questions for EIP7843. So I noticed that this proposal seems to be relatively smaller and I'm not sure how many lines of codes are there but I would be more curious to hear your thoughts on why do you think this is worth formalizing as a part of protocol when today developer can already calculate the slot number using uh timestamps and other thing. What specific problem do you think this proposal is solving here? Yeah. So I think yeah the biggest thing is kind of removing this block on changing the slot length. So I mean there's been a lot of

talk around like scaling I mean primarily through raising the gas limit but I've also heard some people talking about through uh reducing the slot length and I remember this being discussed on ACD quite a while back and this point was raised about you know like what about all the contracts ecosystem are they going to break because they're expecting to have this 12 second slot length. I remember someone saying like, "Oh, that's kind of not our fault, right? Because we never promise that the slong slot length is going to stay at 12 seconds." But I think that that's not really good enough. Like we need to give people a way of doing it properly that's not going to break and not kind of, you know, force them to do it in kind of a dodgy or brittle way which is going to break in in future. And I I can imagine

maybe not in the next hard fork, but in a few time few hard forks time we can try and like reduce the slot length. And we may even want to change this multiple times like down from 8 seconds to four. like we want to be able to like flexibly change it without worrying that contract's going to break. Very well. So I noticed that this is chosen to be implemented as a pre-ompile rather than an op. Yeah, sorry. Yeah, I should have uh sent that to you before because I I quite recently made a PR to change it. So that was actually it started out as an op code and then I made it a pre-ompile and then I've changed it back. And so just to explain the reasoning behind that. So the reason it was changed to a pre-ompile was that there was some concern that it might be

kind of awkward for L2s if it's an op code to like decide whether they want to implement it if it makes sense for them and as a pre-ompile it could be sort of easier for them to disable it or not support it on their network which I think the argument makes sense but actually speaking to different client teams it seems like there's general sentiment is that people aren't a big fan of adding new pre-ompiles they kind of want to keep things simple and prefer to add op codes And also from what I've heard about L2s, like they're not super bothered about disabling the op code. Like it wouldn't be a big problem. So, and also in terms of just gas costs, it's cheaper to use an op code. There's less overhead. So, I think it makes sense to be an op code. Thank you. I

would get back on some questions which are related to both proposals at the end of this conversation. But before that, let's go to another proposal 7793. I'm curious to understand here how easy would it be for a developer to use assert transaction index in their specific contract especially from application point of view. So the way that I imagine it kind of as I was saying is with this like smart account approach. So I think it wouldn't be sort of loads of people using it. I think there would be this like I imagine it would be this relatively specialized application encrypted mess. So you're likely to have like a few transactions with this assert tx index maybe just one which is going to be most of the time

just asserting the TX indo tx index to zero which is the top of block and also be like a relatively specialized contract. So this would be the entry point contract which is sequencing all of these encrypted mele transactions. So I'm not necessarily thinking it's going to be useful for like loads of different purposes but for this kind of specialist purpose it's actually going to unlock a lot. By any chance, are you aware of any tools or examples, those are being developed to help people test or implement this proposal? I'm not aware of any tools that's being developed as of yet, but I kind of think if we decide to include this proposal, then you know that the tooling will come. But I don't think if it's not clear that we're going to include it that people kind of start

building before that makes sense. Yeah, I think the proposal is still in the draft status. So, it might take some time. Yeah. While we are trying to raise awareness about this particular proposal, I understand whenever there is a core proposal, the big reason is it has to be included in the upgrade. So thinking about the broader upgrade process, I noticed this proposal was pfied in January 2025 like proposed for inclusion for Fusaka upgrade but it was removed in April 2025 to DFI that means declined for inclusion. I'm curious to hear your thought why DFI do you think the proposal was not ready or is it not

the best time to include it in Fusaka? Yeah. So my aim is to well I'm going to propose a zoom for Amsterdam and that's kind of my aim is hopefully we can include it there. I mean I proposed it for Fusaka kind of not thinking that there was really much of a chance that we get in at that point because you know it's just such a focus on pardas and and kind of like a few top priorities. So I think that these these proposals are good like they have benefits but they're not like as important as some of this other stuff which has gone in. So I kind of proposed it just to get on people's radar like start getting some feedback and have people thinking about it but yeah I'll try to make more of a push for it to be included in Amsterdam. That's

right. There are a bunch of proposal already up for Fusaka and after EOF being out of the proposal I think perhaps this is not the right time to include any other EVM related proposals maybe we can get back at it on Glamsterdam. There is an interesting comment here. Don't give up on Fusaka. Tons of stuff being pulled in. There is plenty of room. So we hope that proposal is ready and like you know people are sending positive signal then we can perhaps talk about it. And while we are in a position to collect feedback I'm curious to hear your thoughts on responses those have been received either from client teams or the EVM

community or Ethereum community in general. Did you find any of those feedbacks useful and was there any spec change brought into consideration because of these feedbacks? Yeah, so I've got a lot of good feedback. I mean, I've kind of spoken to people at different client teams which seem like they would be potentially interested in supporting it. Yeah, and through the Ethereum Magicians thread, I've got various kind of constructive feedback which has been really useful to shaping the proposal. So as I said so the whole thing about it being a pre-ompile and an op code that's kind of completely based on on people's feedback and the bigger one was about so I had sort of on that last slide about the how I changed it to assert TX index or me

and Ahmad so sorry Ahmad is the co-author of the IP we changed it to assert TX index and that was also based on feedback from ETH magicians and one of my colleagues about the parallel block building. So yeah know it's been very useful that's good to hear. Generally we try to collect as much as feedback during the draft and the review phase so we can make the changes in spec as needed and make it ready for proposed for inclusion. We recently had a conversation with Tim Beo on different network upgrade stages. So it's good to use these stages while we are talking about EIP. So community get a clear signal where it stands as of now and how do we see it progressing. Well, one other important question that always

comes up when we are talking about core proposal is about the security. So security-wise, are there any risk to either exposing the slot number on chain or anything with respect to EIP7793? How have you considered security consideration in the proposal? Yeah. So, in terms of the slot number, I can't really imagine this causing much of a problem. And it's very similar kind of in the way that it kind of functions to stuff we already do. Like we already have the time stamp which is exposed in a lot code in terms of the other one. I also kind of don't really see any issues besides this like parallel block building thing which I've mentioned. But yeah, absolutely I would, you know, love

for anyone to like study this and think about this if if you think there could be any kind of security issue. That sounds good and we do have enough time. If there is something that people can find, they can definitely report it at fellowship of Ethereum magician page so it can be looked deeper into. Well, in my understanding, these proposals may go side by side. Do you anticipate both 7793 and EIP 7843 being bundled or deployed together? I think that they are quite separate at this point. So yeah, I've kind of presented them together mostly because I kind of came up with them roughly through the same kind of process about thinking about encrypted meles. I think

now the slot number one isn't actually that important for encrypted meles but I think it's kind of relatively small. So I thought could present them together but generally I think they are quite independent so can still be considered independently. Of course they are kind of two new up codes and I mean my hope is that both could potentially be included. then we can perhaps give more thoughts on Justin's suggestion that we may have some time and we can perhaps try to bring at least one of them in. Again, this is not a thing coming out from KDF's mind. So, just please take it with a grain of salt. All right. I was about to ask this question. Have you received any client feedback? Are there any client that uh are considering to

implement it even if it is not for Fusaka but for a future upgrade? So, I kind of put together quite a rough prototype. It's not up to date with all the latest like spec changes, but I was just kind of yeah, as I say, just prototyping it to just kind of see how easy it was to implement and it was pretty simple. At the moment, I I don't think any other client team would implement this, but unless there's like a good chance of it going into the fork, but I I see it as kind of relatively minimal in terms of implementation. Like, I don't see it being a big implementation effort. So, I don't think that they would need to necessarily start implementing at this point, but it could still go in with like Yeah. Yeah.

As I said, I don't think it would take too long. Yeah. And I hope the recording when it is out, it might help you get some buy in as well, looking into the simple part of the proposal here. All right. I am assuming that these two proposals are one of those first proposals that you may have documented. So I would be interested to learn about your experience going through the EIP process or this proposal. Was it easy to document or how complicated you find the network upgrade or the EIP process? I guess the kind of the process is is pretty straightforward. I've kind of been a bit more involved in like EIP editing and stuff. So I've got quite used to it. Yeah, I guess the difficult

things were the more technical things of of trying to think through all the implications especially with the TX index like trying to reason about all this stuff that could go wrong or how it could be used was probably the the hardest bit. Yeah, I mean my experience with submitting the IP and getting feedback has has generally been pretty smooth. That's good to hear that because I have noticed that there are a lot of effort going in in improving the present process. So we can definitely use any kind of feedback with respect to EIP process or with respect to network upgrade selection process. Well, that brings me to the end of all the proposal related question. I'm not sure if there are many more because as I mentioned in the beginning, this is still in the

draft status. So we are just hoping to get this proposal out and let people know more about it so we can receive more feedbacks and comments on it. In the meantime, what we can do is have some fun and entertainment here. So, we are going to proceed with the next round which is called rapid fire [Music] round. So, Mark just to let you know in this rapid fire round we try to collect your thoughts, your inputs in form of either one word or one sentence. What do you think and how do you feel about Ethereum and ecosystem in general? Yeah, sounds good. All right. Who is the one Ethereum researcher or developer whose

work you always follow? Would say maybe POTUS and he's doing some good work on EPBS, right? What's one EIP or idea in the ecosystem that you are currently excited about, but that should not be your own proposal? I think scaling the L1 gas limit and all all of the stuff around it. Yeah. What is your favorite place to think about specs? Is it a whiteboard, walk, or terminal? Uh, I think going for a nice walk on a sunny day, but we don't get too many of those in England, unfortunately.

All right. What is the easiest part of writing an EIP? And what would you say is the hardest one? Maybe the it's just not easy, but maybe the coming up with ideas is easy, but then like thinking through all the implications and and things that could go wrong is is hard, right? We definitely have to focus a lot on what is requested and required for that protocol. What's your favorite thing about working on Ethereum? Maybe just the variety. Like you just learn a lot about just different areas. Just so much to learn, right? If Ethereum had a feature freeze week, what would you spend that week hacking on? I think the

beam chain. I'm quite excited about that. Really, it's exciting. One word your friends would use to describe your coding style. I would hope clean. I mean, maybe that's just that's what I like to think anyway, but the EIP suggests that it's very short, sweet, and clean. Thank you. What's your favorite tool or framework in your developers toolkit right now? Maybe currently it's just AI chatbots. It's actually been very useful for kind of brainstorming or thinking about this like spec design process. Right. AI can be very useful tool if used rightly.

GitHub or Ethereum magician where do the real debates happen? I think Ethereum magician is where the the spicy conversations happen. Yeah, I think we should have added one more option. Twitter here. Oh, yeah. Tea, coffee, or slot aligned transaction batches. I think I have to go for coffee over any other option. Very well. Thank you so much, Mark. Very well answered. And thank you so much for taking out time and talking about these proposals. I understand that these are some simple proposals but they can do bigger innovation as we were discussing that there may not be tools right now

but there could be more tools upcoming and uh this encryption of mele can be used in many different ways. So thank you for sharing all these incredibly insightful information with us. Thanks so much for having me. Dear listeners, thanks for tuning in. If you enjoyed this episode and want to stay updated on the latest proposal shaping Ethereum, don't forget to subscribe and share and follow us at Eatcat Hooders. You can find the EIP link and discussion thread in show notes. Until next time, keep reviewing, keep building, and stay curious. Thank you everyone.