Work generation: Changes for consideration

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.

  • Benefits:

    • 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
  • Dependencies:

    • 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.

  • Benefits:
    • Services can pre-cache work for accounts ahead of time before blocks have been produced or related accounts and amounts are known
  • Dependencies:
    • State block v2 to be able to validate at entry without loading account
  • Open questions:
    • 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.

  • Benefits:
    • 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.

  • Benefits:
    • 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).

  • Benefits:
    • Payment processors can pre-cache work for a receive without previous knowledge of sender when using account height-based work
  • Dependencies:
    • 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.

--

Work Generation Series topics

3 Likes

I think this is necessary for any option to prevent pre-computed work, though it'd be hard to implement due to its dependency.

There needs to be a discussion on how this impacts proof of work for forks (and potential DoS there).

How would consensus/confirmation work?? This is the opposite of how cryptocurrencies work.

This has the proof of work for forks problem again.

3 Likes

We are working on the top-down bootstrapping piece and although it is hard as you note, it appears possible given the current view of it. Is there anything in particular you think we should be extra weary of for the top-down bootstrapping approach?

In V21 changes to make elections sequential help to alleviate the issue of blowing up the state space for tracing dependent election paths on forks. In addition with the ability to ignore historical work values there has been discussion of possible successors to forks receiving a higher PoW threshold, which would complicate and discourage pre-generating work for forks at multiple levels. We also will be looking at reducing the resource consumption of forks at the outset, such as limiting republishing of forks more than is currently done (this isn't so much related to deep forks but should alleviate some DoS concerns).

This description wasn't explained clearly enough so will be adjusted. Ultimately the block handoff option isn't to be used for considering a transaction complete, but rather standardize a way to send a signed block to a recipient directly so some initial checks can be avoided that the broader network enforces (mainly work requirements). Once the block is handed off, the recipient can then attach work, use the send-receive pair message, etc. and publish to the network for confirmation. So ultimately it must still go to the network for confirmation, this just provides a standard way to do some block exchanging off network first in scenarios where it may be beneficial - such as when a payment processor wants to know the block hash ahead of time for a payment. Hopefully that makes more sense - we definitely are't proposing ledger entries between two nodes that the rest of the network doesn't see or vote on.

This one will be a little trickier to handle related forks for. This would be limited only to cases where the send-receive pair was published together and not two blocks individually. Then handling of the elections would need to be done as a dependent pair. We'd need to explore how to best handle a case where the send was forked on a send-receive pair when the receive was covering send work, but given the sequential elections and limited state space of this setup it appears manageable. Was there a particular scenario you were most concerned about with this setup?

1 Like