zkAttestor: Block and State Attestations on Ethereum, Applied ZK - Day 1
Ethereum DEV NL·Sun, Oct 9, 2022, 12:00 AM
This talk presents zkAttestor, a project to produce trustless zkSNARK-based on-chain attestations to data from any Ethereum state or block. These attestations are trustlessly verified on-chain in a smart contract which caches historical block hashes. We envision use cases including identity, dapp primitives involving history, and on-chain reputation. Speaker(s): Yi Sun Hosted at Devconnect Amsterdam, 2022 Visit the website: https://devconnect.org/ Or follow @EFDevconnect on Twitter
Transcript
[Music] excited to introduce zk attest to you guys it's a project to prove all ethereum on-chain data to ethereum so let me tell you what that means you might think that on-chain data is already available to ethereum but if you look more closely at the structure of on-chain data on etherscan you'll see that some types of data like the account balance the nonce and the current contract states highlighted here is available for smart smart contracts to use in other applications on the other hand if you look down a little bit in etherscan you'll see the transaction history so that's data that is available to every ethereum archive node but it's not something that you can touch from another smart contract but if you look at other applications that serve information from the blockchain off chain like openc here you'll see that having this transaction history as well as the historic state for example a historical owner of a cryptopunk is pretty important for creating the overall product experience so the goal of zka tester is to give smart contracts trustless access to this much richer set of on-chain data so let me give you a few examples of what you can do with this type of data the first class of applications is for zk based identity for example you might want to make the claim that you own a crypto punk but you don't maybe want to reveal the address you hold it in and which crypto punk you actually own another example for a zk-based social media app is exactly as barry was mentioning you might want to lend more credence to some statement you made by saying that you posted it from an address that holds at least 1 000 youth it's a pretty strong form of civil protection the second class of applications actually removes the zk aspect and this could be useful for on-chain reputation for example if you're trying to establish that your credit worthy address well you might say that you took out a bunch of loans on ave for a large notional amount and therefore a new lending protocol should give you better interest rates on the more negative side you might want to say that hey this miner is being malicious they mined a sandwich attack in the last block or maybe 10 times in the last two weeks and therefore they should suffer some negative consequence in your decentralized application and a final class of applications is again without the zk aspect for history aware updates of protocols if you look at unit swap t-o-op right now the way it works to compute t-wop between time a and time b is that you checkpoint some values within uniswap at time a and then at time b you're able to compute the t-wap by doing some post-hoc computations using zka tester you can compute this atomically without the checkpoint for a final example if you are running a lending protocol like compound right now you can only use the current state of compound to adjust the protocol parameters like interest rates um with zika tester you might be able to use historic information like the lowest collateralization ratio achieved in the last week okay with that let me tell you about how zka tester works mechanically so the idea is that it creates ck snark proofs for arbitrary state and transaction data from any historical block of ethereum so the way that works is you start with a statement about a state or transaction you call your favorite death note maybe your own maybe infuriates to get a light client proof of that state or transaction then you feed it to zka tester which will give you back a zk snark proof which can then be verified on chain against a cached lock hash in a smart contract so through this procedure zk tester is able to prove any data that's available to an ethereum archive node on chain so let me walk you through an example of that for the specific statement that i own a crypto punk so we're going to go through several layers of this statement at the solidity level what it means to own a crypto punk is in the crypto punk's smart contract there's a mapping punk index to address which stores for each crypto punk the address which owns it so the level one answer of what it means to own a crypto punk is just that your address is in this mapping let's go a little bit deeper how does solidity actually work so all information in smart contracts and ethereum is stored in what's called account storage it's a single mapping between uint256 and un-256 that solidity packs the state variables in according to some fairly complicated rules which you can read the documentation for and if you go dig into documentation you'll find that the statement that you own a cryptoconch corresponds to the value in a certain slot determined by the cash of the index of the crypto punk concatenated with 10 10 is the location of this mapping in solidity happens to contain your address so the level of the evm that's what it means to own a crypto punk now let's go one layer deeper to understand what it would mean to prove this statement and for that we're going to have to dig into the data structures underlying account and state storage in ethereum so ethereum commits to all data on chain in what's called a merkle patricia tri that's a degree 16 tri that uses the cat cat 56 hash for mercalization and to give a proof uh of merkel inclusion in this try one has to give an inclusion proof which is a path from leaf nodes to the root node showing compatibility with the keckack hash along each node and also using this rlp serialization of the nodes if you look at the diagram on the right there's some complicated but deterministic spec for how this all works so to give a little bit more detail there are four key merkle patricia tries in ethereum um there's the state try which is a mapping between the kekai cache of your address and an rlp encoding of the relevant data about your account for example the balance the nonce and most importantly the storage try which is your local account storage that stores a key value mapping between the cache of the slot and the data at that slot and finally within each block we have merkle patricia tries of the transactions and the receipts of those transactions which are just mappings between the index and the serialization of the transaction or receipt so all of these merkle patricia tri routes are committed to within the block hash in the block header okay so from this perspective what does owning a crypto punk mean it means that there is a block with a known block hash whose block header contains a specific stage route and within that state route i can do a merkle patricia try proof of inclusion to show that for the address of the crypto punx contra smart contract i have some storage route and within that storage route i can do a merkle patricia tri inclusion proof that a specific key value mapping corresponding to the compiled solidity code has my address as the owner of some crypto punk so that's kind of a mouthful but when we compile the statement that i own a crypto punk all the way down this ends up being what we're going to prove and this is exactly the statement that zka tester proves when making the claim that i own some crypto punk okay so now let's try to do this live so i'm going to show you a demo of this happening and i hope this works okay so i'm on aws with my machine and so first i am going to run a command which generates uh inputs to the zk snark proof for punk slot 1. so you can see some data has appeared now i'm going to run the witness generation and it's going to take a little bit so this is going to generate the witness that goes into the zk snark okay it should appear in about 10 seconds [Music] great okay so now i've generated the witness and now let me give you a stack trace of how that all worked so you can see i have an external circuit which does the ethereum address storage proof it calls the check for the ethereum block hash the proof in the account try and finally a proof in the storage try so i've generated the witness and now i'm going to do the proof this will take a little bit longer so this is now calling the snark prover which took in the original circuit as well as the witness that i just generated and it's going to output a constant size snark proof and let me just cue up the verification command this is this takes about 30 seconds so in perhaps 10 seconds it will complete great so i've generated the snark proof and now let's verify the proof um and what do you know starting just says the proof verifies so if you trust that i actually ran some commands we verified the proof [Applause] okay so what did this prove this proved that for this specific block number this address which is not my address owns crypto punk number one okay so just to wrap up zki tester right now can do address and storage proofs as well as transaction proofs and the hash of the block header proof so as you can see they're both around teens in the like 13 to 16 million constraints in r1cs the proving keys are pretty big but as you just saw live the witness generation and proof times are not so bad uh there are some technical limitations i can only prove transaction sizes up to 7.5 kilobytes out of a maximum possible of 30 kilobytes but i hope to remove those soon okay so the short term roadmap for zka tester is i'm looking to optimize and productionize the circuits and then deploy the smart contract on chain that i mentioned that will cache block hashes and make this whole system fully trustless but most importantly i'd like to integrate with downstream applications that want to make some of the claims that i mentioned earlier in the talk i've been coming up with various ideas for how to use this but i'm sure that you guys have much better ideas so i'd love to hear if you have anything that could use a tool like this uh you can get in contact with me on twitter and i just released the code on github at this address so thanks and love to take any questions [Applause] uh is there a mic too yeah so yeah these are like uh i can see the applications for like proving something from web3 out in a web 2 application but um maybe i missed what was required to then have that on chain is that what the point to it yeah so the question is uh it's clear how to use this to prove in a web 2 application but how does it work on chain yeah that's a good question so i didn't talk too much about the uh smart contract with cash's block hashes so the point is that the evm has access to the last 256 block hashes uh natively um but not more than that um this is there's some eip to change this but for now what we can do is simply have a smart contract which you have to poke every hour or so to just prop just like cache these uh block hashes so you can do it in a smart way you can cache sort of merklizations of them to not take up too much storage um yeah so one thing i didn't mention is that in my proof i just take trees of bounded but variable size so for account and storage proofs i can handle depth up to eight and then for the transaction try because the keys are just rlp encodings of the index you can actually show it's deterministically below i believe death seven yep yeah the question is um what's being done before the zk proof and what's being done um after it uh particularly the usage of the geth node so the way the reason the gethnode comes in is just to get the actual light client proof namely the proof of merkle patricia try inclusion so there's a api in the eth rpc called get proof and a lot of the available services will just give this to you uh barry what's the developer experience of making something like the uniswap kind of price batching like if i want to make that do i have to make circuits ah the question is what's the developer's experience of making something like the uni-swap t-op computation do i have to make circuits um the answer is that you don't have to write any circuits the block cache caching smart contract will accept a proof and then basically contain a list of true statements statements of the form the value in slot xyz ad address abc is whatever it is the developer will have to interpret that very raw low-level evm level information downstream in their application and i think it would be really helpful to develop more tools to make that easier and connect it to the solidity level right now you have to basically compile solidity yourself uh oh more time great um yeah the question is what's the trade-off between the on-chain snark verification versus the direct uh light client put like client proof on chain um like line proofs are pretty huge so i think it's pretty prohibitive to put them on chain for the on-chain snark verification it's order one cost i believe it's or it's constant cost i believe it's around 600 000 gas per operation so right now this would only make sense for fairly high value applications um yeah the questions have i heard a fossil which is doing this on cairo i have not would love to take a look um so you talked about being able to prove things like for example like i own you know a crypto punk but maybe not which one so as things are set up now you're revealing on chain like which addresses your app you're accessing right uh the question is um how can i actually make the crypto punch claim because i'm revealing which addresses i'm accessing um in the future yeah the answer is um we have uh circuits for ecdsa so you would combine this with a proof that you can i know a signature which verifies for the address in question but actually not have the address be one of the public inputs so you can sort of programmatically mix and match what you're hiding all right i think we have one minute for any last half a minute for any last questions oh barry oh sorry yeah oh okay so i'm um with with i guess i was wondering with uh graph 16 obviously you need a trusted setup for this as well uh replication some pairs like if you also try this with other uh cruise systems and what kind of performance you might have seen or expect to see yeah the questions have i tried this on other proving systems the answer is no i would love to the main blocker is actually that i don't know of any other proving systems that have on-chain verifiers right now um so if you're working on that i would love to hear about it all right thanks guys [Music]
Automatic transcript — names and jargon may be misspelled.