Comprehensive compute fees (#20531)
* Comprehensive fees proposal * Updated
This commit is contained in:
Jack May
GitHub
parent
b0ee5d6cfa
commit
94ca5063de
|
|
@ -0,0 +1,132 @@
|
||||||
|
---
|
||||||
|
title: Comprehensive Compute Fees
|
||||||
|
---
|
||||||
|
|
||||||
|
## Motivation
|
||||||
|
|
||||||
|
The current fee structure lacks a comprehensive account of the work required by
|
||||||
|
a validator to process a transaction. The fee structure is only based on the
|
||||||
|
number of signatures in a transaction but is meant to account for the work that
|
||||||
|
the validator must perform to validate each transaction. The validator performs
|
||||||
|
a lot more user-defined work than just signature verification. Processing a
|
||||||
|
transaction typically includes signature verifications, account locking, account
|
||||||
|
loading, and instruction processing.
|
||||||
|
|
||||||
|
## Proposed Solution
|
||||||
|
|
||||||
|
The following solution does not specify what native token costs are to be
|
||||||
|
associated with the new fee structure. Instead, it sets the criteria and
|
||||||
|
provides the knobs that a cost model can use to determine those costs.
|
||||||
|
|
||||||
|
### Fee
|
||||||
|
|
||||||
|
The goal of the fees is to cover the computation cost of processing a
|
||||||
|
transaction. Each of the fee categories below will be represented as a compute
|
||||||
|
unit cost that, when added together, encompasses the entire cost of processing
|
||||||
|
the transaction. By calculating the total cost of the transaction, the runtime
|
||||||
|
can charge a more representative fee and make better transaction scheduling
|
||||||
|
decisions.
|
||||||
|
|
||||||
|
A fee will be calculated based on:
|
||||||
|
|
||||||
|
1. Number of signatures
|
||||||
|
- Fixed rate per signature
|
||||||
|
2. Number of write locks
|
||||||
|
- Fixed rate per writable account
|
||||||
|
3. Data byte cost
|
||||||
|
- Fixed rate per byte of the sum of the length all a transactions instruction
|
||||||
|
datas
|
||||||
|
4. Account sizes
|
||||||
|
- Account sizes can't be known up-front but can account for a considerable
|
||||||
|
amount of the load the transaction incurs on the network. The payer will
|
||||||
|
be charged for a maximum account size (10m) upfront and refunded the
|
||||||
|
difference after the actual account sizes are known.
|
||||||
|
5. Compute budget
|
||||||
|
- Each transaction will be given a default transaction-wide compute budget of
|
||||||
|
200k units with the option of requesting a larger budget via a compute
|
||||||
|
budget instruction up to a maximum of 1m units. This budget is used to
|
||||||
|
limit the time it takes to process a transaction. The compute budget
|
||||||
|
portion of the fee will be charged up-front based on the default or
|
||||||
|
requested amount. After processing, the actual number of units consumed
|
||||||
|
will be known, and the payer will be refunded the difference, so the payer
|
||||||
|
only pays for what they used. Builtin programs will have a fixed cost
|
||||||
|
while BPF program's cost will be measured at runtime.
|
||||||
|
6. Precompiled programs
|
||||||
|
- Precompiled programs are performing compute-intensive operations. The work
|
||||||
|
incurred by a precompiled program is predictable based on the instruction's
|
||||||
|
data array. Therefore a cost will be assigned per precompiled program
|
||||||
|
based on the parsing of instruction data. Because precompiled programs are
|
||||||
|
processed outside of the bank, their compute cost will not be reflected in
|
||||||
|
the compute budget and will not be used in transaction scheduling
|
||||||
|
decisions. The methods used to determine the fixed cost of the components
|
||||||
|
above are described in
|
||||||
|
[#19627](https://github.com/solana-labs/solana/issues/19627)
|
||||||
|
|
||||||
|
### Cost model
|
||||||
|
|
||||||
|
The cost model is used to assess what load a transaction will incur during
|
||||||
|
in-slot processing and then make decisions on how to best schedule transaction
|
||||||
|
into batches.
|
||||||
|
|
||||||
|
The cost model's criteria are identical to the fee's criteria except for
|
||||||
|
signatures and precompiled programs. These two costs are incurred before a
|
||||||
|
transaction is scheduled and therefore do not affect how long a transaction
|
||||||
|
takes within a slot to process.
|
||||||
|
|
||||||
|
### Cache account sizes and use them instead of the max
|
||||||
|
|
||||||
|
https://github.com/solana-labs/solana/issues/20511
|
||||||
|
|
||||||
|
### Transaction-wide compute caps
|
||||||
|
|
||||||
|
The current compute budget caps are independently applied to each instruction
|
||||||
|
within a transaction. This means the overall transaction cap varies depending on
|
||||||
|
how many instructions are in the transaction. To more accurately schedule a
|
||||||
|
transaction, the compute budget will be applied transaction-wide. One challenge
|
||||||
|
of the transaction-wide cap is that each instruction (program) can no longer
|
||||||
|
expect to be given an equal amount of compute units. Each instruction will be
|
||||||
|
given the remaining units left over after processing earlier instructions. This
|
||||||
|
will provide some additional tuning and composability challenges for developers.
|
||||||
|
|
||||||
|
### Requestable compute budget caps and heap sizes
|
||||||
|
|
||||||
|
The precompiled
|
||||||
|
[ComputeBudget](https://github.com/solana-labs/solana/blob/00929f836348d76cb3503d0ba5f76f0d275bcc66/sdk/src/compute_budget.rs#L34)
|
||||||
|
program can be used to request higher transaction-wide compute budget caps and
|
||||||
|
program heap sizes. The requested increases will be reflected in the
|
||||||
|
transaction's fee.
|
||||||
|
|
||||||
|
### Fees for precompiled program failures
|
||||||
|
|
||||||
|
https://github.com/solana-labs/solana/issues/20481
|
||||||
|
|
||||||
|
### Rate governing
|
||||||
|
|
||||||
|
Current rate governing needs to be re-assessed. Current fees are being rate
|
||||||
|
governed down to their minimums because the number of signatures in each slot is
|
||||||
|
far lower than the "target" signatures per slot.
|
||||||
|
|
||||||
|
Instead of using the number of signatures to rate govern, the cost model will
|
||||||
|
feed back information based on the batch/queue load it is seeing. The fees will
|
||||||
|
sit at a target rate and only increase if the load goes above a specified but to
|
||||||
|
be determined threshold. The governing will be applied across all the fee
|
||||||
|
criteria.
|
||||||
|
|
||||||
|
### How do clients calculate a transaction's fee
|
||||||
|
|
||||||
|
Transaction fees are currently calculated based on a fixed cost per signature
|
||||||
|
and implemented via an object in the SDK that took a transaction and returned a
|
||||||
|
cost. This object is looked up via a blockhash and returned via RPC to
|
||||||
|
calculate the fee offline.
|
||||||
|
|
||||||
|
The comprehensive fee calculations are more sophisticated and depend on a
|
||||||
|
greater amount of information (recent program compute meter measurements). To
|
||||||
|
move to the new fee structure the RPC APIs that return a FeeCalculator object
|
||||||
|
will be deprecated, and clients will send their transactions over RPC and be
|
||||||
|
returned the calculated fee.
|
||||||
|
|
||||||
|
Fees will no longer be calculated based on a blockhash since it is
|
||||||
|
cost-prohibitive to retain the fee cost inputs for each bank (program units,
|
||||||
|
account sizes). And mainly, the governed fee is based on network load now, not
|
||||||
|
at some time in the past. This will mean that during offline-signing the actual
|
||||||
|
fee charged will not be known until the transaction is submitted.
|
||||||
Loading…
Reference in New Issue