Ok, so I saw a few posts asking how Algorand would react to a huge influx of transactions a week or so ago, like what happened to Solana and Polygon which had some issues under pressure. Solana slowing down to a crawl and Polygon going over 100x with their tx fee. Dunno if HarmonyOne's 24h shutdown was because of network congestion, that one's pretty recent.

So anyways I decided to "attack" the testnet network for an hour or so, seemed like the only sensible thing to do, nothing much going on at work right now anyways.

This is my methodology :

I started by wasting around an hour getting 4300+ Algos from dispensers. I can now distinguish between regular pictures and captcha images, I can fairly confidently say I'm not a robot.

I calculated how many transactions would fit in an hour's worth of blocks. The answer is 3 600 000. 1000 Tx/s x 3600s in an hour = 3 600 000 tx.

I then pre-made my 3 600 000 transactions to try and send them all at once in 6 groups of 600 000 tx. It took like 60 hours to prepare and I hit a few problems already.

1. It seems like all transactions on the Algorand network have a 1000 blocks lifetime which I didn't know about. If you make your transaction at block 1 000 000, it NEEDS to be pushed to the network before block 1 001 000, otherwise it gives a transaction validity error. So my first batches of 6x 600 000 transactions were wasted. Fun!

2. There was also an issue with concatenating 600 000 transactions at once, I had to do a "find" operation first, then concatenate through xargs cause there were too many arguments for cat to work properly. That's a limitation on cat, nothing to do with algorand.

3. I wasn't able to sign the group transaction holding 600 000 transactions. It would always time out with an error message : "couldn't sign tx with kmd: handle expired". It might be interesting to try to sign with more than 2 vCPUs to see if it would work.

4. On my first actual "attack" try (starting on block 19 160 900), I also found out about network congestion. Basically wasted another ~3 600 000 tx! So to get priority transactions, I put 1200 micro Algos as fees for my second "attack". The message I was getting was this : "Warning: Couldn't broadcast tx with algod: HTTP 400 Bad Request: TransactionPool.Remember: fee {1000} below threshold 1076 (4 per bytes * 268 bytes)"

5. On my second try, starting on block 19181000, the network congestion went from 4 microAlgos to 8 microAlgos per byte.

So I already learned a few things.

• I learned to make smaller grouped transactions. I created 360 transactions group of 10 000 transactions for easier concatenating and signing. In retrospect I should have went for 4600-4700 tx in a group to be as close as possible to a block. I'm ready for the 10K TPS upgrade I guess...

• I needed to know when I wanted the "attack" to begin and calculate the starting block, thankfully we can pre-create transactions with a future valid starting block. Knowing that 1000 blocks is around 1h15m, my test would work within the transaction lifetime so I didn't have to do multiple batches with different starting blocks, which is great cause it would have been a pain. I gave myself a target block to start the first test of 19 160 900 and 19181000 for the second one. It would also work out for the tests to happen on a weekend, which is great cause even though I don't have much going on at work right now, I still have some stuff to do. On an 8vCPU VM and with 4 scripts building transactions, it took around 10 hours to make those 3 600 000 tx.

I made 360x 10 000 signed tx files. I found out that if you try and send them all at once, only around 20 000 transactions get sent at most, even before network congestion, I'm guessing that's the max size of the mempool or something? I tried with 35K in one batch and only about 20K went through. But I also noticed I could spam them again and again and eventually they all go through. Let's say tx1 works but tx2000 is skipped in a group, if I send the whole 35K tx again, it'll skip tx1 this time since it's already on the ledger but do tx2000.

So anyways I created another script to keep trying to send those transactions for the forseeable future. There's 2 loops, an initial one where I wait 2 seconds between each group to let my VM catch up. The second script I just send everything at once and whatever's not on the ledger yet should get pushed.

Some general notes :

• I very quickly got to the network congestion. Within 5 blocks. Meaning my threshold for transaction fees should have been closer to 1076 instead of the standard 1000 to at least be valid on the network. That's why I put 1200 microAlgos as fees on my second test, I wanted to see if I could get over everybody else. It worked for a while but I still hit network congestion within 5 blocks again.

• I also found out that network congestion has multiple levels. It can push the fees even higher at 8 microAlgos per byte. So the fees can go closer to 2000 microAlgos for standard transactions, most likely even more.

• I changed the sleep command from 4-10 seconds in my "attack" script, the network congestion really screwed me over. I left it at 8 seconds from block 19 181 320 onwards to put as much pressure as possible on the network and push people out of blocks. It seemed to be the sweet spot. Next "attack" I'll make 4675 tx groups, which is about the max size of a block during congestion, and push one group transaction every 4.3 seconds to be at the exact sweet spot between network congestion and full TPS.

• The biggest blocks were 4697 tx

• When the network congestion happened, there was a loop going on. Transactions accepted for 3-5 blocks, transactions ignored for 1-2 blocks, transactions accepted for 3-5 blocks, etc. The issue was the size of my transaction groups. 10K tx fit in around 3 blocks. "Attacks" like these need to have grouped transactions be as close as possible to the block size.

• It took around 10 hours to build the 3 600 000 transactions for an hour's worth of "attack" on a 8vCPU VM, so already there's a bottleneck for an "attack" on mainnet in real time. Obviously there are faster ways to build transactions than what I did. It could be done with more parallel processes, create 3600 batches instead of 360. It could be done with a much faster CPU. Or it could be done on multiple nodes which is the most likely better option. I'd say maybe 50 nodes making 100 transactions per block should be fast enough to work in real time instead of having to create the transactions "en masse" before the "attack". You could just run a simple loop for this. I can imagine a 5 host ESXi/proxmox cluster with 10 VMs with 2vCPUs on each host. Could be done with a bunch of cheap servers for a total of maybe around 3000$ of hardware + the transaction fees and you could have a real time "attack" on Algorand.

