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

==================================
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.