FOCIL Breakout #41

Transcript

Justin Traglia: Good morning.

Jihoon Song: Hello, Justin, Justin.

Justin Florentine: Good morning! Justin Party!

Jihoon Song: Yeah, I guess we can start. Hello everyone, welcome to FOCIL Breakout 41. Today, we can share diff… Part of the DevNet, And discuss spec changes. Let's start with FOCIL devnet Status Update. Who wants to go first?

Iván | ethrex: I can go first, Steve. It's okay.

Jihoon Song: Yep, please go ahead.

Iván | ethrex: Okay, we updated our implementation to the latest spec tests. We are passing all of them, but some of them are failing, based on my investigation. not… not for a client issue, but something with the fixtures and also the harness. I opened a couple of PRs to the execution specs repo. That might fix it. I tested locally the changes.

Jihoon Song: Awesome, and thanks for the PRs. Any other updates? Yes, Mehdi?

Mehdi Aouadi: Yep. For Teku, we have a, DevNet Zero, branch ready. Hmm… It also contains the, recent, discussed spec changes, mainly the, signed inclusion list max, max size, and, And, yeah, the Transaction's emptiness check proposed by Barnabas, so those are, addressed in our branch. And, I managed to run some local interop using Kurtosis with Lodestar, ethrex, and BESU. they all work fine, so… yeah. I already published a, a Docker image. And, yeah, I'm still noticing a couple of issues, but really small issues, timing issues, so I'm checking those, and I'm gonna keep updating our branch.

Jihoon Song: Great Fabio?

Fabio Di Fabio: Yeah, for Besu, So we have the… DevNet Zero branch. should be ready. I'm not sure now, since we are already passing all the EIP tests, I'm not sure if… Since there would be some changes there, Maybe there is… There are some issues that would be discovered in the next run. and, I need to double check, the Barnabas spec change does, affect also EL. Because I went through… Intuit. Yet.

Jihoon Song: We still have to discuss, decide on which… gossip rules we want to add, but still, no matter what we decide, I don't think we're gonna affect EL at all.

Fabio Di Fabio: Okay Okay, anyway, we should be ready, so… if there is something… Neither that I will, keep an eye on, on EIP test, and On the chat to see if there is something. That need to be fixed.

Jihoon Song: Okay, cool. Thanks for the update. Any other clients?

Pelle Krabbenhoeft: Yeah, I can give a quick update for Reth. We… Updating… Would be updated to a non-stale branch, so we have… Reth-fossil-devnet-0, should be ready. I ran some basic interop with other clients and hive tests, so… It's definitely not 100%, but it's most of the way.

Jihoon Song: Awesome. I'm just curious… Have you discussed with Reth team with your effort? Like, are they aware that you are working on this?

Pelle Krabbenhoeft: Yeah, Matt made the branch for me and just merged everything in, so, it's out there. They're aware of it now.

Jihoon Song: Great, great. So Mark told me that he won't be able to join us today, but… That the… wait a minute. Simple as time. Yeah, so… He just told me that… That their mind has merged the FOCIL. And it's on FOCIL devnet-0 branch, so it should be ready for DevNet, but he hasn't tried interop with other clients yet. But they are passing all the tests. So, yeah, that's another mind. Do we have any updates from, perhaps, Lodestar?

NC: Yeah, so a while ago, of FOCIL devnet-0 branch was based on Of other 13, and I think… I think Mehdi was doing something interrupt below Star. I realized it was on to data 14, and I think Barnabas opened the PR Just update it. So, the FOCIL branch, is now 14. And… I did run some, simple kurtosis. The Teku, as well. I don't find any problem yet. Yeah, that's it from me.

Jihoon Song: Awesome, thank you. Cristian, I guess you wanted to share some updates for Lodestar?

Cristian Conache: Yeah, sorry.

Jihoon Song: Yeah.

Cristian Conache: Yeah, yeah. So, yeah, quick update, we're still in development. With March, a couple of PRs that we had, adding inclusion list or committee derivation and signature verification. Most of our FOCIL-related work is still in review, and, yeah, that's, the current status.

Jihoon Song: Got it, so I guess… We have Teku and Lodestar. And on the EL and on the EL, we have ethrex, Besu, and possibly Nethermind that we can try and drop. And we can also have Lighthouse as well, if it's ready. So… yeah. I think I can try… go call Introp, and if it's good, then we can move on for, DevNet, but it seems like… We have to set a new launch date for DevNet 0… 343? Not really, my understanding is 2x2. It's sufficient. So, as long as we can start… yeah, as long as we can. I mean, if local intro success… succeeds, then we can… Lunch Definite Zero,

