Simplify Node config

[gligneul]

📚 Context

The node configuration is confusing because it is spread across multiple services.
It doesn't follow a single naming convention, and we have different variables with the same meaning.

✔️ Solution

We want to provide a set of environment variables in the new rollups-node monolith to help configure it. We will concentrate the documentation for these variables in a single place so it is easy to reason. We will also merge variables with the same meaning but different names. For instance, BH_HTTP_ENDPOINT and TX_PROVIDER_HTTP_ENDPOINT will become CARTESI_PROVIDER_HTTP_ENDPOINT.

We plan to add the CARTESI prefix to all variables to avoid clashing with previous names. If an internal variable is already set, the monolith will not overwrite it. For example, if you set BH_HTTP_ENDPOINT, the monolith won't overwrite it with CARTESI_PROVIDER_HTTP_ENDPOINT. Notice, however, that the monolith will set the TX_PROVIDER_HTTP_ENDPOINT to CARTESI_PROVIDER_HTTP_ENDPOINT if it isn't set.

We should define safe default values as much as possible to start the node defining with minimal configuration. Variables that can be set directly from the monolith won't be exposed. For instance, the address of the state server (SC_GRPC_ENDPOINT) will be hardcoded by the monolith to a local host address. If SC_GRPC_ENDPOINT is already set, the monolith won't overwrite, just like the case above. However, this is not recommended.

Here is the list of variables we will provide and where they are used. (In the final version, we won't document where they are used; this is just for development tracking.)

CARTESI_LOG_LEVEL

Sets RUST_LOG in all node services.
We have to think about the server manager log; currently, it is defined by:

• SERVER_MANAGER_LOG_LEVEL=warning
• REMOTE_CARTESI_MACHINE_LOG_LEVEL=info

CARTESI_GRAPHQL_PORT

• graphql-server: GRAPHQL_PORT

CARTESI_INSPECT_PORT

• inspect-server: INSPECT_SERVER_ADDRESS

In this case, INSPECT_SERVER_ADDRESS=0.0.0.0:$CARTESI_INSPECT_PORT

CARTESI_POSTGRES_*

• indexer and graphql-server: POSTGRES_*

CARTESI_REDIS_ENDPOINT

• dispatcher, advance-runner, indexer: REDIS_ENDPOINT

CARTESI_PROVIDER_HTTP_ENDPOINT

• dispatcher: TX_PROVIDER_HTTP_ENDPOINT
• state_server: BH_HTTP_ENDPOINT
• advance-runner: PROVIDER_HTTP_ENDPOINT

CARTESI_PROVIDER_WS_ENDPOINT

• state-server: BH_WS_ENDPOINT

CARTESI_DAPP_DEPLOYMENT_FILE

• dispatcher: RD_DAPP_DEPLOYMENT_FILE
• advance-runner and indexer: DAPP_CONTRACT_ADDRESS_FILE

CARTESI_ROLLUPS_DEPLOYMENT_FILE

• dispatcher: RD_ROLLUPS_DEPLOYMENT_FILE

CARTESI_CHAIN_ID

• dispatcher: TX_CHAIN_ID
• advance-runner and indexer: CHAIN_ID

CARTESI_CHAIN_IS_LEGACY

• dispatcher: TX_CHAIN_IS_LEGACY

CARTESI_EPOCH_DURATION

• dispatcher: RD_EPOCH_DURATION

CARTESI_STATE_FOLD_GENESIS_BLOCK

• state-server: SF_GENESIS_BLOCK

CARTESI_STATE_FOLD_SAFETY_MARGIN

• state-server: SF_SAFETY_MARGIN

CARTESI_STATE_FOLD_BLOCK_TIMEOUT

• state-server: BH_BLOCK_TIMEOUT

CARTESI_STATE_FOLD_DEFAULT_CONFIRMATIONS

• dispatcher: SC_DEFAULT_CONFIRMATIONS

CARTESI_TRANSACTION_DEFAULT_CONFIRMATIONS

Can we merge this one with CARTESI_STATE_SERVER_DEFAULT_CONFIRMATIONS?

• dispatcher: TX_DEFAULT_CONFIRMATIONS

CARTESI_AUTH_*

• dispatcher: AUTH_*

CARTESI_SERVER_MANAGER_SESSION_ID

• advance_runner and inspect_server: SESSION_ID

CARTESI_SNAPSHOT_DIR

• advance_runner: SNAPSHOT_DIR

We can set SNAPSHOT_LATEST in advance_runner to $SNAPSHOT_DIR/latest

CARTESI_SNAPSHOT_ENABLED

• advance_runner: SNAPSHOT_ENABLED

[gligneul]

We should consider #7 (comment).

To handle that, we could add a new variable called CARTESI_LOG_CONFIG that enables printing the config as it is parsed.

[tuler]

For the database configuration I'd follow the suggestion at #55

[gligneul]

For the database configuration I'd follow the suggestion at #55

I will prioritize it

[gligneul]

I evaluated the Viper package for Go, and I don't think it contributes much to what we need to achieve. Instead, I recommend taking a look at this package: https://github.com/caarlos0/env

[gligneul]

We should remove the DApp and Rollups deployment files and receive the necessary parameters as environment variables. The parameters are the DApp address, the deployment block hash, and the addresses of the History, Authority, and InputBox contracts. The History and Authority addresses should be obligatory parameters without default values because the DApp deployer must decide these parameters explicitly. The input box should have a default value because it is the same for every DApp and every chain.