DC Ledger is a public permissioned Ledger which can be used for two main use cases:
- ZB compliance certification of device models
- Public key infrastructure (PKI)
More information about use cases can be found in DC Ledger Overview and Use Case Diagrams.
DC Ledger is based on Tendermint and Cosmos SDK.
The ledger consists of
- A network of Tendermint-based validator nodes maintaining the ledger. Every validator node runs DC Ledger application code (based on Cosmos SDK) implementing the use cases.
- The client to be used for interactions with the network of nodes (sending write and read requests).
The following clients are supported:
- CLI to communicate with the network of nodes (as a light client). The CLI is based on the Cosmos SDK. See CLI Usage section for details.
- REST API which can be deployed as a server. The server can communicate with the nodes (as a light client). The REST API is based on the Cosmos SDK. See REST Usage section for details.
- Tendermint's Light Client can be used for a direct communication on API level. There are currently no DC Ledger specific API libraries for various platforms and languages, but they may be provided in future. These libraries can be based on the following Light Client implementations:
- Public UI
- http://18.197.220.188.
- based onf the REST API
- can be used to browse the ledger
- please note that it doesn't show all the accounts on the ledger
- it shows only the default (demo) accounts created on the UI server
- for demo purposes only: can be used for sending write requests from the default (demo) accounts
DC Ledger is a public permissioned ledger in the following sense:
- Anyone can read from the ledger (that's why it's public). See How to read from the Ledger.
- Writes to the ledger are permissioned. See How to write to the Ledger for details.
In order to send write transactions to the ledger you need:
- Have a private/public key pair
- Have an Account created on the ledger via
ACCOUNTtransaction (see Use Case Txn Auth).- The Account stores the public part of the key
- The Account has an associated role. The role is used for authorization policies.
- Sign every transaction by the private key.
- PoA (proof of authority) approach is used for adding new validator nodes to the network (see Add New Node Use Case) and Running Node Instructions.
A full list of all CLI commands can be found there: cli-help.md.
Please configure the CLI before using (see how-to.md).
If write requests to the Ledger needs to be sent, please make sure that you have an Account created on the Ledger with an appropriate role (see how-to.md).
Sending read requests to the Ledger doesn't require an Account (Ledger is public for reads).
A REST API server is a CLI run in a REST mode:
dclcli rest-server --chain-id <chain_id>.
Please configure the CLI before using (see how-to.md).
A list of all REST API calls can be found in transactions.md.
Details on how a REST API can be used for write and read requests can be found in How to write to the Ledger and How to read from the Ledger.
If write requests to the Ledger needs to be sent, please make sure that you have an Account created on the Ledger with an appropriate role (see how-to.md).
Sending read requests to the Ledger doesn't require an Account (Ledger is public for reads).
After the CLI or REST API is configured and Account with an appropriate role is created, the following instructions from how-to.md can be used for every role (see Use Case Diagrams):
- Trustee
- propose new accounts
- approve new accounts
- propose revocation of accounts
- approve revocation of accounts
- propose X509 root certificates
- approve X509 root certificates
- propose revocation of X509 root certificates
- approve revocation of X509 root certificates
- publish X509 certificates
- revoke X509 certificates
- CA
- propose X509 root certificates
- publish X509 certificates
- revoke X509 certificates
- Vendor
- publish device model info
- publish X509 certificates
- revoke X509 certificates
- Test House
- publish compliance test results
- publish X509 certificates
- revoke X509 root certificates
- ZB Certification Center
- certify or revoke certification of device models
- publish X509 certificates
- revoke X509 certificates
- Node Admin
- add a new Validator node
- publish X509 certificates
- revoke X509 certificates
- To build and run, follow the Cosmos SDK tutorial. Use dcld, dclcli instead of nsd, nscli.
- To start localnet using docker-compose run
make install && make localnet_init && make localnet_start- 4 nodes will be started and will expose their RPC enpoints on ports
26657,26659,26661,26662
- 4 nodes will be started and will expose their RPC enpoints on ports
- To stop localnet run
make localnet_stop - A detailed instruction of now to start a local net in Docker can be found in Setup of Local Net in Docker.
One can either deploy its own network of validator nodes or join one of the persistent DC Ledger Networks.
- If you want to deploy your own network for debug purposes, you can use the provided Ansible Playbook: ansible/readme.md.
- If you want to join an existing network (either a custom or persistent) as a validator node, please follow the Running a Validator Node instructions.
- If you want to deploy your own persistent network, you will need to create a genesis node and a genesis file first as described in Running a Genesis Validator Node. After this more nodes can be added by following the Running a Validator Node instructions. Please note, that Running a Genesis Validator Node describes the case when the genesis block consist of a single node only. This is done just for simplicity, and nothing prevents you from adding more nodes to the genesis file by adapting the instructions accordingly.
