Installing Ethereum's ZK Coprocessor w/ Yi Sun (Axiom)

**Speaker A:** Foreign. **Speaker B:** Hello and welcome back to the Strange Water Podcast. **Speaker C:** Thank you for joining us for another exciting episode. Right now is a very good time to be interested in cryptography. Not only are we seeing some incredibly powerful and important products that are being built directly on cryptography, long thought to be academic or impractical, the research is moving so quickly and in lockstep with industry that every few months we end up solving problems that we previously thought insurmountable. To be a cryptographer in 2023 is one of the the most exciting positions to be in. And yet we have a problem. Our industry is based on some of the most abstract, complicated and difficult math to have ever been invented. It's incredible and so fortunate how cryptography and industry have fused so closely and begun racing forward together. But the result is that all of us mid curve brains or Alphabet application devs or really all builders who don't care that much about math, they're lost in a debris field of unintelligible moon math. To put it more bluntly, it's one thing to discover the tools, but it's just as important to make the tools actually usable. **Speaker B:** We are very good at the former. **Speaker C:** But I think that we need a lot of help on the ladder. And the problem is actually even worse in our specific industry because developing for blockchain or within the EVM is such a new, specialized and poorly understood skill that it's almost impossible to have a full grasp on smart contracts and ZK cryptography. At least for now. Today's guest is Yi sun, co founder of Axiom. Axiom is developing a ZK coprocessor for the evm. The idea behind Axiom is simple. Instead of implementing incredibly delicate and complicated ZK cryptography directly into your smart contracts, you can offload the task to Axiom who can process the requests off chain and then deliver the result with a ZK proof fully verifiable on chain. It's clear to me that ZK will eventually become a critically important technology that underpins life in the modern world. But to get from here to there, we need the axioms of the world to build the developer tools, experience and the knowledge to make ZK actually usable to abstract away the PhD level number theory so that developers can focus on what they are here to do create applications for real human users. This is an incredibly fun and interesting conversation covering everything from Yi's background and the origin story of Axiom to the role or the purpose of ZK cryptography and even some ideas on how ZK will interact with the world once the vision has been fully realized. One more thing before we begin. Please do not take financial advice from this or any podcast. Ethereum will change the world one day, but you can easily lose all of your money between now and then. All right, time to start the conversation. **Speaker B:** Yee. Welcome to the Strangewater podcast. Thank you for joining us. **Speaker A:** Yeah, thanks for having me, Rex. Looking forward to it. **Speaker B:** Yeah, man, I am super excited and I'm super excited to talk about Axiom and like, how you guys are bringing ZK to, you know, like, the evm. But before we get there, like, I'm a huge, huge believer in, you know, the important part of every conversation or the people involved. So before we get to Axiom, can you tell me a little bit about who you are, how you found, you know, what's. If not crypto, then cryptography, and yeah, just get us to understand Yi that founded Axiom. **Speaker A:** Yeah, definitely. Till pretty recently, I actually took a pretty traditional academic path. So I was a statistics professor at UChicago and before that did a PhD in math. And during my PhD dabbled a bit in traditional trading, HFT, equities and futures. And I got interested in crypto in 2017, actually through the market side. I was really interested in the fact that you could trade all these coins globally. But very quickly I got drawn into the fact that you could actually achieve consensus on a global basis and all the possibilities for what that could enable. So since then, I've been poking around the space, trying to understand all the new developments. So in 2018, was thinking a lot about what type of consensus algorithms could make sense. Went pretty hard into DeFi in 2020, just trying to understand what new market structures could be enabled. And then in 2021, I realized that all of the magic properties that ZK had promised since 2018 could actually be realized. I remember in 2018 running a Zcash transaction, thinking it was really cool, but realizing that 15 minutes was probably a pretty challenging wait time. And so in 2021, when I realized that the tooling and performance had just gotten substantially better, started doing a bunch of open source work in ZK and actually eventually got drawn into the space full time. **Speaker B:** Nice. And so when you say that you were like, really excited by and interested in consensus, like, can you just unpack that a little more and help us? You know, was it about this, like, permissionlessness? Was it you. You brought up zcash? Was it about privacy? Like, when. When you realized that consensus was like, basically like academic concept that like, had applications and like a huge Amount of research. Like what, what got you so excited that you're willing to dabble in like, let's say, technologies and assets that are in, you know, like a legal or regulatory gray area? **Speaker A:** Yeah, it was just this idea that you could establish some sort of global source of truth that wasn't really enforced by any entity, even a government. And I felt like that was something fundamentally new to the world. And of course one of the first applications of that would be the list of account balances of everyone. But I got pretty interested in what else that could enable. And so the precise technical underpinnings also were kind of fascinating to me. **Speaker B:** I think people that are in ZK World and especially building in ZK World, it's just like part of our daily conversation that Ethereum or crypto is about so much more than Defi and finance because of really the technologies that people like you are building. But I think for a lot of people who aren't like living and breathing zk, it really feels like this is about finance and I guess, like, do you have a moment where you realize that like what Ethereum, what cryptography enables is about more than just, you know, like trading assets back and forth? **Speaker A:** That's a good question. When I made that leap, I think, yeah, I was definitely first drawn into Bitcoin and the whole idea that you could have any source of value that wasn't governmental was quite interesting, I want to say. When I saw cryptokitties way back in the day and okay, that's the most non financial thing you could really get. And it was just really interesting to me that that was possible to build. And I don't know if you remember, it actually took down Ethereum essentially for about a week. You could still transact, but it was pretty expensive. And so it really expanded my mind as to what this thing could be good for. And honestly, before Defi got really big, I don't think when I thought of Ethereum, I was thinking too much about financial transactions or anything really. More about payments and then other wacky things on top of it. **Speaker B:** Cool. So let's, let's go to like, you know, we, you went full time or you entered Crypto in the 2017 cycle. But it sounds like 2021 is where you really like stood up as a builder and realized like, there's an opportunity here. Can you talk a little bit about, you know, like starting to ingest the ZK research and realizing that like this is the promised land that basically like we were talking about but couldn't really perceive in definitely in like the 2008 era, but even in the 2015 era. What was going on in 2021? **Speaker A:** Yeah, definitely. So from 2017 to maybe 2020 I've been studying just the ZK research papers, just learning the various algorithms. But the problem was just that the performance concretely was pretty bad. And in 2021 two things happened for me. One is that I was helping out a friend who's designing a defi protocol called antifinance anti. And there what they want to do is settle different markets on whether certain on chain invariants hold or do not hold. And one aspect of that settlement is to actually access whether an invariant held in the past or not. And so at that point I realized, wow, actually on Ethereum you can't access historic data from a smart contract in any sort of native way. And so I thought a little bit and realized that maybe ZK could be used to solve this problem. And that actually triggered me to try to figure out what the state of ZK was in late 2021. So I just looked at all the tooling that existed, realized things have really come quite a ways even since the start of COVID Then I went to a 0x PARC learning group to actually learn how to concretely write ZK circuits and so just dived down the rabbit hole. So yeah, it started off from very fundamental things. Did a bunch of open source work on writing ZK circuits for cryptographic primitives like elliptic curve operations, and then moved on to reading from Ethereum data structures, which it turns out is what's necessary to access the history of Ethereum. So at that point I honestly hadn't thought too deeply about the evm, about the actual merkle trees underlying Ethereum. And so it was kind of a wild learning experience. **Speaker B:** Yeah, well, so like let's kind of continue down this path. I mean what you're, you're building ZK circuits. I'm sure in this moment you're realizing that while the math and the theory is done, the actual implementation and the tools are like so far from being done that it's actually pretty shocking when they exist in the first place. So I'm sure this is like the, the area you're entering and you're starting to realize like you a very useful thing that has been untouched is like ingesting and then dealing with data from the evm. Can you talk us through what was your aha moment? That there's a company to be built here? **Speaker A:** Yeah, actually for a very long time I actually wasn't sure whether it's just some sort of exploratory project. In the beginning, I wasn't sure if you could do it at all. And so I thought that surely people had tried to do this. But I, I did a very quick search, I didn't really find anyone. And so I just set out to try to do it myself using a pretty, one of the more classical proof systems called Circle. And so it's very easy to use but not so powerful. And so after about two months I had some prototype. It could access one contract variable from an Ethereum block in about one minute. So while I thought it was kind of cool that I could do this, it certainly was not going to be scalable to anything that anyone was going to use. And so over the summer, last summer, I spent some time learning about more advanced proof systems and eventually settled on Halo 2, which is the proof system that the Ethereum Foundation ZKVM uses and was originally developed by zcash. And so there it felt like performance could get much better. And also with my co founder, we started writing some open Source libraries in Halo 2 and we found that the performance we could achieve just with our learning projects was pretty competitive with state of the art. And so that gave us some confidence that we could really do something here and also got to a performance level where it might be useful in practice. And so that's when we decided to really go for it and try to build it out into a real product. **Speaker B:** Yeah, awesome, man. So let's using these kind of experiments, let's really talk about, talk through what was pos, what wasn't possible before, or what you would need to do to access Ethereum state data and then talk about how your experiments solve that and then we'll transition to how to build a company on that. But before, when you started this whole I say explore phase, let's first talk about the problem statement. So you're, you know that you want to do something in a smart contract and that action is predicated on, let's say, the historical variables within that smart contract, like since it's been deployed on Ethereum and without, without ZK or without any extra tooling, like can you first talk through today, like how you might, let's say, like go get the historical price of ETH from the Chainlink contract just using Ethereum. **Speaker A:** Yeah, yeah. So if you want to access, let's say what Chainlink said the ETH price was one year ago today, you're kind of out of luck. You basically have two options as a developer. So there's one option which is in principle trustless, which is that every block of Ethereum commits to the entire history of Ethereum. That's the definition of a blockchain. And so if you had infinite computational power, what you could do is exhibit to your smart contract, let's say every one of the past 1 million block headers, check that the hash of each block header is in the next block header. So that would establish that A block header 1 million blocks ago is what you say it is. And then check that the commitment to the contract storage variable of chainlink a million blocks ago is what you say it is via Merkle proof. Now, cryptographically, that's all fine, and if you use an Ethereum Lite client today, that is kind of what happens. The light client will send you this sort of this proof. Now the problem is that you definitely can't do that on chain. First of all, you can't put a million block headers on chain that would exceed the size of a block. And secondly, even if you could, it'd be pretty expensive to check the Merkle proof. So what developers do today to work around this is they basically have two choices. One is that they can keep additional data around in their smart contract. So imagine if chainlink, instead of overriding their previous prices, just kept a complete record of all prices that went through the system. That would incur just a greater cost every single time that they update, but you'd have more access. The challenge with that is that even if you don't care about the cost, it means when you first deploy your contract, you kind of have to anticipate all future uses of data in your contract, and you have to cache data in anticipation of that. If you look at Uniswap V2 and Uniswap V3, they did some caching for specific purposes. For example, Uniswap V3 caches some variables specifically to allow liquidity mining. But the challenge with that is it's quite specific. It only works for one type of liquidity mining, and that turns out to not be the pervasive type that's used today. Now, of course you have another option as a developer, which is that instead of having a trustless on chain solution, you can kind of just put the number on chain yourself. And maybe you call it an oracle, maybe you don't, but that obviously has a challenge that your users now have to trust you to accurately put that. **Speaker B:** Number on chain and to secure your system so that no one else can put bad data on your behalf. **Speaker A:** Yeah, that's exactly right. Maybe you have the best of intentions. I think most development teams that get to any sort of scale definitely do. But yeah, hacks are kind of scary. And you have seen some of these multisig oracles, two out of the eight keys get hacked, and that's definitely very sobering. **Speaker B:** Okay, so before you're experimenting, just to be clear, your choice was essentially to try to do this in the EVM directly. And like, maybe you could hack your way through, or maybe with proper caching it could happen, but the reality is that it is prohibitively, in every sense of the word, expensive. And then your other choice is that you can calculate, verify, do whatever you need to do off chain where computation and memory and bandwidth are super, super cheap, and then put that answer into the evm. But you really, really are. You're creating a trust assumption in that explicitly. And so that's the state of play before you started. So let's talk about when you start experimenting with zk. What is your thought? How do you think you can change this? And how do you think that ZK is the secret sauce in order to make this happen? **Speaker A:** Yeah, so I guess my starting point was I realized this fact about cryptographic commitments. And actually, initially I thought, oh, great, we'll just check this decommitment in the evm. Then I went through the calculations that we just talked through and I realized, okay, we're definitely not going to do that. And so then I realized, okay, ZK is supposed to be able to take this expensive computation and compress it and make the verification much cheaper. And so that seemed to me like a pretty good fit for this computation, which would be verifying the chain of block headers and also verifying the Merkle proof into the Ethereum state route. So that sounded pretty good. And as I was experimenting, I was like, oh, I know how to write a Merkle proof verification, and that's pretty simple. And even in zk, surely that's quite simple. So at that point, that's when I learned about the Merkle Patricia Trie that actually underlies Ethereum, which is definitely substantially more complex. So then I went and read about the actual data structures and realized, hey, this is definitely a whole other level of complexity. There's a Hexary Trie, there's this custom serialization scheme called rlp, and all these things are extremely expensive to actually do in zk. So, yeah, I went ahead and wrote an initial implementation, not thinking too hard about performance, just trying to get things to work. The runtime for proving One storage slot was something like one hour. At that point I was like, okay, this is maybe not so practical. I went and did quite a bit of performance optimization to bring it down to the sub minute level. **Speaker B:** Very cool. So you bring it down to sub minute level and you realize, okay, even if this isn't production ready yet, it's clear that me hacking around without any resources or like a clear vision or clear customer can get this far. Like, I'm assuming that this is the moment that you realize, like, here's the problem statement of like, look how complicated and look at how many PhDs it took to just hack together a solution. But also a solution was possible and performance is possible. Is this the moment where you realize, like, we need to build a company around it? **Speaker A:** Still not. Actually I was still. I felt like I was kind of a novice in the space. Like I just started playing around. I. I didn't really like, I wouldn't say I had too much formal training in ZK or anything. And also I felt like the performance still wasn't quite good enough to deliver a lot of value. Like, crypto users are extremely impatient and you know, if, if one, if one data access costs you a minute, you know, it might be a little tough. So my co founder and I started exploring this proof system called Halo 2. And the way we were exploring was that we knew in principle it was pretty performant, but we honestly couldn't figure out how to use it. The reason is that the existing circuit libraries were extremely complicated and frankly, we just weren't able to read the code. So we set out to write our own library just for learning because we didn't really understand things. We chose probably the simplest possible settings. In Halo 2, you have to define certain objects called custom gates. And we chose frankly, the simplest possible gate of all. We went out and we built a elliptic curve library for elliptic curve arithmetic, eventually enabling what's called proof aggregation and recursion. After about a month, we had something working and to our substantial surprise, we were outperforming the existing library and actually enabling a much faster aggregation time. And so that really gave us the confidence that we'd be able to scale the system and also deliver just lower latency for the same storage proofs. **Speaker B:** So this is the moment you are ready to start a company? **Speaker A:** Yeah, well, this is the moment where we feel like there's something there, right? Like, hey, like there's this new primitive of accessing historic data on chain and like, we feel like we have the tools to make it scalable and so we, we definitely had some core conviction that this primitive was going to be useful, but I can't say that initially the markets felt the same way. So we went and talked to a bunch of identity startups and we were met with the resounding reception that they would rather just put the user's identity on chain themselves. And so that was a little bit discouraging. But ultimately we felt like we were providing just this huge new tool and we felt like the market would eventually shift to demanding a trust minimized solution if it were possible and easy to use enough. And so it really was that sort of conviction that we were actually able to build it and that we were adding something net new that made us go for it. **Speaker B:** Yeah, makes a lot of sense. And I will return to like the story of Axiom and really what Axiom is in a moment, but just in this like entrepreneurial moment of creating a ZK company. I think now in retrospect it's pretty obvious, but at the time when you were creating this company, it really wasn't. But like, it is so easy for us nerds who have spent way too much time like digging into it to like, think ahead to what, what does this enable? Like, what types of problems is this solving? Like, even if we're still at the infrastructure level, like if we can scale it here, then we know that new use cases will be opened up. Like, that's super, super easy for us, but like the hard part for everybody else is like, what the hell are these guys even talking about? Like, I don't know what number theory even is. I don't know what cryptography is. Like, how am I supposed to understand how to implement any of this stuff, let alone understand why I'm implementing it? And you know, I think all the companies that are like the most exciting right now, including Axiom, can almost entirely be boiled down to ZK is impossible to use, nobody knows how to use it. Like, we want to abstract away the ZK so that developers can focus on building applications and not PhD level math. And so does that kind of resonate with what you think at Axiom? **Speaker A:** Yeah, definitely. We think ZK is super powerful, but our audience is really the normal solidity developer who, you know, as you say, doesn't want to learn number theory, maybe doesn't want to learn Rust, even, just wants to use tools that they're familiar with and enhance their smart contracts and do more. In all of our communication with developers, we never try to reference ZK as some fancy tool. That's good. We really only talk about, hey, here's what it's doing for you. Here are the trust benefits. And we do try to educate around why does ZK have those benefits? And if developers want to learn more, we run a bunch of educational programs for that. But ultimately the, the end user is just focused on writing their own smart contracts and their application. And so we have to meet them where they are for sure. **Speaker B:** I mean, I think like a great analogy for this is ssl, right? Like nobody knows how SSL actually works and how like the data that is encrypted, whether it's between you and Gmail or us over this call, or even like just like the most mundane, like going to the weather channel, right, is encrypted with like military grade encryption. But nobody knows how this stuff actually works. They just know like, okay, I need a certificate from somewhere else and I need these lines of code in here. And as long as I have those two things which are very well understood and auditable and like, whatever, like if that's in, then my website's secure. And I think like, that's the future we need to skate towards with zk, which is there's always an opportunity to like fall down the rabbit hole and become like as antisocial as the rest of us. Right? But like, we shouldn't want that for people. What we should want is them to. **Speaker A:** Experience. **Speaker B:** You know, ZK the same way they experience like a React component or a Python library or just like modern computer science. **Speaker A:** Yeah, completely agree with that. And I think part of making that happen is getting developers motivated to learn at least a little bit about zk. Not the math, but just how ZK can be applied, namely what is the API of zk. And I think for that, that's why we focus a lot on enabling new applications with zk, because I think developers are pretty motivated by making more expressive like on chain applications. And our experience is that if you tell a developer that they can do a pretty cool new thing, they are willing to meet you in the middle and at least figure out a little bit about how could they use zk. What are the differences in application architecture that are necessary? But of course we can't ask them to learn math. That's a rich. Too far. **Speaker B:** Yeah, I barely can do math and like I enjoy this space. So yeah, I can only imagine people who don't. Anyway, so let, let's go back to Axiom and you know, I'll just to put a little context in for the listener's head, like the thing that I Find like really cool and really special about Axiom is that there are a lot of ZK projects right now. And as we just talked about like basically the only ones that are like moving forward are the ones that are about like just creating developer tools, creating abstractions and like making ZK more performant. But like what, what's very special and unique about Axiom is as far as I'm aware, you guys are the only ones that are thinking about how do we focus on the experience within the like purposely poor computational and like extremely low resourced environment that is the evm. And I think, you know, again on this podcast I've had, you know, folks from Nguayama, from Risk Zero who are building these incredible tools that are really for developers that are outside of the EVM and then just kind of want to send a commitment or trustlessness down to Ethereum. So with like the ultimate question being what is Axiom? And can you just give the brief elevator pitch, like can you talk really about why the EVM and the EVM experience is like the right opportunity for you guys and what you're building? **Speaker A:** Yeah. So Axiom allows developers on Ethereum and EVM compatible rollups to access the entirety of historic data of Ethereum and do verified compute over it. So developers can use Axiom in a completely self serve way. You don't have to talk to us, although maybe you want to. And we let you query into the history of Ethereum, do your own computation on top of it and get to a result. And we verify all results on chain with a zero knowledge proof that checks that all the data you accessed really was in the history of Ethereum and that the compute you wanted to do is valid. So our starting point really was to serve smart contract applications and enable them to just do richer things. And our observation was basically there's definitely a compute bottleneck on chain, but what a lot of people don't realize is there's more of a data bottleneck. So first of all, if you do any sort of solidity or EVM engineering, you'll realize S store and S load are some of the more expensive opcodes. And frankly, if you don't have access to a lot of data, it's very hard to do any type of interesting computation. And that's what motivated us to start with the data first. Plus we have the problem ourselves. But once we dug into the problem, we really realized that the data I think is bottlenecking a lot of interesting applications that could be developed today, even more so than compute, for example, on layer 2s, the compute actually drops in terms of relative pricing quite a bit, whereas data is passed through as call data and ends up being still somewhat expensive. Yes, in the broader space of zk, our feeling is actually that crypto is going to be a market leader here, where only within crypto is the price of trust high enough that users are willing to deal with, frankly, the pretty bad developer experience of using CK today. The latencies are kind of high, cost is kind of high, and it's generally, although we're working hard on it, still relatively difficult to use when you compare to something like React. But within crypto, the whole premise of the space is as much activity should be on chain and trustless as possible. And we think that can really catalyze the development of the underlying technology until we get two or three more orders of magnitude in performance. And frankly, in the last couple of years we've already seen that. I think the first use case of ZK was ZK rollups. And when the concept of ZK rollup was invented in 2018, I remember reading about it and then looking at the existing ZK systems and thinking like, well, we're like 1000x off. I don't see how anyone's ever going to make a ZK roll up. But you know, like two years later, somewhat people really did. And so I think that feedback loop between the active on chain applications and the technology development is really critical. **Speaker B:** Yeah, I mean, man, so much to say here. And yeah, so I guess before we go, like just too meta about it, let's just really drill in on like what Axiom is. So definitely a set of smart contracts. Correct me if I'm wrong. Do you also like provide a centralized archive node that's querying all this data and figuring it out and then through the power of ZK is then turned into trustlessness or how does this system actually work? **Speaker A:** Yeah, today users can send us queries either by sending a transaction to our smart contract or hitting our off chain API. Then our centralized prover hits an archive node to find the answer and then generates a zero knowledge proof and verifies it on chain. So we're permissioning, proving to start just for safety. If there's any sort of bug in our ZK circuits, we certainly won't exploit it. So we just think it offers an extra layer of protection for users. But the crucial property is that once we've actually verified the proof on chain, as a downstream user, you don't need to trust us or really anyone. All you need to trust is that the on chain verifier of the zero knowledge proof is accurately implemented and really does enforce that your query is being answered correctly. **Speaker B:** Yeah, well, one of the things that I really am thinking hard about in the ZK space is so what you said is that you don't have to trust anything, accept that the smart contract is implemented correctly and can, according to the math theory, verify a proof. Right. And that's something that like, especially you, who's much smarter than me, can like understand for yourself on first principles why that's happening. Somebody like me who is like much, much less technical and much less mathematical can like understand the theory enough that like, even though I don't really know what it means to like multiply a polynomial by an elliptic curve point, I can understand the analogy enough to, to build confidence and trustlessness. But like, let's ladder down all the way to like the end users of applications that are going to be enabled by ZK middleware. How important do you think that it is that people in that whole stack trust the ZK cryptography? And how do you think about educating the layers that are beyond the direct developers implementing this? **Speaker A:** Yeah, I think it's definitely important that anyone who wants to get more transparency always can, and that there's a very clear and auditable chain of trust, both from theoretical algorithms to their implementation. And then the third, the fact that the circuits you're writing actually correspond to the algorithms that you care about. Now, as you mentioned, definitely only a pretty small fraction of the world will be interested in checking this stuff, but I think the story there is that you hope at every level of abstraction there are enough people who are curious and demand transparency that you have a quasi automated system system to verify things. I think if you think about the translation between solidity code and EVM bytecode, it's pretty similar story. I think probably most people have not really tried to check whether a verified contract on Etherscan really does correspond to the bytecode. And frankly it's not that easy to check. You have to make sure your solidity compile versioning is all correct and all the settings are the same. But I think just having that green check mark on Etherscan and having the reputation of Etherscan behind it does a lot to help users understand what the contracts they're interacting with do. And I think in ZK it's going to be very similar. It's probably a little bit harder to create that transparency, but it's something as a space we need to work on. **Speaker B:** Yeah, and I think really the Insight at the molten core of this conversation is that for all human endeavors, trust is involved. Right? And, like, we're trying to build systems where there are pillars that hold up the entire system that are not based on trust, and so people can verify and see that there's actually structurally something there. But, like, what makes us different from animals or from, like, rocks or anything is our ability to coordinate and our ability to build relationships. And, like, trust. Is that magic? And I think that there's something so hard but important for us to understand that, like, trustlessness is still built on a foundation of humans, trusting humans. **Speaker A:** Yeah. There's always a social layer in crypto. Even if you take away any sort of zk, you know, how do you know that the latest block of Ethereum is actually valid? Now, you could say that, hey, I checked all the signatures. I run a beacon node. But how do you know that those are the rules that everyone else is coordinating on. And ultimately, I think crypto and ZK just offer some automated tools to let us scale that trust a little bit and scale that social layer. But at the end of the day, why do people even care about what happens on Ethereum? It's only because these numbers have been compelling enough to provide some type of cryptographic evidence that everyone in the world actually accepts. **Speaker B:** Yeah, and I think there's two layers, right? One is about the builders and the mathematicians and the people that are going to actually understand it and implement it. And we can achieve systems that are actually trustlessness at that level. But in order to scale it to mankind, we need to get the rest of humanity to trust that these systems have valuable properties. And so, like, there's always going to be a moment where it's like, hey, the system works. It's verifiable. But, like, now it's not time to, like, basically masturbate over how trustless it is. It is time to, like, get people to use it. **Speaker A:** Yeah, I kind of feel like we're on the front lines of that. Frankly, the biggest pushback we get from developers is. Is like, hey, why do I need this proof? I could just put this number on chain myself. And I have to say, in some cases, that's totally valid. If you're trying to bootstrap some sort of social app. Does anyone really care that you've trustlessly computed their reputation before? The reputation itself is valuable? Probably not. On the other end of the spectrum, if you're doing governance for a dao that controls substantial assets, well, hey, then it's maybe economically pretty valuable for that Governance to be trust minimized. We see all sorts of reasons why people actually might prefer a trust minimized solution that whose connection to trust is not so obvious. One is that you can dramatically modularize your smart contracts by having this type of design. Essentially, if you want to keep additional state on chain in your app, you kind of have to have your core business logic and your side effects of your application just together in the same contract. If you upgrade your logging, you're upgrading now your core business logic, and that's a pretty fragile situation. Whereas using ZK to do the whole thing lets you completely decouple that. And paradoxically, that's been a pretty big selling point that, you know, doesn't ostensibly have anything to do with trust. **Speaker B:** Yeah, I mean, I. It's interesting, right, because we're in a phase of crypto where like we're all kind. And by we I mean crypto Twitter, which is never a good group. But like we're like kind of saying it's really bad to have upgradable contracts and proxy contracts because like they're really important hack vectors. And like in certain senses I think that's really true. But when architected correctly, like ZK is the solution to that. And like, for anyone who's ever touched computer science or programming ever, like literally nothing is more powerful than just simply like simple modularity and abstraction. And so like that. That's not something we should want to throw away. **Speaker A:** Yeah, but obviously you totally understand. Smart contract developers will be as inventive as necessary to build the applications they want for sure. **Speaker B:** Okay, so let's. While we're still talking about how the Axiom system is constructed, I want to zero in on a point that you said about how today and during launch or during the launch phases, correct me if the terminology is wrong, but the prover group is centralized in permission and it at least today is like just you guys, can you talk? Well, let's talk through like how important is it that that becomes like a permissionless, open set of people that are willing to do proofs and stuff and how. And maybe like the power of ZK cryptography is that like it always can be like a single company or single institution that is like running the computers. And it's not like this wide decentralized group. But because of ZK cryptography, we've solved basically all of the trust problems, except for censorship. So can you talk through a little bit about how important you see the decentralization outside of the Ethereum layer for these kinds of systems? **Speaker A:** Yeah, I think the driving concern, there is censorship. So in terms of soundness, if the proofs are implemented correctly, there's not really any type of concern, but there's censorship and also liveness. Maybe our servers, the data center holding our servers catches on fire, then obviously we wouldn't be able to fulfill queries for a period. Now our approach to this is that we think first of all, the whole point of ZK is that you can execute one computation once and prove it so that everyone else doesn't have to re execute it. So the level of redundancy that really makes sense, we think is definitely lower than, let's say, validating Ethereum, which should have the highest level of redundancy. We're not really sure where it's going to land. I think it might be something like block building, where the number of players frankly is not that high. It's pretty capital intensive. I'm hopeful it can be a little bit higher than that, maybe somewhere in the 100 to 1000 range. But it does get a little bit complex since as a user you're paying for that redundancy. If two people try to generate a proof for you, only one of them gets paid. So your price probably has to be 2x as large. In terms of applications today, frankly, we feel like this is a pretty new space. People honestly prefer that we generate the proofs, we ask if they want to generate the proofs. No one has ever asked us to generate a proof themselves. Our approach is going to be to progressively open up the set. Most likely initially it'll be a smaller group and then we try to go bigger. And one thing that a lot of people probably have not thought about is that there's some mechanism, design questions surrounding having a decentralized prover. I think some of the ZK rollups are hitting this earlier than we are, but there's definitely some considerations around mev. If you don't assign proofs to provers and then if you do, then there's a question of whether that could cause some liveness concern. **Speaker B:** Yeah, no. And I just, I guess it's been two weeks now, but just got back from Stanford sbc, which I would like to rename is the ZK Conference. But they, it was really clear that every rollup company, the thing that they're focused on is decentralizing sequencers. And I think, yeah, it's shocking to me how much of an engineering problem that is. I mean, you'd think like, I don't know, like we figured out consensus, we figured out zk like modularize it, put it together, what's the problem? Right, but I don't, I don't know if there's any. Is there any interesting conversation we should have around like the challenges behind decentralized decentralizing, I guess, ZK proving. **Speaker A:** Yeah, the analogy to sequencer is actually quite apt. Maybe one thing to say is that the problem has an additional dimension in the ZK proving space. And the reason is that sequencers almost by definition have a pretty regular and fixed workload. If you're constructing blocks, those blocks on a rollup are taking typically going to be very similar size. But with zk, that's not really the case. If you're not on a ZK rollup, but instead just doing arbitrary computation, the proofs you generate might be highly variable in size and also demand. And so that makes the problem of actually assigning the provers to jobs much more complex. If you think about it from a purely centralized perspective, it's basically a job scheduling problem which already can get pretty complicated even without any type of decentralization. **Speaker B:** Yeah. And especially in the early days, while your organic, I guess like transaction flow or like customer needs is like relatively low and maybe has gaps like you basically need to dedicate a super, super powerful machine to be waiting on standby and you know, like computation isn't free and if nothing else, like there's opportunity cost by like not having that running on something else. So it gets weird when you like can do cloud services and spun up just in time but like it the point I like just very much take your point that the difference between sequencers and ZK proving is you just by definition rollups like have to do something every block interval, whereas you guys only have to do something when there's a real customer need. **Speaker A:** Yeah, and so far it hasn't been too bad. We're hopeful that some of the serverless GPU solutions that are coming online will be really helpful in this regard. **Speaker B:** Very cool. So I think with the remaining 15 or so minutes of this, like, I would really just love to, to maybe like take you through your sales pitch to developers or really help like the audience understand like what are the types of applications and what's the type of world that is enabled when first like your initial product is like being able to trustlessly access historical Ethereum state data. But come on, we can all read the tea leaves here. You're building expertise in zk both on the smart contract side and on the proving side. Both sides are going to need more proving in the future and so you'll be able to service those needs. In particular for cryptography that may not have Ethereum as a direct touch point. But today it's tough, right? It's tough to see what new categories of applications or new ideas are going to be possible. And so with the big, big asterisks that today things are slow and, and not that performant and pretty expensive. But like by the definition of technology, you make order of magnitude improvements on those things and new use cases that like, were actually not conceivable before Openup. So with that asterisk, like, how do you sell to developers, like the types of capabilities that this technology enables? **Speaker A:** Yeah, definitely. Today we're looking for evangelist developers where we're providing them valuable enough information that they're willing to deal with a lot of cost and latency and things like that. So we're starting off in governance, where the ability to prove how many votes you have, that's potentially priceless. Or maybe in some cases it's priceless, in some cases it's literally price zero. So yeah, I think that's pretty obvious use case where users can prove just their historic balances. Another direction that we're really interested in is continuous incentivization on chain. The basic idea there is we'd be able to prove that a user has performed some type of activity. Let's say they did $1,000 of volume on Uniswap, and we envision a world where they can prove that to a smart contract and autonomously claim some sort of incentive or airdrop using that. So if you look at Uniswap, everyone pays the same fee. But if you look at any exchange in the normal world on Binance, there's volume tiers, on Nasdaq there's a fee rebate. And so we think it's just a law of economic reality that Uniswap should have this. And the core reason it hasn't happened yet is frankly, it costs more for Uniswap to compute how much rebate you should get than for you to get the rebate. So you might imagine through Axiom we could prove the volume and then through some criteria set on chain, users could claim their reward. **Speaker B:** And so can you talk through why it's important in this specific case to have that be a ZK proof and not, let's just say, why couldn't Uniswap Labs, the company, just run that calculation off chain and then tell the Uniswap contract where to distribute? **Speaker A:** Yeah, I think there's sort of two answers to that. One Is that if Uniswap Labs is actively distributing the Uniswap token or whatever, it definitely hurts the decentralization of Uniswap as a whole. I think Uniswap philosophically really wants to be a fully on chain protocol. And I think even if this is sort of an auxiliary loyalty system, I actually think it makes more sense for it to be on chain. The second is just that when you have extremely complex off chain computations that go into determining these rewards, sometimes it becomes a bit, there's a bit of trust from the user to this entity that they're actually computing it correctly. If it's very simple, obviously no issue total volume. But if it's some sort of complex hidden formula, I think users might have similar questions. I actually think that this matters most, not for someone like Uniswap Labs. If Uniswap Labs said they were going to do a computation, I definitely believe that they're going to do it. But I think if you're a dev team that's anonymous or less well known, or maybe you're a meme coin creator, maybe users are going to trust you a little bit less. And so I think it's these little niches of low trust environments where we think this is going to start. But ultimately our feeling is that once it becomes easy enough to do this on chain, users are going to start demanding it. **Speaker B:** Yeah, no, I mean I definitely believe that again, the laws of technology are if you make tools that are like performant and easy to use, people will find interesting ways to use them. And so you're exactly right to look at how real exchanges work. Realize there's a huge gap between how real exchanges work and how Uniswap works and not think, okay, that's going to be fixed long term. Right. Because otherwise Uniswap just can't compete. Why would anyone with real money trade there, market make there? I guess so, yeah. Okay, so that, that makes a lot of sense. Again like I, I see so many applications around everything from like loyalty to gov, like basically anything that has to do with on chain reputation. Are you thinking about or working with any companies yet that are working in either? Like I'll just, I'll just say the NFT space or like anything interesting in kind of the more creative creative land. And then are you working with anyone that are thinking of what I think that ZK is really going to unlock, which is like real world assets or off chain assets? **Speaker A:** Yeah, definitely talking to a number of creators in the NFT space. And one thing we found is that actually people in the more creative areas of crypto might even care more about being on chain than people in the super high stakes, lots of money on the line parts of crypto, which is definitely a learning for us. Yeah, we think it's really exciting. You can imagine NFTs that evolve based on proven user activity and as you say, just different fine grained areas of your identity. You might even imagine gaining access to some sort of defi applications or on chain social applications based on, based on, you know, your activity or even just the age of your account if you want to shut out civil attacks. Curious to hear your thoughts on the off chain assets. Definitely not an area we support explored too much. **Speaker B:** Yeah, well I think it's going to be, I think we're going to have to wait for the next like bull narrative, bull run to like hit the masses on that one because it's just, it's too big a leap to like be interested in Sam Bankman Fried's world right now if you're not already in it. So like don't want to get anyone's hopes up too much. But it's just like when I look at the long, long term like roadmap of Ethereum and like the direction of zk, like for me and just how much the world has changed and become connected in the last 20 years, like to me what a huge part of the Ethereum story is, is about giving the Internet of things the ability to like really exist on the Internet. And like what it means is like that these things without governments or you know, these human ideas, like can have an identity online and therefore like actually create a system. And so you know, like I envision a world where it's like you know, like sensors in the Arctic are monitoring climate change and like trustlessly sending down that data so that you know, like cross national agencies can allocate funding or like that kind of stuff. Or I imagine a world where driverless cars like each have the identity and can like you know, get into your house, pick up your kid and like take them to school all with like trustlessly without worrying that it's a kidnapping. Right? Or I see a world where cargo containers or even like things within a cargo container have like an individual identity and so can be like traded or like in some way receive like economic activity while it's crossing the Pacific, right? Like used for insurance or used as collateral. Right. That to me is what Ethereum is. And like the second you start seeing the world that way it's like oh well, ZK is how it happens. **Speaker A:** No, I definitely agree. I sort of see Ethereum as ultimately becoming the root of trust for all data in the world. And like you say, that could be sensor data from ships, that could be data that's already on chain today. That could be data from a social media site like Twitter. And Yeah, yeah, we feel like on chain, data is just the start. And it doesn't have to be data that's literally on chain. It be could just be committed to on chain. And our feeling is that what we can do today to build towards that future is to actually enable developers to build applications in a way that has to be tailored to that type of root of trust for data. **Speaker B:** Yeah. And one of my favorite games to play is like, how can. How do you describe Ethereum in the most, like, reductive way possible? And I just steal mine from some talk I heard that Vitalik was giving that was about like, okay, what does this machine look like in a post? Dank charting, like with state expiry with, you know, like clients with all of this look like. And he said something to the effect of Ethereum will just be a bulletin board that anyone can go put something up in. And then like a month later it falls off and it's like. And so like, I just, I'm like, totally with you. That like, the idea that maybe what all this means is just like committing to stuff on chain as just like a record of it or basically Ethereum itself, all it needs to be is identity. And all the interesting stuff can happen off chain or in the real world. But as long as we use Ethereum and it's extra layers as identity and settlement, then we're just entering a world that's more trustless. Like. And I guess that means different things to different people. But. Yeah, I don't know. I mean, I think. And I think that's what's hard. That's what's really hard about building ZK tools. And especially like a ZK vision right now is that even more so than Ethereum, you have to have already drinking the Kool Aid to like, really get excited about it. And then it's just like you've lost your ability to talk to regular people. Like, you can only preach to the choir. **Speaker A:** Yeah. I will say one thing that's happened recently that's really helped for that is the rise of generative AI. And really it's the only time I've ever heard regular people ask like, hey, how do I know this thing is real? Can I have some Evidence that this image I'm seeing is real. And I think as these AI models get better and better, we're going to start asking like, hey, do I really know who I'm calling? Or when my bank calls me for verification, is this really me? And I think the end point of those thoughts really does land on cryptographic verification, since that's really the only type of verification that a model won't be able to spoof. And so I think that's a very interesting macro trend in the world. **Speaker B:** Yeah, no, I mean, yeah, I am so confident that crypto and AI are part of the same story. And not in a really annoying VC way, but just like when you're in the computation it's like, like especially like when you get down to the hardware level, you're like, I don't, I'm pretty sure we're just doing the same math, like different amounts of times, you know, and across like different size matrices essentially. But I, I, what I really believe is that like AI is about abundance and about like creation and just like imagination and all this stuff. And like what crypto is really about scarcity. Like basically everything that we're building is built on a principal foundation that scarcity creates value and through value like we're just going to embrace the rampant capitalism and then mold it to create outcomes that we want. And so you know, like when I see chat, GPT or mid journey or whatever, like my thought is like, okay, today, right now, like you and me, let's do a startup literally right now, let's just start taking every image that's on the Internet and making a commitment and then just like putting it on immutable X or like whatever the cheapest like place we can put call data is. Right? Because eventually like that's how we're going to solve this stuff is like, oh, when was the first time it was verifiably seen on Chain? And you can't say that this image of, let's say Biden doing something horrific could possibly be real when it's never been seen on Chain before. And so Axiom clearly has a huge part in that story to play. And so I guess, fun little way to go out on. Do you see any interesting intersections with crypto and AI or really crypto and any other technology that makes you really excited about what you're building? **Speaker A:** Yeah, I've done some research work on ZKML before, basically using ZK to prove the correct execution of machine learning models, even relatively large neural networks. But really what makes me interested in that intersection is this notion of data provenance. I really like your idea of checkpointing images on chain. And I do think that the demand for provenance is going to be what brings more data. Maybe not fully on chain, but committed on chain. And yeah, at Axiom, we feel like ZK has a lot to do to build tools to allow applications to be built around that. Today we use the blockchain as just sort of naive database, but you might imagine a less naive ZK database. You might imagine a database that even an application like Twitter could use. And so we're pretty interested in building the infrastructure that can actually enable all of this. **Speaker B:** Yeah, for sure. And the most exciting thing about ZK is that unlike almost anywhere else other than machine learning, like the industry and the academics, like walk hand in hand. And it's just so cool that like you are ingesting the stuff coming out of universities and putting into action like months after, like brand new mathematics is creating, created. And on the flip side, yeah, definitely scary. But on the flip side, like research in cryptography is not becoming, it's changing from like, how do we make things harder and harder to crack? Literally the same problem we've been working on since Alan Turing and Enigma and like, just like, like vibes wise, like, what does this specific 10 year professor think is like a good idea and transforming it into these are real world problems and real world needs and like direct your research into things that actually matter. And like, man, it's just so exciting and so cool and man, I just wish you all the luck. So with that, how do people get involved? If people are excited by this conversation or just like want to learn more about how to add ZK into their applications, but more importantly, why they might want to add ZK into their applications. What should they do? **Speaker A:** Yeah, we're live on mainnet as of July. You can check us out at Axiom XYZ and you can follow our Twitter AxiomXYZ for updates. We're going to have a bunch of news to share there quite soon, so do check us out, man. **Speaker B:** Yee. This is incredible. Thank you so much. And yeah, man, I hope you reach out if you have anything interesting about Axiom to share and I'd love to talk to you about it again. **Speaker A:** Awesome. Thanks so much for having me, Rex. Really enjoyed it.