Okay. Let me try it and see how it goes. Okay. Do we have any… comments. For client development, before we move on. Nico adds in the chat. Did anyone test the unhappy case yet? Maybe the one yet?

I think we can focus on happy paths for the first few dev notes, and then… Test unhappy cases. And the following debits. Alright, I think we can move on. prospect changes. Just as a reminder, PR55… it's on… it's all on the SL. PR5544… That changes IL force key to SLOT-independent Root was merged and included in alpha 14. And following yesterday's ACDE, I would like to ask for feedback on 5575. Sorry, 76.

So, we can go with 40, roughly 40 kibabytes for the build-to-peer limit, but I want to double-click And the gossip-sip rules that it adds. So, it adds conditions that check whether any transaction is empty, And… it's not in the code, but it's in the… in the task, it checks whether the transaction list is empty. So… I'm not sure about its practicality, but technically, it might reduce network bandwidth, but One thing that I want to emphasize is that this affects how we define valid inclusion list. So previously, any collection list that has transactions not exceeding 8KB with a valid signature was valid. But these checks will consider any IELs that has empty Transaction or empty TransactionList invalid.

So… I'm not so convinced by these new validity rules, but I would love to hear what others think about this.

Justin Florentine: Did we, where did the 40K number come from? It's, like, 5X, why do we think that's the right multiplier?

Jihoon Song: Yeah, just for the context. The max transaction size remains the same, 8KB, but on the CL, we need to impose some limit on period object. So, for example, for payload, we impose 10 megabytes limit, which is fairly high enough. And… it is just a… this very high upper bound, because payload size is dynamic. It varies depending on how many transactions you have in the payload. And similar to that, inclusion-based size. I mean… The period objects of inclusive size. Varies depending on how many transactions you have. So, that's why we need to put some limit on inconvenience as well. And that 40-ish gigabyt bytes come from the assumption that the minimum transaction size is 1 byte. I'm not sure whether this is technically correct, but if you calculate

the possible… Serialized in collateralist science. You will get, like, 40-ish kilobytes. Yeah, thanks, Justin. The calculation is in the chat.

Justin Florentine: I see it, yeah. Thank you. I don't really see anything controversial here, I guess this just kind of looks like a minor oversight that we're correcting?

Jihoon Song: Yes, previously we just said… We just assumed that there will be just one transaction in the list. It's just an oversight, yeah. So, we can also bike-shed that number, but it seems like just using 40KB is fine.

Justin Florentine: We forgot that lists were lists, that's all.

Jihoon Song: Yeah, but my question is, there's a… the PR wants to add a new check, Which is… Which is a condition that IELT should not contain any empty transaction. And… I wanna ask, like. what do we feel about adding this new task? I mean, sorry, adding this new… cousin rules.

Justin Traglia: Is there a path from which we can get an EL from an untrusted source? Which may provide an empty transaction.

Jihoon Song: But, you know, CL doesn't really… opine on… Transaction content. Like, we don't… the EL doesn't really see whether This transaction bytes is intrinsically valid. Of course, we're just checking whether it is non-zero, but… Yeah.

Justin Florentine: I'm having a hard time imagining a case where an EL would be correct, saying that this empty transaction should be included. I think… I think this seems like a… Correct filter.

Justin Traglia: I think June's trying to say that it's not the CL's responsibility to check this, right? Will this be caught elsewhere?

Justin Florentine: Yeah, that's fair, I have an EL bias.

Mehdi Aouadi: I personally see it as a defensive mechanism, right? It's not… I'm not strongly… against it, but I simply see it as a defensive mechanism, and it's okay. Got it.

Justin Florentine: Is… Jihoon… did you have a steel man in mind for including the empty transactions?

Jihoon Song: I think we need to distinguish two cases. Oh. Either it is empty Transaction or empty Transaction List. So the prior is, like, you have valid list of transactions, and you put An empty transaction in the list. On top of that. The letter is just… Empty enclosure list.

Justin Traglia: My opinion is that we should keep this empty transaction check for every transaction. Like, I think I agree with Mehdi that this is just a nice-to-have, and Transaction is opaque to us, the EL. So, like, this check is fine. In my opinion.

Justin Florentine: I agree with that. Fabio, you got an opinion on this? You spend a lot of time in transaction pools.

