This list contains all stable releases in the cheqd-node v0.5.x family, and skips pre-release versions.
This new node version is intended to enhance functionality currently available on v0.4.x. The upgrade to v0.5.x will be a breaking change that introduces new routes, fixes a few technical debt issues identified and overall offers significant enhancements to the identity functionality and security of the network.
Full changelog: cheqd-node v0.5.0 release notes
What has changed?
Our did:cheqd Decentralized Identifier (DID) method provides a unique identification number for a DID Subject. This can be thought of in a very similar way to traditional bank cards. (Note: While the example of a bank card is used here, DIDs on ledger are typically written for companies, not individuals.)
Within a bank card, different sections of the card identify different actors, such as the Network, Issuer ID and a Unique Account Number - and when put together, you have a complete card number. DIDs are similar, in the sense that different components of the DID mean different things:
In this update, cheqd has updated the way that DIDs are created and resolved to ensure that the Unique Identifier is a Base58 encoded string (either 16 or 32 characters long). This was done to keep it consistent with the Hyperledger Indy DID method identifier specification.
Why it is important?
Prior to the upgrade, the ledger code itself was relatively “dumb”: the responsibility of ensuring that a valid unique identifier was created, matching our DID specification, would be done client-side. While the cheqd ledger did implement a uniqueness check to ensure that no other DIDs with the same identifier existed within a namespace, it didn’t implement checks to ensure that the identifier specification was met. (This is broadly how a lot of Hyperledger Indy SDKs currently do this.)
We believe that that there will be a blend of various levels of technical complexity in client-side SDKs that interact with DIDs, so relying on only client SDKs to implement this is an unsafe method. By adding checks on the ledger itself, it allows us to ensure consistency across a wide range of client SDKs.
We are additionally exploring future iterations which would allow unique identifiers to be defined as UUIDs instead of the Indy DID method technique as well.
What has changed?
In Hyperledger Indy, the assumption was that DID would have only one Verification Method and one Controller per DID. The DID Core specification has evolved since then to allow for multiple controllers and more complex Verification Relationships.
Learn more about DID’s (Decentralised Identifiers) and why they’re important on learn.cheqd.io.
The cheqd DID method allows multiple controllers, verification methods, and complex relationships to be defined which brings it in-line with the DID Core specification. But this also introduces new challenges. To illustrate through an example, let’s say there is:
A DID Document with three Verification Methods listed within the Verification Methods section of the DID Document (“DIDDoc”)
Next, there is a request to add a new Verification Method to the DID Document.
The question is: how should this DID Document be updated; who needs to sign to make this change?
Why it is important?
Prior to the upgrade, when a DID update request was made, the ledger would only ask for the existing Verification Method(s) listed in the DID Document to sign to approve the change. We have changed this to ensure that both the existing and new Verification Method keys need to sign the update request.
This is important because it will prove that the controller(s) of any new Verification Method(s) have control of the relevant key(s) that the DID update is trying to achieve. This is much more secure because it achieves a level of trust that all of the Verification Method(s) listed in the DID Document can be appropriately signed for by their Controller(s). It also, importantly, follows the DID Core Specification.
What has changed?
When a DID is resolved, it fetches resolution metadata in addition to the DID Document. This metadata contains entries such as when a DID was created as well as when it was most recently updated.
Prior to the upgrade, the Update metadata field would contain the same data as the Created field if the DID had never been updated. We’ve changed this to a null value instead of the same date/time, to make it easier for software to understand this scenario.
Why it is important?
If you see the Update field reads null, it means the DIDDoc has never been updated. This clears up any potential confusion and aligns the DID resolution metadata.
What has changed?
We have changed the way we validate Verification Method keys, splitting this into:
Static validation;
Dynamic validation.
The former, static validation checks, are performed before the inclusion of a transaction in the mempool; and the latter, dynamic validation checks, are performed during the transaction execution once it is included in the blockchain.
Why it is important?
Splitting these is important because now errors in Verification Method keys can be caught earlier and flagged, before any transaction enters the mempool.
Note: The mempool serves the purpose of keeping track of transactions seen by all full-nodes. Full-nodes keep a mempool cache of the last ‘mempool.cache_size’ transactions they have seen, as a first line of defence to prevent replay attacks.
Therefore, the validation improvements will allow nodes to reject invalid transactions in the early stages without including them in the chain and charging the user.
This in turn speeds up the cheqd network as incorrect transactions are not being committed and incorrect Verification Method keys are not errored out when committing a transaction to the mempool.
We’re also using other work to build similar efficiency improvements:
This validator package for null checks, generic DID validity checks in static validation
This validator package for DID namespace checks in dynamic validation.
What has changed?
Within the DID Core specification there are two types of key in a Verification Method:
JSON Web Key (JWK); and
Public Key Multibase.
Previously, the only format of key supported was publicKeyMultibase
Having only one of these two options limits the scalability and interoperability of the cheqd network, as the supported Verification Method keys are limited.
Therefore, we implemented JSON Web Key (JWK) support.
Why it is important?
With JWK, cheqd now supports a broader selection of Public Key encoding schemes, which is an important improvement, given our focus on interoperability and eventual cross-ledger support.
What has changed?
Previously, we were using a Cosmos format of datetime, rather than what is defined in the DID core spec. Now this has been changed to align with DID Core.
Why it is important?
This aligns our DID Document metadata with DID Core, making it more semantically interoperable and spec compliant.
tx_hash in the correct formatWhat has changed?
As cheqd is a chain built on the Cosmos SDK, it relies on Tendermint as its consensus mechanism.
This means that when something is written to the network, there is a Tendermint transaction hash that is created. This is specific to Cosmos chains.
Within DID Document metadata, there is a field called VersionID which, as the name suggests, denotes the specific version of the DID Document.
Previously, in this field, we were generating a hash from the transaction itself to calculate the DIDDoc version ID. We have now changed this to populate a Tendermint transaction hash.
Why it is important?
This is important because the DIDDoc versionId can now be retrieved right after the creation of the DID, with the DID now more easily searchable on a Block Explorer. Previously, we needed to create the DID, then ask it to create version ID, then update.
This update streamlines the process and makes it more efficient.
This list contains all stable releases in the cheqd-node v0.4.x family, and skips pre-release versions.
Our packaged releases are currently compiled and tested for Ubuntu 20.04 LTS, which is the recommended operating system for installation using Debian package or binaries.
For other operating systems, we needed to provide an alternative approach. Therefore, this point release was initiated which offers a pre-built Docker image releases for cheqd-node.
Docker Compose Easy Setup (#250)
Add euox pipefail check for bash scripts (#266)
Test for positive case of upgrade process (#268)
Refactor Debian package installer to handle upgrade scenarios better (#279) (Andrew Nikitin)
Unified network configuration generation (#267)
Further docker, tests improvements (#280)
Updated recommended docker image version
Revert fastsync version to v0 (#256)
Fix small errors around postpurge script
Full changelog: cheqd-node v0.4.1 release notes on GitHub
This software upgrade proposal upgraded the version of cheqd-node software on our mainnet from v0.3.1, to v0.4.x.
Following the successful release of our mainnet in November 2021, we wanted to fast-follow with a some immediate improvements we felt necessary for the cheqd network.
This new node version is intended to enhance functionality currently available on v0.3.1. The upgrade to v0.4.x will be a breaking change that introduces new routes, plus fixes a few technical debt issues identified in the v0.3.x branch.
Bumped Cosmos SDK version from v0.44.3 to v0.44.5
Update DID operations in version v0.3.1 did not carry out a check on the keys used to authenticate the transaction.
In essence, this meant that any update DID operation could incorrectly update a DID or its associated DIDDoc. This has now been fixed.
Switched build system from using Starport to using Makefiles.
This gives greater control for future improvements and optimisation in adding support for other operating systems, database backends etc.
The node software binary has now been compiled with support for Ledger hardware wallet devices for key storage.
REST/gRPC endpoints for querying DIDs have been added. Documentation will be added to explain how these endpoints work.
Full changelog: cheqd-node v0.4.0 release notes on GitHub.
See below for all of our cheqd-node ledger software releases in 2022:
This list contains all stable releases in the cheqd-node v0.6.x family, and skips pre-release versions.
Read Full changelog on GitHub: cheqd-node v0.6.10 release notes
The following steps have been prepared by the cheqd development team for cheqd validators to follow in order to manually upgrade their node.
This is in response to a high-risk security vulnerability (dubbed "Dragonberry") related to IBC protocol / ICS23.
This is closely related to the "Dragonfruit" security vulnerability published on Cosmos forums. v0.6.9 fixes this vulnerability by patching to Cosmos SDK v0.45.9 upstream.
This patch is non-state-breaking. This means that validators can switch to the new binary, and restart their node without necessarily needing an on-chain software upgrade (which is intended for consensus-breaking changes).
The patch has already been applied to cheqd's own validator node and one of the other large validators (at the time of writing this).
Read Full changelog on GitHub: cheqd-node 0.6.9 release notes
Read Full changelog on GitHub: cheqd-node v0.6.7 release notes
Read Full changelog on GitHub: cheqd-node v0.6.1 release notes
Here’s what’s new in the latest cheqd node version - v0.6.0. This release is a state-breaking update that brings fundamental changes to the cheqd-node testnet and mainnet. The release notes below pertain to the cheqd-node changes only.
This upgrade includes 3 primary enhancements and new features, each of which helping accelerate cheqd to support a greater number of credential formats & SDKs, more use cases for decentralised identity applications and streamline the end-to-end developer experience.
Implementation of a Resources module, used to support DID-Linked Resources
Introduction of an Interactive Installer to streamline the developer onboarding experience
Introduction of Cosmovisor for automated upgrades.
What's changed?
The concept of resources in self-sovereign identity (SSI) ecosystems is not new, however, as we will discuss throughout this blog post, existing approaches to resources in SSI oblige adopters to make compromises between security, availability and interoperability. We first noticed this when we were looking at how we could securely reference credential schemas, something we will expand on throughout this post.
Our objective in building resources on cheqd is to improve the way resources are stored, referenced and retrieved for our partners and the broader SSI community, in line with the existing W3C DID Core standard.
An initial use case for DID-Linked Resources is supporting AnonCreds on cheqd. This is an industry first as AnonCreds have to date been tightly bedded to the Indy ledger. We are using the Resources module to create DID-Linked Resources for schemas and CredDef, bringing AnonCreds support to the cheqd ledger in a W3C compliant format.
Please take a look at our blog which provides a thorough explanation for your reasoning on this approach, and links to our documentation.
What's changed?
Prior to this upgrade, we offered developers looking to setup using a Ubuntu .deb package file and installing a with Docker
Although these were fit for purpose, allowing the vast majority of validators on the cheqd network to get set up these methods do require a higher level of technical skillset, and are more time-consuming.
The Interactive Installer offers a more intuitive and simple developer experience, which guides developers through a step-by-step journey, asking questions with the CLI along the way.
Find out more about how to get started using the Interactive Installer here.
What's changed?
With an increasing number of validators on the cheqd network, we wanted to provide developers managing nodes the opportunity to more easily upgrade their node.
Cosmovisor is a small process manager for Cosmos SDK application binaries that monitors the governance module for incoming chain upgrade proposals. If it sees a proposal that gets approved, cosmovisor can automatically download the new binary, stop the current binary, switch from the old binary to the new one, and finally restart the node with the new binary.
Read on GitHub: cheqd-node v0.6.0 release notes
DEV-1319 Add helper to convert ed25519 public keys to JWK by @askolesov in #321
feat!: Interactive installer for cheqd-node with Cosmovisor support DEV-1321 by @anikitinDSR in #329
feat(ibc): Bump IBC to v3 and update associated upgrade tests DEV-807 by @askolesov in #334
DEV-1044 Fix gas estimation for cheqd transactions by @askolesov in #302
Proposal CLI Registration by @keupsonite in #323
chore: Bump Cosmos SDK to v0.45.4 by @askolesov in #328
fix: Small fixes for installer after testing by @anikitinDSR in #343
Dispatch workflow by @ankurdotb in #308
DEV-1096 Improve release processes by @anikitinDSR in #304
build(tooling): Fixing workflows to main branch version by @ankurdotb in #313
Fix workflow calls to refer local versions instead of master by @askolesov in #322
Add gofumpt check to the lint workflow by @askolesov in #324
Add a workflow to lint Semantic PRs by @askolesov in #326
fix: Get linter back by @anikitinDSR in #338
fix: Get rid of Debian package for release by @anikitinDSR in #341
test: Add Cosmovisor support for tests DEV-1278 by @anikitinDSR in #320
DEV-1171 Add additional instruction for updating from 0.4.x version by @anikitinDSR in #301
docs: Remove all documentation from cheqd-node to node-docs repo DEV-1320 by @ankurdotb in #333