Update/improve Soroban fee bump specification.

core/cap-0046-07.md

@@ -420,14 +420,33 @@ Apply-time enforcement: _None_
 
 Every Soroban transaction must contain exactly 1 operation. There is no fee for operations, but there is a ledger-wide limit on transactions (and thus operations) defined by `ConfigSettingContractExecutionLanesV0.ledgerMaxTxCount`.
 
-## "Fee bump" and failing transactions
+## 'Fee bump' semantics
 
-Soroban transactions are compatible with the 'fee bump' transactions, so the total transaction fee can be increased in order to account for the higher network contention or even increase resource fees (as both resource fee and inclusion fee are a part of `tx.fee`).
+Soroban transactions are compatible with the 'fee bump' mechanism via `FeeBumpTransactionEnvelope`. Total transaction fee can be increased in this way in order to account for the higher network contention. However, fee bump transactions can only modify the overall fee of transaction and their semantics is independent of the inner ('bumped') transaction. This leads to the following of the Soroban 'fee bumps':
 
-Soroban transactions might also fail at apply time due to too low declared resource values or too low refundable fee. The transaction sequence number will be consumed and the fees will be withdrawn. This may provide bad user experience in case if it's hard to obtain a new signature for the transaction.
+* `sorobanData.resourceFee` can not be increased via `FeeBumpTransactionEnvelope`, so only the inclusion fee can be raised
+* `sorobanData.resources` can not be modified either, which is why the fee bump envelope is transparent for the resource accounting, i.e. it is not accounted for when computing the transaction size for the sake of enforcing limits/charging the fees
+* The point former also applies to the `TransactionSet` validation: `ledgerMaxTxsSizeBytes` limit enforcement only includes sizes of the inner envelopes of the fee bump transactions
 
-We don't provide any built-in way for re-using the failed transactions in the first version of Soroban. However, the user experience can be significantly improved by decoupling the transaction signature from the signatures used for the host function invocation itself, specifically by using the Soroban Authorization Framework ([CAP-0046-11](./cap-0046-11.md)). If all the signatures are decoupled, then any party can pay the transaction fees and sign new transactions in case of failure. Nonces will only be consumed on transaction success, so the signatures can be re-used as many times as needed until the transaction succeeds.
+The relation between the resouce and inclusion fees for Soroban 'fee bumps' is defined in the same fashion as for regular Soroban transactions:
 
+`feeBumpTx.fee = feeBumpTx.innerTx.sorobanData.resourceFee + fullInclusionFee`
+
+Protocol treats 'fee bump' as an additional operation. Thus the effective inclusion fee bid used for transaction prioritization is defined as follows:
+
+`inclusionFeeBid = fullInclusionFee / 2 = (feeBumpTx.fee - feeBumpTx.innerTx.sorobanData.resourceFee) / 2`
+
+Soroban transactions might fail at apply time due to too low declared resource values or too low refundable fee. We don't provide any built-in way for re-using the failed transactions in the first version of Soroban. However, the user experience can be significantly improved by decoupling the transaction signature from the signatures used for the host function invocation itself, specifically by using the Soroban Authorization Framework ([CAP-0046-11](./cap-0046-11.md)). If all the signatures are decoupled, then any party can pay the transaction fees and sign new transactions in case of failure and there is no need to use `FeeBumpTransactionEnvelope` at all (which is cheaper). Soroban nonces will only be consumed on transaction success, so the signatures can be re-used as many times as needed until the transaction succeeds.
+
+### Future work
+
+Initial implementation of 'fee bumps' follows the 'classic' rules, which simplifies the protocol design, but comes with a number of shortcomings:
+
+* It's not possible to increase the resource fee
+* It's not possible to increase the declared resources
+* The inclusion fee has to be 2x of the inclusion fee for the regular transactions
+
+Future protocol versions may fix these shortcomings by introducing the new type of the 'fee bump' transaction envelope that addresses these shortcomings. The envelope will need to have the `SorobanData` extension that overrides the `SorobanData` of the inner transaction, so that every relevant value can be increased. The new envelope may also have a different inclusion fee semantics that wouldn't count the 'fee bump' as an additonal operation.
 
 ## Design Rationale