Episode 276 - Expanding Computation on Ethereum with Axiom

Transcript

welcome to zero knowledge I'm your host Anna Rose in this podcast we will be exploring the latest in zero knowledge research and the decentralized web as well as new paradigms that promise to change the way we interact and transact online [Music] this week I chat with Yi Sun from Axiom he covers how Axiom Works what a co-processor has been historically in Computing what it means to be a co-processor to ethereum how zkps can be used to help bring historic data into smart contracts and the new use cases that this can enable now before kickoff I do want to direct you to the ZK jobs

board there you'll find jobs from Top teams working in ZK so if you're looking for your next job opportunity be sure to check it out and if you're a team looking to find great talent be sure to add your jobs to the jobs board today I've added the link in the show notes now Tanya will share a little bit about this week's sponsor [Music] Elio is a new layer 1 blockchain that achieves the programmability of ethereum the privacy of zcash and the scalability of a roll-up if you're interested in building private applications then check out Elio's programming language called Leo Leo enables non-cryptographers to harness the power of zkps to deploy decentralized exchanges hidden information games regulated stable coins and more visit

developer.alio.org to learn more for questions join their Discord at elio.org forward slash Discord so thanks again Elio and now here's our episode [Music] today I'm here with Yi Sun co-founder of Axiom and recent guest of the CK podcast welcome back e thanks for having me back on it now yeah last time you were on we actually did this episode about ml it was for me a really important episode I feel like I learned a lot but we didn't cover in that episode though was Axiom the project you're actually working on or we just mentioned it in passing and so yeah I wanted to have you back on to really talk about that yeah definitely so we've been building Axiom for a

little over a year now and Axiom is building a ZK co-processor for ethereum okay and what that means is that we allow smart contracts to do new things using ZK so we let developers access historic data on chain and use it in their smart contracts and that wasn't possible before without using ZK to make that whole process trustless got it let's talk a little bit about the sort of creation of Axiom so in the previous episode that you're on we did hear your bio and background but yeah maybe let's start that's story again from the founding of Axiom what is it who are the co-founders how did it come together yeah so the origin of Axiom was really in a pretty concrete developer problem so I was helping out a friend uh build a

D5 protocol called anti-finance and anti allows projects to commit to certain on-chain unit tests about whether for example for a lending protocol assets will be greater than liabilities and they had the very specific problem that they wanted the test to fail if at any point in the past assets dip below liabilities and so we were just thinking through whether this was possible for a smart contract and we quickly realized it means smart contracts need access history so you can imagine my surprise when I realized that was impossible damn let's explore this idea of History what do you mean by that yeah so essentially if you look at what

smart contracts can access on chain today when you go to the web front end for an on-chain application you'll see lots of very informative data about for example for openc the historic owners of an nft yeah all the transactions that have occurred the price history and if you try to Circle which of those numbers actually open C itself on chain can access you'll realize quickly that there's only one of those pieces of data namely the current owner yeah and so you realize from a smart contract point of view the developer is actually quite Limited in what it can do and of course developers today really mask that from the user by presenting it in nice front end and hacking around the problem but

fundamentally if you want to do things on chain in a trust minimized way today you're quite limited wow so what are they doing in that case is it just like on a centralized server where they're just like every time there is a change record is kept like in the kind of web 2 way but then and it displays on the website but actually if you were tried were to try to like scan the blockchain today you wouldn't necessarily easily be able to find it so if you scan the blockchain today you could query all this information from an archive node okay and I like to think that archive nodes exist to serve the human eyeball so developer requires archive node puts it on their web front end and the user can see the information but what it's not good for is serving the smart contract I

see so if you want to take for example the historic transaction data from openc and do some on-chain operation as a consequence that's very difficult today got it so you mentioned sort of the archival node when you're dealing with a smart contract it can't look into the contents of this node can it yeah that's exactly right okay as a human you can of course query an archive node and you're implicitly sort of trusting that the archive node is sending you correct results so when you see something on the uniswap front end that's what's happening okay now a smart contract obviously can't query an archive node off chain and even if it could well just be getting a number and you know we all know on chain you're not supposed to just accept numbers that an arbitrary person put on chain okay but then okay

so then how do you get this archival part like if you're saying a smart contract can't do it what can do it yeah so every blockchain has a unique twist which is that the current block commits to the Past block and the block before that and so on so actually the current block contains a commitment to the entire history of the blockchain yeah and if we were able to cryptographically reverse that commitment we'd be able to give a cryptographic proof namely via chain of hashes that any piece of historic information appeared in the history of ethereum now the catch is that verifying that proof is quite expensive you might imagine if you want to prove something a million blocks ago you have to present the million intervening blocks oh wow

which is quite a bit of data yeah and in a smart contract context you would never do something like this yeah that's exactly right you can't yeah basically can't okay but then is there anything that maybe not a smart contract but something else can actually query to get that that isn't so expensive so when you query an archive node you can sometimes ask it to produce more data it's called a light client proof so that's something that lets you cryptographically verify that the piece of historic information it gave you is actually in the chain and if you want to use that on chain you can try to verify that like client proof on chain okay so to reduce the expense what we do at Axiom is to put that into ZK so we use the succinctness property of zero

