Mercy Boma Naps-Nkari:Good afternoon, everyone. Welcome to RPC Standard Call 23, and…
Transcript
Mercy Boma Naps-Nkari:In our agenda, let me share the agenda for today.
Mercy Boma Naps-Nkari:We'll be having a presentation by Julian.
Mercy Boma Naps-Nkari:on FCR.
Mercy Boma Naps-Nkari:I shared a link to the agenda, and then I think we can start.
Julian Ma:Okay, perfect. Give me one second.
Julian Ma:So, you should be able to see my screen now. Yeah, so thanks all for having me here, and I'd like to present a bit on the fast confirmation rule, which is a new rule that the Ethereum Foundation is rolling out in the next month or two.
Julian Ma:What it does is it decreases confirmation time from 13 seconds to 13 seconds. So it gives you a very strong Layer 1 confirmation within 13 seconds, which is about a 98% reduction from the 13-minute time to finality.
Julian Ma:This is a great benefit for many types of users. So, first of all, exchanges. What it means is that if someone deposits
Julian Ma:ETH from, let's say, Ethereum mainnet to a centralized exchange like Coinbase. Their deposits can be credited way faster than they could today. And it also means that they face less risk, because the exchanges today typically wait for a few blocks instead of actually waiting for a finality.
Julian Ma:And this is very unsafe, whereas using the fast information rule gives you a provably safe guarantee under its assumptions that a block won't be reorged, which means that it's easier to do the risk management.
Julian Ma:The faster deposits argument actually holds for L2s and cross-strain bridges as well. We'd like… we're approaching L2s to figure out whether FCR is a good fit for them, and see if they want to adopt it. That would mean that instead of following the chain with a few-minute delay, as most L2s have today, they would follow the chain within 13 seconds, which would be way faster, and would mean that if you deposit
Julian Ma:some assets on Ethereum in the canonical bridge to, let's say, Arbitrum, they would be credited way faster than Arbitrum.
Julian Ma:Interestingly, L2s have different benefits as well, which is better pricing. And this… because L2s, follow the L1 with some delay today, they have a delayed price as well.
Julian Ma:So, for example, Arbitrum has a sequencer which only sees the latest, updated blob price from the last blob that it considers confirmed, which could be, let's say, like, 7 minutes ago.
Julian Ma:And that means that the price is very much out of date.
Julian Ma:With FCR, they can get a very updated price, which means it's easier for them to price, their L2 block space to their users.
Julian Ma:FCR does come with additional assumptions over a finality, and these assumptions are synchrony, which means that attestations in the network are delivered within 8 seconds.
Julian Ma:Which holds most of the time. It basically holds when the network is functioning well, and there aren't any, I don't know, like, very large-scale internet outages or DOS attacks on the network.
Julian Ma:And the second assumption is that there's no adversary with more than 25% stake.
Julian Ma:This would mean that there would be an adversary that would have more than about 22 billion US dollars worth of ETH state at this point in time, and, yeah, that's something that's unlikely to happen.
Julian Ma:These are the safety assumptions, and if these two assumptions hold, so if the network is synchronous, and there isn't an adversary with more than 25% stake trying to attack the faster information rule, then any fast confirmed block will be finalized with certainty. So…
Julian Ma:The faster confirmation rule is not something probabilistic, it's not a probabilistic guarantee, it's a deterministic guarantee. Any fast-confirmed block will be finalized with certainty if the assumptions hold.
Julian Ma:And only under very extreme network circumstances, like network asynchrony, or that there actually is an adversary with sufficient state to attack it, will a fast confirm block be reorged. So safety-wise, fast confirmation rules is very, very safe.
Julian Ma:We can see here on the next slide, which is the liveness assumption slide, in the top, there's a cumulative distribution function of how long it takes to fast confirm a block, and this is based on, take your node, running the fast confirmation rule, over a 24-hour time span.
Julian Ma:And we can see that about 94-95% of blocks are fast-confirmed, within 12 seconds.
Julian Ma:And we see that some… for some blocks, it takes slightly longer, so it might take 2 blocks to fast confirm them, or even three, but it approaches 100% quite fast.
Julian Ma:And this is because it could be that there is some network distortions, that means that there's maybe a lower participation rate, which means it takes slightly longer to fast confirm a load.
Julian Ma:And in fact, our liveness assumptions are as follows.
Julian Ma:If there is an adversary with more than 5% stake, it would take at least 2 slots to fast confirm a block. If there were an adversary with more than 50% stake, it would take at least 3 slots to fast confirm a block. And if there were an adversary with more than 20% stake, it would take at least 5 blocks to fast confirm a block.
Julian Ma:This is what you can see in the bottom figure. And so the liveness assumptions and the safety assumptions are slightly different.
Julian Ma:An adversary with less than 25% state, but more than 5, could cause a slight delay to how long it takes a fast confirm your block, but only an adversary with more than 25% state, or if the network is asynchronous, could actually cause a fast confirm block to be reordered.
Julian Ma:So I hope that's clear, and we can see that, again, for, like, 95% of cases, blocks are fast confirmed within 12 seconds.
Julian Ma:And so how do we actually get, a lot better guarantee than, or at least time-wise than finality, which again takes 13 minutes?
Julian Ma:It's because instead of counting blocks, which people do, for example, today as they wait for exchanges to credit deposits, we count attestations, which… and as we know, of course, attestations actually contribute to the four-choice weights, and so they actually contribute to safety, whereas blocks are a more crude measure.
Julian Ma:Counting attestations is what we call the dominance check here, and next to the dominance check, we also do a robustness check.
Julian Ma:What the robustness check does is it checks that, for example, EPOT boundaries, whether slashing was incorporated well, and it checks whether the last fast confirmed block was not too long ago.
Julian Ma:The goal of these robustness checks is to see whether there's any, weird things happening in the network, and so basically what we're trying to figure out is whether the network actually is synchronous.
Julian Ma:There are some cases in which we can catch that the network isn't synchronous, although we can't catch it in all cases. But if these robustness checks don't fill… if these robustness checks pass, so they don't fill, then a block can safely be fast confirmed.
Julian Ma:And now I'd like to compare the faster information rule a little bit with KDeep, which is what many exchanges and L2s use today, where they just wait for a few blocks until they confirm something, and finality.
Julian Ma:So, KDEP and the FASC information rule both, assumes network synchrony, whereas Finality actually also works with network asynchrony.
Julian Ma:Interestingly, KD doesn't have a known adversarial threshold, so it's unknown how safe the rule actually is, and it gives very little guarantees in that sense. The adversarial threshold from the FCR information rule is quite similar to that of finality. It's an 8% percentage point difference, and so, yeah, it's 25%.
Julian Ma:Importantly, also, faster information rule doesn't have any economic security, so it's not like if a faster block does get viewed in the extremely unlikely event that it were to happen, that anyone would actually get slashed.
Julian Ma:It's, yeah. The trade-off here is that FCR has slightly, weaker assumptions, but you get a huge latency decrease. So you go from 13 minutes to 13 seconds, which is faster than the K deep as well for most K, because many places wait for a few amounts of blocks before they can fast confirm something.
Julian Ma:So, the FCR is faster and proven safe, as opposed to KDeep.
Julian Ma:Implementation for L2s, exchanges, and bridges is, like, extremely easy. Basically, what they do is they enable the flag in their clients, and then they can immediately query, and what we have actually done is that we're repurposing the safe block tag.
Julian Ma:And, which is today is used for justification, and we're repurposing that for the faster information rule.
Julian Ma:We're doing so because we believe that the faster information rule provides a better rule for users, as it's way faster than justification, and justification also doesn't have proven guarantees around it.
Julian Ma:The nice thing here is that RPCs will immediately support the faster information rule, and there's actually no implementation work that they need to do. What is left is that they need to inform their customers about the change that's happening, and this is where we're here to support.
Julian Ma:So the next steps are, is that we're establishing the faster information rule as a new industry standard for L2s and exchanges. We're talking with lots of L2s and with lots of exchanges, so our PC providers might expect some inbound from these users.
Julian Ma:The first clients will be ready for testing around the end of March, and we expect that the faster information rule will be used in production in Q2.
Julian Ma:The interesting thing is that there's actually no hard work required for the faster information rule. Instead, it's a rule that's nodes run locally, so it's not a global rule like finality is.
Julian Ma:This means that as soon as the client is ready, so for example, Prism passed all of their tests today, that, client could,
Julian Ma:rollouts, the faster information will go very fast. Just to be clear, Prism isn't rolling it out today, but it should be that Prism is rolling it out faster than some other consensus clients. And this may have an impact on you as an RPC provider, because it could be that different clients now return different safe plots, whereas
Julian Ma:some older clients still return the last justifier block, and the newer client returns the last fast confirmed block. So it's just good to be aware of this, and to ensure that,
Julian Ma:Customers are supported in the transition.
Julian Ma:We're here to support RPCs in informing our customers and ensuring that there is a smooth transition, and yeah, I'd love to hear if there's any questions. We have a website called FastConfirm.it, and there you can find one-pagers with information
Julian Ma:for all of the customer types, so for example, L2s, exchanges, and bridges, so that they have all of the information that they need.
Julian Ma:Okay, that was it. I see that, Felix, you have a question?
Felix (Geth):Yes, can you hear me, actually?
Julian Ma:Yeah, I can hear you.
Felix (Geth):Okay, sorry, I am driving, but, so just a quick question. I missed the beginning of this presentation, but, one thing you should know is that the JSON RPC API, which this call is about, is served by the execution clients. Can the fast confirmation rule be implemented in the execution client?
Julian Ma:So it's a consensus layer rule, but from what I understand is if the consensus layer client implements it, it can be queried via the execution layer client, because it is repurposing the safe block tag, so it's reusing something existing instead of creating a new tag in that sense.
Felix (Geth):Okay, interesting, okay, nice, yeah. So basically, the consensus client relays to the execution client what is the current safe block, but the algorithm for determining the safe block changes with this proposal.
Julian Ma:Yes, exactly. So today, it returns the latest justified block, and when implemented, it will return the latest FastConfirm block.
Felix (Geth):Okay, thank you.
Julian Ma:Yeah, feel free to ask JVN.
jvn:Yeah. Yeah, sure, am I audible?
Julian Ma:You're all available.
jvn:Yeah, just wanted to know. So now, are we removing the concept of justification and finalization from the protocol itself?
jvn:So, just… that's the first part, and the second one, so if we say around 13 seconds, in most cases, if it's fast confirmed in 26 seconds, I'm assuming there won't be no reacts more than 2 blocks on more than 99% of the cases.
jvn:And, what about, like, currently attesters are voting afterwards? Like, now, for a block-in, there are…
jvn:what as we're testing for it on block N plus 2. What are we doing here on these cases?
Julian Ma:Okay, let me get to your first two questions first, and I didn't fully hear the last one, so maybe if you could repeat that one afterwards. So we're not removing the concept of finality from Ethereum. The faster information rule is different. It has different assumptions, and it gives you a different latency, so it's a trade-off that users can make.
Julian Ma:For many of them, the faster information rule will be very good, but some of them might want to wait for a full finality.
Julian Ma:we are removing justification from, like, the RPC endpoints from the nodes, and so we're repurposing that one for the faster information rule.
Julian Ma:Secondly, around, whether it's safe. The thing is that if the assumptions hold, a fast and firm block will never be reorged, and so deterministically, it will be finalized.
Julian Ma:that's, that means that, yes, for the 99% of cases where if a block is fast confirmed, there won't be a deep reord.
Julian Ma:for the cases where a block isn't fast confirmed, it could be that there is a reorg. And this is actually, I think, quite a nice feature of the FCR confirmation rule. There's, like, a sort of a safety net here, so if you don't get sufficiently many attestations, in which case the reorg is more likely to happen, right?
Julian Ma:In that case, we actually don't fast confirm a block, either within 13 seconds and we wait a bit, or if the network is doing very poorly and we're really getting very few attestations, eventually the fast confirmation will actually fall back to finality.
Julian Ma:And so, FCR has, like, a built-in safety net. That means that it's extremely unlikely for a VOR to be affected. And if you could repeat the third question, I couldn't hear that one fully.
jvn:Yeah, sure. So, yeah, your second part actually answered my third question. So, if you don't get sufficient confirmations or attestations, we move the IFCR something. Yeah, that was my third question. It actually answers it.
Julian Ma:Okay, perfect.
jvn:Got it. So we are kind of replacing the justification by this past confirmed rule.
Julian Ma:Yes, that's fair.
jvn:Excited.
jvn:Okay, good. Thank you.
Mercy Boma Naps-Nkari:Okay, I guess that would be all. I don't know if anyone has any other questions in regards to FCR.
Julian Ma:Okay, thanks. I've got my Telegram in the chat if anyone has any questions.
Julian Ma:Thanks, Mason.
Mercy Boma Naps-Nkari:Okay, thank you. Thank you very much, Elena, for the presentation.
Mercy Boma Naps-Nkari:And I think we can move over to the next agenda, but,
Mercy Boma Naps-Nkari:Which is this. So, since Felix is driving, I don't know, Clara, thank you for coming back,
Mercy Boma Naps-Nkari:We need to discuss about this PR, and then some issues.
Mercy Boma Naps-Nkari:Which is this.
Mercy Boma Naps-Nkari:So, and then on the other hand, while I share the links, Sims, you… the error code sphere was meshed today, so is there something else you would like to…
Mercy Boma Naps-Nkari:point out.
Simsonraj Easvarasakthi:No, thanks for merging that, Felix, and I'll start working on the next steps, which will be…
Simsonraj Easvarasakthi:RPC test gen, and eventually the actual tests.
Simsonraj Easvarasakthi:But yeah, I'm glad it's merged, so I can work on the next steps.
Mercy Boma Naps-Nkari:Okay, do we need to talk to clients about this? Like, make a sort of an announcement, or to inform them about this?
Simsonraj Easvarasakthi:Yeah, yeah, we can do that.
Simsonraj Easvarasakthi:by… I guess, they won't be actually implementing it without a test. I think we discussed this kind of already, but I think it is definitely good to give a heads up. It is coming, and it is merged, and people can start implementing it if they want to.
Mercy Boma Naps-Nkari:Okay, thank you.
Simsonraj Easvarasakthi:Thanks, Mosey.
Mercy Boma Naps-Nkari:So, although, Chase, you did share, this
Mercy Boma Naps-Nkari:PRs and these issues. I don't know if you want to say anything about it, but I think Felix is driving, I'm not sure he will be able to, like, look through it.
Chase Wright:Yeah, so…
Felix (Geth):I checked it, and so you posted one about the… the first one you posted is about the testing build block?
Felix (Geth):Yep.
Chase Wright:Yeah.
Mercy Boma Naps-Nkari:Yes.
Felix (Geth):I mean, as far as I understand, this is now implemented already, so we can just merge it, I guess.
Chase Wright:Yeah, I'll fix the conflicts, the… because you merged stuff this morning, I'll fix the conflicts, and then we just need someone to merge it.
Felix (Geth):Yeah, so notably, we need to kind of decide how we're gonna… I think this might be a good time to figure out, also, like, get started figuring out this whole, spec profiles thing, because this testing build block method, I mean…
Felix (Geth):we expect this to be implemented by the execution clients, I guess, but this isn't really something that, like, every endpoint… I mean, it's more, like, adjacent to the engine API, I guess.
Felix (Geth):So basically, what I was trying to say is just that when…
Felix (Geth):If you're a client that implements the engine API, then you also have to implement this method, but if you don't, then this is not required. But right now, we can't really… there isn't really a way for us to… to tell that inside of the spec.
Chase Wright:So, is your assumption that we need to do something, like, globally, within the repo and the spec, to suggest that
Chase Wright:Entire methods and namespaces are just optional?
Felix (Geth):Yeah, I mean, we discussed it kind of before, that there is this whole, idea to potentially split up the spec into different profiles, which are implemented by different entities. So, at the moment, for example, we have things like the ETH namespace.
Felix (Geth):and things related with that. So they are obviously supposed to be implemented by the execution clients, but also, for example, the RPC providers. But then we also have the engine API, which is kind of a mechanism
Felix (Geth):used to communicate with… between the consensus layer and the execution layer, the RPC providers don't have to provide this API. So, it's a bit strange that we have the spec that has, like, everything. And so, for… we wanted to… we will…
Felix (Geth):one to introduce a technical mechanism that allows us to generate two different specs. Like, one for these, that includes, like, the engine API, and one that is basically only the actual
Felix (Geth):access.
Felix (Geth):And, I mean, I'm just mentioning this because, like, with this API, I mean, it's called Testing Build Block. It's maybe clear that, you know, this falls more with the engine API, but it's not in the engine namespace. It's, like, in its own namespace testing, which is basically kind of a one-off, as far as I understand.
Chase Wright:Yeah, I mean, it's a… it's a good point, but I don't… I mean, that's gonna be a lot of,
Chase Wright:It's gonna be a lot of work, but…
Chase Wright:yeah, I… I more or less agree, because we also need to, like…
Chase Wright:Account for the fact that certain clients may… might diverge, and… You know, like.
Chase Wright:like, Ethrex doesn't want to support, like, pre-merge…
Chase Wright:stuff, right? So, I think it makes.
Felix (Geth):Yeah, yeah.
Chase Wright:that we should do this kind of stuff, but I don't think we're gonna solve that on the call.
Felix (Geth):No, no, no, no! That was not my intention, I just wanted to bring it up, because I, like, I just always like to bring up the adjacent topics with this, because, yeah, I mean, this method, it's good, but, I mean, for example, it's also pretty clear we're not going to be adding any, like, normal RPC tests for this method, because it is, like.
Felix (Geth):it exists, like, and we also don't use RPC TestGen to test the engine API, for example, because it has, like, another purpose.
Felix (Geth):So this is something that I just wanted to make clear, that, like, it falls more in, like, this family, and…
Felix (Geth):Yeah
Felix (Geth):Anyway, we can move on now. I can just… I mean, as soon as the conflicts are resolved, I think I can just merge this, it's okay.
Chase Wright:Yeah, I'll do it right after the call.
Mercy Boma Naps-Nkari:Okay, I think the next one will have, like, beads… 756.
Mercy Boma Naps-Nkari:This one.
Mercy Boma Naps-Nkari:And that should be get storage values.
Felix (Geth):Yes, so I'm a bit curious about this. So, I mean, it is now implemented by several clients, I guess?
Mercy Boma Naps-Nkari:Yeah.
Chase Wright:Yeah, yeah, so I know… so it's already merged in Geth, I know Reth also has it. I'm working on a PR for Nethermind,
Chase Wright:I don't… I don't know about Erigon right this second, but I mean…
Tullio | Erigon:We have it, we have it.
Chase Wright:You got it? Okay. So, unless there's actual objections to it, it's already merged in clients, and I assume it's fine.
Felix (Geth):Yeah, I mean, it sounds great that this is going so fast.
Felix (Geth):I… I mean, that's… that's… that's very nice.
Felix (Geth):So, I mean, what's the next action here? Also, it should just be merged, or it requires some more…
Felix (Geth):discussions, or… I mean, basically, I didn't have time to look into this PR a whole lot.
Mercy Boma Naps-Nkari:I think we can merge it, then for clients that don't have it yet, we can…
Mercy Boma Naps-Nkari:signified, but I think majority of the clients already has this.
Mercy Boma Naps-Nkari:Your dad is.
Chase Wright:Yeah, like, like I said, most of the clients already have it, so, like, merging it probably won't…
Chase Wright:ruin anybody's hive test, except Nethermine, but I have a… I have the code already, I was gonna push a PR up to Nethermine and ask them to look at it today, so…
Chase Wright:There's re… There's really no reason not to merge it unless…
Chase Wright:one of the other client teams complains, but I don't… I don't see that happening.
Chase Wright:It's a very… it's a very small change.
Felix (Geth):Yeah, nice. Yeah, yeah, I mean, definitely we can get that in also.
Chase Wright:Geth already has it. It's already merged.
Felix (Geth):Yeah, I know, I mean the spec. We have to watch the spec, right? I, I, I understand we have it…
Felix (Geth):Yes.
Mercy Boma Naps-Nkari:So, before we go on, I have something else to say in regards to this 297. So, I did reach out to, the CL clients, and then the only people that
Mercy Boma Naps-Nkari:responded was Luster and then Nimbus. Loster doesn't have an issue implementing this, or 297 or 302, but the question is, he, Nicole did end up saying, do we actually need this, or we can just close the, PR entirely?
Mercy Boma Naps-Nkari:But I'm not sure how else we can go about this, since the only two clients that has responded so far is just Losta and Nimbus and
Mercy Boma Naps-Nkari:the two, options they chose are not like,
Mercy Boma Naps-Nkari:They are not agreeing to each other, although Lodestar doesn't mind in agreeing with Nimbus, but I'm not sure what exactly to do in this case, where we don't have a consensus on what to do.
Chase Wright:Sorry, which one are you talking about specifically? Which pair?
Mercy Boma Naps-Nkari:2297, the JW2Secrets.
Chase Wright:Oh… Yeah, I don't know.
Mercy Boma Naps-Nkari:It's an old… it's an old PR.
Chase Wright:Yeah.
Chase Wright:I mean, it's so old that, like…
Chase Wright:And no one seems to care. The last comment's 2023, like…
Felix (Geth):I mean, so we kind of agreed a while earlier that, like, this is kind of… this is going to be the strategy. We do have to process these things, and I do think it makes sense to bring it up another time.
Felix (Geth):But if… if… basically, what has to happen here is that we have to, solicit some recent comments from current clients, and if they cannot agree on it, then we either have to drop it, or we have to bring it up on a wider forum.
Felix (Geth):So the playbook, basically, for these kinds of things is always the same.
Felix (Geth):Yep.
Mercy Boma Naps-Nkari:Yeah, I did bring it up to ACDC. That was last Thursday.
Felix (Geth):So…
Mercy Boma Naps-Nkari:The thing is, not everybody actually, like, went through it. Then, before then, before ACDC last Thursday, I brought it up, because I think the other ACDC call that was supposed to happen before this last one was canceled.
Mercy Boma Naps-Nkari:So, I sent it, as a message on the Discord channel. Lodestar and Nimbus commented on it.
Mercy Boma Naps-Nkari:Luster says they don't have any issue. Then Nimbus complained about some complexities that has to do with, I think, 302 or this 297.
Mercy Boma Naps-Nkari:Now, the thing is, I sent a link here to, an issue Nico tagged me to.
Mercy Boma Naps-Nkari:So, he was saying, if this is really important, it's been, like, for… since 3 years back, if it is not important, we can drop it. Because nobody's really saying anything about it. The only people that left a comment on it is Losta and Nimbus.
Mercy Boma Naps-Nkari:So… I'm not exactly sure how we can…
Mercy Boma Naps-Nkari:But I did bring it up to ACDC. I did…
Felix (Geth):Okay, well, that's great. So in that case, there isn't really anything more we can do. Basically, we have… it is just… I think from this group, the… basically, our job is to float these ideas to the client developers, and if they are just
Felix (Geth):simply not interested in it, then we just have to close the issue, because we cannot make it happen. And if it turns out to be so important, then someone else will come back to propose it another time.
Felix (Geth):So that's kind of how I see it. It just…
Felix (Geth):we just don't have another option, like, we cannot just keep bringing it up also, because I don't think that it will change. So maybe the right course of action now is just to close the issue.
Mercy Boma Naps-Nkari:Yeah, that's the same thing he said, so…
Mercy Boma Naps-Nkari:I think we can close it, and then I can inform him also on it.
Mercy Boma Naps-Nkari:Thank you. Then the next one should be,
Mercy Boma Naps-Nkari:771, I think.
Felix (Geth):Wait, is this the get transaction by a nonce one?
Chase Wright:Yes.
Felix (Geth):Yeah, so with this one, it's kind of… it has some… the issue that you need to have a separate index for it. And this index in Geth, definitely we don't have it. And as far as I understand, NetherMind also doesn't have it. So…
Felix (Geth):I mean, the idea itself is not bad, but the implementation is definitely gonna be more than just adding an endpoint. Like, it's not possible right now to create this endpoint in, like, any… any…
Felix (Geth):way in Geth, so we would have to do some engineering to actually get this in. So the indexing of transactions has to be updated to also store the index, and the index has to be managed, and so on. I'm not saying this can't be done, but definitely,
Felix (Geth):not something that I… I can just commit to, like, right away, that, like, this is gonna happen, like, anytime soon.
Chase Wright:Yeah, that's totally fair. The issue's been open for a while, and people have wanted it. Someone created a Geth PR for it, and that was what encouraged me to write the test. So…
Chase Wright:I don't have a lot of skin in the game. I just looked at there's an issue for it, there's a PR for it, and…
Chase Wright:You know, so how can I help move it forward by creating tests and spec? So I did that. It's in draft because the Geth PR is also, not merged and hasn't been reviewed, so…
Chase Wright:The only thing I'm bringing up here is that we need someone to actually review the implementation and figure out
Chase Wright:Is it good? Do we want to do it or not? And… and then we can go from there. I don't have any issues with this sitting in draft until a decision is made.
Felix (Geth):Yeah, I would be curious a bit to hear the use cases for this method. I mean, it is kind of,
Felix (Geth):Basically, it allows you to iterate the transactions of an account, or… What's.
Chase Wright:Yeah, so the actual issue that it is linked to has a bunch of documentation about why they want it, and there's a big discussion in the issue. So I… you could review that, I guess.
Felix (Geth):Yeah, sorry, I cannot review it right now, but, I mean, definitely, I will also review it later.
Chase Wright:Yeah.
Felix (Geth):I wish I I'm curious if there's, like, any kind of, like, really compelling argument for this.
Felix (Geth):Like.
Chase Wright:Yeah, so, I mean…
Chase Wright:In the original issue, there are diagrams, there are workflows, there are reasons why they want it, and other people have chimed in, app developers, so you can review it when you have time.
Mercy Boma Naps-Nkari:Hi, Jeffrey, and you can… your hands are raised.
jvn:Yeah, sure. So, basically, I can quickly summarize it on that. So, this get transaction by sender and loans is basically… so, to get the transaction as from,
jvn:the sender and the, non-soft sender. It's basically… it's currently for the use of valid, so currently what they are, like, assuming is,
jvn:Valid, once they get the transaction, they send the transaction to the node, and there is a possibility, that the valid doesn't send the transaction hash again to the end customer.
jvn:So now the end customer, even though the transaction was already broadcasted to the node, this end customer or the third party doesn't have a way to actually get that transaction hash again.
jvn:So, this was a problem in some of the valid use cases.
jvn:So, certain wallets, what it does is, it sends the hash before and before it sends the, before it sends the transaction to the node itself, but there are certain wallet implementations where it sends to the node, and after the, after it's gone into the mempool, it sends the hash to the,
jvn:libraries and stuff, all the… you need the daps and stuff. So if that… if that one fails, the tab has no way of knowing the hash again.
jvn:So, this kind of,
jvn:So if that particular transaction didn't go into the block, so this, RPC basically helps the, so the DAP can query the transaction as just by giving the non-sender
jvn:The center address, which the tab already knows beforehand.
jvn:To give a quick summary of what…
jvn:the… it's all soft. Yeah. I hope… Yeah, thank you.
Felix (Geth):I mean, it's useful to hear this, but at the same time, it doesn't really inspire the confidence from my side, because, for example, it is tech… I mean, the… if you are submitting transaction to Ethereum, probably you should know the hash of the transaction before you send it. Like, you're not in any way dependent on the node to tell you the hash.
Felix (Geth):Like, usually you just already know what the hash is gonna be, because it is literally just…
Felix (Geth):The hash of what you are sending.
Felix (Geth):Like, I mean, you know what I mean? It's like, typically the node, like.
Felix (Geth):the app will send a transaction by invoking the send transaction by hash, but the Ethereum transaction hash is literally just the hash of the input to send raw transaction. So they could just hash that input, and then they would have the return value. So that's not very, like…
Felix (Geth):That doesn't really make me very confident that, like, this… this endpoint is needed just for this exact case. It basically just seems to be, like, a software issue where some wallets are architected so that it might actually forget this hash somehow. Like, it might forget what transaction it already sent before.
Felix (Geth):And then it kind of wants to re-initialize itself, from the chain state.
Felix (Geth):I'm not against it, but I'm basically also want to make you aware that, like, implementing this requires, like I said, an additional index on the client, and it's basically an information that can be derived from the chain by indexing it.
Felix (Geth):So…
Felix (Geth):if the app wanted to know, like, all of the recent transactions in the chain, it could just iterate the chain and index it by itself on their side, stuff like that. So there are other solutions for it. It's not like a critical service that has to be provided by the execution node.
Felix (Geth):At the same time, I mean, so I would… basically, I would rate it more as a, like, convenience feature.
Felix (Geth):And so, I mean, that, for me, that decreases slightly the priority of this feature anyways, because it's possible…
Felix (Geth):Okay.
Felix (Geth):Where I also see…
Felix (Geth):I mean, one of the things in Almond now is that they have a time window
Felix (Geth):for which transaction hashes are indexed. So, if you do get transaction by hash, actually that only works for some amount of time. You cannot actually get all transactions that were submitted ever using get transaction by hash, at least not in the default configuration of the full nodes. So,
Felix (Geth):because of this, I think it would be similar with this, like, transaction by sender nonce. Basically, there is going to be a time window where this information is available, but then after a while, it's not going to be available. And so this means, for example, you cannot,
Felix (Geth):walk… All the transaction of an account all the way back.
Felix (Geth):At least not with the default configuration, but you will only be able to access recent transactions from the account.
Felix (Geth):And, I'm not really sure what are the, like, requirements for this, like, would it be okay to just have it for only, like, one week of time, or would it have to go back, like, more than two weeks of time, or like… so basically, these kinds of requirements would be really good to hear, because otherwise, when we would implement this.
Felix (Geth):You would just have to take a guess, basically, how long you would want that.
jvn:Yeah, yeah, I totally get it. Yeah, it's currently implemented on some, like, yeah, currently Red and JKSYNC have it. Yeah, as I see, I also tried to implement one
jvn:get, actually. So, as she said, I discussed with Sina also. So, there is no indexing, as you mentioned, so we created an optional indexing which can be configurable via an index flag, but as you said, it's… we do create a new index for transactions, for every transaction.
jvn:Yeah, maybe some kind of window to actually delete the old indexes might be a good idea.
jvn:Yeah.
Felix (Geth):Anyway, I will also review the issue. Thank you, for, summarizing it.
jvn:Thank you, Felix.
Mercy Boma Naps-Nkari:Okay, I think you can go about to 753.
Mercy Boma Naps-Nkari:the engine and its… I think I've shed it, okay.
Chase Wright:So this one… this one touches on…
Chase Wright:the consensus and the engine stuff, but it's mostly just nits and, like, updating links and stuff. I don't…
Chase Wright:I don't see anything wrong with it, but again, I'm not an expert on the engine stuff, so…
Chase Wright:I asked… Michael and if he would review it, but I don't know if…
Chase Wright:there's anyone else who could review it? I don't know. I think it's fine, but…
Mercy Boma Naps-Nkari:How… is it possible for us to, like, also introduce this to ACDC?
Mercy Boma Naps-Nkari:Or just acts on the channel.
Felix (Geth):So this is about the 753?
Chase Wright:Yep.
Mercy Boma Naps-Nkari:Yeah.
Felix (Geth):Because, basically, we kind of have this rule on this call that we cannot process the engine changes. It even seems ridiculous, but the thing is, we… I mean.
Felix (Geth):yes, maybe it's not bad, and we can just merge it, but I would rather leave it to Mikhail to merge it. And, I mean, he will get to it, so he is definitely the person to ping, because he is the de facto owner of the engine API. I mean, I can also review this, and pretty much, I mean.
Felix (Geth):Like you say, it's nothing big, so we can… Just get it in, also?
Felix (Geth):And… but I think on this particular call, this isn't really the venue to discuss this.
Chase Wright:Yeah, it's fine. We can do it out of sync. I think it just helps to sometimes have a stamp of approval from
Chase Wright:From… from someone else.
Felix (Geth):Yup.
Felix (Geth):I get it.
Mercy Boma Naps-Nkari:And I think the last one should be 773, the one that has to do with ZKVM.
Mercy Boma Naps-Nkari:Fuh-
Mercy Boma Naps-Nkari:Oh… It was opened 3 days ago.
Felix (Geth):So, this one, I have no idea about.
Felix (Geth):I checked this, and it just seems like…
Felix (Geth):I think this is not really something we can…
Felix (Geth):Process on this call, because it's kind of a proposal for…
Felix (Geth):Something between the consensus layer and the execution layer with, like.
Felix (Geth):some strings attached, like, it's… it's not just, like, a JSON RPC, change.
Mercy Boma Naps-Nkari:Yeah, I have a question in regards to this. I just wanted to… is this something we need an EIP for?
Felix (Geth):Yeah, I mean, I haven't really had the time to review this, but if it does… if it fundamentally changes the engine API, then usually it has to be at least
Felix (Geth):decided by another forum, and if it's not… if it's not a backwards compatible thing, then it probably requires also EIP. I mean, just because
Felix (Geth):Ultimately, the communication between
Felix (Geth):I don't fork rules, so it's… we at least have to engage… with the…
Felix (Geth):Right body that, you know, governs these rules.
Mercy Boma Naps-Nkari:So, because I'm trying to understand how, REST endpoints works, like, how to, like, introduce new REST endpoints, so…
Felix (Geth):I think, recently this discussion of the REST-based engine API has come up, and basically the whole idea there was that we will
Felix (Geth):want to transition the engine API from JSON RPC to another format, which would be a REST API.
Felix (Geth):And…
Felix (Geth):this also maybe highlights why this call is not the right one to discuss this, because, I mean, if it's a REST API, are we still going to talk about it here? I mean, we basically… we talk about the engine API here sometimes because it is also a JSON or PC API, but that's about the only thing it has in common with the other APIs. So it's like…
Felix (Geth):Like I said, I think this PR is not for this call.
Felix (Geth):So, anyway, in the recent times, there have been discussions about changing the engine API to use REST,
Felix (Geth):And, I think in this PR, they are basically building on that proposal to
Felix (Geth):Add, like, another endpoint to it or something.
Mercy Boma Naps-Nkari:Yeah, that is just, like, my point, like, where do we discuss this? Because I can see on, Lighthouse and Iterex, I think they have this already implemented.
Mercy Boma Naps-Nkari:That's, like, yeah.
Felix (Geth):I mean, yeah, it's like, consensus clients doing consensus things, yeah.
Mercy Boma Naps-Nkari:Shh, okay.
Felix (Geth):I mean, one problem is that we don't really have a lot of representation from the consensus clients on this call. Basically, there's mostly, I mean.
Felix (Geth):I'm pretty happy that now, at least, we have representation from the execution clients on this call, and that's nice, but…
Felix (Geth):I mean, we cannot really decide anything without the actors who are involved in this, and in this case, it's the consensus clients, so…
Felix (Geth):We would need to have them on this call to talk about it at all.
Mercy Boma Naps-Nkari:Okay, I think the last one on our list should be 706.
Mercy Boma Naps-Nkari:760, though.
Chase Wright:I mean, this is another one that McKaylin is already actively involved in, and I don't…
Chase Wright:I don't know if…
Felix (Geth):So it's, again, like, engine API. It's an engine API…
Felix (Geth):It, like, modifies the semantics, and it's related with the fork choice values, so it is not something that we can, I mean, make a decision on here. Also, it looks like, yeah, I mean, they are actively discussing it, so…
Felix (Geth):We just have to leave it alone, basically.
Mercy Boma Naps-Nkari:Okay, thank you very much. I think that's all from my end. I'm not sure if someone else has something else to say, or on issues of Gingo.
Chase Wright:I think that's it for today.
Mercy Boma Naps-Nkari:Yeah, okay. So, I was actually expecting Zane in the call, in regards to the version we talked about, but…
Mercy Boma Naps-Nkari:Maybe we can defer that for the next two weeks.
Mercy Boma Naps-Nkari:Alright, thank you everyone for joining today's call. See you same time next two weeks. Bye.
Tullio | Erigon:Thank you.
Felix (Geth):Thank you, bye.
jvn:Oh my goodness.
jvn:Thank you.
Vlad S:Thank you, bye-bye.
Chat Logs
00:06:02
Mercy Boma Naps-Nkari:https://github.com/ethereum/pm/issues/1974#issue-4087783188
00:21:21
Julian Ma:https://fastconfirm.it/
Here is the FCR website with one-pagers for each customer group
00:21:34
Julian Ma:@julianzma TG
00:21:51
Mercy Boma Naps-Nkari:https://github.com/ethereum/execution-apis/pull/747
00:22:03
Mercy Boma Naps-Nkari:https://github.com/ethereum/execution-apis/pull/756
00:22:19
Mercy Boma Naps-Nkari:https://github.com/ethereum/execution-apis/pull/771
00:22:26
Mercy Boma Naps-Nkari:https://github.com/ethereum/go-ethereum/pull/33854
00:22:33
Mercy Boma Naps-Nkari:https://github.com/ethereum/execution-apis/pull/753
00:25:05
Mercy Boma Naps-Nkari:https://github.com/ethereum/execution-apis/pull/773
00:31:04
Mercy Boma Naps-Nkari:https://github.com/ethereum/execution-apis/pull/297
00:31:55
Julian Ma:Thanks all! Need to drop 👋
00:32:58
Mercy Boma Naps-Nkari:https://github.com/ChainSafe/lodestar/issues/9064?notification_referrer_id=NT_kwHOBcDdGtoAJVJlcG9zaXRvcnk7MTM4MzEzNDk3O0lzc3VlOzQxMDI3OTc2OTU#issuecomment-4103158014
00:34:50
Mercy Boma Naps-Nkari:https://github.com/ChainSafe/lodestar/issues/9064#issuecomment-4103136430
00:35:23
Mercy Boma Naps-Nkari:https://github.com/ethereum/execution-apis/pull/771
00:37:54
Chase Wright:https://github.com/ethereum/execution-apis/issues/494
00:44:38
Mercy Boma Naps-Nkari:https://github.com/ethereum/execution-apis/pull/753
00:45:07
Mercy Boma Naps-Nkari:https://github.com/ethereum/execution-apis/pull/773
00:50:42
Mercy Boma Naps-Nkari:https://github.com/ethereum/execution-apis/pull/760
Summary
11 highlights
· 3 action itemsExperimental
Summary
11 highlights · 3 action itemsExperimentalfast confirmation rule
- FCR decreases confirmation time from 13 minutes to 13 seconds00:06:45
- Safety assumptions: network synchrony and <25% adversarial stake00:09:08
- ~95% of blocks fast-confirmed within 12 seconds00:10:29
- Safe block tag repurposed from justification to FCR00:14:42
- First clients ready for testing end of March; production Q200:15:29
- Different clients may return different safe blocks during transition00:16:14