Conversation
birchmd
reviewed
Jun 2, 2025
Contributor
birchmd
left a comment
birchmd
left a comment
There was a problem hiding this comment.
Thanks for bringing this up! It is good to think about how to prevent possible DoS attacks under SPICE.
neps/nep-0611.md
Outdated
| #### Access Key Parallelism Restriction | ||
| We now restrict the ability to send multiple parallel pending transactions with Access Keys. | ||
|
|
||
| Specifically, for any given account $A$ with any number of access keys, the total number of access key transactions in the pending transaction queue whose sender is $A$ cannot exceed $P_{\mathrm {max}}$, a |
Contributor
There was a problem hiding this comment.
Is this enough to prevent the attack described above? Instead of having one account they send many transactions to, it could be many accounts they send only a few transactions to each.
Contributor
Author
There was a problem hiding this comment.
The idea is that the amount of block space the attacker consumes vs amount of gas the attacker has to pay, i.e. the "waste amplification factor", is unbounded in the attack mentioned in the NEP, but only O(1) with a maximum parallelism. It's then still possible to attack, but the attack would cost a proportional amount of gas - just cheaper than it is today - which isn't a very great incentive to mount the attack (given that the attack is only a DoS).
github-merge-queue bot
pushed a commit
to near/nearcore
that referenced
this pull request
Jun 10, 2025
See near/NEPs#611 This PR adds the GasKey trie key. In subsequent PRs we will introduce a new transaction type to accept gas key transactions, and to implement the gas key actions.
ssavenko-near
pushed a commit
to near/nearcore
that referenced
this pull request
Jun 13, 2025
See near/NEPs#611 This PR adds the GasKey trie key. In subsequent PRs we will introduce a new transaction type to accept gas key transactions, and to implement the gas key actions.
trechriron
temporarily deployed
to
robin/611 - nomicon PR #611
Render
Destroyed
Contributor
|
Hi @robin-near (or anyone who is interested in championing this NEP forward) – we are cleaning the NEP backlog and noticed that this PR still has some incomplete sections: particularly, it has a "TODO: Other things". Therefore, we are labeling this PR as "Needs author revision." Please ping the @near/nep-moderators once you are ready for us to review it. We typically close NEPs that are inactive for more than two months, so please let us know if you need more time. |
gagdiez
added
S-draft/needs-author-revision
Contributor
|
Because there has been no activity from the author for more than 3 months, I'm marking the proposal as RETRACTED. Please feel free to open it again if you'd like to continue working on it. |
garikbesson
added
the
S-retracted
This was referenced Oct 27, 2025
github-merge-queue bot
pushed a commit
to near/nearcore
that referenced
this pull request
Feb 10, 2026
This is 3 out of 3 PRs for charging gas keys for failed transactions. See near/NEPs#611 for details. For reviewer's reference, all changes together: #15031 - When a gas key transaction fails because the account can't cover the deposit, gas is still charged from the gas key balance. This prevents SPICE spam where an attacker drains their account between submission and execution to get free transactions. - Adds `TxVerdict::DepositFailed` variant: the verifier returns this when gas key balance is sufficient but the account can't cover the deposit - Adds `NotEnoughBalanceForDeposit` error variant - `test_gas_key_tx_deposit_insufficient_charges_gas` (apply-level), `test_gas_key_tx_deposit_failed_for_{account_balance, storage_stake}` (verifier-level) - Will fix protocol schema and openapi.json after review.
github-merge-queue bot
pushed a commit
to near/nearcore
that referenced
this pull request
Feb 10, 2026
This is 3 out of 3 PRs for charging gas keys for failed transactions. See near/NEPs#611 for details. For reviewer's reference, all changes together: #15031 - When a gas key transaction fails because the account can't cover the deposit, gas is still charged from the gas key balance. This prevents SPICE spam where an attacker drains their account between submission and execution to get free transactions. - Adds `TxVerdict::DepositFailed` variant: the verifier returns this when gas key balance is sufficient but the account can't cover the deposit - Adds `NotEnoughBalanceForDeposit` error variant - `test_gas_key_tx_deposit_insufficient_charges_gas` (apply-level), `test_gas_key_tx_deposit_failed_for_{account_balance, storage_stake}` (verifier-level) - Will fix protocol schema and openapi.json after review.
This was referenced Feb 14, 2026
github-merge-queue bot
pushed a commit
to near/nearcore
that referenced
this pull request
Feb 24, 2026
Gas keys ([NEP-611](near/NEPs#611)) allow access keys to carry a NEAR balance dedicated to paying for gas, separate from the account's main balance. This PR implements Rosetta Construction API support for `TransferToGasKey` and `WithdrawFromGasKey` actions, enabling bidirectional conversion between NEAR actions and Rosetta operations. - New operations: `InitiateTransferToGasKey`, `TransferToGasKey`, `InitiateWithdrawFromGasKey`, `WithdrawFromGasKey` - Each gas key action maps to a pair of Rosetta operations (initiate + main), following the existing pattern used by `Transfer`, `AddKey`, etc. - `TransferToGasKey` is non-SIR-compatible (sender != receiver), `WithdrawFromGasKey` is SIR-compatible - Roundtrip bijection test updated to cover both new action types
github-merge-queue bot
pushed a commit
to near/nearcore
that referenced
this pull request
Feb 24, 2026
Gas keys ([NEP-611](near/NEPs#611)) allow access keys to carry a NEAR balance dedicated to paying for gas, separate from the account's main balance. This PR implements Rosetta Construction API support for `TransferToGasKey` and `WithdrawFromGasKey` actions, enabling bidirectional conversion between NEAR actions and Rosetta operations. - New operations: `InitiateTransferToGasKey`, `TransferToGasKey`, `InitiateWithdrawFromGasKey`, `WithdrawFromGasKey` - Each gas key action maps to a pair of Rosetta operations (initiate + main), following the existing pattern used by `Transfer`, `AddKey`, etc. - `TransferToGasKey` is non-SIR-compatible (sender != receiver), `WithdrawFromGasKey` is SIR-compatible - Roundtrip bijection test updated to cover both new action types
github-merge-queue bot
pushed a commit
to near/nearcore
that referenced
this pull request
Feb 24, 2026
Gas keys ([NEP-611](near/NEPs#611)) allow access keys to carry a NEAR balance dedicated to paying for gas, separate from the account's main balance. This PR implements Rosetta Construction API support for `TransferToGasKey` and `WithdrawFromGasKey` actions, enabling bidirectional conversion between NEAR actions and Rosetta operations. - New operations: `InitiateTransferToGasKey`, `TransferToGasKey`, `InitiateWithdrawFromGasKey`, `WithdrawFromGasKey` - Each gas key action maps to a pair of Rosetta operations (initiate + main), following the existing pattern used by `Transfer`, `AddKey`, etc. - `TransferToGasKey` is non-SIR-compatible (sender != receiver), `WithdrawFromGasKey` is SIR-compatible - Roundtrip bijection test updated to cover both new action types
github-merge-queue bot
pushed a commit
to near/nearcore
that referenced
this pull request
Feb 24, 2026
Gas keys ([NEP-611](near/NEPs#611)) allow access keys to carry a NEAR balance dedicated to paying for gas, separate from the account's main balance. This PR adds Rosetta Data API support for tracking gas key balances, building on the action encoding from #15100. At a high level, uses `StateChangesRequestView::AllAccessKeyChanges` to get changes to gas key balances, including when they are deleted. Then, adding a new `SubAccount` type, which represents the aggregate gas key balance for an account on the Rosetta side. - Add `SubAccount::GasKey` for querying aggregate gas key balance via `/account/balance`. - Track per-key gas key balance changes by observing access key state changes in each block - Attribute balance diffs to their causal receipt/transaction with `transfer_fee_type` metadata: `GasPrepayment` for `TransactionProcessing`,`GasRefund` for system predecessor - Handle key deletion by emitting a `GasKeyBalanceBurnt` operation for the remaining balance - Add test covering transfer-in, refund, gas usage, key deletion, and gas prepayment scenarios
github-merge-queue bot
pushed a commit
to near/nearcore
that referenced
this pull request
Feb 24, 2026
Gas keys ([NEP-611](near/NEPs#611)) allow access keys to carry a NEAR balance dedicated to paying for gas, separate from the account's main balance. This PR adds Rosetta Data API support for tracking gas key balances, building on the action encoding from #15100. At a high level, uses `StateChangesRequestView::AllAccessKeyChanges` to get changes to gas key balances, including when they are deleted. Then, adding a new `SubAccount` type, which represents the aggregate gas key balance for an account on the Rosetta side. - Add `SubAccount::GasKey` for querying aggregate gas key balance via `/account/balance`. - Track per-key gas key balance changes by observing access key state changes in each block - Attribute balance diffs to their causal receipt/transaction with `transfer_fee_type` metadata: `GasPrepayment` for `TransactionProcessing`,`GasRefund` for system predecessor - Handle key deletion by emitting a `GasKeyBalanceBurnt` operation for the remaining balance - Add test covering transfer-in, refund, gas usage, key deletion, and gas prepayment scenarios
github-merge-queue bot
pushed a commit
to near/nearcore
that referenced
this pull request
Feb 24, 2026
Gas keys ([NEP-611](near/NEPs#611)) allow access keys to carry a NEAR balance dedicated to paying for gas, separate from the account's main balance. This PR adds Rosetta Data API support for tracking gas key balances, building on the action encoding from #15100. At a high level, uses `StateChangesRequestView::AllAccessKeyChanges` to get changes to gas key balances, including when they are deleted. Then, adding a new `SubAccount` type, which represents the aggregate gas key balance for an account on the Rosetta side. - Add `SubAccount::GasKey` for querying aggregate gas key balance via `/account/balance`. - Track per-key gas key balance changes by observing access key state changes in each block - Attribute balance diffs to their causal receipt/transaction with `transfer_fee_type` metadata: `GasPrepayment` for `TransactionProcessing`,`GasRefund` for system predecessor - Handle key deletion by emitting a `GasKeyBalanceBurnt` operation for the remaining balance - Add test covering transfer-in, refund, gas usage, key deletion, and gas prepayment scenarios
2 tasks
Contributor
|
Hi everyone! seeing that some members of the WG voted, and by the request of @walnut-the-cat, we are moving forward to meet and vote this NEP @robin-near, @jakmeier, @matejpavlovic, @darioush if you could share your availability here we will try to find some time that works for everyone @robin-near / @darioush would be awesome if one of you could present a high level explanation of the NEP. No need to have a full presentation, just 1 - 3 slides, enough overview for people to understand the gist of it. Thank you everyone! |
gagdiez
changed the title
gagdiez
added
S-voting/needs-wg-voting-indication
Contributor
|
@gagdiez Thanks for setting up the scheduling. I would be happy to present a few slides. |
Contributor
|
As the moderator, I would like to thank @robin-near for submitting this NEP-Category, and for the @near/wg-protocol working group members for your review. We are scheduling a Protocol Working group meeting tomorrow, where this NEP can enter the final voting stage. Anyone can discuss the technical details by adding your comments to this discussion. And join the call to learn about the final decision and how to get more involved. cc @jakmeier @walnut-the-cat @darioush @birchmd Meeting Info |
31 tasks
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Contributor
|
Thank you to everyone who attended the Protocol Working Group meeting! The working group members reviewed the NEP and reached the following consensus: Status: Approved
Meeting Recording: https://youtu.be/oJgyyT37mxw @darioush thank you for authoring this NEP! Next Steps:
|
gagdiez
approved these changes
Mar 5, 2026
gagdiez
added
S-approved
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
12 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In the near future of the Near blockchain, we foresee that via the SPICE project, transaction and receipt execution will become decoupled from the blockchain itself; they will no longer run in lockstep. Instead, transactions will be included in the blocks first, and then execution will follow later.
This inherently introduces a problem that we must accept transactions before we know whether they are valid. Today, when a chunk producer produces a chunk containing a transaction, it can verify using the current shard state that the transaction has a valid signature, has enough balance, and a valid nonce. But as execution becomes asynchronous, we no longer have the current shard state to verify the
transactions against.
This NEP proposes a mechanism called the Pending Transaction Queue to solve this problem.