overview

enabling senders to pay a transaction fee reduces spam transactions, incentivizes node operators to be online to validate and store transaction data, influences the speed and scale that transactions propagate through the network and provides opportunities to architect additional features to increase the economic activity supported by the protocol.

problem

1. unlike blockchains, where miners construct blocks of transactions and collect a batch of fees from the transactions included into the block, in a decentralized DAG it is unknown which node will earn a transaction fee. trying to determine which node will do work, then paying them a transaction fee based on the quality of their work would require a complex system of back-and-forth negotiations to update the transaction in question or a cascading amount of transactions with endless fee transactions that require more fee transactions to validate.

2. although millix nodes store data that is relevant to validate their own balances, and are obligated to store network transaction data in an assigned shard, there are edge cases where historical data needed to validate transactions could be unavailable or inefficient to find.

3. for a variety of reasons, it is preferable that nodes sending transactions be online. verifying whether nodes are online en masse is not a simple or reliable operation.

4. if an invalid transaction is submitted to the network, many nodes would perform duplicate, useless work searching for supporting data only to all independently conclude that the transaction is invalid. this is inefficient in the best case and forms an attack vector on the network in the worst case.

solution

1. in addition to node operators storing unexpired transactions and transaction assigned to the shard they are obligated to support, they are also encouraged to store the history of transactions needed to validate their balance.

2. force senders to connect to a random online node as a proxy node, send it the new transaction and as much of the supporting data possible and pay the node to act as a proxy that pre-validates and submits the transaction to the network on the sender's behalf. proxy nodes do not contribute to trust, they are only used as an administrative requirement to submit transactions to the network.

transaction flow

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

2. sender 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 it’s outputs, including the transaction fee to the proxy, are invalid.

fee determination

senders can explicitly configure the size of the 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 each with which they can locate historical transaction data needed to validate new transactions.