BPL Delegate Node Software: Automatic Updates

White Paper

Purpose

This article describes the Automated Update process coming to the BPL Delegate Node Software, which will be referred to as bDNS for the remainder of this document.

We have designed the update process to encompass the full release cycle for all future versions of bDNS from development, community testing, through to mainnet.

This secure and strict update process lets Blockpool release enhancements without impacting the integrity of the Blockpool network.

Concept

One of the main challenges we face as developers revolves around system critical changes to either database structure or the blockhash of the chain.

If we continue to deploy changes to the Blockpool mainchain in the traditional fashion — where each delegate updates their own node manually — there is some chance that delegates may miss a notification or simply not have time to complete the update in the required timeframe. If enough delegates were to miss an update, we would open ourselves up to chain conflicts and potential forks.

To avoid this issue Blockpool have developed a robust release process that tracks a Package from devnet through to Community Testing and finally, after a fully transparent testnet vote, deploys this automatically onto every mainnet node.

The automatic update process deploys not only code changes but also ensures that the database is always up-to-date with the most recent version.

Timing

The v0.5.5 update includes system critical database and blockhash changes. Thus it is necessary for v0.5.5 to be released on mainnet before we are able to deploy the code for Sidechains and Smart Contracts.

New Data Types

To support this new process we’re creating two new data types, Update Transaction and Poll Creation Transaction.

Update Transaction (type 8)

This transaction contains the information that communicates and triggers the Automated Update Process. An Update Transaction can only be transmitted if it is signed by a defined Private Key. It contains the following information:

VersionLabel — what we are calling the pending release (0.5.5, for example)

CheckHash — SHA256 / SHA 512 hashed signature of the package

BlockHeightTrigger — the block height at which the auto update will take place

IPFSPath — the link to the Package on IPFS

VerifyingTransactionId — nullable verification backlink

Pending Release

This is a system table that contains information about an upcoming release. It contains the following information:

VerifyingTransactionId — Transaction Id of the Verifying Update Transaction

BlockHeightTrigger — block height at which the Auto Update will take place

Poll Creation Transaction (type 9)

This transaction supports the creation of a poll which will be leveraged in the Auto Update Process. It contains the following information:

PollName — what you want to call the poll

PollingAddress — the address that will become associated with this poll

PollStartDate — the date from which this poll becomes active

PollEndDate — the date at which this poll becomes inactive

PollIntentions — an array of valid options for the poll

There are some constraints on these fields, as follows:

PollingAddress — must be unique

PollStartDate — must be in the future and a maximum of six months in the future

PollEndDate — a maximum of twelve months after the PollStartDate

PollIntentions — minimum of two options, must be unique options

Full details on Poll functionality will be released in a future White Paper.

How it works

The following describes the steps a new Package will take to mainnet via the Automatic Update process.

Please Note: this is NOT the deployment process for version 0.5.5, which will be communicated separately. This document covers the deployment process for all subsequent bDNS versions after v0.5.5 has been released on mainnet.

  1. A Candidate Release will complete internal Development Testing and will be compiled and packaged into a zip file.
  2. The Candidate Package will be pushed to IPFS and an Update Transaction will be pushed to BPL testnet. This occurs via an internal process the involves multiple signoffs from within the Blockpool team. This transaction is termed the Initiating Update Transaction.
  3. After a certain period of time a second Update Transaction is pushed to the BPL testnet. This is identical apart from it contains the transactionId of the Initiating Update Transaction in its VerifyingTransactionId field. This transaction is termed the Verifying Update Transaction.
  4. A Poll will be created by Blockpool with two Intentions (“YES” and “NO”) that will be used for the testnet voting process. This will open after testnet has been running for at least one week, and will remain open for at least two weeks, though these details will be defined for each release and communicated with the Community
  5. When a testnet bDNS forges a block containing the Verifying Update Transaction it will validate with the Initiating Update Transaction by checking that values are identical. If validated it will transmit to all other bDNS (both forging and relay) that there is an update to perform at a specified block height by entering a value into the PendingRelease table.
  6. As soon as a testnet bDNS (both forging and relay) becomes aware of a new release it will carry out a verification step itself and then download and unzip the package immediately into its inactive location.
  7. When the correct Block Height is reached every testnet bDNS will switch the inactive folder to become the active folder (including running any packaged update scripts on the database) and make the currently active folder the inactive one. The strategy we are using for this is a class of Blue/Green deployment.
  8. During the Poll Period (created in step 4) testnet delegates will be able to vote YES or NO using myBlockpool or BPL Desktop Wallet. The vote will be aggregated automatically by BiT at the PollEndDate with the following rules:

· one valid vote per originator address

· contradictory votes from the same originator address cancel each other out until one Intention has one more vote

· only addresses associated with testnet bDNS delegates will have eligible votes

· votes received outside of the defined voting period will be ignored

9. Once the vote has been aggregated the results will be pushed to IPFS and the IPFS link will become available for review by anyone. If the vote results in a “NO” then the process will stop here and consultation will take place.

10. In the case of a YES vote BiT will automatically process the Package to be pushed to live. There are internal checks and balances that are applied for sign off within the Blockpool Organisation and when these are complete BiT will push an Update Transaction to the mainnet. This will point to the SAME IPFS PACKAGE that was used in testnet; the CheckHash voted for on tesnet will be IDENTICAL on this mainnet transaction.

11. After a certain period of time a second Update Transaction is pushed to the BPL mainnet. This is nearly identical to the first Update Transaction, but the second one contains the transactionId of the Initiating Update Transaction in its VerifyingTransactionId field.

11. When a mainnet bDNS forges a block containing the Verifying Update Transaction it will validate with the Initiating Update Transaction by checking at tall values are identical. If validated it will transmit to all other bDNS (both forging and relay) that there is an update to do at a specified block height by entering a value into the PendingRelease table.

12. As soon as a mainnet bDNS (both forging and relay) becomes aware of a new release it will carry out a verification step itself and then download and unzip the package immediately into its inactive location.

13. When the correct Block Height is reached then every mainnet bDNS will switch the inactive folder to become the active folder (including running any packaged update scripts on the database) and make the currently active folder the inactive one. The strategy we are using for this is a class of Blue/Green deployment. With this release, speed of update takes a higher priority than having a roll back option.

Summary

The Auto Update process is designed to future proof BPL and its sidechains while continuing our excellent interaction with the community. It ensures that patches and improvements are rolled out across the entire network in a safe manner that does not risk delegates falling behind and causing potential fork issues.

As BPL grows and more Sidechains come online, the logistical problem of keeping all delegates up to date and running a consistent bDNS version will only become more and more challenging. Thus it is vital that we solve this challenge now.

-The Blockpool Team