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
|
||||
|
||||
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
|
||||
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
|
||||
criteria.
|
||||
|
||||
### How do clients calculate a transaction's fee
|
||||
### Deterministic fees
|
||||
|
||||
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.
|
||||
Solana's fees are currently deterministic based on a given blockhash. This
|
||||
determinism is a nice feature that simplifies client interactions. An example
|
||||
is when draining an account that is also the payer, the transaction issuer can
|
||||
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
|
||||
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.
|
||||
Determinism is achieved in two ways:
|
||||
- blockhash queue contains a list of recent (<=~2min) blockhashes and a
|
||||
`lamports_per_signature` value. The blockhash queue is one of the snapshot's
|
||||
serialized members and thus bank hash depends on it.
|
||||
- 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
|
||||
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.
|
||||
In both cases, when a transaction is assessed a fee, the
|
||||
`lamports_per_signature` to use is looked up (either in the queue or in the
|
||||
nonce account's data) using the transaction's blockhash.
|
||||
|
||||
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