Automata Docs
  • Understanding Automata
    • What is Automata?
      • TEE Coprocessor
      • Proof of Machinehood
        • Optimistic Attestation
        • Zero Knowledge Proof
        • Modular Trust
    • Key terms
  • TEE Overview
    • TEE Prover
    • Multi-Prover AVS (EigenLayer)
      • Operator guide
        • Installation
        • Deposit strategies
        • Opt in to run AVS
        • FAQ
    • TEE Compile
      • Getting Started
      • Vendorizing
      • Attestation Report
    • TEE Builder
      • Block Builder Architecture
      • Stateless Executor
    • Verifiable Random Function
      • Why Automata VRF
      • How does Automata VRF work
      • Attestation
  • Build with PoM
    • Introduction
      • Smart contract libraries
      • Attestations on Verax
      • Frequently asked questions
    • Attestation module
      • Machine Attestation
        • Intel SGX
        • AWS Nitro Enclaves
        • Miscellaneous
      • Device Attestation
        • Yubikey
        • Andriod
        • Apple
        • Windows
        • FIDO U2F Authenticator
      • WebAuthn Attestation
        • WebAuthn Attestation Types
        • Attestation Statements & Privacy Impacts
  • Backed by PoM
    • 1RPC
    • L2Faucet
      • Frequently asked questions
  • Protocol
    • App-Specific Rollup
    • Mainnet
    • Testnet
    • Bridge
      • Bridging Native Tokens from L1 to L2
      • Bridging Native Tokens from L2 to L1
    • Explorer
    • Specification
      • Attestation
      • Attestor
      • Smart Contract
  • Research
    • Account Abstraction
    • Decentralized Randomness
    • Maximal Extractable Value
    • Reproducible Build
    • Lightpaper
Powered by GitBook
On this page

Was this helpful?

  1. TEE Overview
  2. Verifiable Random Function

Attestation

PreviousHow does Automata VRF workNextIntroduction

Last updated 12 months ago

Was this helpful?

There are 4 kinds of verifiable attestations happened in Automata VRF in Automata 2.0. The dependencies among these attestations can be found in .

Attestation: TEE software program

Type:

The TEE program arrives at a reproducible MRENCLAVE value when rebuilding the code in a base builder docker hosted in AWS Nitro Enclave. Find more details in .

Because the whole compilation is reproducible and the attestation is provided by the builder docker which already attested by the AWS Nitro Enclave, we leverage the root of trust from the AWS Nitro Enclave and choose optimistic attestation, which doesn't provide a challenge method during this attestation.

Attestation: TEE hardware

Type:

Current Automata VRF is hosted in Azure, which uses to finish the TEE attestation, which ensure the hardware execution environment and the running code is matched as expected.

Since the Intel DCAP Quote verification is quite complicated and it will cost a lot of gas, we choose to use consensus-based attestation and introduce a certain of the trusted parties' attestors to validate the correctness of the quote uploaded by the off-chain TEE VRF Oracle.

Attestation: DRAND Input parameters

Type:

Leveraging the BLS12-381 curve verifiable provided by , other than the BLS verification in the off-chain TEE VRF worker, this parameter is also able to be verified on chain.

Attestation: TEE submitted randomness

Type:

Based on the , since the signers in the workers are known in advance, the submitted randomness can be attested and verified on chain by recovering the signer.

TEE Compile
Intel DCAP
circuit
0xPARC's circom-pairing
attestation protocol
Optimistic Attestation
Consensus-based Attestation
Verifiable Attestation
Verifiable Attestation
Trusted Off Chain Oracle Workflow