Frame Transaction Breakout #4

Transcript

kwame: Hello, hello?

Marc Garreau: Hey, I don't see you with the host label on either.

Lightclient (Matt Garnett): It did not ask me anything about… being host. I wonder if I'm not logged in or something? Yeah, I'm not logged in.

Marc Garreau: I'm sure, one of the co-hosts. can… Give out the role once they get in here.

Lightclient (Matt Garnett): Yeah, there it is.

Marc Garreau: Nice. Hey everyone, as usual, we're gonna get started at about 3 minutes after top of the hour, so 2 minutes from now.

Alright, everyone, just posted this link in a… In a couple places, so hopefully we'll get… All the relevant voices in here. We'll kick it off now, and I'm gonna start by posting the agenda link in the chat. I am happy to report that I no longer think we need a long-winded context catch-up. I think our most existential questions are perhaps behind us at this point. We'll see if we can dig any more up as we go here today. So in the agenda for today, leaving space up top for any spec changes or test releases. As a reminder, last week we left off with the goal of having a DevNet 0, Frame's DevNet 0, launching this week.

So, I will first call on, either Matt for any spec changes or out-of-the-gate comments, and then Guru will have the floor for any test release, latest updates. And then we'll have, space for client updates in general. Before leaving the, whatever, the last half of the call for… anything else we want to cover? Matt, did you want to kick us off?

Lightclient (Matt Garnett): Yeah, thanks, Mark. No spec changes in the last week. I know there's some outstanding PRs right now. Obviously, like, DevNet Zero would kind of have frozen, and would only add clarifications at this point. If there's any… yeah, I don't know if there's any prioritization of changes people want to start thinking about for DevNet1 going forward? Yeah, feel free to post in the chat, raise your hand, or just DM me. I can take a look at them. I honestly haven't taken a look at a lot of the open-spec PRs. Because I've mostly been working on the implementation of frames and guests, for myself. So I think, yeah, on the spec side, nothing… nothing new in the last week.

Marc Garreau: Cool. I will link, where you can find some of those open PRs against 8141 in the chat, but Guru, do you wanna talk about the latest test releases?

Guruprasad Kamath: Yes, so, last week we did a version 0.3.0 release for Frames, so the ELS implementation is up-to-date with the frozen DevNet Zero specs, and, the 0.3.0 is, test release is based on that. So, this particular release also exercises some of the deeper EVM code parts that are, also available for the legacy transactions, but also, this time. Via the Frame Transaction Envelope. So, with any client kind of passing all of these tests should be in a pretty good place. in terms of DevNet Zero readiness, so we have a good mix of deep EVM code path tests, as well as, like, the frame-specific tests. Of course, we are working on, like, more tests, frame-specific tests, which we will be adding in the coming days, but this, I think, should be a…

a good enough place, to assess kind of frames, definite zero readiness. Let me post the link in the chat for the… Yeah, that's the release.

Marc Garreau: Thank you, Guru. Do any, client teams, or anybody else for that matter, have questions about what's in the test release? Okay. Thanks, Ankura. Do we know at this point, who from PandaOps is gonna facilitate the… the DevNet on their side? If not, that's okay, I just want to make sure that… We know who to… to ping when we're… Ready for that? Okay, Marius is Barnabas, probably, but he's out for the moment. Cool. Let's get into, client updates then, and I guess a big focus here will be on that Frame's DevNet Zero readiness, and then we'll see if we can

Define that, a good lunch date, if it is this week. Matt, you already started in, I heard you say that. Jeff, is DevNet ready? Did you want to elaborate?

Lightclient (Matt Garnett): Yeah, we also, over the weekend. was able to pass the EELS test and ran a kurtosis network with the ethrex and Nethermind implementations on Frame's DevNet0. Our branch is also Frame stuffNet Zero, if you guys wanna… Also run it, and… Collaborate that. That would be good. But I think, yeah, at this point, I don't know if we do any other steps before we get these DevNets started, usually, but it feels like we're… Yeah, at this point, kind of just need to talk to… DevOps and figure out who can kick us off.

Marc Garreau: Cool. So I heard, ethrex, another mine mentioned as ready for the first go. Ben or Yvonne, do you wanna… Jump in here, elaborate anymore?

Iván | ethrex: Okay, well, we are ready also, we are still passing all the latest test suite. So, yeah, we're good to go on that.

