New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

Axiom 🛠 Access Transactions and Receipts On-Chain

ETHGlobalMon, Oct 9, 2023, 12:00 AM

Join Yi Sum for workshop titled "Access Transactions and Receipts On-chain". Some of the most skilled web3 developers, designers and product builders from all around the globe came together for a weekend-long adventure at ETHGlobal New York 2023. ----------------- Follow us: https://twitter.com/ETHGlobal​ Check us out: https://ethglobal.co​m Email us at: hello@ethglobal.com

Transcript

foreign [Music] hey welcome everyone um yeah we're gonna get started with the workshop just want to First give a brief overview of what Axiom is and then talk through how you can actually build a ZK powered app with Axiom in about 30 minutes so first of all what's the problem that we're trying to solve at Axiom it starts with the observation that if you're building a smart contract on ethereum today you actually quickly realized that your contract can't access much data as an example if you look at the openc listing page for pudgy penguin you'll notice that almost all the information that is on the page is on chain data for example the transaction history or historic owners but only the current owner is actually accessible on chain and the reason for that is to maintain the decentralization of transaction validation on ethereum so developers work around this by making pretty difficult trade-offs today between paying more to access more data in their smart contracts by just storing more data in storage or reducing the security of their applications by using a trusted Oracle that simply puts data on chain and so at Axiom we're removing this trade-off by providing a new way to access historic on-chain data using zero knowledge proofs what that means is that we use the fact that the current block of ethereum commits to all historic data on ethereum to give cryptographic proofs that a piece of historic data that your application is using is actually valid in the history of ethereum but because we're using cryptography instead of consensus to access data we can offer a whole new set of capabilities for your application and so we've wrapped this up into or calling a ZK coprocessor for ethereum the flow of using it is that you send a query to our smart contract we provide trustless reads to any block header any accounts or any contract storage variable in the history of ethereum and we're also adding transactions and receipts in our V2 which we're previewing at each global once you have that data you can do computations on top of it with custom ZK circuits and get to a result that your on-chain application is interested in we provide a zero knowledge proof that those results are actually correctly computed and come from data which actually comes from ethereum so that means that you can rely on data results that come from Axiom with the same cryptographic guarantees as something you're accessing directly on chain so let me talk through how you'd actually use this in your application so the flow of an application that uses Axiom to access historic data goes as follows first we provide a very easy SDK to allow your users to prove computations and request data in your web web front end so here we actually provide a client-side ZK approver that your users are going to be running on their laptops they'll send a query for on-chain data to the Axiom smart contract which we're indexing and we'll prove that the data access that they're doing is authentic using xero knowledge proofs finally we verify the end results on chain with the ZK proof and we execute a custom callback on your smart contract which is the only change you need to make to your contract to integrate actually so let me talk through the steps of actually integrating Axiom into your application first we Pro we provided a easy web repel interface for you to specify the computations you want to do and the on-chain data access you want to make so this is called Axiom Rebel and we'll walk through it later in this Workshop once you've done that we allow you to export a webassembly ZK prover to a next JS app we have a scaffold app for you already from this web repel but you can also migrate that prover to a web front end of your choice this would be ultimately what your end user is using to interact with Axiom once that's done in the flow of your application users would send queries to Axiom from the web front end that happens through an on-chain transaction we're indexing those queries and we'll prove validated valid data access through zero knowledge proofs that are executed on our server backend finally we'll Implement a callback on sorry you'll Implement a callback on your on-chain application and what we ask is that you extend our Axiom V2 client interface that gives us standardized format for the Callback which allows you to check various properties of the query make sure things are authenticated and permissioned correctly and finally gives you the user data that you're actually interested in okay so now time for a demo you can follow along by going to rebelpreview.axiom.xyz uh it unfortunately will not work on your phone but for those of you with laptops you can you can watch what I'm doing you'll actually see the same demo code as I'm running live so let me just pause for like five seconds so everyone can get the URL and then I'll go to do some live coding all right so back to Axiom Rebel all right so what's going on here we've we've developed a JavaScript interface to allow you to actually access on-chain data and do computations on it so as you can see here we have this in this window you are writing actual JavaScript and we're going to write an application to prove the first block that a user's account actually made a transaction on ethereum so how can we know that a user's account made a transaction for the first time at a certain block well if you look into the details of the evm you'll know that we have to check that the nonce of that account was Zero at the previous block and then became positive on the claimed block where they made the first transaction and that's exactly what we're going to check in this JavaScript interface so we have an input box which let me just pull up here and what we'll check is that for this address the first block in which I made a transaction was the claimed block number here and this is all on Gurley testnet so the way we do that is first we constrain we we've compute the previous block and here whenever we do any computations in this JavaScript interface we require you to use our JavaScript functions we've written custom functions for example sub add mole and div to implement arithmetic operations that will later be proved in zero knowledge so here we would prove we would compute the previous block number and then we would call functions that we've implemented to allow you to access on-chain data through this interface for example here we're calling get account you can also call functions like get storage uh get solidity mapping get transaction or get receipts to access the entirety of ethereum execution layer data so we've here we get the account object from the previous block with this address and then we can access the nonce from that account just by calling dot knots and remember we wanted to check that that nonce was Zero so we call assert equal to check that the nonce at the previous block is actually equal to a constant which is zero now we want to check that at the claim block this nonce actually became positive so again we fetched the nonce by fetching the account and then calling dot naughts on that account and then we used a function check less than to check that 0 was less than the current nonce thereby showing that it's actually positive so if all of these pass then we can use a final function add to callback to specify that the address in the claim block number should actually be sent to your um your smart contract as the Callback arguments so if I click test circuit we're going to generate test outputs here and we'll see that's indeed we outputted the address and the claimed block number as the test callback arguments now we're going to show I'm going to show a demo flow of this actually interacting with a contract on Gurley testnet so to do that we're going to generate proving and verification keys and then we're finally going to generate a zero knowledge proof of the execution of these computations namely subtracting one from the claimed block number and checking the quality of the nonce to zero and the positivity of the next knots once we've generated this proof we now can send a query to Axiom to authenticate all the data inputs that went into this proof what I mean by that is we need to check that the account nonce that we fetched was actually correct for both the previous block and the next block so we can do that by sending a query on chain to Axiom and that actually sends an on-chain transaction on Gurley once we send that we can check it out on etherscan as you can see it's still being indexed so let me pull up a transaction I sent maybe one hour ago so that's the exact same transaction and we called this send query function what we sent and that's being done in our web front end is some information about the data that we wanted to fetch so here we have the source pane in this case the source chain ID is 5 which corresponds to girly testnet the data query hash which is a hash that specifies that we wanted to fetch the nonce of one account and then not at one block and then on to that same account in the next block and finally the information about the computation we did which we encode in this compute query object so we have two pieces of information one is a v key that allows us to verify that the zero Notch proof we did in the browser was correct and secondly the compute proof which actually is the proof so what this query is going to do is to request Axiom to check that check two things one that the compute proof was correct and two that the data we're requesting was actually used correctly in that compute proof once that check has passed we're going to call this callback that you can specify here I've specified uh address of an example contract um a function selector of an example callback call and we specified that two results should be passed so there's a result line of two and finally it will allow you to pass in extra data in the Callback as well the rest of the arguments specify what sort of gas requirements you want us to hit the callback with so this is a transaction that's been sent to the Axiom smart contract on chain and we will fulfill that transa that request by calling the fulfill query function as you can see the fulfill query function gives you the compute results so this was the address and this was the block number that the address first sent a transaction it also provides a zero knowledge proof that the compute proof was correct that the data was validly plugged into the compute and then everything really came from the history of ethereum and finally we hit a callback on an example contract in this case but in in an application this would be your contract and we require that you implement an interface for ACT we call Axiom V2 clients that simply takes a callback that expects the following arguments that kind of correspond to your query so the first argument is just the source chain ID where the data is coming from the second argument caller address is the eoa address that initiated the query so if you're allowing any user to send a query into Axiom for your application this would be the address of your user finally the query schema specifies what your query is about so every time we generate we write a query in the browser it generates a unique query schema that you should validate in your application the last two arguments the query hash is a unique identifier for the specific query that's being sent and the Axiom results are the results in this case the address and the number and the block number were that address first sent a transaction so all you need to do to integrate Axiom into application is to write in a query in our Axiom reple interface export the next JS prover and then implement this Axiom V2 callback function on your smart contract application and we provide this interface Axiom B2 client for you to do it okay so last couple minutes just wanted to reiterate those steps so first you write a query or circuit in Axiom Rebel to specify the computation export the prover modify your front front end to integrate that prover we will on our server index your users queries and provide approve a valid data access and then you will Implement a callback on your contract so for this weekend we stood up a preview version of Axiom V2 on Gurley and we have a bunch of ideas for what you can build with it first we think the areas of identity and governance are super interesting we think you can provide autonomous airdrops namely airdrops where you deploy a smart contract with some criteria for who should be able to get the airdrop users can prove using oxium that they performed relevant activities in the past and are therefore entitled to get incentivized that takes away control of the airdrop from a centralized team and gives it to a Smart contract similarly you can imagine giving volume rebates or other types of Loyalty Rewards for usage of on-chain applications if you think about uniswap no matter how much you trade you're paying the same fee with Axiom and unisotv for hooks you might imagine that higher volume Traders or new Traders can get lower fees um another angle is that you can actually construct a trustless Oracle using Axiom you might imagine taking his an average of on-chain gas prices and constructing an index of of ethereum gas prices to settle a derivatives protocol we listed a few other D5 ideas here and we're having special prizes for the best usage of Axiom in both identity incentivization and oracles I'm sorry and D5 in the last couple minutes just a couple more ideas you can use oxium to slash participants in a protocol on chain for example because we allow you to access transaction and receipt data we think he might be able to detect whether an ethereum block contains a sandwich attack and who might be responsible for that if someone's responsible for a sandwich attack maybe you should punish them or maybe you can use that attack to refund part of the proceeds to the initial user other things we think are interesting are automatically adjusting parameters of a D5 protocol using on-chain historic data or having batch auction settlement prove to be optimal again off chain finally there are a bunch of very silly ideas you can give people little badges for various on-chain Degen activities they may have done imagine proving that you owned a lot of um a lot of one type of nft or you lost money trading nfts imagine you you have a badge if you lost 100 each training nft you could also prove that you did various interesting on-chain activities for example if you farmed yam during defy summer I think that might be a notable attribute of your account so we really are interested in creative ideas from you guys we also have a special prize for the most creative usage of Axiom as well as the best overall usage so we have a bunch of materials prepared for the global hackathon we have a special guide at global.axiom.xyz and if you use this QR code it'll take you to our telegram group or you can get help directly from the team

Automatic transcript — names and jargon may be misspelled.