Skip to content

SIMD-0290: Relax Fee Payer Constraint #290

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

SIMD-0290: Relax Fee Payer Constraint #290

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
80 changes: 80 additions & 0 deletions proposals/0290-relax-fee-payer-constraint.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,80 @@
---
simd: '0290'
title: Relax Fee Payer Constraint
authors:
- Andrew Fitzgerald (Anza)
category: Standard
type: Core
status: Review
created: 2025-05-29
feature:
---

## Summary

This proposal aims to relax the handling of invalid fee payers in Solana.
Currently, if a transaction with an invalid fee payer is included in a block,
the entire block is rejected.
This proposal suggests that instead of rejecting the entire block, the
transaction with the invalid fee payer should simply skip execution.

## Motivation

The current constraint forces block-validation to be synchronous since in order
to determine if a block is valid or not, some subset of transactions must be
executed in order to determine if the fee payer has sufficient funds to pay the
transaction fees.
By relaxing this constraint, we move one step closer towards asynchronous
validation/execution.

## New Terminology

None.

## Detailed Design

A transaction has a statically determined fee `fee` lamports.
A transaction can successfully pay fees if:

- The fee payer account has exactly `fee` lamports.
- The fee payer account has at least X + `rent_exempt_reserve` lamports.

If the fee payer account does not meet either of these conditions, the transaction
may be included in a block, but it must not be executed.
The transaction will have no effect on the state.

Invalid fee payer transactions will count their requested,
or default, compute units (CUs) towards block limits.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wrt "default", if SIMD-0172 is approved, default will be zero, or a small number (chances are smaller than its would-be actual CUs).

This is intended to make it strictly cheaper to process invalid fee payer
transactions compared to valid fee payer transactions of the same construction.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

make it strictly cheaper to process invalid fee payer transactions compared to valid fee payer transactions of the same construction.

Can you say more about why "cheaper to process" invalid transaction that uses request (or default) CUs? Does it refer to request_cu usually greater than actual_cu, therefore fee/requested_cu will be smaller than fee/actual_cu (which is the case for valid transaction), therefore invalid fee payer transactions will have lower priority?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using assumption that checking fee payer is a constant cost regardless of whether it can pay fees or not (not really true, but for the cost-model it is what we assume).

Then we 3 paths, and the things we do:

  1. Account exists and has enough funds:
    • check if fee payer account exists
    • check fee payer account balance
    • execution
  2. Account exists and doesn't have enough funds:
    • check if fee payer account exists
    • check fee payer account balance
    • (stop early)
  3. Account does not exist:
    • check if fee payer account exists
    • (stop early)

^ we do less work, i.e. don't need to do any execution checks if the fee payer cannot pay.


## Alternatives Considered

- Requiring some sort of fee-payer lock up/bonding mechanism to ensure that fee
payers have sufficient funds to pay for the transaction fees.
- This is more complex compared to this proposal.

## Impact

Transactions that are unable to pay fees may be included in blocks.

## Security Considerations

- Possible attack vector where a malicious leader can spam transactions with
invalid fee payers. Mitigation for this is charging full CUs for these.

## Drawbacks

- If there is no interest in simplifying block-validation to allow for
asynchronous, this proposal is not necesary.
- Concern about data propagation for without paying fees to the network (burn):
- This concern has been raised in the past when this has been discussed.
- However, the concern is largely invalid since even without this proposal,
a malicious leader could still propagate data through the network for free
by simply using an invalid fee payer.

## Backwards Compatibility

- All previously valid transactions and blocks are still valid.
- Blocks produced after the change may be rejected by previous versions of the
validator client(s).
Loading