Add design proposal for deterministic transaction fees
This commit is contained in:
parent
8660c3581e
commit
1adf8355f2
|
@ -57,8 +57,9 @@
|
|||
- [Cluster Test Framework](cluster-test-framework.md)
|
||||
- [Testing Programs](testing-programs.md)
|
||||
- [Credit-only Accounts](credit-only-credit-debit-accounts.md)
|
||||
- [Solana Installer](installer.md)
|
||||
- [Cluster Software Installation and Updates](installer.md)
|
||||
- [Testnet Participation](testnet-participation.md)
|
||||
- [Deterministic Transaction Fees](transaction-fees.md)
|
||||
|
||||
- [Implemented Design Proposals](implemented-proposals.md)
|
||||
- [Leader-to-Leader Transition](leader-leader-transition.md)
|
||||
|
|
|
@ -0,0 +1,52 @@
|
|||
# Deterministic Transaction Fees
|
||||
|
||||
Transactions currently include a fee field that indicates the maximum fee field
|
||||
a slot leader is permitted to charge to process a transaction. The cluster, on
|
||||
the other hand, agrees on a minimum fee. If the network is congested, the slot
|
||||
leader may prioritize the transactions offering higher fees. That means the
|
||||
client won't know how much was collected until the transaction is confirmed by
|
||||
the cluster and the remaining balance is checked. It smells of exactly we
|
||||
dislike about Ethereum's "gas", non-determinism.
|
||||
|
||||
## Implementation Status
|
||||
|
||||
This design is not yet implemented, but is written as though it has been. Once
|
||||
implemented, delete this comment.
|
||||
|
||||
### The Fees Program
|
||||
|
||||
The Solana cluster has an on-chain program called Fees with just one global
|
||||
account called the *fees account*. The account holds a set of fee parameters
|
||||
that the cluster will use to calculate transaction fees in the following epoch.
|
||||
Any slot leader may submit congestion statistics to the fees account and the
|
||||
Fees program uses that data to automatically adjust the fees to maximize
|
||||
resource usage. Each validator checks congestion statistics and rejects blocks
|
||||
that include congestion data inconsistent with its own observations.
|
||||
|
||||
The client uses the JSON RPC API to query the cluster for the current fee
|
||||
parameters. Those parameters are tagged with a blockhash and remain valid
|
||||
until that blockhash is old enough to be rejected by the slot leader.
|
||||
|
||||
### Calculating fees
|
||||
|
||||
The fees account contains a variety of fee parameters. Before sending a
|
||||
transaction to the cluster, a client may submit the transaction and fee account
|
||||
data to an SDK module called the *fee calculator*. So long as the client's SDK
|
||||
version matches the slot leader's version, the client is assured that its
|
||||
account will be changed exactly the same number of lamports as returned by the
|
||||
fee calculator.
|
||||
|
||||
### Fee Parameters
|
||||
|
||||
In the first implementation of this design, the only fee parameter is
|
||||
`lamports_per_signature`. The more signatures the cluster needs to verify, the
|
||||
higher the fee. The exact number of lamports is determined by the number of
|
||||
transactions per second the cluster processed in the previous epoch versus the
|
||||
cluster's capacity.
|
||||
|
||||
Future parameters might include:
|
||||
|
||||
* `lamports_per_pubkey` - cost to load an account
|
||||
* `lamports_per_slot_distance` - higher cost to load very old accounts
|
||||
* `lamports_per_byte` - cost per size of account loaded
|
||||
* `lamports_per_bpf_instruction` - cost to run a program
|
Loading…
Reference in New Issue