> For the complete documentation index, see [llms.txt](https://docs.aeternity.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.aeternity.com/developer-documentation/protocol/sync-1/p2p_messages.md).

# P2P messages

P2P messages are transported using the [Noise\
protocol](https://noiseprotocol.org/). Since each message in the Noise protocol\
is limited to (65536 - 2) bytes we sometimes have to fragment larger messages\
(in particular blocks and transaction pool-chunks). On top of this we use a\
simple message format, where 2 bytes (16 bits) are used for a big-endian encoded\
message type integer followed by the payload for the particular message. Since\
Noise (and the fragmentation) handle message size we need no length field. The\
payload is a byte array, and messages are either fixed binary data or encoded\
using [RLP](https://github.com/ethereum/wiki/wiki/RLP).

The following P2P messages are implemented in\
the [æternity node](https://github.com/aeternity/aeternity/blob/master/apps/aecore/src/aec_peer_messages.erl):

* [MSG\_FRAGMENT](#msg_fragment)
* [MSG\_P2P\_RESPONSE](#msg_p2p_response)
* [MSG\_PING](#msg_ping)
* [MSG\_GET\_HEADER\_BY\_HASH](#msg_get_header_by_hash)
* [MSG\_GET\_HEADER\_BY\_HEIGHT](#msg_get_header_by_height)
* [MSG\_HEADER](#msg_header)
* [MSG\_GET\_N\_SUCCESSORS](#msg_get_n_successors)
* [MSG\_HEADER\_HASHES](#msg_header_hashes)
* [MSG\_GET\_BLOCK\_TXS](#msg_get_block_txs)
* [MSG\_GET\_GENERATION](#msg_get_generation)
* [MSG\_TXS](#msg_txs)
* [MSG\_BLOCK\_TXS](#msg_block_txs)
* [MSG\_KEY\_BLOCK](#msg_key_block)
* [MSG\_MICRO\_BLOCK](#msg_micro_block)
* [MSG\_GENERATION](#msg_generation)
* [MSG\_TX\_POOL\_SYNC\_INIT](#msg_tx_pool_sync_init)
* [MSG\_TX\_POOL\_SYNC\_UNFOLD](#msg_tx_pool_sync_unfold)
* [MSG\_TX\_POOL\_SYNC\_GET](#msg_tx_pool_sync_get)
* [MSG\_TX\_POOL\_SYNC\_FINISH](#msg_tx_pool_sync_finish)
* [MSG\_GET\_NODE\_INFO](#msg_get_node_info)
* [MSG\_NODE\_INFO](#msg_node_info)
* [MSG\_CLOSE](#msg_close)

Each message type (except for `MSG_FRAGMENT`) is versioned such that the\
message can easily be changed while still maintaining backwards compatibility\
by adding logic to handle several versions of a message.

## Types

In the following we use some types to abbreviate the documentation here is how\
various types should be interpreted (corresponds to their encoding):

* `uint16` - 16 bit, big endian unsigned integer.
* `byte_array` - variable sized byte array (either the last field in a\
  static message or RLP encoded).
* `bool` - representing `true` or `false` - encoded as 0 or 1.
* `int` - variable (RLP encoded) integer
* `[X]` - variable (RLP encoded) list of `X`:s

## MSG\_FRAGMENT

*(Tag = 0)*

Fields:

* `N :: uint16` - fragment N of M
* `M :: uint16` - total number of fragments
* `Data :: byte_array`

*NOTE:* Data is either (65536 - 6) bytes or `N` is equal to `M`.

## MSG\_P2P\_RESPONSE

*(Tag = 100)*

Message is RLP encoded, fields:

* `Result :: bool` - `true` means ok, `false` means error.
* `Type :: int` - the type of the response
* `Reason :: byte_array` - Human readable (UTF8) reason (only set\
  if Result is `false`)\*
* `Object :: byte_array` - an object of type `Type` if Result is `true`.

## MSG\_PING

*(Tag = 1)*

Message is RLP encoded, fields:

### Version 1

* `Port :: int` - listen port.
* `Share :: int` - number of peers to share.
* `GenesisHash :: byte_array`
* `Difficulty :: int` - the total difficulty of the chain.
* `TopHash :: byte_array`
* `SyncAllowed :: bool` - if the sender of this ping message is accepting\
  synchronization messages.
* `Peers :: [byte_array]` - list of shared peers.

### Version 2

* `Versions :: list`
  * `Protocol :: binary` - type of message, currently only "ping" is supported.
  * `Vsns :: [int]` - versions supported
* `Port :: int` - listen port.
* `Share :: int` - number of peers to share.
* `GenesisHash :: byte_array`
* `Height :: int` - current height.
* `Difficulty :: int` - the total difficulty of the chain.
* `TopHash :: byte_array`
* `SyncAllowed :: bool` - if the sender of this ping message is accepting\
  synchronization messages.
* `Capabilities :: byte_array` - list of supported capabilites.
* `Peers :: [byte_array]` - list of shared peers.

Peers are serialized/deserialized in `aec_peer_messages`

## MSG\_GET\_HEADER\_BY\_HASH

*(Tag = 3)*

Message is RLP encoded, fields:

* `Hash :: byte_array`

## MSG\_GET\_HEADER\_BY\_HEIGHT

*(Tag = 15)*

Message is RLP encoded, fields:

* `Height :: int`
* `TopHash :: byte_array` - to ensure we get a header at height from the right fork

## MSG\_HEADER

*(Tag = 4)*

Message is RLP encoded, fields:

* `Header :: byte_array`

The Header is serialized using the`aec_headers:serialize_to_binary/1` function.

## MSG\_GET\_N\_SUCCESSORS

*(Tag = 5)*

Message is RLP encoded, fields:

* `FromHash :: byte_array` - header hash to start at
* `TargetHash :: byte_array` - target header hash (to ensure we get headers from the right fork)
* `N :: int` - number of header hashes to get

## MSG\_HEADER\_HASHES

*(Tag = 6)*

Message is RLP encoded, fields:

* `HeaderHashes :: [byte_array]`

Each header hash contains a 64-bit big endian height and the corresponding\
hash, see `aec_peer_messages` for details.

## MSG\_GET\_BLOCK\_TXS

*(Tag = 7)*

Message is RLP encoded, fields:

* `Hash :: byte_array - The block we fetch TXs from`
* `TxHashes :: [byte_array] - List of TxHashes to fetch TXs for`

## MSG\_GET\_GENERATION

*(Tag = 8)*

Message is RLP encoded, fields:

* `Hash :: byte_array`
* `Forward :: bool`

## MSG\_TXS

*(Tag = 9)*

Message is RLP encoded, fields:

* `Txs:: [byte_array]`

A signed transaction is serialized as a tagged and versioned[signed transaction](/developer-documentation/protocol/serializations.md#signed-transaction).

## MSG\_BLOCK\_TXS

\*(Tag = 13)

Message is RLP encoded, fields:

* `Hash :: byte_array - The block we fetch TXs from`
* `Txs :: [byte_array] - List of serialized signed TXs`

A signed transaction is serialized as a tagged and versioned[signed transaction](/developer-documentation/protocol/serializations.md#signed-transaction).

## MSG\_KEY\_BLOCK

\*(Tag = 10)

Message is RLP encoded, fields:

* `KeyBlock :: byte_array - Serialized key block`

The key block is [serialized](/developer-documentation/protocol/serializations.md#key-block).

## MSG\_MICRO\_BLOCK

\*(Tag = 11)

Message is RLP encoded, fields:

* `MicroBlock :: byte_array - Serialized micro block`
* `Light :: bool - flag if micro block is light or normal`

A normal micro block is [serialized](/developer-documentation/protocol/serializations.md#micro-block).\
A light micro block is serialized using`aec_peer_connection:serialize_light_micro_block/1` - in effect replacing the\
list of serialized signed transactions with a list of transaction hashes.

## MSG\_GENERATION

*(Tag = 12)*

Message is RLP encoded, fields:

* `KeyBlock :: byte_array`
* `MicroBlocks :: [byte_array]`
* `Forward :: bool`

The key block and each of the microblocks are serialized using the `aec_blocks:serialize_to_binary/1` function.

## MSG\_TX\_POOL\_SYNC\_INIT

*(Tag = 20)*

Message has no body.

## MSG\_TX\_POOL\_SYNC\_UNFOLD

*(Tag = 21)*

Message is RLP encoded, fields:

* `Unfolds :: [byte_array]`

Unfolds are serialized in `aec_tx_pool_sync` - the serialization is described in\
\[tx\_pool\_sync])(./tx\_pool\_sync.md).

## MSG\_TX\_POOL\_SYNC\_GET

*(Tag = 22)*

Message is RLP encoded, fields:

* `TxHashes :: [byte_array]`

## MSG\_TX\_POOL\_SYNC\_FINISH

*(Tag = 23)*

Message is RLP encoded, fields:

* `Done :: bool`

## MSG\_GET\_NODE\_INFO

*(Tag = 125)*

This message has no fields.

This is to be used for network monitoring.

## MSG\_NODE\_INFO

*(Tag = 126)*

Message is RLP encoded, fields:

* `Version` :: byte\_array - the version of the node
* `Revision` :: byte\_array - the revision of the node
* `Vendor` :: byte\_array - a string to differentiate between different protocol implementations
* `OS` :: byte\_array - the operating system the node is being ran
* `NetworkId` :: byte\_array - the node's expectation of the `network_id`. This has heavy impact on authentication validations
* `VerifiedPeers` :: integer - the amount of peers the node consideres to be verified
* `UnverifiedPeers` :: integer - the amount of peers the node consideres to be unverified

This message is the response for the [MSG\_GET\_NODE\_INFO](#msg_get_node_info)\
message. It is important to note that responding to it is not required by the\
p2p protocol as a peer might prefer keeping this information private.

## MSG\_CLOSE

*(Tag = 127)*

This message has no fields.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.aeternity.com/developer-documentation/protocol/sync-1/p2p_messages.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.