More deterministic fee info (#20825)
This commit is contained in:
parent
443611d050
commit
451aac7f7f
|
@ -102,7 +102,7 @@ https://github.com/solana-labs/solana/issues/20481
|
||||||
|
|
||||||
### Rate governing
|
### Rate governing
|
||||||
|
|
||||||
Current rate governing needs to be re-assessed. Current fees are being rate
|
Current rate governing needs to be re-assessed. Fees are being rate
|
||||||
governed down to their minimums because the number of signatures in each slot is
|
governed down to their minimums because the number of signatures in each slot is
|
||||||
far lower than the "target" signatures per slot.
|
far lower than the "target" signatures per slot.
|
||||||
|
|
||||||
|
@ -112,21 +112,53 @@ 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
|
be determined threshold. The governing will be applied across all the fee
|
||||||
criteria.
|
criteria.
|
||||||
|
|
||||||
### How do clients calculate a transaction's fee
|
### Deterministic fees
|
||||||
|
|
||||||
Transaction fees are currently calculated based on a fixed cost per signature
|
Solana's fees are currently deterministic based on a given blockhash. This
|
||||||
and implemented via an object in the SDK that took a transaction and returned a
|
determinism is a nice feature that simplifies client interactions. An example
|
||||||
cost. This object is looked up via a blockhash and returned via RPC to
|
is when draining an account that is also the payer, the transaction issuer can
|
||||||
calculate the fee offline.
|
pre-compute the fee and then set the entire remaining balance to be transferred
|
||||||
|
out without worrying that the fee will change leaving a very small amount
|
||||||
|
remaining in the account. Another example is for offline signing, the payer
|
||||||
|
signer can guarantee what fee that will be charged for the transaction based on
|
||||||
|
the nonce's blockhash.
|
||||||
|
|
||||||
The comprehensive fee calculations are more sophisticated and depend on a
|
Determinism is achieved in two ways:
|
||||||
greater amount of information (recent program compute meter measurements). To
|
- blockhash queue contains a list of recent (<=~2min) blockhashes and a
|
||||||
move to the new fee structure the RPC APIs that return a FeeCalculator object
|
`lamports_per_signature` value. The blockhash queue is one of the snapshot's
|
||||||
will be deprecated, and clients will send their transactions over RPC and be
|
serialized members and thus bank hash depends on it.
|
||||||
returned the calculated fee.
|
- Nonce accounts used for offline signing contain a `lamports_per_signature`
|
||||||
|
value in its account data
|
||||||
|
|
||||||
Fees will no longer be calculated based on a blockhash since it is
|
In both cases, when a transaction is assessed a fee, the
|
||||||
cost-prohibitive to retain the fee cost inputs for each bank (program units,
|
`lamports_per_signature` to use is looked up (either in the queue or in the
|
||||||
account sizes). And mainly, the governed fee is based on network load now, not
|
nonce account's data) using the transaction's blockhash.
|
||||||
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.
|
This currently comes with the following challenges:
|
||||||
|
- Exposing the `FeeCalculator` object to the clients (holds the
|
||||||
|
`lamports_per_signature`) makes it hard to evolve the fee criteria due to
|
||||||
|
backward-compatibility. This issue is being solved by deprecating the
|
||||||
|
`FeeCalculator` object and instead the new apis take a message and return a
|
||||||
|
fee.
|
||||||
|
- Blockhash queue entries contain the fee criteria specifics and are part of the
|
||||||
|
bankhash so evolving the fees over time involves more work/risk
|
||||||
|
- Nonce accounts store the fee criteria directly in their account data so
|
||||||
|
evolving the fees over time requires changes to nonce account data and data
|
||||||
|
size.
|
||||||
|
|
||||||
|
Two solutions to the latter two challenges
|
||||||
|
- Get rid of the concept of deterministic fees. Clients ask via RPC to
|
||||||
|
calculate the current fee estimate and the actual fee is assessed when the
|
||||||
|
transaction is processed. Fee changes will be governed and change slowly
|
||||||
|
based on network load so the fee differences will be small within the 2min
|
||||||
|
window. Nonce accounts no longer store the fee criteria but instead a fee
|
||||||
|
cap. If the assessed fee at the time of processing exceeds the cap then the
|
||||||
|
transaction fails. This solution removes fee criteria entirely from the
|
||||||
|
blockhash queue and nonce accounts and removes the need for either of those to
|
||||||
|
evolve if there is a need for fee criteria to evolve.
|
||||||
|
- Retain the concept of deterministic fees. Clients ask via RPC to calculate
|
||||||
|
the current fee and pass in a blockhash that fee will be associated with.
|
||||||
|
Blockhash queue and nonce accounts switch to a versioned but internal "Fee"
|
||||||
|
object (similar to "FeeCalculator"). Each time there is a need for fees to
|
||||||
|
evolve the fee object will add a new version and new blockhash queue entries
|
||||||
|
and new nonce accounts will use the new version.
|
||||||
|
|
Loading…
Reference in New Issue