jleony/nanoreth
1
0
Fork 0
mirror of https://github.com/hl-archive-node/nanoreth.git synced 2025-12-06 10:59:55 +00:00
Code Issues Packages Projects Releases Wiki Activity

add doc_markdown clippy lint (#8552)

Browse Source 
Co-authored-by: Alexey Shekhirin <a.shekhirin@gmail.com>
Co-authored-by: Matthias Seitz <matthias.seitz@outlook.de>
This commit is contained in:
Thomas Coratger
2024-06-03 15:21:45 +02:00
committed by GitHub
parent 34af610b8e
commit 7c17c6e469
440 changed files with 2166 additions and 2145 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
docs/crates/eth-wire.md
View File

@ -1,7 +1,7 @@
# eth-wire
The `eth-wire` crate provides abstractions over the [RLPx](https://github.com/ethereum/devp2p/blob/master/rlpx.md) and
[Eth wire](https://github.com/ethereum/devp2p/blob/master/caps/eth.md) protocols.
The `eth-wire` crate provides abstractions over the [``RLPx``](https://github.com/ethereum/devp2p/blob/master/rlpx.md) and
[Eth wire](https://github.com/ethereum/devp2p/blob/master/caps/eth.md) protocols.
This crate can be thought of as having 2 components:
@ -47,7 +47,7 @@ pub enum EthMessageID {
}
```
Messages can either be broadcast to the network, or can be a request/response message to a single peer. This 2nd type of message is
Messages can either be broadcast to the network, or can be a request/response message to a single peer. This 2nd type of message is
described using a `RequestPair` struct, which is simply a concatenation of the underlying message with a request id.
[File: crates/net/eth-wire/src/types/message.rs](https://github.com/paradigmxyz/reth/blob/1563506aea09049a85e5cc72c2894f3f7a371581/crates/net/eth-wire/src/types/message.rs)
@ -85,8 +85,8 @@ Let's understand how an `EthMessage` is implemented by taking a look at the `Tra
Transactions (0x02)
[tx₁, tx₂, ...]
Specify transactions that the peer should make sure is included on its transaction queue.
The items in the list are transactions in the format described in the main Ethereum specification.
Specify transactions that the peer should make sure is included on its transaction queue.
The items in the list are transactions in the format described in the main Ethereum specification.
...
```
@ -140,11 +140,11 @@ The lowest level stream to communicate with other peers is the P2P stream. It ta
- Tracks and Manages Ping and pong messages and sends them when needed.
- Keeps track of the SharedCapabilities between the reth node and its peers.
- Receives bytes from peers, decompresses and forwards them to its parent stream.
- Receives bytes from peers, decompresses and forwards them to its parent stream.
- Receives bytes from its parent stream, compresses them and sends it to peers.
Decompression/Compression of bytes is done with snappy algorithm ([EIP 706](https://eips.ethereum.org/EIPS/eip-706))
using the external `snap` crate.
Decompression/Compression of bytes is done with snappy algorithm ([EIP 706](https://eips.ethereum.org/EIPS/eip-706))
using the external `snap` crate.
[File: crates/net/eth-wire/src/p2pstream.rs](https://github.com/paradigmxyz/reth/blob/1563506aea09049a85e5cc72c2894f3f7a371581/crates/net/eth-wire/src/p2pstream.rs)
```rust,ignore
@ -220,7 +220,7 @@ pub(crate) fn poll_ping(
### Sending and receiving data
To send and receive data, the P2PStream itself is a future which implements the `Stream` and `Sink` traits from the `futures` crate.
For the `Stream` trait, the `inner` stream is polled, decompressed and returned. Most of the code is just
For the `Stream` trait, the `inner` stream is polled, decompressed and returned. Most of the code is just
error handling and is omitted here for clarity.
[File: crates/net/eth-wire/src/p2pstream.rs](https://github.com/paradigmxyz/reth/blob/1563506aea09049a85e5cc72c2894f3f7a371581/crates/net/eth-wire/src/p2pstream.rs)
@ -296,7 +296,7 @@ pub struct EthStream<S> {
}
```
EthStream's only job is to perform the RLP decoding/encoding, using the `ProtocolMessage::decode()` and `ProtocolMessage::encode()`
functions we looked at earlier.
functions we looked at earlier.
[File: crates/net/eth-wire/src/ethstream.rs](https://github.com/paradigmxyz/reth/blob/1563506aea09049a85e5cc72c2894f3f7a371581/crates/net/eth-wire/src/ethstream.rs)
```rust,ignore
@ -334,8 +334,8 @@ impl<S, E> Sink<EthMessage> for EthStream<S> {
}
```
## Unauthed streams
For a session to be established, peers in the Ethereum network must first exchange a `Hello` message in the RLPx layer and then a
`Status` message in the eth-wire layer.
For a session to be established, peers in the Ethereum network must first exchange a `Hello` message in the ``RLPx`` layer and then a
`Status` message in the eth-wire layer.
To perform these, reth has special `Unauthed` versions of streams described above.
@ -368,5 +368,3 @@ impl<S> UnauthedP2PStream<S> {
```
Similarly, UnauthedEthStream does the `Status` handshake and returns an `EthStream`. The code is [here](https://github.com/paradigmxyz/reth/blob/1563506aea09049a85e5cc72c2894f3f7a371581/crates/net/eth-wire/src/ethstream.rs)

8
docs/crates/network.md
View File

@ -145,7 +145,7 @@ pub struct NetworkConfig<C> {
pub executor: Option<TaskExecutor>,
/// The `Status` message to send to peers at the beginning.
pub status: Status,
/// Sets the hello message for the p2p handshake in RLPx
/// Sets the hello message for the p2p handshake in ``RLPx``
pub hello_message: HelloMessage,
}
```
@ -312,7 +312,7 @@ pub struct NetworkState<C> {
genesis_hash: B256,
/// The type that handles requests.
///
/// The fetcher streams RLPx related requests on a per-peer basis to this type. This type will
/// The fetcher streams ``RLPx`` related requests on a per-peer basis to this type. This type will
/// then queue in the request and notify the fetcher once the result has been received.
state_fetcher: StateFetcher,
}
@ -648,7 +648,7 @@ fn on_bodies_request(
## Transactions Task
The transactions task listens for, requests, and propagates transactions both from the node's peers, and those that are added locally (e.g., submitted via RPC). Note that this task focuses solely on the network communication involved with Ethereum transactions, we will talk more about the structure of the transaction pool itself
The transactions task listens for, requests, and propagates transactions both from the node's peers, and those that are added locally (e.g., submitted via RPC). Note that this task focuses solely on the network communication involved with Ethereum transactions, we will talk more about the structure of the transaction pool itself
in the [transaction-pool](../../../ethereum/transaction-pool/README.md) chapter.
Again, like the network management and ETH requests tasks, the transactions task is implemented as an endless future that runs as a background task on a standalone `tokio::task`. It's represented by the `TransactionsManager` struct:
@ -832,7 +832,7 @@ struct Peer {
}
```
Note that the `Peer` struct contains a field `transactions`, which is an [LRU cache](https://en.wikipedia.org/wiki/Cache_replacement_policies#Least_recently_used_(LRU)) of the transactions this peer is aware of.
Note that the `Peer` struct contains a field `transactions`, which is an [LRU cache](https://en.wikipedia.org/wiki/Cache_replacement_policies#Least_recently_used_(LRU)) of the transactions this peer is aware of.
The `request_tx` field on the `Peer` is used as the sender end of a channel to send requests to the session with the peer.