BUIP021: Proposal for implementation of node performance testing and safe block size estimation and broadcast
Proposer: Peter Waterland
Submitted: 2016-07-18
Status: draft

Background:
A major concern raised over on-chain-scaling is the presumption that a
rising blocksize will harm decentralisation of the network and lead to a
falling number of non-validating nodes. No assessment of true individual
node performance or means to gauge this currently exists for the bitcoin
network. Armed with this knowledge it would be possible to objectively
evaluate the potential performance increases the network could endure
without losing nodes for purely technical reasons (rising cost
excluded). If nodes on the network begin to broadcast a ‘safe’ block
size threshold to which they can perform then miners will be confident
in safely raising the block size in the future.

Proposal:

This proposal is to incorporate a suite of simple benchmarking tests to
the unlimited node software package to allow a specification of the node
in terms of: CPU performance, memory capacity, storage space and perhaps
most importantly network bandwidth capacity to be recorded.

This information can be passed across the network upon request to allow
analysis of the specifications and capabilities of the nodes making up
the network as a whole.

Each node after running the node performance suite will be assigned a
‘safe to X mb block size’ value which can be broadcast to the network
and is independent of other node settings. The default setting for this
should be active, with a user configurable setting to disable this.

Data gathering required prior to implementation:
The team will run an experimental testnet of BU nodes at different
gradations of maximum blocksize from 1 to 50mb (and varying connected
numbers of nodes) to generate simulated mainnet bandwidth traffic
between nodes (Xthin enabled) which will be measured.

This data will then be used along with estimations for ECDSA validations
and calculated disk space for a year of blockchain growth at each
maximum blocksize between 1 and 50mb to create a table of recommended
node specifications for each block size greater than 1mb at 0.5mb
intervals.

Detail of performance testing:

Code for benchmark testing may either be standalone to be run
periodically and and generate a report for the node to use or could be
merged directly into the codebase.

Fine details of testing routines to be left to developers.

CPU performance:
A testing routine should be performed which assesses the maximum number
of ECDSA validations the node is able to perform per second. Fairly
trivial.

Memory capacity:
This is even more straightforward. The total available memory capacity
of the node (in gigabytes) to be recorded (to give a theoretical maximum
mempool size).

Network assessment:
A testing routine to assess maximum available bandwidth (up and
downstream) to the bitcoin network.

Storage:
Maximum available disk space to the node recorded. This can then be used
to generate theoretical blockchain growth capacity in years based upon
various blocksizes.

Safe for blocksize setting:
Once the above benchmarking tests have been performed for the node a
value will be generated to signal to the network that the node has
required capacity (CPU power, memory storage, disk space and network
bandwidth) to tolerate data associated with a maximum block size up to a
given value.

The node will compare the results of the benchmark tests with the table
generated/supplied by the development team to select the appropriate
value. A suitable safety margin will be integrated.

As this is bitcoin unlimited this will be activated by default but will
be user configurable to deactivate.

Conclusion:
Decentralisation is vital to the bitcoin network. It seems obvious that
some form of network assessment to identify node specifications prior to
network performance upgrades should be integrated into node software.
Bitcoin Unlimited has the opportunity to be the first to integrate
this.

Voting:
Voting will be either a YES or NO to both integrate performance testing
into BU and activate a (user configurable) ‘safe for x mb blocksize’
setting which is visible to the network.

Final comments please, prior to voting…