usmann

If you're interested in catching chain halts, here are some ideas: Consensus critical paths: - Check consensus invariants and how to break them -> halt - Check functions that should always succeed, but you find a way to make them fail or revert for everyone every time -> halt - Check functions that should always return a response (success or failure), but you can make them panic -- unexpected side effect or missing recovery mechanism. - Look for possible sources of non-determinism -- may lead to chain halt or fork Risk profiles: - Halt the production of blocks - Halt the production of proposals - Halt the processing of transactions - Halt the p2p communications - Halt the processing of txs - Crash validators consistently - Crash critical dependencies consistently Attack Surface: - Trace back the critical paths, and the components that could be broken - It may be a malicious transaction by any user, or a malicious p2p message relayed to the nodes - It could be a rogue validator with a malicious proposal - The chain might read events from contracts. It could have a light client checking things happening on other chains. - It could be time based, or something that happens on specific blocks, or during some special event. - There might be issues in dependencies that aren't critical anywhere else, but they lead to a more severe impact in some specific flow - The chain could have special roles that could be vulnerable to specific attacks Resource exhaustion: - CPU: make validators spend too much time computing transactions or blocks -- they won't make it in time for agreeing on the block - Memory: crash validators with OOM errors - Storage: bloat the disk space - Invariants: bloat some resource invariant, like consistently surpassing the block size, or tx size, making proposals fail. Caveats: - Most bugs aren't vulnerabilities. Learn how to code an e2e PoC for a network. - Not every panic leads to a crash. They're often gracefully caught. - Not every crash leads to a chain halt. You may crash the RPC node, but not the validators - A chain might have different clients, and the overall impact may not lead to a chain halt - Permissionless attacks are more dangerous than ones that require a validator - Panics in transactions are usually caught by the execution layer - If the impact is that your tx reverts, there's no impact. If the impact is that your proposed block is rejected, there's no impact. - Chains have different consensus mechanisms and caveats. The same vulnerability won't necessarily lead to the same impact. There's a huge overlap with other impacts. The same core vulnerability could be exploited for a chain halt, or could be used to take down validators to gain consensus, or could be abused to lead to a chain fork, or other issues. It's also possible that it doesn't lead to any real impact too. It's up to you to assess the most critical impact.