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.
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.
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.
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
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.
at the time of genesis, the data size of an average transaction is 3,500 bytes including database indexes.
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.
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.
millix allows the option of submitting transactions which require more than one signature to release the transaction’s funds. signatories are able to add or direct transaction outputs prior to the transaction being validated. this feature enables a multisig transaction to be funded before the transaction recipients are known. this method has been implemented with the escrow feature to process millix protocol fees such as confirming transactions.
the millix escrow features allows authorization for funds to be released when criteria are met, such as proof of work or proof of stake. the protocol doesn’t define or limit how proof is established or demonstrated, and some implementations may be better described as “probability’ as opposed to ‘proof’.
at the time of genesis, the data size of an average transaction is 3,500 bytes including database indexes.
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 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.
the following principles were considered in the fee process design:
1. fees are denominated in millix
2. fees must be pre-funded and visible for workers to verify as available prior to work beginning
3. fees are paid when the payee proves to the payer’s satisfaction that work is complete
4. the amount funded to the fee may not be sufficient to satisfy the number of workers claiming to have completed the task
5. multiple workers may claim to have completed the task, the fee budget cannot be exceeded, and some claims may not be compensated
6. fee transactions must be settled and confirmed without causing a cascade of more transaction fees
7. the worker uses the escrow key to complete the signature and complete an output in the multisig with the address they want the fee sent to.
8. both the multisig transaction containing the fee and its’ associated transaction must be confirmed before either’s confirmation is considered complete.
9. in the case of fees for millix protocol tasks such as transaction confirmation, the multisig transaction that contains the fee for another transaction must be verified by nodes for no additional fee. this is considered an overhead task which nodes must complete before performing compensated tasks.
not all tasks are compensated and certain tasks are obligatory for participating on the network, such as storing transaction data and confirming fee transactions. work can be completed by more workers than the task or task budget allows or requires. the consequence is work occurring without compensation, which is inefficient. it’s reasonable to assume that a task could require or be budgeted to compensate 10 workers, but fifty workers complete the work, resulting in an efficiency of 20%.
for references it’s important to consider the inefficiency of blockchain protocols that rely on miners to do work. if 100,000 miners work to solve a block and only 1 miner is compensated for solving the block, the efficiency is .00001%.
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.
millix operates on a directed acyclic graph, known as a DAG, instead of a blockchain.
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.
to stimulate network growth and balance network resources, millix node operators are incentivized for being online and contributing computing resources to the millix network.
anyone holding millix could run their own incentive program to encourage any type of behaviour. There is no official incentive program and no permission required for anyone to pay node operators any amount for any activity. This document merely describes incentives that millix founders wish to spend their millix on because it is beneficial to the network. The node operator incentive program is managed by millix founder Emmanuel Braden.
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.
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.
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.
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
the initial millix road map consisted of the following themes:
summer 2020- base organization and functionality
fall 2020- connecting millix protocol to machines for large scale transactions
fall 2020- large scale transaction speed and storage
fall 2020- a community of earning
winter 2021- store and own your personal data