Automata Docs

Zero Knowledge Proof

Prove the validity of computation without compromising privacy
Zero-knowledge succinct proofs are cryptographic techniques that hold significant capabilities in the realm of secure and private computations. Zero-knowledge proofs enable one party to convince another that a statement is true, without revealing any additional information beyond the truth of that statement. These proofs are succinct, meaning they are non-interactive, concise, and quickly verifiable. As a cryptographic building block, zero-knowledge proofs provide a foundational layer for constructing more private and secure systems across a range of applications.
Take for instance: device attestation statements. These statements are digitally signed proofs generated by trusted sources like secure modules, often containing identifiable particulars about a device or entity. They can be used to verify the identity of devices, secure boot processes, and ensure the integrity of devices' current operating configuration. Zero-knowledge proofs come into play here, enabling the validation of such statements without compromising confidential data, such as model numbers, manufacturers, or serial codes.
Let's consider an example where zero-knowledge proofs can be used to verify the authenticity of a user's smartphone without revealing sensitive information about the device.

Scenario: Verifying Legitimate Smartphone Ownership

Alice wants to prove that she owns a legitimate smartphone without disclosing specific details about the phone, such as the model, make, or serial number. The verifier needs to ensure that Alice's claim is genuine before granting her access to a restricted application or service.
Here's how zero-knowledge proofs can be employed in this scenario:
  1. 1.
    • The smartphone manufacturer provides Alice's smartphone with an attestation statement or a mechanism in which the attestation statement can be generated, which certifies that the smartphone is genuine and secure.
    • The attestation statement is linked to a device root of trust unique to Alice's smartphone.
  2. 2.
    Generating a Zero-Knowledge Proof:
    • Alice generates a zero-knowledge proof that demonstrates she possesses the attestation statement without revealing the statement's content or the device's root of trust.
  3. 3.
    • The verifier receives Alice's zero-knowledge proof.
    • Using the zero-knowledge proof, the verifier can confirm that Alice has a valid attestation statement without gaining access to the specific details of the statement or the device root of trust.
  4. 4.
    • The verifier is assured that Alice's smartphone is legitimate and secure, as validated by the attestation statement.
    • Alice's privacy is preserved since she hasn't disclosed sensitive information about her smartphone.
In this example, zero-knowledge proofs enable Alice to demonstrate ownership of a legitimate device without revealing information that could potentially compromise her privacy or security. The verifier gains confidence in Alice's claim without needing to know the exact details of the device's make and model, ensuring a balance between trust and privacy.
Another application of zero-knowledge proofs lies in off-chain computing. They allow complex computations to be performed off the blockchain while offering a way to validate the accuracy of these computations on-chain, thus relieving the blockchain network of excessive computational load expanding the types of verification or attestation that we can do on-chain. Take signature verification for example, Ethereum adopts the usage of ECDSA over a Koblitz curve (secp256k1) making signature aggregation hard. On the other hand, while Boneh-Lynn-Shacham (BLS) signatures over the BLS12-381 curve allow us to have highly efficient signature aggregation, it is not natively supported on Ethereum, making it expensive to verify. Instead of trying to verify the signature on-chain, we can instead off-load this computation off-chain and make use of a Succinct Non-Interactive Argument of Knowledge (SNARK) proof to show that we have properly verified the signature off-chain and that it is correct.
Let's consider the example of Automata's VRF where we utilized Drand, a distributed randomness beacon, as a source of our entropy. The randomness that is produced by Drand is simply the hash of a threshold-BLS signature of the round. Thus, we can attest the integrity of Automata's VRF entropy source by verifying the signature of the current round. This is done off-chain using a SNARK circuit and the attestation is simply the proof of a successful verification.
Let's consider the example of how Automata's Verifiable Random Function (VRF) uses Drand as an entropy source and attests its integrity using off-chain verification with a SNARK circuit.

Scenario: Verifying Automata's VRF Entropy Source

  1. 1.
    • Automata's VRF uses the Drand service as its entropy source. Drand produces randomness through a threshold-BLS signature of the current round.
    • The goal is to ensure the integrity of Automata's VRF by verifying the validity of the signature from the Drand service.
  2. 2.
    Off-Chain Signature Verification using SNARK:
    • The producer asserts the statement "a given signature corresponds to the signing of a specific hash using the private key that corresponds to a provided public key"
  3. 3.
    SNARK Proof Generation:
    • The VRF producer provides a SNARK circuit that takes three inputs: public key, signature, and hash.
    • This circuit generates a cryptographic proof that demonstrates the relationship between the provided inputs: that the signature indeed corresponds to the private key holder's signing of the hash.
  4. 4.
    Validation on Chain:
    • The VRF producer submits the SNARK proof and the three inputs (public key, signature, and hash) to a smart contract on the blockchain.
    • The smart contract validates the SNARK proof using its cryptographic properties, ensuring that Alice indeed performed a successful verification of the Drand signature off-chain.
    • The smart contract then verifies that hash(signature) == randomness value.
  5. 5.
    Integrity Attestation:
    • If the smart contract successfully verifies the SNARK proof, it accepts the VRF producer's claim that the statement holds true.
    • The smart contract can record this attestation on-chain, providing an auditable and tamper-proof record of the VRF's integrity.
By following this process, Automata's VRF producer can demonstrate the integrity of the entropy source through the utilization of SNARK circuits and off-chain verification, while the smart contract on-chain ensures the validity of the claim. This approach combines cryptographic security with efficient verification, enhancing trust in the integrity of the VRF's entropy source.