Marc Harvey-Hill: Yeah, for, Nethermind, I think we're also ready for the first DevNet. Yeah, we have a Validator running on ethrex's DevNAT. And we're, just making some improvements to the code and hopefully getting it merged soon.

Marc Garreau: Thanks, Mark, didn't see you there. Okay, are there any other clients represented here that think, that either want to give a status update, or think they'll be ready for, for this DevNet Zero at the, the launch?

Iván | ethrex: I'm sorry, as a couple of more updates, I proposed a test to test the fork transition coverage for the Xperiaverifier install. I just saw, Guru that you sent some feedback. I will check it right after this call. And on our public testnet, we've also upgraded it to the latest spec tests, and, As Marc said, Nethermind has been able to join us as a validator there, so… That's very good, and it's also good, Matt, if you want to spin up some validators on that, let me know, and I can… I can send you some deposit tokens. Right, I'll talk to you via telegram or Discord.

Marc Garreau: Okay, thanks, Ivan. That sounds like a… a great ability to keep moving forward until DevOps, EthPandaOps are ready for us. Last call for any client updates. I think we might have everybody represented here. Or everybody, every team represented has given an update so far, as far as I can see. Okay, that's nice and quick, then. That kind of leaves the rest of the call for… Everything else we might want to talk about on the agenda, I've got Rahul wanting to, dig into frame expiry, and then a couple of PRs highlighted by Daniil from Nethermind. Rahul, do you want to take over from here?

raxhvl: Sure.

Marc Garreau: Okay, floor's yours. Did you want to share a screen or anything? There you are.

raxhvl: Yep.

Marc Garreau: I can see it.

raxhvl: And I said.

Marc Garreau: Yeah, no, I can't.

raxhvl: Yeah, give me… give me a sec.

Marc Garreau: There we go, we got full screen now.

raxhvl: Okay, so I want to talk about Xi frames. These are frames that, You know, ensure that a transaction does not get executed after a point in time. Briefly, how this works is you have a special frame which has no flags, values, or… Cast limit? And it targets an EVM contract, which, checks for a timestamp. And, if it's expired, you rewards. Now, the contract, which, fails the frame. And then, the transaction is mapped invalid. This has some moving parts. But, the intent, of what we're trying to do is a simple check. Whether, the block timestamp is… is greater than the expiry. Also, we note that the expiry applies to not an individual frame, but the transaction as a whole.

And so… As opposed to a frame, this information fits naturally into the transaction metadata. And if you do that, it kind of simplifies, some things. First of which is, state. Expiry validation is a pure function which takes the current block and transaction. And, returns a Boolean value, if the transaction is valid or not. Bringing stateless, to this equation complicates, quite a lot of things, like tooling. Mempool validation, efficiency, and network parity. And this is because Now, the pure computation has to flow through state. Of course, we can have a native implementation that bypasses EVM, but we still gotta check if the contact is actually present in state. And, if not, there's a drift, and all this takes a hit on performance.

This is caveated in the IP text, in two fronts. First is that, obviously, we need a native implementation for performance. Second, there is no behavior guarantee across networks, right? It could be that a certain network has not Deployed a contract, and all this is tied to the current state of network. It has impact on tooling, this is, a sample PR that has… that is just spoken about. This installs the expiry, verify a contract into the testing framework. This has about 200 lines of, code. For what we discussed, right? It's just a simple line check, and this feels like… A bit disproportional, given the intent is to do a simple check. If we add expiry to the payload, of the transaction itself, we can…

Get some guarantees, by design. First is that we don't need to check if we have multiplex value frames. Because the payload has only one position for expiry, it guarantees that, you know, there can be only one expiry timestamp for a transaction. And because we get, rid of the special frame, we can get… Rid of its constraint. Such as checking whether the flags and, values are zero, and there are no state caps. There are also some exceptions we make for this particular frame. First is that, verify Ethereum generally don't, include their call data as part of the signature? But we gotta… add, the call data-flow expiry Frame into the signature, because That has the expiry information, and we don't want, it to be tampered.

We also allow a band timestamp of code to be executed for, this special frame. If we… if we do a standard native expiry, The transaction payload is… contains the expiry and is automatically included in that signature. And also, we don't need to make any EVM exception, because we just bypassed EVM. It's… Also smaller. Because we're mostly encoding an empty frame. Towards the right, you can see that, you know, the flags are zero. We just have some execution gas, to do the pure competition, and the timestamp itself. So, if we just have a native integer, it's significantly smaller. That's one, it's about 9 bytes versus 41 bytes.

