HugoTrentesaux

Run a distance oracle🔗

In Duniter v2, the distance computation is managed outside the runtime core to avoid taking all the block capacity. Running a distance oracle is optional but makes the results more resiliant to attacks. Here we suggest a way to run the distance oracle aside the validator node using docker networks and docker volumes.

# Duniter distance oracle plugging to smith node

version: "3.5"

# distance oracle uses same image but another entrypoint
services:
  distance-oracle:
    image: duniter/duniter-v2s-gdev:latest      # <--- same image as Duniter
    entrypoint: docker-distance-entrypoint      # <--- but an other entrypoint
    environment:
      ORACLE_RPC_URL: "ws://duniter-smith:9944"   # <--- here "duniter-smith" corresponds to your smith service
      ORACLE_RESULT_DIR: "/var/lib/duniter/chains/gdev/distance/" # <--- "gdev" or the name of the chain
      ORACLE_EXECUTION_INTERVAL: "1800"         # <--- every 30 minutes to not miss a session
      ORACLE_LOG_LEVEL: "debug"
    volumes:
      - data-smith:/var/lib/duniter             # <--- uses the docker volume of your smith node
    networks:
      - duniter                                 # <--- uses the docker network of your smith node

# external volume of duniter node to share data for the inherent to read
volumes:
  data-smith:
    name: duniter-gdev-smith_data-smith         # <---- volume name of your smith node
    external: true

# external network of duniter node to read data from rpc API
networks:
  duniter:
    name: duniter-gdev-smith_default            # <---- network name of your smith node
    external: true

It is convenient to run it aside to be able to update it independantly from the smith node. To know the name of the volume and the network, you can do:

# get the name of the volume
docker volume ls
# get the name of the network
docker network ls

They are defined by default by the name of the folder containing the docker-compose.yml.