Configuration

Boros uses a config.toml file to define some configuration parameters. At least one Cardano Node Peer is required and a U5C server.

Schema

Example config.toml

[storage]
db_path = "boros.db"

[server]
listen_address="0.0.0.0:50052"

[peer_manager]
peers = [
  "Node:3001",
  "Node:3001",
]
desired_peer_count = 10
peers_per_request = 10

[monitor]
retry_slot_diff = 1000

[u5c]
uri = "https://mainnet.utxorpc-v0.demeter.run"

# metadata is optional
[u5c.metadata]
"dmtr-api-key" = "your key"

# optional config
[[queues]]
name = "banana"
weight = 2

[signing]
api_addr = "http://127.0.0.1:8200"
token = "your root token"
path = "path"
key = "key"

storage section

The storage section defines the options to start the local database. This db saves the transaction that the user sends and controls the status.

property	type	example
db_path	string	”/etc/boros/local.db”

• db_path: path to create the boros db

server section

The server section controls the options for the gRPC endpoint that can be used by clients.

property	type	example
listen_address	string	”0.0.0.0:50051”

• listen_address: the local address (IP:PORT) to listen for incoming gRPC connections.

peer_manager section

The peer_manager section defines the options that the peer manager uses to connect to the Cardano Node peer and to propagate the transactions.

property	type	example
peers	array	[ “Node:3001”, “Node:3001” ]
desired_peer_count	number	10
peers_per_request	number	10

• peers: The peers address (DNS or IP:PORT) to connect to the Cardano Node and to propagate transactions.
• desired_peer_count: The maximum allowable number of peer client connections.
• peers_per_request: The maximum number of peers that the peer client will request via peer sharing mini-protocol.

monitor section

The monitor section defines the options to control the monitor stage.

property	type	example
retry_slot_diff	number	1000

• retry_slot_diff: The number of slot units used to determine when to retry a transaction. If (slot_current_block - slot_tx_sent) > retry_slot_diff, the transaction will be retried.

u5c section

The u5c section defines the options for U5C to connect to chainsync.

property	type	example
uri	string	”https://mainnet.utxorpc-v0.demeter.run”

• uri: The uri to connect to a U5C server.

u5c.metadata section

The u5c.metadata section is optional and defines metadata for U5C connection, it’s a hashmap key value.

property	type	example
key	string	”value”

• key: a string value.

queues section

The queues section defines the options to create queues.

property	type	example
name	string	queue_name
weight	number	2
chained	bool	true
server_signing	bool	true

• name: queue name that can be used in sending transactions.
• weight: the weight of the queue. A queue with a bigger weight will have more priority to process transactions.
• chained: define the queue’s behaviour, when it’s true, to send a transaction to the queue it’s required to lock the state first.
• server_signing: indicates whether the queue can sign unsigned transactions.

signing section

The signing section defines the hashicorp vault configurations.

property	type	example
api_addr	string	”http://127.0.0.1:8200”
token	string	”your root token”
path	string	”path”
key	string	”key”

Local installation guide: Hashicorp Vault Installation

After installation, run the vault server via either of the following:

• vault server -dev: This automatically generates a root token, which is printed at the bottom of the Vault server logs.
• vault server -dev -dev-root-token-id="custom-root-token: This will allow you to generate your own custom root token

In either case, copy the root token and paste it into the token field in the signing configuration.

Once the server runs, login to hashicorp vault via:

• export VAULT_ADDR='http://127.0.0.1:8200'
• vault login your-root-token

After logging in successfully, you can manually store a secret using either of the following methods:

• Hashicorp Vault UI: In the dashboard, since we’re using Hashicorp Vault’s kv secret engine, click on the secret/ item under Secret Engines. Create your own secret — this will be the value for the path field in the signing config. Under secret data, specify the key-value pair. The key will correspond to the key field in the signing config.
• vault kv put secret/secret-name key="value": Alternatively, use this CLI command to store a secret directly.

Note that this is the case for hashicorp vault’s secret storage, at least for kv secret engine. You can store multiple key-value pairs under one secret / path.

• api_addr: The local hashicorp vault api address.
• token: Used mainly for authentication. Can either be automatically or manually generated when vault server runs.
• path: The path or basically the name of the secret.
• key: The key to be retrieved and be used for signing.

Tips

For U5C, the UTxO RPC from Demeter can be used.

The Cardano Relays can be found in the Pool details in the Cardano Explorer, example cexplorer.