# Risks around post quantum signature aggregation This document aims to list some potential risks/fears we have around post quantum signature aggregation for the beam chain so that we keep them in mind for the future. This could help to quantify the risks and impacts. 1) An attack on Poseidon2 emerges. There's a loss of confidence in it and doubling the number of rounds is insufficient to appease cryptanalysts. 2) Implementation complexity is too high to fully formally verify the verifier. 3) An attack on fiat-shamir (eg diagonalisation 2.0) is found. 4) An attack on recursion is found. 5) [parametrisation] The industry standardises on binary fields and the fastest hardened hash function is significantly slower than Poseidon2. 6) [parametrisation] The way we compile WHIR to Whirlaway is buggy and we suffer a significant performance penalty when reparametrising. 7) [parametrisation] A mistake in the WHIR security proof is found. We fallback to FRI and suffer a ~2x cost? 8) [parametrisation] The proximity gaps conjecture we rely on is found to be false. We suffer a ~2x cost? 9) [parametrisation] The industry converges on a prime field that is not optimal for hashing (eg BabyBear). We suffer a ~2x cost? 10) [parametrisation] 64 bits of quantum security is deemed insufficient. We suffer a ~2x cost? 11) even if we formally verify the verifier components related to WHIR / AIR / zkVM + ISA, there is still an attack surface on 1) the compiler high-level-langage -> ISA, and 2) the recursion program in itself (written in the high level langage). I don’t know to what extent formal verification can help us here. 12) The overhead from the minimal zkVM is larger than expected and we can't reach target performances with reasonable implementation complexity. 13) Another vm (even a small one) enshrined into the consensus is not accepted by the community with a lot of strong voices against this. 14) Not really a fear, but let's imagine that the progress of zkvms is so amazing that in less than 1 year, their performance + proof size (RISC0 guys told us during beam day that they have 200kB proof without SNARK wrapping, to be checked) is so nice that we don't need all the machinery, just run a Rust recursion program inside their VM. + The VM in question should be formally verified. Then we don't need the minimal VM + the PIOP + WHIR, we can just use an existing VM.