This list contains all stable releases in the cheqd-node v1.x.x family, and skips pre-release versions.
This version primarily fixes the interactive installer, an off-ledger helper software for carrying out cheqd-node installations and upgrades. The installer now:
Attempts to create a backup of the user's configuration folder and private validator state files, when carrying out upgrades or downloading snapshots.
Frees up spaces by deleting the data folder when requesting a snapshot restore (only if the backup has been made).
Bumps Cosmovisor if necessary.
Set environment variables for cheqd-node as well as for Cosmovisor.
Separates out warning, error, info etc level messages based on success status of the action.
To enable debug level logs in case the installer fails, set an environment variable called PYTHONDEVMODE
to the value 1
on your system. This will provide additional diagnostic logging that can help pinpoint errors if the installer fails.
Read Full changelog on GitHub: cheqd-node v1.4.0 release notes
This version creates a standalone Golang package called github.com/cheqd/cheqd-node/api
which is generated using the Pulsar generation file. This allows non-ledger applications such as the did:cheqd
Resolver to consume a standalone package with just the API interaction elements, without needing to import the entire cheqd-node
Golang package.
This version also bumps Cosmos SDK to v0.46.10.
Read Full changelog on GitHub: cheqd-node v1.3.0 release notes
The previous version of our node software had to be run in pruning="nothing"
setting due to an upstream issue with the Cosmos SDK iavl
package. This release fixes and restores support for setting pruning settings.
Read Full changelog on GitHub: cheqd-node v1.2.5 release notes
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. Changes to identity applications and tooling is summarised in a separate change log.
The release can be broken down into 6 primary areas of development:
Identity transaction pricing and burn
Enhancements to DIDs and DID-Linked Resource functionality
Changes to protobuf definitions required for enhancements to DID and DID-Linked Resource functionality
CosmosSDK version bumps
Miscellaneous fixes
Introduction of Behavioural Driven Development
In this release we’ve introduced new mechanisms to the cheqd’s tokenomics. Currently (prior to this release), writing a DID to cheqd mainnet only cost the gas fee, which was approximately 0.004 $CHEQ. This is extremely cheap when compared to networks such as Sovrin, where writing a DID costs $10, especially taking into account the value we are bringing as a network, protocol and team. Alongside this, $CHEQ is currently inflationary (where staking rewards come from), with only slashing, tombstoning or no-with-veto slashing providing any deflationary pressure.
Going forward, any changes required to periodically maintain these, especially before we implement pricing oracles to programmatically maintain stable dollar pricing for our partners, will require further votes.
Architectural decisions, diagrams and in-depth explanations of the scope and relationships will be shared shortly in a follow-up blog-post and document.
Identity transactions such as DIDs and DID-Linked Resources (e.g. visual representations of Verifiable Credentials; trust & revocation registries; schemas; documents; logos) writes will have a cost greater than gas which will increase rewards from the network as identity utility increases. At current price levels ($0.03-$0.04), writing a DID will equate to 66.6–50 $CHEQ, which leads us to where these tokens will be distributed upon writes. See detailed pricing and comparison to Sovrin here.
As mentioned above, the network is currently inflationary only aside from slashing, tombstoning and no-with-veto having deflationary effects. Implementing a burn mechanism will bring the system into equilibrium. The volume of tokens burnt will increase in the same way as distributions will, with the aim of bringing total supply back to one billion.
As can be seen in the image available here showing the genesis parameters which define the costs in $CHEQ, there is also a “burn_factor” variable which sets the percentage of the tokens charged for identity transactions which will be directly burnt. This can be adjusted through on-ledger governance votes according to the cheqd community preferences.
A number of core changes have been implemented to enable continued interoperability with products and applications across the decentralised identity ecosystem. These include:
Previously it was not possible to mark DIDs as deactivated on the cheqd network. This is now possible. This enables cheqd to support each of the required transactions for integrating with the Universal Registrar.
Fetching historical versions of DIDDocs easily and without friction is an incredibly important feature for DIDDoc indexing in decentralised identity applications.
We have used the same versioning techniques for DIDDocs as was implemented for DID-Linked Resource versioning. This required an on-ledger change as previously we were using the ‘transaction hash’ of the on-ledger block as the DIDDoc ‘version’, which presents a problem as in the event a user has multiple DID operations in the same transaction, it becomes impossible to distinguish between the various versions of the DIDDocs. This has now been replaced with a UUID.
A number of other networks lack this feature and don’t provide the functionality to fetch historical DIDDocs, which can be a limiting factor for those building decentralised identity applications.
UUIDs are not case sensitive. This means that UUIDs with both upper and lower case characters are semantically identical
Previously when users created a UUID for a DID-Linked Resource they could use both lower and upper case in the UUID. The cheqd network, however, is only able to handle lower case characters. As such, we introduced a converter that would convert all UUID DIDs to lower case UUIDs.
As a result of this change, existing DIDs and Resources that were created prior to this upgrade, will be altered to lowercase if they previously contained uppercase characters.
The style for the unique identifier of a DID was initially based on the legacy Hyperledger Indy algorithm. We’ve brought it in line with the updated DID Indy specification requirements instead.
As part of our interoperability efforts and support for AnonCreds with AFJ (documented here we needed to expand the supported identifiers on-ledger. The main barrier preventing full support for AnonCreds on cheqd using Aries SDKs is that AnonCreds is still dependent on the Indy SDK. When you call any function in the Indy SDK, you need to use the legacy Indy-style identifier format to carry out a transaction. Supporting Indy-style identifiers is therefore a stepping-stone in the wider AFJ support for cheqd.
By default DID-Linked resources have a DID URL auto generated. For example, a DID URL for a DID-Linked Resource looks like this:
did:cheqd:testnet:z6jKUJA5YcZsNxZgsrQPKPipL2FRTf4s/resources/8140ec3a-d8bb-4f59-9784-a1cbf91a4a35
When resolved (see here) you’ll find that this shows the IIW logo, used in our wallet demo.
However, as part of our mission to drive the wider adoption of DID-Linked Resources beyond cheqd, and create the “web of trust”, we have enabled the ability to add an alternative URI for where that same resource can be found.
This is similar to the ‘alsoKnownAs’ property in the DID Core specification.
A checksum is a value that represents the number of bits in a transmission message, used to detect high-level errors within data transmissions. They provide a party on the receiving end information about the date to make sure that the full range of data is fully delivered. The checksum value itself is typically a long string of letters and numbers that act as a sort of fingerprint for a file or set of files to indicate the number of bits included in the transmission.
For example, if a user created a DID-Linked Resource, and 1 month later wanted to retrieve this, it would be possible to calculate the sha256 locally and then compare it with the “checksum” field from the resource in order to check whether this resource was changed or not.
Prior to this release, it was calculated in a less usable way, using “sum256 + data_bytes” where it only needed sum256 (which is what is used from v1.0.0 going forward).
To accommodate for the ledger enhancements, fundamental changes are required to the underlying code base which the ledger uses known as protobuf definitions.
Protobuf definitions can be seen as a template for variables in the ledger code-base; the existing release up to this point uses protobuf definitions v1, whilst this upgrade replaces these with v2 protobuf definitions. For example identity transaction pricing and the ability to provide an alternative URI for a DID did not exist in the previous version, meaning this feature would not be possible to implement.
To inspect the source of protobuf definitions, follow the links below. These are simply contained within the overall v1.0.0 upgrade so don’t require any additional steps for developers.
Previous protobuf definitions:
cheqdid.cheqdnode.cheqd.v1
cheqdid.cheqdnode.resource.v1
Updated:
cheqd.did.v2
cheqd.resource.v2
Another aspect of this change is based on best practices. When we launched the cheqd network we identified certain best-practices and designed an implementation approach which would allow us to roll out these conventions in a phased approach. This enabled us to move quickly, whilst not compromising anything on ledger in the initial stages. With this release the cheqd ledger is in line with overall style guides making it more flexible and robust for both our team and other developers to build on.
As is customary with the use of the underlying CosmosSDK and associated libraries, regular version bumps are required to keep the cheqd ledger in line with the wider ecosystem's changes, for example updates to IBC. In this release we’ve bumped the Cosmos SDK version to 46.6, crucially bringing key security patches as well as a bump to IBC to ibc-go v5.1.
cheqd-noded configure
command removedAs part of the overall ledger changes, the cheqd-noded configure
command has become an outdated and deprecated command. The command has been removed and documentation has been updated accordingly. This changes the manual installation of cheqd-node, and the Interactive Installer which previously relied on this.
The Interactive installer was using the legacy configure cmd ‘cheqd-noded’ to do the configuration for app.toml and config.toml files. As this is no longer used, the interactive installer no longer requires the configure command.
The following changes are now made by default when installing a node:
RPC port by default listens to world i.e from tcp://127.0.0.1:
to tcp://0.0.0.0:
The default minimum gas price is set to 50ncheq
, increased from 25ncheq
An option introduced for a user to enter persistent peers, log level and log format when doing interactive installation
A bug was identified where the Ledger nano hardware wallet was not working with cheqd transactions. This has been resolved in this release.
To date our testing approach has been focused around unit testing and more manual approaches to application testing. In this release we’ve introduced Behaviour Driven Development (BDD) at scale across the entirety of the cheqd node. BDD, is a framework which uses human-readable descriptions of product requirements as the basis for testing. Developers implement a well known vocabulary that can be understood by a regular user, to help identify the issues that arise.
We see this as an integral to building strong foundations that will enable developers to more easily build with cheqd, and streamline the overall development process for our core team as we progress further with ledger development centred on the implementation of cheqd payment rails.
feat(installer): Get installer to handle multi-platform binaries DEV-1667 by @ankurdotb in #376
feat: DeactivateDid transaction to mark DIDs as deactivated DEV-1774 by @khornonzon in #332
feat(proto): Proto API v2 DEV-1786 by @askolesov in #398
feat(proto): Refactor app to support proto v2 by @askolesov in #436
feat: DidDoc versioning DEV-1892 by @askolesov in #443
fix(installer): Fixed binary permissions DEV-1826 by @Eengineer1 in #414
fix: Add resourceType for versioning functionality DEV-1703 by @anikitinDSR in #397
fix: Checksum calculation DEV-1649 by @anikitinDSR in #396
test: Fix installer by @anikitinDSR in #348
fix(release): Bump semantic release package by @ankurdotb in #377
fix(installer): Fixed binary permissions DEV-1826 by @Eengineer1 in #414
fix: Error handling by @askolesov in #425
fix: Use proto marshaller instead of amino to derive sign bytes DEV-1694 by @askolesov in #430
fix: Add support for Ledger nano by @ankurdotb in #442
build(buf): Change buf.build package name by @ankurdotb in #453
build(docker): Move to Alpine images for Dockerfile by @anikitinDSR in #356
build: Backport workflow and other fixes to release/0.6.x branch DEV-1822 by @ankurdotb in #410
build: Release with v-tags by @ankurdotb in #424
security(tendermint): Bump github.com/tendermint/tendermint from 0.34.19 to 0.34.20 by @dependabot in #367
test: Move unit testing to Gingko DEV-1652 by @anikitinDSR in #373
test: Integration tests merging state by @Eengineer1 in #419
test: Add interactive installer to workflow and get rid of deb by @anikitinDSR in #347.
See below for all of our releases in 2023:
family