Devp2p Run A Node

Run a Node — SyncNode facade (Nethereum.DevP2P.Sync)

Connecting to a peer and discovering peers (see devp2p-peer-connect and devp2p-peer-discovery) cover the transport primitives one at a time — dialing, listening, discovering. A real node needs all of them working together: a peer pool, a fetch scheduler, an inbound listener serving eth/snap to other nodes, and (optionally) a mempool relay — plus the sync engine (devp2p-full-sync, devp2p-snap-sync). SyncNode is the facade that ties this into one object, in the same spirit as Web3 for the JSON-RPC side of Nethereum: construct it once from your chain's storage and activation config, then reach every sync capability from it.

Package

dotnet add package Nethereum.DevP2P.Sync

You'll need an IChainStoreBundle (block/state storage) and IChainActivations (fork schedule) from Nethereum.CoreChain — these come from whichever chain you're running (mainnet follower or an AppChain), not from this package. You'll also typically have already built the peering resources: an IPeerPool, an IFetchRequestScheduler, and optionally a PeerListener for serving.

Mental model: one facade, four capabilities

public sealed class SyncNode
{
    public IPeerPool Peers { get; }                    // dial-out / inbound pool (null if not configured)
    public IFetchRequestScheduler Scheduler { get; }   // fans fetch requests across peers (null if not configured)
    public PeerListener Serving { get; }               // inbound listener; serves eth + snap (null if not serving)
    public RelayMempool Mempool { get; }               // good-citizen relay tx pool (null if not relaying)

    public SyncNode(
        IChainStoreBundle bundle, IChainActivations activations, ILogger logger,
        IPeerPool peers = null, IFetchRequestScheduler scheduler = null, PeerListener serving = null,
        RelayMempool mempool = null);

    public Task StartServingAsync(CancellationToken ct = default);   // bind the listener; no-op if not serving
    public Task<SnapBootstrapper.Result> RunSnapBootstrapAsync(      // cold-start state; delegates to the orchestrator
        ICanonicalStateRootSource canonicalTip, SnapSyncOrchestratorOptions options = null,
        CancellationToken ct = default);
}

Each of the four properties is null when you didn't configure that capability — a node that only backfills the archive (no inbound serving) simply won't set serving, and node.Serving stays null. This lets one class model "full node," "archive-only follower," and "serving-only" without three different types. The underlying drivers (SnapSyncOrchestrator, SnapBootstrapper, the phase workers) stay directly usable for advanced control — SyncNode is a front door, not a wall.

Start serving eth and snap to other peers

If you built a PeerListener (the inbound serving composition — binds a port, drives the eth server handshake, and serves eth plus snap/1 to peers syncing from you) and passed it into the constructor's serving parameter, StartServingAsync binds it:

var node = new SyncNode(bundle, activations, logger, peers: pool, scheduler: scheduler, serving: peerListener);

await node.StartServingAsync(ct);   // no-op if you didn't pass a `serving` PeerListener

This is what makes your node useful to other nodes doing full sync or snap sync against you — without it, your node can dial out and sync but nobody can sync from it. RlpxListener.PeerAccepted alone (see devp2p-peer-connect) does not run the eth Status exchange; PeerListener fills that gap.

Relay locally-submitted transactions

RelayMempool is the "good citizen" side of mempool participation: it admits transactions your own node (or a locally-connected wallet/RPC client) submits — after running them through MempoolAdmissionValidator — holds them in an ITxPool, and announces their hashes to your connected peers. It is deliberately leaf-only: it never re-gossips transactions it received from other peers, so a SyncNode participates in propagation without becoming a full relay hub.

var node = new SyncNode(bundle, activations, logger, peers: pool, scheduler: scheduler, mempool: relayMempool);

var result = await node.Mempool.SubmitAsync(signedTx);   // MempoolSubmitResult tells you the outcome
if (!result.Accepted)
{
    // result.RejectReason (MempoolRejectReason) + result.RejectMessage explain why
}

SubmitAsync(ISignedTransaction, CancellationToken) : Task<MempoolSubmitResult> — the real signature, from Mempool/RelayMempool.cs. Do not use an Admit-named method; it does not exist. MempoolSubmitResult (Mempool/MempoolSubmitResult.cs) exposes Accepted, TransactionHash, Sender, RejectReason, RejectMessage. Check result.Accepted (and RejectReason/RejectMessage on failure) before assuming a submitted transaction actually made it into the pool — a full pool, a stale nonce, or a validator rejection all fail silently from the caller's perspective unless you inspect the result. (AdmitFromTrustedPeerAsync is the separate inbound path used when relaying transactions received from peers, not the path for a locally-submitted transaction.)