Now, there is some trade-off, to adding this, to the payload. Expiry Frame allows you to define optional expiry. But if you add something to the payload, that becomes a mandatory field. Which adds a fixed 9-byte overhead. Across all transactions. And ideally, we should have the ability to define expiry as an option. That brings us to… The core of this proposal, it's, something called Transaction features. Features define, like, optional qualities of a transaction, these get applied To Transaction as a whole. And you can choose to define features that fits a specific transaction. Here's how that looks. Features are simple. Key value pairs. Keys are called feature tags. Values are arbitrary values that, you need for that feature.

Feature tags, allows you to, you know, only define the features that you need. For example, if you need expiry, you can just have Have that tuple as part of your feature list. And if you don't, you can just remove it. And if a transaction has no feature at all, we just encode an empty… List? Which has very little overhead. Which, which is just a single byte RLP, header. features, need to follow canonical ordering. That means Each feature tag, which are just integers. Need to ensure that, you know, Follow a strictly ascending order. So if we follow that, we can ensure two properties. One is that no features can be duplicated in a transaction, so a transaction cannot have two expiry, for example.

And, this gives you, like, deterministic, deterministic way to encode a transaction, which gives you, a canonical signature. On the price front, We can start with two features. There's a proposal that, that wants to add like, Valid from timestamps, so we start with a from and an until feature. These are simple comparisons, that have… negligible cost. On the value front, these are 8 byte each, and encoded as part of the transaction payload. This is quite similar to the call data. So we could, price it similarly, or, we can choose to not do that. We can have that. Up for discussion? And, yeah, that's about it. I have a DAS PR, and, yeah, that's all I've got.

Thanks.

Marc Garreau: Thanks, Rob. So, to clarify, this is a proposed change to Frame Transactions itself, or would be tackled in a, like, a separate EIP, for example?

raxhvl: This is… This is not a native proposal to how features are implemented within FrameDirection. How expiring is implemented within FrameCon.

Marc Garreau: Okay, I see Matt already left you a couple comments in the chat. Did anybody want to respond now?

Lightclient (Matt Garnett): Alright, maybe I can ask a more broad question. What is the motivation for… You know, choosing to add this functionality in the protocol. Because from my perspective, like, we can implement this outside of the protocol, and if you can implement something outside of the protocol. Generally, you should implement it outside the protocol.

raxhvl: The core motivation of that, the comparison is… stateless? And I was wondering why should we add state as a dependency, yeah?

Lightclient (Matt Garnett): What is the state?

raxhvl: The EVM contract?

Lightclient (Matt Garnett): I mean, you don't have to… Like, load this… this state, you can interpret it natively in the mempool.

raxhvl: Yeah, but we still have to read the… State to ensure that the contract is deployed.

Lightclient (Matt Garnett): I mean, right now, the contract is deployed as part of the EIP.

raxhvl: Yeah, so we will not check at runtime, just to be sure if the contract has been deployed, I mean, just to ensure there's no drift.

Lightclient (Matt Garnett): Why would we check it if we know it's deployed? I think this is a lot of complexity to… potentially avoid. reading state, when I think there are, like, clear ways to avoid reading the state.

Toni Wahrstätter: Yeah, I tend to agree with Matt here. To me, please, like, or to put it that way, this has been discussed at some point, like, should we have, like, those special verify frames versus And putting things into the transaction envelope. And it… at some point, it just felt cleaner to have things, be put into the… into, like, special verifier frames that are, like, recognized by their target. And with features in specific, I'm not sure if there is much more, like, maybe I'm just not creative enough right now, but I'm not sure if there is so many other features that we would need to generalize that option that much. Of course, there's, like, the expiry and also the valid from.

But those two are easily, implementable with the special verify frame. So I'm not sure if there is much more, that would justify generalizing it that much.

raxhvl: Yeah, I don't think we have more than two at the moment. Also, I mean, the core mutations also, the frame is mostly empty. So, encoding it as… Into the payload, saves you some… some bytes. In the transaction.

Toni Wahrstätter: Yeah, I think always when we look at transaction sizes and bytes, we always have to assume snappy compression. So if there is, like, an integer with, like, leading zeros and everything, or some padding applied. We… we can almost ignore that entirely, because in the end, it will end up being snappy compressed very well.

raxhvl: Yeah, that's all from me.

