# zkAttestor: Trustless on-chain Ethereum indexing

Although Ethereum has a large set of on-chain data, only the small portion of current **state** data is available for use in smart contracts. This means on-chain data like historical state, **transactions** and **receipts** are not available for use in dapps. With this enhanced set of on-chain data, dapps could deliver richer experiences:
* A mining DAO could trustlessly slash miners for mining a sandwich attack.
* A new lending protocol could offer better terms to past Aave or Compound users.
* A defi protocol could update its risk parameters based on the worst loan-to-value achieved over the past week.

**zkAttestor** solves this problem with the magic of zkSNARK proofs. It produces zkSNARK-based attestations to data from any Ethereum state or block, trustlessly verified on-chain. By using zkAttestor, downstream applications can access historical block or state information for use cases like on-chain reputation, programmable identity, and defi primitives involving history.

## What is zkAttestor?

zkAttestor consists of two components:
* The `ZKAttestor` smart contract on Ethereum which validates claims about historical states, transactions, or receipts on Ethereum and stores them on-chain.
* A permissionless off-chain proving service which generates zkSNARK proofs of such claims and allows users to put them on-chain.


To use zkAttestor to prove a claim about historical state (e.g. "I owned CryptoPunk #1 at block 14194126."), a user can:
* Query an archive node to get an **Ethereum light client proof** of the claim.
* Use the zkAttestor ZK circuits to produce a **zkSNARK proof** that the light client proof is valid.
* Submit the zkSNARK proof to the `ZKAttestor` smart contract, where it will be verified on-chain and checked against a trustlessly cached set of Ethereum block headers.

Initially, we will operate an off-chain proving service to automate this process for users, but the entire process is **permissionless** and **trustless**. Users are always able to generate their own proofs and they do not need to trust any aspect of our proving server -- the resulting zkSNARK proofs will be verified on-chain. Our live demo at [zkattestor.xyz](https://www.zkattestor.xyz) illustrates this process with live contracts deployed on the Goerli testnet.

## What can I use it for?

zkAttestor can be useful for any protocol or dapp where historical on-chain data is important. A few of the initial applications we envision include the following.

### On-chain reputation
By enabling access to the past transaction history of Ethereum accounts, zkAttestor enables dapps to construct reputations for them based on their past on-chain activity. For example, zkAttestor could prove the claim "Address ABC has repaid a loan of at least 1 ETH on Aave", which may make the owner of ABC a good candidate for a referral bonus for a competing lending protocol. Unlike existing approaches to reputation, this reputation can be computed and verified independently of any trusted third party.

### Programmable identity
Experiments such as [Cabal](https://www.cabal.xyz/), [heyanon](https://www.heyanon.xyz/), and [Sismo](https://www.sismo.io/) allow users to show they are members of a certain on-chain group (e.g. CryptoPunk owners) but use zero-knowledge to avoid revealing other facts about their identity. Because they do not have access to the on-chain Ethereum state within a SNARK, these applications rely on a trusted third party to create groups. zkAttestor removes this trust assumption and enables applications to use arbitrary on-chain criteria for group membership.

### Application primitives involving history

Applications use two approaches today to work around limits on state access to deliver richer functionality. One approach involves caching historical information using expensive checkpointing, like for [Uniswap's TWAP computation](https://docs.uniswap.org/protocol/concepts/V3-overview/oracle) or ERC-20 tokens using [Compound governance](https://github.com/compound-finance/compound-protocol/blob/a3214f67b73310d547e00fc578e8355911c9d376/contracts/Governance/Comp.sol#L233), where extra gas is used on *every token transfer* to cache governance weights. Another approach is to use trusted off-chain governance or oracles, like [Gauntlet's parameter updates for Aave](https://app.aave.com/governance/proposal/70/) or [Chainlink oracles](https://data.chain.link/).

zkAttestor provides a more efficient and trustless approach. By giving smart contracts historical state information, it removes the need for checkpointing. For example, zkAttestor enables developers to compute Uniswap v2 TWAP over any time interval without any prior checkpointing. Furthermore, zkAttestor can completely remove the use of trusted third party for access to on-chain data, resulting in fewer necessary trust assumptions for users.

## How do I integrate with zkAttestor?

Developers can integrate with zkAttestor in two ways. The simplest method, live on testnet today, is to call into the `ZKAttestor` smart contract to verify historical state. We provide an `attestSlot` function which accepts a claim of the form "the value at `slot` for `address` at `block` was `value`", verifies it in a zkSNARK proof, and stores the outcome on-chain. Users of your application can call this either synchronously or asynchronously and then use the verified historical state in your application.

In the near future, we are developing a method for smart contracts to use zkAttestor via a trustless off-chain callback system inspired by the [EIP-677 standard](https://github.com/ethereum/EIPs/issues/677). In this system, developers can:
1. Post a request for a zkSNARK proof of a claim by emitting a `ZKAttestorRequest` event.
2. Rely on a permissionless network of provers to generate a zkSNARK proof of the claim.
3. Have an arbitrary callback triggered on-chain by any prover after the zkSNARK is trustlessly verified in the `ZKAttestor` smart contract.

This system will be similar to the way existing smart contracts integrate with oracles like Chainlink, but will be completely permissionless and trustless. Because zkSNARKs can be verified on-chain, we can allow anyone in the world to submit a SNARK and trigger the callback. This means developers do not need to trust the liveness of any permissioned entity for execution of their smart contract code. Of course, in the initial deployment phase, we will run a proving server to ensure execution -- but you don't have to trust us!

## How does it work?

Each Ethereum block header contains commitments to the full Ethereum state as well as transactions and receipts in that block. Using these commitments, Ethereum **light client proofs** enable a recipient to trustlessly validate any information about an Ethereum state or transaction against the block hash. These consist of proofs of Merkle-Patricia trie inclusion, which can be large and costly to post directly on-chain. Furthermore, the EVM only provides access to the 256 most recent block hashes, meaning older block hashes must be cached to allow for trustless verification.


zkAttestor solves these issues by operating a smart contract which periodically caches trustlessly verified block hashes from the EVM on-chain. We then generate zkSNARKs to trustlessly prove light client proofs for on-chain data are correct. zkAttestor then verifies these zkSNARK proofs on-chain and checks that they are consistent with the cached set of block hashes. If these checks pass, the resulting claims about Ethereum history are valid.

## What's next?

As we move towards productionizing the current testnet version of zkAttestor, we are looking for early integration partners to use zkAttestor. We are actively iterating on the smart contract interface and the sophistication of statements we can prove, and would like your feedback on what can make zkAttestor most useful for your application.

If you would like to learn more:
* Try our live demo of zkAttestor on Goerli testnet at [zkattestor.xyz](zkattestor.xyz).
* You can check out our open-source circuit code at https://github.com/yi-sun/zk-attestor.
* Watch our talk at DevConnect 2022 at https://www.youtube.com/watch?v=2-yYtEJdrFY.
* Follow us on [Twitter](https://twitter.com/zkattestor) and join our [Telegram](https://t.me/zkattestor).

To discuss possible applications, or if your project would like to be an early integration partner, reach out on Twitter at [@zkattestor](https://twitter.com/zkattestor)!