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 Snowman++, the mempool was opened to the network, allowing the gossiping of local transactions as well as the hosting of remote ones.
The PlatformVM's mempool performs the following workflow:
- An unconfirmed transaction is provided to
node A
, either through mempool gossiping or direct issuance over a 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 anAppGossip
message. The node's engine will randomly select peers (currently defaulting to6
nodes) to send theAppGossip
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 newrequestID
and respond with anAppRequest
message with the unknown transaction's ID.node B
will track the content of the request issued withrequestID
for response verification. - Upon reception of an
AppRequest
message,node A
will attempt to fetch the transaction requested in theAppRequest
message from its mempool. Note that a transaction advertised in anAppGossip
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 anAppResponse
message. TheAppResponse
message will carry the samerequestID
of the originatingAppRequest
message and it will be sent back tonode B
. - If
node B
receives anAppResponse
message, it will decode the transaction and verifies that the ID matches the expected content from the originalAppRequest
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 anAppResponse
message, the engine will issue anAppRequestFailure
message. In such a casenode B
will mark therequestID
as failed and the request for the unknown transaction is aborted.