ZK9: Adding reflection to the EVM with Axiom – Yi Sun (Axiom)

Transcript

foreign [Music] next talk is by Yi who will be telling us about how to add a reflection to the evm using Axiom everyone Applause [Applause] [Music] so today I wanted to talk about a new capability that ZK actually enables for blockchain computing and that's something I want to term reflection so before we get into what reflection actually is in a blockchain context I want to review a little bit how humans actually access information about the

chain so the special property of blockchains is that all execution and state at least at present is transparent and publicly verifiable and so as a normal user you would typically access a blockchain by first finding an archive node either one that you're running yourself or perhaps run by a service like inferior or Alchemy then you would sort of query this node for the historic historic on-chain State and then you would view that in your eyeball so in my language archive nodes really are there to feed on-chain information to human eyeballs and as the ecosystem has developed uh users demand sort of increasingly more

sophisticated ways to actually understand this information so at the most basic level you have a variety of archive nodes that provide answers to Json RPC queries you can choose Geth Aragon nethermind or and soon you'll probably be able to choose ref but as users use more sophisticated on-chain applications they actually want to understand what the raw data of their querying actually means and so for that you would turn to an indexer like etherscan the graph or covalent and we're now seeing a new wave of different ways to look at the chain that give very context specific information

for example there are wallets like Blowfish and stello that will actually simulate a transaction you're about to run on top of the current state of the chain to see if you're actually getting hacked and going to lose all your nfts so the general Trend here is for users to view the chain with more and more processing on top now let's think about the situation of a smart contract viewing the state of ethereum there this it's quite different if you go to a application like openc and you try to identify which of the pieces of data on the page are actually accessible to the openc smart contract you'll find

that there's exactly one number on a listing page that that's accessible namely the current owner of the relevant nft and this is a more General phenomenon so there's all this historic information about past States transactions and receipts on the Chain that's fundamentally unavailable to Smart contracts and that's not an arbitrary decision there's a very good reason for this which is that all validating full nodes need to have this type of information and random access in order to validate a transaction so we really cannot force these nodes to have to keep historic information and still maintain the ability to run them on reasonable Hardware

secondly even if we could access all this data it's very difficult to process it in a blockchain VM you know as every smart contract developer knows the evm or actually any blockchain VM is pretty limited there are certain types of operations that are made artificially cheap via pre-compiles but there's a whole world of other interesting operations that for whatever reason are not included as pre-compiles and become pretty difficult to use in your application again this isn't just arbitrary choice this is to maintain the consensus stability of ethereum or in principle any other blockchain so situation looks pretty Grim for

blockchain computers they're pretty limited on historic access and also compute but they actually have a special weapon to combat this so unlike most other types of computing blockchains have commitments from the current block to all previous blocks and thereby all information contained in all previous blocks so if you have access to a current or recent block header of ethereum in principle you have some type of cryptographic access to the entire history of ethereum and so to sum this up blockchains have this special property of cryptographic memory and what does this mean well it means

that we can actually allow blockchains to reflect by accessing this memory in ethereum this would work by first taking the current block decommitting a pretty long chain of blocks back to a pass block containing the information that you want to access and then providing some Merkel Precision fry proofs to access a specific piece of information about State transactions or receipts and I like to think of this as kind of a baby version of reflection because it's quite expensive to access each piece of information maybe if you want to find data about one storage slot in the past that's okay but if you want to scale this it's going to

be prohibitively expensive so what we're doing at Axiom is adding reflection to the evm at scale using ZK we wrap that whole process of providing a Merkle Patricia tri-proof and a ketchup chain of block headers in ZK and from this perspective the verification of all these proofs is compressed using the succinctness property and that allows us to think a lot bigger and address much more powerful statements using reflection so we've packaged this into something we're calling a ZK coprocessor and what we're building is something to allow

smart contracts to trustlessly access and process all types of this on-chain data so let me tell you how that works from a developer perspective when you query into Axiom we divide your query into some historic on-chain reads and compute on top of that so I already told you that the on-chain reads are reaching in to the committed memory of the chain and then on the compute side we allow developers to apply different types of Primitives on top of the data that they access so this ranges from pretty pedestrian things like basic analytics to kind of whackier things like cryptography or machine learning

