Mempool/TX-pool synchronization
Last updated
Was this helpful?
Last updated
Was this helpful?
On startup the æternity node needs to update (or get from scratch if it is a completely new node) its list of unconfirmed transactions. New transactions it will get through gossip, but by construction older transactions that (for some reason) have not made it onto the chain is not gossiped.
Potentially there is a big overlap between the list of transactions held by the starting node (transactions are persisted) and the peer it is synchronizing with; thus to save network bandwidth it is preferable to only send the missing transactions. The protocol is straightforward:
the node picks one peer to synchronize with
they each create a MP tree holding their local transactions - In the MP tree, each element has as key the hash of the signed transaction and as (placeholder) value the empty list.
the initiator asks for a partial unfolding of the peer's tree
the initiator computes what parts of the tree it doesn't know about and either goes back to 3. and asks for further information, or
the initiator asks for the missing transactions.
The P2P messages used are listed in .
The instructions for unfolding an MP tree are sent over the P2P protocol, thus
they need to be serialized. There are four different messages sent, they are
listed below. Except for the types mentioned in we also use the type path which is path to
a node in an MP-tree, thus it could be an even or odd number of nibbles. RLP
require an even number of nibbles, i.e. whole bytes, so we pad with a parity:
even number of nibbles add byte with 0
odd number of nibbles add a nibble with value 1
The result is an even number of nibbles and the first nibble indicate how it should be deserialized.
Message is RLP encoded, fields:
type :: int = 0
path :: path
node :: byte_array
Message is RLP encoded, fields:
type :: int = 1
leaf :: path
Message is RLP encoded, fields:
type :: int = 2
subtree :: path
Message is RLP encoded, fields:
type :: int = 3
key :: byte_array