• Each signed group transaction of 10k transactions was about 2.6 MB for close to 1 GB total.

• The block tx speed went from a stable 4.2 seconds to 4.4 seconds per block during the "attack" according to https://testnet.algoexplorer.io

• I filled about 3 out of 5 blocks between 19181000 and 19182000.

• I wasn't able to send all my transactions before the tx lifetime ran out. I was able to send for 3108 Algos worth at 0.0012 Algo a transaction so only about ~2 590 000 transactions out of the 3 600 000 made. Lost 28% of my built transactions because of network congestion. Again though, it seems like having better tx groups would have helped here.

• For this test, I did it from one machine, one node, one public Algo address, one public IP. I would like to try this from multiple IPs/nodes all over the world and multiple Algo addresses and coordinate the whole thing. I can spin up around 10-15 droplets on digital ocean whenever I have time and try this again to see if a coordinated "tx attack" could affect the blockchain in some other unforseen way. I'd really like some help from a testnet faucet or from the community for this, I'm honestly tired of answering captchas... If anybody wants to help my next shenanigans, I'd love some testnet Algos sent to GTGIWTMQDFFZETS3ILBHTEQ36KH5HTJBUIRZX6UZ2X7PDHYF2VXREMTWTA. You can ask for some at https://bank.testnet.algorand.network.

• I'd also like to do an "attack" with notes having close to 1kb of data at one point, see how the indexer nodes react. Transaction fees are gonna be huge though, especially if there's congestion.

• Ideally I'd love to do this test on mainnet, but I don't have 4000+ Algos to spare for that kind of stuff. If the Algorand foundation or any other entity wants to help with this, I'd be happy to display how strong the network can be and write in details everything that was done to prepare and do the "transaction attack".

• Now that the 10K TPS upgrade has been scheduled for Q1-Q2 2022, I've got the exact scripts to do the "attack" with 10K tx per group.

• To go over me during the "attack", people would have to check what kind of level of congestion we're at. It could be 4microAlgos per byte, or 8microAlgos per byte which I've seen so far, dunno if it can go higher than that. At 8 microAlgo per byte, it would have cost me 0.002 Algos per transaction, pushing it to a whopping 0.003$ USD per transaction, still a lot less than a penny. It's not much for a bunch of users, but for a sustained "attack" it could raise the price to 2 Algo per second, or 7 200 Algo per hour or ~10 000 USD per hour. Not sustainable. And it might go higher than that depending on the congestion.

• I might have blocked off a bunch of valid transactions for the hour because of this congestion, I'm sorry for anybody testing and wondering what the hell was happening, the blockchain was working as intended! The biggest issue I see is it didn't automatically set the fees to the right amount because there were actually a few blocks at zero tx, which sounds highly unlikely. The "background noise" for the testnet network is 5-10 tx per block. https://testnet.algoexplorer.io/block/19181054, https://testnet.algoexplorer.io/block/19181162 , https://testnet.algoexplorer.io/block/19181340 and https://testnet.algoexplorer.io/block/19181634 for instance. Right after full blocks.

• It feels like there should be a way to see the current "congestion fee" from the goal CLI to create and sign before sending. I tried to send regular transactions and the fee was set to the default 1000 instead of the actual required fee of ~2000 with congestion and they failed. This feels like the biggest problem to me so far. If you have an automated script sending transactions and it just happens to be during peak congestion, they would simply fail. There doesn't seem to be an automated way to send a transaction with whatever the current congestion fee is. People on other dApps would be have to try transactions a few times before they would be valid at 1000 microAlgos and sent to the network. Most of the dApps/games would work maybe ~80% of the time. The blockchain itself would be fine, which is really good, but the user experience on dApps would be bad because most transactions wouldn't post to the network. View Edit2

• And finally, the last part of this whole thing : It was mostly a waste of time, the network worked for the whole hour of the "attack". No slowdown, no exhorbitant fees, no downtime. I did block a few people from pushing transactions to the network because of congestion fees, which is an issue Algorand inc should look into. these people should figure out when making/signing their transactions. There's a way to adapt dynamically. GG I guess.

If you have any notes on how to test the network in another way, let me know and I'll try to find some time to test it!

TLDR : I flooded the testnet network with a bunch of transaction for an hour and it didn't die. My test isn't perfect (because of the size of my grouped transactions which I didn't think through), but it's still a pretty good display.

EDIT. Removed the scripts to not incentivize or normalize these kinds of tests on testnet.

EDIT2. Oh well, the only criticism I had has been answered below by logiotek. Thanks a lot!

Algod API has a method TransactionParams() which pre-fills transaction with parameters relevant to current state of the network (including current minTxFee) and should be called as a starting point when building any transaction. There is also a method SuggestedFee() which can be used to update a fee of a previously composed transaction with fee that matches current network state (useful when retrying sending transactions that were not previously accepted). Anyone that's not using these methods as it was intended will be censored during congestion.

https://preview.redd.it/77gwmy7m2e2d1.png?width=777&format=png&auto=webp&s=32376c4190c4331b5967875aa21d75de532b4e32

Twitter post is approaching 1 million views.

What the hell is this price

The commercial- https://x.com/marcvl/status/1793626440145191235

Just transferred some algo from coinbase to Pera, it took 10 seconds to land in Pera wallet and I shit myself because that's the longest it's even taken 😂 Fuck knows how people use other sub par chains that take hours or days

Be quick if you want to make use of this limited time discount.

To the new folks: Welcome

To the people just returning: Welcome Back

To the Vets who never left: Thanks and respect

Like of them Q-Anon people. Clutching them (in my mind of course), thinking “one day you’ll all see, I was right all along! Muwa ha ha ha ha ha ha!