and finally in parallel we're generating zero knowledge proofs that all of this was done in a correct fashion and we verify those proofs on chain the end result of this is a kind of different smart contract Computing paradigm you have a smart contract you send us a query to a co-processor this picture is a picture of a actual math coprocessor from the 1990s you'll notice it's made by math Co so this is kind of a throwback but in our coprocessor we'll do the reads in the compute and finally we put the verified result on chain for a smart contract to use

and so we think this is a new delegated data read and compute Paradigm for smart contract applications so let me talk a little bit about how we specifically achieve this so there's essentially two tasks the first is to actually be able to access historic block hashes at some scale doing this doing this from scratch for each query would be pretty expensive even in ZK so we maintain a smart contract that caches a merchalized form of all historic block hashes on ethereum the idea here is that the evm for

whatever reason allows you to access the last 256 block caches and we systematically reverse that ketchak header chain to Cache every 1024 block caches the end result is that our smart contract which you can view on mainnet today actually contains a verified Merkle root of all past block hashes from Genesis the day we did that we were the number two gas consumer on ethereum which is a rather dubious distinction I hope to not repeat now when we actually fulfill a query about specific historic information into Axiom we can verify proofs against this cache of block hashes so all we need to

do for single queries is Merkel Patricia tri-proofs that are verified in our smart contract against these Merkle routes so the resulting ZK based reflection type system differs from standard smart contract Computing in some pretty critical ways so our view is that smart contracts are generally powered by consensus what that means is that they're very good at providing synchronous access to a pretty limited amount of on-chain State on the other hand they don't give you any access to Historic State and your compute is pretty carefully metered

on the other hand if you use a zero knowledge powered reflection type system you don't get any access to the current state since it's a fundamentally asynchronous operation in return though you can actually do unlimited compute on historic data so long as you're willing to pay for the proving and you get async access to the entire chain history so we think we're presenting a different type of trade-off for developers here all right so that was a lot of very conceptual talk about New Primitives what can we actually do with this so we think of this in stages and I've drawn a rough plot of the amount of data

read for an application on the horizontal axis and the amount of compute that's required for an application on the vertical axis the first class of applications are things that are generally possible in the evm today whether by doing single storage proofs directly or by adding caching to your application so this would be things like reading historic consensus level Randomness From the Block header verifying your account age or reading a historic UNIF swap spot price or tiwap price if we scale up though to things which require much more data complexity and much more compute complexity then we get

not more novel applications which really are not accessible in the evm today this would be things like adjusting parameters of your D5 protocol by applying some basic machine learning algorithms to the historic performance rewarding your protocols participants by doing a trustless evaluation of their on-chain track record or actually Computing an on-chain credit score in a trustless fashion instead of relying on a centralized provider to put that number on chain and we think that these applications because the scale of the data read in the compute is so much beyond what you can think of on chain today

they're actually hard to think of and we think as developers try to use this this primitive of reflection more they'll find new ones one thing I want to note on this basically made up graph of my estimate of the complexity is that the data complexity of an application is actually intrinsically quite tied to its compute complexity essentially if we offer you access to a huge number of data points then it's very hard to use that without a commensurate level of compute similarly if you're going for an application that does very sophisticated compute for example some type of neural network inference you very likely will have to access quite a bit of data in a

trustless fashion to even get the input so at Axiom we're going after applications in this top right corner so if you have any ideas that aren't on this list definitely come talk to me after the talk now for the rest of this talk I want to talk a little bit about what would be next if we finish this entire 2D plot and what I think could be next is something that I want to call introspection so we've talked about reflection as the blockchain looking at itself and well what's introspection for a human psychology that's sort of thinking about your actual your actual mind and thinking about what you might do in some

hypothetical situations and so for a blockchain I will take introspection to mean doing simulation of what hypothetical activities could happen if you were to do different transactions on chain okay so this will require doing much more access as well as much more compute than anything that I've written on the slide and in this case we think that it will require first of all something like a ZK VM and can allow application developers to make much richer statements about blockchain activities just to list a few examples of things

that are kind of pie in the sky today but may be possible down down the road you might be able to test whether a hypothetical property would happen to your protocol if a user were to execute some type of transaction in the context of insurance we think the highest possible standard for whether you should be entitled to a claim for insurance is when you try to withdraw your money from a let's say lending protocol if you can prove that you are not able to withdraw then you're certainly entitled to a claim on the other hand if you are able to withdraw perhaps you shouldn't get paid similarly if you're a white hat hacker

