Dismantling the technical advantages of Ethereum ZK coprocessor Axiom

Author: Mask Network

At the ETHShanghai 2023 summit, Axiom founder Yi Sun introduced Ethereum's ZK coprocessor Axiom and its importance in terms of data access and computing power. Axiom realizes the expansion of data access and calculation through the concept of Reflection operation, and realizes the validity of the query by verifying the hash chain and maintaining the cache. Applications for Axiom include high-cost applications, larger data access, applications based on historical data management protocols, and more. Through Axiom, smart contracts can obtain broader data and computing power, further promoting the development of Ethereum applications.

The following text is the Chinese compiled version of Yi Sun's speech, and the link is the live video:

First, let's understand the user journey of actually accessing Ethereum information. When we were first using Ethereum, the way we actually received information about what was happening on-chain was through JSON-RPC calls to archive annotations. The purpose of the JSON-RPC API is to actually present information about the on-chain history to the user. Essentially, all the information we see about the blockchain is extracted from these API calls and presented as an entry on the website for the user to read.

Now, as users become more adept at interacting with the blockchain, we're starting to require increasingly complex views of the chain. Therefore, different types of archive nodes are being developed for different user tradeoffs. So there was Geth, Erigon, Nethermind, and now Reth. We can choose the most suitable archive node according to our own needs.

If users are not satisfied with a separate JSON-RPC API, an indexer can be chosen to apply post-processing while tracking transactions. For different applications, users may be interested in data returned from The Graph or Covalent.

More recently, there have also been wallets and other products that offer transaction simulation on top of archive nodes. This means we can see the actual outcome of a virtual transaction before committing it. Overall, as end users, the way we interact with Ethereum is getting more sophisticated, using more computation on top of the data we read.

Now, if we think about it not from the perspective of a user, but from the perspective of a smart contract on Ethereum. Of course, contracts also want to be able to access data and perform computations on it, but this is more challenging. In fact, if we go to OpenSea and look at the list of CryptoPunk, we will find that of all the information on the page, only a small part is accessible in the smart contract on the chain.

In fact, for CryptoPunk's listings, this information is only for current holders. Of course, there is a lot of other information on the page, but all information related to historical transfer information, historical prices, and historical holders is actually inaccessible to the smart contract because it belongs to the past history. These histories constitute on-chain information, but they are not available to smart contracts because we need to avoid forcing every full Ethereum node to maintain this information in its random access to verify transactions.

Also, as any blockchain developer can tell you, running computations on-chain is prohibitively expensive, although Ethereum has relatively efficient virtual machine (VM) operations, and precompilation makes certain types of operations cheaper. For example, Ethereum provides relatively cheap support for elliptic curve operations on the BN254 curve. However, for some specific applications, the Ethereum Virtual Machine is still a very expensive runtime environment. When designing a blockchain virtual machine, one must choose an inherent set of operations that need to be carefully metered to ensure that each node can verify transactions at a consistent time. In addition, worst-case security and consensus stability must also be considered. So the challenge here is how to implement application-specific scaling for on-chain applications. Axiom aims to expand data access and computing capabilities for smart contracts to meet the expansion needs of different applications.

What Axiom is building is what it calls an Ethereum Coprocessor (ZK Coprocessor), which allows certain smart contracts to trustlessly delegate to our off-chain system so that they can delegate data reads and verifiable computations to Axiom . To issue a query to Axiom, a smart contract can send a transaction to our on-chain system. Our offline node will receive the transaction and generate a result based on Ethereum's historical query, and attach a zero-knowledge proof to prove the correctness of the result. Finally, we verify the results on-chain and credibly deliver the results to downstream smart contracts.

This is similar to how the CPU in a computer delegates computation to the GPU, and fetches the results back when they are known. This concept was called coprocessor (Coprocesso) in the early days. On the slide I show an image of an advanced math coprocesso from the early 1990s that is analogous to what the Axiom does.

We can gain insight into what types of operations Axiom can perform Each query to Axiom can be broken down into three parts.

The first is the reading part, which is how Axiom queries are entered - we can reliably read historical on-chain data.

The second part is that we can run validation computations on this data. This might start from basic analysis, like summing some numbers, finding the maximum or minimum, to more complex calculations. For example, some signature aggregation or verification from cryptography, and even zero-knowledge-based machine learning, such as verifying the operation of certain reputation algorithms on social data on the chain or using certain machine learning algorithms in financial applications. Ultimately, we will provide programmable computing composite functions through virtual machines.

The last part, after the read and compute steps, we get a result and always pair that result with a zero-knowledge proof that the computation of the result was valid. Therefore, we verify this proof in the Ethereum smart contract, and then store the result for use by the contract.

Since all results returned by Axiom are actually verified with zero-knowledge proofs, this means that the security of everything returned by Axiom is cryptographically equivalent to that of Ethereum itself. Axiom's philosophy is that we don't want to impose any additional assumptions on users beyond the cryptographic assumptions they already have using Ethereum.

Next, I will introduce its implementation principle in detail, which involves the concept of Reflection operation mentioned in the title of the speech. The core principle that makes it all possible is that every block on the blockchain contains a complete history. We can start at the current Ethereum block and work our way back to the earlier blocks we are interested in. By taking all the block headers between the past block and the current block, and by verifying the hash chain of these block headers, we can actually reverse the commitment of the past block to the current block.

So what are the benefits of Reflection?

