Anonyome Labs already maintains validator nodes in support of the Sovrin and Indicio networks. Recently we increased our contribution to decentralized identity and verifiable credentials by becoming a founding member of the cheqd production network. With more companies leveraging SSI and governments beginning to implement them, large-scale public adoption of these technologies appears to be around the corner.
Anonyome Labs is particularly interested in new economic models for SSI technologies and infrastructures that can amplify adoption by end-users, businesses, and governments. Economic incentives provide a way for validators to be rewarded for running the network and for issuers of verifiable credentials to be rewarded for issuing credentials. The adoption of these new economic models in turn increases the amount of SSI credentials in circulation, making it increasingly easier, more efficient, and more secure for organizations to get trusted data from the consenting identity subject. These financial incentives are a clear driver for transition from centralized and federated identity systems to an SSI ecosystem.
What are verifiable credentials?
In short, they are tamper-proof credentials that can be verified cryptographically. Their use cases include checking the validity of travel visas, healthcare certificates, airline tickets, credit score checks and credentials for opening a bank account. Three parties take place in the verifiable credential workflow: the issuer digitally signs a document and sends it to the holder which can then present their credential (to W3C specifications) to a verifier. A verifier checks presented credentials and verifies the contained authority, validity, and tamper-proof characteristics of the credential. If validity conditions are met and the presented credential contains the required claims, the holder is granted access to an associated resource or service.
Why do we need tokens for SSI?
Currently the main method of paying for verifiable credentials is through conventional payment networks. This has several drawbacks as mentioned in Sovrin’s whitepaper, where:
- markets are restricted to only the highest value credentials
- current issuers are at risk of data breaches
- credentials are not privacy respecting.
Since third-party identification issuers (such as credit bureaus) charge a fee to verify a user’s identity, it can be assumed that paying for credentials will remain a fundamental element of SSI. Tokens act as a solution to this problem, with Sovrin having already designed and tested tokens for their network (but not put them into production).
What is cheqd?
cheqd’s network is built on the Cosmos blockchain with a dedicated token for payment which enables new business models for verifiers, holders and issuers. In these business models, verifiable credentials are exchanged in a trusted, reusable, safer, and cheaper way — alongside a customizable fee.
How cheqd uses tokenomics
cheqd employs concepts of tokenomics on top of governance which sets it apart from the Sovrin network. With any of the three participants – holders, validators, and issuers – capable of receiving tokens as an incentive, it promotes participation and accountability, which will facilitate a greater adoption of the technology and SSI as a whole. This allows users to reclaim their privacy, and organizations to build their reputation and reduce the potential for fraudulent credentials. The value of $CHEQ depends on several factors including overall cryptocurrency market health, cheqd protocol resilience and the real-world implementation of use cases by SSI vendors.
cheqd’s choice of SDK
In 2017 Sovrin open sourced their codebase to Hyperledger Indy which Indicio builds upon to provide its services and network. Hyperledger Indy is a collection of tools, libraries and further components for digital identities rooted on blockchains. It’s important to note that tokens are not natively supported; in fact Brian Behlendorf, Executive Director of the Hyperledger Project, mentioned in an interview that “you’ll never see a Hyperledger coin” and “by not pushing a currency, we avoid so many political challenges of having to maintain a globally consistent currency.”
cheqd’s network is built on the Cosmos SDK which has several benefits. They include Cosmos’s identity capabilities, easily customizable token behavior, on-ledger voting for governance frameworks and smart contract functionality. cheqd’s application-specific blockchain implementation addresses the shortcomings of smart contracts by building a full-node client, a light-client, and all the necessary interfaces (CLI, REST, etc.) to interact with the nodes. These reasons make Cosmos a viable solution as an SDK since the added benefits that tokenomics bring allows cheqd to develop a network for SSI applications.
cheqd DID method
Decentralized identifiers (DIDs) are cryptographically proven, verifiable and decentralized digital identities. DIDs are designed to be decoupled from centralized registries, identity providers and certificate authorities. A DID can refer to any subject, entity, organization, thing, data model or abstract entity as specified by the DID controller. Where DIDs come into play is their ability to be stored on the blockchain as a public verifiable data registry. These immutable records can be queried for the authenticity/validity of a verifiable credential to see who issued without consulting the issuer.
cheqd has proposed that it will build on Hyperledger Indy DID method, renaming NYM transactions to DID transactions and removing roles to move from a public-permissioned network to public-permissionless.
The Anonyome validator configuration
Because of the potential advantages of having a token as part of the decentralized identity network, Anonyome Labs has configured and brought online its own validator. We use Amazon Web Services to deploy our validator, however the cheqd-noded software can be run by other hosting providers or even locally.
To successfully become part of the cheqd production network and have an operational validator, we:
- set up an AWS elastic cloud (EC2) instance running Ubuntu 20.04
- configured a virtual private cloud (VPC) using security groups at the network interface level to act as a firewall
- enabled automatic backups via AMI policies
- created custom SNS topic to Slack notifications for outlier detection within CloudWatch Metrics.
AWS elastic cloud (EC2)
To run the cheqd validator installation we currently use a t3.small EC2 with the Ubuntu server 20.04 LTS (HVM) image. The storage is split across two EBS volumes: a 10GB EBS volume for the operating system and cheqd software and another 150GB EBS for the cheqd home directory containing the increasingly large data directory which stores the ledger.
Both disks are encrypted, and the 150 GB volume is mounted within the operating system and set as the home directory for the cheqd user account.
Virtual private cloud (VPC)
The VPC security groups are configured to whitelist inbound and outbound traffic, only allowing specific access to SSH, RPC and HTTP/HTTPS ports from pre-determined IP addresses. Deliberately specifying which traffic the validator allows/expects reduces the potential for vulnerabilities that can be exploited. An elastic-IP connects to the EC2 instance which grants the validator a static IP.
AMI backup policies
To ensure swift recovery from any outages, attacks or node misconfigurations, an EBS-backed AMI policy has been put in place to make daily and monthly backups. These backups create live snapshots of the system such that when the validator must be restored, it resumes from the snapshot’s instance state. This aims to minimize downtime on the network and the slashing penalties that incur. When restoring from an AMI, the validator only needs to catch up from its latest block height and match that of the networks rather than a new validator which would have to catch up from the beginning, potentially saving days of downtime.
SNS topic to Slack notifications
Enabling telemetry via Slack notifications allows for real-time error handling and informative reporting on the status and health of our validator. This minimizes the risk to the confidentiality, integrity, and availability of the node through notifying problem-specific alerts which can be acted on immediately.
Some of the triggers our system looks out for are:
- abnormally high resource usage (CPU, RAM, NetIO)
- unusual cheqd network statistics (no validators on the network)
- security alerts (unauthorized access)
- general instance status metrics.
Future plans
With new technologies come new challenges and by nature many learnings and improvements are discovered. While we have our node actively validating, there are several improvements that we are making to our system architecture to tighten security and reduce the risk of downtime.
Upgrading the network to a multi-node sentry-validator architecture allows for stronger protection from DOS attacks and other threats which can be mitigated by honeypots. Although more complex than a single validator instance, the benefit of reduced downtime in the case of an attack ensures a lower risk of slashing.
In order to reduce the risk of lost or stolen tokens earned through validating, we aim to use a cold-wallet backup solution. The implementation will include further steps to tighten security, such as multi-factor authentication, hardware cold-wallets and internal auditing, which in turn minimizes the attack vector.
Other future considerations may include securing validator keys using a HSM or other implementations which secure the Ed25519 keys used by Tendermint Core. These improvements and alterations to the validator are first performed on our Testnet node before they are applied to the Mainnet. Since Testnet tokens have no actual value, they can be used to develop, test, and deploy security changes without having the risks associated with making changes on the Mainnet validator.
To stay up to date with our developments and involvement with the cheqd network, join our mailing list on our main blog page.
Image Source: www.cheqd.io
