Here is a great explanation of why the ETN fork is so slow.
Edit: Original source -
https://electroneum101.com/status-of-the-tech-update-fork/Why are things so slow after the tech update/fork? Read up!https://www.reddit.com/r/Electroneum/comments/8o7r7l/why_are_things_so_slow_after_the_tech_updatefork/Why are things so slow after the tech update/fork? After the fork, blocks were being mined very slowly
The team initially thought that the high difficulty was the big culprit for this, coupled with the low hash rate. They reasoned that we were trying to mine blocks at a high difficulty with low hashing power (since all the ASIC miners are now gone) and that it should take time before the difficulty starts adjusting. Read more about how difficulty works here.
But that was only part of the problem...
The real problem (identified here) was related to a feature that was being removed in the new update, ring signatures, and the implementation thereof. Ring signatures were used in the past to obfuscate who the real sender of a transaction was. You could "mix" other transactions with yours and so hide the real sender of the transactions in there. The amount of transaction you "mixed" with yours was known as the ring size.
This feature was removed in the tech update, and no more mixing was allowed. Transactions could only have a ring size of 1. However, there were some transactions in the transaction pool from before the fork that have ring sizes of 5. And processing these transactions after the update is what caused problems.
Unfortunately, it seems like only the "checking" part of the new software was coded right, and not the "block creation" part. They were assuming that no transaction in the pool would have a ring size of more than 1, and so it would not be necessary to check for that when putting together a block.
So as a result, blocks were being created with the unallowed transactions in them, but then immediately rejected by the checking part of the same piece of software, and by other miners who were running the new software.
So pools were mining blocks correctly, but they were rejected right away because of the faulty transactions in them.
The solution to this was just to empty (or flash) the transaction pool, and basically delete all transactions currently awaiting processing. This would keep all the ETN in the wallets of the original senders, and they would need to attempt the transaction again. These transactions would have been reversed anyway had we gone on like this since they would have expired after 3 days in the transaction pool
The team has asked several pools to empty their mempools.
Once all the mempools are flushed, and legitimate blocks are being created, it will still take some time to get through the first 75 blocks until the difficulty starts adjusting downwards, but not nearly as much time as it took initially.