[deleted]

John Woods (CTO of Algorand Foundation) gave some hints about what the technical roadmap would contain in 2025 in a recent interview. One of the things discussed was the 'fees market'. This post is to explain how fees are used to fight spam rather than just being a mechanism to fund the blockchain.

TLDR Summary

>Algorand has a well designed anti-spam mechanism implemented with fees , rents and budgets which will need tuning in the future as the cost of IT resources fall with time and as performance is better understood as well as providing sustainable funding for the blockchain infrastructure.

Intro

What is spam? In IT spamming is a way to attack systems causing them to fail or become unusable by overloading their resources. No doubt most people are aware of spam email which try to overload your attention with lots of scammy emails. Proof of Work was suggested originally as a way to stop email spam by Adam Back who now as CEO of Blockstream is one of the maintainers of the bitcoin core client.

Blockchains also need to stop spam as without spam protection attackers could spam millions of transactions and required storage for the blockchain storage would become so huge it would be too expensive to maintain for node runners.

Storage spam

Algorand's blockchain design allows nodes without a full copy of the blockchain to participate in concensus, participation nodes and non-archival relays only need retain the last 1000 blocks and current blockchain state, but there are still archival nodes which store the whole blockchain. Blockchain Explorers will use these and they are essential for new archival nodes joining the network to replicate the full blockchain history.

This means there are 2 types of storage corresponding to each node type to protect

1. The whole blockchain storage. (Archival nodes)
2. The current blockchain state and the last 1000 blocks. (Non-archival nodes)

To protect 1) the transaction fee, currently 0.001 Algos is intended to do this. Since only a small number of node runners run archival nodes this can be very low without costs for node runners being huge.

To protect 2) the minimum balance for accounts serves this function. The simplist example of this is for any account a minimum of 0.1 Algo is required. This is more of a rent than a fee since the account can be closed and all funds collected including the minimum. When this happens the account data no longer needs to be in the 'current blockchain state' so the rent is no longer required. This type of storage is called 'persistant storage' in the documentation. Since EVERY node needs this current blockchain state data it makes sense that data storage here is more expensive than the archival storage costs since it is stored so many times more. Smart contracts only have access to this data.

There are other reasons why the minimum Algos in an account will be raised to compensate for the additional burden on current blockchain state storage this extra data causes.

• Adding additional assets such as USDC adds 0.1 Algos minimum
• Creating/Signing into a smart contract adds 0.1 Algos minimum
• Sometimes smart-contracts need extra storage. They can rent extra storage by raising the minimum Algos to rent storage space known as 'box data'. The formula for this is (0.0025 per box) + (0.0004 * (box size + key size)).

None storage resource spam

Storage isn't the only resource that can be spammed.

• Individual blocks could become too big to transfer to all nodes in time for the next block, this would be a type of network spamming.
• Node compute power can be spammed. This is a compute spam attack.

To address Individual block spam Algorand has a couple of mechanisms to counter this. First there is an absolute limit to the size of all transactions of 5Mb that can be in a single block. This was originally 1Mb but it has already been tuned up to a higher value. In addition as blocks fill up the minimum fees are raised. This allows nodes to priortise transactions that the sender considers time critical so is willing to spend higher fees on as opposed to lower priority transactions that will wait till congestion reduces to save on fee costs.

Node compute power is countered by a non-fee mechanism. Instead every smart contract is given a compute budget with every TEAL Op Code costing a certain amount. If the budget is exceeded then the transaction is failed. Failed transactions on algorand don't leave the 1st node they are sent to so this means there is no spam sent to the network just an individual node and since Algorand is designed to have large numbers of nodes the loss of one does very little harm to the whole blockchain.

Tuning anti-spam fees.

In the future compute, networking and storage costs are very likely to fall because computing resources have always had deflationary costs and are likely to fall further. To stay competative as a blockchain these fees are likely to need further tuning at somepoint to reflect lowing costs.

Satoshi foresaw this

>Forgot to add the good part about micropayments. While I don't think Bitcoin is practical for smaller micropayments right now, it will eventually be as storage and bandwidth costs continue to fall. If Bitcoin catches on on a big scale, it may already be the case by that time. Another way they can become more practical is if I implement client-only mode and the number of network nodes consolidates into a smaller number of professional server farms. Whatever size micropayments you need will eventually be practical. I think in 5 or 10 years, the bandwidth and storage will seem trivial.

Unfortunately this was ignored when 'bitcoin' split from 'bitcoin cash' after Satoshi had left as the bitcoiners didn't take advantage of the lowering cost of resources.

On Algorand parameters that control these fees and other parameters are stored in the Algorand concensus. Since any change in concensus requires 90% of nodes to install the new algorand node code this gives node runners a way to reject a change to fees that they disagree with by refusing to upgrade.

What could go wrong? If the costs of running the blockchain (including all node runners costs) is higher than the fees raised then the blockchain isn't self supporting the operators would be underfunded for their efforts and would likely stop running nodes. If it is the other way round and fees are too high then it could make the blockchain too expensive for some applications and DApps might start to migrate away to blockchains with lower infrastructure costs. There is a balance that needs to be managed and tuned.

The future

These are a few things I'd like to see emerge but are by no means essential for future needs. These are just examples of things we might see.

A performance model could be created and made public so the impact of tweaking the various parameters that control the anti-spam measures can be understood quickly. Then informed decisions could be made regarding changing the various parameters. Algorand must be collecting some of the data required already as some of the rational for reducing blocktime to 2.8 seconds (dynamic lamda blocktimes) would have been needed performance metrics to justify that. John suggested there is more tuning in this area expected next year.

A strategy could be published by Algorand Inc for updating node requirements. A common approach in IT is to publish hardware requirements and give an 'expected end of life' date after which the requirements are expected to be revised. Normally hardware requirements get a minimum 4/5 year 'expected end of life' after publication and give at least 1/2 years notice of the new minimum requirements becoming mandatory so customers know how long their hardware will definitely be usable for so they can budget properly for this and they have time to plan when a hardware upgrade is due to buy new node hardware.

In quite a few years all of the funding for the development of Algorand including any cryptographic research and IT work will need to be funded by fees. It might be that Algorand foundation is seen as justifying its continued existence with fees too or other organisations funded to promote algorand might emerge. It could be that participation node running becomes so low cost that no fees need to go to participation node runners as was Silvio's original vision. At that point we will likely have nodes running on our phones!

I would like a way to dynamically change fees in the test environments provided for algokit. With that feature developers could test how their DApps work when fees dynamically increase or are retuned in a future change of concensus. Features like this and spreading awareness that fees are likely to change in the future will allow developers to deliver DApps that are more robust to changes over time in the fees. This should already be possible, I think (please correct me if this wrong) it needs a node rebuild to change which is a big overhead for a developer just trying to test a DApp, a configurable mechanism would be preferred.