# Architecture

## General Designed Architecture

See [here](https://dragonchain.com/assets/Dragonchain-Architecture.pdf) 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](https://redis.io/), 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](https://redis.io/), accessible via the
  `LRU_REDIS_ENDPOINT` and `REDIS_PORT` env vars. This redis should be
  [configured as an LRU cache](https://redis.io/topics/lru-cache) and is
  intended to be used as a write-thru cache for storage and other ephemeral
  data.
- [Redisearch](https://oss.redislabs.com/redisearch/index.html), 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](https://www.openfaas.com/) 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](https://docs.docker.com/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

![Dragonchain Kubernetes Architecture Diagram](/static/DragonchainArchitecture.svg)