We should implement an opt-in key rotation feature that cycles among a list of keys to avoid this bottleneck. The approximate number of keys needed will be a function of the expected Avalanchego node account limit and the expected transaction issuance rate on the destination blockchain.
@cam-schultz I believe you are probably going to implement this feature straight after #288 . If there is another interesting issue I can work on, please ping me in.
Context and scope Both the
account-private-key
andkms-key-id
approaches (see https://github.com/ava-labs/awm-relayer?tab=readme-ov-file#configuration) support a single key per destination blockchain. Avalanchego nodes are configureable to limit the throughput of transactions in the mempool from a single address, and with scaling solutions such as https://github.com/ava-labs/awm-relayer/issues/31, a single relayer instance may bump against that limit.We should implement an opt-in key rotation feature that cycles among a list of keys to avoid this bottleneck. The approximate number of keys needed will be a function of the expected Avalanchego node account limit and the expected transaction issuance rate on the destination blockchain.