Marc Garreau: Okay, thanks, Rahul. Somehow in the chat also mentioned that you've gone through a similar discussion for recent routes, and… linked to a PR. If you'd like to reference that. Okay, if somebody wants to follow up on this discussion, this design decision? Rahul, is there a good place for that to happen right now?

raxhvl: I'll comment on…

Marc Garreau: Go ahead.

raxhvl: Yeah, I'll comment on the Frame Transaction, ETHMAC session.

Marc Garreau: Okay, great. We've got, just two more bullet points on the agenda, both from Daniil. Daniil, do you want to… mention those two PRs?

Daniil Ankushin: Yeah, let me start from the first one. I just wanted to present the ERC. Okay, let me share the screen. Alright, I hope that you see the screen.

Marc Garreau: Yep.

Daniil Ankushin: Okay. Okay, what's the problem I was trying to solve? The problem is that We have now two types of native account obstruction, 8141 and 8130, and they're going to be alive together somehow. So, I was thinking about how can we define the key, life cycle for, for these two, EIPs. So basically, we have, three actions that we can, do with the… our keys is to add, rotate, and revoke. Well, this is at least how I defined it. And the issue is that now we don't have, basically, the common base, and, different accounts define, this, potentially can define it differently. And, basically, I dis- I proposed, model, the scheme, how can we make it, a common base?

So, let's start from the off-chain data. How our wallet works. So, basically, in Wallet, we have a tree. with leaves as, defined as this one, authority ID, and pretty gate. So basically, Authority ID is just an ID for, for the key, and prettyK is, well, let's say, the logic in the key itself. So we have, for example, a session key, guardian key, and a spend limit. And, we have this, tree, and we have an authority root. So basically, the fingerprint. Let's, so this, this data, is off-chain again, but, optionally, it can be on-chain. I will, mention it a bit later. So let's look at the… Scheme how… we… how we add, the key, on-chain. So, first of all, we need to insert a leaf, a new leaf, in this, tree. After that, we recompute the root, this root, and, we have

This, new route, R1. So, and, we send it on-chain. We have two options. We can store it as, state slot, or, we can store it as recent root. I will describe, the, difference a bit later. And how, does the… Transaction happen. So, basically, what we should do is to send, membership proof, together with, transaction. So we have, this, our leaf, the proof, and, root reference. So we, check, the proof against our, root. The root is, res- is valid. And after that, we have, we check in our predicate, and after that, we approve or, withhold. So, yeah, let's, let's talk about, two different tiers, and, differences between where do we store our,

fingerprint, our, root. So, the thing is that, I define these two tiers as, two, kind of different, options. How can we, store the key? The thing is that we have our three, let's say, verbs, add, rotate, and revoke, and the thing is that, our add verb is, monotone and, but, rotate and Revoke are… Anti-monotones. And, the thing is that with, We need to have, this, recent route, for on time, unaton, Oh, wait. I'm like, we, we can, be in danger if we use untime and a tone, type, with, Risanoot. What I mean by that? For example, let's imagine that, your key has been stolen and you need to, revoke it. And with Tier 1, for example, if you store, your, fingerprint in your recent route, there will be a delay.

with the recent routes, because, yeah, it updates, so, it lives a bit longer on chain than the instant slot, change. And the thing is that when you revoke the key, there is a delay in Tier 1, but with Tier 2, there is no delay, but the issue is that, you need to read the state. But it's not that scary, you only need, To read your own state, that, at least Frame transactions allow. And yeah, the same mechanism for, 8130. For 8130, we have freshly introduced, checkpointed image hash. That's, I would say, analogy of, recent roots and, image hash, for, for Tier 2. Let's also imagine that we lost our wallet.

And this is the thing, I said that, this wallet data can be optionally stored on-chain, to, to easily, To easily restore, this tree. for, for your, for your wallet. But it's up to the, up to the user, it requires, some privacy, or, or less state. User can, rely only on, its own, and, store, this tree offline. Let's see, trade-offs, between tiers. It's not that important, but still, Root source, or on Tier 1, we have recent root, yeah, for this one, I only, Defined, for, frames. So, yeah. For Tier 1, we have, Risan route, and for Tier 2, we have, account state slLot, current one.