We can take a block of the current Ethereum and go back to a previous block we are interested in. If we get the block headers between the past block and the current block, we can reverse the commitment of the past block into the current block by verifying the hash path between these block headers. Then, if we are interested in some information from a past block, we can give a proof of inclusion in that block's commitment. Specifically, this could be a Merkle Patricia Trie proof that the information exists in the block's state trie, transaction trie, or receipt trie. In the EVM, at least in principle, any past information on the chain can be accessed only through knowledge of recent block hashes.

Unfortunately, doing this in the EVM is expensive. As just mentioned, you have to verify the hash chains and Merkle proofs of all block headers, which involves many Keccak hash calculations on a large amount of data. So once you go back in time, it becomes very difficult. Therefore, we apply the Reflection operation by wrapping this proof with ZK in the EVM. So instead of putting all past block headers and all these Merkle proofs on-chain and then verifying them, we check in zero-knowledge whether there is a sequence of past block headers and some proofs of verification.

This has two advantages. First, it saves us from having to put proof data in call data. Second, it allows us to aggregate proofs, which is unthinkable without the use of ZK. The idea here is that when verifying any number of computations on Ethereum, the gas cost is fixed, so we can use a single ZK proof to verify a large amount of historical data access.

Let me briefly touch on the trade-offs of the ZK-based Reflection operation concept.

There are two ways to access data. The first is the way you know about it before - you can access data on Ethereum directly from the smart contract. This has the very big advantage that access is synchronous. Therefore, you can directly call the read function in the smart contract to get the current value. For example, when you trade on Uniswap, you need this synchronicity. However, it also has many limitations. Your computing power is limited by fuel costs and you don't have access to any historical data.

Second, if you want to take advantage of ZK's ability to reflect into Ethereum, because you have to generate proofs that your access is correct, there is no way to do it synchronously. So there's actually no direct access to the current on-chain state, because you have to attest to a state.

On the other hand, if you allow yourself to access historical data asynchronously, you can apply almost unlimited computations to it and have access to huge amounts of data. Therefore, by relaxing the concept of synchronization, ZK-based Reflection operational data access can be greatly expanded.

We then look at how to implement Reflection operations through Axiom.

First, we actually have to maintain a cache of all previous blocks in our smart contract. In the EVM, the last 256 block hashes are available natively. We can prove that in every batch of 1024 blocks, the hash of the last block of the previous batch is committed in the next block. Likewise, the hash of the second-to-last block in the previous batch is committed in the last block, and so on. Therefore, we can reverse verify this hash chain and prove the validity of this hash chain through zero knowledge.

This allows us to cache block hashes starting from the most recent block all the way up to the genesis block. In fact, we have implemented this in our mainnet smart contract, which contains cached Merkle paths every 1024 block hashes from the genesis block.

Another feature we are adding is Merkle Mountain Range. It's built on top of this block hash cache, a data structure that allows us to reference every block hash in Ethereum in a limited DNA.

Once we have built the cache, we can query Axiom by validating the blocks in the cache. In order for this to work, we have to prove that every piece of data in the Ethereum history we are trying to access is actually committed to being in some block's cache. Second, we have to prove that all computations we perform on this query are correct. To check this on-chain, we verify the validity of the zero-knowledge proof. We also check that it correlates with the information we have recorded on-chain. We always build trust in our caches or block caches and match information in those block caches with public information in zero-knowledge proofs.

Now let's talk about the possible applications of the Reflection operation envisioned.

The horizontal axis represents data complexity, how much data actually needs to be accessed to implement the application. The vertical axis represents computational complexity, which is how much computational resources actually need to be applied to complete the task.

Therefore, the first type of application is an application that Axiom or any type of Reflection operation mechanism can be implemented on Ethereum, but the cost is slightly higher.

Some examples of this include reading consensus-grade nonces from block headers in the Ethereum consensus layer, verifying historical account ages, or reading different types of oracle data from historical price information. In the EVM, various solutions can be employed to implement these applications, but by placing these solutions in zero knowledge, efficiency can be increased.

Now, there is another class of applications that generally require more data access and therefore more computation. In my opinion, these applications would not be possible without the use of the ZK coprocessor.

As an example, an interesting application is to allow a Roll-up on Ethereum to read the state of the base layer or another Roll-up in a trusted manner, using zero-knowledge to interact. One such application might be to allow Roll-ups to read full balance snapshots of ERC20 tokens.

If we turn our attention from storage to the transaction history of accounts, you can imagine building a trusted reputation, identity or credit scoring system by recording the complete history of Ethereum addresses. This could be used for credit scoring, or to give you access to some type of on-chain DAO, or to give you access to issue custom NFTs.

There is also a class of applications that use on-chain historical data to actually manage the protocol. Generally known as agreement accounting.

The idea here is that protocols exist to coordinate the behavior of participants, and the basic principle of coordination is the ability to reward or punish participants for their behavior. If you look at many protocols on Ethereum, the record of the actions of the participants is actually kept entirely on-chain. So, with Axiom, we can imagine that based on the complete set of actions of protocol participants, the protocol can determine the payment structure, or even impose some type of penalty on the participants, which we think can really expand the design space of protocol applications.

Finally, if we really move up the level of computation, we think it might be very interesting to use machine learning models to tune parameters on-chain. If you think about traditional financial applications, it is very common to model complex future parameters based on large amounts of historical data, such as price data, economic data, etc. And when we look at the current DeFi, it is far from reaching that level. I don't think that DeFi should work exactly the same way as traditional finance, but we do think that injecting some historical databases and machine learning-based models and information may help create a more dynamic DeFi protocol.

These are just a few ideas of what Reflection operations can bring to the blockchain.