Fabio Di Fabio: I'm thinking this. A transaction with zero bytes Doesn't seem to make sense. So… It's… It's not that we are… Excluding some kind of use cases that could appear in the future. So, it seems safe. For me to have this track. We could also see in the spec that… Transaction should be at least one byte. in the Get Inclusion List, EnginePI method. If this is not yet the case. So, in my opinion, I don't see an issue. Checking that there are non-empty transactions.

Jihoon Song: I say, it seems like… We wanna add this. Empty Transaction Check. to add to that, Do we think that we also need to specify this in EnginePI spec? Like, the EL should return non-empty transactions. As Fabio mentioned.

Fabio Di Fabio: I… I suggest, too, because… Also, another… S… another EnginePI method. There is something that say the… Transaction to be valid should be at least 1 byte. So it seems consistent with also other, methods.

Justin Florentine: Yeah, given the state of the… RPC stuff, I would err on the side of overspecifying it.

Justin Traglia: That makes sense. I… I mean, I can try to argue against it, like. shouldn't it be implied that a ZRAB transaction will always be invalid? So, like, do you always say. the EL must not return an invalid execution payload, or an invalid transaction, or an invalid XYZ.

Justin Florentine: I think, though, this is… this would actually be carrying forward underlying specifications, right? So from a domain model perspective. I think it makes more sense to keep it… rigidly defined all through the different layers, right? Now, we're getting into API design aesthetics, so, I mean, I'm not gonna go to the mat on it, but, seeing how Hive tests, can be very, very subtle and nuanced in how they pass or fail on different clients. I would… I would just go through the, you know, two sentences that it takes to actually specify this on the RPC spec.

Justin Traglia: Yep, I mean, for what it's worth, I agree with you. When in doubt, be explicit.

Jihoon Song: Yeah, I can open a PR ad. Add some specifications. that are similar to other, like, new payload V1, as Fabio shared in the chat, that the EL should return, like, valid trans… enclosure transactions. do… do the EL people think that It's worth to have high tasks for… Get Enclosure list.

Fabio Di Fabio: Yeah, I think it's worth, because… Besu had an issue. with the Get Inclusion List and point. that Mehdi discovered. But not the EF test. We were passing EF tests. Even if we're at this bulk. So, yes. I suggest to include Crush on this test purpose.

Jihoon Song: Ivan is also supportive in the chat, but the thing is… GetIL is non-deterministic, so you cannot say that, given this. input, like, these transactions in the mempool, you cannot say this IL is expected, because technically, you can produce just empty IL. Of course, we can, Discuss this a bit later, but… Yeah, you can't… you just… Free to include just one transaction out of 10, for example.

Fabio Di Fabio: Yeah, I see your point. Indeed, so we cannot check the… content, fully? Maybe some, the syntax, or… some… Degenerate cases like the empty transaction. Without having to… Go and check. Which transactions are included or not, so… Because every client can choose their own implementation on this.

Justin Florentine: The other option would be to add a debug namespace method for… Actually, we have a test space, don't we? We have, like, a test space in the API? But the point is, is that the Hive test could actually explicitly Add a transaction to the mempool and say, hey, this is going to be, censored. Right? Like, you would kind of have to be constructing a debug-only path If you don't want to cover the underlying heuristics. with the clients, and I don't think that we do, right? I think… We intentionally want clients to have different censorship detection heuristics, right?

Jihoon Song: Yes, you're right.

Fabio Di Fabio: I'm not sure about the debug endpoint, because this… Possibly will not, cover the production code? Or at least, will not cover. All the production code, so… Could not be so effective.

Jihoon Song: I'm not super familiar with IF test code, but maybe we can… Have it, like, test whether it has valid transactions. But… is it… useful. Like, if you have this, then it might be… Flaky. Flaky as in, sometimes it might pass, sometimes it might fail if there's fog, so my point is… It could pass, even if there's a bug.

Justin Florentine: Yup. You know, if you modularize the censorship detection, that would be a good argument for allowing this. I don't know that that's realistic, but…

Jihoon Song: Could you expand a bit on the…

Justin Florentine: Yeah, so, like, you could have, you could… potentially clients could design it in such a way that something provides the censorship detection? Imagine, imagine a client that's actually not connected to the mempool, but is connected to, like, a private mempool. Right? That… private mempool needs a way to tell the execution engine, it says, hey, I see something that's being… being censored. And once you have that modularity, then your testing framework can abstract it out and say, for testing, I'm gonna use this, you know, silly blanket, but consistent across all clients. Heuristic for detecting censorship. Now, is that good enough for production? I think from a Hyatt perspective, it is.

