In this article we walk you through our recent upgrade of our validator node on the Sovrin network. This is a detailed read, but in short:
- Anonyome Labs is proud to host a validator node on the Sovrin network.
- We recently upgraded the Anonyome validator node to conform to the latest technical and organisational requirements for being a Sovrin Steward.
- We upgraded our node’s server hardware specifications, reviewed our security polices and reconfigured our network configuration.
- Given the importance of each individual node to the performance of the overall Sovrin network, we took a very meticulous approach to upgrading our node.
- We are proudly the first Sovrin Steward to host a node in Australia.
Now, let’s dive into the detail.
In 2018, Anonyome joined the Sovrin Foundation as a Founding Steward. As a global non-profit consortium, the Sovrin Foundation aims to give the control of digital identities back to the people by enabling self-sovereign identity (SSI) for all. It does this through the governance of the Sovrin network – a decentralized ledger for identity.
The Sovrin network is underpinned by distributed ledger technology (DLT) based on Hyperledger Indy, a ledger system that is replicated by multiple entities across multiple locations. The replication of the network is known as decentralization and it prevents a single authority from gaining control of the data. A well-known example of a DLT being used today is the Bitcoin blockchain, where entities known as miners replicate and contribute to the ledger.
Unlike the Bitcoin ledger which stores Bitcoin transaction data, the Sovrin network is purpose-designed for identity management while storing no personal data in its ledger. Individuals and organizations can use the Sovrin network to create verifiable digital credentials that allow them to prove who they are and validate certain facts about themselves while still retaining full control of that information.
The reliability of the Sovrin network comes from the fact that Sovrin is a ‘public permissioned’ ledger. This means that anyone can read from the ledger, but only trusted entities can replicate and write to it. These trusted entities are known as validator nodes (the equivalent of a miner in Bitcoin) and can only be administered by Sovrin Stewards. The Sovrin Stewards are a pool of trusted organizations, governments and businesses that volunteer resources and time towards hosting a validator node.
You can see the components of the Sovrin network here:
Sovrin’s vision of enabling privacy-enhancing decentralized identity for all closely aligns with Anonyome Labs’ vision of putting the user in control of their personal data, and we are proud to be contributing to the operation of the Sovrin network.
Since we launched our node in 2018, the technical requirements for being a Sovrin Steward have changed as the network has grown and matured. This meant we had to upgrade the Anonyome validator node to conform to the latest technical and organisational requirements. Elements to upgrade included computing hardware, new security polices, and specified network settings. Also, Anonyome’s Steward Node administrators have changed and we needed to communicate this to Sovrin.
What is required of a Sovrin Steward?
The technical and organisational policies that Sovrin Stewards must conform to are instrumental to the durability and security of the Sovrin network as a whole. The Sovrin Governance Board agrees on these requirements and they are publicly documented in the Sovrin Governance Framework.
The specific policies to which a Steward must conform depends on the specific Sovrin network in which their validator node is running. Sovrin currently runs three networks: MainNet, StagingNet (sandbox network) and BuilderNet (test network). A validator node running on the MainNet must meet the specific requirements set out in the policy documents, while for other nodes on the other networks, this is only highly recommended.
At the time of writing, the Anonyome node runs on StagingNet, but to future-proof our node and to participate in MainNet operations, we wanted to bring our node to full compliance.
The changes meant upgrading our node’s server hardware specifications, reviewing our security polices and reconfiguring our network configuration. We also advised Sovrin of our new Sovrin Steward administrators.
We took a careful step-by-step approach to upgrading the node
Given the importance of each individual node to the performance of the overall Sovrin network, we took a very meticulous approach to upgrading our validator node.
Our node is hosted on Amazon Web Services (AWS) and uses their Elastic Cloud Compute (EC2) and Virtual Private Cloud (VPC) offerings. Hosting our node on AWS allows for streamlined scalability, automated backup options and peace of mind that our node is running on a robust, secure server. We chose to run our node in the AWS Sydney data centre to bring greater geographic diversity to the Sovrin network and, as such, we were the first Steward to host a node in Australia.
The first upgrade step we took was to compare the current node’s baseline attributes with Sovrin’s Steward Node requirements. This involved investigating the hardware specifications of our EC2 instance type, understanding the network configuration of our node and verifying all our security policies.
From our findings, we identified two main areas to act on. First, we wanted to test our recovery process, to ensure that if an outage were to occur, we had a clear, practised approach for recovering our node. Second, we wanted to bring our node into full compliance by upgrading the hardware and reconfiguring the network settings.
Due to the high-availability requirements of the node, it was important to minimize the amount of downtime we had during the upgrade process. To ensure that we knew exactly what to do when upgrading the node, we built a second ‘test’ validator node that was not connected to the Sovrin network. Using this ‘test’ node we did a practice run-through of the recovery and upgrade process, documenting the steps we took. Once we had a good grasp of the steps required to upgrade our node, we notified Sovrin of our plans to take down the node and the anticipated outage times.
Recovering our validator node
We first tested out our node recovery process to ensure we could recover our node if an unexpected outage occurred and to provide some peace of mind before attempting to upgrade our node.
Recovery involved setting up regular Amazon Machine Image (AMI) snapshots to back up the image and hard disks of our validator node. We then created a launch template, which allows us to pre-configure launch settings such as the Instance Type, AMI, security and networking.
To test the recovery process, we terminated (shut down and deleted) our validator node EC2 instance. We then launched a new EC2 instance using the AMI snapshot and launch template. During this process we used the Indicio Sovrin Network Health Dashboard to monitor the status of the node. From this process we learned that we were able to successfully recover our node in under 15 minutes.
Now that we were confident that we could recover our node if something went wrong, we attempted to upgrade our node. We decided to upgrade our node by building a new launch template that used the AMI snapshot backup with updated configuration settings.
Upgrading our validator node
Using AWS EC2 services, upgrading the hardware of our node was straightforward and was achieved by simply selecting a new instance type. For us, this meant upgrading from an r4.large to m5.2xlarge AWS instance type, which offers more CPU cores and RAM.
Upgrading our network configuration was more involved. We first created a new subnet (subset of VPC) dedicated for validator-to-validator communications. We then edited our launch template to configure two network interface cards for our validator node, each in a different subnet. This allowed inter-validator traffic to be separate from any other network traffic going in or out of the node.
When we first attempted to launch our upgraded node, we found that the network settings from the previous node instance were carried across to our upgraded node through the AMI backup. This meant that our virtual network interfaces could not be configured and as a result, we lost remote SSH access to the node.
We overcame this issue by adjusting our launch template to use one of the original virtual network cards and then created a second virtual network card which had the desired network settings in the correct subnet. Once we launched the instance, we were able to remotely access the node and reconfigure the network configuration to accommodate for the new network interface card.
Using AWS’s Elastic IP address service, which allocates public IP addresses to your AWS account, we dedicated an IP address each for validator communications and client communications when the node was first launched. Since these IP addresses are registered on the Sovrin network (see our Pool ledger transaction), we reallocated them to the network interfaces on our upgraded validator node to ensure that no external network changes were made.
We’re ready for the future
Upgrading our Sovrin validator node was a great way to review our existing node and refamiliarize ourselves with the intricacies and technologies of hosting a node.
We are now confident that we have a reliable recovery plan in case our Sovrin validator node goes down and we are ready for any new upgrades required by the Sovrin network, especially with the desire to change from Ubuntu 16 to a later version on the horizon.
We are proud to be hosting a conformant Sovrin validator node and look forward to continually supporting the Sovrin Foundation and being a part of the Sovrin network.
