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