Builds on the flat HookFeeV2 model:
- hook_api.macro: HOOK_API_COST(name, cost, amendment) per API, loaded
into the import whitelist and charged per import call in Guard.h
- sfHookGasPrice on FeeSettings / SetFee / validations, voted through
FeeVote and exposed in server_info, ledger streams and validations
- hook_gas_price config knob (FeeSetup) and genesis FeeSettings value
- hookCostToFee(view, cost) prices cost units with the ledger's gas price
- jtx Env applies features before the app is built so genesis FeeSettings
see them; hash-order dependent tests updated accordingly
Per-API cost tables and the votable HookGasPrice move to the HookFeeV3
branch. V2 charges one cost unit per wasm instruction and 100 units per
hook API call (including _g), with ten units per drop rounded up.
- Guard.h: drop the per-import cost map, charge a fixed api_call_cost on
every import call
- Remove sfHookGasPrice, FeeSettings/SetFee/validation fields, fee voting,
server_info output and the hook_gas_price config knob
- hookCostToFee no longer depends on the ledger view
- Restore genesis ledger, jtx Env and fragile-hash tests to dev
- Update expected hook costs in SetHook_test
Api costs were looked up as import_type_map[callee_idx], but that map is
keyed by wasm type index while callee_idx is a function index. A hook was
charged whichever api happened to occupy the callee's index, or nothing at
all when no type carried that index, and imports sharing a signature
collapsed to a single cost. Reordering imports was enough to call
util_verify, the most expensive api, for free. Costs now come from
import_cost_map, keyed by import function index, and import_type_map is
reduced to the signature checking it is actually used for.
compute_wce() applied the loop multiplier to instruction_count only, so an
api call inside a guarded loop was charged for one iteration no matter how
many the guard allowed. The multiplier now applies to execution_cost as
well, with the same floor instruction_count uses.
Due to rounding, the LPTokenBalance of the last LP might not match the LP's trustline balance. This was fixed for `AMMWithdraw` in `fixAMMv1_1` by adjusting the LPTokenBalance to be the same as the trustline balance. Since `AMMClawback` is also performing a withdrawal, we need to adjust LPTokenBalance as well in `AMMClawback.`
This change includes:
1. Refactored `verifyAndAdjustLPTokenBalance` function in `AMMUtils`, which both`AMMWithdraw` and `AMMClawback` call to adjust LPTokenBalance.
2. Added the unit test `testLastHolderLPTokenBalance` to test the scenario.
3. Modify the existing unit tests for `fixAMMClawbackRounding`.
* Add AMM bid/create/deposit/swap/withdraw/vote invariants:
- Deposit, Withdrawal invariants: `sqrt(asset1Balance * asset2Balance) >= LPTokens`.
- Bid: `sqrt(asset1Balance * asset2Balance) > LPTokens` and the pool balances don't change.
- Create: `sqrt(asset1Balance * assetBalance2) == LPTokens`.
- Swap: `asset1BalanceAfter * asset2BalanceAfter >= asset1BalanceBefore * asset2BalanceBefore`
and `LPTokens` don't change.
- Vote: `LPTokens` and pool balances don't change.
- All AMM and swap transactions: amounts and tokens are greater than zero, except on withdrawal if all tokens
are withdrawn.
* Add AMM deposit and withdraw rounding to ensure AMM invariant:
- On deposit, tokens out are rounded downward and deposit amount is rounded upward.
- On withdrawal, tokens in are rounded upward and withdrawal amount is rounded downward.
* Add Order Book Offer invariant to verify consumed amounts. Consumed amounts are less than the offer.
* Fix Bid validation. `AuthAccount` can't have duplicate accounts or the submitter account.
Combine multiple related debug log data points into a single
message. Allows quick correlation of events that
previously were either not logged or, if logged, strewn
across multiple lines, making correlation difficult.
The Heartbeat Timer and consensus ledger accept processing
each have this capability.
Also guarantees that log entries will be written if the
node is a validator, regardless of log severity level.
Otherwise, the level of these messages is at INFO severity.