you know you want to get paid a bug Bounty but maybe you don't trust the team to actually pay you so there we think the highest standard would be to prove that you have knowledge of exploiting transactions which would allow you to violate certain protocol level guarantees if we go more to the infrastructure level you'll sort of see that this proof of exploit is actually quite similar to the notion of a ZK based fraud or fault proof in an optimistic roll-up a fraud proof is nothing more than a demonstration that the state that is arrived to on chain or that is claimed on Chain by sequencer is actually not the correct application of a sequence of

transactions and finally in the domain of Mev and block building we think that doing hypothetical execution of transactions that are being submitted in a mempool to be put in a block could be a way to actually provide accountability or some sort of performance evaluation for Block builders for example you might be able to prove that of all the transactions in some set you actually built some block which is good by some type of arbitrary performance metric so in general I think we're very early about thinking about the implications of introspection for applications in the space and we're pretty excited to see

what developers can come up with once this sort of idea is even possible so I want to end and by coming back to the beginning of the talk and drawing an analogy with what's happening in the more user-facing side of crypto on a data access so we started with sort of off-chain access to basic Primitives via an archive node and things in that area of the space have really moved to beyond that to tracing archive nodes to full transaction simulation and all sorts of very fancy indexers that are coming to market now and at Axiom we're bringing the very basic blocking and tackling applications

of on-chain reflection via co-processing for smart contract applications and as things develop we're excited to explore the implications of that for on-chain introspection for smart contracts so just to finish we're hiring pretty aggressively so we have a bunch of job listings for both engineering ZK as well as developer relations and BD roles at our job sites and we'd love to have you guys join us in building the foundations necessary for smart contract developers to build expressive and Powerful trust minimized applications on chain so I think there's quite a bit of time

for questions so yeah [Applause] as you said if anyone has any questions please feel free oh yeah one uh yes she is coming to get thank you for the talk you had great slides in there could you say a few more words about the architecture because it will seem like everything happens on chain but I guess you know there are things that happen off chain two right

foreign yeah definitely so there are two pieces to the architecture the first is that we have to keep our cache of historic block hashes well first we have to initialize it so to do that we provide zero knowledge proofs of the valid uh ketchak chain of block headers in groups of 1024. so we do that historically and then we also have to do that on an ongoing basis to maintain this cache so actually you can look on mainnet today we're running a zero knowledge proof every 30 minutes to keep this updated so for the historic access we did some tricks to actually do a batch Import in groups of about 128 000 at a time

now the second thing is for the query fulfillment on chain so let me find the right diagram so what happens here is that a smart contract will make a query into our off-chain system will pull the data and run the compute to find the result of that query and in parallel we'll generate a zero knowledge proof that we did all those actions in a valid fashion and because we've built this cache of block headers we're actually able to verify that proof on chain and then check that the appropriate block hash information matches the verified block headers we already have in our on-chain contract and this way we're offering essentially delegated data reads and compute to our

off-chain co-process thank you anybody else have any questions thank you I have the impression that this system could have huge implications for Mev and Mev simulation it's this two or is this only an impression it sounds like you know much more about Mev than we do so first of all we'd love to talk to you about that one area where I think it could have some implications is that we're able to access for example The Ordering of transactions in an actual block and I've been told at least that first of

all in nvv this is what people care about but also that this might have implications on driving some accountability for various systems in Med so I'd love to talk further about that thank you that's right here hi um and yeah I would like to know what type of proving system are you using I mean which which system or are you using recursion or I don't know because it you know it seems that performance is really important here yeah definitely so we're using Halo 2 with the kzg backend so we're using the same Fork of Halo 2 as PSC and scroll

are using for the zkevm and definitely to we're proving pretty big statements so we make pretty heavy use of non-native aggregation and recursion okay thank you so much and if you want to see the Gory details we actually open sourced all of our code so you can check it out on our GitHub could I bring my own data meaning at some point in history the hash of my data is included in the chain could I bring that data and bring that into the proof yes I think the question is like if you

have some committed data that's sort of hidden can you somehow provide it as a witness yeah that's in our system today you would have to do that in a smart contract land but we are exploring ways to allow not just committed data but just arbitrary public sorry arbitrary private inputs that users provide another example where that's interesting is if that data is a user provided signature yep cool any last burning questions ideas Notions Commons constructions no well one more thank you to ye this is

great thank you so much and I will [Applause]