This repository hosts the shared code used by many of the other repositories in the CCD Explorer Universe. The only way I knew how to make this work (locally and in Docker containers), is by publishing this repo as a Python package.

Most important modules in the repo are:

• GRPCClient: this is the partial Python SDK that contains all relevant GRPC types and methods to request information from the GRPC endpoint from a node.
• MongoDB: this module contains the connection to the MongoDB instance (or replicaset). See the Mongo Type Docs for more information.
• Tooter: this module is a light wrapper around Apprise, used to send notifications.
• CIS: this module contains logic to decode CIS-2 events according to the CIS-2 Specifications. This module is used in token accounting. See the CIS Type Docs for more information.

This module is implemented as a partial Python SDK for the GRPC endpoint for a node. As such, it needs to be updated regularly whenever new types and methods are added to the GRPC Protocol Documentation. It relies heavily on BetterProto, however only version 2.0.0b6 seems to work. Hence, run

pip install "betterproto[compiler]"==2.0.0b6

to install this version.

BetterProto takes the .proto files from the Concordium GRPC Api Repo and converts this into the neccesary classes. When an update is performed on the Concordium GRPC Api Repo, copy the new files to the same location and run the following command:

python -m grpc_tools.protoc -I. --python_out=. --pyi_out=. --grpc_python_out=. --python_betterproto_out=. service.proto

This will generate the new _pb2.py(i) files.

When I started with this project, I didn't know the first thing about Protobuf. To be honest, I still don't, but I have found a way to manage this by creating my own classes, mirroring the classes as generated by the types.proto file . These classes are stored in a submodule called CCD_Types. This contains 165 classes and 55 type aliases. See the GRPC Type Docs for more information.

The services in the service.proto file are mirrored in the queries submodule, where all relevant GRPC calls are built. These are the methods that other services call to retrieve specific information from the node.

For every call to the node, it calls grpc.channel_ready_future to check if the service is ready (the node is able to respond to queries). Is this somehow fails, the module tries to connect to a different node (as supplied in the ENV variables).

Almost none of the modules in this repo as useful as a standalone package, with the exception of the GRPC SDK.

NOTIFIER_API_TOKEN (API token for notifier bot)
API_TOKEN (API token for actual bot)
FASTMAIL_TOKEN (I use Fastmail to send email, leave blank, won't send email)
MONGO_URI (MongoDB URI)
ADMIN_CHAT_ID (Telegram admin chat ID)
MAILTO_LINK (I use Fastmail to send email, leave blank, won't send email)
MAILTO_USER (I use Fastmail to send email, leave blank, won't send email)
GRPC_MAINNET (A list of dicts with GPRC hosts) (Example: [{"host": "localhost", "port": 20000}, {"host": "my.validator.com", "port": 20000}])
GRPC_TESTNET (Same as GPRC_MAINNET)

The CIS module and GRPC module have associated tests.

• explorer.ccd - Everything

This project is licensed under the Apache 2.0 License - see the LICENSE.md file for details.