Anna Rose (00:00:05):
Welcome to Zero Knowledge. I'm your host, Anna Rose. In this podcast, we'll 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.

(00:00:27):
This week, Tarun and I chat with Chris Goes from Heliax, the team behind Anoma and Namada. We start off with a short recap of Chris's journey since we last spoke on the show and what's happened in Cosmos since he and the team at Interchain GmbH launched IBC into the wild over two years ago. We then dive into the topic of the episode that is intents and how one builds systems with intents at their core. We cover the history, the concept of intents from Chris's earlier work on the Wyvern contracts to his more recent work on Anoma. The discussion around intents has been growing over the last six months or so, but the meaning of the term can vary from project to project. So in this episode, we try to lay the groundwork for intents. We explore the history of the term and the existing projects that already have some form of intents baked in.

(00:01:15):
We then discuss how the term can be generalized and the new architectures that this could enable. We start to scratch the surface on the opportunity that this may bring for user experience, but also talk about the trade-offs these systems need to grapple with, especially when you add ZK or privacy to the mix. Now, before we kick off, I wanna remind you about zkSummit10. It's happening on September 20th in London. Once again, we are bringing together ZK enthusiasts, experts and practitioners from around the world to showcase the latest research share updates, discuss important and high relevant themes, and hopefully spark new projects, new ideas, and new directions. There's an application form not only for speakers, but also for attendees. If you wanna join the zkSummit, you do need to fill that out. Tickets are limited, so applying does not guarantee a spot, but we do tend to prioritize folks who've applied early. So get your application in soon. I've added the link in the show notes. Now Tanya will share a little bit about this week's sponsors.

Tanya (00:02:15):
Polygon Labs is thrilled to announce Polygon 2.0. The value layer for the internet. Polygon 2.0 makes mass adoption possible by offering users and developers unlimited scalability and unified liquidity. This mission is fueled by groundbreaking ZK innovations, including a first of its kind ZK-powered interoperability protocol. And the next generation of the industry leading and widely adopted Plonky2 proving system. Polygon 2.0 will change the way we experience Web3 by bringing the security and decentralization of Ethereum to the scale and usability of the internet itself. Polygon 2.0 and all of their ZK tech is open source and community driven. Reach out to the Polygon community on Discord at discord.gg/zeroxpolygon to learn more, contribute or to join in on building the future of Web3 together with Polygon. 

(00:02:52):
Aleo is a new Layer 1 blockchain that achieves the programmability of Ethereum, the privacy of Zcash, and the scalability of a rollup. If you're interested in building private applications, then check out Aleo's programming language called Leo. Leo enables non-cryptographers to harness the power of ZKP's to deploy decentralized exchanges, hidden information games, regulated stable coins, identity products, and more. Aleo's incentivized testnet is now live. Participate as a developer. Apply for a grant or go for a bug bounty. Check out aleo.org/blog for more info. That's aleo.org/blog. You can also find the link in our show notes. So thanks again Aleo. And now here's our episode.

Anna Rose (00:03:51):
So today Tarun and I are here with Chris Goes from Heliax, the team behind Anoma and Namada, and we're gonna be talking about the topic of intents. Welcome to the show Chris.

Chris Goes (00:04:00):
Thank you for having me.

Anna Rose (00:04:01):
Actually, I should say welcome back. Last time you were on the show, you were here talking about IBC and the work you were doing there. I'm thinking this is over two years ago that we last spoke.

Chris Goes (00:04:13):
I think it was around the launch of IBC. Which was in like February/March, 2021.

Anna Rose (00:04:18):
Nice. Yeah. One of the first things I wanna do is do a little bit of a catch up, but I also wanna say Hi to Tarun. Hi Tarun.

Tarun Chitra (00:04:23):
Hey. Excited to be back. It's been a little bit of a sabbatical...

Anna Rose (00:04:28):
I'm glad to have you back. Okay, Chris, let's do that catch up and backstory, since you were last on, you were working on IBC since then, we know that IBC has launched. Tell me a little bit about that time. Yeah, how was it? Did it, did it go the way you'd expected?

Chris Goes (00:04:46):
Yeah. I don't know how I had, I mean I tackled IBC from kind of like a very tactical perspective at the time. You know, there was a bunch of organizational chaos within Cosmos. The engineering team had to unionize and secede. In order to launch the protocol. You know, we were a little bit like short-term focused, let's put it that way. So I, I don't think I had like a theory of the political economy of IBC in 2021. Okay. We just had some design problems, make the blockchains talk to each other, and I really wanted it to be something other than just token transfers because I thought that was boring. And if I spent like a year of my life designing a protocol that people only use to do token transfers, then, you know, it was hard to justify. Here we are two years later, people mostly use IBC to do token transfers.

Anna Rose (00:05:30):
I was gonna, I was gonna ask...

Chris Goes (00:05:32):
But at least, at least people understand that it's more general than that. So that part, like at least it didn't get communicated, you know, early on people read the Cosmos Whitepaper. It said like, IBC does token transfers. And so, you know, I had to, I spent a lot of time trying to communicate that the problem it solves is a bit more general.

Tarun Chitra (00:05:50):
Maybe to go into a little bit, what are the things that aren't token transfers that people do right now that you would say, like stick out in your mind? To me, the one thing that sticks out is like, people who use Tendermint chains for custodying, and then they build all this kind of like, multisig type of management across multiple chains. But there's gotta be something better than that because that's only slightly above token transfer usage.

Chris Goes (00:06:16):
Yeah. I mean, I know there's some usage of I believe the standards are called interchain accounts and interchain queries. Interchain accounts I think is related to what you're talking about. Basically where you use, there might be multiple layers of custody here, but where you use, one chain or an account on one chain to control an accountant on another chain. Interchain queries is basically like state proofs over IBC, just in this nice standardized way where you can request state proofs of particular things. People are using this, for example, for liquid staking in the Cosmos ecosystem, I think there's a chain called Stride, which provides liquid staking for Cosmos Hub and maybe some other chains. And they use some of these non-token transfer IBC packets. So, you know, if you go look at the chart, mapofzones.com, I think it is, I don't know if they display packet type breakdowns, but it's still probably 99% token transfers. But there is at least a little bit of other stuff.

Anna Rose (00:07:11):
Would you say, like looking back, is there any choices that you made at the time that you would now make differently?

Chris Goes (00:07:18):
Yeah, I mean I think, it's interesting to watch in some sense IBC was kind of early, like bridging protocols seemed to have become a very hot topic in the last 12 months, six months. Now, there are a lot of other protocols, which from my very biased perspective, I kind of wonder why they are necessary. It seems like many of the problems people want to solve or problems that at least in principle IBC kind of was designed to tackle. And I wonder, you know, why they don't just use it. But I think that there are good reasons for that. I think IBC made some assumptions about, I mean, it's a relatively intricate protocol. It's difficult to implement it in Solidity, even if the gas costs weren't a factor and on EVM chains, typically they are, it's just like a lot of work to implement a protocol like that.

