Architecture

General Designed Architecture

See here for a general architecture/design of Dragonchain, as well as the network of chains (Dragon Net).

Current Implemented Architecture

Dragonchain is implemented using a modular architecture meant to be ran as a series of pods in kubernetes.

Overview

To run a dragonchain, various modular components must be used in conjunction. These involve 3rd party components and various containers built by the project’s Dockerfile.

3rd Party Components

Every chain requires a running instance of the following 3rd party components:

• Persistent redis, accessible via the REDIS_ENDPOINT and REDIS_PORT env vars. This redis maintains persistent data, such as state of various Dragonchain systems. This also serves as a hub for intra-chain pod communication by providing consistent queue messaging.

• Cache (LRU) redis, accessible via the LRU_REDIS_ENDPOINT and REDIS_PORT env vars. This redis should be configured as an LRU cache and is intended to be used as a write-thru cache for storage and other ephemeral data.

• Redisearch, accessible via the REDISEARCH_ENDPOINT and REDIS_PORT env vars. This should be set up to persist, as it is used for indexing.

Additionally, L1 (business logic) chains also require a running instance of the following:

• OpenFaaS deployment accessible via the FAAS_GATEWAY env var. This is used for running smart contracts as Docker containers. (Must be accessible to chains, but NOT the greater internet)

• Docker Registry accessible via the FAAS_REGISTRY env var, used for storing built smart contracts for OpenFaaS.

Note that many L1 chains can share the same Docker Registry and OpenFaaS deployment.

1st Party Components

The 1st party component of a dragonchain consist of the docker container generated by the project’s Dockerfile utilizing different entrypoints as the container’s CMD.

Every chain requires a running instance of the following 1st party components:

• Webserver (via the webserver.sh entrypoint). This is the main gateway for communication into the chain.

• Transaction Processor (via the transaction_processor.sh entrypoint). This is the component that processes transactions into blocks.

Additionally, L1 (business logic) chains also require a running instance of the following:

• Broadcast Processor (via the broadcast_processor.sh entrypoint). This is responsible for talking with Dragon Net to send blocks for verifications.

• Contract Invoker (via the contract_invoker.sh entrypoint). This is responsible for talking with OpenFaaS to invoke contracts as they are queued and process their results.

• Scheduler (via the scheduler.sh entrypoint). This is responsible for scheduling actions on a chain, such as queuing smart contract invocations every X seconds or per a cron-expression.

• Job-Processor (via the job_processor.sh entrypoint). This is responsible for creating arbitrary kubernetes jobs for a chain. Currently, this is used to trigger smart contract builds, which require elevated permissions to the docker daemon. This container is to restrict the permissions given to the webserver.

• Contract-Builder (via the contract_job.sh entrypoint). This is the job created by the job-processor and is responsible for taking a customer smart contract, modifying it to be compatible with OpenFaaS, and deploying it.

Diagram