Congestion stats, take 3

This commit is contained in:
Greg Fitzgerald
2019-03-18 11:47:47 -06:00
parent 4e0316f792
commit 15947b8642

View File

@ -15,11 +15,10 @@ implemented, delete this comment.
### Congestion-driven fees
Each validator submits network congestion data to its voting account. The
cluster then uses a stake-weighted average from all voting accounts to
calculate fee parameters. In the first implementation of this design, `tps` and
`tps_capacity` are the only statistics uploaded. They are uploaded once per
epoch.
Each validator uses *signatures per slot* (SPS) to estimate network congestion
and *SPS target* to estimate the desired processing capacity of the cluster.
The validator learns the SPS target from the genesis block, whereas it
calculates SPS from the ledger data in the previous epoch.
### 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
`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.
higher the fee. The exact number of lamports is determined by the ratio of SPS
to the SPS target. The cluster lowers `lamports_per_signature` when SPS is
below the target and raises it when at or above the target.
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_byte` - cost per size of account loaded
* `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.