ZK Paris: Yi Sun - Using ZK to Enhance the EVM with Axiom

Transcript

okay up next we have using ZK to enhance the evm with Axiom by Yi Sun at Axiom uh hey everyone so one of the founders Axiom here to tell you how we're going to enable applications on ethereum to access more data and so I just want to start by covering how we typically access data on ethereum as users and that's through this Json RPC interface that all full nodes and

archive nodes expose and the purpose of this API is essentially to deliver information about the state of ethereum to the human eyeball so what would typically happen is a web front end would query the state of the chain through possibly through an external service or in rare cases through your own node and deliver this these numbers to your users and as things have progressed people demand increasingly more sophisticated ways to view this information there are many options for autograph nodes now and there are also indexers that make the information you get from an archive node more semantically meaningful and finally once you have that information now there are these fancy

wallets that will even simulate your transactions live against the state of the chain so this situation is extremely different from the situation for smart contracts from the point of view of a smart contract they are almost blind so it might be surprising that smart contracts can't access any historic on-chain information if you go to openc and pull up a listing for this cute pudgy penguin you'll realize that the only piece of information on the page that's actually accessible on chain is the boxed current owner which for this penguin is Zac Efron For Better or Worse all the other information on the page like the transaction history the

previous owners the previous prices that's not accessible on chain so you might think this is kind of a design flaw of ethereum like why don't we let contracts access more information but it's actually a fundamental trade-off that ethereum makes to remain decentralized if we allowed smart contracts to access the full history then every full node was would essentially have to become an archive node and have random access to the entire history of ethereum and that would obviously hurt decentralization now one thing that probably everyone knows is that compute on chain is very expensive so there are certain pre-compiles that make some operations cheaper but we're

not going to add arbitrary computation as pre-compiles the reason for that is to add a pre-compile to the evm or any blockchain VM we have to be very sure that it doesn't open up a DDOS attack Vector on transaction validation and it doesn't really make sense to use social consensus to go through a list of all computations so as a result we have this very data limited and compute limited on-chain compute environment so the question we asked at Axiom is how can we scale smart contracts to enable more data Rich on-chain applications and our answer is to use something we're calling a ZK co-processor so what that

means is we allow smart contracts to query into Axiom to do two things first to read historic on-chain data and second do some verified computations on top of that data after we do both of those things we come to a result and we generate a zero knowledge proof that that result was computed correctly we then verify the proof on chain and deposit the results in a smart contract for any other application to use so you might ask what types of things can we do well we can access the full history of ethereum and then we want to allow applications to run analytics cryptography or we hear machine learning

is very popular these days on this data no matter what we always verify a proof on chain of the data and what that means is that all the results that you get back from Axiom actually have security that's cryptographically equivalent to accessing data from ethereum itself okay so let me talk through how that's even possible so if you have a smart contract then it has access to the current block hash of ethereum and that block actually commits to the previous block of ethereum which commits to the previous block which all the way back commits to the Genesis block of ethereum

and each block of ethereum commits to the state and all transactions and receipts in that block so if you were to try to access ethereum history naively in a smart contract you would provide a Merkle proof of let's say a transaction into a previous block header and if that's a block header a million blocks ago you would provide all million intermediate block headers and then you would check the Merkle proof and the chain of cat Shack hashes of the block headers now of course that's extremely expensive and you can probably at best access a really small amount of data in this way so what we do at Axiom is put that whole computation into ZK so this lets us

compress the amount of compute needed on chain to verify the computation as well as compress the data we have to put on chain to do the computation so this lets us scale the data access and also compose it with other operations okay so dive a little bit more deeply we don't actually want to prove the full chain of one million ketchak hashes every if to access data from 1 million blocks ago so what we actually do on chain is we maintain a smart contract that caches the entire history of block hashes on ethereum back to Genesis and in order to enable queries into different blocks in one query let's say

an account from one block a storage slot from another block and a block header from yet another block we commit the entire history of block hashes in a data structure called a Merkel mountain range and as ethereum progresses we actually have to maintain this miracle mountain range by providing zero knowledge proofs on chain of the past Ketch act chain of blockheaders we do this every approximately 45 minutes now when we actually fulfill queries into the history of ethereum we always query against this chain this cache of block caches so what that means is we

verify Merkel Patricia tri-proofs of historic State addresses and storage slots into the cache of block caches and just to show more explicitly what we can handle in every ethereum block we have the block header which is the block number the block hash and commitments to the state transactions and receipts now on mainnet we can allow you to prove any property of an address namely the nonce balance code hash or storage route through an account proof or any storage slot into the storage route of any address

