The upcoming network upgrade

After over a year in development, thousands of development hours among dozens of contributors, and tireless work and planning, I am very excited about what the next few months hold for our Stratis blockchain node software. Long awaited since the start of our journey in the early 2017, we are releasing stable versions of our node to make a huge technical leap forward. We will finally be switching over to a blockchain network running entirely on C# in dotnet core. 
Over the course of the next few months, Stratis blockchain will experience a network software upgrade. In the crypto space, an upgrade of this kind is very probably unique; no blockchain network has upgraded its software to a new version written in a different programming language while the network is live. Nodes running the C++ version of the software will coexist side by side with nodes running the C# version of the software. This situation will continue until the majority of miners have upgraded to the C# software. At this point, the C++ implementation becomes obsolete, and we can finally retire that inflexible software. In its place will be our well structured, fully modular and modern C# node that gives Stratis and its clients the flexibility they need to build innovative blockchain solutions.

The Stratis development team are part of the Stratis Group Ltd. company and are (currently) the only maintainers of the Stratis token code base. However, the company does not control the network itself, and the network is ultimately the responsibility of the miners (or stakers as this is a PoS network). The developers can only propose changes to the codebase and then attempt to convince miners to adopt the upgrade to the C# implementation. Therefore, the coming upgrades require a general consensus within the community.

The network software upgrade will happen in 3 stages:

  1. Both implementations run side by side until the C# version is stable.
  2. Coordination with the exchanges so they can move to the new version of the codebase.
  3. Older implementations are retired by shutting down the gateway nodes (see below).

What’s coming in the upgrade

This current software upgrade has two main parts to it: a consensus change and a protocol upgrade.

General stability

The new release has been extensively tested at node level and, with the introduction of a UAT (User Acceptance Testing) environment, at the network level. Improvements have been made to memory consumption and network bandwidth. There has been a focus on node stability because it is an important requirement (especially for mining nodes) to be able to run uninterrupted for long periods.

Consensus change

Cold staking is a secure way to mine blocks without exposing the private keys, which are controlling the coins, to any risk. Cold staking requires a change to the consensus and will be activated using the BIP9 specification. Cold staking blocks will only be accepted by upgraded peers when 90% of miners signal that they have accepted the change. The high percentage requirement is for security reasons. Once cold staking is activated, the legacy implementation becomes vulnerable to a network split attack because it accepts blocks which the C# nodes do not consider valid and therefore reject.

You can read more this here:


The progress of cold staking activation can be found here:

Protocol changes

There are two big changes to the Stratis C# implementation.

1. Syncing as Bitcoin Core

The fundamental design has been changed so that all potentially relevant chains are tracked. This means the way a node will handle network splits (or reorgs) is more secure and conservative.

The C++ implementation downloads full blocks in order to find the best chain. This methodology is inefficient, has weak security, and is prone to attacks. The new implementation (inspired by the Bitcoin Core) keeps an internal tree of all known chains. A swap to a better chain (a chain with more work) that is inside the max reorg protection window only occurs once all blocks for that chain are downloaded and partially validated.

2. Proven Headers — A “headers first” solution adapted for Proof of Stake

A Proof Of Work header is small and very simple to validate. The proof that the creator is allowed to produce the block is in the header’s hash itself. If the header’s hash meets the difficulty in the bits field it means the creator has the right to mine the block.

With Proof Of Stake, the proof the creator of the block is allowed to produce a new block is in the second transaction of the block (not in the header as with POW). Proven Headers adds additional metadata to the headers, which contains the proof to validate the header. This includes the coin that produced the block, the merkle proof, and the block signature. Including this information prevents malicious parties from producing multiple fake headers. These fakes can cause nodes to be “stuck” for long periods trying to download non-existent blocks until a genuine chain, which is longer than the fake chain, becomes available. Nodes will be able to verify a block was produced correctly for a proven header before downloading the block.

Proven headers is a protocol change that is immediately available once a node has been upgraded. You can read more about Proven Headers here:


How can both implementations exist side by side?

The dependency of the C# implementation on proven headers means that upgraded nodes cannot download blocks from legacy nodes. To overcome this issue, gateway nodes have been introduced that will act as a bridge between the two implementations. Gateway nodes are completely invisible and appear as any other node on the network.

Note that legacy nodes can, however, download blocks from the new nodes as normal. The gateway node will be removed once the majority of the miners have upgraded to the C# implementation (which can be ascertained via cold staking activation tracking). Legacy nodes can still, however, validate blocks. Stratis aims to work with companies and services around the Stratis token and encourage maximum migration to the newer C# implementation.

A more fluent release process

To achieve a stable version of the Stratis Full Node, more frequent releases are required and each release still needs to contain quality code.

One of the changes arriving with this release is the introduction of a UAT (User Acceptance Testing) environment. This will allow Stratis to test and release new versions of the Stratis Full Node more frequently.

When features are developed, the developers write tests to verify the new code is working correctly. However, this code does not test all the components of the Full Node and the network as a whole, so regression testing is required. Now, when a release date is decided:

  1. A snap shot of the master branch (where the active development takes place) is tagged and at this point a release branch is created.
  2. The release branch undergoes a series of regression tests where the creation of many blockchain networks is automatically simulated. This make sure nothing is broken.
  3. If the regression testing found bugs those are fixed on the release branch and then merged to the master branch.
  4. The regression testing runs for a few days and if all is well, the binaries for the branch are released on GitHub.

The UAT environment is not part of the open source project but is offered freely by the Stratis company as a service for the Stratis token. This UAT environment will be offered as a service for testing other public blockchains that have active release cycles.

To summarise

I am very proud of what the development team here at Stratis have been doing over the past two years and their hard work and dedication can be seen in the powerful software we have in the C# Full Node. Software development is an ongoing process of improvement and innovation. Every once in a while, this results in a significant upgrade such as we will see over the coming months. This upgrade gives Stratis a formidable foundation and I am excited to see what will be built on top of it.