rfc: p2p light client (#7672)

docs/rfc/README.md

@@ -46,5 +46,7 @@ sections.
 - [RFC-006: Event Subscription](./rfc-006-event-subscription.md)
 - [RFC-007: Deterministic Proto Byte Serialization](./rfc-007-deterministic-proto-bytes.md)
 - [RFC-008: Don't Panic](./rfc-008-don't-panic.md)
+- [RFC-009: Consensus Parameter Upgrades](./rfc-009-consensus-parameter-upgrades.md)
+- [RFC-010: P2P Light Client](./rfc-010-p2p-light-client.rst)
 
 <!-- - [RFC-NNN: Title](./rfc-NNN-title.md) -->

docs/rfc/rfc-010-p2p-light-client.rst

@@ -0,0 +1,145 @@
+==================================
+RFC 010: Peer to Peer Light Client
+==================================
+
+Changelog
+---------
+
+- 2022-01-21: Initial draft (@tychoish)
+
+Abstract
+--------
+
+The dependency on access to the RPC system makes running or using the light
+client more complicated than it should be, because in practice node operators
+choose to restrict access to these end points (often correctly.) There is no
+deep dependency for the light client on the RPC system, and there is a
+persistent notion that "make a p2p light client" is a solution to this
+operational limitation. This document explores the implications and
+requirements of implementing a p2p-based light client, as well as the
+possibilities afforded by this implementation.
+
+Background
+----------
+
+High Level Design
+~~~~~~~~~~~~~~~~~
+
+From a high level, the light client P2P implementation, is relatively straight
+forward, but is orthogonal to the P2P-backed statesync implementation that
+took place during the 0.35 cycle. The light client only really needs to be
+able to request (and receive) a `LightBlock` at a given height. To support
+this, a new Reactor would run on every full node and validator which would be
+able to service these requests. The workload would be entirely
+request-response, and the implementation of the reactor would likely be very
+straight forward, and the implementation of the provider is similarly
+relatively simple.
+
+The complexity of the project focuses around peer discovery, handling when
+peers disconnect from the light clients, and how to change the current P2P
+code to appropriately handle specialized nodes.
+
+I believe it's safe to assume that much of the current functionality of the
+current ``light`` mode would *not* need to be maintained: there is no need to
+proxy the RPC endpoints over the P2P layer and there may be no need to run a
+node/process for the p2p light client (e.g. all use of this will be as a
+client.)
+
+The ability to run light clients using the RPC system will continue to be
+maintained.
+
+LibP2P
+~~~~~~
+
+While some aspects of the P2P light client implementation are orthogonal to
+LibP2P project, it's useful to think about the ways that these efforts may
+combine or interact.
+
+We expect to be able to leverage libp2p tools to provide some kind of service
+discovery for tendermint-based networks. This means that it will be possible
+for the p2p stack to easily identify specialized nodes, (e.g. light clients)
+thus obviating many of the design challenges with providing this feature in
+the context of the current stack.
+
+Similarly, libp2p makes it possible for a project to be able back their non-Go
+light clients, without the major task of first implementing Tendermint's p2p
+connection handling. We should identify if there exist users (e.g. the go IBC
+relayer, it's maintainers, and operators) who would be able to take advantage
+of p2p light client, before switching to libp2p. To our knowledge there are
+limited implementations of this p2p protocol (a simple implementation without
+secret connection support exists in rust but it has not been used in
+production), and it seems unlikely that a team would implement this directly
+ahead of its impending removal.
+
+User Cases
+~~~~~~~~~~
+
+This RFC makes a few assumptions about the use cases and users of light
+clients in tendermint.
+
+The most active and delicate use cases for light clients is in the
+implementation of the IBC relayer. Thus, we expect that providing P2P light
+clients might increase the reliability of relayers and reduce the cost of
+running a relayer, because relayer operators won't have to decide between rely
+on public RPC endpoints (unreliable) or running their own full nodes
+(expensive.) This also assumes that there are *no* other uses of the RPC in
+the relayer, and unless the relayers have the option of dropping all RPC use,
+it's unclear if a P2P light client will actually be able to successfully
+remove the dependency on the RPC system.
+
+Given that the primary relayer implementation is Hermes (rust,) it might be
+safe to deliver a version of Tendermint that adds a light client rector in
+the full nodes, but that does not provide an implementation of a Go light
+client. This either means that the rust implementation would need support for
+the legacy P2P connection protocol or wait for the libp2p implementation.
+
+Client side light client (e.g. wallets, etc.) users may always want to use (a
+subset) of the RPC rather than connect to the P2P network for an ephemeral
+use.
+
+Discussion
+----------
+
+Implementation Questions
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+Most of the complication in the is how to have a long lived light client node
+that *only* runs the light client reactor, as this raises a few questions:
+
+- would users specify a single P2P node to connect to when creating a light
+  client or would they also need/want to discover peers?
+
+  - **answer**: most light client use cases won't care much about selecting
+    peers (and those that do can either disable PEX and specify persistent
+    peers, *or* use the RPC light client.)
+
+- how do we prevent full nodes and validators from allowing their peer slots,
+  which are typically limited, from filling with light clients? If
+  light-clients aren't limited, how do we prevent light clients from consuming
+  resources on consensus nodes?
+
+  - **answer**: I think we can institute an internal cap on number of light
+    client connections to accept and also elide light client nodes from PEX
+    (pre-libp2p, if we implement this.) I believe that libp2p should provide
+    us with the kind of service discovery semantics for network connectivity
+    that would obviate this issue.
+
+- when a light client disconnects from its peers will it need to reset its
+  internal state (cache)? does this change if it connects to the same peers?
+
+  - **answer**: no, the internal state only needs to be reset if the light
+    client detects an invalid block or other divergence, and changing
+    witnesses--which will be more common with a p2p light client--need not
+    invalidate the cache.
+
+These issues are primarily present given that the current peer management later
+does not have a particularly good service discovery mechanism nor does it have
+a very sophisticated way of identifying nodes of different types or modes.
+
+Report Evidence
+~~~~~~~~~~~~~~~
+
+The current light client implementation currently has the ability to report
+observed evidence. Either the notional light client reactor needs to be able
+to handle these kinds of requests *or* all light client nodes need to also run
+the evidence reactor. This could be configured at runtime.