You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have defined a transaction exchange protocol that I believe is quite efficient. As the project matures, we should properly document these protocol decisions.
Upon successful connection on the base network layer, the node layer marks a peer as active & sends his memory pool content as bloom filter.
Upon reception of a memory pool bloom filter, a peer creates a list of transaction IDs he has that are not part of the bloom filter and replies with that inventory.
Upon reception of an inventory of transaction IDs, a peer checks which of transaction IDs he still doesn't have and requests them from other peers.
Upon reception of a request of transaction IDs, a peer sends those transactions in his reply.
Currently, the bloom filter uses a false positive ratio of 1%. This leaves us with a 0.01% chance of missing a transaction if we are connected to even just two peers. That should be fine, but we have to verify whether the hash functions of the bloom filter are randomly initialized so that we don't deterministically reproduce the same bloom filter for the same memory pool.
We should also add a queue of pending transaction downloads between step 3) and 4), so that a node requests transactions evenly from all peers, taking into account their reply speed as well.
The text was updated successfully, but these errors were encountered:
The transaction exchange protocol needs to be improved to handle the case of bootstrapping nodes. As we don't have the notion of exchanging blocks, but only block candidates plus requesting the missing transactions, we need a way to request transactions that are part of the consensus state already (outside of the memory pool).
A decent approach would be to include our current parent hash in the bloom filter exchange and include all transactions in blocks after that hash in the bloom filter. From the perspective of the requester, these transactions are equivalent of not being part of the state yet anyway.
awfm9
changed the title
Transaction exchange protocol
Mempool synchronization
Mar 15, 2018
awfm9
changed the title
Mempool synchronization
Memory pool synchronization protocol
Mar 15, 2018
I have defined a transaction exchange protocol that I believe is quite efficient. As the project matures, we should properly document these protocol decisions.
Upon successful connection on the base network layer, the node layer marks a peer as active & sends his memory pool content as bloom filter.
Upon reception of a memory pool bloom filter, a peer creates a list of transaction IDs he has that are not part of the bloom filter and replies with that inventory.
Upon reception of an inventory of transaction IDs, a peer checks which of transaction IDs he still doesn't have and requests them from other peers.
Upon reception of a request of transaction IDs, a peer sends those transactions in his reply.
Currently, the bloom filter uses a false positive ratio of 1%. This leaves us with a 0.01% chance of missing a transaction if we are connected to even just two peers. That should be fine, but we have to verify whether the hash functions of the bloom filter are randomly initialized so that we don't deterministically reproduce the same bloom filter for the same memory pool.
We should also add a queue of pending transaction downloads between step 3) and 4), so that a node requests transactions evenly from all peers, taking into account their reply speed as well.
The text was updated successfully, but these errors were encountered: