mirror of https://github.com/luxfi/node.git synced 2026-10-30 15:24:05 +00:00

Files

T

zeekay 7cf87b230b node-unified is the node

The module already called itself github.com/luxfi/node while containing no node
in Go: cmd/luxd was twenty-one lines that printed the size of a few types, and
the Go column of the matrix measured a VM plugin. A repo that fetches the thing
it claims to be has not replaced it, so the Go sources move in — 1515 files,
the daemon and everything under it — and the build reaches outside this module
for nothing.

Rust and C++ sit beside it unchanged and are still measured against it by the
differential. That is the point of one repo: the reference implementation and
the two ports are the same checkout, so parity is a thing you can run rather
than a thing you assert.

Verified: builds, and the closure carries no lux-private — checked at build time
rather than believed. The daemon starts twelve chains on a local network
(P X C Q Z A B G K M F, plus D through its plugin) and reports healthy.

2026-09-07 16:15:25 -07:00

2.3 KiB

Raw Permalink Blame History

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.

2.3 KiB Raw Permalink Blame History

Mempool Gossiping

Mempool Gossiping Workflow

2.3 KiB

Raw Permalink Blame History