techpaper

overview

millix is an open source project that provides utility as a simple, high speed, large scale, peer-to-peer cryptocurrency with no organizational or functional centralization.

the founders of millix were motivated to create a cryptocurrency protocol with the utility of millix because of their backgrounds building social network platforms, content management systems, e-commerce systems, data distribution systems, financial services, communication services, affiliate marketing, manufacturing and logistics operations, gaming platforms, accounting and legal practices. the potential use cases of these and other disciplines influenced the millix design philosophy.

the scope of millix is to provide basic functionality and components for developers to use in their applications. for example, the millix protocol does not include a smart contract engine or programming language interpreters. however, included features such as multisig and escrow were designed to be simple and universal, allowing developers to use them as reliable foundational components to build complex functionality.

to the extent there is an inverted correlation between utility and a store of value, millix is not intended to compete with the use case or feature set of any blockchain projects. the utility that comes from scale and speed has been prioritized, leading to the philosophies and methodologies described below.

network

nodes

the millix network is made up of nodes. a node is any device running the millix software. millix nodes are all of equal capability and authority; there is no hierarchy of nodes or node operators, or centralized controllers.

node relationships

each node seeks to connect with N peer nodes to sync data to-and-from the network. node connections are regularly rotated and replaced with connections to other random nodes. each node saves a history of nodes it’s had a relationship with or arms length exposure to, saves the attributes of the nodes and blocks connections / ignores communications from nodes exhibiting undesirable behavior.

communications

data is published and exchanged between nodes in a variety of ways:

1. data that is intended to be broadly published to the network, such as transactions, are stored in local tables that are set to propagate data to connected peer nodes

2. targeted data requests, such as transaction history or escrow keys can be made privately and securely to specific nodes via api. this hasn’t been defined

3. signed message, this hasn’t been defined

time keeping

transactions are time stamped with the time provided by the local clock of the node that created the transaction. nodes periodically compare their local time with internet clocks. if there is a discrepancy between the node clock and the internet clock the node is forced offline.

transaction

transaction data

at the time of genesis, the data size of an average transaction is 3,500 bytes including database indexes.

transaction integrity

each node is capable of earning fees by working on tasks of many types. a significant, yet common task is verifying the integrity of transactions and detecting double spends. unlike blockchain protocols which produce blocks containing limited numbers of transactions at infrequent intervals, millix has no blocks. each transaction is audited and verified atomically by multiple, random nodes. as a result, individual transactions are created, audited, confirmed and verified with consensus as fast as random nodes can perform the work, instead of in infrequent batches.

as transactions are confirmed by nodes, the nodes earn fees for their work. unlike blockchain protocols where all nodes perform similar work and only one node earns a fee when the work is complete, millix nodes earn fees consistently and more work is accomplished with less resources.

speed

each node is capable of performing every protocol activity, no activity is centralized or reserved for special nodes. this eliminates traditional bottlenecks. the speed of the network is the accumulation of the speed at which each individual node operates. as more nodes participate on the network, the network becomes capable of more transactions per second with linear scaling.

for example, if a single node is capable of processing and verifying N transactions per second, the speed of the network with 100 nodes should be (100 * N) transactions per second. nodes running on more powerful devices, storing more data and operating with faster processors are able to complete tasks faster and earn more fees.

during testing prior to genesis, millix was performing at 5 transactions per second using only 20 nodes, including intentionally light devices (raspberry pi, refurbished i5 desktop, virtual machines with 2 cores and 2 gb of ram). moderately powerful consumer grade devices running intel i7 processors were processing (syncing, validating, completing consensus round, audit point formation, pruning) up to 50 transactions per second with insignificant load on system resources.

smart contracts

at the time of genesis, the data size of an average transaction is 3,500 bytes including database indexes.

consensus

trust

unlike blockchain protocols designed to provide trust from a network whose state and data is known and agreed upon by the majority of the participants, it is difficult to know the complete state of the millix directed acyclic graph. trust is achieved with the following philosophical toolkit:

    1. select a random node

    2. request information

    3. repeat N times

    4. compare responses for consensus

    5. discourage undesirable behavior as needed by adding cost and friction

the amount of trust required by the task defines the number of times these steps are repeated and the stringency of the consensus.

fees

fees are how workers (nodes) are compensated for completing tasks. some tasks, such as confirming transactions, are built into the millix protocol. additionally, the system is designed to allow developers to create their own tasks which compensate nodes for completing the work defined by the developer. this forms the foundation for a fee based economy.