knowledge proofs to reduce the amount of data that has to be put on chain to prove the access and also to make the verification cheaper I recently met a developer named Tracy who is looking really closely at this space and he was really kind enough to like map out a little bit what this looks like and what he described was that the thing that's in the smart contract the call can't directly talk to this archival node so instead you're doing this like separate call to the archival node what is that called what is that there's a optional extension to these Json RPC API which gives a call which is eth get proof okay and actually Alchemy and inferior both implement this call and so it allows you

to in addition to requesting a piece of contract storage you can accompany it with a Merkle proof that that storage value is actually committed to in the history of ethereum I see is that very very heavy like is that not verifiable like what's wrong with just having that and then immediately writing that chain yeah so it is verifiable you basically check some hashes but the difficulty is it's pretty large okay and the cost of verifying these proofs adds up so if you want to query one piece of historical data you would have to verify this Merkle proof against a historic block hash I see and we can get into how you get these block hashes which is its own thing okay but suppose you wanted to

query let's say a thousand pieces of historic data now it's approximately one kilobyte per proof okay kilobyte times a thousand is a megabyte which quickly adds up so you're just saying like you might be able to do this thing but it would just be like completely impossible if you were actually trying to do more than this one query meaning like it's very very limited yeah that's exactly right if you think about most applications you actually want to do you need to query quite a few pieces of on-chain data to really do anything so then are you creating sort of a intermediate interface or an intermediate environment do you have something that's like hearing the smart contract going off chain and then doing this query and then it goes back to it

yeah maybe describe a little bit what this looks like yeah that's exactly right so when a developer wants to query into Axiom they send us an API call that can either be just a standard off-chain rest API call or they can emit an on-chain event which triggers us to fulfill the query so on our side we will look up the historic data and perform some post-processing and compute on top of it once we get the result we generate a zero knowledge proof that everything we did was kosher that we fetched the right data and we did the compute correctly and finally we verify that proof on chain in our smart contract and deposit the result for the on-chain application to use but in that case you actually I think you just said it so say

we're say we're starting from a smart contract somebody writes a smart contract they somehow in that smart contract ping you or access you you then do the query you then create a proof you bring it back but like do you actually do something as well are you like changing the state in the Axiom environment we actually in our smart contract we have a list of verified results of queries and so developers can read into our verified results and use that information Downstream in their application to change State on the main chain yeah that's exactly right how do you force that though like it like I can't even really imagine what like is a smart contract written in a very

specific way is it different than normal smart contracts or like is there a different even like formatting if you're like sending code off chain or is that just like normal I'm not a solidity developer so maybe it's just like a normal thing that always happens it's just a normal smart contract so the the difference is that everything we put into our smart contract it has to be verified with the zero knowledge proof verifier that also occurs on chain in our contract so it's very similar to how an oracle works so if you request let's say a price feed from chain link today you make a request either off chain or on chain okay chain link provides a fully trusted price on chain and then your application reads from that price from chain link smart contract uh the

only difference with Axiom is that all the results we put on chain you don't have to trust us we already have a proof that verifies that they are correct so you're replacing that trust with the zkp and are they also doing this like archival data or is this actually also novel the fact that you're like specifically focused on on the historic data yeah we're focused on historic data because it allows us to verify it without any additional trust assumptions so our philosophy is that anything you get from Axiom shouldn't impose any cryptographic assumptions beyond what you're already trusting on ethereum okay so any number we give you you can think of it as the same as a number you read from Smart contract what kind of ckps are you actually using have you decided

that we actually think of it pretty holistically today we're using Halo 2 okay the kzg backend so we're using pretty standard snarks and we're using lookup tables and custom Gates so the whole the whole modern toolbox yeah yeah okay but I actually think of building in ZK as maybe similar to operating in the early semiconductor industry there are sort of new technologies to make ZK proofs all the time you have to continually upgrade your back end to deliver a better performance and because the jumps are quite large you really have to keep up where you'll be left behind how hard is it to update your snarks though you know it's honestly a question of art rather than science but like do you have

to redeploy the entire system every time I'm guessing yes yeah you just definitely have to redeploy the on-chain verifier okay but we've designed our system to be somewhat modular so we have a core system which serves the function of caching all block hashes of ethereum from Genesis until the current block and we have systems which call into that to verify user queries against those block hashes so we can we can opt to upgrade pieces of that as needs arise or as we can deliver greater efficiencies in terms of the querying like are you running a full node full archival node as well in your system or is that like are you pinging a stranger right now we're pinging frankly infuria okay

eventually we will run a archive node but the beauty of our system is that the user doesn't have to care how we're producing the results because we're producing a proof that there's a results are correct so to the user we could have maybe done everything by pen and paper so long as the proof verifies they should be okay with the result wait how does the proof verify on chain that it's correct how does it know it's correct yeah so the key that's a great question actually so whenever you verify as you're an ultra proof you have a root of trust meaning that there's no sort of absolute truths about the chain you really can only verify that if you believe that a certain block hash was present on ethereum then you should

believe that it contains a commitment to some potentially very complex historic statement okay so we always have to check that claimed block hash for a specific block number actually was the block hash that occurred on ethereum but when it's verified on chain it still can't look into the archival node right yeah that's exactly right so you're basically relying on like the zkp to say because we're using this ekp this is why it's correct yeah that's right the only aspect that the evm provides to look into the ethereum data structures themselves is the block hash op code okay so you can use so there is a view from the smart contract on chain into just that that's right just that it's very limited you're taking