(00:08:04):
IBC, you know, it tries to provide many things. It tries to provide, for example, different ordered channel abstractions that you can have relationships between the partial ordering is in different state machines. So it's designed for like efficient concurrent cross-chain communication. And how many concurrent VM's are there on blockchains right now? Like just DOT or any of them using multiple IBC order channels to have like efficient parallel cross-chain execution? I think the answer is no. So some of that protocol complexity maybe could have been like, factored out or abstracted in different ways. I think there've been some learnings there. I also think there's, you know, there's still a fair amount of like incentives for communicating things or understanding things that are kind of token-aligned in unhelpful ways. Not that it's anyone's fault, but I think people perceive IBC sometimes as particularly Cosmos specific or Tendermint specific. And some people, occasionally I end up in conversations like, oh, do I have to use the Cosmos Hub to use IBC or something? Or people thought they needed atoms. Which you don't. But that indicates a certain, I think that kind of communications mismatch may lead people sometimes to reinvent the protocol wheel when they might not have needed to.

Anna Rose (00:09:14):
Do you think the role, like now that it is live and it's been live, the role of the relayer is something I'm kind of curious like did you already envision how that would happen? Or had you thought of incentives for relayers? And maybe just to describe to the listeners, like, there is this agent that's helping to move things. I'm maybe saying this wrong, but like bring things across from different zones over IBC, but that often are not compensated. And so incentives for running this infrastructure has been sort of questioned or it's been thought about since then.

Chris Goes (00:09:48):
Right. I mean, to be honest, at the time when we were working on IBC, we had like three engineers. And so, you know, at the time we made the choice to simplify our scope somewhat by leaving problems till later that at least didn't have anything to do with the security of the protocol. And the relayer was one of those. I'm sure we could have considered some of the things at the time more, but I don't think that even if we did there was very much we could have done with the way the scope for IBC was designed. Right? So the scope of IBC takes Tendermint as this black box or takes consensus' black box, which have their own peer-to-peer networks and their own rules for accepting transactions and their own systems of messaging.

(00:10:32):
And IBC just builds on top of those black boxes. Another system of messaging on top, right? So the relayers are acting as message relayers, just copying data basically from one consensus network or mempool to another. And the only way, thinking about it now, the only way I see to really clean those abstractions up is to like redraw some of the boundaries and to put or basically to make consensus more aware of this interchain messaging that's going on to kind of fuse these networks at least partially so that messages can just flow at the mempool layer or the sort of lower level gossip layer directly. Right. I mean, IBC when executing an IBC transaction, in some sense the blockchain already knows where it should be sent, right. It's just the fact that the validators running consensus don't, they don't have any like protocol built-in way to route a message to this other network. So you have to sort of redraw the boundaries to, to get that without any additional relayer, which now you have to pay and it's just this kind of software engineering point of unnecessary complexity.

Anna Rose (00:11:34):
Although they don't pay the relayers, right. Still...

Chris Goes (00:11:36):
They're subsidized.

Anna Rose (00:11:38):
Okay.

Tarun Chitra (00:11:39):
Actually, one other point towards implementing IBC and other networks, it definitely seems like the security characteristics of the particular implementation can be quite nuanced. And so I've always like heard people who've tried doing like EVM IBC style protocols arguing that like they can't really verify the exact same claims. I know you spent a lot of time on the verification for Tendermint and Cosmos at ZK and I imagine that that might also be a slight barrier to entry of like re-auditing that for the new environment might be like just as hard as it was for you the first time.

Chris Goes (00:12:19):
Yeah, that makes sense to me.

Tarun Chitra (00:12:20):
Do you think that's true?

Chris Goes (00:12:21):
I mean IBC you know, also I think it depends on when people try to do it early on. A few of the abstractions in clients, for example, light clients in IBC, which is the part that performs the verification were not the cleanest. They were still maybe a little bit Tendermint-specific or made certain API assumptions, which would be difficult to satisfy with an EVM blockchain or a very different consensus algorithm over time the IBC team has done a pretty good job, I think, cleaning those up. So I suspect that some of these concerns might have been addressed, but there's still, I mean, IBC was not designed to be efficient on the EVM, right? Or easy to implement on the EVM that just wasn't designed constraint in most rollup teams or people building bridge protocols currently. I expect just because of the prevalence of EVM networks take that to be a design constraint, they probably end up with at the very least different like engineering trade-offs.

Anna Rose (00:13:19):
Let's continue on with your story. So, this was cool to hear the recap since IBC launched, but like after the launch of it and after it was rolled out, what did you do? Did you stick around for a while? I know you'd been working at like Interchain GmbH at the time, I think, but like. Tell me a little bit about what, what you started working on since then.

Chris Goes (00:13:41):
Right. So IBC launched, I'm gonna get these dates wrong now, but I think in like February/March, 2021. Along with the Stargate upgrade for the Cosmos network now, IBC launched and then it was on one blockchain. An interoperability protocol on one blockchain is not so useful. Right. So it took a few more months before people launched other chains that I think the Iris hub had it pretty soon on. And the real kind of kickstart for IBC usage came with Osmosis. Right. Kind of later in the summer. So, there was a slow start, but, around the time IBC launched, I kind of wanted to see that through to actual production and it seemed to be working. Someone did token transfers and then that was a good cadence for me to just part ways with Interchain GmbH, although I still remain friends with them and kind of embark upon a philosophical investigation into what the purpose of all these blockchains is.

(00:14:41):
Well, I would say like Anoma started with this vision paper, right? The vision paper describes how we thought about trying to characterize coordination in particular and how blockchains might be helpful in solving coordination problems. But the vision paper is, it's abstract. You know, it's, I think it was helpful for us thinking about things, and it was helpful for recruiting some people who were interested in these aims, but it wasn't yet a mathematical description of the system. Right. It took us, you know, several kind of different tries and incarnations to come up with a good understanding of how all of these concepts and components fit together. So that's what we've been doing on Anoma in the past, you know, past two years really. We care about things like privacy or..., I've stopped using the word privacy recently, I think it's the wrong word, but maybe we'll get into that later.

(00:15:33):
But we care about like, the ability for users to read about where their information is going within a system. We care about all of these design constraints that we wanted to kind of all include to how we even think about what the system is doing in the first place. So a lot of Anoma's journey in the past two years has been figuring out what that is and also the right words to describe it. So I suspect that sometimes people have been confused because very fairly we like use one term to describe a system and then we decided we didn't like it. And then there's like some terminological whiplash going on. But I hope that we are reaching the point of sort of conceptual solidification and it will become clear what everything means.

Anna Rose (00:16:12):
The one of those words is one of the things we want to talk about today, I think, intents. And I have to say, every time I say it, it comes out a little bit like 'intense'. But it's intents, intentions is sort of like....

Tarun Chitra (00:16:26):
That's why it's a good meme though. That's the, that's the point.

Anna Rose (00:16:29):
Oh really? It's just super intense, intents.

Tarun Chitra (00:16:32):
People make so many memes about it because they like can't say it exactly correctly and like every different, you know.

Anna Rose (00:16:39):
Nice. We wanted to bring you on in part because we wanted to start exploring this concept of intents. And I wondered in that story you just shared and like kind of trying to figure out a lot of these concepts, when does the idea for intents start for you? Is it with Anoma, the founding of Heliax? Where, where did that first come up and did you coin the phrase because we think you did?

Chris Goes (00:17:04):
Right. The honest answer to that question is I know when I actually traced this back recently because I was interested in this question. When did I start using this phrase? 'Cause I didn't really remember. And I'd managed to trace the first piece of writing I found that used the phrase was actually back to this protocol called Wyvern, which I wrote as an early Ethereum project many years ago, like five, six years ago now.

Tarun Chitra (00:17:27):
You, it, you should, you should also mention it's one of the most used Ethereum contracts in history.

