Snowfork's Analysis of Sync Committee Security

Tech Talk
4

Could you explain what you mean by “invalid block” in “get them to produce quorum an invalid block”? (I’m not an expert arguing with you, just a learner.) When I read @vbuterin’s multichain vs cross-chain comments he contrasts 2 cases:

  1. [Native ETH] “Even if 99% of the hashpower or stake wants to take away your [native] ETH, everyone running a node would just follow the chain with the remaining 1%, because only its blocks follow the protocol rules. If you had 100 ETH, but sold it for 200000 USDC on Uniswap, even if the blockchain gets attacked in some arbitrary crazy way, at the end of the day you still have a sensible outcome - either you keep your 100 ETH or you get your 200000 USDC. The outcome where you get neither (or, for that matter, both ) violates protocol rules and so would not get accepted.” ==> The 1% of honest nodes never follow an “invalid block”.

  2. [Bridged ETH] “Now, imagine what happens if you move 100 ETH onto Polkadot to get 100 Polkadot-WETH (via Snowfork within BridgeHub), and then Ethereum gets 51% attacked. The attacker deposited a bunch of their own ETH into Polkadot-WETH and then reverted that transaction on the Ethereum side as soon as BridgeHub confirmed it. The Polkadot-WETH bridge is now no longer fully backed, and perhaps your 100 Polkadot-WETH is now only worth 60 ETH. Even if there’s a perfect ZK-SNARK-based bridge that fully validates consensus, it’s still vulnerable to theft through 51% attacks like this.” => Again there is no “invalid block”, BUT there is a reverted transaction that causes the value of the Polkadot-WETH to dwindle maybe all the way to 0.

The primary way of “stealing from the bridge” would be via (2), not by generating invalid blocks that are outside protocol rules but by reverting transactions (or censoring), right?

After seeing Polkadot Dispute Storm - The Postmortem (1 validator doing something buggy, but easily could have been > 2/3 of the network) I CAN see how automated MEV tools integrated into Ethereum clients would similarly generate a coordinated “attack” by reverting transactions (or censoring) [but not actually producing “invalid blocks”] and make the probability of attack much much more likely than the astronomically small 10^-54, maybe even > 1/2. Not because the humans running the validators are malicious, but because the scenario where MEV tools would pursue incentives to revert/censor seems SUPER plausible. Or (with the paranoia of all the AI doomsday types) these tools – with only a bit more intelligence – may well conclude that its actually VERY rational to have an Ethereum cartel and “accidentally” kill off any neighboring L1/L2 ecosystem bridge. Almost all human monopolists behave this way, why wouldn’t the MEV tools be programmed to behave in cartel like ways just like them?

So, I changed my mind: it IS important to add the Approval Committee and I urge both Snowfork and t3rn to take @rphmeier fears seriously.