advantage of cool so you can see the last 256 block hashes but nothing further okay um oh that's interesting and we actually have to work very hard to extend that view from 256 block caches back to Genesis okay why do you use the term coprocessor what is actually a code like is it mimicking something on in computers like Hey where's that word coming from yeah you have to dig kind of into the dark history of semiconductors uh back in the day before everything got integrated into CPUs when you built a computer you'd have your generic CPU processor and then you would have different coprocessors that were specialized to different operations okay so I I went back on the internet and found a picture

of actually a math co-processor so as a coprocessor that allowed you to do floating Point arithmetic effects wow and it was actually made by a company called mathco very nice so yeah back in the day these you would buy like your processor and then you'd buy a coprocessor and hook them up and so we think of our system as an analogy of that for smart contracts so smart contracts are really good at doing synchronous small computations yeah and accessing a small amount of data in a synchronous fashion whereas Axiom allows them to access huge amounts of data asynchronously and do kind of big computations on top what era when you talk about like that math chip what era is that from I think the last one I was able to find was the early 90s okay so

from the 70s to the 90s it was kind of a thing to have a co-processor for your physical processor do you think we should we can think about the blockchain as being in that state then in a way like are we 1985 I actually like in terms of what a computer looks like and how it works I went back to see what it you know in terms of clock Cycles how fast is ethereum yeah I think I concluded it was something pre-80s well definitely in the 70s really and I wonder do you think that like actually developers in the space in general should be looking at those models to like sort of predict what other tooling will be needed or actually should we like not do that because maybe computers need to be rethought

I think a combination is helpful so blockchain computers are certainly extremely limited computers in some ways and that's where I think looking at historical analogies can be helpful on the other hand the constraints of blockchain computing are pretty weird for an example there's this distinction between synchronously accessing State and asynchronously accessing state which doesn't quite exist on a standard you know old school computer why is that is it because of the decentralized nature because there's nodes everywhere and like information is flowing in different places or yeah why why does asynchronous not exist there yeah it's exactly this requirement for decentralization so when you run a transaction on ethereum what's really happening is that all the

validating nodes on ethereum are re-running your transaction and coming to consensus about whether they ran the transaction correctly so first of all that's tremendously expensive there's a 500 000 X overhead but secondly you have to actually come to consensus every time so when you run a synchronous transaction on ethereum you're paying that overhead so what ZK is fundamentally allowing us to do is to run that transaction asynchronously wow when you say asynchronous like are you kind of saying that like the Axiom environment might actually be taking more time like would it take I don't know three blocks where if you tried to do something like this it would normally be

one and then it comes back three bucks later and changes the state is it like that or yeah we let you do access way more information but the price you pay is that you have to commit to some historic block at which you're reading that information and once you're finished processing that block and generating the proof you can put your conclusion on chain in a trustless way but it doesn't have to be the next block it doesn't have to be the next and that's the asynchronous where like something can be happening over here and it comes back later that's exactly right so you have to wait a little bit to process off chain is there anything else from the main chain that you could be accessing like you've talked about historic data maybe that is the only thing that's there but is there anything else that one could try to derive from

these nodes we do want to access sort of all on-chain data so today we offer access to block headers account data so your account balance your knots and contract data yeah and finally local account storage so or in the process of adding transaction and receipt data which would in particular give developers access to events would it ever make sense to have like another node tier that like is analyzing these nodes maybe this is actually what this could be where it itself becomes a source of truth that could be queried does that sound totally insane you can totally be like you're not a computer stupid it's actually something we've thought

about okay as being uniquely enabled by ZK so so at the beginning of the conversation we mentioned that you know smart contracts can't read archive nodes yeah but really that's just because any read a smart contract does from an archive node would need to be accompanied with some type of proof and at present those proofs are huge and difficult to verify so One Vision we have for the future is to actually put an entire archive node in ZK so imagine proving the correct execution of your full r-cut node okay so that's a huge task but if we were able to do that we could serve every query from our archive node on chain in a provable way interesting would there ever be I'm going to tell you a little bit more what

I'm actually envisioning which is almost like there's an analysis of historic data that's then stored in a new structure to always be easily queried but like not that you'd have to run the computation each time could that exist is that sort of what you just described that's what we're that's the direction we're going in so we're thinking you could process the the chain once and in a certain way in a certain way so imagine an archive node but as a side effect generating a zero knowledge proof of every step and recording those proofs in a ZK friendly format once we're in that format if a smart contract queries against it we could return the result of the query much faster than it than the initial process of generating the proof got it

this is cool and if you think about a normal archive node that is kind of what it's doing it listens to blocks somehow processes them and ingests them into its database and it can return queries to a user quickly what we're thinking of doing is adding ZK over this whole layer interesting I I've had another question just about Axiom and not just Axiom projects that I think fall in sort of a similar category what are you I mean you're using the term coprocessor but like in the ZK context are you a tool are you another category are you like a platform an environment like I've actually when I do lists if I list Axiom on it it's sort of like ZK plus because I don't know what it is what is it I would say we're sometimes

