There is nothing that can be done to prevent a diff spike if a miner/pool rolls in with 5x or 10x the base network hash-rate. This is the job of the diff algo. It is how the diff algo handles the hash-rate spike... both during the spike and after that is important.
Example 1. - Large hash-rate miner/miners adds 5x the base hash-rate to the network, the diff must increase by 5x or the block times will become skewed. The miner/miners are stable, mid-term miners and mint for several days or weeks. If the miner/miners leave the network suddenly, due to power or network issues, the diff will remain 'stuck' at 5x until the next blocks are found by the base network hashrate, which can be up to several hours. This is how the diff algo is supposed to work and is working properly. Ideally, the hash-rate is withdrawn slowly which helps prevent a 'stuck' network.
Example 2. - A multi-pool attacks a network with 5x to 10x the base hash-rate, collecting all the blocks quickly as the diff algo adjusts to the added hash-rate, the multi-pool is getting the blocks at a discount until the effective diff is found. But the multi-pool leaves when the diff levels out, leaving the network stuck. It may take hours to find a new block, the diff falls back the base, the multi-pool attacks again... rinse and repeat... doing this a multi-pool can basically own a network and mint the majority(as high as 90%) of the new blocks at a discount up to 60%.
In example 2, DGW3 in the case of a long block target time(more than 60 seconds), over-reacts to the diff spike on the back side(when the high hash-rate is withdrawn) and plunges the diff to a false low in response to a 'stuck' network, here is where a multipool can really make money by re-entering the network at the false low diff and minting blocks back through the base diff up to the high diff level. This makes a network essentially unusable.
Digishield handles this scenario much better than DGW by lowering the diff on the back side of the spike slower preventing a false low and when configured properly can deal with a 10x hash-rate spike effectively. There will always be a time when the network appears to be 'stuck' when a significant portion of the nethash is withdrawn, but you can make the network highly resistant to multi-pools/high hash-rate attacks with a properly configured Digishield implemented which reduces the number of blocks minted in such an attack by the high-hashrate miner that the attack becomes unprofitable.
I personally spent several weeks running testnets as high hash-rates, deploying multiple attacks, implementing different diff algo code variables, as well as working as part of the Criptoe Team, so I have a reasonably clear understanding of how diff algo's work and don't work. I will do a GIT clone in the next few days and have a look at the GUN code base.
Very good - thanks for the detailed explanation to our community here!