Jihoon Song: So if I understood correctly, the test. speech the memo with certain transactions, and you're gonna specify you expect, like, transaction XYZ must be included.

Justin Florentine: Yes, or… You tell… you actually tell the client to censor that.

Jihoon Song: Interesting. Using some, like, debug API?

Justin Florentine: Yeah. I don't know. It seems like a lot of work to cover, like… Something that we're never actually gonna cover in production, right?

Jihoon Song: Yeah.

Justin Florentine: This is a good question, Jihoon. I thought it was a slam dunk, but yeah, obviously we would cover it in a hive test, but now I'm not so certain.

Jihoon Song: Yeah, I think… you know, this… Hive Test Simulator for IL. It's a… I heard that this is a new thing for… From, the EL… I mean, stills perspective. So, we were… actually, we were having this kind of discussion, like, do we really need this EIP test for IL? I don't think we need to conclude this today, but this is something we need to figure out down the road. I can relay some of his opinions. Distill, and maybe we can continue discussing this.

Justin Florentine: Yeah, along those lines, could we maybe run by ACD, you know, do we want to try to have… more deterministic rules Because I understand that the mempool itself is non-deterministic, right? You're never going to be able to view it, but if the heuristic itself was standardized, and I know that Marius and some other people on GetH have suggested that there's a very simple censorship detection algorithm. Right? That everybody could implement the same way. And if they did that, then you would at least have enough reliability in a hive test that you could deterministically test over it, right? Really, the only non-deterministic part of that scenario is, you know, mempool propagation, which we don't really care about in a Hive test.

So, a TLDR… How committed are we to having all the clients implement different heuristics for censorship detection?

Jihoon Song: Yeah, come on.

soispoke: Yeah, I think it's a good question. I think it's worth, like, discussing maybe a bit more, but… at the end of the day, I really don't think there is an objective function that actually allows to detect censorship, like, it's… It's always been heuristics, like, how… How many slots do you wait to basically… Say whether or not a transaction that's… been propagated is actually censored, like, I don't… I don't actually think there is, like, a… an exact metric Even, you know, where… when we had, like, the… OFAC sanctions and everything, and dashboards and everything, like, everyone was… it was actually a mess, because everyone was using their own metrics, so it was very hard to sort of, like.

know exactly what was going on, and I think it's always gonna be the case, so… For me, like, different clients having different rules. Has the advantage of, like. yeah, it's just, like, a bit more difficult to try to game it. Like, when you really have, like, the same heuristic across clients, then it's easier to sort of, like, try to design around it. But, you know, in the future, we might move Towards some more coordination. Or more shared rules across clients, because we might want to deal with, you know. overlap explicitly, like, have, have, like, you know, certain… certain committee members look at certain transactions, and, and, like, so we want… we might want to sort of, like, move towards this, but, like, as a first sort of, like, safe heuristic, safe…

first. try, I think, like, having slightly different rules makes sense. I'm not, like, against anything else, it's more, like, this was the thinking around it.

Justin Florentine: So why don't we just not cover it in the hive test, and make sure that it's covered elsewhere? I don't know, I think that's potentially reasonable. We'll see what PandaOps thinks about that, our testers. Nico, I see you tagged me in chat, I'm… what are you referring to? You're referring to the override builder flag?

Nico Flaig: Yeah, so this is quite old, right? It's, like, 2 years ago. I looked at the back references, and it seems like only Nethermind has had the PR for this. So I'm not even sure how useful this heuristic would be, or whether, like, ELs should just be kept simple, and you just put in based on priority fee, or whatever. Because this is something ELs could already be doing, right? To override the builder.

Justin Florentine: I think I see it. Thank you.

Jihoon Song: Yeah, I'm gonna discuss this with Steele, and then bring this up in… next All Core Devs call, so that we can get more input. Yeah. I wanna… Ask about the empty transaction list. I mean, it is basically empty IL. Do we want to also filter out empty IL?

Fabio Di Fabio: What do you mean by filter out? That is not a valid… Output for Get Inclusion List.

Jihoon Song: on… oh, sorry. On the SL, do you want to add a gossip rule that ignores any empty commercial list?

Justin Traglia: Right now, I'm thinking no. Done. That is a valid inclusion list, isn't it? They just don't have any opinions.