somewhere in between a developer tool okay and a platform okay so we intend ourselves to be used by smart contract developers who don't have to know anything about ZK and the problem we think we're solving is that ZK can do many things but it's really inaccessible to developers today like maybe if you're very interested you can write circuits and get deep into ZK but if you just want to build a more powerful and expressive application there's really nothing there to help you use it today yeah and we're just really focused on helping developers do more in their applications when you're writing those initial smart contracts though do you need to know a certain like syntax to communicate specifically with you or

yeah what what's going on in that yeah we strive to make our smart contract interface as simple as possible developers frankly don't need to know anything about ZK they just have to read from very standard solidity data structures and the trick is that the ZK is powering the fact that all of our results can be relied upon in a trustless fashion but like in the smart contract itself it's just regular smart contract language they're not like doing new things yeah just regular solidity okay we but is it true that like say you're looking for like a historic piece like there is no query currently to be done in a smart contract for the base chain so like is it just sort of a blob of text that's like not being read in the smart contract that's exactly right

okay so the query and taxium is made to be interpreted off chain so it's simply an off-chain rest API query or just a blob of encoded data that's emitted on chain and interpreted often where in the smart contract is that I don't even is there memo field like where does it go uh we intend for developers just to admit an event okay it's an event yeah so it's actually quite similar we're mimicking an on-chain oracle call so when developers call into chain link they either can hit a chain Link's off-chain server or also emitted event with their call I see so you're kind of following that model yeah we think we just want to be as close to what developers are used to as possible in this example though like so everything we've been talking about is sort of like

getting a piece of data or getting some data Maybe range but like would you be able to calculate like an average over a period of time or like can you actually do like a calculation on that and kind of yeah to what extent can you do things in the beginning we're offering very basic post-processing of data so we can feed you arbitrary historic data and give you the Merkle root of that data and developers can access that in a self-serve fashion today okay we're also offering sort of custom ZK circuits to do specific processing that can enable specific powerful applications what we're building in the future is a virtual machine that can layer on top of that and allow developers to specify compute in a query language on top of

the data that they're accessing where does the VM live so the VM is executed fully off chain okay and what's important is that the correct execution of the VM is proven in ZK off chain okay and this is living then the VM would live in the Axiom environment yeah that's right and how complicated could these processes be then like how are the computation like do you have an upper limit to what still could not be done or do you feel like anything yeah we think what's kind of special about this co-processing setup is that there's no fundamental blockchain limitations to the computation you have to do interesting so long as you can prove the validity of the computation in ZK then you can use it on chain whereas in let's

say a roll up you actually have these considerations like should you be occupying all the block space of the roll-up for your computation at the expense of others I actually was just about to ask you like what's the interaction then with a roll-up like I can imagine that you could live on a roll-up yeah that's right but if you're able to like run computation and all it is is writing a proof are you then sort of competing with like the value proposition of a roll-up they're kind of saying that they're the environment for all of this computation because it's so cheap but you're sort of saying like well actually there's this VM where you could do a lot of the computation and you only have to write like a single proof yeah we think we're offering a village really complementary type of computation from what Roll-Ups do so we

think Roll-Ups are really good for things like trading on an amm and that's very synchronous computation where the transaction right before you really affects your transaction we're thinking of operations like performing a neural network inference or Computing your on-chain reputation these are things where it's a pretty long running computation and it's relatively independent of other participants on the Chain so as you mentioned earlier we can definitely serve rollups and we can also feed information from let's say eth L1 to Roll-Ups you sort of mentioned earlier the like client you're not building a light client are you like would you put yourself in a similar category as something like succinct at all the project because I in the past

have well if you guys yet but then realize like I don't know if you really are doing the same thing yeah I think we're pretty complimentary so also complementary okay yeah succinct is proving the ethereum consensus so it's really operating at the consensus layer and we're taking the consensus as a given and verifying against the block hashes that consensus already agreed on I see you're interacting with like clients but you're not creating a like client of your own yeah that's right we're using my clients but we're not creating one I see and the reason is we don't want to impose any additional truss assumptions so because we're verifying on ethereum itself if a user is willing to accept ethereum then we have a cryptographic equivalence between the data we're providing and what ethereum itself provides

any sort of cross chain-ness to this because as you're describing it I'm sort of like basically the smart contract would write from one roll up and you could then actually instead of querying like base chain roll up or base chain L1 you could just like query another roll up and then you're delivering information back is that at all what you're doing like are you kind of a bridge we're definitely not a bridge okay you don't want to be a bridge well definitely not a token bridge but like are you message passing Bridge Maybe I I think we are part of a modular construction of a bridge I see so our perspective is that we're going to deliver what we view as objective facts and we want our users to choose uh what sort of mechanism they want to use to

bridge those facts between ethereum and other chains or Roll-Ups so in the case of Roll-Ups there's a native bridge and so there's not really much controversy of what over what to use but we think for cross-chain applications users all have their own favorite Bridges and what we want to do is verify facts on ethereum and users can choose how to Port those facts to other chains I see with the system that you've built today you would never be querying the block header headers of another chain for ethereum but you you're only doing that query to the ethereum chain right yeah today we support reading from ethereum mainnet and verifying against a block hash of ethereum mainnet and the user can choose what trust assumptions they

