Axiom 🛠 Access Transactions and Receipts On-chain with Axiom

[Music] so what is axium well Axiom essentially enables ZK superpowers for your smart contract and what exactly does that mean right I'm sure you're wondering uh well let's just back up a little bit so right now smart contracts really only know the current state of the blockchain they can only see things like let's say you go to Ether scan right and you look at some random account you can only see like the current balance of that account uh on chain and like you know things like how many transactions that account of sent via the nons so all this data that's in the red here is actually data that is not available on chain and what that means is that you can't use that in your smart contract uh until now right so much of this R rich in onchain history is just not available um so you you you can see the number of transactions but you can't actually see what's in those transactions so accessing more data onchain generally just requires tradeoffs right so you can either pay more to store data in the state of ethereum um because the contracts can't access the history uh but that imposes like some extra costs on each user you have when you store more State you uh increase gas costs essentially um or you can reduce security and use trusted oracles so that also introduces additional trust assumptions on users um and also lets you scale it also prevents you scale um in in a lot of ways so developers either have this uh conundrum right they can either increase the cost or decrease the security so then the question is how do we enable Smart contracts to leverage Rich the rich history of onchain data so what axium allows you to do is Access Data with ZK cryptography instead of consensus right so if you look here this is essentially a model of a blockchain right so each past block commits to the entire history of the blockchain and each block has commitments to the state the transaction and receipts um and so proving that data in ZK uh enables scale and composition because using when you prove it in ZK you're able to basically get all this data and put it and and use it in your smart contract and what we have is this reple uh that we have online it's at reel. axyz it's basically a inter interface that allows uh people to um write their own circuit in a JavaScript edsl that's a wrapper over Halo 2 and so what this means is that you can grab uh historical data like block headers accounts uh storage and you can also get data like transactions receipts and mappings um and so what we do essentially is we uh let you specify this application logic in in the uh reppel interface and then you can export a client side ZK approver that you can use in your webd app so where does axium fit in in this whole stack right so essentially you have the front end which is like your client app and then on the back end you have like a data aggregator or indexer um that could be anything like uh Alchemy Cove valent uh quick Noe etc etc um and then um between the back end and the blockchain itself sits Axiom so we have offchain and onchain components uh and then essentially we will uh send a call back to the developer's contract um and the developer can then uh process that data in whatever way they see fit um so I'll just really quickly go over this workflow um but essentially we start off with generating a compute proof via a client side prover right uh and then we with that proof we send a query into the axium contract uh the axum contract then uh generates a proof on the proving server um and then the proving server sends uh the result of that proof onto to the axim contract which then calls the onchain verifier and so that data is verified before it's sent via callback to the developer's uh DF contract yes is it possible to access the proof in the call uh the actual proof itself um not right now yeah but that data that proof data is available like uh if you look in we have a thing called axiim Explorer and so that proof data is actually available there um and so we aggregate uh all this data um via Universal aggregation so the compute proof and data proof that is uh generated uh on the client side in axium repple um that circuit uh is put into Universal Universal aggregator uh and then we then are able to verify it using a universal onchain verifier so what this essentially means is that there's no ZK related smart contract deploy that uh developers need to deploy in order to use axium and so using results from a for axium in your smart contract is as simple as just uh adding this um very specific function to your contract uh to receive the call back um and so this is just a toy example uh that we'll be going over um and it's on governance so how is governance done today right users will vote on a proposal uh if the proposal passes then we trust some entity or entities to implement that proposal um and sometimes they don't so what exactly are we building here we're building a contract and D whose parameters are autonomously governed by users who meet specific criteria based on their past onchain actions and so well let me back up in this specific case the past onchain action that we are um are looking at is whether a user minted an an nft and are still holding it so essentially we have four pieces to this right we have this uh first piece which is the nft project uh useless nft which is an ERC 21 we'll pretend it was minted like a year ago or something uh and then the ZK circuit with axium repple um so we write a circuit that checks that a user minted this useless nft uh we have the nft Project's new useless governance token that they want to uh deploy um and this is where the axium call back is implemented um and users who've minted the useless nft and still hold it can influence the tokens paremeters directly um so basically each of these users who have minted the Mt and and still hold it are able to uh vote to increase or decrease the tokens tax and stake rates by 0.1% uh whether this is something that you actually want to do or not that's you a question for yourselves but um then we have this webd app front end right so users will connect the wallet um and app uses an indexer to find the uh US nft Mint event and then uh qualified users can vote and then it generates and sends a query to Axiom all right so this is part one part two part three and part four all right so the high level architecture is uh as such so you basically just have this user that mints this useful sftt and then uh the developer creates a circuit in axi repple they have this web app uh and then some data that Tu and indexer uh once this query is sent it's sent to axm V2 query uh who generates uh a who uh sends the data to the prover and then the prover generates the proof um and then it's verified in ZK or it's verified on the onchain verifier and then the call back is sent to the useless governance token yes is that open source uh yes it is uh so actually right now it is still I think closed Source uh and in development and audit uh but once it's all done that will be open sourced and we've open sourced XM V1 um already it's kind of like the high LEL API the same yeah uh no no XM V1 and xv2 are completely different yeah um okay so this is the uh GitHub to the um actual uh thing that we'll be talking about today uh it's axium crypto governance prams example axium crypto governance prams example um and we'll have a link to this at the end as well so first part is this useless nft right so we have it's just like a standard completely unremarkable ERC 721 uh and then we have an external mint function that allows anyone to Mint an ft uh I'm not going to go over this at all because it's just very standard um but for axium repple uh what we're interested in is this mint event which is which is actually a transfer event right uh where the zero address is from and the two address is the uh person who minted the nft uh and then we have the token ID as well who we're interested in um and then the address of the uh of the contract that amended the event which is the nft event uh nft contract so in axium reppel there's when you go to the website there's two uh separate parts and each part uh well there's one part that's code and one part that's inputs and so the code is essentially like how you're specifying uh getting data from the blockchain and then also doing any sort of compute on that data uh and essentially you can think of it as your circuit um the inputs is actually what uh your web app can override or basically like use as inputs to the Circuit when you export it um so you know this mint block and mint TX number will be different for each user uh and also the vote value as well um but going over each part uh and sorry that's going over each part of this uh so we have the transfer event schema right so you have the log uh where you get the receipt um and so for this for this um for these transactions the there's only one log and so we know that that's Al always at index zero um and then we check that the address that's emitted uh is the nft contract itself um and then we also want to check that the uh transaction is a mint transaction right so it's from address zero um and then we also want to make sure that the mentor's address and the token ID uh that we get the mentor's address and the token ID um and then we also just want to check that the vote value is either a one or a two where one is yes two is no and we're not using zero just to not handle any default issues um and then scrolling down a little bit uh then we have these add to call back calls and so these are the calls uh these are what lets you add values to your contract the call back that will um get the data to your contract and so the data that we're interested in uh getting is the two address the the token ID and the vote which we will uh handle in our contract later um and so what we're able to do here is export this typescript circuit in axium repple um and then also we want to check uh grab this query schema and so the quer schema is pretty important it's basically a commitment to your circuit and what that means is that when a call back is received to your um to your contract uh we want to make sure that that callback is talking about the same circuit that you wrote uh and so if you change any part of the circuit that query schema is going to be different uh and so we want to make sure that that that you're that the call back that you get is for the call back for the circuit that you wrote um okay so next part is the erc20 token aka the useless governance token that uh receives the Axiom call back so it's a standard erc20 token and it has uh State variables that hold the tax rate the reward rate and the number of votes uh number of Voters who voted um and so this has a function to receive and validate the axiim call back and you know for a production contract obviously you could have like a mapping of structs that holds voting requirements and data for each proposal but in this case uh you know we are just doing a toy example and so we just have one contract that has all this uh data um and so let's go over this part real quick um so here's the uh axium callback query schema that we want to put in here um and this is uh this is saved on on contract deploy uh and then we have the tax rate reward rate and total votes as well as a mapping um of people and their uh token IDs that did vote and so we have a function that checks if the user voted already uh and so we just basically hash the um address and the token ID and then um that just returns a true or false uh but the main meat of the of of this is this axm V2 callback and so um I'm just going to jump over to this other file here called axm V2 client and so this is uh essentially what our um other uh contract deres from and so this contract uh has a function called ax and V2 callback that has the correct uh function signature right um and then essentially we are just uh overwriting these two functions here so let's go go over this again um so in this part we want to parse the results array right so we get a uh so if you remember earlier we had three uh add to callback calls and so we'll have three uh results in the array the of and these results are ZK verified results of your history so at this point we parse the results array right uh so we get the nft holder the token ID and the vote value and then um at this point we want to uh make sure that the owner of this token ID is still holding it um and then we just want to make sure that uh we go through all these different validation checks as well um I'm running a little bit low on time so I'm going to go I'm going to skip over a few parts here but um essentially we have uh the vote values that are updated and then we updates and then we have event that is emitted um and then we this is some of the validation stuff um but the next part is this web D app uh and it kind of like has this um you know flow where user connects wallet mints uh and actually I'll just go over these screenshots real quick here so we have this um page where a user can just mint the nft check the whether they're eligible and this is a toy example so of course they can still just mid the nft um and then they're able to vote uh and then submit this vote and then once that's updated then once that once that vote goes through then the tax rate and reward rate and the contract itself are updated um and so this is kind of like the whole web D app uh flow um and essentially we have uh something that parses this transaction data uh or checks the transaction data uh from like um Alchemy and then we uh just make sure that we find the one that we care about um and then these are just things that uh you can use to build the axium query itself um and then yeah this is also just building the axm query um and then essentially what happens is we get this ether scan transaction uh where we see the new tax rate and reward rate that have been updated um so let's talk about the project ideas real quick uh so Computing the total volume uh traded by swap pair uh providing that a user lost at least 10 eth by buying and selling nft um getting access to a def5 protocol Trust settl trustless settlement of onchain gas price derivatives providing uh proving that a block contained a sandwich attack um algorithmically adjusting D5 protocol parameters um proving an offchain solver ran correctly giving users incentives or aird drops based on their onchain actions minting an FTR or badge for achievements for an onchain game uh or giving incentives for prior users of a competing protocol to switch protocols um and so we have these five prizes and each prize is worth $2,000 um and you have best overall use most collaborative best use of axium for onchain identity best use of AUM for Defi and best use of AUM for onchain incentivization so you can build these ideas uh with ax V2 on testnet available today and uh these are all the different uh links that we have here the example that I went over is in this examples V2 repository here and then the hackathon guide is at eth global. aim. XYZ thank you very much