Expand description
What the model decides on a devp2p node: whether to admit a peer and with what Status, how
to answer its eth requests, and what to ask it for.
Rust owns everything under that — the RLPx handshake and frame encryption, Snappy, RLP, the
Hello exchange, Ping/Pong, block hashes. The model writes headers as the JSON fields
eth_getBlockByNumber returns and never a byte of RLP; Rust encodes them, hashes them, and
refuses an answer whose headers are not the ones the peer asked for (wrong numbers, a first
hash that is not the requested one, a header whose parentHash is not the previous header’s
hash, or a hash field the fields do not produce).
The action definitions here are shared with the client (src/client/devp2p/actions.rs):
once the handshake is done both sides of a devp2p session speak the same protocol.
Structs§
- Common
Config - Parsed startup configuration shared by both roles.
- Devp2p
Protocol
Statics§
- ANNOUNCED_
EVENT - BODIES_
RECEIVED_ EVENT - BODIES_
REQUESTED_ EVENT - HEADERS_
RECEIVED_ EVENT - HEADERS_
REQUESTED_ EVENT - POOLED_
RECEIVED_ EVENT - POOLED_
REQUESTED_ EVENT - REQUEST_
TIMEOUT_ EVENT - STATUS_
EVENT
Functions§
- all_
actions - Every action, in the order the model sees them.
- common_
config - common_
startup_ parameters - The startup parameters both roles share: identity and the Status defaults.
- default_
client_ id - The client id NetGet sends in Hello unless configured otherwise.
- disconnect_
action - event_
types - example_
header - A complete, valid header for examples: block 1 of an empty post-Cancun chain.
- p
- request_
bodies_ action - request_
headers_ action - request_
pooled_ action - send_
bodies_ action - send_
headers_ action - send_
pooled_ action - send_
status_ action