Introduction

Our P2P works using a packet system from scratch where we assign a byte id to each packet. Every packet listed below is shared in a secure TCP connection with a remote peer with full encryption.

These packets allows for easier communication / sharing data between peers in the XELIS Network by having a defined architecture while trying to reduce as much as possible its overhead.

This part explains all packets used in the XELIS network to communicate over P2p.

Key Exchange

Key Exchange is the first real packet being sent when creating a new connection. This allow exchanging public keys for Diffie-Hellman key exchange between peer to establish an encrypted communication channel over TCP.

But it is also used to rotate the encryption key from a peer by updating the local encryption state by sharing the new encryption key to use, being encrypted by the previous encryption key if any.

Handshake

The handshake packet must be the first packet sent with the blockchain state inside to upgrade a connection to a peer. If valid, the peer will send the same packet with is own blockchain state.

This packet is only sent one time, and at the beginning of a connection once the secure communication has been established.

Transaction Propagation

The transaction propagation packet contains the hash only to prevent sending the TX. Its also backed by a cache per peer to know if the transaction had already been sent/received.

Block Propagation

The block propagation packet contains the block header only. Its sent to all peers who have their height minus our height less than STABLE_LIMIT. To build the block, transactions are retrieved from the mempool. If a transaction is not found in the mempool, the local node requests it from the same peer in order to build it.

Chain Request

This packet is sent to a peer to request a chain sync. It contains a maximum allowed response size and the last CHAIN_SYNC_REQUEST_MAX_BLOCKS blocks hashes of the local node's chain with their topoheight spaced exponentially.

Chain Response

This packet is sent to a peer in response to a chain request. It contains the last CHAIN_SYNC_RESPONSE_MAX_BLOCKS blocks hashes of the peer's chain ordered by block topoheight.

Only block hashes are sent in this packet, allowing a peer to request the full block if don't have any block matching the hash. It also prevent any DDoS attack by sending a lot of blocks to a peer or having high bandwidth usage during high traffic. Blocks are requested one by one to the peer to prevent any overload and controling the memory and network usage.

Ping

The ping packet is sent at an regular interval and informs peers of the local node's blockchain state. Every 15 minutes, the packet can contain up to MAX_LEN sockets addresses (IPv4 or IPv6) to help others nodes to extends their peer lists.

Object Request

This packet is sent to a peer to request an object (block header, full block or transaction) by its hash. It is mainly used for chain synchronization, block / transaction propagation.

Object Response

This packet is sent to a peer in response to an object request. It contains the requested object (block header, full block or transaction) or the requested hash if the object was not found.

Notify Inventory Request

Inventory request packet is requested when we've connected to a new synced peer or when we've finished to sync the chain with the peer. It is used to request the mempool of the peer to have the same transactions in the mempool.

The inventory is paginated using one (optional) byte that contains the page number.

Notify Inventory Response

Inventory response packet is sent in response to an inventory request. It contains the list of all transactions hashes from the mempool of the peer.

An optional byte is used to indicate if the inventory is paginated and if there are more pages to request.

Bootstrap Chain Request

Bootstrap chain request packet is a specific packet that is split in several sub-variants to efficiently request the top chain state from a peer.

This packet should be used only with a trusted peer, to prevent any bad behavior that could occurs (like sending fake datas, etc).

Requests variants must follow the following proceed:

• Chain Info: The chain info contains the chain state (common point, stable height, stable topoheight, stable hash, etc)
• Assets: retrieve all assets present in the chain
• Keys: all accounts registered in the chain
• Nonces: nonce of each account
• Balances: all balances summary of the accounts for a specific asset
• Balances Details: all balances details of the accounts for a specific asset
• Blocks metadata: 80 blocks below stable topoheight containing hash, supply, reward, difficulty, cumulative difficulty, difficulty P variable.

Bootstrap Chain Response

Bootsrap chain response contains all the needed data to bootstrap the chain from a peer.

It is split in several sub-variants to efficiently request each part of the chain.

Disconnect

The disconnect packet is sent when a peer is disconnected from the local node and we have it in common with another peer.

This is used to keep synced the "propagation map predicate".