Chris Goes (00:17:32):
Right or another way of putting it is that the Ethereum miners gained a lot of extra revenue for my very not 'gas optimized' Solidity contracts, which were written in the days of like four Gwei gas prices. Like, it was great. So yeah, a theory of minors you should, you should donate to public goods. But originally I wrote Wyvern and like kind of as, I don't know, just a random project. I was just thinking at the time I was reading a bunch of like, 'Meditations on Moloch' or something like blog posts about coordination problems. And I thought, oh, these blockchains seem like a great tool for solving these coordination problems because you can make credible commitments and you could just describe your preferences about the state of the system. Right. I just prototype that in like a way, but it was a Wyvern kind of implements intents in a very limited and restrictive way on top of the EVM.

(00:18:25):
So in order to do that, it needs like a very hacky like account abstraction sort of thing. It needs...it can only do two parties basically, or I wrote it just to do two parties. Cause other things are just more complicated. But it could do simple kinds of intents and opens the use this even for stuff like bulk orders, I think. So users could describe which NFT's they wanted to buy in a bundle or something and place bids or offers on specific combinations of things. So yeah, early, early kind of prototypical intents system.

Anna Rose (00:18:55):
Cool. I didn't know you, I didn't know you were behind that. I know that from, I mean, if you've ever signed like a bulk thing on OpenSea, you see the name of that contract. It's, it's W Y V E R N. Okay, cool. Interesting. Was it, was that just you or was there like a group of you there?

Chris Goes (00:19:12):
Well, so originally I tried to be pseudonymous and so it was mostly just me. I kind of like, it was very hard to be pseudonymous, which is why I gave up and went back, went to not being pseudonymous no longer pseudonymous. I don't know what I'll do after Anoma to become pseudonymous again. Dye my hair like some other color. But, it was difficult to kind of recruit contributors in that day and age. When you were pseudonymous, there was just too much spam in the world. So Wyvern was mostly just me. I mean, a few people contributed to the open source stuff, but I didn't wanna turn it into a company or anything.

Anna Rose (00:19:45):
So you're saying that, that it was like around that time in that project where you first started to use this term? Let's continue on that. So when was the next time?

Chris Goes (00:19:55):
Yeah, I mean, to be honest, my reflection is at the time I worked on this project for Ethereum, I thought, oh, cool. And that was also before it became popular. So I didn't have any slide incentives, which maybe is good. But, then I thought, "hmm, but I think we really need political polycentrism, right? I don't want one world computer." I wanted like a network of sort of interoperable, kind of, overlapping computers. So for that reason, I went to work on IBC because that seemed like the thing most sort of relevant to this understanding of like the political philosophy of blockchains. And then joined the Cosmos project and worked on IBC. So I kind of took the intent idea and then said, "Hmm, but we need like different foundation" and went somewhere else.

(00:20:35):
Also, I think it's like, you know, I don't want to claim a special amount of foresight here. I don't think that I had a special amount of foresight. I was just reading some blog posts about coordination problems. And the word intent comes very naturally from natural language. You know, if you're getting lunch with some friends, you say your intents, like, I want to go to Mexican food or Thai food, I want to go to Thai food before 13 o'clock. Then you find some maps that satisfies all of those preferences. And most people would have no trouble describing, you know, they might not always use the word intent, but if you use the word intent, people would understand what you're talking about. Right. So I think there's kind of a, a natural correspondence here.

Anna Rose (00:21:15):
Yeah. Is there any intent-stuff in IBC or would you say you shelved that for that project and then kind of came back to it after?

Chris Goes (00:21:24):
Um, you know, it depends on whether some of the messages in IBC are kind of formally intents or not, depends on how exactly you define the term. And some of them might be, but they're, you know, if they're intents, they're not really user level intents. They're like protocol level intents, like subjects, these conditions update the state atomically on this other chain. Right? So yes, but not at the kind of holistic user-centered understanding of intents level.

Anna Rose (00:21:51):
I think it's probably a good moment to really define it and maybe define it as you define it today. I think you've just given us a really kind of nice human example of the Thai food lunch plans, but tell us your definition of intents today.

Chris Goes (00:22:06):
Right. So I wanna give two definitions here because I think they're actually, they're two slightly different. So another reason why I think intents has recently become popular and it's clearly not due to Anoma because we've been talking about it for a long time and it never became popular. So, I think credit for like intents becoming popular is much more due to kind of what you alluded to Tarun, but that it's this kind of unifying concept or universal concept, which is a great way to describe what many of these systems are doing that you can view from a lot of different angles, right? So the first definition of Intent I'll give here is the way that I think people use the word, like on Twitter, let's just say, like in the discourse, and I think there people use the word intents to refer to basically credible commitments to preferences over the stage of some system, right?

(00:22:59):
And what the system is, the kind of boundaries of the system vary. So someone might be talking about intents on Ethereum, then the system they're talking about is Ethereum. Someone might be talking about intents across all the Ethereum rollups, like maybe SUAVE is interested in this. Then the system they're talking about draws boundaries around all the Ethereum rollups, someone might be talking about intents, in Cosmos or like some Cosmos chains. And then the system they're talking about draws sort of bounds the system around these Cosmos chains, right? But in particular the first part of that definition, 'credible commitments to preferences', distinguishes intents from transactions in this useful way, right? So intents don't specify an exact path of execution, right? They specify some executions of a system or some future shades of a system. A user is, let's just say happy with or which a user authorizes.

(00:23:48):
That's what makes the commitments credible. And then how precisely what exact path the system takes, what exact computations the validators execute or, you know, including solvers and other parties to get from A to B, let's say, is not fully constrained by the Intent. Whereas in a sort of transaction-based system, kind of at the other extreme, a transaction fully constrains. It says start at A and do little step X, then little step Y then little step Z, sort of whatever you get to, that's what I authorize it in virtue of its having resulted from this path of execution, but an Intent instead authorizes this kind of end state directly.

Anna Rose (00:24:25):
Was that your first definition or was that both?

Chris Goes (00:24:27):
That was definition one. Yeah.

Anna Rose (00:24:29):
Okay. So what's definition two?

Chris Goes (00:24:32):
Definition two is kind of the version where you try and include privacy. Or try and reason about how information is flowing around the system. And this is kind of the definition Anoma uses, which is just a little bit different, that intents are credible commitments to information flow constraints. So in particular, intents, let's, let's take the example of like a zero knowledge swap. I think it's illustrative. So when you're doing some kind of zero knowledge swap with Taiga, and I suspect that other private swap projects, I don't know exactly how they work, but they're probably doing, they're also routing information in this way. What you're really doing is saying that I will give someone information or give their private key, which I know the public key for the ability to send these tokens, which I'm sending to them in the future, if I also get this other information, which allows me to send these tokens that I'm getting in the future, right?

(00:25:28):
So the thing which you're actually routing around the system is information which is related in a particular way, right? In this case it's related to some state on the blockchain, which is information that everyone can see that assuming everyone follows the protocol says that if we provide, a zero knowledge proof of such and such in the future that, you know, counts as spending the asset, right? But this definition probably sounds really abstract, and in a certain way it is, but it's also helpful in that it kind of unifies what we're doing with all of these little cryptographic components, right? There are many different cryptographic components in a system, like Anoma or Ethereum, sort of public key cryptography, digital signatures or zero knowledge proofs, sometimes fancier stuff, verifiable encryption, hypomorphic encryption. And if we think of from the perspective of like the system designer, and in particular from the perspective of the user, what these cryptographic components are doing, from the perspective of the user, these cryptographic components are allowing them to specify how information gets routed around the system, right? And you could have a transaction centric view of that where you say, route information in exactly this way, and exactly these steps in a more intents centric view steps back and says, okay, here the ways in which you could route information that I am happy with, that I authorize. Right?