transaction fees reduce spam transactions, incentivize node operators to be online to validate and store transaction data, influence the speed and scale that transactions propagate through the network and provide opportunities to architect additional features to increase the economic activity supported by the protocol.

senders can explicitly configure the amount of the transaction fee they propose to proxy nodes. the millix client is also able to suggest an appropriate fee amount based on current network fee prices. nodes are also able to configure the minimum fee they are willing to accept to act as a proxy node.

nodes that are configured to maintain connections to many peer nodes may decide to configure a higher proxy fee minimum because their network connectivity accelerates the speed at which they can propagate transactions. nodes that are configured to support many data shards may configure their fees to represent the speed with which they can locate historical transaction data needed to validate new transactions.

transaction flow

    1. sender constucts a transaction with inputs, recipients and amounts to be sent.

    2. sender node selects a random node from a list of nodes that recently transacted on the millix network. this is the proxy node.

    3. sender submits an unsigned transaction payload with proposed transaction fee to proxy node. 4. if proxy node accepts proposed fee, proxy gathers the required transaction data to validate the transaction and send proof of work to the sender.

    5. the sender verifies the proof of work and sends the signed transaction to the proxy node.

    6. if the proxy node validates the transaction it collects the fee and propagates the transaction to its peers.

    7. proxy node notifies the sender that the transaction was validated and propagated

    8. the peers that are connected to the proxy node perform work to validate the transaction, knowing that the data required for validation is hosted by the proxy node at a minimum. this reinforces that relevant data for a current transaction exists, renews and spreads on the network.

    9. if nodes can’t validate the transaction, all of its outputs, including the transaction fee to the proxy, are invalid.

storage

data storage

each node stores transaction data that has been verified by itself and / or other nodes. as transactions are verified, audit points are created. an audit point represents a point at which it is unnecessary to audit deeper into a transaction’s history. audit points allows the historical data used to verify the transactions contained in the audit point to be pruned from the database.

transactions with high value or that require higher levels of trust can be verified by requesting raw transaction history from nodes and auditing the complete transaction lineage from genesis. nodes that choose to store raw transactions without summarizing them in audit points can be compensated for their data storage, whether directly for providing requested data or indirectly because their data coverage qualifies them to verify tasks that nodes with less data can’t.

beyond confirmed transactions and the audit points summarizing them, nodes also store transaction data that is yet to be verified.

data structure

millix operates on a directed acyclic graph, known as a DAG, instead of a blockchain.

data sharding

to ensure that copies of every raw transaction exists online on the network forever, without forcing each node to store all transactions, data is spread across the nodes using sharding. there is an obligatory amount of data that each node must store to participate on the network. nodes that store more than the obligatory amount can be compensated if, and when, that data is requested by another node.

this method, combined with audit points, allows nodes to operate indefinitely with small disks.

extreme data storage

up to 100 MB of data can accompany and be stored with each output of each transaction. transactions containing data are assigned to custom (non-protocol assigned) shards.

use case

use case

a range of millix amounts and probabilities is managed to increase or sustain the number of nodes and to balance node configurations and shard assignments on the network. Every minute an analysis of active nodes is performed using table node_attribute. The balance of the resource economy is assessed and individual payments are made to node operators each minute.

while the range of potential payments is determined based on each node’s attributes relative to the balance of the network state, the precise value within that range is selected at random using weighted probability.

this method produces a stable daily sum of payments that achieves the targeted daily payment amounts, with short term deviations that make it difficult to see how monetary policy affects payment amounts.

the daily payment target per node is roughly determined using the daily dollar cost of running an aws instance, plus profit added for the node operator.

baseline infrastructure

    overview

    a baseline amount of nodes and transaction data storage will be in operation prior to the public launch of millix.

    these nodes will consist of a mix of server grade devices, full node cluster valves and lightweight pruned nodes. The nodes guarantee a minimum service level for the millix network by creating transactions to ensure the DAG constantly progresses, validating transactions and publishing data for syncing nodes. Prior to broader node operator adoption, the existence of the baseline nodes makes the economics of 51% attacks less attractive.

    the baseline nodes will be managed by millix founders Price Givens and Emmanuel Braden.

talent network

    overview

    recruit, educate, certify and incentivize professionals and their projects that contribute to the millix ecosystem. match businesses with known professionals that can contribute to their objectives.

    use case

    • compensate lead developer of each whole number version that is released

    • compensate each meaningful git submission

    • compensate educators for professionals they recruit and mentor through certification

    • compensate professionals for achieving certification