diff --git a/docs/src/proposals/comprehensive-compute-fees.md b/docs/src/proposals/comprehensive-compute-fees.md index a47460dec..236951e76 100644 --- a/docs/src/proposals/comprehensive-compute-fees.md +++ b/docs/src/proposals/comprehensive-compute-fees.md @@ -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.