and this week we just launched on testnet proofs into any historic transaction or receipt in the history of ethereum so now I want to talk through okay all this technical stuff what are the actual applications that we think it can enable so I've drawn like a little diagram on the horizontal axis we have the data complexity namely how much historic data do you actually need to view in your smart contract to do this and on the vertical axis the compute complexity and they're actually roughly correlated if you have a large amount of data you generally need a large amount of compute to handle it so in the beginning we actually think that the applications are going to be

things that are possible in the evm but maybe a little bit inefficient they might require some additional caching or they might require some additional trust assumptions so things like accessing the consensus level Randomness from the beacon chain verifying your account age Computing some average prices or having a volatility Oracle these are things that maybe you can work around in your smart contract but are much more convenient if you can access history as we actually scale I think there's a new class of applications which are really only possible by using ZK reads into the history of ethereum these are things like verifying the entire checkpoints of erc20 balances of some

tokens Computing on-chain reputation by trustlessly proving your actions objectively slashing participants in a protocol for provable actions which violate some rules in your protocol or even adjusting the parameters of your defy protocol based on the full on-chain history of what happened so we're really excited about enabling new applications that actually rely on Smart contracts reading the history of the chain itself so let me just give a picture of where we are today and where we're going so today we've launched on mainnet reads to blockheaders accounts and account

storage and on testnet we have transactions and receipts and to do compute over those today you need to deploy a custom ZK circuit where we think ZK co-processing is going is to start by accessing the whole of on-chain data and then to actually do post processing on that data in a way that's most native to Smart contract Developers and we think that way is by applying view functions whose execution is proven using the ZK evm so this might seem like a bit of a pipe dream I mean the zkevm even seemed like a pipe dream a year ago we actually think this cut could come sooner than most people expect

and these first two steps together would constitute taking an entire archive node and putting it into ZK after that's done we think that the best thing is to actually leave the bounds of the evm and allow developers to start doing computations that are well beyond what's possible in a blockchain VM and we think that that'll be best through a ZK native VM so we've started building out this roadmap and we're pretty excited to see what it can unlock in the future so we're Axiom we're the ZK co-processor for ethereum and we just launched our main net two weeks ago so you can check out our developer docs and try us out fully self-serve using docs.axiom.xyz

and at the end of this talk I just want to put in a plug we think ZK is a bit too much of a black box for ordinary developers today so we started something we're calling the Axiom open source program to help change that so it's a program where we teach developers how to write ZK circuits and develop ZK applications in our first iteration of that program finished a couple weeks ago a couple of the participants are in this room and they built things like fixed Point arithmetic ed25519 signatures and other fundamental ZK Primitives so applications are closing for the second iteration July 28th and you can apply at the URL on this slide

uh that's it thanks guys [Applause] do we have any questions yes I can see someone at the back yeah hey uh thanks for the talk um you mentioned enforcing good behavior it's kind of off topic but something actually action could actually offer on the ethereum roadmap you have this uh proposal Builder separation that is supposed to be enshrining the protocol um I mean if you look at the advance of ZK the stack in general we didn't make more sense to instead of making every

single node you know replicate this kind of computation I have some kind of protocol that relies on ZK and just have a proof of whatever is your constraint set basically just don't enshrine PBS and and just think about an entire new design around this yeah I think when you think about applying ZK to PBS and Mev in general you have to consider sort of how much latency you're willing to tolerate I'm not too deep in PBS but my understanding is that there are certain things that are hyper latency sensitive and I think ZK today is not so appropriate for those and there are other things which are almost post hoc where something has

happened and you want to punish or reward someone to create an incentive and I think ZK could be a pretty powerful tool for that I think the last thing to say there is ZK is really good at enforcing objective statements so if you want to write down a rule that you're very committed to enforcing then ZK can do that I think my understanding in PBS is that there you might want some subjectivity and so I'm not sure to what extent you'd want to codify that using ZK but okay okay for example um you could have all the messaging between the beta and the proposer so if you look at flashbot the way the Builder has this bit Trace message and they just

basically the most important field is the is the actual bid and the proposer then choose the most valuable block and sign sign stats I mean at the end of the day or the message it could could happen of chain and you could just verify that there was a commitment to a set to a block or whatever and verify that part and basically your float all this messaging shouldn't I mean there could be a way in which you could use the case that the messaging itself doesn't happen happen on chain yeah I definitely agree like especially if you have a protocol where some sort of bad commitments According to some Criterion you specify are later punished okay thank you how do you think about resource pricing

for the co-processor yeah to be frank I think right now it's a little early to commit to anything on resource pricing um a bunch of things are going to enter the mix which aren't really a factor today so one is pretty large scale aggregation both with inquiries and across course so that will reduce costs quite dramatically the second is understanding what the size of queries people want to make even is particularly on the compute side so generally speaking we think that the proving costs should be determined on some sort of Market basis just to allow

a smooth transition as provers get better but we generally want to see more usage before understanding what the market structure should look like [Applause]