github.com/badrootd/nibiru-cometbft@v0.37.5-0.20240307173500-2a75559eee9b/docs/rfc/rfc-010-p2p-light-client.rst (about)

     1  ==================================
     2  RFC 010: Peer to Peer Light Client
     3  ==================================
     4  
     5  Changelog
     6  ---------
     7  
     8  - 2022-01-21: Initial draft (@tychoish)
     9  
    10  Abstract
    11  --------
    12  
    13  The dependency on access to the RPC system makes running or using the light
    14  client more complicated than it should be, because in practice node operators
    15  choose to restrict access to these end points (often correctly.) There is no
    16  deep dependency for the light client on the RPC system, and there is a
    17  persistent notion that "make a p2p light client" is a solution to this
    18  operational limitation. This document explores the implications and
    19  requirements of implementing a p2p-based light client, as well as the
    20  possibilities afforded by this implementation.
    21  
    22  Background
    23  ----------
    24  
    25  High Level Design
    26  ~~~~~~~~~~~~~~~~~
    27  
    28  From a high level, the light client P2P implementation, is relatively straight
    29  forward, but is orthogonal to the P2P-backed statesync implementation that
    30  took place during the 0.35 cycle. The light client only really needs to be
    31  able to request (and receive) a `LightBlock` at a given height. To support
    32  this, a new Reactor would run on every full node and validator which would be
    33  able to service these requests. The workload would be entirely
    34  request-response, and the implementation of the reactor would likely be very
    35  straight forward, and the implementation of the provider is similarly
    36  relatively simple.
    37  
    38  The complexity of the project focuses around peer discovery, handling when
    39  peers disconnect from the light clients, and how to change the current P2P
    40  code to appropriately handle specialized nodes.
    41  
    42  I believe it's safe to assume that much of the current functionality of the
    43  current ``light`` mode would *not* need to be maintained: there is no need to
    44  proxy the RPC endpoints over the P2P layer and there may be no need to run a
    45  node/process for the p2p light client (e.g. all use of this will be as a
    46  client.)
    47  
    48  The ability to run light clients using the RPC system will continue to be
    49  maintained.
    50  
    51  LibP2P
    52  ~~~~~~
    53  
    54  While some aspects of the P2P light client implementation are orthogonal to
    55  LibP2P project, it's useful to think about the ways that these efforts may
    56  combine or interact.
    57  
    58  We expect to be able to leverage libp2p tools to provide some kind of service
    59  discovery for tendermint-based networks. This means that it will be possible
    60  for the p2p stack to easily identify specialized nodes, (e.g. light clients)
    61  thus obviating many of the design challenges with providing this feature in
    62  the context of the current stack.
    63  
    64  Similarly, libp2p makes it possible for a project to be able back their non-Go
    65  light clients, without the major task of first implementing Tendermint's p2p
    66  connection handling. We should identify if there exist users (e.g. the go IBC
    67  relayer, it's maintainers, and operators) who would be able to take advantage
    68  of p2p light client, before switching to libp2p. To our knowledge there are
    69  limited implementations of this p2p protocol (a simple implementation without
    70  secret connection support exists in rust but it has not been used in
    71  production), and it seems unlikely that a team would implement this directly
    72  ahead of its impending removal.
    73  
    74  User Cases
    75  ~~~~~~~~~~
    76  
    77  This RFC makes a few assumptions about the use cases and users of light
    78  clients in tendermint.
    79  
    80  The most active and delicate use cases for light clients is in the
    81  implementation of the IBC relayer. Thus, we expect that providing P2P light
    82  clients might increase the reliability of relayers and reduce the cost of
    83  running a relayer, because relayer operators won't have to decide between rely
    84  on public RPC endpoints (unreliable) or running their own full nodes
    85  (expensive.) This also assumes that there are *no* other uses of the RPC in
    86  the relayer, and unless the relayers have the option of dropping all RPC use,
    87  it's unclear if a P2P light client will actually be able to successfully
    88  remove the dependency on the RPC system.
    89  
    90  Given that the primary relayer implementation is Hermes (rust,) it might be
    91  safe to deliver a version of Tendermint that adds a light client rector in
    92  the full nodes, but that does not provide an implementation of a Go light
    93  client. This either means that the rust implementation would need support for
    94  the legacy P2P connection protocol or wait for the libp2p implementation.
    95  
    96  Client side light client (e.g. wallets, etc.) users may always want to use (a
    97  subset) of the RPC rather than connect to the P2P network for an ephemeral
    98  use.
    99  
   100  Discussion
   101  ----------
   102  
   103  Implementation Questions
   104  ~~~~~~~~~~~~~~~~~~~~~~~~
   105  
   106  Most of the complication in the is how to have a long lived light client node
   107  that *only* runs the light client reactor, as this raises a few questions:
   108  
   109  - would users specify a single P2P node to connect to when creating a light
   110    client or would they also need/want to discover peers?
   111  
   112    - **answer**: most light client use cases won't care much about selecting
   113      peers (and those that do can either disable PEX and specify persistent
   114      peers, *or* use the RPC light client.)
   115  
   116  - how do we prevent full nodes and validators from allowing their peer slots,
   117    which are typically limited, from filling with light clients? If
   118    light-clients aren't limited, how do we prevent light clients from consuming
   119    resources on consensus nodes?
   120  
   121    - **answer**: I think we can institute an internal cap on number of light
   122      client connections to accept and also elide light client nodes from PEX
   123      (pre-libp2p, if we implement this.) I believe that libp2p should provide
   124      us with the kind of service discovery semantics for network connectivity
   125      that would obviate this issue.
   126  
   127  - when a light client disconnects from its peers will it need to reset its
   128    internal state (cache)? does this change if it connects to the same peers?
   129  
   130    - **answer**: no, the internal state only needs to be reset if the light
   131      client detects an invalid block or other divergence, and changing
   132      witnesses--which will be more common with a p2p light client--need not
   133      invalidate the cache.
   134  
   135  These issues are primarily present given that the current peer management later
   136  does not have a particularly good service discovery mechanism nor does it have
   137  a very sophisticated way of identifying nodes of different types or modes.
   138  
   139  Report Evidence
   140  ~~~~~~~~~~~~~~~
   141  
   142  The current light client implementation currently has the ability to report
   143  observed evidence. Either the notional light client reactor needs to be able
   144  to handle these kinds of requests *or* all light client nodes need to also run
   145  the evidence reactor. This could be configured at runtime.