# Council daemon v2 migration guide [Goerli] This guide describes how to migrate from Council deamon v1 to Council deamon v2. This guide is for the **Goerli** test network. ## Table of contents - [Changlelog](#Changelog) - [Overview](#Overview) - [Step by step guide](#Step-by-step-guide) ## Changelog #### Staking Router support Council daemon currently fetches keys from Node Operator Registry contract. In future validators set can be expanded with Community and DVT validators sets. In new protocol version Staking Router contract manages these different sets of validators. These sets implemented as Staking Modules of Staking Router. Currently only curated set (ode Operator Registry contract keys) exists. Council daemon v2 supports Staking Router contract. #### Keys API For fetching keys from diffent Staking Modules Council daemon v2 uses Keys API service. Keys API is a simple HTTP API to fetch keys from staking modules contracts. It stores keys in PostgreSQL database. To read more about Keys API check [document](https://hackmd.io/fv8btyNTTOGLZI6LqYyYIg?view) #### Using a PostgreSQL database to store the key cache The database is used as a caching layer of the Keys API. Since we will support a wide range of modules in the future, we need a database to store keys and other staking modules information in a more flexible way. #### We now use RabbitMQ instead of Kafka Using RabbitMQ is a step towards decentralization and reducing dependence on SaaS solutions. ## Overview The deployment consists of two parts: - Preparation of new infrastructure - Waiting for the DAO vote ### Preparation of new infrastructure Since the application was changed and it is important for us to keep the Consuls up and running during the upgrade, we need **to leave the old council-daemon v1 instance running** and start the new council-daemon v2. You can read how to start a new build of the application in the [guide](https://github.com/lidofinance/lido-council-daemon/blob/develop/README.md). This document contains the configuration files and a short guide on how to run Council daemon v2. ### Waiting for the DAO vote In the result of voting council-daemon v2 will switch to Staking Router contract automatically and start handling deposits and pauses. Council-daemon v1 will handle deposits and pauses before voting. We have added the following logs to the application to check switching to new contracts. ```log info: Contract address was changed {"address":"0x0000000000000000000000000000000000000000","contractKey":"contract:LidoAbi"} info: Contract address was changed {"address":"0x0000000000000000000000000000000000000000","contractKey":"contract:SecurityAbi"} info: Contract address was changed {"address":"0x0000000000000000000000000000000000000000","contractKey":"contract:StakingRouterAbi"} ``` Where it indicates that the contract addresses have changed. The addresses will be different, not as in the example. ## Step by step guide ### Run a **separate** instance To update, we need to run a new build of the application (council-daemon v2) **without turning off** the old build (council-daemon v1). In order to start a new build it is necessary to fill in the file with ENV variables. Below is an example to fill out. Data for RabbitMQ will be sent to your personal messages. <details> <summary>sample.env</summary> ``` # App PORT=3000 # Log level: debug, info, notice, warning or error LOG_LEVEL=info # Log format: simple or json LOG_FORMAT=simple # Pubsub (default: rabbitmq) PUBSUB_SERVICE=rabbitmq # RabbitMQ RABBITMQ_URL=wss://dsm.testnet.fi:443/ws RABBITMQ_LOGIN=LOGIN_FROM_PERSONAL_MESSAGES RABBITMQ_PASSCODE=PASSWORD_FROM_PERSONAL_MESSAGES # Private key # Used to sign transactions and stop the protocol. # Make sure there are enough ETH on the balance to send a transaction to stop the protocol WALLET_PRIVATE_KEY=0x0000000000000000000000000000000000000000000000000000000000000001 KEYS_API_HOST=http://keys_api_service_api # Keys API KEYS_API_PORT=3001 # chain id # for mainnet 1 # for testnet 5 CHAIN_ID=5 RPC_URL= # KeysAPI DB config KEYS_API_DB_NAME=keys_service_db KEYS_API_DB_PORT=5452 KEYS_API_DB_HOST=localhost KEYS_API_DB_USER=test KEYS_API_DB_PASSWORD=test ``` </details> The completed configuration file must be named as `.env` Next, take the docker-compose configuration file and put it next to the completed `.env` file. <details> <summary>docker-compose.yml</summary> ```yaml= version: '3.7' services: keys_api_service_db: image: postgres:14-alpine container_name: keys_api_service_db restart: unless-stopped environment: - POSTGRES_DB=${KEYS_API_DB_NAME} - POSTGRES_USER=${KEYS_API_DB_USER} - POSTGRES_PASSWORD=${KEYS_API_DB_PASSWORD} ports: - ${KEYS_API_DB_PORT}:5432 volumes: - ./.volumes/pgdata-${CHAIN_ID}/:/var/lib/postgresql/data keys_api_service_api: image: lidofinance/lido-keys-api@sha256:996476f3c272fd74ba89b8e46ec2510bc5c07831ebb276ad661ddb00971f1a21 container_name: keys_api_service_api ports: - '127.0.0.1:${KEYS_API_PORT}:3001' environment: - PORT=3001 - LOG_LEVEL=${LOG_LEVEL} - LOG_FORMAT=${LOG_FORMAT} - CHAIN_ID=${CHAIN_ID} - PROVIDERS_URLS=${RPC_URL} - VALIDATOR_REGISTRY_ENABLE=false - DB_NAME=${KEYS_API_DB_NAME} - DB_PORT=5432 - DB_HOST=keys_api_service_db - DB_USER=${KEYS_API_DB_USER} - DB_PASSWORD=${KEYS_API_DB_PASSWORD} depends_on: - keys_api_service_db council_daemon: image: lidofinance/lido-council-daemon@sha256:f9b1715aa4367821676a9cada0b6d159ace24a7f446da81e9c2838031e7bb5a9 ports: - "127.0.0.1:${PORT}:3000" # port is used for prometheus metrics environment: - PORT=3000 - LOG_LEVEL=${LOG_LEVEL} - LOG_FORMAT=${LOG_FORMAT} - RPC_URL=${RPC_URL} - WALLET_PRIVATE_KEY=${WALLET_PRIVATE_KEY} - KEYS_API_HOST=${KEYS_API_HOST} - KEYS_API_PORT=${KEYS_API_PORT} - PUBSUB_SERVICE=rabbitmq - RABBITMQ_URL=${RABBITMQ_URL} - RABBITMQ_LOGIN=${RABBITMQ_LOGIN} - RABBITMQ_PASSCODE=${RABBITMQ_PASSCODE} depends_on: - keys_api_service_api volumes: - ./.volumes/cache/:/council/cache/ ``` </details> After installing the docker-compose file and the .env configuration file, simply type the command: ```bash docker-compose up -d ``` Next, we can read the log: ```bash docker-compose logs -f ``` ### **Don't disconnect** old instance (council-daemon v1) In this step, it is important to make sure that you have not shut down the old application instance. We will let you know when you can turn it off. ### Check that the new instance (council-daemon v2) works You may have errors in your logs but this should not interfere with the functionality of the application ### Stay tuned After March 20th the Lido team will contact you and advise when you can disable the old instance