want to put on that block cache so if that's on ethereum we provide a way for them to access those block hashes fully trustlessly if that's on a roll-up then the native Bridge provides a way for them to access ethereum block hashes now if it's on another blockchain then the user can choose what sort of bridge they use to get access to those block hatches okay could someone build us I guess they could build something like Axiom on another Network but I guess the thought is like since most of the activity I guess most of the interest is on ethereum that you would you wouldn't have as many queries that way yeah we can definitely support reading from any evm equivalent chain so that includes Roll-Ups or even alternative l1s right

now we're really focused on ethereum mainnet just that's where most of the developers and users are yeah but if that changes we're definitely open to supporting developers where they are have you looked into any of the other ecosystems about like how they would feed you historic data like are other blockchains built differently than ethereum I assume so yeah we've done some basic investigation some blockchains are easier than others okay so there are some chains like near where every block actually natively contains a commitment to all previous block hashes okay and so that makes things a lot easier for us of course we still have to adapt to their storage formats but that's not a huge deal other blockchains like Solana have a much more complex way of committing to Historic state so

there's no individual commitment to the full State and so that's a lot more challenging for us to handle interesting but I guess like this it sounds like you're not doing work in those directions right now anyway you just sort of evaluated yeah right now we're really focused on sticking with the evm and we're starting with ethereum mainnet and we're thinking of adding Roll-Ups to start with nice I want to hear about potential use cases like we've talked just now about like the architecture and some of the the where the information's going but we haven't really talked much about like who uses this why do you use it why do you need this historic data what does it actually enable so yeah like tell me a little bit about the kind of use cases that you're envisioning yeah I'd be really curious to hear that yeah

definitely we're pretty excited about use cases that are funnily new and not possible without this access to Historic data one of the big patterns we like is enabling decentralized applications to have accountability and what I mean by that is the whole purpose of a decentralized protocol is to coordinate the actions of some group of participants and we think the most fundamental tool is to be able to reward good behavior and punish bad behavior what's bad behavior though in this case bad behavior would be just anything slashable so if you okay if you have a protocol typically you want to slash people for doing something that's against your rules through your consensus rules

um not necessarily consensus it could be a decentralized application I say okay or it could be something that you don't want to put into consensus but which you still consider to be bad one example would be if you have some sort of Consortium of validators or block producers you might want to say hey we are like good block producers we're not going to mine a sandwich Tech so maybe you could stake some collateral saying you're not going to do that and we could prove like hey this producer mined a sandwich attack they should be slashed so in the case here bad is not like you are a hacker yeah like that you can't undo that you're not watching for that if they're able to hack a smart contract and take funds you can't like stop that that's right it's more on this the

validators the Mev side it sounds like it could be sort of any on-chain protocol does it as a different example where maybe the consequence is not slashing if you have an on-chain asset management protocol you want to see the performance of your asset managers and typically you want to see things Beyond just their profit at the end of the day you want to see how much risk they took what was the type of drawdown they had and you might want to pay them or even potentially slash them based on what they actually did interesting so in this case like this I mean I guess these are examples where historic data accurate historic data and nuanced in-depth historic data is really interesting yeah we want to give developers more

programmable control over how they design their applications today you kind of have to bake your reward or punishment mechanism into the fundamental design of your smart contracts and we think that if if developers can do that much more flexibly they can design just richer applications can you imagine something like Insurance becoming more on chain because I'm just thinking like there have been these Insurance protocols but they're kind of clunky it seems like and I don't know that they're tracking things at that level but there you could almost like decide like what is the rate of insurance based on actual historic behavior of some on-chain protocol or phone chain application I think there's

sort of two directions we're interested in one is underwriting so if you can look at a user's historic Behavior or look at a protocol's historic you know loan to value that might feed into some sort of machine Learning System that determines the parameters of let's say your insurance protocol or even your lighting protocol itself wow is it this is not a credit score is it I don't think it's quite it's quite a credit score credit score comes with connotation yeah like uncoateralized lending which is tricky on chain but I think of it more as underwriting so if if a protocol has set some risk parameters and they're doing quite well maybe they can be a bit more aggressive with those parameters or if there's been a couple close calls maybe you should have some autonomous system to back off

a little bit what are some other use cases where you'd need that and another sort of defy setting we sort of think that D5 protocols today have very simple parameter sets on chain and the reason is that they're not able to adjust them in a trustless fashion at high resolution so in amms they pretty much have a default set of fees whereas we think that fees should really depend on market conditions if it's a very volatile Market maybe a user should pay more for the Privileges trading gets in am whereas if the Market's not doing much maybe the amm needs to lower fees to incentivize Trading and so we think that there's a new generation of D5 protocols that can be built using this awareness of historic information that's

interesting are there teams that have already shown interest in that or is it almost like because this tool is being developed these new opportunities are there like have you heard desire for that we we've seen some teams essentially changing the parameters but in a fully centralized way so the team itself just changes the parameters and because they're looking at historic data like by eye yeah exactly they're they're running some octane computer programs and they kind of pick the parameters and sometimes this is called an Oracle and I don't think it's necessarily bad uh but I I do think that if it's switched to this more trustless model they can change those parameters at a higher resolution and just more frequently what are some other like tangible maybe like

user-facing use cases that people might think about one big vertical we're really excited about right now is governance so if you think about what's necessary for governance the most fundamental object is voting and to vote you need to know how many votes you have okay and so in a lot of settings on chain there are sort of dows that for whatever reason did not bake in the recording of how many votes everyone has into their smart contract really and yeah they just can't vote so yeah one thing we're doing is building on-ching boating for a dow that can't vote whoa was this was this cause this Dow was deployed a long time ago and the poet that gets changed since then or is it like yeah is

