Litepaper

The Ethereum blockchain contains over 15 million blocks, in which over 1.7 billion transactions have occurred and over 200 million accounts have been created. This rich set of data can be accessed by any archive node or block explorer, but is currently inaccessible to smart contracts running on chain. Using new cryptographic tools such as zk-SNARKs, Relic Protocol gives smart contracts access to all of this historical data, enabling entirely new types of applications to be built on Ethereum.

Motivation

Smart contracts on Ethereum are limited to accessing data exposed by the Ethereum Virtual Machine (EVM), such as account balances, current block information, and their own storage. If smart contracts want to access data stored in another smart contract, it must have code that allows external access to that storage. Access to historical information is also extremely limited, with smart contracts only having access to the most recent 256 block hashes.

What if smart contracts could trustlessly and provably access any historical information about any Ethereum account, transaction, or block? We call these provable historical facts, Relics.

  • Soulbound tokens could be issued that provably certify qualities of an account, such as an its age, token ownership history, borrowing and lending history, and more. These tokens could set the foundation for the future of decentralized identity on chain.
  • Airdops could become more trustless, fair, and transparent. Instead of airdrops requiring a trusted admin to manually determine which accounts qualify, a project could simply query if an account meets the airdrop criteria, all on-chain and transparent.
  • New projects could reduce risk by restricting access to accounts that meet certain criteria, enabling new types of project launch cycles.

These few examples demonstrate that many new applications could be built with access to this information. We are confident that the community of Ethereum builders will find other ingenious use-cases.

Additionally, a rich identity ecosystem may require more than historical on-chain data. We provide access to other types of information that are attested rather than proven. This can include external account reputation, proof of attendance, and any other off-chain data. We call this attested information, Artifacts.

By combining Relics and Artifacts, we provide an on-chain data warehouse for smart contracts, enabling development of innovative decentralized applications that were not possible before.

Terminology

  • Relics
    • Provable facts, currently based on historical Ethereum state, Merkle-Patricia trie (MPT) proofs, and zero-knowledge (ZK) proofs
  • Artifacts
    • Attested facts, currently used for off-chain data
  • Soulbound tokens
    • Non-transferable ERC-721 tokens that are minted from relics or artifacts
  • Historical Ethereum state
    • Information about the Ethereum blockchain at any point in time, including block headers, accounts, storage, transactions, and event logs

Products

  • Relics
    • Prove facts about an account using historical Ethereum state and MPT proofs
    • For example:
      • Did an account exist in the world state at a specific block number?
      • Did an account have a certain amount of ETH at a specific block number?
      • Did an account own a specific NFT at a specific block number?
  • Artifacts
    • Attest facts about an account with a signature from Theori
    • For example:
      • Did a user attend a conference?
  • Historical Ethereum state
    • Query for historical Ethereum state which is proven with ZK proofs and MPT proofs
    • For example:
      • What value is in a smart contract's storage at a specific block number?
      • What was the base gas fee at a specific block number?
      • Was there a smart contract event log produced at a specific block number?

Technology

Relic is built on a secure foundation of Merkle tree proofs, Merkle-Patricia trie proofs, and zk-SNARKs. These technologies allow Relic to prove facts about historical Ethereum state without relying on a trusted party. Developers and users can rely on Relic with the knowledge that the Relic developers cannot provide false information.

Zero-knowledge proofs provide the means for Relic to efficiently learn about old and new Ethereum blocks. Scalability is essential to building a sustainable system that is not too expensive for developers and users. A naive approach of adding one block hash (or even 256 block hashes) at a time will quickly become unsustainable if gas fees rise to historical highs. By leveraging zk-SNARKs, Relic is able to prove the validity of any number of Ethereum blocks at once. For example, Relic can validate over 1,000,000 block hashes in a single transaction, reducing gas costs by up to 99%.

An important development in zero-knowledge proofs was the PLONK proving system which has a universal trusted setup. This eliminated the need for a trusted setup for individual circuits. There is no trusted setup for Relic and the Relic developers have no toxic material that could be used as a backdoor. Relic uses the same universal trusted setup files as Aztec and zkSync, which were built with a trusted setup that included 176 participants, including many respected Ethereum community members.

While zk-SNARKs are very powerful and can represent any circuit, the proving time grows as the circuit grows in size. Additionally, the Relic circuits need to implement Keccak-256 which is notoriously inefficient in PLONK. Relic takes two approaches: UltraPLONK and aggregation. UltraPLONK is an improved version of PLONK with lookup-tables and custom gates, which improves the efficiency of hash functions and elliptic curve operations in circuits. Aggregation enables Relic to combine two or more small proofs into a new small proof.

Using these improvements to zk-SNARKs, Relic can construct a provably correct Merkle tree root that includes any number of block hashes. The circuit proves that each block hash corresponds to a block header, and that each block header is properly linked by the parent hash field in the block header. The zero-knowledge proof can be efficiently verified on-chain and the Merkle tree root stored on the blockchain.

Using Merkle tree proofs and these stored Merkle tree roots, Relic can prove the block hash of any historical block number. Merkle tree proofs use a cryptographic hash function, for example SHA-256, and allow for succinct proofs that can be efficiently verified. For example, if a Merkle tree contains 8,192 block hashes, then a proof that a block hash is in the Merkle tree requires only 416 bytes of calldata and 13 SHA-256 hash operations. This is signifcantly cheaper than an on-chain verification of a zk-SNARK.

With these proof systems, Relic can prove that a block header is in the Ethereum blockchain. An Ethereum block header contains several important fields: block number, timestamp, world state trie root, transaction trie root, and receipt trie root. Using Merkle-Patricia trie proofs, Relic can prove many interesting facts about that block, including:

  • That an account exists (or doesn't), and the values of its balance, nonce, code hash, and storage slots
  • That a transaction was executed (or wasn't), and its receipt, including any event logs that were emitted.

This data allows Relic to prove many facts, for example, an account's ERC-20 balance or an account's ownership of a NFT.

The combination of these technologies give rise to Relics, provable facts based on historical Ethereum state, without a trusted party and without unsustainable gas fees.

Fees

The Relic Protocol has costs to upkeep, and therefore must collect fees from its usage.

  • Users pay fees in ether (ETH)
  • In the future, third-party developers may choose to pay-per-use with ETH or pay for a subscription with USD
  • Based on feedback from users and third-party developers, we may introduce a token to use for payments
  • Fees may change, but actions that currently require a fee correspond to the features which have upkeep costs:
    • Verifying a historical block hash + header's validity
    • Proving a relic or an artifact

Roadmap

  • Developer SDK for facts
    • Provide third-party developers with an easy to use SDK to access facts about an account
    • Many use cases, but one example is airdrops based on account age to prevent sybil attacks
  • Developer SDK for historical state
    • Provide third-party developers with an SDK to access historical Ethereum state on-chain
  • Reputation artifacts
    • Determine an account's reputation using off-chain data and provide users with an artifact they can use to attest their reputation
  • Complex relic conditions
    • Use zero knowledge proofs to verify relic conditions that would require too much gas using only MPT proofs
  • Multichain
    • Bring Ethereum state to other blockchains without a trusted bridge
Table of Contents