0.5.x
Read about the major cheqd network upgrades, moving to version 0.5.x
Last updated
Was this helpful?
Read about the major cheqd network upgrades, moving to version 0.5.x
Last updated
Was this helpful?
This list contains all stable releases in the 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:
What has changed?
Our 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
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 instead of the Indy DID method technique as well.
What has changed?
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:
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.
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.
In Hyperledger Indy, the assumption was that DID would have only one and one per DID. The has evolved since then to allow for multiple controllers and more complex .
Learn more about DID’s (Decentralised Identifiers) and why they’re important on .
A DID Document with three Verification Methods listed within the section of the DID Document (“DIDDoc”)
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 .