seed: node

[ebuchman]

This a high level description of the first stage Rust Seed Node effort:

Here we propose to implement a Tendermint seed node in Rust, capable of running on Stargate networks, feature complete with the existing Tendermint seed node in Go. However, the current Tendermint p2p stack uses custom implementations of multiplexing over TCP (the "MConnection") and a custom authenticated encryption handshake ("SecretConnection"). MConnection is a significant amount of code that is quite old and minimally maintained, and SecretConnection has been cryptographically broken on multiple occasions. There is a history of discussions of moving to better standardized protocols with more robust implementations, like Quic and Noise, or even moving to libp2p, but there isn't resolution on this yet. Here, we propose to implement a seed node in Rust that is compatible with existing Tendermint in Go PeX reactor, but to also begin investigating upgrading Tendermint to use Quic and Noise and participate in the discussions about how to move this forward for Tendermint.

This work would include:

• MConnection compatible packet stream in Rust - packet-based streaming over TCP, compatible with Tendermint MConnection, but only for a single stream, with throttling, but without support for multiplexing, pings, or channel statistics. Essentially good enough to run only the PeX reactor on top
• SecretConnection - authenticated encryption wrapper around the MConnection. This is already implemented in Rust as part of the KMS but would be made compatible with the underlying MConnection
• Transport abstraction - develop an abstraction layer around the transport to easily support multiple implementations, including the MConnection, an in-process connection (for simulation and testing), and possible future transports like Quic
• NodeInfo Handshake - initial handshake with Tendermint peers after establishing a connection to verify node information and ensure compatibility
• AddressBook - an IP-based address book to track peers, facilitate service discovery, and provide some mitigation for certain network and DoS attacks
• Peer Exchange reactor - Tendermint PeX reactor, both "seed" and "normal" modes, for gossipping messages about peers

Tracking

• [x] p2p: migrate secret_connection to new p2p crate
• [x] p2p: rewrite SecretConnection handshake using the state machine pattern
• [x] p2p: test SecretConnection handshake
• [ ] p2p: design transport agnostic peer abstraction
• [ ] p2p: implement new peer abstraction based on secret_connection
• [ ] p2p: implement MConnection transport

[xla]

• AddressBook - an IP-based address book to track peers, facilitate service discovery, and provide some mitigation for certain network and DoS attacks

The sub points here seem conflated, implementing the address book by defining the shape of what to store per peer/ip is sensible to support dissemination to other peers for the actual seed functionality. If it comes to attack mitigation (if that is desired) needs to be broken out and looked at in more detail. Generally the breakdown here is mostly a one to one mapping of how the internals of the Go implementation work, which might not always be ideal. For example given the transport/p2p is in place a single protocol (Pex) on top of it could hold onto the peer list and answer independently of a global (rest of the node) view to pex requests.

Voiced this is sync communications before, I'm wary to commit to have fully assembled binaries as part of the core offering of this project/repo. Mainly as it is increases the surface that needs to be maintained and adds liability where it could be avoided. Surface does not only include the implementation itself - which would also require extended efforts into operationalisation of the binary - but also bug reporting facility, release management and distribution. Therefore I'm advocating for the strict offering of building blocks, with impeccable documentation on how to hold them in this repo, while pushing actual glued together binaries to adjacent repos, where they can be maintained and distributed with properly focused mandate.

[ebuchman]

The sub points here seem conflated

You mean re DoS attacks being part of the AddressBook? We definitely don't need to implement the Go addrbook exactly, and certainly don't need anything like the complex bucket mechanics yet, but we should have some minimal mitigations, things like basic address validation, not adding ourselves, a max size (but still have a way to probabilistically add new and drop old addresses), and removing peers that misbehave (eg by sending too many requests, or that we fail to connect to). The AddrBook is the list of peers we've heard about and might tell others about, but haven't necessarily even connected to yet, so we should at least avoid it being too easily DoSable.

Re the binary I think that could makes sense, so long as there's at least a basic binary for local development testing purposes. While the node is still in it's infancy I'd probably advocate for building the binary within this repo, but then break it out into its own repo before tagging say the v0.1.0