Configuration
Learn how to configure a Relayer
A relayer is configured to relayer messages between certain source and destination L1s. Therefore, the configuration consists of three parts:
- General Config: Configuration independent of the source and destination L1s concerning the network as a whole
- Source Blockchain Configs: All parameters necessary for the relayer to pick up the messages
- Destination Blockchain Configs: All parameters necessary to deliver the messages
The configuration is supplied to the relayer as a JSON file. Let's open the one automatically created for the Avalanche-CLI relayer:
Where the xxxx_xxxx will be a name automatically assigned to your local deployment.
Let's go through the different values:
General Config
The general config contains among others the following parameters:
- info-api-url: The URL of the Info API node to which the relayer will connect to to receive information like the NetworkID.
- p-chain-api-url: The URL of the Avalanche P-Chain API node to which the relayer will connect to query the validator sets.
Source Blockchain Configs
Next is the configuration for our source blockchain. This is the configuration of the blockchain where messages will be initiated and picked up. The relayer will aggregate the signatures of the validators of that Subnet.
- subnet-id: The Blockchain ID of the L1 that the source blockchain is part of. In this example this is the Blockchain ID of the Primary Network.
- blockchain-id: The blockchain ID of the source. In this example this is the blockchain ID of Fuji's C-Chain.
- vm: A string specifying the virtual machine of the destination L1's blockchain. Currently, only the EVM is supported, but this field has been added in anticipation of communication between blockchains powered by different virtual machines in the future.
- rpc-endpoint: An API Config containing:
- base-url: RPC endpoint of the destination L1's API node.
- query-parameters: Additional query parameters to include in the API requests
- http-headers: Additional HTTP headers to include in the API requests
- wss-endpoint: An API Config containing:
- base-url: The WebSocket endpoint of the source L1's API node
- query-parameters: Additional query parameters to include in the API requests
- http-headers: Additional HTTP headers to include in the API requests
- message-contracts: A map of contract addresses to the config options of the protocol (e.g. Teleporter) at that address. Each MessageProtocolConfig consists of a unique message-format name, and the raw JSON settings. "0x253b2784c75e510dD0fF1da844684a1aC0aa5fcf" is the address of the TeleporterMessenger on the Fuji C-Chain.
- message-format: should be set to Teleporter. Additional message formats next to Interchain Messaging may be developed in the future
- settings > reward-address: The address that will be rewarded if a L1 is incentivizing relayers to send messages on it's behalf. This is the address of the wallet you will create for this relayer.
Destination Blockchains
Next is the configuration for our source blockchain. This is the configuration of the blockchain where messages will be initiated and picked up. The relayer will aggregate the signatures of the validators of that L1.
For each destination L1, the relayer has the following config parameter:
- subnet-id: The ID of the L1 that the destination blockchain is part of.
- blockchain-id: The blockchain ID of the destination blockchain. This is the Blockchain ID of Fuji's Dispatch L1.
- vm: A string specifying the virtual machine of the destination L1's blockchain. Currently, only the EVM is supported, but this field has been added in anticipation of communication between blockchains powered by different virtual machines in the future.
- rpc-endpoint: The RPC endpoint of the destination L1's API node. Used in favor of api-node-host, api-node-port, and encrypt-connection when constructing the endpoint.
- kms-key-id: The ID of the KMS key to use for signing transactions on the destination blockchain. Only one of account-private-key or kms-key-id should be provided. If kms-key-id is provided, then kms-aws-region is required. Please note that the private key in KMS should be exclusive to the relayer.
- kms-aws-region: The AWS region in which the KMS key is located. Required if kms-key-id is provided.
- account-private-key: A private key for a wallet that holds gas tokens on the destination L1. This is required so the relayer can sign the transaction that delivers the warp message.
If you have been following all the course up to this point with the Avalanche-starter-kit and Avalanche-CLI will provide you with a relayer already funded to perform transactions between the local C-chain and your own chain
Some configuration fields have been omitted for the purpose of this exercise. If you are interested to read the extensive list of relayer configurations, you can visit the awm-relayer GitHub repository here.