platformvm/docs/mempool_gossiping.md

Mempool Gossiping

The PlatformVM has a mempool which tracks unconfirmed transactions that are waiting to be issued into blocks. The mempool is volatile, i.e. it does not persist unconfirmed transactions.

In conjunction with the introduction of Linear++, the mempool was opened to the network, allowing the gossiping of local transactions as well as the hosting of remote ones.

Mempool Gossiping Workflow

The PlatformVM's mempool performs the following workflow:

• An unconfirmed transaction is provided to node A, either through mempool gossiping or direct issuance over an RPC. If this transaction isn't already in the local mempool, the transaction is issued into the mempool.
• When node A issues a new transaction into its mempool, it will gossip the transaction ID by sending an Gossip message. The node's engine will randomly select peers (currently defaulting to 6 nodes) to send the Gossip message to.
• When node B learns about the existence of a remote transaction ID, it will check if its mempool contains the transaction or if it has been recently dropped. If the transaction ID is not known, node B will generate a new requestID and respond with an Request message with the unknown transaction's ID. node B will track the content of the request issued with requestID for response verification.
• Upon reception of an Request message, node A will attempt to fetch the transaction requested in the Request message from its mempool. Note that a transaction advertised in an Gossip message may no longer be in the mempool, because they may have been included into a block, rejected, or dropped. If the transaction is retrieved, it is encoded into an Response message. The Response message will carry the same requestID of the originating Request message and it will be sent back to node B.
• If node B receives an Response message, it will decode the transaction and verifies that the ID matches the expected content from the original Request message. If the content matches, the transaction is validated and issued into the mempool.
• If nodeB's engine decides it isn't likely to receive an Response message, the engine will issue an RequestFailure message. In such a case node B will mark the requestID as failed and the request for the unknown transaction is aborted.