Looking up to Confirmation Height

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

Zach Hyatt
Mar 16, 2019 · 6 min read
Image for post
Image for post

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

  • 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).
Image for post
Image for post
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.
Image for post
Image for post
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

  • 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).
Image for post
Image for post
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).
Image for post
Image for post
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.
Image for post
Image for post
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

Confirmation of dependent elections

Coming in future versions

Serve only confirmed blocks on bootstrap network

Better ledger snapshots

Ledger pruning


The best place for all of the latest Nano updates…

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store