On the head. For, state read, for Tier 1, we don't have any state read, and, for Tier 2, we have a 1 minute read. Mempool cost, it's, for Tier 1, it's cheap, and for Tier 2, it's also kind of cheap, but one extra, read per check. Revoke speed. As I said, we have a delay for Tier 2, and, instant for Tier… I'm sorry, delay for Tier 1, and instant for Tier 2. So pros for, tier 1 is, cheapest, scales to high volume, and, For, to revoke is immediate. Const, revoke, logs by the window, as I said. Yeah, basically the, the same, information that I said, earlier. What it, yeah, I just wanted to add, also, it's not only for 8141 code, or 8130 key store, it's also for potential, changes in native account obstruction,

And yeah, and for future ZK. Let's also talk about, cross-chain. So, basically, this, all ERC can be cross-chain easily, so we have our home chain, Where we store, our, authority route. After that, we have Root delivery to, executing chain, that imports, the home chain route, and, now we just have, one more, proof. So this is the membership proof that I was talking about, and the second one is the proof that error is the value at the account's home chain slot. And yeah, the same mechanism as above. So, yeah, yeah, that's… that's it. This is on the first point.

Marc Garreau: That feels like a good spot to stop and pause for questions. You covered a lot of ground there, so… while people are coming up with any questions, I'll also ask, is there, Any of this that you would like any specific feedback on, or, any specific parties that you Most want to get their feedback from.

Daniil Ankushin: Well, originally I was resolving the issue. I was thinking how to resolve the issue for wallets to not implement different logic for different, stuff, so maybe we have some Guys from, different, Well, it's here, and yeah, also, also the general view, if it works, if it's logical or not. So, yeah, I'm open to, for feedback.

Marc Garreau: I noticed in the ERC proposal itself, in the PR there, there is… A lot of, chart, like, graphic explanation for the flow of things as well. Maybe that would be helpful to readers also.

Daniil Ankushin: Yeah, and also, I added, the link to ExplosDraw here and in the PR, so, yeah. And also, there is a topic on Ethereum Magicians for that.

Marc Garreau: Okay, Daniil has one other, PR to bring up today, so I'll… I'll pause for… One more second, does anybody have any questions? ready for this ERC? Okay. Then you know where to direct feedback and questions. Daniil, do you want to continue with, I've lost the link now. definition for max feriff, I guess.

Daniil Ankushin: Yeah, yeah. So, just a small reminder that, we have a constant, called, maxVerifyGas. This constant, is created to limit the verification prefix for Frame Transaction, in mempools. And, well, currently it's, it's defining, so we, we're doing, some job, for, with benchmarks, so Manuel is focused on that. But, my change, is a bit different, so, I would rather define this Not as a limit, but as a mempool floor, and, let, different nodes, Decide, whether they, sh… whether we… sorry. Whether they can, can set a higher, limit to handle, let's say, heavier, transactions. This should, unlock the…

let's say, complex transactions. Yes, they're going to be, slower, they're going to be, gossiped, a bit slower, but it still will be possible. And also, just wanted to say that, this, max purifier gas, limit, is not a good… is really not a good, I would say, definition of, limit for, different nodes, because different implement, implementation, has, obviously, different, attack vectors, weaks and, strong, parts, so, We're trying to make them equal in mempool, and yeah, the thing is that we can allow different nodes to handle heavier transactions, if they can do so, and this way we can

Make, our, mempool. More flexible, and let's say, define some, gradient, in mempool. So, yeah, we have our floor, where we guarantee that, this transaction can be gossiped, can be properly handled by different nodes. But on top of that, we can, also define, non-guarantee layer, but yeah, it's still, Allows, some heavier transaction to be handled. So that's the idea.

Marc Garreau: So you've gotten some feedback already in the PR there, one from Toni? Is there anything, any feedback or questions? Folks want to point out that? Currently. Okay. Async it is, then. Thank you very much for presenting those… both of those items, Daniil. That does conclude everything we've got on the agenda today. I noticed, some… we've had some more join the call later, including some of the Beacon devs, so maybe a quick recap for them, at the very start of the call.

We discussed, likely Barnabas being the… the PandaOps representative that will drive the first Frame Net0, and he's out at the moment, but there are a few teams that are ready to get started, and one way that they can do that is by leveraging ethrex's testnet or DevNets. To test their… their clients there. Basically, folks, did you want to give any status update on your end?

Justin Florentine: We don't have any status as far as code-wise, but this is Justin, I'll be the point person on this. Where can we find more details about joining that testnet that you just spoke of?

Marc Garreau: Ivan, that's your cue.

