Looking up to Confirmation Height

Exploring how high this new feature in V19 Solidus will take us

Confirmation height is a major feature included in the upcoming Solidus release of the Nano node and helps make the network more secure, efficient and accessible while laying the foundation for a host of new features.

Once this height is set in V19, it will provide confirmation history, allow for the cementing of blocks in the ledger, and will be used to reduce elections. These changes will allow for lower network traffic and enable easier ways to integrate services with Nano.

Let’s take a tour through what this addition is and what it enables for future versions.

Today’s real-time election processes

To date, Nano nodes have relied on a real-time election process to determine whether blocks are confirmed across the network. These elections regularly occur and as of today their results are not explicitly captured by nodes for later reference. Instead they are observed in real-time and if there is any question on their validity at a later time, the node requires doing the same election process over again. Here is a simplified explanation of how it works and the numbers listed correspond to the diagrams mixed in:

  • When blocks are received on the live network via UDP (User Datagram Protocol), they are inserted into the ledger (1) and elections begin (2). This means nodes vote on whether the transaction is valid and share those votes with other nodes they are connected to.
  • Votes on blocks and any possible conflicting blocks are tallied up. The losing blocks are removed leaving only the single winning block (3). Once this quorum is reached on the winning block it triggers the RPC (Remote Procedure Call) callback (if configured) and it shows up in other RPC calls so that services tracking in real-time can verify it was confirmed by the network (4).
  • In addition to the UDP network, blocks can also be requested in bulk from other nodes via the TCP (Transmission Control Protocol) bootstrap network (5). This is mainly done when starting a new node or when gaps in blocks for an account are detected, such as when a node is out of sync. When these blocks come in via the TCP bootstrap network they are inserted into the ledger but elections aren’t started. Because of this, RPC callbacks aren’t triggered and they aren’t returned in any RPC calls which are reserved only for confirmed blocks.
  • The confirmation of these bootstrapped blocks is implied by future confirmations on the live network for blocks ahead of them (6). Confirmation for bootstrapped blocks can then be considered a passive process in order to save voting traffic (7).
Pre-Solidus real time election process diagram.
  • Because historical voting data is not recorded by nodes, the only way a node knows a block is confirmed is to observe the result of a live election. From the node’s perspective it can’t definitely say by itself whether an older block was previously confirmed on the network. This is because blocks can come in via the TCP bootstrap network without triggering active elections.
  • The result of this design is that if at any point confirmation is needed for a specific block not active on the live network, you would need to make the RPC block_confirm call for that block (8) which would start a new election on the network (9). Once network quorum was reached (10) the RPC callback would be triggered (11) and you can observe and record the necessary details outside the node.
Diagram showing how nodes must determine confirmation for blocks not in active elections

This reliance on real-time voting for confirmations has a few consequences including extra traffic on the network from repeated elections and more difficult processes for determining whether blocks have been confirmed by the network if they are not seen during real-time voting.

A better way to confirm

With Solidus and the introduction of confirmation height, this dependency on real-time elections is removed. Instead, confirmations are tracked using a single field on the account as follows:

  • Currently on V18, each block added to an account is given a block height — an integer value starting at 1 for the first block and incrementing with each block added. So, for example, the 15th block on an account would have a block height of 15.
  • With confirmation height, when a block reaches quorum on the live network it is considered confirmed and the confirmation height on the account gets set to the block height value for that confirmed block (15, 17).
Solidus will introduce confirmation height which eliminates the need for real-time elections on the confirmation status of blocks not in active elections
  • The node will then trace down to any ancestor blocks and update the confirmation heights for the associated accounts which have now been implicitly confirmed (18).
How confirmation height funnels down to ancestor blocks
  • As additional blocks appear on the live or bootstrap networks they are evaluated against this confirmation height and if they match up with a block height equal to or lower than the current confirmation height, they will be discarded as invalid. No forks are considered or elections started and this results in immediate “cementing” of blocks at or below the confirmation height.
  • When confirmation on a block needs to be performed the RPC block_info call can be made (19) and the comparison of block height to confirmation height will result in either a true or false response (20). This is done without triggering additional elections on the network.
Here we can see that querying a block for confirmation status no longer results in election on the live network.

Confirmation height provides the foundation for a number of great features, some of which are included in this release and others are planned for future updates.

Available in V19

Confirmation status included in RPC calls

Updates to the block_info and blocks_info RPC calls to return details about confirmation height are included in V19. This was previously not available due to the need for starting an election to verify confirmation for blocks not active on the live network, but now with confirmation height it is a simple check of the block height in question against the confirmation height on the account.

Confirmation of dependent elections

When confirmation height is set, any blocks below that height in the account are also considered confirmed by extension, as well as any dependent blocks from other account chains. This means the node can stop any elections for these lower blocks and remove them from any processing queues. This will save processing and bandwidth resources.

Coming in future versions

Serve only confirmed blocks on bootstrap network

Today the bootstrap network can serve both confirmed and unconfirmed blocks to their peers upon request. But with confirmation height the bootstrap blocks can be limited to only confirmed blocks which helps reduce proliferation of unconfirmed blocks.

Better ledger snapshots

When snapshotting ledgers for use in other nodes, they can be limited to only confirmed blocks up to the confirmation height. This allows a ledger to be used in certain trusted scenarios with a guarantee that blocks contained within it have already been confirmed on the network.

Ledger pruning

This confirmation height provides a value around which pruning efforts can be more easily managed. As the frontier of confirmation, all blocks with heights lower than this value can be removed from the ledger regardless of the number of unconfirmed blocks ahead of it.