Protocol Working Group 3/3/26: NEP-611 and the Future of NEAR Transaction Processing
Nothing is loaded from YouTube until you press play, and then without tracking cookies.
About this video
In this session of the NEAR Protocol Working Group, contributors review NEP-611, a proposal introducing Gas Keys and a Pending Transaction Queue to improve transaction validation and protect the network from spam and denial-of-service attacks.
The proposal is designed to support the upcoming separation of consensus and execution, an important step in NEAR’s long-term scalability roadmap. When consensus and execution are separated, there can be a gap between when a transaction is included in a block and when it is actually executed. That gap creates an opportunity for attackers to manipulate account balances and submit transactions that ultimately fail but still consume network resources.
NEP-611 addresses this problem by introducing a new type of access key called a Gas Key. Gas keys include a prefunded gas balance that ensures transactions can pay their fees even if account balances change between inclusion and execution. This prevents attackers from submitting transactions that later become invalid without paying for them.
Key topics discussed in this meeting: • The spam and DoS vulnerability introduced by separating execution from consensus • How Gas Keys provide prefunded gas balances to guarantee fee payment • The design of the Pending Transaction Queue • Compatibility with existing workflows and access keys • A grace limit of four in-flight transactions for contract accounts without gas keys • Benefits for relayers, exchanges, and high-throughput applications with parallel nonce management • Why NEP-611 acts as a stepping stone toward the next iteration of NEAR’s protocol architecture
During the meeting, protocol engineers and reviewers discuss the design, implementation considerations, and how the proposal fits into NEAR’s broader roadmap. By the end of the discussion, subject-matter experts align on approving the proposal, recognizing it as a necessary step toward future protocol upgrades.
Participants: NEAR Protocol Working Group members and contributors including Dario (NEP author), Jacob, Michael, Anton, and other protocol reviewers.
If you’re interested in how blockchain protocols evolve under the hood, this discussion provides a real look at how technical proposals move from idea to approval.
Resources • NEAR Protocol NEPs: github.com/near/NEPs • NEAR Developer Docs: docs.near.org
Transcript
1,762 wordsCaptions as YouTube publishes them, usually machine-generated, so product and people names can be misheard.
- 0:02
Perfect. And now we're recording. So, hi everyone. Welcome to a new meeting from the pro protocol working group. Today we're going to be talking about NEP 611, the pending transaction queue. And yeah, let's just take it away. Dario, would you like to present briefly the NEP?
- 0:23
Um, yes. Uh, thanks everyone for being here. Uh let me quickly share this window. Um yes. Uh so we are going to review NEP 611 today. Uh which introduces uh gas keys and the pending transaction queue. Uh and the main reason for this is to prevent a specific spam and denial of service attack that exists in separation of consensus and execution uh project.
- 0:54
Um so we can first see uh what is this problem that exists in separation of execution and consensus. Um basically we need to prevent uh attackers from including transactions from free in blockchain. Uh otherwise they may be tempted to do so. Uh right now this does not exist because the trunk producers uh always have access to the most recent state. So they can easily look at um the state and determine whether a transaction is valid
- 1:27
or not at the time of inclusion and there is no room for anything to change um from that moment until it's actually executed. Uh however in spice we have this gap between inclusion and execution in which uh for example an account that has a contract uh could try to send its balance to another account. um most likely controlled by itself um and then causes um the other transactions to fail and become non-fee paying transaction.
- 2:01
Um any questions or we can move to the uh solution part. If there are no questions we can move forward. Cool. Um so we are introducing a new kind of access key uh which contains a prefunded gas balance. Um the gas balance is preunded in the sense that um it cannot be reduced without the chunk producer having observability into this reduction.
- 2:38
Um there is also a caveat that it can be burned as well. Um so if there is an attempt to programmatically um delete the key for example um in such case the calculation that was done by the chunk producer is still holding because uh the attacker was not able to re recover those fees. Uh instead they just burnt it. So if they do cause an invalid transaction uh they will have paid for it um either paid for it or have burned it.
- 3:14
And we also have a fallback for the existing um behavior to uh not cause too much disruption for existing workflows. Um so accounts that do not have any contract deployed are not impacted by this at all and have no restrictions.
- 3:35
And if an account has a contract deployed uh we are giving them a uh four transaction in flight uh kind of um uh grace um period. Uh of course we can also reduce this if it uh turns out to be a problem. Any uh questions? Um another point that uh we would like to touch on with the gas keys is that uh every gas key allows to share the gas balance with an array of nonses. Uh this can be useful for uh relayers or
- 4:18
exchanges or gaps that have to do complicated nons management. and would like to issue a lot of uh transactions in parallel. Um this is um sort of an in between solution between um uh forcing the total nons management and um having no nons in a way.
- 4:50
And uh lastly I have the uh overview of u the new chunk producers behavior. So first when the transaction arrives uh it will check if it's a access key or not or a gas key. Uh in case of access key we will check for contract and if there are more in uh than four in flight uh we will reject that or it would have to wait until those transactions that are in flight are certified and then they would be included uh and for the gas key session
- 5:22
limit doesn't apply. Instead we can accurately check uh whether the transaction can pay its fees and include it based on that. Um yeah this uh concludes uh the slide I had for today. Perfect. Thank you so much. And actually this diagram is very nice. I think I have not seen it on the NEP. So it might be a good idea to to to actually add it.
- 5:51
Uh so later if you want either you add it or share it with with any of us and and we can and we can do it. Uh Jacob, I understood I understand that you have been uh following the process of this NEP and um you were one of the subject matter experts uh reviewing it. Would you like to comment some some on something on on on on this NP?
- 6:15
Um I think most of it has been written down. I I'll briefly reiterate kind of my findings which are first of all this has been a long process trying to address uh how can we get anywhere closer to the next iteration of the consensus specifically uh consensus execution being separated and I think we had a couple of iterations of getting gas keys done that probably would have been good enough but the team really
- 6:47
went above and beyond try to come up with the best possible solution. So we had some back and forth, try to make the design fit better into the existing design um around keys and like how access keys and these new type of gas keys how these work together and I'm really happy with with what we have in the end. I think this is the best solution that we we have come forward with or really I should say that the team the team has
- 7:17
come forward with and the only kind of um thing to consider that I wanted to bring forward is that this really is on its own a feature as a stepping stone towards um separating execution from consensus and not itself a very useful feature even though this like nonp parallelism can be useful but I don't think we would have gone through all of this work just for that because as far as I know there hasn't
- 7:50
been like a a huge uh request for getting that done but yeah more details are all in the discussion so that's all I wanted to say perfect and I do understand that you recommend for this NP to be approved right yes absolutely perfect uh Michael you are yourself uh a part of the of the working group uh of the protocol working group. Um so anything you would want to say about this NEP any concerns and then you know
- 8:21
like if you if you feel like this NEP should be approved or not? Uh yeah I definitely think it should be approved. I agree with Jacob of, you know, it's um clearly addressing a potential issue in spice and doing so in in a nice way. So, we're we're happy about that. Um my favorite part about this is that it's moving us in the direction of space while being a standalone backwards compatible independent feature. Right? So this is
- 8:57
letting us iteratively move towards what is ultimately going to be a fairly large change to the protocol. But uh doing so in in these sort of smaller steps lets us sort of validate that it's being done well um and that it's it's not going to be breaking anything all of a sudden. So um I'm I'm definitely happy about that.
- 9:16
Would definitely like to see more of that as as we continue to move for Spice. Um, but otherwise I I had left a few minor comments uh some technical details in uh my initial review that's that's on the GitHub there. All of which were addressed and um yeah, so I'm I'm happy with with the state of things and and happy to vote for it to be approved.
- 9:39
Perfect. That's very good. Um, Anton, uh, have you are you familiarized with the with the NEP and, you know, do you have any concerns and will you suggest this NEP to be uh, approved or rejected? Uh, yeah. So, I've been mostly on the implementation side. So, I've been reviewing the implementation. Uh, obviously I'm familiar with the design to review it. So, yeah. Uh, I think it should be approved. It's, uh, solves the problem. uh we we have uh with spice to
- 10:12
to move forward. So yeah, no brainer should be approved. Okay, perfect. So uh the good news is that all subject matter experts align on on it being approved. You might call yourself as part of the working group also. Uh I think that we can consider this NEP for what it is basically approved. Um I will just most probably go and reach out uh async another member of the working group. Um I don't know if
- 10:42
maybe Marcel or I will search for someone else just to have like one you know extra member of the working group uh approval but for all intended purposes we can assume that this NP has been approved. Uh Dario thank you so much for uh you know championing the NEP. We all know that it's not a simple process and it generally involves tens or maybe hundreds of messages on on on on GitHub and coordinating with multiple subject matter experts. So
- 11:13
thank you so much for for for the hard work you put and yeah so we will continue this uh through GitHub where I will basically comment that this is uh by all means uh by all practical means approved and uh I will just let you know that how we how we just finish this in order to actually get it merged. So yeah, that will conclude actually the the meeting except if anyone else has anything that you would want to share.
- 11:45
Otherwise, please thank everybody for uh the time and effort that was put into this to reviewing NEP u especially from uh your website and uh also uh Anton put great efforts into reviewing uh implementation and re uh design. So, thank you everybody.
- 12:05
Perfect. Well, thank you so much everyone and we will continue this through GitHub and have a great day. Bye-bye.