initial step of dynamic peer selection

[rkuhn]

Abstract

We add the ability for Amaru to identify potential peers and initiate connections to them.

Why?

Currently, only the peers specified when starting Amaru will be candidates for upstream connections. #658 will lead to the disconnection from misbehaving peers, so we’ll need the ability to dynamically connect to new peers.

Also, SPOs using Amaru as a relay will expect it to find and follow the Cardano network topology.

How?

A new stage will be added that receives information from the ledger and from the network (peer sharing?) to compute new peer candidates when those are needed: a configuration will be added to specify target cardinalities for various kinds of upstream peers. We’ll take inspiration from the Haskell implementation as well as from discussions with SPOs (those already started in 2025). This stage will send connection requests to the existing Manager.

Testing Strategy / Acceptance Criteria

The main focus here will be unit testing, because the peer selection logic is local and pure. We’ll also add an integration test (see #657) that discovers a new peer by communicating with a preconfigured peer, to show that it works.

Discussion points

No response

Dependencies & Related Tasks

depends on #658 to get organised wrt. upstream peer tracking

Checklist

• I understand that feature requests and unrefined work item should be open as GitHub Discussions instead.
• I have assigned this item to an existing milestone from the roadmap
• I have added a label capturing the impact of this item (i.e. value for users/stakeholders if successful)
• I have added a label capturing the delivery risk of this item (i.e. how likely is it that this task will succeed as planned)
• I have added a label capturing the effort of this item (i.e. how large is the task?)