More deterministic fee info (#20825)

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.