🔍
Understanding cheqd DID Resolver
DID methods are expected to provide standards-compliant methods of DID and DID Document ("DIDDoc") production.
The cheqd DID Resolver is designed to implement the W3C DID Resolution specification for
did:cheqd
method.Code and deployment packages for the cheqd DID Resolver
Since cheqd uses the Cosmos SDK blockchain framework, the underlying data storage and retrieval mechanisms used rely on those offered by the Cosmos SDK framework.
Cosmos SDK uses Protobuf (Protocol Buffers) encoding for its wire protocol and provides gRPC/gRPC-Web, JSON-RPC, and REST API endpoints for on-ledger modules and functionality.
The cheqd DID Resolver uses these existing gRPC/REST API endpoints to carry out DID URL Resolution and Dereferencing not packaged within the cheqd-node ledger code.
📝 Architecture Decision Record for cheqd DID Resolver
The current implementation of Universal Resolver driver for
did:cheqd
uses the Full cheqd DID Resolver deployment pattern described below.The Universal Resolver project aims to provide a common REST API definition for DID Resolution where each DID method can provide a Docker container that with an easy-to-deploy mechanism for the specific DID method.
The Full cheqd DID Resolver is able to use
github.com/cheqd/cheqd-node
as a Golang module for send resolve
requests to a cheqd node instance to fetch DIDDoc / Resources from the ledger.Since the Full cheqd DID Resolver is wrapped for usage as a Docker container image using the Universal Resolver specification, the end-to-end sequence diagram for our DID Resolver would look like below:

Full cheqd DID Resolver sequence diagram
- 1.Since the cheqd-node ledger / Cosmos SDK is written in Golang, this resolver would consist of Golang libraries imported from the existing ledger code. This promotes code reuse.
- 2.Data would be fetched from the ledger using the gRPC endpoint on a node, which allows it (by default) to take place over an encrypted channel since gRPC uses HTTP/2.
- 3.Data retrieved would be in the native Protobuf representation as stored on ledger, thus allowing data integrity computations to be made.
This deployment pattern for the cheqd DID Resolver has not been built and released yet. It is described here to provide information on potential future areas of making DID Resolution easier than the current industry state-of-the-art.
- 1.Universal Resolver drivers are designed to be run as Docker containers. A limitation of this approach is that the computation footprint of a compute resource can be quite high, e.g., a Docker container may be 100 MB+ in size and suffer from slow startup times in a "cold-start" scenario.
- 2.Thus, our "Light" DID Resolver idea was to explore using Cloudflare Workers, a lightweight serverless compute platform. As a comparison, Cloudflare Workers are limited to 1 MB in size and have extremely low cold-start times. (We use Cloudflare Workers in our Cosmos SDK Custom Data API, for example.)
- 3.Cloudflare Workers can also be deployed outside the Cloudflare service in a Docker container using Miniflare. This could be used to provide a Docker container deployment option for the Universal Resolver
did:cheqd
driver. - 4.However, a limitation of Cloudflare Workers is they do not allow a gRPC request to be made to an external endpoint. This would force the "Light" cheqd Resolver to use the gRPC-Web / REST endpoint
resolve
implementation to fetch data from the ledger. This could be considered a higher risk profile in terms of data integrity by resolver operators / client applications.
Last modified 1mo ago