You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

66 lines
3.5 KiB

  1. # Peer Discovery
  2. A Tendermint P2P network has different kinds of nodes with different requirements for connectivity to one another.
  3. This document describes what kind of nodes Tendermint should enable and how they should work.
  4. ## Seeds
  5. Seeds are the first point of contact for a new node.
  6. They return a list of known active peers and then disconnect.
  7. Seeds should operate full nodes with the PEX reactor in a "crawler" mode
  8. that continuously explores to validate the availability of peers.
  9. Seeds should only respond with some top percentile of the best peers it knows about.
  10. See [the peer-exchange docs](https://github.com/tendermint/tendermint/blob/master/docs/spec/reactors/pex/pex.md)for details on peer quality.
  11. ## New Full Node
  12. A new node needs a few things to connect to the network:
  13. - a list of seeds, which can be provided to Tendermint via config file or flags,
  14. or hardcoded into the software by in-process apps
  15. - a `ChainID`, also called `Network` at the p2p layer
  16. - a recent block height, H, and hash, HASH for the blockchain.
  17. The values `H` and `HASH` must be received and corroborated by means external to Tendermint, and specific to the user - ie. via the user's trusted social consensus.
  18. This requirement to validate `H` and `HASH` out-of-band and via social consensus
  19. is the essential difference in security models between Proof-of-Work and Proof-of-Stake blockchains.
  20. With the above, the node then queries some seeds for peers for its chain,
  21. dials those peers, and runs the Tendermint protocols with those it successfully connects to.
  22. When the peer catches up to height H, it ensures the block hash matches HASH.
  23. If not, Tendermint will exit, and the user must try again - either they are connected
  24. to bad peers or their social consensus is invalid.
  25. ## Restarted Full Node
  26. A node checks its address book on startup and attempts to connect to peers from there.
  27. If it can't connect to any peers after some time, it falls back to the seeds to find more.
  28. Restarted full nodes can run the `blockchain` or `consensus` reactor protocols to sync up
  29. to the latest state of the blockchain from wherever they were last.
  30. In a Proof-of-Stake context, if they are sufficiently far behind (greater than the length
  31. of the unbonding period), they will need to validate a recent `H` and `HASH` out-of-band again
  32. so they know they have synced the correct chain.
  33. ## Validator Node
  34. A validator node is a node that interfaces with a validator signing key.
  35. These nodes require the highest security, and should not accept incoming connections.
  36. They should maintain outgoing connections to a controlled set of "Sentry Nodes" that serve
  37. as their proxy shield to the rest of the network.
  38. Validators that know and trust each other can accept incoming connections from one another and maintain direct private connectivity via VPN.
  39. ## Sentry Node
  40. Sentry nodes are guardians of a validator node and provide it access to the rest of the network.
  41. They should be well connected to other full nodes on the network.
  42. Sentry nodes may be dynamic, but should maintain persistent connections to some evolving random subset of each other.
  43. They should always expect to have direct incoming connections from the validator node and its backup(s).
  44. They do not report the validator node's address in the PEX and
  45. they may be more strict about the quality of peers they keep.
  46. Sentry nodes belonging to validators that trust each other may wish to maintain persistent connections via VPN with one another, but only report each other sparingly in the PEX.