Justin Florentine: Which seems like spam to me, but…

Justin Traglia: Yeah, I sort of agree. Er, sorry, it's… I'm a bit… I'm a little on the fence.

Justin Florentine: Okay.

Jihoon Song: Yeah, it might be a bug.

soispoke: It's spam, but it's… it's spam, but it's limited spam, right? Like, you can only, sort of, like, spam with 16 hires that… Max. Is that right?

Jihoon Song: Yeah, and you can spam it only if you're an encoder.

soispoke: Yeah, exactly. But it's… I mean, I agree, it's still a spam at the end of the day, it's not like… But it's… and maybe we want to be… it to be very clean, sort of, like, filter it out, so it just, like, never happens, but I'm just saying, it's like, it's not like it's a huge DAS risk for the network or anything, like, you would need, like, the 16 included to somehow all submit. Like, empty inclusion lists that are probably, like, if… Very light, in terms of bandwidth consumption, and… So, yeah, just trying to say it's not a huge risk, not that we… Don't need to…

Justin Florentine: And it's not terribly actionable either, right? Like, you're not gonna disconnect an IL committee member.

soispoke: Yeah. It doesn't really do anything.

Jihoon Song: How about from… approaching from… validity perspective, like NC said in the chat, the EL might… if EL doesn't want to include any EL transaction, then it might send an MTIL, or just send nothing. So… an empty… an IL being empty doesn't mean that it is invalid as of today, unless we add this new rule. to put it differently, if an encoder sends an empty IL? Technically, it did its duty, It's just… at… no value. to… Do they have transactions?

Justin Florentine: But now you're building, like, a censorship watchdog, which… Maybe it's okay. But you're taking the overhead of, like, a heartbeat that's kind of going out, saying, all good, all good, all good.

soispoke: I mean, I… I think it's… Yeah, you have two ways to look at it, I guess, like… First way is, like, it's worse for the network if you send something that's empty than not send anything, just because… I mean, the network still has to, like, process it and send it around, even if it's very light and doesn't really cause a lot of trouble. Meow. Like… I don't know. I would rather, like, people not sending anything if they just, like, don't want to do their duty, and we can flag it. And, like, use that to sort of, like, know who's censoring or not anyways, like, because it's very… obvious, Yeah, I guess, like, the only sort of, like, use case is, like, someone wanting to actually, sort of, like, signal that they are censoring. Like, there is no… there is no way there was a bug, and I was actually offline, and I couldn't do my duty, but I was, like… I actually advocate

For… and I want to sort of, like, signal I'm censoring by sending empty inclusion lists all the time, but, yeah, it feels pretty niche.

Justin Traglia: I was thinking they would signal that there just aren't any transactions at the moment, but I'm still doing my duty. different.

soispoke: Yeah, maybe.

Justin Traglia: It's not like it's recorded anywhere in the protocol, so what does it matter?

soispoke: Yeah.

Justin Traglia: If I need to give an opinion, I think I would… lean towards adding an ignore statement for empty inclusion lists, June. That would be mine.

Jihoon Song: I see. So… We're gonna add to… you gossip rules. One is checking whether any transaction is empty, and the second one is checking whether this enclosure list is empty.

Justin Traglia: Yep. To be clear, we would reject MT transactions and ignore MT inclusion lists. One is… Feasibly valid, and the other is never valid.

Jihoon Song: Right.

Justin Florentine: Yeah, I'd say it's malformed, right?

Jihoon Song: Yep. Yeah. It's like, yeah. easy… easy check that EL can do regarding transactions, validity.

Justin Traglia: Yep.

soispoke: I think it's maybe more of a high-level comment, so I'm not sure how actionable it is, but, like. One… maybe one design… Philosophy we would have here is, like, just trying to design it as if we had Rewards or penalties for… for inclus. Like, obviously, like, There is a world in which you could have penalties for not submitting A valid inclusion list, or something like this. So it feels nice to maybe, like. Even if we never end up doing this, but, like, Design with this in mind, so… If we need to plug it in later, like, we need to plug in… rewards and penalties later. We have, like, the sort of, like, infrastructure underlying it that is, like, sort of, like, clean and…

And easy to build on for, for things.

Jihoon Song: That's really a good point. But… In my opinion. If you were to consider… some incentive mechanism for encoder, then maybe we… it's better to accept empty encoder list? Of course. I don't know. It depends on how we design it. Like, if… if we distribute some incentive. proportional to how many transactions in the IL is included in the payload, and how many other includeers also put it in there, so on and so forth. Then maybe FDIL is, like… Yeah, go ahead.

