In the realm of decentralized systems, determining transaction fees poses a significant challenge. On one end, a centralized approach where a trusted third party sets the fee based on new information against a pre-agreed public key of the entire blockchain could be considered. However, this method contradicts the principles of decentralized systems, as it can be manipulated by a single actor beyond accountability. On the opposite end, nodes independently sourcing public data, such as the token’s value from exchanges to align transaction fees with a stable currency value, risks causing forks due to inconsistency in external data when queried by different nodes at various times.

The Challenge of External Consensus

Achieving a secure consensus on external data, such as a token’s value relative to other currencies, is inherently complex within a blockchain framework. Automatic resolution of such consensus cannot be realized due to the decentralized nature and the variability of external data sources. This presents a dilemma for maintaining transaction fees consistent with a stable currency value amidst the fluctuating value of the blockchain’s principal token.

A Node-Operated Voting System for Fee Scale Adjustment

To address this issue, we propose a system where registered node operators on the network can regularly vote on the appropriate multiplier, which we term the “fee scale,” for minimum transaction fees. This system aims to maintain the transaction fee value constant relative to a stable currency, even as the main token’s value varies. Entrusting such a critical network parameter to node operators is potentially risky, and a more comprehensive discussion of this risk is intended for future work. However, we favor this approach over the inherent risks associated with imposing a static minimum fee for the reasons outlined above.

Balancing Node Operator Incentives

We believe the risk associated with the node-operated voting system can be mitigated by balancing two opposing incentives that should limit each other. On a small scale, a node operator desires to maximize transaction fees collected in each block by pushing the network fee scale higher. However, on a larger scale, high network fees may deter users from conducting transactions on the blockchain, affecting usability and potentially reflecting on the token’s price. This, in turn, influences the real value a node operator can earn, incentivizing them to lower the network fee scale.

Implementing the Fee Scale Adjustment Mechanism

The fee scale adjustment based on voting is realized through three mechanisms: node operators commit to their votes, reveal votes they previously committed, and employ a calculation of the mean to determine the new network fee scale. This process ensures a democratic and balanced approach to adjusting transaction fees, aligning with the decentralized ethos of blockchain systems while addressing the practical need for stable transaction costs.

Voting Phases for Fee Scale Adjustment

The process of adjusting the fee scale within a decentralized network involves a structured voting mechanism. This mechanism is divided into two main phases: the Commitment Phase and the Revelation Phase. Each phase plays a crucial role in ensuring the integrity and security of the voting process.

Commitment Phase

During the Commitment Phase, node operators submit their votes on how the network’s fee scale should be adjusted, if at all. This is done through a commitment vote transaction, which creates a fee vote object. This object contains a recent block hash, the corresponding block height, the user’s vote on the new network fee scale, and the digital signature of the account over these pieces of information. Including additional details in the fee vote object (such as the block hash and account signature) is crucial for making the vote object’s hash resistant to attacks where an attacker might guess the fee scale a user is voting for.

Revelation Phase

Following the Commitment Phase is the Revelation Phase, where votes are recorded on the blockchain and tallied. In this phase, registered node operators are allowed to send a revelation vote transaction. This transaction includes the full content of the fee vote object previously committed by the user. The transaction must be signed and sent to the network, and for nodes to accept it as a valid transaction, the hash of the submitted fee vote object must match the commitment hash previously sent by the user during the Commitment Phase.

This two-phase voting process ensures that votes are cast securely and anonymously in the initial phase, with integrity verified in the subsequent phase. It’s designed to prevent manipulation and ensure that each vote genuinely reflects the operator’s intentions regarding the network fee scale adjustments.