Tarun Chitra (00:26:47):
I guess, you know, one question I have about these things in general is somehow, and, and maybe this is my myopic view, but somehow these definitions never include any notion of efficiency and I think like somehow that seems fundamental to how well they're usable by end users. Like, there's sort of a couple high level things, right? There's like, how efficiently can these paths be found or taken? And then when you talk about some notion of credibility in some sense, to me, credibility at least from the sort of like economic lens sort of means, hey, like the user doesn't really have to do a lot of work or a lot of communication to figure out that the person who's doing the task or the group that's doing the task didn't fuck them.

(00:27:44):
I think that's like kind of the, that that's my colloquial definition, right? Like, you don't have to do much work to know you didn't get fucked, right? So maybe a little too blunt of a definition, but somehow there's like three components here, right? There's like privacy, there's efficiency, and then there's how fucked are you? How easy is it to tell if I got fucked, right? Like whatever that is. And somehow those three things are this like triangle that you're kind of choosing your where you are. And like that's where I find it hard to come up with one definition personally, if that makes sense. Like there is some like balancing of this like table of those three things. It feels like, I don't know do you think I'm missing anything in there? Because like, at least that's always been my conception, is that those three things are like the fundamental things you're getting at

Chris Goes (00:28:32):
Right, no, I mean, I think you're absolutely right. That intent at, at this level of abstraction doesn't talk about efficiency. I think that results from that intent is a way, at least as we use it as a way of describing what's happening in a system that is dependent only on properties which the user can ultimately verify, right? Or is not so concerned with how things get computed, but rather is concerned with what could be verified at the end. And that things can be efficiently computed is very important, right? It's critical to a system actually working. But I think it is, you can describe a system, sort of the topology of a system and the properties which interfaces must satisfy in a kind of simpler and just more easily universal way if you leave how things get computed as a separate choice, right? So not that intents wouldn't say that an 'intent-centric' design wouldn't make your system more efficient or less efficient necessarily. It's just sort of orthogonal to the question of efficiency.

Tarun Chitra (00:29:42):
Yeah. I get that there is a way of of defining it separately, but it does feel like in practice it does quite matter and, you know part of the examples of this are like the intents that people talk about those existing in practice are like CoW Swap or RFQ's or kind of like 0x or Wyvern and those just have a very particular notion of efficiency. There's sort of a sense of which efficiency is built into their mapping. You have to prove to the user some guarantees on price or some guarantees on like routing quality, right? And their efficiency is seems to be like quite explicit. So I guess my question is, you know, you're talking about definition that doesn't include it what's like the boundary, right? It feels like it's like a computational complexity boundary of like, some things can be intents, but like never verifiably efficient intents or something and like how do you think about designing a system when your users are sort of not omniscient and unfortunately have to run simple algorithms?

Chris Goes (00:30:51):
Right. No, I mean that then I think, I think it definitely makes sense to restrict the space of like intents that you actually encourage users to author and try to execute to ones for which there are sort of computational bounds on the solving algorithms, right? And something like Uniswap or CoW Swap or OpenSea all have like nicely boundable complexities-solver algorithms. Maybe a kind of interesting alternative lens to this question that I think is helpful is thinking about when we could come up with a, you know, in principle you can make an intents system that is like a sort of interesting way to farm out NP solving problems to like a market, right? And I think that probably does have some applications.

Tarun Chitra (00:31:40):
That was the original CoW Swap, which never took off. Like whatever Gnosis called the DEX, Gnosis DEX in 2019 or 2020 where they had this NP-hard problem, but they're like, we'll take any solution that verifies. And so in theory and it was just like matching these pools of different tokens, but it like completely was too complicated. And by that time Uniswap and like the simpler complexity things beat the more complex things, but they were effectively farming out this like mixed integer linear program and being like, "Hey, find a solution, or you find any solution up to some constraints, we'll execute it and you win." So I guess like there's sort of...this is where I find trouble reasoning about these systems from all the different aspects that people have.

(00:32:34):
Because in some, the very concrete ones, the efficiency thing seems important, when you gave this talk at research day in New York, like last, was that last month or two months ago, something like that, last month, maybe. You gave a lot of examples of like more general intents, right? Like writing a programming language for, for these. So like how, I guess, like how do you think about that? Like how do you think about the structure of like a language for describing this? And maybe this goes into to like the philosophy of how you should write languages?

Chris Goes (00:33:07):
Yeah. I guess to be clear, I guess I just, as a protocol designer, I work really hard to be lazy, right? Like, I want the minimum number of abstractions to kind of talk about how different parts of the system relates to each other. And at least I find, in kind of conceptualizing what's going on, efficiency to be separable, as in practice you want to use systems where you can reason about efficiency, but the relationships of the interfaces that allow you to compose a system, like let's say you have a zero knowledge proof scheme, right? And different zero knowledge proof schemes have different specific efficiency parameters, but they all provide the same abstract interface modulo sum. You know, important but mostly abstractable, or cryptographic assumptions, right? They all provide you a way to take a statement and make a proof about it, that a third party verifier can verify non-interactively, usually non-interactively, that attest to the truth of the statement or that, you know, some data as satisfying it.

(00:34:07):
So I think it's possible to like describe how you would fit a zero knowledge proof scheme into some larger system, and then separately calculate the efficiency of using the whole composite system with different zero knowledge proof schemes, right? So for just from the design perspective, it's helpful to separate these parameters. I think if you do it well, it can allow you to reason more cleanly about efficiency because you can view efficiency as a function of the kind of a composition of the different costs of all of your different specific primitives, right? So you have kind of some system design that uses a zero knowledge proof scheme, and you can reason about, okay, well, given a zero knowledge proof scheme with proof size X and prover cost Y and verifier cost Z, you can say the whole efficiency properties of this system are a function of X, Y, and Z, right?

(00:34:59):
And then you sort of pull that out, right? That would at least be sort of my argument for why this kind of frame could make reasoning about efficiency, a little bit like easier just because it separates out these components. In terms of languages, I think primarily are what we've been spending time on is thinking about what the key, you could call it VM or like what the key black box abstraction that an intent-centered system tries to provide is, right? So something like Ethereum was originally designed to provide a world computer and they modeled, or at least that's what used to be on the website and they modeled the EVM after these old Von Neumann machines, which take some instructions and take a stack, they have some memory and kind of run through the instructions and sequence, right?

(00:35:54):
So users send transactions which give sequences of instructions, and those are executed. And the central, you know, replicated abstraction that's being provided here is this sort of instruction executing machine, right? So what we've been trying to think about is what instead would it take to make an intent-executing machine? And the one thing which sort of changes from a transaction-centric world to an intent-centric world is that in an intent-centric world, you have multiple intents, which you want to match and settle atomically, and you want to take the system from some initial state to some final state where all of the intents involved in that is what we call a transaction, right? All, all of the intents involved in that transition, have their conditions satisfied. So it's a different black box, right? As opposed to like the atomic unit is executed instruction, executed instruction, executed instruction.