there some reason why that you can't calculate how many votes you have essentially that's the reason so the smart contract for the Dow was deployed a long time ago and they just weren't thinking of on-chain governance at the time okay and it's obviously you can't modify the smart contract now and so we're helping them retroactively put that back in oh that's interesting is there some use case that sort of would be more focused on the identity front because even like that first use case where we talked about like insurance and stuff like this I feel like there was something about like credibility track record so like yeah is there an identity play here yeah so we can let anything you do on chain be provable and that ties into your identity in different ways so today if you collect an airdrop you sort of claim

to some protocol that you did a set of good actions and they should give you your airdrop but it's fully centralized the protocol team kind of looks on chain and sees what you did we can Envision a future where teams simply deploy a smart contract laying out the rules for what gets incentivized and what doesn't and users can autonomously prove to the contract to get their token reward in slightly less airdroppy fashion we think that you can actually use this for a user acquisition so maybe I'm launching a new lending protocol and I want to just give better rates to users who have used a competing lending protocol oh and we allow you to actually set those criteria in a pretty programmable away

so you can try whatever programs you want to attract users to your protocol damn the airdrop farmers are going to have such a hard time they're just gonna have to be doing everything all the time now exactly and the developers have some tools to fight back we can set very fine grain criteria yeah huh any other ones you keep mentioning inference ml is that one of the main focuses I wouldn't say it's a main focus but we're pretty excited just to give developers better tools to adjust their applications on chain and so for machine learning we think it can be applied initially to D5 so if you want to change your lending rates or if you want to change your fee schedule maybe you should be using some machine learning So In traditional

Finance that's what they're massive teams that trade based on very complex machine learning algorithms but none of that is really possible in D5 today if you look at the code for an am it's pretty straightforward yeah in a way when you say that too does that mean like the predictive nature like it's using it to predict right it's like predict what the rate should be not what it is according to today that that's right today what's on chain is a pretty crude approximation of what could be an ideal rate and I don't think that you can necessarily deploy an autonomous model to get the ideal rate but I think that you can make the on-chain systems a much closer approximation to a more efficient Financial system is there any future like more complicated ml things

that you could imagine yeah we're actually pretty excited about application of ml to nfts oh so there's this whole area of sort of generative art nfts yeah and if you look into it you'll realize that there's nothing on chain proving that is generative that is actually generated from anything oh and so we think that we could tie the identity aspect to General nfts by allowing you to prove that an nft was generated based on your on-chain activity and so this would give sort of farming for the best looking nft like a new meeting so you can imagine promotional nfts like if you are a heavy unisop user maybe you get an nft that has more of a uniswap theme but

interpreted through this generative algorithm it's neat so like since we're talking about ml the last time you were on the show that was the main topic we were talking about works that you and Daniel had done obviously those were like very specific machine learning plus ZK cases but are you using like machine learning somewhere in the Axiom stack are you are you still engaging with that or are you just creating a platform for like use cases of ml at the product level we really want developers to use ML on our platform okay but actually within the development we started using co-pilots a couple months ago it's been pretty transformative is it just faster what's going on it's faster and particularly for things like front-end development it

really fills in all the boilers this is GitHub right yes this is GitHub I'm I'm kind of a novice at it but it's been incredible if you haven't tried it you definitely should and have you seen like I guess a lot of your engineers are doing it is your team just more productive do you notice it I think on more well-trodden types of programming we definitely notice it so on back-end apis and front-end code it's a big multiplier on some of the circuit code and smart contracts less so okay and actually on Smart contracts we deliberately do not use it sometimes it hallucinates various lines of solidity that are subtly wrong and it's much harder to pick up those bugs oh no so yeah we're a little bit careful on the security critical Parts but on

things like the front end we're really excited to use it cool just generally like what is the state of the Axiom product are you on test net are you like is there any sort of sense for when this will actually be usable yeah we put a demo out on mainnet in January and the reason it's on mainnet instead of testnet is we're all about accessing history and obviously there's no history on testnet oh yeah so you can go to our website today demo.axiom.xyz and you can check out a few toy apps we built on top so we got a grant from the unisoft foundation to allow users to access uniswap t-wap values in a trustless way through Axiom and there's a couple other toys you can prove your account age we're working

towards uh production release coming soon and we'll have a couple of launch Partners to share at that time okay cool where do you see sort of the the general blockchain space going do you actually think we're on the precipice of like an explosion of computational power where like we could have on-chain games for real or like on chain like big complicated programs or do you think we're still like just taking small steps towards that I think we're definitely getting some pretty big unlocks um at least at a conceptual and proof of concept level I think what's missing is actually the developer tooling to a lot of developers that don't know anything about ZK or the other Technologies going

into it to actually access that power and once we do that I'm pretty excited about the new wave of trust minimize applications that that's going to enable do you think that like as you're saying this I'm just thinking about like existing development Suites or environments something like Unity or something like huge is there ways that they could start to like interface would they just need to like add a few things to their system to be able to deploy some of the stuff on chain I think proving Unity on chain that'd be awesome I think we're a little far away okay I feel the direction for that to happen is to be able to reuse some of their code and actually prove the execution of that

