Comparison

vs Axiom

Block Hash Oracle

In order to verifiably access Ethereum state, you first need to know the hash of the block containing the data. Unfortunately, the EVM only exposes the previous 256 blockhashes, so trustlessly accessing older data on-chain requires some magic. Both Relic and Axiom use ZK-SNARKs to verifiably compress the block hash history into Merkle trees, allowing smart contracts to efficiently verify block hashes all the way back to genesis. Our ZK-circuit design for this process was documented in our medium post, and Axiom’s design is quite similar.

State Proof Verification

Once you have a verified block hash, the state inside the block can be verified via Merkle-Patricia-Trie (MPT) proofs. The primary difference between Relic and Axiom is in how these state proofs are verified. Relic verifies the MPT proofs directly on-chain via a highly optimized Solidity verifier, while Axiom verifies the MPT proofs inside of a ZK-SNARK. While Relic also has ZK-circuits for MPT verification, they are not yet used in production, due to the inherent tradeoffs:

1. Gas costs: SNARKs are expensive to verify on-chain (~500k gas), while well-optimized EVM code can verify MPT proofs for much cheaper (~100k on average). However, a SNARK verifier can theoretically verify multiple MPT proofs simultaneously for the same flat gas cost, while the native MPT verifier’s cost multiplies with each fact.
2. Proof times: SNARK proofs can take minutes to generate, while fetching a raw MPT proof from an archive node takes less than a second.

We believe most use-cases will require only a few state proofs, and thus will be cheaper and faster using on-chain MPT verification rather than on-chain SNARK verification. See the table at the end of this post for a direct comparison of gas costs and proof times for each of the demo applications.

If a use case requires access to lots of historical state, aggregating the state verifications into a single SNARK will likely reduce overall gas costs. In these cases, the long proving times may be worth the gas savings. In fact, Relic’s ephemeral facts system unlocks the possibility of aggregating state proofs from different applications into a single SNARK, potentially reducing gas costs for even the most simple use-cases. Expect more details on this soon!

Although ZK-SNARKs also have privacy preserving properties, this is not relevant for most use cases. If a user needs to associate their public address with a fact that they prove, then they will not benefit from doing their proof “in secret”. It is possible that some specialized use cases may benefit from privacy preserving proofs, but this will also require that the ZK-proofs are generated by the user rather than a third-party prover.

dApp Integrations

Another major benefit to on-chain MPT verification is that integrations become much simpler. Relic has open SDKs, allowing any Ethereum developer to tap into historical state in their applications. Axiom’s approach thus far requires building a custom low-level ZK-circuits for each use-case, which are both difficult to develop and difficult to reason about.

Every Relic demo application is written in Solidity and Typescript using the public Relic SDKs, demonstrating that any Ethereum developer can build these powerful applications without needing to write complex ZK-circuits.

Relic’s smart contracts were designed with both immutability and extensibility in mind. Relic’s core smart contract is the Reliquary (a container for Relics), which serves as both a central fact registry and an extensible prover registry. The Reliquary code is immutable, but allows Relic governance to add new fact proving modules with efficiency, usability, or security improvements. Every fact stored in the Reliquary is immutably tagged with its prover, allowing other dApps to choose the level of extensibility that fits their use case, whether it be full immutability or full forward-compatibility.

Currently, Axiom requires each dApp to be responsible for deciding which Axiom contracts store and prove each piece of data. Furthermore, there is currently no unified interface for proving and accessing data, which requires ad-hoc handling by on-chain applications.

Scaling Approach

One large benefit of performing state verification in ZK-circuits is that it enables additional verifiable computation to be performed on the data before bringing it on chain. To this end, Axiom promises to enable applications which are otherwise too expensive to run on-chain.

However, expensive computations are not only expensive on-chain; they are also expensive to prove using ZK-circuits. This expense manifests as latency (high proving times) and server costs. The upside is that these costs are borne by only one party, rather than every Ethereum node. The downside is that it reintroduces centralization risks. Correctly written ZK-circuits ensure computational integrity, but they do not ensure liveness or censorship-resistance. These properties can be achieved with a decentralized set of incentivized provers, but this is a difficult problem which even many ZK-rollups have yet to fully solve.

Relic’s approach to scaling verifiable compute is simple: don’t reinvent the wheel. Thanks to the hard work of many teams (zkSync, Polygon, Scroll, Consensys, Kakarot, etc), various types of ZK-EVMs are now a reality. As a result, Relic’s existing EVM state verification can be seamlessly composed with any EVM-compilable language (e.g., Solidity) for arbitrary verifiable computation. This approach both simplifies developer integrations and enables tapping into existing decentralized proving networks (for instance, those powering ZK-rollups).

It’s clear that ZK-SNARKs are crucial to scaling verifiable computation, and Relic intends to build on the most Ethereum-aligned and developer-friendly ZK tech: ZK-EVMs.

Demo App Comparison

Note: Relic’s exact gas costs vary slightly from proof-to-proof, so these values are approximate. Each row is an apples-to-apples cost comparison of performing the same proof, using the default values from the Axiom demo page where possible.

If you’d like to try out the demo apps, you can’t find Relic’s demos here and Axiom’s demos here. The source code for the Relic demos can be found on GitHub.

Birth Certificate / Account Age

Axiom’s Account Age demo is comparable to Relic’s Birth Certificate app, in that they both use state proofs to prove an Ethereum account’s age on-chain. However, Relic’s app also mints the user a fully on-chain Soulbound Token to show off. Despite the additional functionality, Relic’s app still uses substantially less gas and generates the proof in less than two seconds.

UniV2 TWAP

Uniswap V2 was designed with time-weighted average price (TWAP) oracles in mind. To compute the TWAP of any asset pair between any two blocks, you only need to access the pair’s on-chain state at each block. Before Relic and Axiom, this was difficult to do on-chain because accessing old contract state was prohibitively expensive. Now, we can build completely trustless on-chain TWAP oracles with very reasonable costs!

This is the most complex of the demo apps, as it verifies multiple storage slots at each block. Despite this complexity, Relic’s optimized MPT verification still uses less gas for nearly every TWAP calculation, including popular trading pairs like ETH / USDC.

RANDAO

This simple demo app allows trustless access to the RANDAO value from any post-merge Ethereum block. Note that RANDAO is slightly biasable by Ethereum block proposers, so this value should not be used as a perfectly fair random value. Paradigm recently published a randomness beacon design combining RANDAO with VDFs to produce fully unbiasable and trustless random data on-chain.

For this demo, both Relic and Axiom are low-cost, because RANDAO values are stored directly in Ethereum block headers, so no MPT proof verification is needed.

Custom (storage slots)

Relic supports proving many types of historical state, including log emissions, storage slots, and more! If multiple storage slots from the same contract and block are required, Relic’s MultiStorageSlotProver gives an efficient way to batch prove storage values. Axiom’s “Custom” demo gives a similar capability (currently limited to 10 slots), but for a fixed proof verification cost (the only variable cost is due to on-chain storage). As a result, Axiom’s demo is cheaper when simultaneously proving more than 6 slots from the same account.

Conclusion

The biggest difference between Relic and Axiom is how state proofs are verified: Axiom verifies all state proofs in ZK-SNARKs, while Relic uses both ZK-SNARKs and on-chain MPT verification to minimize the high costs and latency of ZK proving. Developers can integrate with Relic using Solidity and Typescript (rather than through custom ZK-circuits), and ZK-EVMs allow for substantially more complex apps to be built on Relic while remaining entirely trustless.

If you are interested in building a history-powered dApp, check out our SDKs and feel free to reach out to the Relic team on Discord with any questions or feature requests!