TL;DR imagine a signature verification library that verifies a signature indeed signs the given hash, but not that the signed data hashes to that hash. Woopsie.
I guess nobody's commenting on this because it's very dense math without any context. Lucky for me I spent an hour or two yesterday learning how practical non-interactive zero knowledge proofs work.
In SNARKs (and other commitment schemes based on polynomials in elliptic curve groups, hope I got the terminology right), you verify the commitment (unneeded technical details: polynomial on EC at secret point nobody knows including the committer so he has to make the polynomial match at most points, and polynomials that match at most points match at all points) by multiplying two things you calculated from the circuit and commitment (which is just a couple of group elements) and verifying that it comes out as 1. The multiplication and comparison under encryption is done with a homomorphic encryption primitive-type thing called a "pairing" (normally with elliptic curve encryption only addition can be done on secret group elements that you don't know the value of).
They found a way to tell a specific library that implements this operation "believe me, this pairing is ok" that doesn't depend on any of those technical things. Just "these are not the droids you're looking for". Because it was not validating that some precomputed thing needed for the pairing verification actually matches this specific situation, and there are trivial parameters that would always yield 1 (but not be valid in the situation).
What would it mean if someone were to successfully exploit these? Most or all L2 ecosystems or the magic components that let them speak to each other would need a hard reset?
It's a "this transaction is valid even though the signatures, amounts, potentially everything is wrong about it" vuln.
Every node that uses this library to validate would lose synchronization with every other node (if we take them at their word that it's not a monoculture), the bigger half would be considered "correct" according to how blockchains work, if it's the non-exploitable half - just lots of wasted resources and longer settlement times, if it's the exploitable half - illegal transactions would need to be reverted by agreement of the community, which is some sort of reset.
Cryptography *2*? We're still over here trying to implement Cryptography 1 without side channels, and they went and invented a new one?
TL;DR imagine a signature verification library that verifies a signature indeed signs the given hash, but not that the signed data hashes to that hash. Woopsie.
I guess nobody's commenting on this because it's very dense math without any context. Lucky for me I spent an hour or two yesterday learning how practical non-interactive zero knowledge proofs work.
In SNARKs (and other commitment schemes based on polynomials in elliptic curve groups, hope I got the terminology right), you verify the commitment (unneeded technical details: polynomial on EC at secret point nobody knows including the committer so he has to make the polynomial match at most points, and polynomials that match at most points match at all points) by multiplying two things you calculated from the circuit and commitment (which is just a couple of group elements) and verifying that it comes out as 1. The multiplication and comparison under encryption is done with a homomorphic encryption primitive-type thing called a "pairing" (normally with elliptic curve encryption only addition can be done on secret group elements that you don't know the value of).
They found a way to tell a specific library that implements this operation "believe me, this pairing is ok" that doesn't depend on any of those technical things. Just "these are not the droids you're looking for". Because it was not validating that some precomputed thing needed for the pairing verification actually matches this specific situation, and there are trivial parameters that would always yield 1 (but not be valid in the situation).
Can you say more about the homomorphic encryption bit? It's fascinating to hear about it being used in practice and making it out of research.
What would it mean if someone were to successfully exploit these? Most or all L2 ecosystems or the magic components that let them speak to each other would need a hard reset?
It's a "this transaction is valid even though the signatures, amounts, potentially everything is wrong about it" vuln.
Every node that uses this library to validate would lose synchronization with every other node (if we take them at their word that it's not a monoculture), the bigger half would be considered "correct" according to how blockchains work, if it's the non-exploitable half - just lots of wasted resources and longer settlement times, if it's the exploitable half - illegal transactions would need to be reverted by agreement of the community, which is some sort of reset.