code in some type of virtual machine the difficulty today is that the performance hit you take by doing that is truly immense okay and you kind of can't even think of using it in a similar fashion I tend to think that the way we are still in the 70s right yeah we're not ready for it okay okay but I think what's exciting is applications typically have two pieces one is the core business logic and the rest is sort of user-facing stuff and I think that applications will be re-architected to put the Core Business logic in some sort of trustless Fashion on chain and have everything else done off chain so imagine it as smart contracts on steroids whoa cool

I wondered like since you're here and the last time you were on you know we did this cknml I wanted to take a minute just to kind of recap what's happened you know we're recording this beginning of May um you were on the show I think in February what have you seen on that front maybe outside of of just the work you guys are doing or maybe even outside of like Axiom specifically yeah I think there are a number of pretty exciting teams building in that space so there's uh open source framework called Ezekiel which is trying to support sort of all manner of Primitives for zkml um and then Daniel has continued to work in that space he recently open sourced his framework which is called zkml and he's been using it to address a bunch of

quite interesting uh models so he recently snarked gpt2 I believe and then he also verified the Twitter algorithm in ZK I saw that actually we'll link to those pieces in this in the show notes we've been talking to Daniel a little bit about that idea of after zkpod.ai came out and I got kind of freaked out it was like is there ways that I could start to prove the you know provenance of audio being recorded by me and like you know actually released by Me versus something like the ai's answers yeah I mean I I hope that we get to see more on the audio front for that because I know you guys had already done a lot of work on images but seeing it in these

different mediums I think is going to be useful yeah and I think it'll be interesting to see where zkml gets deployed so there's always a question of the data provenance so I think that can either come from some sort of a tested sensor or if it comes on chain from some sort of proof that the data is actually validly read from the chain yeah that's crazy what is the makeup of team trying to enter zkml at this time like what do you I guess you need the ml experts need the ZK experts you need the blockchain experts but like yeah is this is this a very difficult to find combination or do you think are you seeing more groups like this pop up I think people coming into zkml really come from one of two directions one is you are already interested in blockchain applications

and you want to apply ml to those applications the other direction would be you're interested in trustless ml and then you view blockchains as one potential application but not necessarily the only one do you think the fear that kind of emerged after gpt4 came out do you think that has also like I don't know encourage more people to look at CK I actually I am curious how much CK has even permeated the imagination of some of the ml people do they know about it I think very few of them know about it okay we recently submitted our paper to a conference and frankly none of the reviewers knew it really thought about this concept too much wow I do think what gpt4 has brought into the public Consciousness is

a need for provenance in Communications of all forms yeah you see this with text and also with deep fakes and fake phone calls and I actually think that blockchains and cryptography as a whole are sort of the way to solve this once you can't trust what you see with your eyes really the only thing you can trust is some type of signature yeah I think it also plays though on the ID front like you're gonna need better ID and then the zkps along the way because like that starting point the thing that signs also needs to somehow be yours it has to for sure come from you and this is where it's like is this forcing an acceleration of these ideas that we thought were like kind of interesting

and cool to like all of a sudden they're like actually needed it's definitely presenting the general population with the first real application where yeah they actually want to verify whether something is real yeah that's pretty crazy I still am due to do like an episode on zkpod.ai which I don't know if listeners aren't familiar with it uh Kobe has created a llm of me speaking and him actually answering questions about CK fed with the podcast transcripts um it's not perfect you should check it out if you haven't seen it though but yeah like that's definitely brought it up for me like that was the big wake-up call that like the you know I'd had sort of these like fleeting like oh maybe

sometime in the future this kind of thing could happen then all of a sudden it's like in front of me and I'm like wow this is now I needed some tools yesterday that don't exist yet and kind of amazingly it's like our community we are in a position to build some of these it's kind of crazy it's good there's definitely some urgency maybe in a few months the episode will record itself yeah I think I mean it's pretty messy still I don't know I think I'd say for a little while because ckpod.ai answers very confidently not always correctly and pronounces things sometimes strangely but anyway to wrap up I do want to just ask you a little bit about ZK generally you've sort of mentioned the sort of tech stack that you're using today and this idea of

upgrading but yeah what's your take on ZK itself what we're seeing is a continuation of the really fast advancement in proof systems and I think the feedback loop with actual applications is definitely helping there's much more engineering going into these systems and really understanding their trade-offs I would say that a really exciting recent idea is folding and accumulation teams in general yeah and this really started with the introduction of Nova I think early 2022 and although Nova was really interesting there are some limitations which prevented it from being applied very widely and recently there's been a flurry of papers yeah one a week almost

that remove a lot of those limitations and show that folding is more of a generic idea rather than you know nova or supernova or hypernova being a specific scheme that you have to stick to and so we're thinking through how that can be incorporated into our systems and what ways we can almost weaponize these ideas to produce the most efficient ZK proofs I I think it's actually very similar to the phase in between the introduction of Planck in 2019 and the invention of sort of P lookup and Ultra plonk ultimately in the next few years interesting where people digested these ideas and realized they could be used in more creative ways yeah I I've been thinking a lot about out