Justin Traglia: That creates weird incentives, like, they may just, Detect that they are an included in an upcoming slot, and then spam transactions, which they can then include themselves or something. Right.

soispoke: Yeah, yeah. Yeah, I think, yeah, I really didn't want to get into the incentives question, I think it's very, very hard, but I guess my high-level take was more, like, if we need to sort of somehow design something on top of it, like, maybe that can be a guideline for how to sort of, like. implement these things, but I also agree, like, it… ultimately, it also very much depends on the exact type of rewards and penalties we want to get in. It was more like.

Justin Traglia: Yeah. It's a good point to make.

Justin Florentine: I'm all for, like, designing towards something, which I think is how I would describe what Tama is suggesting. However, in this particular problem space, I find it very difficult to imagine Ways to accommodate incentives or punishments. For a lot of these things, because there's so many… there's so many cases where we have to prove negatives. And the thing that we're proving over is also non-deterministic, the memorable, right? So I'm a little on the skeptical side that… We will know in advance how to color our designs to move them toward A world where we can reward or punish inclusors.

Jihoon Song: I see. Justin, do you want to add something?

Justin Traglia: Shh, sure, I mean, I was gonna say… I mean, yeah, what you guys are saying makes sense, but I don't think that there are gonna be rewards for includeers in the foreseeable future, and if there are, we could just, remove an empty inclusion list check in the future. Like, that's not too hard.

Jihoon Song: Yeah, that also makes sense. So, Can I summarize that we are okay with adding this to emptiness checks? Reject for empty transaction, and ignore for empty IL.

Justin Traglia: Yep, for me.

Jihoon Song: Thumbs ups. Right. Cool. Thank you very much, This is all I had for spec discussion. Do we have any other comments or questions? Yeah, Tala.

soispoke: Yeah, sorry, it wasn't in the agenda, but it's gonna be very fast. I just wanted to… flag this sort of, like, EIP that's still not merged, but, like, and there is a lot of you that have already sort of, like, looked at it and contributed. But, yeah, it will benefit from… more eyes from FOCIL experts, so for anyone that hasn't, sort of, like, seen it or looked at it, it's, It's an AP… that is mostly targeted at understanding how FOCIL and frames interact, and now that they are SFI'd, I think it would be nice to sort of, like, get input on… on that one. So, yeah, just, like…

Jihoon Song: Yep, awesome. Thanks for sharing. So, assuming that… frame Transaction is gonna get SFI'd. We need to figure out… how… Frame Transaction, and FOCIL we're gonna track. And this is, proposed solution to enable the interaction. As far as I know, ethrex is actively working on prototyping and… Back in this effort. So… Please take a look if you are also interested. And maybe we can also discuss it in, like, featured, breakouts. Possible they have… Fossil and Frames, DevNet, like, a couple of months or something.

Justin Florentine: Frames, Breakout calls right after this one.

Jihoon Song: Indeed, in 10 minutes.

Justin Florentine: Is this VOPS thing? Is this, what we're using to refer to trying to not break the mempool with frames?

soispoke: No. VOPS is a validity-only partial state. So… yeah, it's basically the part of the state that will… that mempool… that mempool nodes will need to keep storing, just to make sure they can evaluate whether transactions are valid or not.

Justin Florentine: Yeah.

soispoke: So, with regular transactions, it's obviously quite easy, it's, like, basically non-s and balance. But, you know, with frames, it gets way, way more difficult. So it's trying to sort of, like, get around it, yeah.

Justin Florentine: Yeah, that's what I meant, okay. Yeah, this is a whole problem space.

soispoke: Yes, yes.

Justin Florentine: Huh?

Jihoon Song: Yeah, I guess… Frame Transaction Breakout might be busy with discussing with, 81.30, so maybe we could use next Breakout to, you know. go over this 8369, if Tom has some time, and maybe we can have some Q&A.

soispoke: Yeah, definitely, happy to.

Jihoon Song: Okay, great. Any other comments, or… Questions? All right, thank you everyone for joining. I'm gonna try local interop and see how it goes. And, yeah, have a great rest of your day, and see you in two weeks.

soispoke: Thank you. Bye.

Mehdi Aouadi: Hi, everyone.

Fabio Di Fabio: Bye.

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