feat(gas-keys): gas key refunds#14985
Conversation
|
|
||
| // Fund the gas key | ||
| let gas_key_fund_amount = Balance::from_near(100); | ||
| let gas_key_fund_amount = Balance::from_millinear(10); |
There was a problem hiding this comment.
This seems too high for gas balance, so I reduced it here as well
There was a problem hiding this comment.
Pull request overview
This PR updates gas refund handling so that refunds from gas key–driven transactions credit the gas key balance instead of the account balance, while preserving existing behavior for deposit (balance) refunds and adding a fallback when the gas key is missing.
Changes:
- Refactors gas key tests in the TestLoop harness to share helpers and adds an integration test that verifies gas and balance refund behavior for gas-key-based function calls.
- Introduces
try_refund_gas_key_balanceand updatesaction_transfer_or_implicit_account_creationso gas refund receipts first attempt to refund the gas key’s balance, falling back to account balance and allowance refund when no gas key is present. - Adds runtime apply-layer tests to validate that gas refund receipts increase gas key balances when the key exists and credit the account balance when the key is unknown.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
test-loop-tests/src/tests/gas_keys.rs |
Adds shared helpers for querying gas key balances and asserting function call errors, adjusts funding to millinear units, and introduces an end-to-end gas refund test for gas key function calls with deposit. |
runtime/runtime/src/actions.rs |
Adds try_refund_gas_key_balance to safely credit gas refunds to gas key balances when a matching gas key exists. |
runtime/runtime/src/lib.rs |
Updates action_transfer_or_implicit_account_creation to classify gas refunds, route them to gas keys when possible, and otherwise retain the existing account-balance and allowance refund behavior. |
runtime/runtime/src/tests/apply.rs |
Extends apply-level tests to cover gas refund receipts to existing gas keys and to unknown keys, ensuring correct routing to gas key or account balance respectively. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot <[email protected]>
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #14985 +/- ##
===========================================
+ Coverage 1.30% 68.83% +67.53%
===========================================
Files 726 920 +194
Lines 140760 201606 +60846
Branches 140760 201606 +60846
===========================================
+ Hits 1835 138782 +136947
+ Misses 138872 56852 -82020
- Partials 53 5972 +5919
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
# Gas Keys ([NEP-611](near/NEPs#611)) Gas keys are a new type of access key that carries a pre-funded NEAR balance and multiple independent nonce sequences. When a transaction is signed with a gas key, gas costs are deducted from the gas key's balance rather than the signer's account balance (deposits like NEAR transfers still come from the account). ## Why do we need gas keys? - Enabling SPICE without a DoS vector. The SPICE project (Separation of Execution from Consensus) decouples transaction execution from block production: transactions are included in blocks first, and executed asynchronously later. This means chunk producers can no longer verify account balances at inclusion time. An attacker could drain an account's balance in one transaction, then flood the chain with many transactions signed by that account. All would be accepted (since execution hasn't caught up), consuming block space for free when they inevitably fail. Gas keys close this gap by requiring gas to be pre-committed in the key itself, so chunk producers can verify gas availability without access to the latest state. - Parallel transaction submission. Today, programmatic users who submit many transactions in parallel must manage multiple access keys (each with its own nonce sequence). A gas key supports up to 1,024 independent nonce slots via a single key, removing that complexity. # Context - NEP (if exists): near/NEPs#611 - Implementation: - near#14868 - near#14869 - near#14883 - near#14891 - near#14892 - near#14911 - near#14924 - near#14925 - near#14930 - near#14933 - near#14969 - near#14985 - near#15033 - near#15034 - near#15067 - near#15068 - near#15100 - near#15101 - near#15186 # Testing and QA - unit tests - test-loop: https://github.com/near/nearcore/blob/master/test-loop-tests/src/tests/gas_keys.rs - forknet (automated): near#15207 - forknet (manual testing, planned) # Checklist - [x] Link to nightly nayduck run: https://nayduck.nearone.org/#/run/4756 - [x] Update CHANGELOG.md to include this protocol feature in the `Unreleased` section.
Uh oh!
There was an error while loading. Please reload this page.