(00:36:43):
The atomic unit for us is take a lot of intents and try and match them in some way. And then there's a very like, non-trivial problem of how do you know, choose because now you have multiple possible paths of execution, right? There are many different at least potentially many different final output states, which might satisfy all of the involved attempts. So now you have this very non-trivial problem of how do you pick, which I'm going to leave for later, but for now, just talk about this black box. So our, I'm not sure, I think originally, like we thought that that might be a languages question, and we did a lot of language research and we have some interesting languages which do nice things like abstract zero knowledge proof schemes, that one's called Vampire, but I'm not really in the end, I think I'm, it's maybe not a language question, it's more like a VM design question or like, what is your atomic unit of state transition?

Anna Rose (00:37:35):
I'm kind of curious, like, as you describe this, how if you had multiple parts of this kind of intent put forward, are you talking like the end user would basically say, I want this for either this or this, or maybe I want this instead for this, and like, is that sort of what you mean? It's like this desire and how much they wanna pay and what they wanna do with it, and like, maybe can you give a little bit more color to what that UX might look like?

Chris Goes (00:38:02):
Right. I mean, it could look like that, it could look like something like a, let's, let's take the example of real world things because I think it'll be a little bit clearer. So if I want to purchase a festival ticket and a hotel ticket and a train ticket all at the same time, I want atomicity for that transaction, but I might have some flexibility for, let's say the dates. So I want the cheapest set of tickets to go to the festival, the festival's running next weekend and the weekend after. So two possible weekends. I want train tickets from Berlin to Munich, for three people I want to be sitting next to my friends, right? So I have some preferences over the state space here, but I don't, you know, I'm willing to go either weekend. I just want the best price.

Anna Rose (00:38:48):
This festival is in Munich

Chris Goes (00:38:49):
Yeah. That was the, that was the city I came up with, sorry, Munich must have some festivals.

Anna Rose (00:38:55):
I feel like you'd be coming up to Berlin, right?

Chris Goes (00:38:57):
Right. So in that example, right, in that example of these specific real world, these would be non-fungible tokens or something like this. Yes, the user would use them kind of interface that describes what configuration of things they want. And if you go to like online ticket sellers or something like that, I mean, they typically have some perhaps slightly simplified version of this, right? You can search through things based on constraints. You can select your maximum price, you can select which states you're willing to fly, and it will, you know, Google Flights is a very intent-based flight search engine, right? It's doing a lot of pathfinding for you. So I think that many things, many applications in the real world already try and do a lot of the work of interpreting a user's intent for them and searching over the state space of available flights, available, hotels, available...

(00:39:48):
You could even have something like available stock trades, on the basis of what the user said their intent was. So that's the kind of like real world application example. I mean, also, and perhaps to Tarun's point, there are many kinds of intents for which you want very specific efficiency or fairness guarantees like you want to guarantee of optimal execution over some batch of intents or like fair pricing over some batch of intents. And there your intent is going to include that constraint. So it's going to say that like, I am happy with the output price I get as long as the output price is calculated in this way. Where this way is like, take all the intents in dispatch, which was maybe previously committed, and then threshold decrypted and calculate the output price at the best price, or let solvers within some period submit solutions and rank them by whatever your price optimality criterian is.

(00:40:42):
So intents will include often properties that they want to be true about the path of execution, right? And that might be a way in which you can get specific kinds of efficiency or fairness guarantees. I think that's particularly important when dealing with fungible assets. Let's say a lot of the things people use, you know, Uniswap or CoW Swap to do today and might be, you know, for tickets or something like train tickets, hotel tickets. These things are a little, it's, it's harder to define what a kind of fair price would be. And maybe also a little bit less important because there's less, there is MEV scalping, I don't know, they're weird things, but there's less immediate concern for like exact best price execution in some batch.

Anna Rose (00:41:28):
I wanna just go back. So we've mentioned sort of CoW Swap a few times and like when I started learning about this concept, CoW Swap was floated as like, if you wanna know how an intents system kind of works, CoW Swap sort of does that, but what is different from what they are doing and what you are proposing? Like, is there some sort of like central actor in their system? Is it, because it's including ZKP's that it becomes more interesting? Yeah. I'm just curious how you'd differentiate your new ideas about intents from what that is.

Chris Goes (00:41:59):
So Anoma really just aims to kind of like generalize and protocolize the architectural problems faced by intent-centric applications. So CoW Swap is already an intent-centric application. They have users sign intents, they submit them to some kind of aggregator. As far as I understand, the last version of the system, someone explained to me. So it could have changed, but the last version I understood, someone, users submit their intents to an aggregator. The aggregator takes a batch of intents, then solvers compete to submit solutions for that batch, right? So CoW Swap has built all of this extra infrastructure. They've built this aggregator, they've built this intent language, they've built this kind of way to rank solutions from solvers. People have built solvers, and Anoma really just tries to like build protocols that can handle many of those things without special-cased intent systems for each application.

(00:42:54):
So CoW Swap has their own like RPC API and own network for submitting intents, and CoW Swap intents are CoW Swap specific. They're not composable with intents of other applications, at least not easily. Because they're kind of being handled by this separate network and sort of off-chain execution selection system. Anoma tries to make things composable at the intent layer, right? So you could have intents for one application and intents from another application and maybe in some cases they might not even be solvable unless you compose the applications, right? Let's suppose that I want to buy a ticket that I want to pay in some different currency other than what the ticket seller wants to accept, right? Then I might want to compose intents from the ticket application and from the like currency trading application, so that I can get this compose thing, which together matches and satisfies everybody's preferences.

(00:43:43):
But without application, without intent-level composition of applications here, you would just have two, you know, two separate interactions. At the very least, you couldn't make them atomic. Primarily what we're aiming to do is solve the general problems once and turn them into protocols so that people who want to build applications like how CoW Swap or like OpenSea can do so without reinventing the wheel on intent-based architecture, without building their own networks of solvers, without building their own Gossip systems for intents, without building their own intent languages, especially if they want privacy. That's kind of a big lift in terms of cryptography required. So we want to standardize and abstract those components of intent-centered applications just so that they're easier for people to write and can compose.

Tarun Chitra (00:44:25):
Yeah. The only thing I wanted to kind of ask / add is in some sense all of that sounds great, but the thing that still is hard for me to deal with is like, there's so many just like difficulty or impossibility results for these types of aggregation problems and like, I just like really actually understanding like how you think about things where someone writes some intents system, but like they create a bunch of intents whose aggregation is basically like too hard to solve. Like how do you deal with some of these like problems where like the developers can shoot themselves in the foot because you can easily do that with the very tiny changes. So I'm just kind of Yeah. Like how are you thinking about that?

Chris Goes (00:45:06):
Right. I mean, I think that we want to still give people freedom, or at least like, we don't want the architecture to necessarily constrain all these things. What becomes feasible to solve will also change in time. But we want, you know, we're trying to build say a language for intents that has very clear termination properties has computational complexity that you can reason about stuff like this. So you should be able to check whether or not solving a particular kind of attempt is feasible. That's not, you know, nothing in the architecture can exactly prevent developers from shooting themselves in the foot. I mean, I think it's a different...like the pistol is different, right? In Ethereum it's easy to shoot yourself in the foot by assuming that you have this like, control over ordering that you really kind of don't.

(00:45:56):
Right? And that's, we see the sort of non-MEV aware applications, at least implicitly seem to be making the assumption that like, people will submit transactions and that's the only thing that's happening. And like, there aren't other actors who can influence the ordering of events in the system. Unfortunately there are. I think the pistol is different and primarily we want to have a language that makes it easy to express these kinds of simple properties. But also just let you know, let a market of applications figure it out over time. They're not going to like break any of the impossibility results. But I also think experimentation is good.

