Note: These are cliff notes from the talk by Vitalik Buterin at Ethereum Meetup, Zug.

The cost of transaction fees to use decentralized networks are an emotive topic that consistently resurfaces, as network congestion (organic or otherwise) on the likes of Bitcoin and Ethereum frequently leads to excessive and volatile mining fees. However, despite the important role they play, the principles behind pricing mechanisms are arguably debated less than many other aspects of network development.These mechanisms have an important role to play in:

‍Preventing attacks: As explored in a recent piece on DoS attacks, spam attacks prevent the regular usage of a network and bring it to a halt. Whilst it may not be possible to prevent DoS attacks completely, the fees an attacker must pay for transactions can make them economically unviable to sustain for long periods.

‍Aligning the validator (e.g. the miner in a PoW system) with the wider network: Mining incentives are often opposed to the interests of other users on the network.

This is because the majority of costs in the long run are ultimately carried by nodes on the network which must update/store every transaction.Facilitating usage: Networks want to encourage users to make transactions and as such must balance the desire to make them cheap enough to use against a need to prevent spam and encourage the validation of transactions.

‍The long-term health of the network: Networks must be created to last; creating a flexible pricing mechanism capable of meeting demands such as the above is a crucial aspect of this.

Pricing mechanisms: Basic principles

If Alice wants to send Bob a transaction, she can enter Bob’s address and send the desired amount. At this point, assuming a Proof of Work blockchain such as Bitcoin or Ethereum, a validator will include the transaction in a block which (assuming they are the first to discover the solution for) will then be processed and the transaction confirmed.There are three main points in which an expense occurs or accrues.

• Alice is sending something for her benefit and so will decide how much it is worth to her to send said transaction. If the network is really full or she needs it sent urgently she may have to pay slightly more in order to be able to send her transaction
• The validator is taking on an initial cost (the mining fee) with the expectation of a return (block reward) for processing the transaction
• The rest of the nodes on the network will end up having to update their ledger to match the new state

So how do we decide what a fair amount is for:

• Alice to send her transaction
• The validator to take as a reward
• The nodes to update their state

One thought is that it should be simply driven by market forces. If Alice deems her transaction important, she will pay more to get it sent quicker. If not, she will set a low amount and wait until a miner accepts the transaction. This is also known as an auction mechanism. Whilst in a perfectly efficient market this may be optimal, in practice it is arguably inefficient for the market because:

• Alice might not and probably won’t have the information required to know what is the optimal fee to pay. This means she may overpay what the miner wanted to process it or not realise the current fees and her transaction would not be processed
• It can make fees highly volatile which could lead to a poor user experience, for the reasons outlined in point (a) and because users don’t expect fees to multiply by 7x as witnessed in December
• Ultimately it is in the interests of the miner to process the transaction (more processed transactions, more fees) despite the fact that, as previously noted, it is in everyone else on the network who bears most of the costs of the transaction in the long run. As such, it creates a disconnect between the miner and the wider userbase

An alternative auction model known as second price auctions sees Alice, Bob, Charlie and everyone else submit their bids but, as opposed to the model described above, everyone instead pays the lowest accepted bid price (e.g. if a miner is willing to process a transaction for $0.4, then even if Alice submits a transaction with an associated fee of $10 she would only pay the $0.4. If she had submitted a bid of $0.2, then her transaction wouldn’t be processed).

As such, the emphasis changes from “how little can I pay and still get my transaction through” to “how much is too much for me to pay for this transaction that I’d rather see it fail”. However, this is again subject to miner manipulation, as they could fill blocks with ‘fake’ transactions from themselves to both reduce real transaction volume and increase the lowest bid.Now let us expand this scenario slightly. As a result of miners processing as many transactions as possible, as is in their best interests per (c), the block sizes become bigger and bigger. T

he larger the block size, the more intensive it becomes for people to run a node and the more intensive it becomes the less nodes will be spun up. This brings in an additional risk of increased centralization, as the network becomes the responsibility of a decreasing number of nodes.This is why we must think of the social cost ofthe pricing mechanism underpinning the network – what impact will it have on all users on the network rather than just the validators? We do not want to arrive at a situation where we have priced out the majority of users from securing the network.

Smart contracts: An additional challenge

Zoom out again. A network such as Ethereum brings forth more complex transactions which aren’t just Alice sending Bob 1 BTC but also now include smart contracts requiring larger amounts of data, computation, bandwidth and storage. How does this change the dynamic?For one, processing fees (or gas costs in the case of Ethereum) are no longer as easy to predict. It is no longer a case of checking for network congestion, but rather Alice must also compute the cost of the contract.

‍On Ethereum this is gas price (the fee the user is willing to pay to ensure a fast transaction) multiplied by the gas used (which is essentially the cost of the computation to run the smart contract).

Other networks such as Neo operate differently, making the Gas a separate (and tradable) entity to the main unit Neo. This introduces its own challenges, as a needed resource becomes a speculative commodity.We also need to factor in the additional problem that these contracts may be running essentially forever and so we need a means of both making sure enough gas is taken out at the start (to prevent it cancelling mid-execution) and that there is a gas limit. This is done to prevent a bad actor from making a transaction that would be essentially unprocessable by miners but would be constantly running – a potential DoS attack vector.

Validation vs Storage: Are both acts worth rewarding?

Finally, let us consider the long-term health of the network. Alice’s smart contract transaction is one of billions being completed each day, week, month, year. All nodes must record each of these transactions being constantly processed across thousands or more of smart contracts and millions of users. Every node must store these transactions, an easy task at first but one that becomes ever more expensive and harder to fulfill for most nodes the larger the ledger becomes (as an example, Ethereum’s blockchain size exceeded 1TB earlier this year).

However as noted in most implementations nodes don’t get paid for maintaining the full blockchain ledger. The only people who get paid are those who process the transactions initially. This creates an incentive to process transactions and a disincentive to run nodes maintaining the ledger, an act necessary for the survival of a network.

As such, any pricing mechanism must consider the cost of storage and if there needs to be an ongoing storage fee to reward such nodes performing this vital task.Decentralized networks remain in their infancy, particularly those running smart contracts. As such we are likely to see the continuation of situations where networks are unable to cope with demand or where others are accused of deliberately seeking to exploit the pricing mechanism as a means to spam and attack the network.

Ultimately, however, this is why all network implementations need to consider the issues listed when determining how much transactions should cost and who should get paid.