First published on VOICE in January 2021 -> Check it out here.

While we can’t yet dive inside the super-secret GitHub repositories, to learn more about the long-awaited financial product and other secret developments, we can view the ongoing public improvement of eosio and envisage future capabilities. 

In this eosio developments series #3 part #1, we look into one of the recently announced enhancements, BlockVault, part of the 2.1 release candidate of eosio.

Current State

Before 2.1RC, a block producing node failure in a public network would result in missed blocks and a pause of up to six seconds where the network cannot process any new transactions. Block producer intervention is necessary to switch out the failed node to a backup and restore the network to full write capacity. Block producers have crafted numerous workarounds and improved their processes to reduce downtime, but until now, there was no built-in option for minimising the impact.

To highlight this issue, the Aloha Reliability Tracker monitors block production, and alerts missed rounds around the clock. Check out the telegram channel for full details.

In a private eosio network, running a single producing node (such as, 2.1RC introduces new high availability (HA) and resiliency capabilities.

Source: Screenshot of cleos CLI output for Single “producer”

In previous versions, losing “producer” would force the entire chain offline and require the operations team to reinstate network function from a snapshot or backup. There are many ways to achieve this, but human intervention would be necessary to get back up and running. Automation is possible, but there was no elegant option available to app builders and maintainers. 

Furthermore, day two operational duties such as upgrades or server maintenance, are challenging and require coordination to achieve without network impact. Again workarounds exist but are suboptimal when compared to modern cloud-based products.   

BlockVault To The Resue

To fill the gap, developed BlockVault (or Nodeos Clustering) and added it to the impressive list of features available in eosio 2.1RC. Amanda Clark, Product Manager for eosio at, best describes the feature in this video.



When describing the new capability, the article states:

Nodeos now supports clustering for the block producer node, enabling blockchain administrators to implement industry standard high availability or disaster recovery architectures…”

While this feature increases resiliency for block production on public networks, it also provides particular value for private chains running with a single logical producer. Single-producer chains can use it to provide immediate finality…

BlockVault High-Level Architecture

To picture BlockVault’s potential, the following depiction illustrates a two-node eosio cluster, connected to a highly availability Postgress database.

Building a BlockVault network resembles a conventional design, except for the BlockVault Plugin which works in tandem with the Chain Controller, to coordinate block production amongst the cluster.

When a nodeos instance connects to a BlockVault cluster with the plugin activated, all nodes effectively write the chain, with the fastest writing the next block.

To the developer and operations team, this is a welcome abstraction. Clustering provides greater confidence in the networks ability to remain available during maintenance or failures. Failure in any global network frequently occurs, meaning the concept of a logical block producer increases resilience and makes the system more robust. 

Additionally, the eosio network with BlockVault may be fronted by load balancers giving system administrators control over the direction of traffic and transaction flows. It’s worth noting each node in the cluster can service read requests which provide horizontal scalability. We’ll cover this in part 2.  

Finality In A BlockVault Enabled Network

Using this capability in a private network enables almost instant and resilient finality (0.5 seconds) when deployed in a single geographical region. For enterprises running production from a single location or cloud region, BlockVault can guarantee a transaction is written to, and finalised to the blockchain, before acknowledging user actions. 

Anyone who has used an application on EOS Public Blockchain will have experienced the benefit of half-second transactions. The user experience (UX) gains are extraordinary, to the point that using other chains feels like a significant downgrade. However, as many of my readers would know, there is still a lag time between the initial commitment, and it’s eventual finalisation. There is always a risk (albeit small) data will be lost, and transactions get forked out of history. This risk may be acceptable for people using the public network; however, for Enterprise, such a threat may not be permissible.      

Eosio enabled with BlockVault provides new options for Enterprises looking to build on Blockchain Technology. Enterprise apps where a finality time less than or equal to half a second, can use BlockVault to guarantee their customers’ transactions without extra tools. Half a second is good enough for many use cases in web, mobile and transactional environments today. 

For Enterprises who require a higher degree of certainty, eosio BlockVault may be coupled with optional add ons to bridge the gap. For example, Dfuse transaction life cycle management can report unexpected failure, allowing the app to re-propose a transaction if necessary. Alternatively, it’s possible to connect eosio to the forthcoming Dfuse Kafka plugin or use eosio’s upcoming built-in AMQP plugin to propose new transactions in an Event-Driven Architectural model. Such tools support replay of failed transactions, but that’s a topic for another day.  

Community Feedback

BlockVault is a “Developer Preview” so feedback is an essential part of improving the product. Discussions so far have identified several concerns which will likely get addressed before the code is generally available (GA).

While BlockVault helps make eosio more flexible, it does offload some of the complexity to the external database. cc329d on Twitter pointed out the plugin does not set up indexes or provide any database management. No database management may result in future performance degradation or system slow down. It also requires system administrators to be familiar with Postgress databases, and be willing to use the specific database in their production environments.

Matthew Darwin pointed out some discrepancies between the advertised feature set and the code itself but noted this is typically for a developer preview.

Following the release of 2.1RC, we at CrytpoWriter reached out to with our own set of questions. In part 2, I’ll explore Bart Wyatt, VP, Blockchain Engineering responses and dive a little further into what this means for eosio and importantly the EOS Public Blockchain in the future.

Stay tuned for more eosio developments.