Iván | ethrex: I'll share you, just right now, the link. You can't find anything here, or you can also ask me any questions in Discord or Telegram. I'm happy to help onboarding you guys.

Justin Florentine: Awesome. Thanks, Ivan. That's it for us.

Marc Garreau: Okay, we're doing great on time today, that's 15 minutes plus towards, till the end of the scheduled time, so the floor is open if there's anything else folks would like to chat about today. Alex, go for it.

Alex Forshtat: Yeah, hi. Can you hear me well?

Marc Garreau: Yep.

Alex Forshtat: Yeah, great. So, I proposed the EIP7906 to Hegota. This is an extension to Frame Transactions, it adds a post-transaction frame. And an opcode to, like, a set of opcodes to get, like, state diffs that happened during that transaction. That is supposed to have transaction assertions, the general, like, checks for what the transaction actually did. I saw a post yesterday from the protocol, team, and this… this proposal was ranked A, and the feedback that, like, the informative part of the feedback was, like, one sentence that There is a recommendation to focus on the ball shape of data and events. So I would like to hear some feedback, like, maybe in more detail about, what exactly does that mean? How exactly would that look like?

I presume this does belong, in a way, to the Introduction Breakout in general, so, yeah, I would be happy to hear from you, or if, if nobody's here to give feedback, I can ask for questions about what… what the shape of the data is now, and the what changes are needed to make it more, ball, like… Thank you.

Toni Wahrstätter: Yeah, maybe, maybe I can help. I'm actually not sure where the connection is between Transaction Assertions and BAL. I don't see any, and… It feels like, if a blog post says something about some incompatibility, then this is… feels like wrong. There is something about ball data, there is an EIP that proposes to meter ball data as every other data in the block. But similar for that one. Shouldn't impact transaction assertions at all. So, to me, it feels like Transaction Assertions is a very nice extension. That is probably… worth to consider for Hegota, because, of course, if we don't ship it in Hegota, then we have to touch, Frame transactions again, potentially in I-Star. Or data. So, my recommendations to Code Epps would be that we include it.

Alex Forshtat: Awesome, thank you. So, I would love to talk to you more, maybe, like, after the call, about the exact shape. So I, I, if I remember correctly, there is a, like, a very long post about BAL, related changes to… To the post-relection assertions in… in the magicians. form? I… I… I can't show it. I think the idea there was that all clients already have BAL data, and there is a standard for what the data is. I'm not sure if that is actually.

Toni Wahrstätter: Yeah, I see what you mean. Like, for balls, we collect statiffs, and we would do the same. We would also need stateless for Transaction assertions. The thing is, we should probably not commingle the two, because the ball is on the block level, so… For… you would have, like, transaction indices for… The different status, but… I, I, you know, this is… this is, like, this is not really a convenient thing to do, so I would just not commingle them at all, and have this opcode. be implemented however clients want to get to that opcode, and they would probably I don't know, debug trace, or basically the same as they do for Ball. Or very similar. But I wouldn't commingle the two.

Alex Forshtat: Okay, awesome. Thank you very much for both David.

Marc Garreau: Okay, any other items before we wrap up today? Damai, yeah.

soispoke: Yeah, yeah, it's a very small one. I just wanted to flag this new, post that we had. It's called Matcha… Because I would like feedback from… from clients. I think it's… Would be quite important to the Kadakik, because, like, basically the goal is To allow, multiple frame transactions. per sender. Right now, there is, like, a mempool policy that just allows one. And we need, like, basically, it's very important for privacy apps to… to get, like, many transactions per sender, so… We wrote something that will allow to do this while still, like, bounding, sort of, like, state-based invalidation attacks. So yeah, just a pointer, and a flag for everyone that's interested.

Marc Garreau: Great, thanks very much. Okay, last, last call. We still have 10 minutes. If not, just a couple of reminders. This call is weekly for the time being, for as long as it is useful, so we'll meet back here at the same time next week. And this Thursday, ACDE meets, and that will be, the expectation is to go over some Or, or all of the ready of the client team preferences for… Hegota, non-headliner EIPs. So please get those at least 24 hours in advance to Nixo and Ansgar if you're able. Yeah, I believe… Ivan Frames, as a headliner will be an official decision, or will be ratified, or able to be ratified as a decision on Thursday's call as well.

That's my understanding of it. Okay, if that's all, thanks everyone for your time. And see you on Thursday.

Daniil Ankushin: Thank you. Goodbye.

soispoke: Thanks.

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