Tarun Chitra (00:46:31):
The interpretation of this is it's the second amendment of programming. Like you have the right to bear arms, including against yourself.

Chris Goes (00:46:39):
I mean, I do think that there also is the reason especially that I hesitate to say that like you shouldn't do this, is that I think sometimes you might want to, like, it could actually be you could make a bounty, for example, for computing some kind of solution, which is, doesn't violate in the possibility result, but it's just presumed to be very difficult to compute or something like this. Or you can create different kinds of incentives for people to discover certain ways of solving, certain subclasses, of NP problems more efficiently. So I think that there could be also applications in that area.

Anna Rose (00:47:15):
Chris, I have a question about the sort of ZKP's in the system that you've created. Like are the zero knowledge proofs here just like a way to make a lot of this private, or are they kind of key to constructing the thing? What kind of parts of the ZK are you using basically?

Chris Goes (00:47:32):
Yeah. In the way we use zero knowledge proofs in Anoma, they certainly do provide privacy. We've also tried to align them with just the separation of computation from verification so that, you know, whether you get privacy is kind of a choice of whether the proof is zero knowledge and whether you get like succinct compression is a choice of whether the proof is is succinct, right? So you can kind of separate out these properties in the architecture as they result differently from different properties in the proof scheme. We also care specifically about zero knowledge proofs because we've taken this, nullifier commitment to nullifier scheme originally introduced by Zerocash and built what we think is an interesting approach to private bridging. In particular, we can use commitments and nullifiers to do a kind of global double spend detection. Which is something that IBC doesn't try to do.

(00:48:27):
So we investigated for a while building private bridges on top of IBC, and that turns out to be very difficult because when IBC sends tokens from one blockchain to another or sends state from one blockchain to another because it can't reason about the correctness of the state transitions, which took place in the other chain, it has to do a kind of supply check at the boundary. So if I'm chain A and you're chain B and I send you 5 tokens and you send me 6 tokens back, I'll say, wait, no, you can't send me 6 tokens back because I only sent you 5 tokens in the first place. That's great, but it requires that you can count the tokens, right? This violates privacy or privacy is sort of incompatible with this counting method.

Tarun Chitra (00:49:05):
I like to think of this as the border checkpoint of blockchains where like your privacy is always goes to zero whenever you leave a nation national border.

Anna Rose (00:49:14):
In the example you just gave though, would, like, if you're going cross-chain, would both chains need to be built in the way that you're building it? Are you picturing kind of like two Anomas or two Namadas or something like two instances of your system communicating?

Chris Goes (00:49:28):
Yes, or at least part of it, at least the kind of, at least what we call Taiga, which is like the privacy preserving virtual machine. So we do intend for this to be kind of available as a separate component. So you could run Taiga as an Ethereum rollup, for example. You could run it in part of a different security zone or as part of a different system and still take advantage of this private bridging function.

Anna Rose (00:49:53):
Is there a way to implement some of this into, like, thinking of the IBC model of like putting, I mean, I don't know what you call it actually, but like the IBC like line or some IBC module on a chain that isn't Cosmos-native. Would you be able to do something like that for Anoma chains where you'd, or intent-centric chains where you'd basically be able to put some module or some like Yeah. Something on the other chain that can then, like start talking to it?

Chris Goes (00:50:20):
Yeah, that's the idea. I mean, the restriction in, at least the way we have designed private bridging in this system is that you can only get private bridging between different instances of the VM. You know, in our case, Taiga, you could do something slightly different, which accomplishes the same goal, which understand each other's, state system enough to reason about commitments and nullifiers. So the idea with commitments nullifiers is that you represent your state in these Zerocash calls, them notes, but in these atomic units and that these atomic units are consumed only once when you consume them, you reveal the nullifier. So how we plan to implement private bridging in Anoma involves merging nullifier sets. So when you say send a transaction from A to B, you do some stuff on B, then you merge the history back into A, we can avoid this intermediate border control sort of transparent balance check because we can check that, we can check the full history, privately, but we can check through the zero knowledge proof, the full history of all of those tokens back from all the way when they came from A, and we can check that there are no double spends in that history or are no violations of linearity and that it requires standardization of more than what IBC standardizes, right?

(00:51:36):
It requires standardization of this privacy preserving VM layer. Uh, you know, on top of that, I mean Taiga is, is kind of, relatively agnostic to like the languages in which you write or something. You just need to be able to compile them to circuits. So on top of that, you could have other VM's or other things going on, but you do need to deal with your state in this way, if that makes sense.

Anna Rose (00:51:56):
Continuing on that topic of privacy, I actually I had a question from before. I think this, like you were speaking about something earlier about kind of hinting at a, at a DEX or a ZK swap. I think when you were talking about that, I started to think, you know like two years ago, Tarun, Guillermo, you guys did a bunch of work and I think Alex did a bunch of work around these private DEX's and some of the challenges when you get into these intent-based systems, is it a completely new landscape where we can start to really think about private swaps in a different way? Or are those problems that you had highlighted, and this is also to you Tarun a little bit, but like, do they still stand in a system like this? The fact that you'd often have to reveal something in order for like a proper marketplace, or at least in the way that we've thought about it in the past?

Chris Goes (00:52:43):
Yeah. I'm not extensively familiar with that specific paper, but I think in general, intents are a way of designing an architecture and a way of designing, in our case the virtual machine. They don't break any possibility results or whatever. You need, someone needs to see enough information to combine the intents, right? So that someone could be like someone inside an SGX, right? Or it could be someone inside FHE, although I still think we're many years away from that, but some, you know, logical party needs to be able to see the intents and see at least the information about what the users want to trade so that they want to trade A for B and B for A in order to match them.

Tarun Chitra (00:53:28):
Yeah, I don't, I don't think this changes any of that. In some sense, this gets more complicated because it's like non-atomic, so like you're in fact more likely to have these privacy problems. I think the key thing that people have accepted is that any financial transaction fundamentally has to have some public data, like a price and interest rate a fee and some private data if it at least like what people expect normally right? Like people aren't expecting to always be showing that they're making some transaction and the public data always has some information about the private data and the key is just like allowing the user to choose how much they make public and then they get a price based on how much they get they give publicly, right? Because like obviously if they gave all of their information you could get the best possible price, but in reality it's kind of it's like the user should be able to decide their trade-off between privacy and efficiency. This is again why I brought up the efficiency thing earlier. There's, there's sort of like, I feel like it is, kind of fundamental to this type of stuff, but I agree. It's like it's not clear how to do it in a way that doesn't just like tell people don't make any applications.

Chris Goes (00:54:43):
Right. Well I would also, I think there's like, there's privacy and efficiency and security, which is another tricky, like in these cross-domain systems where you might have different security assumptions, you also have to trade that sometimes against efficiency, right? Cause you have to agree typically to a set of security assumptions in order to get that efficiency. So yeah, we don't try to answer those questions in the architecture. We try and like maybe at least make it clear what the trade-offs are and let users, perhaps with the help of developers pick from them. You know I think the privacy efficiency access is also interesting because, there's some things that you can kind of get for free. You can hide your user account without losing any of the properties you might want.

(00:55:31):
But you can't hide, you have to reveal what it is that you have and what it is that you want in the intent lingo in order for someone to match that. And then the more you know, if you have some kind of distributed dark pool of solvers, let's think of it like that. You have a bunch of people with private liquidity who don't post it to a central place, then it is just, it's very hard to reason about what kinds of fairness guarantees you can get. Right? On the other hand, it seems like many parts of real world systems might be working like this. So I think it might be, it's an interesting problem to characterize.

