I do agree with Micah. In the end, it’s the users running nodes that can defend the chain against all kind of majority attacks. I really like the story of Segwit2x playing out, as it showed the power of users in the governance process.
Regarding the 100m gas limit with a artificial cap at 1MB:
In the end there are many bottlenecks, if it’s not bandwidth, then it’s computation or storage. 100m gas would fit too many operations into one block such that small validators are not able to keep pace. So, not a bandwidth problem (or history size) but computation: An attacker would check the benchmarks, indentify the “worst” opcode and then fill the block with as much computational load as possible, without even requiring much calldata.
So yes, at 100m gas, I’m very certain we’d open Ethereum to DoS attacks.
Regarding the cap: basically all clients have limits already. E.g. the geth limit at 128kb per transactions is an example for it. Though, this doesn’t mean that txs cannot be larger than 128kb and that everything larger is reorged out by geth nodes - it’s just that geth node would reject such txs (=not forward it to others) if they see such a tx i the mempool.
As soon as we’re talking about size limits, we’re basically talking about calldata limits as it’s the calldata that makes up the “size” of a block. Thus, increasing/decreasing the gas limit directly impacts the maximum calldata (=max size) of a block.