Very interesting new project, Axiom, to enable onchain smart contracts to access historical on-chain data and other types of compute that was formerly out of reach. Uses the power of zero knowledge proof to expand what is composable in trustless fashion.
https://twitter.com/axiom_xyz/status/1620104714322051073?s=21&t=Kj09AVHw4xWuNWG2xOhjFg
@Sunfishstanford not sure from the announcement what the value prop for the “zero knowledge” bit is - archival blockchain data is already public so keeping it secret doesn’t seem to add utility. Is this about hiding the function that you personally want to compute over that data?
@elfprince13 my understanding is that only full nodes on Ethereum have the full blockchain data, while light nodes only have the block headers. So a light node cannot generate the historical state data without help from a full node. So here, zkp is used for its delegated computing aspect. So it lets an off chain entity do the computing, and uses a Zk proof to ensure correctness.
@Sunfishstanford that’s what I gathered as well - in particular I’m assuming it’s a zk-SNARK, or similar “proof of knowledge” protocol. But….the way zero knowledge proofs in particular are formulated, the querier can’t learn anything new from the response - ie you have to already know the answer before you ask for a ZKP as the proof won’t reveal it, only whether the other party knows it too.
@Sunfishstanford that seems anti-useful for the most of the computations I would want to run on historical blockchain data (although the broader category of “proofs of knowledge” seems very useful, as it would allow you to return the answer and the proof without the whole historical blockchain coming along for the ride - this is where the other paper I linked sets out a nice framework).
@elfprince13 the verifier of this proof does not need to perform the calculation of the function (which could be very computationally expensive) and does not need access to the witness (which could be very large in size), but instead can rely on the zk proof to be sure the statement is correct.
@elfprince13 in the use case where the witness does not need to be secret, the zksnark can be considered to be a labor-saving device, where the prover performs the calculation once, and after that any verifier can very cheaply verify the correctness of the calculation without needing to do it again. This is how zk rollups work.
@elfprince13 e.g., see Justin Thaler’s book Sect. 7.4, https://people.cs.georgetown.edu/jthaler/ProofsArgsAndZK.pdf
The notion of a proof or argument of knowledge is…a prover establishes not only that a statement is true, but also that the prover knows a “witness” w to the validity of the statement. For example, in the authentication application…Alice chooses a password x at random, publishes the hash value y = h(x) of x, and later wants to prove to a verifier that she knows a preimage of y under h, i.e., a w such that h(w) = y.
@Sunfishstanford okay, right, so my original assumption that the main value prop is the “SNARK” bit and not the “zk” bit holds up, in that while the verifier doesn’t require knowledge of w, nothing bad happens if the proof leaks bits of w (since w is public already, if you wanted to allocate storage for it)
@Sunfishstanford contrasted with the standard authentication example where leaking bits of w allows impersonating Alice
@Sunfishstanford anyway, highly recommend the Valiant paper I linked earlier in the thread. He’s a fantastic communicator.
@elfprince13 a zksnark can be used when there is a publicly known function that accepts a private input (the “witness” or “preimage”) and produces a public output. The zk proof establishes (in a succinct and noninteractive way) that the function evaluated on the witness indeed has the claimed output result. This is the “statement” that is proved.