How Ethereum Nodes Talk and Sync: Peer-to-Peer in Action

Ethereum is a peer-to-peer network where thousands of computers, called nodes, communicate using shared rules. These rules, known as the "networking layer," help nodes find each other and share information. This communication happens in two ways: broadcasting data to many nodes (gossiping) and sending specific messages between individual nodes. Ethereum nodes have two main parts: execution clients and consensus clients. Each has its own job and network. Execution clients share transactions in an encrypted P2P network, storing them in a local pool. When a validator creates a new block, these transactions are sent to the consensus client through a local connection. The consensus client packages them into Beacon blocks and shares them on its P2P network. This setup requires two separate P2P networks: one for sharing transactions and another for sharing blocks, ensuring smooth and secure communication between nodes. The Ethereum execution layer uses two main networking protocol stacks to keep the network running: Discovery Stack: This stack operates on UDP and helps new nodes find and connect to peers in the network. DevP2P Stack: Built on TCP, this stack enables nodes to share and exchange information after connecting. Both stacks work together in parallel. The discovery stack ensures that new nodes can join the network, while the DevP2P stack handles communication between nodes, enabling them to interact seamlessly. This combination ensures that Ethereum's peer-to-peer network remains decentralized and efficient. How New Nodes Discover the Ethereum Network? When a new Ethereum node joins the network, it needs to find other nodes to connect with. This process is called discovery. Starting with Bootnodes What Are Bootnodes? Bootnodes are special nodes with hardcoded addresses in Ethereum clients. Their sole purpose is to introduce new nodes to the network by providing a list of active peers. They do not participate in tasks like syncing the blockchain and are only used the first time a client connects to the network. How It Works: When a new node starts, it contacts a bootnode to receive a list of neighbors (peers) using the discovery protocol. The node then establishes connections with these neighbors through additional discovery interactions. The Discovery Protocol Ethereum nodes use peer discovery protocols to locate and connect with other nodes in the network. This is essential for maintaining Ethereum's decentralized peer-to-peer (P2P) network. Currently, Ethereum uses Discovery Protocol Version 4 (Discv4) and is transitioning to Discovery Protocol Version 5 (Discv5). Here's how these protocols work: Discv4 (Current Protocol) Purpose: Discv4 is the current standard for Ethereum's peer discovery, used in execution clients. How It Works: Each node maintains a Kademlia-like Distributed Hash Table (DHT). This table maps Node IDs to IP addresses and ports. Node IDs are derived from public keys. Node "closeness" is determined by the similarity of Node IDs, not by geographic distance. Nodes periodically refresh their DHT to maintain accuracy and security. Steps to Discover Peers: Initiating Contact: A new node sends a PING message to a bootnode or a known peer. The PING contains: The Hashed Node ID (unique identifier of the node). The Bootnode ID (identifier of the target bootnode). An Expiry Timestamp (indicating the validity of the message). Verification: The bootnode responds with a PONG message that includes the hash sent in the PING. If the hashes match, the connection is verified, and the nodes are considered bonded (trusted). Requesting Neighbors: Once bonded, the new node sends a FIND_NEIGHBOURS request to the bootnode. The bootnode replies with a list of neighboring peers (nodes that are close to the new node's ID in the network). Bonding with Neighbors: The new node performs a PING-PONG exchange with each neighbor received from the bootnode. Successful exchanges bond the new node with these neighbors, allowing them to communicate. Expanding the Network: The new node repeats the process (PING, PONG, FIND_NEIGHBOURS) with newly bonded peers to discover additional nodes. This iterative process continues until the new node has a sufficiently diverse list of peers. Discv5 (Upcoming Protocol) Enhancements Over Discv4: Ethereum Node Records (ENR): A structured object introduced in Discv5 to manage identifying information. Key components of ENR include: Signature: A cryptographic hash of the record contents, ensuring data integrity. Sequence Number: Tracks updates to the ENR, enabling dynamic handling and prioritization of the latest records. Key-Value Pairs: Additional information like Node ID, IP address, supported protocols, and client type/version. Dynamic IP Handling: ENR supports nodes with changing IP addresses, improving network flexibility. Future-Proof Design: The ENR format is versatile, accommodating future changes in network structure. Additional Features: Nodes can advertise supported subprotocols, allowing for compatibility negotiation. Improved scalability and security using modern cryptographic techniques. Why ethereum discovery is built on UDP protocol over TCP protocol? The Ethereum discovery protocol uses UDP because it's fast and simple, without the need for setting up connections or handling errors. This makes it perfect for quickly finding other nodes in the network. UDP just sends information efficiently without waiting for confirmation. For more detailed tasks, like syncing data, Ethereum uses TCP, which ensures reliable communication with features like error checking and resending data if something goes wrong. This way, Ethereum uses UDP for speed during discovery and TCP for reliability during data exchange. Establishing Connections After discovering peers, Ethereum nodes use the DevP2P stack, starting with the RLPx protocol to establish secure communication. RLPx is a key protocol in Ethereum's DevP2P stack that helps nodes connect and communicate securely. It uses RLP (Recursive Length Prefix) encoding to compress and organize data efficiently for transmission. The protocol ensures encrypted and authenticated communication, creating a secure connection between nodes. Once this connection is established, nodes can interact using various subprotocols for exchanging blockchain data or for syncing state, enabling smooth and reliable network operations. RLPx Protocol Cryptographic Handshake: The nodes exchange public keys and initiate encryption using ECIES (Elliptic Curve Integrated Encryption Scheme). This generates a shared secret, ensuring secure communication between the nodes. Hello Exchange: Following the handshake, the nodes send "hello" messages containing key details, including: Supported subprotocols. Client version. Node ID. Port and protocol version information. This allows both nodes to identify each other's capabilities and set up a compatible connection. Session Maintenance: Ping/Pong Messages: Periodic "ping" messages are sent to confirm the peer's availability, and the receiving node replies with a "pong" message. This ensures that the session stays active and maintains the connection. Disconnect Message: If a node intends to terminate the session, it can send a "disconnect" message to the peer, notifying them of the upcoming disconnection. This is a polite way of closing the connection gracefully. Sub-Protocols within DevP2P stack: Transaction and Data Exchange After nodes are connected, the wire protocol manages how they communicate. It originally handled tasks like: Syncing chains: Ensuring all nodes are up-to-date with the blockchain. Propagating blocks: Sharing new blocks across the network. Exchanging transactions: Sharing pending transactions between nodes for future blocks. However, with Ethereum's shift to Proof of Stake (PoS), syncing blocks and chain data is now part of the consensus layer, while transaction exchange continues under execution clients. Light Ethereum Subprotocol (LES) The LES protocol is for light clients, which are nodes that don’t store the whole blockchain. They rely on full nodes to provide data when needed. Light clients save space and resources, but they depend on full nodes to share information with them. However, because full nodes aren’t incentivized to serve light clients, LES has not been used much. Snap Protocol The Snap protocol is an extension that helps Ethereum nodes exchange state snapshots (recent data states). This allows nodes to verify accounts and storage without downloading too much data, speeding up the process of syncing with the network. Witness Protocol (Wit) The Witness Protocol lets Ethereum nodes share state witnesses, helping them stay updated with the latest blockchain state. This is especially useful for clients syncing to the latest block, reducing the amount of data they need to download. Whisper Protocol (Deprecated) The Whisper protocol was designed for secure messaging between nodes, without storing any messages on the blockchain. However, it had problems with scalability and wasn’t widely adopted. As a result, it has been deprecated, and other projects are now working on similar secure messaging solutions. The Consensus Layer The Ethereum consensus layer ensures that all Ethereum nodes agree on the state of the blockchain, keeping everything in sync. It works separately from the execution layer (where transactions are executed) but needs to interact closely with it. Peer Discovery Just like the execution clients, the consensus clients need a way to discover other nodes (peers) in the network. They use a protocol called discV5 over UDP. This is different from the old DevP2P system and integrates libP2P, a newer and more flexible technology. Ethereum Node Records (ENR) for Consensus Nodes Each consensus node in the Ethereum network has an Ethereum Node Record (ENR), which helps other nodes identify and connect to it. The ENR contains: Public Key: The node’s cryptographic key for secure communication. IP Address: The node’s internet address. UDP and TCP Ports: These specify which ports the node listens to for communication over UDP and TCP. Attestation Subnet Bitfield: This field helps nodes find others that are involved in attestation gossip, making it easier to sync with peers that are part of specific attestation sub-networks. Eth2 Key: This identifies which Ethereum fork version the node is using. It ensures that nodes only connect to peers running the correct Ethereum version, keeping everything compatible and synchronized. LibP2P: The Communication Backbone After discovering peers, the consensus layer uses libP2P to keep the communication going. It uses two main methods for communication: Gossip: This helps spread important updates like new blocks and attestations quickly across the network. It’s like passing a note between people in class, making sure everyone gets the same information fast. Request-Response: This is a more specific way for one node to ask another for particular data, like a block with certain information. It’s like requesting a copy of a specific page from a book. Why SSZ for Consensus? In Ethereum's consensus layer, SSZ (Simple Serialization) is used instead of the usual RLP (Recursive Length Prefix) format. This is because SSZ is faster and more efficient when dealing with large data and makes it easier to verify information in Merkle trees, which are used to keep the blockchain secure. Connecting Execution and Consensus Clients The execution layer (which processes transactions) and the consensus layer (which secures the blockchain) need to talk to each other. This happens through a local RPC connection. They share a common Ethereum Node Record (ENR), which keeps track of information like the client's public key and which layer it belongs to. When consensus client is not block producer: Consensus client receives a block via the block gossip protocol (consensus p2p) Consensus client pre-validates the block, i.e. ensures it arrived from a valid sender with correct metadata The transactions in the block are sent to the execution layer as an execution payload (local RPC connection) The execution layer executes the transactions and validates the state in the block header (i.e. checks hashes match) Execution layer passes validation data back to consensus layer, block now considered to be validated (local RPC connection) Consensus layer adds block to head of its own blockchain and attests to it, broadcasting the attestation over the network (consensus p2p) When consensus client is block producer: Consensus client receives notice that it is the next block producer (consensus p2p) Consensus layer calls create block method in execution client (local RPC) Execution layer accesses the transaction mempool which has been populated by the transaction gossip protocol (execution p2p) Execution client bundles transactions into a block, executes the transactions and generates a block hash Consensus client grabs the transactions and block hash from the execution client and adds them to the beacon block (local RPC) Consensus client broadcasts the block over the block gossip protocol (consensus p2p) Other clients receive the proposed block via the block gossip protocol and validate as described above (consensus p2p) References: Ethereum Networking Layer Documentation From Kademlia to Discv5 Overview of Kademlia in Decentralized Platforms Ethereum is a peer-to-peer network where thousands of computers, called nodes, communicate using shared rules. These rules, known as the "networking layer," help nodes find each other and share information. This communication happens in two ways: broadcasting data to many nodes (gossiping) and sending specific messages between individual nodes. Ethereum nodes have two main parts: execution clients and consensus clients. Each has its own job and network. Execution clients share transactions in an encrypted P2P network, storing them in a local pool. When a validator creates a new block, these transactions are sent to the consensus client through a local connection. The consensus client packages them into Beacon blocks and shares them on its P2P network. This setup requires two separate P2P networks: one for sharing transactions and another for sharing blocks, ensuring smooth and secure communication between nodes. The Ethereum execution layer uses two main networking protocol stacks to keep the network running: Discovery Stack: This stack operates on UDP and helps new nodes find and connect to peers in the network. DevP2P Stack: Built on TCP, this stack enables nodes to share and exchange information after connecting. Discovery Stack : This stack operates on UDP and helps new nodes find and connect to peers in the network. Discovery Stack DevP2P Stack : Built on TCP, this stack enables nodes to share and exchange information after connecting. DevP2P Stack Both stacks work together in parallel. The discovery stack ensures that new nodes can join the network, while the DevP2P stack handles communication between nodes, enabling them to interact seamlessly. This combination ensures that Ethereum's peer-to-peer network remains decentralized and efficient. How New Nodes Discover the Ethereum Network? How New Nodes Discover the Ethereum Network? When a new Ethereum node joins the network, it needs to find other nodes to connect with. This process is called discovery . discovery Starting with Bootnodes Starting with Bootnodes What Are Bootnodes? Bootnodes are special nodes with hardcoded addresses in Ethereum clients. Their sole purpose is to introduce new nodes to the network by providing a list of active peers. They do not participate in tasks like syncing the blockchain and are only used the first time a client connects to the network. How It Works: When a new node starts, it contacts a bootnode to receive a list of neighbors (peers) using the discovery protocol. The node then establishes connections with these neighbors through additional discovery interactions. What Are Bootnodes? Bootnodes are special nodes with hardcoded addresses in Ethereum clients. Their sole purpose is to introduce new nodes to the network by providing a list of active peers. They do not participate in tasks like syncing the blockchain and are only used the first time a client connects to the network. What Are Bootnodes? What Are Bootnodes? Bootnodes are special nodes with hardcoded addresses in Ethereum clients. Their sole purpose is to introduce new nodes to the network by providing a list of active peers. They do not participate in tasks like syncing the blockchain and are only used the first time a client connects to the network. Bootnodes are special nodes with hardcoded addresses in Ethereum clients. Bootnodes are special nodes with hardcoded addresses in Ethereum clients. Their sole purpose is to introduce new nodes to the network by providing a list of active peers. Their sole purpose is to introduce new nodes to the network by providing a list of active peers. They do not participate in tasks like syncing the blockchain and are only used the first time a client connects to the network. They do not participate in tasks like syncing the blockchain and are only used the first time a client connects to the network. How It Works: When a new node starts, it contacts a bootnode to receive a list of neighbors (peers) using the discovery protocol. The node then establishes connections with these neighbors through additional discovery interactions. How It Works: How It Works: When a new node starts, it contacts a bootnode to receive a list of neighbors (peers) using the discovery protocol. The node then establishes connections with these neighbors through additional discovery interactions. When a new node starts, it contacts a bootnode to receive a list of neighbors (peers) using the discovery protocol. The node then establishes connections with these neighbors through additional discovery interactions. The Discovery Protocol The Discovery Protocol Ethereum nodes use peer discovery protocols to locate and connect with other nodes in the network. This is essential for maintaining Ethereum's decentralized peer-to-peer (P2P) network. Currently, Ethereum uses Discovery Protocol Version 4 (Discv4) and is transitioning to Discovery Protocol Version 5 (Discv5) . Here's how these protocols work: peer discovery protocols Discovery Protocol Version 4 (Discv4) Discovery Protocol Version 5 (Discv5) Discv4 (Current Protocol) Discv4 (Current Protocol) Purpose: Discv4 is the current standard for Ethereum's peer discovery, used in execution clients. Purpose: Discv4 is the current standard for Ethereum's peer discovery, used in execution clients. Purpose: How It Works: Each node maintains a Kademlia-like Distributed Hash Table (DHT). This table maps Node IDs to IP addresses and ports. Node IDs are derived from public keys. Node "closeness" is determined by the similarity of Node IDs, not by geographic distance. Nodes periodically refresh their DHT to maintain accuracy and security. How It Works: Each node maintains a Kademlia-like Distributed Hash Table (DHT) . This table maps Node IDs to IP addresses and ports. Node IDs are derived from public keys. Node "closeness" is determined by the similarity of Node IDs, not by geographic distance. Nodes periodically refresh their DHT to maintain accuracy and security. How It Works: Kademlia-like Distributed Hash Table (DHT) Kademlia-like Distributed Hash Table (DHT) Steps to Discover Peers: Initiating Contact: A new node sends a PING message to a bootnode or a known peer. The PING contains: The Hashed Node ID (unique identifier of the node). The Bootnode ID (identifier of the target bootnode). An Expiry Timestamp (indicating the validity of the message). Verification: The bootnode responds with a PONG message that includes the hash sent in the PING. If the hashes match, the connection is verified, and the nodes are considered bonded (trusted). Requesting Neighbors: Once bonded, the new node sends a FIND_NEIGHBOURS request to the bootnode. The bootnode replies with a list of neighboring peers (nodes that are close to the new node's ID in the network). Bonding with Neighbors: The new node performs a PING-PONG exchange with each neighbor received from the bootnode. Successful exchanges bond the new node with these neighbors, allowing them to communicate. Expanding the Network: The new node repeats the process (PING, PONG, FIND_NEIGHBOURS) with newly bonded peers to discover additional nodes. This iterative process continues until the new node has a sufficiently diverse list of peers. Discv5 (Upcoming Protocol) Enhancements Over Discv4: Ethereum Node Records (ENR): A structured object introduced in Discv5 to manage identifying information. Key components of ENR include: Signature: A cryptographic hash of the record contents, ensuring data integrity. Sequence Number: Tracks updates to the ENR, enabling dynamic handling and prioritization of the latest records. Key-Value Pairs: Additional information like Node ID, IP address, supported protocols, and client type/version. Dynamic IP Handling: ENR supports nodes with changing IP addresses, improving network flexibility. Future-Proof Design: The ENR format is versatile, accommodating future changes in network structure. Additional Features: Nodes can advertise supported subprotocols, allowing for compatibility negotiation. Improved scalability and security using modern cryptographic techniques. Steps to Discover Peers: Initiating Contact: A new node sends a PING message to a bootnode or a known peer. The PING contains: The Hashed Node ID (unique identifier of the node). The Bootnode ID (identifier of the target bootnode). An Expiry Timestamp (indicating the validity of the message). Verification: The bootnode responds with a PONG message that includes the hash sent in the PING. If the hashes match, the connection is verified, and the nodes are considered bonded (trusted). Requesting Neighbors: Once bonded, the new node sends a FIND_NEIGHBOURS request to the bootnode. The bootnode replies with a list of neighboring peers (nodes that are close to the new node's ID in the network). Bonding with Neighbors: The new node performs a PING-PONG exchange with each neighbor received from the bootnode. Successful exchanges bond the new node with these neighbors, allowing them to communicate. Expanding the Network: The new node repeats the process (PING, PONG, FIND_NEIGHBOURS) with newly bonded peers to discover additional nodes. This iterative process continues until the new node has a sufficiently diverse list of peers. Discv5 (Upcoming Protocol) Enhancements Over Discv4: Ethereum Node Records (ENR): A structured object introduced in Discv5 to manage identifying information. Key components of ENR include: Signature: A cryptographic hash of the record contents, ensuring data integrity. Sequence Number: Tracks updates to the ENR, enabling dynamic handling and prioritization of the latest records. Key-Value Pairs: Additional information like Node ID, IP address, supported protocols, and client type/version. Dynamic IP Handling: ENR supports nodes with changing IP addresses, improving network flexibility. Future-Proof Design: The ENR format is versatile, accommodating future changes in network structure. Additional Features: Nodes can advertise supported subprotocols, allowing for compatibility negotiation. Improved scalability and security using modern cryptographic techniques. Steps to Discover Peers: Steps to Discover Peers: Initiating Contact: A new node sends a PING message to a bootnode or a known peer. The PING contains: The Hashed Node ID (unique identifier of the node). The Bootnode ID (identifier of the target bootnode). An Expiry Timestamp (indicating the validity of the message). Verification: The bootnode responds with a PONG message that includes the hash sent in the PING. If the hashes match, the connection is verified, and the nodes are considered bonded (trusted). Requesting Neighbors: Once bonded, the new node sends a FIND_NEIGHBOURS request to the bootnode. The bootnode replies with a list of neighboring peers (nodes that are close to the new node's ID in the network). Bonding with Neighbors: The new node performs a PING-PONG exchange with each neighbor received from the bootnode. Successful exchanges bond the new node with these neighbors, allowing them to communicate. Expanding the Network: The new node repeats the process (PING, PONG, FIND_NEIGHBOURS) with newly bonded peers to discover additional nodes. This iterative process continues until the new node has a sufficiently diverse list of peers. Initiating Contact: A new node sends a PING message to a bootnode or a known peer. The PING contains: The Hashed Node ID (unique identifier of the node). The Bootnode ID (identifier of the target bootnode). An Expiry Timestamp (indicating the validity of the message). Initiating Contact: A new node sends a PING message to a bootnode or a known peer. The PING contains: The Hashed Node ID (unique identifier of the node). The Bootnode ID (identifier of the target bootnode). An Expiry Timestamp (indicating the validity of the message). A new node sends a PING message to a bootnode or a known peer. A new node sends a PING message to a bootnode or a known peer. PING The PING contains: The Hashed Node ID (unique identifier of the node). The Bootnode ID (identifier of the target bootnode). An Expiry Timestamp (indicating the validity of the message). The PING contains: PING The Hashed Node ID (unique identifier of the node). The Bootnode ID (identifier of the target bootnode). An Expiry Timestamp (indicating the validity of the message). The Hashed Node ID (unique identifier of the node). Hashed Node ID The Bootnode ID (identifier of the target bootnode). Bootnode ID An Expiry Timestamp (indicating the validity of the message). Expiry Timestamp Verification: The bootnode responds with a PONG message that includes the hash sent in the PING. If the hashes match, the connection is verified, and the nodes are considered bonded (trusted). Verification: The bootnode responds with a PONG message that includes the hash sent in the PING. If the hashes match, the connection is verified, and the nodes are considered bonded (trusted). The bootnode responds with a PONG message that includes the hash sent in the PING. The bootnode responds with a PONG message that includes the hash sent in the PING . PONG PING If the hashes match, the connection is verified, and the nodes are considered bonded (trusted). If the hashes match, the connection is verified, and the nodes are considered bonded (trusted). bonded Requesting Neighbors: Once bonded, the new node sends a FIND_NEIGHBOURS request to the bootnode. The bootnode replies with a list of neighboring peers (nodes that are close to the new node's ID in the network). Requesting Neighbors: Once bonded, the new node sends a FIND_NEIGHBOURS request to the bootnode. The bootnode replies with a list of neighboring peers (nodes that are close to the new node's ID in the network). Once bonded, the new node sends a FIND_NEIGHBOURS request to the bootnode. Once bonded, the new node sends a FIND_NEIGHBOURS request to the bootnode. FIND_NEIGHBOURS The bootnode replies with a list of neighboring peers (nodes that are close to the new node's ID in the network). The bootnode replies with a list of neighboring peers (nodes that are close to the new node's ID in the network). neighboring peers Bonding with Neighbors: The new node performs a PING-PONG exchange with each neighbor received from the bootnode. Successful exchanges bond the new node with these neighbors, allowing them to communicate. Bonding with Neighbors: The new node performs a PING-PONG exchange with each neighbor received from the bootnode. Successful exchanges bond the new node with these neighbors, allowing them to communicate. The new node performs a PING-PONG exchange with each neighbor received from the bootnode. The new node performs a PING-PONG exchange with each neighbor received from the bootnode. PING-PONG Successful exchanges bond the new node with these neighbors, allowing them to communicate. Successful exchanges bond the new node with these neighbors, allowing them to communicate. Expanding the Network: The new node repeats the process (PING, PONG, FIND_NEIGHBOURS) with newly bonded peers to discover additional nodes. This iterative process continues until the new node has a sufficiently diverse list of peers. Expanding the Network: The new node repeats the process (PING, PONG, FIND_NEIGHBOURS) with newly bonded peers to discover additional nodes. This iterative process continues until the new node has a sufficiently diverse list of peers. The new node repeats the process (PING, PONG, FIND_NEIGHBOURS) with newly bonded peers to discover additional nodes. This iterative process continues until the new node has a sufficiently diverse list of peers . sufficiently diverse list of peers Discv5 (Upcoming Protocol) Discv5 (Upcoming Protocol) Enhancements Over Discv4: Ethereum Node Records (ENR): A structured object introduced in Discv5 to manage identifying information. Key components of ENR include: Signature: A cryptographic hash of the record contents, ensuring data integrity. Sequence Number: Tracks updates to the ENR, enabling dynamic handling and prioritization of the latest records. Key-Value Pairs: Additional information like Node ID, IP address, supported protocols, and client type/version. Dynamic IP Handling: ENR supports nodes with changing IP addresses, improving network flexibility. Future-Proof Design: The ENR format is versatile, accommodating future changes in network structure. Additional Features: Nodes can advertise supported subprotocols, allowing for compatibility negotiation. Improved scalability and security using modern cryptographic techniques. Enhancements Over Discv4: Ethereum Node Records (ENR): A structured object introduced in Discv5 to manage identifying information. Key components of ENR include: Signature: A cryptographic hash of the record contents, ensuring data integrity. Sequence Number: Tracks updates to the ENR, enabling dynamic handling and prioritization of the latest records. Key-Value Pairs: Additional information like Node ID, IP address, supported protocols, and client type/version. Dynamic IP Handling: ENR supports nodes with changing IP addresses, improving network flexibility. Future-Proof Design: The ENR format is versatile, accommodating future changes in network structure. Enhancements Over Discv4: Enhancements Over Discv4: Ethereum Node Records (ENR): A structured object introduced in Discv5 to manage identifying information. Key components of ENR include: Signature: A cryptographic hash of the record contents, ensuring data integrity. Sequence Number: Tracks updates to the ENR, enabling dynamic handling and prioritization of the latest records. Key-Value Pairs: Additional information like Node ID, IP address, supported protocols, and client type/version. Dynamic IP Handling: ENR supports nodes with changing IP addresses, improving network flexibility. Future-Proof Design: The ENR format is versatile, accommodating future changes in network structure. Ethereum Node Records (ENR): A structured object introduced in Discv5 to manage identifying information. Key components of ENR include: Signature: A cryptographic hash of the record contents, ensuring data integrity. Sequence Number: Tracks updates to the ENR, enabling dynamic handling and prioritization of the latest records. Key-Value Pairs: Additional information like Node ID, IP address, supported protocols, and client type/version. Ethereum Node Records (ENR): A structured object introduced in Discv5 to manage identifying information. Key components of ENR include: Ethereum Node Records (ENR): Signature: A cryptographic hash of the record contents, ensuring data integrity. Sequence Number: Tracks updates to the ENR, enabling dynamic handling and prioritization of the latest records. Key-Value Pairs: Additional information like Node ID, IP address, supported protocols, and client type/version. Signature: A cryptographic hash of the record contents, ensuring data integrity. Signature: Sequence Number: Tracks updates to the ENR, enabling dynamic handling and prioritization of the latest records. Sequence Number: Key-Value Pairs: Additional information like Node ID, IP address, supported protocols, and client type/version. Key-Value Pairs: Dynamic IP Handling: ENR supports nodes with changing IP addresses, improving network flexibility. Dynamic IP Handling: ENR supports nodes with changing IP addresses, improving network flexibility. Dynamic IP Handling: Future-Proof Design: The ENR format is versatile, accommodating future changes in network structure. Future-Proof Design: The ENR format is versatile, accommodating future changes in network structure. Future-Proof Design: Additional Features: Nodes can advertise supported subprotocols, allowing for compatibility negotiation. Improved scalability and security using modern cryptographic techniques. Additional Features: Additional Features: Nodes can advertise supported subprotocols, allowing for compatibility negotiation. Improved scalability and security using modern cryptographic techniques. Nodes can advertise supported subprotocols, allowing for compatibility negotiation. Improved scalability and security using modern cryptographic techniques. Why ethereum discovery is built on UDP protocol over TCP protocol? The Ethereum discovery protocol uses UDP because it's fast and simple, without the need for setting up connections or handling errors. This makes it perfect for quickly finding other nodes in the network. UDP just sends information efficiently without waiting for confirmation. For more detailed tasks, like syncing data, Ethereum uses TCP, which ensures reliable communication with features like error checking and resending data if something goes wrong. This way, Ethereum uses UDP for speed during discovery and TCP for reliability during data exchange. Why ethereum discovery is built on UDP protocol over TCP protocol? Why ethereum discovery is built on UDP protocol over TCP protocol? The Ethereum discovery protocol uses UDP because it's fast and simple, without the need for setting up connections or handling errors. This makes it perfect for quickly finding other nodes in the network. UDP just sends information efficiently without waiting for confirmation. For more detailed tasks, like syncing data, Ethereum uses TCP, which ensures reliable communication with features like error checking and resending data if something goes wrong. This way, Ethereum uses UDP for speed during discovery and TCP for reliability during data exchange. Establishing Connections Establishing Connections After discovering peers, Ethereum nodes use the DevP2P stack , starting with the RLPx protocol to establish secure communication. DevP2P stack RLPx protocol RLPx is a key protocol in Ethereum's DevP2P stack that helps nodes connect and communicate securely. It uses RLP (Recursive Length Prefix) encoding to compress and organize data efficiently for transmission. The protocol ensures encrypted and authenticated communication, creating a secure connection between nodes. Once this connection is established, nodes can interact using various subprotocols for exchanging blockchain data or for syncing state, enabling smooth and reliable network operations. RLP (Recursive Length Prefix) RLPx Protocol RLPx Protocol Cryptographic Handshake: The nodes exchange public keys and initiate encryption using ECIES (Elliptic Curve Integrated Encryption Scheme). This generates a shared secret, ensuring secure communication between the nodes. Hello Exchange: Following the handshake, the nodes send "hello" messages containing key details, including: Supported subprotocols. Client version. Node ID. Port and protocol version information. This allows both nodes to identify each other's capabilities and set up a compatible connection. Session Maintenance: Ping/Pong Messages: Periodic "ping" messages are sent to confirm the peer's availability, and the receiving node replies with a "pong" message. This ensures that the session stays active and maintains the connection. Disconnect Message: If a node intends to terminate the session, it can send a "disconnect" message to the peer, notifying them of the upcoming disconnection. This is a polite way of closing the connection gracefully. Cryptographic Handshake: The nodes exchange public keys and initiate encryption using ECIES (Elliptic Curve Integrated Encryption Scheme). This generates a shared secret, ensuring secure communication between the nodes. Cryptographic Handshake : The nodes exchange public keys and initiate encryption using ECIES (Elliptic Curve Integrated Encryption Scheme). This generates a shared secret, ensuring secure communication between the nodes. Cryptographic Handshake ECIES Hello Exchange: Following the handshake, the nodes send "hello" messages containing key details, including: Supported subprotocols. Client version. Node ID. Port and protocol version information. This allows both nodes to identify each other's capabilities and set up a compatible connection. Hello Exchange : Following the handshake, the nodes send "hello" messages containing key details, including: Hello Exchange Supported subprotocols. Client version. Node ID. Port and protocol version information. This allows both nodes to identify each other's capabilities and set up a compatible connection. Supported subprotocols. Supported subprotocols. Client version. Client version. Node ID. Node ID. Port and protocol version information. This allows both nodes to identify each other's capabilities and set up a compatible connection. Port and protocol version information. This allows both nodes to identify each other's capabilities and set up a compatible connection. Session Maintenance: Ping/Pong Messages: Periodic "ping" messages are sent to confirm the peer's availability, and the receiving node replies with a "pong" message. This ensures that the session stays active and maintains the connection. Disconnect Message: If a node intends to terminate the session, it can send a "disconnect" message to the peer, notifying them of the upcoming disconnection. This is a polite way of closing the connection gracefully. Session Maintenance : Session Maintenance Ping/Pong Messages: Periodic "ping" messages are sent to confirm the peer's availability, and the receiving node replies with a "pong" message. This ensures that the session stays active and maintains the connection. Ping/Pong Messages : Periodic "ping" messages are sent to confirm the peer's availability, and the receiving node replies with a "pong" message. This ensures that the session stays active and maintains the connection. Ping/Pong Messages Disconnect Message: If a node intends to terminate the session, it can send a "disconnect" message to the peer, notifying them of the upcoming disconnection. This is a polite way of closing the connection gracefully. Disconnect Message : If a node intends to terminate the session, it can send a "disconnect" message to the peer, notifying them of the upcoming disconnection. This is a polite way of closing the connection gracefully. Disconnect Message Sub-Protocols within DevP2P stack: Sub-Protocols within DevP2P stack: Transaction and Data Exchange After nodes are connected, the wire protocol manages how they communicate. It originally handled tasks like: Syncing chains: Ensuring all nodes are up-to-date with the blockchain. Propagating blocks: Sharing new blocks across the network. Exchanging transactions: Sharing pending transactions between nodes for future blocks. However, with Ethereum's shift to Proof of Stake (PoS), syncing blocks and chain data is now part of the consensus layer, while transaction exchange continues under execution clients. Light Ethereum Subprotocol (LES) The LES protocol is for light clients, which are nodes that don’t store the whole blockchain. They rely on full nodes to provide data when needed. Light clients save space and resources, but they depend on full nodes to share information with them. However, because full nodes aren’t incentivized to serve light clients, LES has not been used much. Snap Protocol The Snap protocol is an extension that helps Ethereum nodes exchange state snapshots (recent data states). This allows nodes to verify accounts and storage without downloading too much data, speeding up the process of syncing with the network. Witness Protocol (Wit) The Witness Protocol lets Ethereum nodes share state witnesses, helping them stay updated with the latest blockchain state. This is especially useful for clients syncing to the latest block, reducing the amount of data they need to download. Whisper Protocol (Deprecated) The Whisper protocol was designed for secure messaging between nodes, without storing any messages on the blockchain. However, it had problems with scalability and wasn’t widely adopted. As a result, it has been deprecated, and other projects are now working on similar secure messaging solutions. Transaction and Data Exchange After nodes are connected, the wire protocol manages how they communicate. It originally handled tasks like: Syncing chains: Ensuring all nodes are up-to-date with the blockchain. Propagating blocks: Sharing new blocks across the network. Exchanging transactions: Sharing pending transactions between nodes for future blocks. However, with Ethereum's shift to Proof of Stake (PoS), syncing blocks and chain data is now part of the consensus layer, while transaction exchange continues under execution clients. Transaction and Data Exchange Transaction and Data Exchange After nodes are connected, the wire protocol manages how they communicate. It originally handled tasks like: Syncing chains: Ensuring all nodes are up-to-date with the blockchain. Propagating blocks: Sharing new blocks across the network. Exchanging transactions: Sharing pending transactions between nodes for future blocks. Syncing chains: Ensuring all nodes are up-to-date with the blockchain. Syncing chains : Ensuring all nodes are up-to-date with the blockchain. Syncing chains Propagating blocks: Sharing new blocks across the network. Propagating blocks : Sharing new blocks across the network. Propagating blocks Exchanging transactions: Sharing pending transactions between nodes for future blocks. Exchanging transactions : Sharing pending transactions between nodes for future blocks. Exchanging transactions However, with Ethereum's shift to Proof of Stake (PoS) , syncing blocks and chain data is now part of the consensus layer , while transaction exchange continues under execution clients . Proof of Stake (PoS) consensus layer execution clients Light Ethereum Subprotocol (LES) The LES protocol is for light clients, which are nodes that don’t store the whole blockchain. They rely on full nodes to provide data when needed. Light clients save space and resources, but they depend on full nodes to share information with them. However, because full nodes aren’t incentivized to serve light clients, LES has not been used much. Light Ethereum Subprotocol (LES) Light Ethereum Subprotocol (LES) The LES protocol is for light clients , which are nodes that don’t store the whole blockchain. They rely on full nodes to provide data when needed. Light clients save space and resources, but they depend on full nodes to share information with them. However, because full nodes aren’t incentivized to serve light clients, LES has not been used much. LES light clients full nodes LES Snap Protocol The Snap protocol is an extension that helps Ethereum nodes exchange state snapshots (recent data states). This allows nodes to verify accounts and storage without downloading too much data, speeding up the process of syncing with the network. Snap Protocol Snap Protocol The Snap protocol is an extension that helps Ethereum nodes exchange state snapshots (recent data states). This allows nodes to verify accounts and storage without downloading too much data, speeding up the process of syncing with the network. Snap state snapshots Witness Protocol (Wit) The Witness Protocol lets Ethereum nodes share state witnesses, helping them stay updated with the latest blockchain state. This is especially useful for clients syncing to the latest block, reducing the amount of data they need to download. Witness Protocol (Wit) Witness Protocol (Wit) The Witness Protocol lets Ethereum nodes share state witnesses , helping them stay updated with the latest blockchain state. This is especially useful for clients syncing to the latest block, reducing the amount of data they need to download. Witness Protocol state witnesses Whisper Protocol (Deprecated) The Whisper protocol was designed for secure messaging between nodes, without storing any messages on the blockchain. However, it had problems with scalability and wasn’t widely adopted. As a result, it has been deprecated, and other projects are now working on similar secure messaging solutions. Whisper Protocol (Deprecated) Whisper Protocol (Deprecated) The Whisper protocol was designed for secure messaging between nodes, without storing any messages on the blockchain. However, it had problems with scalability and wasn’t widely adopted. As a result, it has been deprecated , and other projects are now working on similar secure messaging solutions. Whisper secure messaging deprecated The Consensus Layer The Consensus Layer The Ethereum consensus layer ensures that all Ethereum nodes agree on the state of the blockchain, keeping everything in sync. It works separately from the execution layer (where transactions are executed) but needs to interact closely with it. Ethereum consensus layer Peer Discovery Peer Discovery Just like the execution clients, the consensus clients need a way to discover other nodes (peers) in the network. They use a protocol called discV5 over UDP . This is different from the old DevP2P system and integrates libP2P , a newer and more flexible technology. discV5 UDP DevP2P libP2P Ethereum Node Records (ENR) for Consensus Nodes Ethereum Node Records (ENR) for Consensus Nodes Each consensus node in the Ethereum network has an Ethereum Node Record (ENR) , which helps other nodes identify and connect to it. The ENR contains: consensus node Ethereum Node Record (ENR) Public Key: The node’s cryptographic key for secure communication. IP Address: The node’s internet address. UDP and TCP Ports: These specify which ports the node listens to for communication over UDP and TCP. Attestation Subnet Bitfield: This field helps nodes find others that are involved in attestation gossip, making it easier to sync with peers that are part of specific attestation sub-networks. Eth2 Key: This identifies which Ethereum fork version the node is using. It ensures that nodes only connect to peers running the correct Ethereum version, keeping everything compatible and synchronized. Public Key : The node’s cryptographic key for secure communication. Public Key IP Address : The node’s internet address. IP Address UDP and TCP Ports : These specify which ports the node listens to for communication over UDP and TCP . UDP and TCP Ports UDP TCP Attestation Subnet Bitfield : This field helps nodes find others that are involved in attestation gossip , making it easier to sync with peers that are part of specific attestation sub-networks. Attestation Subnet Bitfield attestation gossip Eth2 Key : This identifies which Ethereum fork version the node is using. It ensures that nodes only connect to peers running the correct Ethereum version, keeping everything compatible and synchronized. Eth2 Key fork version LibP2P: The Communication Backbone LibP2P: The Communication Backbone After discovering peers, the consensus layer uses libP2P to keep the communication going. It uses two main methods for communication: libP2P Gossip: This helps spread important updates like new blocks and attestations quickly across the network. It’s like passing a note between people in class, making sure everyone gets the same information fast. Request-Response: This is a more specific way for one node to ask another for particular data, like a block with certain information. It’s like requesting a copy of a specific page from a book. Gossip: This helps spread important updates like new blocks and attestations quickly across the network. It’s like passing a note between people in class, making sure everyone gets the same information fast. Gossip : This helps spread important updates like new blocks and attestations quickly across the network. It’s like passing a note between people in class, making sure everyone gets the same information fast. Gossip Request-Response: This is a more specific way for one node to ask another for particular data, like a block with certain information. It’s like requesting a copy of a specific page from a book. Request-Response : This is a more specific way for one node to ask another for particular data, like a block with certain information. It’s like requesting a copy of a specific page from a book. Request-Response Why SSZ for Consensus? Why SSZ for Consensus? In Ethereum's consensus layer, SSZ (Simple Serialization) is used instead of the usual RLP (Recursive Length Prefix) format. This is because SSZ is faster and more efficient when dealing with large data and makes it easier to verify information in Merkle trees, which are used to keep the blockchain secure. SSZ (Simple Serialization) RLP (Recursive Length Prefix) faster and more efficient Connecting Execution and Consensus Clients Connecting Execution and Consensus Clients The execution layer (which processes transactions) and the consensus layer (which secures the blockchain) need to talk to each other. This happens through a local RPC connection . They share a common Ethereum Node Record (ENR) , which keeps track of information like the client's public key and which layer it belongs to. execution layer consensus layer local RPC connection Ethereum Node Record (ENR) When consensus client is not block producer: When consensus client is not block producer: Consensus client receives a block via the block gossip protocol (consensus p2p) Consensus client pre-validates the block, i.e. ensures it arrived from a valid sender with correct metadata The transactions in the block are sent to the execution layer as an execution payload (local RPC connection) The execution layer executes the transactions and validates the state in the block header (i.e. checks hashes match) Execution layer passes validation data back to consensus layer, block now considered to be validated (local RPC connection) Consensus layer adds block to head of its own blockchain and attests to it, broadcasting the attestation over the network (consensus p2p) Consensus client receives a block via the block gossip protocol (consensus p2p) Consensus client pre-validates the block, i.e. ensures it arrived from a valid sender with correct metadata The transactions in the block are sent to the execution layer as an execution payload (local RPC connection) The execution layer executes the transactions and validates the state in the block header (i.e. checks hashes match) Execution layer passes validation data back to consensus layer, block now considered to be validated (local RPC connection) Consensus layer adds block to head of its own blockchain and attests to it, broadcasting the attestation over the network (consensus p2p) When consensus client is block producer: When consensus client is block producer: Consensus client receives notice that it is the next block producer (consensus p2p) Consensus layer calls create block method in execution client (local RPC) Execution layer accesses the transaction mempool which has been populated by the transaction gossip protocol (execution p2p) Execution client bundles transactions into a block, executes the transactions and generates a block hash Consensus client grabs the transactions and block hash from the execution client and adds them to the beacon block (local RPC) Consensus client broadcasts the block over the block gossip protocol (consensus p2p) Other clients receive the proposed block via the block gossip protocol and validate as described above (consensus p2p) Consensus client receives notice that it is the next block producer (consensus p2p) Consensus layer calls create block method in execution client (local RPC) create block Execution layer accesses the transaction mempool which has been populated by the transaction gossip protocol (execution p2p) Execution client bundles transactions into a block, executes the transactions and generates a block hash Consensus client grabs the transactions and block hash from the execution client and adds them to the beacon block (local RPC) Consensus client broadcasts the block over the block gossip protocol (consensus p2p) Other clients receive the proposed block via the block gossip protocol and validate as described above (consensus p2p) References: Ethereum Networking Layer Documentation From Kademlia to Discv5 Overview of Kademlia in Decentralized Platforms References: References: Ethereum Networking Layer Documentation Ethereum Networking Layer Documentation From Kademlia to Discv5 From Kademlia to Discv5 Overview of Kademlia in Decentralized Platforms Overview of Kademlia in Decentralized Platforms