As we continue to develop the protocol and the node implementation, we are constantly discovering opportunities for improvement. Some improvements would be very welcome on the network, but aren't possible or as effective with the current state block structure. Because of this, the introduction of a new state block version with structural changes is becoming a priority.
This topic is aiming to discuss the changes we are considering and why we think they are worth the effort. Before formalizing the specification for a new state block, we want to explore all possible additions to help reduce the need for additional versions in the future. This is especially important because each new block version not only requires an upgrade process with multiple node releases, canary blocks or epoch blocks, but also requires hardware wallets and other custom integrations to change their payload setup and signing code.
With some of these changes it is important to remember that even though the data being considered for addition to the block may be available already either explicitly or implicitly from other data the node has access to, in many cases additional computational or disk IO resources are required to access it. Adding them directly to the block may save on these resources but of course comes with tradeoffs including additional bandwidth usage.
As the theoretical bottleneck with Nano is bandwidth, we must do our best to weigh these tradeoffs to ensure their long term impact is properly balanced.
Candidates for new fields
Size: 1 byte
This would replace previous epoch version markers and provide a point in each account chain to transition certain behaviors in the node. For example, when the new work algorithm is implemented an incrementing of the block version could be used to signal an account switching over.
This also provides a clear indication at the network level of what epoch or version a block is, allowing for better filtration and management of traffic before further resources are used to validate these details.
Size: 64 bits (Max block height per account: 18,446,744,073,709,551,615)
This is a powerful addition to the block payload as it allows easier filtering of unwanted traffic in certain scenarios:
If the block may be discarded due to it being below the existing confirmation height for the account
If the block could possibly be a fork without having to reference the root
It also makes it easier to understand the relationship of the block to the ledger when it does not fit on a known chain. Currently blocks for an account that don't fit the existing chain don't provide that context to know how close they are to the current frontier (unless an open block), but the block height provides that context.
Size: 1 byte
The original state block design removed the need for different types of blocks having different structures. This improvement made some elements of the node and protocol simpler, but also removed context which can be useful in certain scenarios, including during block validation.
Although more detail is needed to finalize the flags, the main considerations are indicators of the signature being used (epoch vs. self signed) and how to interpret the link field value (hash for receive, account for send, etc.). Requiring these will help streamline management of the block on arrival and offer additional protection against certain accidental changes such as sends to the burn account.
Not all bits in this field would be used in the current design, saving room for additional uses for this field in the future.
Size: 16 bytes
Although the amount of Nano being transferred by a block is easily calculated by comparing balances between the current and previous blocks, adding an amount field gives more explicit details on the intended transfer.
This is helpful for various offline wallet or lighter node implementations, as well as with some pruning scenarios where keeping the previous to pending send blocks may be necessary if this field wasn't available.
We are proposing these block changes after careful consideration of the benefits and tradeoffs. We are interested feedback and analysis of these additions, especially around possible drawbacks seen against potential benefits.