overview

two families of data propagate throughout millix:

1. transaction data: transferring millix from a sender to a recipient

2. network data: information about the nodes participating on the millix network

transaction data propagates through the network to be received by the recipient and stored by all the nodes supporting the shard that the transaction is associated with. network data describes attributes of nodes, such as what shards they support, how often they prune data, how many peers they are connected to and other information that describe themselves for other nodes to consider.

data propagation is made possible by nodes connecting to other nodes as peers and syncing the data that they have received from their other peers.

example

node A is connected to:

node B
node C
node D
node E
node F

node B is connected to:

node A
node C
node G
node H
node Z

in this example node A and node B are peers that sync data to each other. as a result node A would be exposed to data stored on nodes G, H and Z and node B would be exposed to data stored on nodes D, E and F.

data propagates consistently and quickly when nodes frequently rotate their peer connections. nodes are configured to have a maximum number of inbound and outbound peer connections. the optimal configuration of the number of connections is determined by the health and strength of the hardware the node is running on and the role it aspires to perform (see full node cluster valve).

nodes can have preferred peers, but to optimize their visibility to as much of the network activity as possible, they should connect to a large and diverse pool of nodes. each time a node replaces a peer with another peer (rotation) they are potentially exposed to new data from a different part of the network.

when to rotate peers

peer rotation occurs proactively and reactively:

• proactive rotation supports the node striving to have current and diverse data from the network. the node knows that new data is available but it doesn't have expectations about what the data is. proactive rotation behavior is defined by a collection of node configurations. the nature and frequency of proactive rotation is configurable.

• reactive rotation occurs when the node knows it is missing data and wants to connect to the peer node that is most likely to have the data. it strives to connect to a peer node that announces attributes about itself that make it a good candidate to respond to a specific data request. reactive rotation is done as needed.

selecting a new peer: proactive rotation

there are three approaches to selecting peer nodes in order to gather current and diverse data from the network:

1. data quantity: favoring peers based on the amount of data they store

2. peer popularity: favoring peers based on the number of peers they connect to

3. random selection

for normal node operations a blend of all three approaches should produce optimal data currency and diversity. the default configuration is to use each of the three approaches with equal frequency. however, the weighting of the approaches is configurable in any combination. for example, a node could be set to randomly select a peer node 100% of the time.

in addition to the configuration of the weighting across the three approaches, an additional configuration is available to further define the data quantity and peer popularity approaches. the configuration allows definition of data quantity and peer popularity as either:

• more than average: chooses a random node from an eligibility pool consisting of the top 50% of nodes

• more than most: chooses a random node from an eligibility pool consisting of the top 20% of nodes

• more than all: chooses a random node from an eligibility pool consisting of the top 1% of nodes

the hard coded options above are available in the millix user interface and can be replaced with any value directly in the millix database config table.

selecting a new peer: reactive rotation

selecting a new peer to request specific data is done by examining peer attributes and identifying which nodes are most likely to have the data requested based on the following criteria:

• shards supported

• record counts of each shard

• timestamps of most recently added records in each shard

• fee for providing data

• node reputation (how many nodes are blocking it, how many doublespends has it created or validated etc)

the node attempts to connect and query the node attractive node first, and continues down the list until a successful connection is made and the requested data is provided.