After exploring a variety of approaches to help solve some issues including work credits, new block types and other schemes, we have some work generation changes for consideration.
As not all of these concepts have been fully explored, we're looking for assistance in evaluating their effectiveness, potential drawbacks, attack vectors, etc. Those with experience with Nano specifically, as well as other systems designed to resist similar forces, are encouraged to pitch in analysis to help us better validate the possibility of these changes.
Additional details about each option will be expanded on further as discussions get underway, but early feedback is very much appreciated!
Ignoring historical work values
Allow work values to be ignored once block is at or below current confirmation height.
- Ledger size reduction from discarding of old work values
- Work can be dynamic based on current network conditions during initial consensus without worrying about later evaluation - longer term this allows more flexible work thresholds to be implemented
- Exclusive top-down bootstrapping method required (no genesis forward method used)
Account height-based work generation
Allow work generation to be based on the hashed account number + block height instead of relying on the previous block hash.
- Services can pre-cache work for accounts ahead of time before blocks have been produced or related accounts and amounts are known
- State block v2 to be able to validate at entry without loading account
- What impact does this have on auto-receiving? Those using this type of work for receiving would need to disable auto-receiving or set a reasonable receive limit in their wallets to prevent spam attempts eating up pre-cached work. This doesn't appear to be worse than current impacts today.
Direct block handoff option
Provide methods for publishing a signed send block directly to the related receiving node instead of broadcasting across the network. The send block would still need to be published to the network and be voted on/confirmed before being considered a confirmed send.
- Enables a payment processor to accept a signed block for payment before publishing so the block hash/details can be recorded for accounting purposes
- Provides mechanism to leverage the send-receive paired block publishing below
Send-receive paired block publishing
Create a send-receive paired protocol message to handle publishing an entire transaction together.
- Allows receiving blocks covering send work option below
- Possible reduced voting bandwidth and decreased overall transaction times by allowing reduced scope dependent elections/voting
Receive blocks covering send work
Allow receive blocks using the send-receive pairing to cover work for the send block (cumulative threshold between the two).
- Payment processors can pre-cache work for a receive without previous knowledge of sender when using account height-based work
- Send-receive paired block publishing
- Ignoring historical work values
Exploring options for limiting pre-computed work
With some of the above features the ability for services to pre-compute work becomes more flexible. This levels the field a bit more against spammers, but there are still reasons to explore options to limit pre-computed work. To avoid these limitations resulting in pre-computed attacks being designed horizontally across accounts, some of the time-based expiration of work ideas are worth evaluating, but these would be larger efforts and out of scope of these short-to-medium term items.