Git-Mirrors/mev-toolkit
1
0
Fork 0
mirror of https://github.com/autistic-symposium/mev-toolkit.git synced 2025-04-25 02:09:24 -04:00
Code Issues Packages Projects Releases Wiki Activity
mev-toolkit/MEV_by_chains/MEV_on_Ethereum/running-a-node-advanced.md

7.3 KiB
Raw Blame History

🍕 more advanced notes on running validators



Screen Shot 2022-09-23 at 8 46 39 PM



tl;dr architecture


  • the validator is responsible for creating a new block and sending it out to other nodes on the network.
  • to participate as a validators, a user must deposit 32 ETH into the deposit contract and run 3 pieces of software: - an execution client - a consensus client - the engine api
  • once activated, validators receive new blocsk from peers (the txs delivered in the block are re-executed, and the block signature is checked).
  • the validator then sends a vote (attestation) in favor of that block across the network.
  • the timing of blocks is not determined by the mining difficult anymore, but it's fixed:
    • slots (12 seconds)
    • epochs (32 slots)
  • in every slot, a committee of validators is randomly chosen, whose votes are used to determine the validity of the block being proposed.
  • the first block in each epoch is a checkpoint.

tl;dr block creation


  1. execution clients gossip transactions over the execution-layer peer-to-peer network (encrypted communication)
  2. the execution layer's networking protocols is divided into 2 stacks:
    • the discovery stack: built on top of UDP and allows a new node to find peers to connect to
    • he DevP2P stack: sits on top of TCP and enables nodes to exchange information
  3. discovery of other nodes is boostrapped using a small set of bootnodes (nodes with addresses hardcoded into the client so they can be found easily)
  4. a validator is selected to propose a block, and transactions from the node's local transaction pool is passed to consensus clients via a local RPC connection, which will be packaged into Beacon blocks
  5. consensus clients use discv5 over UDP for finding peers.
  6. consensus clients then gossip Beacon blocks across their p2p network
  7. the process requires two separate p2p networks: one connecting execution clients for transaction gossip and one connecting consensus clients for block gossip
  8. the libP2P stack supports all communications after discovery, clients can dial and listen on IPv4 and/or IPv6 as defined in their ENR.


Screen Shot 2022-09-24 at 12 10 38 AM



validator lifecycle


The sequence of states that a validator can exist in:

  1. deposited: At least 32 ETH has been deposited to the deposit contract by the validator.
  2. pending: the validator is in the activation queue waiting to be voted into the network by existing validators.
  3. active: currently attesting and proposing blocks.
  4. slashing: the validator has misbehaved and is being slashed.
  5. exiting: the validator has been flagged for exiting the network, either voluntarily or because they have been ejected.

network addresses


  • three standardized formats that any Ethereum node can understand
multiaddr
  • universal format designed for peer-to-peer networks
  • for example, a classic IPv4 listing to TCP port 33000 /ip4/192.168.22.27/tcp/33000, plus an node id (a hash of the pub key)

enode
  • identify an Ethereum node using a URL address format

ethereum node records (ENRs)
  • allow greater informational exchange between nodes
  • contains a signature, sequence number and fields detailing the identity scheme used to generate and validate signatures
  • key-value pairs contain the node's IP address and information about the sub-protocols the node is able to use
  • consensus clients use a specific ENR structure to identify boot nodes

the JSON-RPC interface


  • interface that allows us to write programs that use an Ethereum client as a gateway to an Ethereum network and blockchain.
  • the RPC interface is offered as an HTTP service on port 8545. For security reasons it is restricted, by default, to only accept connections from localhost.

setting a dedicated hardware


execution client


  • check estimate of the blockchain size.
  • minimum specs:
    • CPU with 4+ cores
    • 16 GB+ RAM
    • fast SSD with at least 1TB free space, up to 12TB+ (bottleneck for your hardware is mostly disk space.
    • interent bandwith ~1.2-1.3 GB download and ~0.9-1 GB upload per hour.

consensus client


  • ~200GB for beacon data.

engine api


  • in order to connect a consensus client, the execution client must generate a jwtsecret:
openssl rand -hex 32 > jwtsecret

other considerations


  • after downloading a client release and its signature, use some PGP to verify them.
  • your router and firewall needs to accept connections on listening ports. By default Ethereum clients use a listener (TCP) port and a discovery (UDP) port, both on 30303 by default.
  • execution clients offer RPC API endpoints that you can use to submit transactions, interact with or deploy smart contracts on Ethereum.
  • the consensus clients all expose a Beacon API that can be used to check the status of the consensus client or download blocks and consensus data.
  • a privacy-preserving way to set up a publicly reachable endpoint is to host the node on your own Tor onion service.

useful commands and urls


find your ip

  • private: ifconfig | grep "inet " | grep -v 127.0.0.1
  • public: curl v4.ident.me
  • router: ip route | grep default (Linux), netstat -nr | grep default (MacOS)

beacon chain checkpoint sync

resources