gaspersic/solana
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Congestion stats, take 3

Browse Source
This commit is contained in:
Greg Fitzgerald
2019-03-18 11:47:47 -06:00
parent 4e0316f792
commit 15947b8642
1 changed files with 18 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
proposals/src/transaction-fees.md
View File

@ -15,11 +15,10 @@ implemented, delete this comment.
### Congestion-driven fees ### Congestion-driven fees
Each validator submits network congestion data to its voting account. The Each validator uses *signatures per slot* (SPS) to estimate network congestion
cluster then uses a stake-weighted average from all voting accounts to and *SPS target* to estimate the desired processing capacity of the cluster.
calculate fee parameters. In the first implementation of this design, `tps` and The validator learns the SPS target from the genesis block, whereas it
`tps_capacity` are the only statistics uploaded. They are uploaded once per calculates SPS from the ledger data in the previous epoch.
epoch.
### Calculating fees ### Calculating fees
@ -37,9 +36,9 @@ lamports as returned by the fee calculator.
In the first implementation of this design, the only fee parameter is In the first implementation of this design, the only fee parameter is
`lamports_per_signature`. The more signatures the cluster needs to verify, the `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 higher the fee. The exact number of lamports is determined by the ratio of SPS
transactions per second the cluster processed in the previous epoch versus the to the SPS target. The cluster lowers `lamports_per_signature` when SPS is
cluster's capacity. below the target and raises it when at or above the target.
Future parameters might include: Future parameters might include:
@ -47,3 +46,14 @@ Future parameters might include:
* `lamports_per_slot_distance` - higher cost to load very old accounts * `lamports_per_slot_distance` - higher cost to load very old accounts
* `lamports_per_byte` - cost per size of account loaded * `lamports_per_byte` - cost per size of account loaded
* `lamports_per_bpf_instruction` - cost to run a program * `lamports_per_bpf_instruction` - cost to run a program
### Attacks
#### Hijacking the SPS Target
A group of validators can centralize the cluster if they can convince it to
raise the SPS Target above a point where the rest of the validators can keep
up. Raising the target will cause fees to drop, presumably creating more demand
and therefore higher TPS. If the validator doesn't have hardware that can
process that many transactions that fast, its confirmation votes will
eventually get so long that the cluster will be forced to boot it.