Prysmctl Command to Request Beacon Nodes for Block Ranges Over P2P

[rauljordan]

What type of PR is this?

Feature

What does this PR do? Why is it needed?

We lack tooling to spin up a local libp2p host that can peer with beacon nodes and issue proper requests for data. This is important for load testing new features that depend on the p2p stack, such as #11010. This PR adds in a subcommand to prysmctl which allows for querying a specific beacon node peer for a range of beacon blocks over p2p. Here's how to use it:

go run ./cmd/prysmctl p2p send beacon-blocks-by-range --help
NAME:
   prysmctl p2p send beacon-blocks-by-range - Request a range of blocks from a beacon node via a p2p connection

USAGE:
   prysmctl p2p send beacon-blocks-by-range [command options] [arguments...]

OPTIONS:
   --chain-config-file value    The path to a YAML file with chain config values
   --peer-multiaddrs value      comma-separated, peer multiaddr(s) to connect to for p2p requests
   --client-port value          port to use for the client as a libp2p host (default: 13001)
   --prysm-api-endpoints value  comma-separated, gRPC API endpoint(s) for Prysm beacon node(s) (default: "localhost:4000")
   --start-slot value           start slot for blocks by range request. If unset, will use start_slot(current_epoch-1) (default: 0)
   --count value                number of blocks to request, (default 32) (default: 32)
   --step value                 number of steps of blocks in the range request, (default 1) (default: 1)
   --help, -h                   show help (default: false)

This connects to a beacon node via gRPC as well to retrieve the necessary data to handshake with beacon nodes before making proper requests for data. The tool then outputs data to stdout showing the request timing and checking if the request worked or not.

To support custom configs, remember to specify the --chain-config-file to the command as well. This is crucial to get the feature to work well with the Sepolia chain, for example.

Example on Sepolia:

go run ./cmd/prysmctl p2p send beacon-blocks-by-range --chain-config-file=/Users/zypherpunk/interop/config.yaml

INFO[0000] List of peers                                 peers="[/ip4/10.0.0.74/tcp/13000/p2p/16Uiu2HAkzUiJ2it2cCaW3kKGVDjWCxaR4YNg2ca4YQFdG1RjEZNM]" prefix=prysmctl-p2p
INFO[0000] Sending blocks by range p2p request to peer   count=32 headSlot=216551 peer=16Uiu2HAkzUiJ2it2cCaW3kKGVDjWCxaR4YNg2ca4YQFdG1RjEZNM prefix=prysmctl-p2p startSlot=216512 step=1
INFO[0000] Preparing request for topic                   prefix=sync topic=/eth2/beacon_chain/req/beacon_blocks_by_range/2
INFO[0000] Received blocks from peer                     numBlocks=29 peer=16Uiu2HAkzUiJ2it2cCaW3kKGVDjWCxaR4YNg2ca4YQFdG1RjEZNM prefix=prysmctl-p2p timeFromSendingToProcessingResponse=27.388083ms totalBlocksWithExecutionPayloads=29

Which issues(s) does this PR fix?

Part of #10589

[prestonvanloon]

What's up with these changes?

[rauljordan]

See some of the self-review comments above. I don't have a great name for this composed interface, but it's the minimum amount of methods needed by the p2p service regarding the chain itself. During p2p and sync, we need the current fork, the genesis time, genesis validators root, and current slot. This new iface encompasses all that

[rauljordan]

Reducing interface surface area by composing stuff into something called ForkFetcher. This is the minimum set of methods needed by p2p and sync from the blockchain interface

[nisdas]

This is the wrong direction imo, we should be having all this under the network package as a sub-package for all these helpers.

[nisdas]

Same thoughts here