Anna Rose (00:56:10):
I kind of wanna redefine efficiency here too, 'cause are you talking about... is this very specific to DEX efficiency? Is this market efficiency?

Tarun Chitra (00:56:22):
Yeah, I mean there's two types of efficiency, right? One is just strictly price efficiency that's more like clearing price. Also very hard to define. You can actually in some cases show there doesn't exist any market clearing prices depending on how the market's structured. So, but there's also just some notion of like, does there exist an equilibrium, a) such that you maximize people's batching and, and execution. And even if there does exist one, can you find it quickly or can anyone find it quickly? And those are like three different, you know, if you made the meme of, you know the person and then the person with the brain, that's in that order, right? Like price efficiency is kind of the easiest one, but it's obviously missing a lot of the clearing aspects. But then yea, equilibrium finding equilibrium existence is easier than equilibrium finding. That's the hardest part. Actually, Chris's talk in New York had this example of this like fixed point iteration finding intent and that's exactly the type of thing that like you might not be able to find the equilibrium for depending on...that's why I thought it was a good example though of like, it is one of these ones that like might just be impossible, right?

Chris Goes (00:57:35):
Yeah. I mean, one reason I like the concept, personally, although I promise after this episode I'll shut up about it, is that it illuminates a little bit like the boundaries of what the systems can actually do. So I think Sam, a friend of mine, Sam Hart had this great tweet where he's like, the thing about intents systems is that you assume that users know what they want, right? Like, you know, maybe users sometimes don't know exactly what they want. And I think that that's probably true. But it also, maybe it provides a helpful way to understand, any kind of like distributed blockchain system can conceivably do, right? If you as a user don't know what you want, but you commit to some specific preference anyways, then you're definitely going to get something that you know wasn't what you wanted because you didn't even say what you wanted in the first place. So I think that illuminating the boundary can be helpful to illustrate what these systems just can't do.

Anna Rose (00:58:30):
I have like a weird idea here, which I don't know if it would fit at all, but as you describe this, I start to think, could we somehow in a system like this almost have like recommendations pop up where you like, or like could you add into an intents system things that people haven't actually asked for, they've left sort of an open blank space that you could then like inject something into?

Tarun Chitra (00:58:54):
So an interesting like IRL example of this is like if you think of like food delivery apps often times they'll send you notifications to be like, "Hey, we'll give you a 10% discount if you buy from this restaurant right now" because someone is already ordering in the same region or building or whatever. And that actually turns the constraint problem in into like a better problem sometimes. Like, cuz it like makes your their revenue go up even though like, but like their costs down on a per unit basis, right? Because like their costs per unit are a lot lower, 'cause I went to the same building, right? But the revenue went up like x%. And so a lot of the optimization and marketplace design for like these peer-to-peer gig economy stuff is like exactly doing this Google Flights is also exactly doing this.

Chris Goes (00:59:44):
Yeah. I just wanted to mention that I actually think a lot of the real world application examples of intent-based systems are going to be a little bit more interactive than blockchains are right now. I mean something like trade token X for token Y and maybe get this specific efficiency guarantee can be made non-interactive because the preferences are like sufficiently exact, but often in say, Airbnb, decentralized Airbnb, decentralized Uber, things like this, you kind of want a round of interactivity because you can't, you want to like see the exact details of the thing before you confirm. So for example, when I book an Airbnb, you could make a non-interactive Airbnb where you just specify, I want to go to this city for these dates. I want a place that has like these characteristics. Find me one and book it. Don't ask me for any more confirmation.

(01:00:36):
And Airbnb doesn't do that, right? And I think the reason is that people typically have these like sort of approximate preferences and then they want to look at the actual options. They want to look at the pictures of the place and see, oh, it looks nice, or oh, that looks like the room's too small, stuff like this. And I think that not, with kind of tokens or, very like clean, abstract, objects on blockchains where you don't, where you know the things are fungible or you don't really care about the specific properties. You don't need this kind of interactivity. But with trips in an Uber where you wanna see how long the ride is as a driver before you confirm or with Airbnb's where you wanna see like the exact details of the place. I suspect that you'll have like multiple rounds of interaction built into the system.

Tarun Chitra (01:01:23):
Yeah, I mean another way of thinking about it is, if you think of it more as like a two-sided iterative game of like, I place an intent that causes someone to have to try to service it, which causes me to change my intent. It's like, "hey, I want to go on a trip to Europe." And then the reply you get is, "here are the five places that are cheapest from your city." And then you're like, okay, I'm gonna choose this subset. Okay. And then they're like, okay, here's the path, you know, here's your itinerary, right? And like you have this thing where like the user gives some very coarse thing. The searcher gives something finer the user and, but it's sort of a way of making in theory at least MEV work for the user rather than against the user, right? And, and in some sense that's like, does seem to be the long-term vision, you know, I maybe as a curmudgeonly theory lover, just like always like I look at the formulations of these things, I'm like, ah, everything is like impossible. So it's sort of like one of the...But you know, I definitely get the idea like, it, it clearly, it clearly is a thing people would like, right? They don't want to think about swapping, they don't want to think about like signing 500 OpenSea transactions.

Chris Goes (01:02:35):
Right, right. Well no, I think people should be very skeptical of intent systems and sometimes yeah, I see comments where I think people, maybe people take intents to be to be magical or something like this. Like I'll just say like, give me more money and the system will do it right? And you know, that's not going to happen.

Tarun Chitra (01:02:57):
The ones where people are like, "oh, I'll just like ask it to make me money in the stock book." I'm like, I don't think... it's like there is clearly some... it needs to be... this is why I said you have to, you know... efficiency has to include ability to find an equilibrium, not just exist in equilibrium like that's kind of like the holy grail.

Anna Rose (01:03:14):
Tarun, you just said something about like MEV and like I don't think we've really talked about is there like do intents and MEV have any sort of crossover?

Tarun Chitra (01:03:22):
Yeah, so, so I mean like one simple way of viewing it right is like MEV as user says a very precise transaction. Then the MEV searcher is like, "hey, I'm going to like optimize that and optimize my profit." Now imagine if there was something where the user said, "hey, here's my transaction. You can service it, but only up to some threshold," right? An argument is like in Uniswap the slippage limits are like that, right? If I slip the perfect slippage limit, the searcher can't really sandwich attack me or do much. But because I can't figure out what the optimal search slippage limit is, someone can kind of front run me. Now in a world where you can have these verifiable commitments, you could say like, "hey, if you're going to use my transaction, you have to prove to the blockchain that you didn't make the slippage more than X."

Anna Rose (01:04:11):
Oh,

Tarun Chitra (01:04:12):
Right. It's not just, it's not just like, hey, I said it, it's like anything action you do to include my transaction has some covenants or constraints on it.

Anna Rose (01:04:20):
But was that like described in the intent itself?

Tarun Chitra (01:04:23):
That is sort of the intent. Like I don't want lose more than like X dollars, right? Or like, I don't want to be more than X dollars off the previous price in the block, right? Like, and that's sort of this approximate thing. It's not exactly saying the transaction but saying some rough version of it because it relies on the other party sort of these, the searchers kind of like optimizing that over all the order flow. And so the idea is you're encouraging people, said strictly profit to profit under some constraints, right? Like you're fine with them making some profit provided they meet your constraints and hopefully there's enough volume and aggregation effect that they can actually do that. Chris, am I missing anything? It in my mind it just like MEV working for you, like instead of the other way,