this the sort of development pattern and it does seem to almost be these like steps that are reached there's no standard fully or this that that step only lasts for a certain period of time but it's like from move from step one to step two there's this flurry of research all these different pruning schemes and then sort of like there's a settling around one a lot of tools get built around that built off that you might get variations of that and then there's these like this next step recently I had Arielle Gabby's on on and we talked about these two kind of streams of thinking which is like the accumulation advancements and then the lookup table advancements and that like these are moving at kind of different Paces I don't know if there's been any like sort of proving systems that have unified

them as effectively as they can because sometimes they're using similar underpinnings like if kzg's additive homomorphism yeah I think there's sort of three really cool ideas coming in the space right now there's sort of some check based methods from hyperplunk there's sort of folding and IVC from from Nova and its descendants and then there's this idea of cached quotients for large lookups developed by Ariel and his collaborators and I think we're sort of digesting to what extent they could be mixed and matched what are the precise limitations and how things will look in actual real world engineering yeah because I mean hypernova does include some checks exactly but as I understood not much and maybe there's

more that could be incorporated and you're going to get some interesting trade-off space there yeah and I think the space as a whole is undergoing that process faster and faster I think people are realizing hey if we implement this very quickly get some benchmarks we know exactly what to do next and that this iterative process is actually possible yeah like when Planck came out I don't think it was very obvious that you could just think more about the circle of ideas around Planck and get much more out of it and now everyone I think sort of knows that's possible yeah and so with folding it's sort of happening much faster with subject as well one sort of I don't know if I should say drawback but maybe like challenge or threat to this model like I think it's so exciting

because we're seeing these like stepping points but there is this idea or issue of like auditing these systems knowing actually are these libraries like super fully usable if you think of the speed of the development it's very very exciting people are very like excited and into it you're bringing new minds to to look at these problems that's all good but what is kind of sometimes a little scary is like you're having things built on things built on things and like there could be some Primitives or some like ideas there that haven't been fully battle tested and then you're all of a sudden layering on top of that like lots of value potentially how do you think about that like in a way especially because like you're going to be using a zkp that I'm assuming will have like some form of

standardization at that moment you're gonna feel confident about it but yeah like how are you looking at that are you worried about that would you actually have an auditor audit the exact circuits that you're doing or would you kind of depend on the open source Community there no we definitely take security super seriously um and we think of it in many different dimensions so first off we are getting an audit actually where all our circuits are getting audited as we speak and we're even getting the Auditors to look at the verifier which is actually the most crucial piece because it's the only thing that is deployed on chain okay in terms of new proof systems it is tough um I think it's very exciting to prototype very new proof systems but I think as a space we should be clear that

it's very experimental yeah it's important to prototype to get a sense for the performance but I think when we go to production we want to we really want as many eyes as possible to look at it both from the open source community and even from a more rigorous audit more a very formal write-up broadly we think it's important to crystallize on what is the best expression of an idea and commit to formalizing that proof system and really devoting resources to that implementation and I think with Planck we saw like Ultra plonk be the final form and many different teams are building production-ready implementations of that today with folding I think it's still unclear yeah

and with with some tech and large lookups that's also to be determined I also think that audits aren't the end-all be-all of security I think as a team looking to go to production we want to be pretty deliberate that's why we put our demo up with a ton of warnings if you go to our website it'll say like don't use this for anything valuable and we think we want to climb the ladder of application value we want to start with you know things where even there's some issue it's not a big deal yeah and only layer on things that are more valuable and could lose users money once we have a higher degree of battle testing yeah I mean I think like just on on my front I've been thinking about like how do we incentivize more of the white hat stuff

and like disclosures and making sure that like people are incentivized to look deeply into these libraries especially I mean it's sort of the the challenge of Open Source in a way where it's like the maintenance the maintenance in a way is making sure that these things are correct and but it's like less fun and you don't get rewarded really that much unless you're I mean if you're an auditor and you're hired that's one thing but like how do we get all of those eyes really spending the time to try to break these things before or break them ethically and share that yeah yeah there's definitely a bunch of work that people in running bug Downey programs or platforms like immunify have done in smart contract space and we're hopeful that they can be applied to ZK as well one line of work that I think is

really interesting in ZK but quite early is formal verification of ZK circuits yeah I've been hearing about this a little bit okay so there's a company called verdice that we played a small part in a paper they recently wrote on developing a DSL for cercom that makes it easier to formally verify circlum circuits oh wow and it's a dsl4 circle yeah it's DSL for DSL it's exactly squared okay it forces you to write in this very in this subset of circom that they kind of know how to formally verify I see okay oh it's a subset it's because okay they've been able to check these ones completely but is it a DSL it really is a DSL of a DSL okay it is some

new language which compiles to Circle and it's yeah it's quite complex but we think the pattern that it enables is really powerful because today as a developer you can kind of write some ZK circuits and you do your best you test you audit you internally audit you externally audit but it's very hard to take effort and make your circuits more secure whereas formal verification even if it's quite onerous you can really put in some elbow grease and if you get to something formally verified and your spec is clean like you have a lot of confidence so I think that's a really exciting Direction that's actually that's really promising cool well listen thanks so much for coming on and sharing with us a little bit more about Axiom

this time and sharing this little update on sort of what's going on in the zkml space too yeah thanks so much for having me Anna cool and I want to say a big thank you to the podcast team Henrik Rachel and Tanya and to our listeners thanks for listening [Music] foreign