Chris Goes (01:05:11):
Right? I think that's exactly right. I mean you can, another way to think about maybe is that there's a spectrum from being kind of very loose about what constraints you impose upon operators, solvers, validators, the other parties processing the intent to very specific. And you can be specific about different things. Like one way of understanding an Ethereum transaction is that it's an intent that says that it must be globally ordered with respect to all the other transactions in a block. So in a sense it's actually too specific like you're paying for this property global ordering, then most of the time you probably don't care about, right? Like most, you know, if you're doing a trade, you don't care about ordering with respect maybe to other assets, if you're doing a purchase of an NFT, like you don't care about ordering with respect to someone else who purchased a different NFT.

(01:06:00):
But the way you know, understanding a transaction is a special case of an intent. The property that this transaction is enforcing and that you're just like paying very dearly to have en enforced for you is this global ordering. So in that case you maybe want to be less specific, like you actually don't care about some of those orderings, but you might want to be more specific about what kinds of, you know, slippage bounds, anyone who includes and builds upon matches your intent has to respect or how your intent is processed with respect to other intents and a match, stuff like this. So just kind of getting to more precise specifications for if we think like there's some kind of delegated agency going on, right? As a user you have an intent and you want the operators doing things in the system, validating, solving, relaying messages on the peer-to-peer network, etcetera. You want them to do things which kind of like respect your intent and you can use, various kinds of commitment devices to kind of bind them to doing that in different ways.

Anna Rose (01:06:59):
I actually have one last question, which is about sort of the state of intents architectures. And like I obviously I think we can talk specifically about yours, but like, is it a finished idea? Is it mapped out through and through or do you feel like this is still, like parts of it are understood and you've built those parts, but there's gonna be, you're gonna kind of need some sort of like market testing to figure out how to do the other parts? Or is it a complete architecture?

Chris Goes (01:07:27):
Yeah, I mean I think there are parts that are sort of clearly generalizable and protocolizable and parts that are more application specific. So the Gossip network and consensus and private state transition stuff like this, you can do in a general way at least specific to like certain classes of applications. You know, applications using single user private state or multi-user private state in different ways just require specific configurations of cryptographic primitives regardless of what the exact computations they're performing are. But then, also to Tarun's point, different solvers, especially solvers where you want to or classes of intents where you want to reason about concrete efficiency of the solving algorithms require different specific solvers there. You can't, I mean you can try and, you know, the general version of this is something like Z3 or whatever, but it's not going to be particularly efficient for many of the cases that you might care about. So that will require some more market discovery and testing. I mean, I think, I think a fair amount of this, you could understand this already existing and like Ethereum MEV solvers which have gotten to do pretty sort of general and impressive things. Flash loans, like doing a bunch of state space execution, searching, CoW Swap solvers, stuff like that. So many of those techniques I think will kind of port over already or so to speak.

Anna Rose (01:08:50):
Interesting. Do you think it'll be the Heliax team building this or do you actually see this being more of a community effort?

Chris Goes (01:08:57):
I really see this as being a community effort. I don't think that we could build all of the solvers or applications and we certainly don't want to. You know we also want to make things interoperable with Ethereum and Cosmos. Assets and existing change in validator sets as much as possible.

Tarun Chitra (01:09:17):
Yeah. So I mean, you know, let's say it's been, I don't know how many years since Wyvern 2018, five years or, or was it 2019?

Chris Goes (01:09:24):
Five years. Five years it is.

Tarun Chitra (01:09:25):
Right. Okay. Five years since it came out, you know, now there's kind of in 2023 been this flurry of like, it became a meme. People were like starting companies and projects based on the name. How does it feel, you know, personally it to be kind of in the limelight from this obviously limelight in a very tiny demographic of people who pay attention to this, don't get me wrong. But it's still in the limelight. Does it feel like sort of imitation is the best form of flattery? Like do you feel like it's cool that people are finally like realizing this? Cause I feel like it wasn't very popular last year. I think like in the world where people were like, oh, we're just gonna have like... the people were losing faith I guess in like the app chain / rollup because those two theses basically the same nowadays. People were like way more in the like monolithic world, I would say last year and then it kind of flipped and when it flipped people like, oh shit, we need this. So yeah, like how do you feel like kind of about that and kind of the increase in interest in this?

Chris Goes (01:10:32):
That's a good question. I just feel like I'm now under a lot of pressure, like really good pressure from people such as you Tarun to write down some math so that my like declarations about intents don't seem quite so philosophical and could be concretely falsified. So that part is nice. I mean I think maybe an interesting question for me is I think people sometimes view like what the blockchain space is doing in different ways. I think some people view the blockchain space as kind of like startup land where you sort of experiment with a lot of different ideas and you know, what works is kind of a complex function of market conditions and how things are explained and there's not like any clear convergence, right? But I think personally I understand the ecosystem is more of like a distributed research field, it's not quite so unified it's like subfields and academia and it's more oriented around synthesis of like many things which already exist.

(01:11:34):
But I think it's very cool that, you know, I come at intents from this like 'thinking about language and philosophy and coordination problems' angle not from the like bottom up MEV angle, but the bottom up MEV angle sort of reflecting on these actual protocols which are already deployed in the world seems to point to the same general direction. So for me it's a very cool convergence of these two ways of approaching like the design questions and blockchain systems, the sort of like what are coordination systems doing perspective and this like, well how do these actual systems evolve according to how user users actually use them perspective. Kind of seem to point towards the same at least like many different angles to a similar concept, and I think that that's cool.

(01:12:20):
I mean I think it's helpful to Uma from Succinct put it, I think at research day intents have gotten people who think about user experience and people who think about like abstract system architecture problems to talk to each other. And that these two people weren't previously, like these groups of people weren't talking to each other. And I think that kind of unification of different aspects of the discourse, realizing that they were kind of viewing the same problem through different lenses and maybe they can now collaborate, is really cool and could lead some good outcomes for users.

Anna Rose (01:12:53):
Nice. Chris, thank you so much for coming on the show and sharing with us your sort of the history of intents.

Tarun Chitra (01:13:01):
You mean his 'intents-ity'

Anna Rose (01:13:02):
His intensity about intents. But yeah, no, thanks so much for sharing with us and like this is very helpful to give context to these ideas because I mean, I've known about the Anoma project since the its inception, but this idea of intents, even though I think we've even had it in ads on the show, I wasn't always clear on like where this is coming from or what exactly you mean by that. And this has been really helpful to understand that.

Chris Goes (01:13:29):
Thank you. I hope it was interesting. And yeah, Tarun, speaking here Anoma, we definitely owe you like some good mathematical characterizations of some of these problems. So hopefully hoping that we can provide those and answer some of the very good questions around like, what are the bounds for different efficiency classes of intent-centric applications. I think that's a good one.

Tarun Chitra (01:13:54):
Yeah, for sure. I think I still think it is the right mental model though, because I think it, it does get at this, all the marketplaces that exist, that people have apps for, like do kind of do this, right? You're never really saying like a precise thing. It, you just get matched to something. And I think like inevitably that any way of describing that makes sense. It's just more a question of yeah. Like, yeah, what, what, what does this look like in 10 years? And it does feel like there is some like actual new research to come out of that. So looking forward to it.

Anna Rose (01:14:28):
Cool. All right. Thanks again. Thank you. And I wanna say thank you to the podcast team Rachel, Henrik, Tanya and Jonas who edited this episode. And to our listeners, thanks for listening.