Anna Rose (00:00:05):


Welcome to Zero Knowledge. I'm your host, Anna Rose. In this podcast, we will be exploring the latest in zero knowledge research and the decentralized web, as well as new paradigms that promise to change the way we interact and transact online.


(00:00:26): 


This week, Tarun and I chat with Sunny and Dev all about Osmosis. Osmosis is a Cosmos zone/DEX that uses IBC to allow enabled assets to be traded, pooled and staked. We talk about their journey to Osmosis, what this means for the Cosmos Hub and how they aim to provide an MEV solution that differs from the one proposed by the Flashbots team.


(00:00:48):


Wanted to quickly highlight that the ZKValidator, the project running validators on some key L1 PoS networks, is also now running on Osmosis. I didn't get a chance to mention this at the time of recording as we hadn't yet confirmed that we were going ahead with it. But I did want to let you know now that the ZKValidator is live on Osmosis. We are powered by our new staking partner, Chorus One. And so if you're thinking of staking your OSMO, you can find us in the Osmosis staking interface.


Anna Rose (00:01:18):


Now I want to thank this week's sponsor, Least Authority. Least Authority is a leader in the security of distributed systems. They provide security consulting services, develop open source products and contribute to the advancement of learning and research in the field. In addition to their recent security reviews of innovative projects, such as Chia Network, Mina and Bender Labs' Wrap Protocol, they will soon be releasing a whitepaper on ZKAPs, or Zero-Knowledge Access Passes. ZKAPs is an anonymous token.-based authorization protocol that facilitates an online exchange of value, while disconnecting the necessary payment data from the day-to-day usage service data of customers. They have adapted the Privacy Pass design and implemented this for something called PrivateStorage, a soon to be launched cloud storage service designed with privacy and security features to give you control over who has access to your data. If you'd like to be notified of the ZKAPs whitepaper and the latest security research projects, sign up for their monthly newsletter, at leastauthority.com/newsletter. So thank you again, Least Authority. Now here is our Osmosis interview with Sunny and Dev.


(00:02:31):


So today I want to welcome Dev and Sunny to the show to talk to Tarun and I about Osmosis. Welcome to the show guys.


Sunny Aggarwal  (00:02:39):


Thanks for having us on again.


Dev Ojha (00:02:40):


Thanks, pleasure being back on.


Anna Rose (00:02:41):


Yeah. And it's funny, because you've both been on the show, but you've been on completely different episodes. This is the first time you're actually here together. I had Sunny on first, I believe, and we did an episode way back where you shared with me an introduction to Cosmos. I think it was the first episode we did on Cosmos actually. And then Dev, you came on the show for a deep ZK episode, where we looked at Fractal.


Sunny Aggarwal  (00:03:07):


I think actually, maybe the first time we did it was at EthCC, 2 or 3 years ago. I remember you were doing those governance...


Anna Rose (00:03:13):


The combo ones! Yes.


Sunny Aggarwal  (00:03:16):


That one was so much fun. I love...


Anna Rose (00:03:17):


That's true. Okay, so it's your third time on? Cool.


Sunny Aggarwal  (00:03:20):


I guess, technically. Yeah, that was one of my favorite interviews I've done, because you just had such cool questions about governance.


Anna Rose (00:03:25):


I remember you were talking about like Cosmos is the United Nations... Is it the United Nations? You had this interesting metaphor going on there.


Sunny Aggarwal  (00:03:34):


Yeah, I think it was Cosmos was NATO or something. Something like that.


Tarun Chitra  (00:03:41):


Do you still believe this analogy like a couple of years later?


Sunny Aggarwal  (00:03:45):


Yeah, I think so. Specifically, it was about the Cosmos Hub, like everything that does shared security with the Cosmos Hub is NATO and the Cosmos Hub is like the US who's just helping everyone else out, but it's more voluntary. It's not this thing that you are not allowed to leave.


Tarun Chitra  (00:04:03):


Why was I that asking, because what happens in a pandemic in this analogy? Do all the Cosmos chains start fighting for validators with each other?


Sunny Aggarwal  (00:04:11):


Maybe.


Tarun Chitra  (00:04:11):


Fix validators fix vaccines?


Anna Rose (00:04:16):


So you've both been on, I want to hear from both of you what you've been up to since those interviews? And maybe how the Cosmos ecosystem has also changed and your roles in it have also changed. So Sunny, why don't we start off with you? What have you been up to? What's what's new in Cosmos?


Sunny Aggarwal  (00:04:34):


Yeah, sure. So I guess we did that maybe 2 years ago. So that was after the launch of the Cosmos Hub and everything. So I've talked about that. I think what happened was most of 2019 was really spent working on getting IBC up and... Most of 2020, sorry, was spent on getting IBC up and running, and like Stargate, which was this huge upgrade to the Cosmos SDK. And the Cosmos SDK V1 was just like... It worked well for launching this thing, but we needed to basically build this V2 where we had these weird encoding structures in the first one and certain things were just very counter-intuitive.


Anna Rose (00:05:12):


Yeah. I actually did a whole episode on the Stargate upgrade from like four different perspectives, and we heard a lot about that. I'm going to add the link to that in the show notes.


Sunny Aggarwal  (00:05:20):


Oh, perfect.


Anna Rose (00:05:21):


But, yeah, so you were part of that. I was curious like how active were you during that thing? Were you already starting to work on Osmosis then, or were you focused primarily on Stargate?


Sunny Aggarwal  (00:05:32): 


I was helping a little bit on the Stargate's side, but it wasn't really my main focus. So what happened was, you probably heard about what we'd like to call GORE 2020, which is the Cosmos ecosystems' Great Organizational Restructuring of Early 2020.


Anna Rose (00:05:50):


GORE?


Sunny Aggarwal  (00:05:50):


GORE 2020.


Anna Rose (00:05:50):


I never heard that! Okay, cool.


Sunny Aggarwal  (00:05:54):


Basically we had like... What happened was everyone was working in this one company called Tendermint and then in early 2020, basically everyone... Or not everyone, the Tendermint company is still there, but then a lot of people sort of left the Tendermint company and started working on other things, like creating new companies to contribute back to Cosmos. And what's really interesting was, it was nice to see that no one left the Cosmos ecosystem as far as I can tell. Everyone's still working on Cosmos, but like Zaki went and like started working on, has founded a company called Inqlusion, and now they're building a product. You have a lot of like Chris and a lot of people, they went to the Interchain Foundation and it was working on Stargate from there. And so Dev and I sort of we already had this validator that we were running for a long time and I think we talked about that last time. And so we're like, all right, let's just...


Anna Rose (00:06:43):


Sikka.


Sunny Aggarwal  (00:06:44):


Yeah, and so we're like let's just run this validator and we'll do some a little bit of open source development, just contributing back to the Cosmos SDK in the meanwhile. And then as we got into it, we realized running validators just isn't super fun. At least it's not for us. I know there's some people who really enjoy it, but I think we're just more... We wanted to build something. I started working a lot with the Flashbots team very early on, so maybe like last summer basically, and they got me really excited about MEV and stuff. I'm like, wow! This is such a huge issue. And then they tell me their solution. I'm like, guys, that's not a solution, you're making the problem worse. You're productionizing the extraction of MEV. And I was like, no, no, no. So then we went back to Dev and I was like, all right, let's figure how to... They're going to make this problem even worse. Let's figure out how to solve it. And so we spent some time trying to figure out how to reduce the MEV. And we came up with a pretty good solution and we started building it. And then along the way we were like, okay, this is a really cool feature. It needs a product. And so that's sort of how Osmosis came about, where we merged with a company called Chainapsis, they built the Keplr wallet, which is the most popular wallet of the Cosmos ecosystem. And they actually built the base of the base of what Osmosis code base is today, at a hackathon last year. And Joshua was a really close friend, we worked together at Tendermint for a while, and he's been in the Cosmos ecosystem probably as long as I have actually. So we sort of have merged forces with them and we're like, all right, let's launch this Osmosis thing and then use it as a vehicle to lock, add in all this like front running resistance and privacy and all this kind of stuff we want to add on.


Anna Rose (00:08:23):


Cool, cool. I wanna dig into Osmosis really soon, but I want to also hear from you, Dev. What has your trajectory been? Because last time we spoke, you were deep in ZK world, and I know you were also running Sikka at the same time. What was your journey to this?


Dev Ojha (00:08:37):


Yeah, so I think the last time we talked, I was still running the Sikka validator, but back then, it was still kind of passive, where we just helped with some Cosmos SDK or Tendermint designs. Because you know, a lot of things are, Sunny and I had a core part, building a lot of the core infrastructure of SDK and Tendermint. Sunny and I, we devised some new designs there. But I was mostly focused on finishing college and doing a recursive SNARK research. So we talked, started this work on Fractal. And since then I was helping out with building this the Arkworks Rust ecosystem. You had a podcast with Pratyush the other day or maybe a couple months back.


Anna Rose (00:09:10):


A few months ago, yeah. Cool.


Dev Ojha (00:09:13):


And so I was helping out with that and trying to build the ecosystem, in addition to working on recursive SNARKs. Then sometime, like mid 2020, Sunny comes to me, he's like, "MEV. What do?"


Anna Rose (00:09:28):


Was there a moment in there where you were also looking at ZK stuff in the context of Osmosis or whatever this project was? Because I vaguely remember us talking about that.


Dev Ojha (00:09:37):


Yeah. So I think the initial dream of this was like, let's figure out how to make a zero knowledge DEX or like what's the most best way to get a DEX that's very privacy preserving. And we're like, okay, well this dream of literally no information about trades is public doesn't really work out. But how about this? How about  we have everyone... You can hide who is doing a trade, but the actual list of trades are still public. And we could do this, we figure out a way to front running and these ordering issues. And then basically we ended up just talking to people about this and they were all like, okay, this front running thing, it's very cool. We want it today in Ethereum. Privacy is interesting, but not a today problem.


Anna Rose (00:10:21):


Man, this is so the problem of what I feel like we face this constantly and it's totally economic and it makes total sense. There is a reason why there's priority given to some of these problems. But we've talked about this so often on the show, if privacy isn't baked in at the beginning, it's super hard to add later. But I'm going to leave hope that you will revisit it, because I know that you've gone further with the MEV but, Dev, I know that you have a deep background in zero knowledge stuff. So I'm hoping you'll bring it back in at some point


Dev Ojha (00:10:53):


Yeh. I think the dream is... My current dream is, there's this idea of having this... Some projects trying to have computation kinda done off-chain and have that computation to be private, so it's kind of the ZEXE model. Well, and I feel like what might actually end up being what happens is you still have the code be public and some public input to the code, but you're fully blind, who's doing things. You break this linking. And I think that's kind of the dream I have for what happens in Osmosis as well. Like we bake away so that maybe all of these actions are public, but who's doing it and ways to link actions, other than kind of metadata or side channel leakage of trying to figure out your strategies. Ignoring those, you can't really link these together.


Anna Rose (00:11:40):


Got it. So I think we're at the point where we should really introduce Osmosis, because we are now mentioning it a couple times. What is Osmosis? I've played with it, I think it's really exciting, but tell me exactly what it is and what people can do with it.


Sunny Aggarwal  (00:11:57):


Yeha, sure. So Osmosis is a DEX that we've built on the Cosmos ecosystem, currently the V1 that we launched, I would say it's basically most inspired by the Balancer. The hackathon project that was created a year ago that was basically taking the Balancer code base and putting it onto the Cosmos SDK. And so I think that Balancer has the most Cosmos-esque mindset of all the AMMs, or at least at the time it did. And what that means is, Cosmos, the mindset, is just about like, okay everyone can spin up their own zones and they'll have their own governance and they'll compete. And the market will figure out which ones work. I think Balancer is a very similar idea, but applied to AMMs. It's like, all right, give you as much flexibility as you want, or I go make weird weighted pools, go make multipathed pools. And you have multiple pools with the same pairs, and just the market will figure out which ones work out or not. And so that's why we were just the most drawn to Balancer. And so we took that code base and then we started just adding in ideas from other protocols as well. Like we really liked the bonded liquidity that Curve tries to do. And so we integrated things from that. We took a lot of inspiration from Sushi's token design and stuff, and how they do liquidity incentives. So we added that on. So yeah, we just took a bunch of ideas from different protocols on Ethereum and like, okay, let's bring this to Cosmos. Let's launch this, because Cosmos needs DeFi like now.


Anna Rose (00:13:28):


Yesterday.


Sunny Aggarwal  (00:13:29):


And then... Yesterday, yeah. And then, now we have it and now this is going to be a platform for us to start iterating and adding in all of these new features that we're talking about.


Anna Rose (00:13:43):


Is Osmosis a standalone blockchain? Is it a zone? Let's talk about how it connects into the Cosmos ecosystem.


Dev Ojha (00:13:52): 


Okay, sure. So it is its own independent L1. And in Cosmos, kind of the popularized way is it's a multichain world where every chain can talk to each one another via this protocol called IBC. TLDR is like just have those chains to use light clients to one another, you say, Okay, I trust your consensus is good. So if I can get a light client proof and have a finalized state, we can transfer assets back and forth. So we use this to connect to every other Cosmos zone who has us enabled. And so assets can flow in and out of Osmosis via IBC. And then you can trade on Osmosis and move things back out.


Anna Rose (00:14:32):


And one of the things that Osmosis, I believe, unlocks, and maybe there's another project that did it, but at least for me, it was the first time that ATOMs could be automatically... Like within a Cosmos product, actually traded for other Cosmos network or Cosmos ecosystem tokens. It's the first time that I see that, the first time that it at least becomes very easy without a centralized exchange. Is that the first project or was there anything like it before?


Dev Ojha (00:15:01):


Yeah, it's basically the first project that does that, first IBC-enabled DEX. And part of the problem was I think a lot of these Cosmos assets were having a little bit of a tough time getting added through centralized exchanges, because centralized exchanges have all of this infrastructure, if you have an ERC-20, they can just press a button probably and it adds the ERC-20, but integrating a chain, a new chain into a centralized exchange is definitely a lot more work, because they have to run a node, they have to do all this kind of stuff.


Anna Rose (00:15:30):


Even of it's just a Cosmos zone and it's using Cosmos SDK? Are they so customizable that they'd have to really work on it?


Tarun Chitra  (00:15:38):


They'd need to do an ETL on the data, to be able to query it, to determine provenance and stuff. And so they have to index each chain separately.


Anna Rose (00:15:45):


I see.


Tarun Chitra  (00:15:45):


With ETH, there's a million ways, a million tools to auto-index the different token standards. But I'm actually surprised, it's a slight tangent, but I'm surprised there isn't someone who does this data management for Cosmos chains. And do you guys see that as a problem in the future for people who want to do queries or Nansen-style tagging...


Sunny Aggarwal  (00:16:12):


So the Cosmos SDK, we started adding Rosetta API integration. So that's like Coinbase's, the one that they created. But we definitely need people to come in and add more of this, because for example, yesterday was our first reward distribution on-chain and the rewards just showed up in people's accounts. And then people were like, "Oh my God, how do I explain this to my tax person that I just got airdropped... Like $8,000 just dropped in my account, and there's no transaction explaining why that happened. And so this is definitely something that, from our side, we have to be improving events and logs that get output by the chain. And then I think there are definitely going to be companies that come in now, and once the DeFi is there, I think then these things... Now there's an incentive to put together all of this analytics now.


Anna Rose (00:16:59):


Let's talk a little bit about what it is to use Osmosis from a user's perspective, so that people can really understand what this is, and maybe what it enables. Let's start the journey from the Hub, the Cosmos, where the ATOMs live. What would a user do from there? They have ATOMs, what do they do?


Dev Ojha (00:17:19):


So currently the flow is you go to this Osmosis website with your Keplr wallet connected, and then you click on some assets page and you basically have an ATOM's field. If you press deposit, and enter the amount you want to deposit onto the chain, it'll do an IBC transfer underneath. And so what that means is, one of the nice things about Cosmos is that we do have a standard for addresses and pubkeys. So I can have an address on the Cosmos Hub and I can actually have an address with the same pubkey on Osmosis. So this asset button when you hit deposit, what it's gonna do is it's going to do this IBC transfer and then to move those tokens from the Hub onto Osmosis. So IBC's actually, and I give TLDR earlier, It's light client verification of both chains. There's a lot of details to it. There's things called channel IDs for allowing a chain to have multiple connections with other chain. And these look like a random hash, basically. So what's stored on-chain is actually unreadable for us. What are these things? One thing we've worked really hard on, or the Chainapsis folks worked really hard on, was getting this UI to be such that the user doesn't have to ever learn about the fact that channels are underneath.


Anna Rose (00:18:38):


That you can just do this IBC transfer right into that new zone, basically?


Sunny Aggarwal  (00:18:44):


As far as I can tell, our front end doesn't even say the word IBC anywhere. It's literally just, it says deposit and withdraw and it's just supposed to mimic the UX that users are already familiar with.


Anna Rose (00:18:56):


Well, having used Keplr to also play with this, I did have to push a button that said transfer using IBC, but I was excited to do it because I'd heard about IBC for so long, and I was like, oh, cool. I get to use IBC. By the way, I have a question to both of you. And this is something I've asked a few times. You just mentioned IBC as these two light clients living on different zones. It's a rule set for transferring tokens across different blockchains, but is it a bridge? Is IBC like the makings of a bridge. And because I've heard it lumped in, or maybe we actually on the show lumped it in with bridges as a type of bridge or something. But I don't know, how do you see it? Do you think of it as a bridge?


Sunny Aggarwal  (00:19:37):


Yeah. Basically, it is a bridge. It is a protocol for building bridges. It's a generalized bridge protocol right now. And by bridge, depends on what you mean by bridge. I don't know if there's a tautology, where I'm going to say, oh, if you mean a bridge as something that's generalized, I have two chains talk to each other, then yes, that's what IBC is.


Tarun Chitra  (00:19:56):


I think bridges should be classified by what their bus is. Do they need to have data availability on both sides, do they need to have data availability on one side? Do they only do metadata between them? So maybe actually distinguishing in that sense would be useful.


Sunny Aggarwal  (00:20:10):


Yeah. So what IBC is, all it knows is, hey, give me a light client proof that something exists in your stage tree. That's all it cares about. Now you build higher level protocols on top of that. And one of them is, we call it ICS 20, which is the ability to transfer tokens. And so that's a higher level protocol built on top of IBC, where it's like, "Okay, what are we proving about your state? It's like okay that you locked up tokens in this specific part of state. And then I'll accept that, and then mint your tokens here. It's you can have ICSs for all of things. You can just say, "Oh, here's a proof that there's some Oracle data that's on the other chain." And prove to me that that Oracle data is in the state of your chain. And is that classified as a bridge? I don't know, but that's what IBC does. The other piece of IBC that's interesting is that it's just so standardized. The process of running a bridge is really annoying, because we're actually starting to run Ethereum bridges on the Cosmos Hub soon. And so, as a validator, we have to start running Ethereum nodes and all this kind of stuff. But with IBC, you can make a connection between two chains by sending two transactions. You send a transaction on chain 1 and send a transaction on chain 2, and you have a bridge. And just the fact that how fast and simple it is, I think that's what's going to be really game-changing for IBC.


Tarun Chitra  (00:21:37):


And one question, what's the destructor process for IBC? Like if I want to close a bus of data being sent between two chains. I imagine it's something like you send one transaction that's like open, receive from remote chain X, remote chain X makes a transaction that's like send just data or metadata across. But when you close things, is there a process? Is there like, yeah, what's the destructor process? Is there a lot of state on both chains?


Dev Ojha (00:22:06):


So I guess, we're talking about as an individual user? Or are we talking about the entire channel or the bus itself?


Tarun Chitra  (00:22:12):


I guess the bus itself, because I'm trying to think about, let's say, you're an Osmosis and I want to route trades between different chains and there's many different routes. I may want to deprecate some edges in that sort of like pairs of trades that you're allowed to make because they're inefficient or like...


Dev Ojha (00:22:30):


So I could be wrong, but I believe the base IBC protocol actually doesn't really do destructors, in the sense where, if I open this bus, it's like I don't really have to actively maintain too much. And what I'm maintaining is like a last header of the other chain or the last block hash. And then, after some period of time, it becomes too old, like weak subjectivity concerns, and you're going to need governance of the host chain to re-update the hash. The reason for this is, because proof of stake has this whole weak subjectivity issue, where if I'm trying to client sync to your chain and it's been too long, I can't actually know, is this the real chain or not.


Sunny Aggarwal  (00:23:15):


So the IBC connections can never be closed. And that's what IBC... That's the header part and then the ICS 20, those take place on the channels on top. And so whether those can be closed, it's up to the ICS where the ICS can say, "Okay, we have a methodology for deciding to close it, for deprecating a channel or not." I don't believe the ICS 20 one has one, but you could build an ICS that can be closed.


Anna Rose (00:23:41):


You've used this a few times, but ICS, what does that stand for?


Sunny Aggarwal  (00:23:44):


Interchain Standard.


Anna Rose (00:23:45):


Okay.


Dev Ojha (00:23:45):


So you can imagine this how for a normal networking things, there's UDP and then everyone builds their own or not, a lot of people build their own protocols on top of UDP. Now we're seeing QUIC, it's very exciting, it's actually getting deployed. Then you have these things for video formats, et cetera, that are these protocols on top of UDP, where it's like, "Okay, well here's this one way of communicating, but me and you, we know we're going to send data in some more advanced format. So we can do some tricks and the structuring and coding of things to get better efficiency." And so that's the analogy for ICSs are, where it's like, okay, well, we have this communication route called IBC, and then we can build together, me and other chain can add more things on top, if we want to. And the way we standards for what are these more things we're building are called the ICSs.


Sunny Aggarwal  (00:24:41):


Same as ERCs. ERCs are just standards for how smart contracts talk to each other. ICSs are going to be standards for how chains talk to each other over IBC.


Anna Rose (00:24:48):


Awesome. That's actually a great comparison that helps give a good, clear picture of what that is.


Tarun Chitra  (00:24:55):


Yeah. Actually maybe a little bit back to Osmosis. How do you deal with routing across chains right now?


Sunny Aggarwal  (00:25:01):


We only do direct connections right now. So I think that this might be a controversial opinion, but I think that the Cosmos Hub vision of being the router for all chains is wrong. I think that all chains will connect to every other chain. You'll have many, many connections and everything will, if you want to send tokens from one chain to another, what you will end up... Let's say you have a token from a third chain and you want to send that from A to B, well, I think what's going to happen is they're going to unwind that first hop and then you're gonna extend the next hop. I really don't think connections are going to be, or assets are gonna be multi-hop. I think they're going to... Most of them are gonna be one hop only.


Dev Ojha (00:25:38):


I think multi-hop is, in some way, a premature optimization, unless we get this world of thousands of different blockchains, not hundreds, actual thousands or tens of thousands.


Tarun Chitra  (00:25:48):


Yeah. I mean, I guess in Ethereum it makes a lot of sense, because there are actually millions of tokens on Uniswap. And so you do actually have to care about this. But I guess the idea here is your best unbiased estimate for how the market develops is you're going to have a small set of Cosmos chains, like sub a thousand that you have pair-to-pair or connect-to-hub trading, basically.


Sunny Aggarwal  (00:26:15): 


Yeah. I think that Osmosis should be able to connect to 1000 chains by itself. Like it shouldn't have to go through another router to do that. And if...


Tarun Chitra  (00:26:25):


Actually, are there any limitations on size, so how many DEXs you can create or is there like extra resident state that is common to a registry and the registry can't be too big or something like that?


Dev Ojha (00:26:39):


So actually the state for every IBC connection is not that bad, it's basically what you need as a light client. So proof of stake, it's basically just last verified header, proof of work actually do the same thing, last, final header that you believe was finalized, which is not that much data. A header should not be more than a kilobyte. So it's like, can you store a kilobyte for every chain? Yeah.


Sunny Aggarwal  (00:27:02):


And you don't need to keep the history. I mean, you can just prune away anything that's older than three weeks or whatever the un-bonding period is.


Tarun Chitra  (00:27:09):


Right. But you don't have to store data per pair, right? It's not N-squared storage.


Sunny Aggarwal  (00:27:15):


Are you asking for Osmosis, for the DEX, or are you talking about the IBC connections?


Tarun Chitra  (00:27:19):


For the DEX. Sorry, for the DEX. How much state do you.... I'm just curious, if I were to scale this, at 1,000,000 chains, would Osmosis have some performance or cost degradation? At 1,000,000,000 chains would it have that or at a 10,000... Just to get an idea of how to think about it relative to Ethereum DEXs, where there's millions of tokens.


Sunny Aggarwal  (00:27:41):


Yeah. I mean, I think the solution is you end up having base pairs. And that's just always been the solution. And so on Osmosis right now, basically there's two base pairs being used. There's half the pools are basically using ATOM as a base pair, and half the pools are using OSMO as a base pair.


Dev Ojha (00:27:55):


So anyway, it is permissionless, anyone can add more base pairs, but so far, no one's...


Sunny Aggarwal  (00:27:59):


There are some pools already that have been added, which is like AKT/ DVPN or something, but it's like you see most of the liquidity is still concentrated on the ATOM/OSMO pairs.


Tarun Chitra  (00:28:10):


Actually, is anyone else doing liquidity mining for providing liquidity to Osmosis pools, other than the Osmosis ones themselves?


Sunny Aggarwal  (00:28:18):


Yes. Well, it's going to start probably like... I don't know, it depends on when they send the transaction, either today or tomorrow, but the Akash network team is going to be adding additional incentives, and the chain is designed to do this where it's very easy... They just have to send the funds into a contract and then it'll automatically start distributing at the same time with all the OSMO rewards. And I think there's a couple of other teams who are also, like the AKT team and I think there's 2 or 3 teams that are all trying to add in the external incentives.


Anna Rose (00:28:47):


You just mentioned sort of on a smart contract. Is Osmosis, can someone deploy something onto that zone in that zone? Is it smart contract-enabled itself?


Sunny Aggarwal  (00:28:56):


Yeah, that's why I hesitated, when I said the word contract. I use the term, because it's probably something that most people are familiar with, but no, it's not actually a smart contract. It's like, currently all the logic on Osmosis is part of the node code base. And so you can't add additional functionality, I guess. We're looking into how to you add more customizability, especially for the AMMs, because one of the core goals of Osmosis was to have very customizable AMMs. And so to do that, we'll probably gonna need some sort of VM, we want to be more staged in our rollout for this. And so we want to make it more, a very restricted sort of VM, where it's like, okay, you're only allowed to deploy a contract as long as it meets the interface that we expect an AMM should have. That kind of thing.


Dev Ojha (00:29:49):


It's really a restriction for helping people who want to get some extra functionality. It's not a real restriction on you, whatever you build for a VM, it's almost certainly going to be Turing-complete, and you can hack in whatever type of functionality you want, because Turing-complete, you just change inputs and outputs as you please.


Tarun Chitra  (00:30:06):


Are you actually planning on making it a full VM? Or is it going to be an interpreter or something like tiny register, mini register machine? How do you think about what the minimum viable version of this looks like?


Dev Ojha (00:30:22):


So when we were last looking at it, there is this new VM language, popularized in Cosmos, called CosmWasm, which is, you give it this Wasm code, and then, so you locally compile your native architecture, you trust this compilation process isn't going to introduce any non-determinism across machines. So you do have... I guess it's a VM in sense that the VM, upon reception of code, compiles it locally and executes that compiled code. So then it's using, I don't really know how Wasm register system works, but then the compiler code uses your...


Tarun Chitra  (00:30:57):


Yeah. No, I mean, the Wasm interpreter does have sort of some mapping to registers. I was just curious. Where you're thinking about that, because I do think that problem can get hairy, if you...


Dev Ojha (00:31:09):


So the reason we just want to start from actually a more interpreted code, it's actually hard to enforce any API structure on the compiled code, or trying to get security guarantees.


Tarun Chitra  (00:31:21):


Yes. Don't look at the Solana virtual machine, if you want to see a bad example of this.


Sunny Aggarwal  (00:31:27): 


Before we started using CosmWasm for this, we were actually looking at this thing called CEL-Go, it's by Google. And it's this interpreted, non Turing-complete math interpreters. It's pretty easy to write math functions into it. And that's why we're like, all right, AMMS are just math functions. And so let's just use that. And then what we realized over time is AMMs actually have to be way more stateful than we were expecting. And so that's why the whole Cel-Go, we switched it out with something that is more like a traditional contracting system, which is CosmWasm.


Anna Rose (00:31:58):


I know that in the Cosmos Hub world, there's also this Gravity DEX. There was a hub proposal around this. What is that? And how does it relate to what you're doing?


Sunny Aggarwal  (00:32:08):


Yeah. So Gravity DEX, it's an AMM that's being deployed on the Cosmos Hub directly. Osmosis and Gravity DEX  kind of birthed around the same time, near the end of last year.


Anna Rose (00:32:23):


Who's the team behind it? Who's pushing that?


Sunny Aggarwal  (00:32:27):


It's a team called B-Harvest.They're a validator on Cosmos Hub and I think they actually recently got acquired by Tendermint.


Anna Rose (00:32:34):


Okay.


Tarun Chitra  (00:32:36):


Weren't they doing staking derivatives at some point, and then they'd stopped?


Anna Rose (00:32:41):


And ZK stuff, I think.


Sunny Aggarwal  (00:32:42):


And ZK stuff.


Tarun Chitra  (00:32:43):


It sounds like a very buzzword-hopping type of thing.


Sunny Aggarwal  (00:32:48):


Yeah. And so when we started doing Osmosis, we were like, hey, let's put this on the Hub. Let's go build the DEX for the Hub. And then as we went into it, we just realized, for multiple reasons, that's just not the right way to do it, because for one, we just want to be able to upgrade way faster. Like the Hub is a much slower thing. Our goal was, we want to be able to upgrade the chain on a monthly basis if we want, that's just something that Hub doesn't do.


Anna Rose (00:33:15):


Because if you did it through the Hub, you'd actually have to do it with voting and validators and here you have... But with Osmosis don't you also have to do it with the validators? Or do you feel like, is there still sort of a developer key that lets you move fast?


Sunny Aggarwal  (00:33:30):


There's no developer key, but it's just about the expectations that were set, we've told every validator that runs on Osmosis it would be like, hey, expect to be upgrading every month, if you're not okay with that, please don't run a validator on Osmosis. And that sort of like, the Hub is meant to be this more conservative chain. And Osmosis, it's a science lab, it's like we were pushing this idea that it's meant for experimentation, we're gonna go just way faster. And then on top of that, we also just needed access to much lower level stuff, like we can't do the threshold decryption stuff, we need to go change how Tendermint works a little bit. And so having our own chain is useful, it's really important to be able to move fast on those kinds of things. And then finally, obviously, just to bootstrap a DEX, you need some sort of liquidity mining scheme and it's really hard to build a good liquidity mining scheme on an existing token, like ATOM that's already so distributed. If we're building this DEX, we want it owned by the LPs and make sure they're incentivized and are part of the governance process. And so the best way to do that is to issue a new token that you give to the LPs.


Anna Rose (00:34:36):


What is the plan for connection to Ethereum? How would that happen for Osmosis? I know that there's a bridge being built, but wasn't that bridge between the Hub and Ethereum?


Sunny Aggarwal  (00:34:49):


Yeah. So there's a team called Althea, they're putting together something called Gravity Bridge, which is...


Anna Rose (00:34:54):


I thing I was mixing those up actually. Sorry. Okay. That's fine.


Sunny Aggarwal  (00:34:59):


Also, yeah. It's confusing though, because it's called Gravity DEX and Gravity Bridge. So Gravity Bridge is this bridge from Cosmos SDK chain to Ethereum. So it's the name of the software. And then the Hub is planning on deploying it to connect to Ethereum, but then different chains can deploy it as well. For example, Sommelier actually, which is Zaki's project, they also are using Gravity Bridge, but they're adding in more extensions on top of it as well.


Anna Rose (00:35:26):


So you guys, Osmosis, would just deploy the Gravity Bridge potentially?


Sunny Aggarwal  (00:35:30):


Potentially. So I mean the original idea was we wanted to just go ahead and use the Gravity Bridge of the Cosmos Hub, but we're a little bit worried right now about the credible neutrality of the Cosmos Hub because if you have this.... This is kind of what I've always been pushing, where it's like, hey guys, don't put this DEX on the Hub, because you're going to harm the new... Imagine Ethereum Foundation built their own native DEX, would people have built DEXs on top of Ethereum? Probably not. So I don't know. I think that hopefully Gravity DEX spins off onto its own chain eventually. And then Osmosis would be happy to use the Gravity Bridge of the Hub, but we'll see. And if not, then maybe we just end up deploying our own.


Tarun Chitra  (00:36:10):


And there is some precedent for this, Vitalik did basically right on the Uniswap forum, "Hey, you should just copy UMA". And I feel like UMA sentiment has not quite recovered since then.


Sunny Aggarwal  (00:36:27):


Yeah. I tweeted that where I was like, All right, so... It was literally just like you to said, copy UMA. It was really very interesting.


Tarun Chitra  (00:36:36):


More or less. I mean, without... In more polite terms, perhaps, it was like; well, UMA sucks at liquidity, so Uniswap, you should just copy them. It was basically the TLDR.


Dev Ojha (00:36:47):


You have high market cap, use this to do all the good ideas.


Anna Rose (00:36:51):


So I want to go back a little bit to this user journey. We started on that user journey. We got them using Keplr, sending something over IBC, but I want to go back to what happens when someone arrives in Osmosis. What do you do there?


Dev Ojha (00:37:08): 


That's kind of what do you want to do? So DEXs now have the ability to add liquidity to stake your tokens, or to trade on DEX, it's got a permissionless manner.


Sunny Aggarwal  (00:37:17): 


It has the same functionality as you can imagine on Uniswap today. There's three buttons at the top, there's the trade, pool and like govern or something. I think they have gov, right?


Anna Rose (00:37:29):


But that's a slight difference is that because it's a proof of stake chain of its own, that's what's kind of a little different, at least when I was looking at the interface. It also looks like the interface of any proof of stake network, where you're actually using voting, you're staking, you're adding liquidity and you trade. I guess it's the liquidity adding and the staking in the same interface that I hadn't seen before. Well, I guess I have seen it, when you have these, like I know Aave, you can stake as well, but I guess I know that in this case there's actually an underlying blockchain. And so you're validating when you're staking with somebody, you're actually validating this whole blockchain.


Sunny Aggarwal  (00:38:09):


Yeah. Right now there's two options. If you have OSMO, you can go LP it or you could go stake it. And this is a choice that you have to make right now. But over time, we're actually gonna make these... These two things are going to become more and more combined. So we're working on something called codename right called reverse staking derivatives. We'll probably come up with a better name, I think superfluid staking. I think...So here is why I call it reverse...


Tarun Chitra  (00:38:34):


Now you sound... Do you realize that your choice of naming makes you sound like boring TradFi people? Because repurchase agreements are like staking agreements and reverse repo is when the central bank does the opposite. And now you sound like...


Anna Rose (00:38:47):


You sound like you need a new name.


Sunny Aggarwal  (00:38:53):


We'll have a name, don't worry, I'm working on the name. But here...


Tarun Chitra  (00:38:56):


It's like a little too TradFi for you. That's all I...


Sunny Aggarwal  (00:39:02):


Yeah. I completely agree. I'm liking the term superfluid somehow. And I want to use that because I think it comes from...


Tarun Chitra  (00:39:08):


Dan Elitzer. He gets, I guess he gets credit for that, right?


Sunny Aggarwal  (00:39:10):


Yeah. Another reason is, because I really love Dan's post and it's basically based off of that. So let me explain what it is first. So what it is is in normal staking derivatives, and it's also usually called liquid staking. What people are proposing is you go ahead and you stake your coins, you get back some derivative asset.


Anna Rose (00:39:30):


Like an IOU to that.


Sunny Aggarwal  (00:39:33):


Yeah. And then you go use that asset in DeFI. But the problem is this just breaks the entire security model of proof of stake. We spent all this time designing proof of stake and all this lockups and everything, and this just undoes it. So the reason I've been calling it reverse is we're putting this in the opposite direction. What if we take our staking coin, use it in DeFi, take our DeFi assets and stake them. So in this example, for Osmosis specifically, it would be, imagine you have OSMO and something else, Bitcoin, you add it to the liquidity pool, you get back an LP share. And this LP share has some underlying OSMO value. If you were to withdraw it, you could get out a certain amount of OSMO. And so now we're saying, well, let's just go ahead and stake this LP share, and have it be treated as the underlying OSMO value. And the chain can query this every single block, if it wants you to, say, what is the conversion between this LP share and the OSMO. Obviously, it wouldn't be like every pool can do this, because that will get out of hand. But the chain can basically vote to say, all right, these pools, their LP shares are allowed to be staked. And so now you can be both LP-ing and staking at the same time. And obviously a lot of this is actually heavily inspired from Tarun's work as well, he has a whole thing about how you can borrow against LP shares.


Tarun Chitra  (00:40:54):


Yeah. That's cool. Just needs a better name.


Dev Ojha (00:40:59):


Yeah, I think this name superfluid has a problem where superfluids are nice. There's zero friction. Yeah. But if you stake...


Tarun Chitra  (00:41:04):


Superfluid? You know that there's also supersolid, it's actually been very hard to construct these things. This is why I left physics. It just took 10 years to fucking resolve this thing. But there was this guy who claimed to have made supersolid helium-4 and super solids are interesting. Superfluids have no friction, but they kind of rotate forever, like almost perpetual motion machine. Supersolids are like super liquids, except imagine an ice cube in a little circle and you push it and then it just rotates forever. But it stays as an ice cube, it doesn't melt or it doesn't have... All the atoms are basically.... So anyway, sorry, slight tangent. But you may want to look into names like that.


Sunny Aggarwal  (00:41:48):


I'll look into supersolids. But superfluid's cool, because it's liquid staking, this is superfluid staking, and then it is picking Dan's idea of using the same collateral for many things. And that is literally what we're trying to do here.


Tarun Chitra  (00:42:00):


I wonder if any layer 1 would do this. I mean, not saying that you aren't, I just mean one that is like...


Sunny Aggarwal  (00:42:06): 


I want to be able to expand this to more and more DeFi assets. I mean, ironically, I think LP shares are probably been the harder ones to start with, but it's what our chain is. But you can imagine it's much easier to do this with something like C-OSMO, if you had OSMO and Compound, it's much easy to take that C asset and have that be staked. LP shares are probably much harder because of the impermanent loss and all that kind of thing. I think there's a whole new paradigm here that can be done, where we can generalize this and have it be used for all these different DeFI assets that are based on OSMO and can still be used to stake.


Dev Ojha (00:42:38):


The main, hard question here is how does the chain reason about the risk premium it should be taking. Like 1 Compound/OSMO, say, should not really be worth, suppose as 1 OSMO's collateral for this, shall be worth a full OSMO, because there's some correlated concerns here, like liquidation that's not caught in time and it can actually not be withdrawn for full OSMO back, it can only maybe it's 0.9. And how do you reason about this as chain governance seems actually pretty hard.


Anna Rose (00:43:09):


You have a validator set of your own. That's the security of the Osmosis chain. But is there any shared security at all between you and any of the tokens that are coming across IBC? Or is this completely separate?


Sunny Aggarwal  (00:43:24):


Right now there's no shared security. I mean, this is also part of why I was upset about Gravity DEX, because I was like, guys! you guys should be working on shared security. We need to use it. But at the moment, yeah, Osmosis is just self-sovereign and all other chains are also self-sovereign.


Anna Rose (00:43:40):


Does this not bring up that issue or that fear of if there is a corrupt zone and it has deployed IBC and it starts to trade with other IBC-enabled assets, but it's corrupt, so it's bullshit. Could that somehow taint or screw up some of these trades? Basically like minting things that aren't there and having some... Could it be a rug pull at some point?


Sunny Aggarwal  (00:44:05):


I don't think so. Because only the people who hold or are exposed to the asset from that chain are the ones who are affected. Because if, let's say you hold ATOMs on Osmosis and then this other chain goes corrupt, they can't do anything to ATOMs. What they could do is they could go ahead and mint infinite of the other token and then drain the liquidity pools and take all the ATOMs. So yes, but as being an LP of a pool with that token, you're still exposed to that. And so if you're exposed to it, it's the same as having held the token on the other originating chain itself.


Anna Rose (00:44:43):


You're saying like the ATOMs, like the other assets wouldn't be affected, those chains wouldn't be affected, but the LP tokens in Osmosis and LP token holders would be, if they had that corrupt one?


Sunny Aggarwal  (00:44:53):


Only for the people of that pool.


Dev Ojha (00:44:55):


Like to phrase a bit differently, It is a theory in the kind of earlier overview IBC we were giving, but there's a separate thing in IBC that says that basically tokens from one zone, originating from one zone, can't be confused with tokens originating from other zone. So only tokens that are from there could have this confusion. So zone C cannot mint ATOMs, or they can mint some tokens to localize at their chain, and it has the same name, because names, they're internally namespaced, but it can't be confused on Osmosis or another chain as though it's from the Hub.


Sunny Aggarwal  (00:45:33):


Goal of ICS 20 and the styles of ICSs that we want to design are so that we want to localize anything that like any chain failure, it should be localized to people who are exposed... They have to opt in, right.


Anna Rose (00:45:45):


Exposed to that chain. Like they chose.... I want to now ask you a question about what is an asset on Osmosis though? I'm just realizing, it's not that the ATOMs are actually on Osmosis, they're just derivatives of ATOMs through IBC, right? And so you'd have derivatives of this crappy chain. Would there be any way to block it, if that happened somehow? I mean, I don't know, maybe that's impossible. Or any way to gauge, if all of a sudden there's this flood of seemingly more tokens than there should be coming into Osmosis from this corrupt chain, would there be any signifier to stop that?


Dev Ojha (00:46:24): 


So there is one safeguard thus far, and it's already deployed, which is that suppose I sent over, the Hub sent over 1000 ATOMs to Osmosis. If there was a bug and Osmosis had some corruption, it could not send back 1001 ATOMs, the Hub keeps track that we had 1000 tokens flowing out this way. And so you can only send back 1000, but then the chain the zone, you were sent to, could still do attacks like changing who owns it, but they can never mint more. And there's some ideas for boosting this where it's like, okay, maybe we want to rate-limit transfers back and forth for some reason, because it gives you time to catch a failure, some ideas for doing some more tracking of whale addresses or something. But these are still very much in spec phase and they're not such that they're always good. Whereas for this one, like ensuring it's max supply per zone, maximum is sent back to me, that one's like deploy everywhere, because there's almost no reason to not have that.


Sunny Aggarwal  (00:47:27):


So because of this restriction, if you're one of the boomers who is keeping your ATOMs on the Cosmos Hub and not bringing them to Osmosis, you will not be affected if Osmosis bails for some reason. Only the people who actively chose to bring ATOMs into Osmosis will be affected.


Anna Rose (00:47:43):


Got it.


Tarun Chitra  (00:47:45):


And remember, this is true in Ethland too. That's why if Uniswap moves completely to WETH, and so once they did that, it basically meant that you have the exact same issue. If WETH failed then like, goodbye everything. And that's not just Uniswap, all the AMMs use WETH. Except Curve, but that's because of using stable... Mainly stablecoins.


Sunny Aggarwal  (00:48:05):


I guess the fact that ATOMs are one of the two base pairs right now, Osmosis could be worried, if the Cosmos Hub gets corrupted, almost half the pools are based on ATOMs. And if you could just mint infinite ATOMs right now, you could drain half the pools.


Anna Rose (00:48:22):


But I guess your assumption here is the security model there is decent enough to make that your base for now.


Tarun Chitra  (00:48:28):


If we get back to some of the biggest problems with AMMs and constant function market makers in general, it's the problem of sandwich attacks and other things, but I guess that's the most prominent one. And that brings us to sort of MEV, or miner extractable value or VEV, validator extractable value. Both of these terms are kind of, MEV and VEV, would annoy physicists if they saw that. One is vacuum expectation value and the other as Mega Electron Volt.


Dev Ojha (00:48:59):


One is Milli Electron Volt.


Tarun Chitra  (00:49:01):


Or Milli Electron Volt. It's just that usually whenever you're measuring an electron volts, it needs to be giganto. But one interesting thing is I think there's been this huge philosophical debate about MEV. Does it have to exist? Can we actually really find a cryptographic solution? Should we bother trying? Or should we only have an economic solution? This of course led to this very public fight between Phil Daian and his advisor. Which usually in academia, people don't get along with their advisor, but it's usually their advisor just shits on them at conferences, but here it's like his advisor is writing this public news article being like, my student sucks, effectively. And so you're on a very particular side of this argument. So I think it'd be really great to hear your views. What influence is why you think it is sort of like the way you believe and then I'm framing it openly, so you can...


Anna Rose (00:50:03):


Maybe do explain both sides, too, for listeners. Might be helpful.


Sunny Aggarwal  (00:50:07):


Yeah, sure. So, I mean, for content, I definitely agree with... His advisor is Ari, right? Ari Juels?


Tarun Chitra  (00:50:13):


Yes.


Sunny Aggarwal  (00:50:13):


Yeah. So I definitely agree with Ari on this one. Let me explain the situation first. So what is MEV, miner extractable value? What it is it's the idea that whoever the block proposer is, so in proof of stake it's validators and in proof of work it's miners, the block proposer has certain powers that no one else has and they can use those powers in order to extract value and get some edge.


Anna Rose (00:50:39):


A.K.A front run.


Sunny Aggarwal  (00:50:42):


Front running is one. In my classification of MEV, I would include things like time jacket.  Remember those things where it's like, oh... Back when people used to use the timestamp as a source of randomness in Ethereum. It's like, if you manipulate that, I considered that miner extractable value. Anything that the miner can do is part of it. Now front running is probably the biggest class of MEV attacks. Before that there's what I call a transaction ordering/censorship attacks, which is the idea that the proposer can choose what gets included in a block and what order they're included in the block. And so within this, there's two categorizations. I call it absolute positioning and relative positioning. Absolute positioning is just saying that you're not trying to base yourself off of other transaction in a block, you're just trying to have some absolute position in a block. And this would be something like, if there's liquidations happening and someone has to be the one to trigger the liquidation and they get some profit by doing so, the block opposers able to, say, guarantee that they will be the first one in the block. And that way they can always....That's extractable value. And this type of MEV... I mean, we have ideas for how to restrict it, but it's not what we're focused on at the moment, maybe we'll come to that in a future. And I think that there's actually a reasonable philosophical argument. I think there's a good debate to be had there, where someone has to be doing these liquidations, and they're not extracting value from anyone, it is really a positive something where they're performing a service for the network. And they're just making sure they get to be the ones to do it and profit from it. But they're not actively harming anyone else. But then there's the other form, which is what I call a relative front running, where you're trying to base your transactions position off of someone else's transaction. And so this is what sandwich attacks would be, like that, where you see a trade coming in, a big trade, you could go ahead and...


Anna Rose (00:52:44):


And pump up the value or push down, do something to the price and then you can profit from it.


Sunny Aggarwal  (00:52:50):


And for this, I really do not see how there's a strong argument to be made that this is ethical, I just don't see it. This is a privacy concern to me. I really do see this relative front running as a privacy concern more than anything else. It's if I'm able to hide what I'm about to do, I should be doing that. And so the threshold decryption solution that we're building is really meant to address that relative front running. And so to your point about Phil, honestly, I don't understand where they're coming from right now. In his MEV What Do blog posts, he's like, there's a protocol Equitas and they do like a bunch of like.... They're focused more on the absolute front running, I think, or they're looking into a different solution, working like a privacy-focused solution on front running. They're taking a more fair ordering solution, which they have some ideas there. But Phil puts this chart, and in the Equitas thing, they have 4 or 5 different parameterizations of their protocol, and each of them have different outputs, and he's like, well, which of these should we do? They all have trade-offs, how can we decide? And then he's like, Phil, every single one of those are better than what's going on currently. You can't be like, oh, there's too many choices that are better than the current to be a reason not to fix what's going on right now.


Anna Rose (00:54:10):


What is the philosophy of Flashbots though, in regards to that? What's the difference? What you're describing is how they're critiquing these models, but what are they doing?


Sunny Aggarwal  (00:54:21):


Okay. So front running an MEV, there's the MEV itself, there's the value being extracted from users, and then there's side effects to MEV and this is like the insane gas spikes and the like consensus instability, and all this kind of stuff that happens from side effects of MEV. And I think the Flashbots team is really focused on minimizing the side effects of MEV, but they're not actually focused on tackling the MEV itself.


Dev Ojha (00:54:50):


I think that's a bit of an understatement. So things like sandwiching, it does fix that. Imagine you have this layer of all these transactions are encrypted via centralized SGX...


Sunny Aggarwal  (00:55:01):


Which is not right now, by the way, they don't use SGX right now. They just send to miners.


Tarun Chitra  (00:55:06):


There's no... Now for the record, and there's a lot of controversy about this today on the Flashbots Discord and Twitter, they are extremely centralized service that is attempting to decentralize via SGX or potentially some other routes, but they already have spam issues, cause they only have like 3 nodes and they're running into basically sybil resistance issues right now.


Dev Ojha (00:55:32):


This is the whole reputation thing, right?


Tarun Chitra  (00:55:33):


Yes.


Anna Rose (00:55:33):


So wait, they were thinking of using SGX, but are they using SGX to perform the same kind of thing that you wanted to do with threshold cryptography? Like create a private area where people can't see what's coming next and therefore not do the sandwich?


Tarun Chitra  (00:55:48):


The auction should be private. So there's an auction that takes place. Although it's kind of a... They solve the auction greedily. So it's not the optimal solution when there's multiple things presented right now. And that also led to some attacks against it. But if the auction is private, then no one can see who the winning sandwicher is or try to front run them right before. And right now it's kept private by, they run the node and you effectively trust them on that.


Dev Ojha (00:56:16):


So if you trust that they run the node, you don't really have details of how much sandwich opportunity is there, you don't get to read everyone else's transaction before you get to make your bid.


Anna Rose (00:56:28):


So they act as the privacy entity.


Tarun Chitra  (00:56:31):


Yeah. Effectively right now. And obviously, for a variety of reasons, some legal, some philosophical, some economical, you really want to not be centralized, but they wanted to get to market really quickly. And to be fair, they were able to aggregate an insane amount of hash power because of that, because they were the first ones to do it. And they also didn't, these cryptographic mechanisms are quite unproven in practice and production like that. That's the real... It's like SNARKs, are we really sure we're ready to actually deploy this on hundreds of billions of dollars? Probably not.


Sunny Aggarwal  (00:57:10):


To give them credit? You know, I believe part of their roadmap is they want to use the SGX to become this sort of private mempool over time that each miner can just have their own SGX based mempool and normal users can use it. So there's something called MistX right now, which is like an overlay on top of Uniswap which uses the Flashbots system. And so, like I said, no SGX right now, but eventually if they just do SGX, you could use that as a way of creating a private mempool. Normal users could submit transactions privately, but then we have all these reasons why SGX doesn't work. So Dev can maybe go into that.


Dev Ojha (00:57:45):


Yeah, I mean, SGX is kind of... What it's doing is saying, okay, here's a compute device.


Anna Rose (00:57:53):


Enclave? Yeah. Actually, I would say like, I think our listeners probably know the SGX battle at this point, pretty well. It's a trusted enclave, there could be a backdoor...


Sunny Aggarwal  (00:58:03):


I guess, the main, well, the thing that we actually are... is, for us it's like what is the security budget here? Right? It's like how much will it cost you to break an SGX? Maybe it'll cost $10 million. You hire a team of 10 top notch engineers or researchers and give them a year. They could probably break it, right? And it's like, okay, well, MEV is so much more than $10 million right now. And it's like, it's worth it to break the SGX.


Anna Rose (00:58:29):


I have a feeling breaking the SGX might be a bit more expensive than that...


Dev Ojha (00:58:32):


It depends on what you mean by break, right? Because what you do is just get the key out of one. And we see like... Or take one.... Get one to be able to do whatever you want.


Sunny Aggarwal  (00:58:43):


Like you just need to break one SGX, that's it. You just need to get the key out of one. And now you're able to deanonymize the entire mempool.


Anna Rose (00:58:51):


Let's shift here, because I want to talk about the threshold cryptography, because that going back to the beginning of the episode, that was like one of the core ideas you had. And something that, as far as I know, is not yet in Osmosis, but it will eventually. Good. Okay. So let's talk about what does that do exactly. And I know, like we don't have too much time in the episode left and I will point people at a video and a talk that you gave recently at a ZKV event that we did. So there is like some other documentation that, but yeah. Tell us how does threshold cryptography actually help with MEV?


Dev Ojha (00:59:26):


Sure. If all transactions are encrypted before they get into a block, then that means if I'm someone on the p2p layer, I can't know what's about to be in a block, therefore or I can't see what the actual content is here, so I can't front run it. I can't do any of this content-aware algorithms, which is what sandwiching is. So if it's fully blind, then gets into a block. Block gets finalized, then it gets decrypted. And decryption process is kind of trustless, I'll get back to that in a second. Then we know that I had no front running, or no relative front running possible. So the flow is then, I spread an encrypted transaction, it gossips around, but the fee part's public. Miners use the fee, check there's a fee enough for this amount of bytes then they get into a block, they encrypt a blob into a block. Block gets finalized, sometime later, transaction gets decrypted and then executed. This prevents anyone from front running me because before it was finalized, all they got to see was an encrypted blob.


Anna Rose (01:00:28):


Yes. And this is this private aspect, adding privacy at the point of... In the mempool, I guess. So that ordering cannot be changed or you can't see something and try to get in front of it. Is it super different when it moves from proof of work to proof of stake? Is there any difference in the proof of stake world for this?


Dev Ojha (01:00:48):


The big difference is around finality. So all proof of work algorithms fundamentally have some probabilistic finality, or you kind of try to overlay some, at some degree, we just call it the probability, especially when negligible and called deterministic. Whereas in the proof of stake world, some chains have guaranteed finality, some don't. So the key thing is, it depends on your solution, but to get like max security, you want it to be decrypted after finalization, but to some extent that's maybe not needed in that, supposed that we have the 1% case happens where got some rollback, okay, yeah...


Sunny Aggarwal  (01:01:25):


It's happened in Ethereum by the way, someone reorged and took something that was like a flashbots bundle. Once it got revealed, they reorged and used it.


Dev Ojha (01:01:35):


And so if it gets sufficiently bad, then you can have this probabilistic finality, someone might say, okay, it's worth it for me to try and attack this, but at least you're still getting protection most of the time. But when you have guaranteed finality, you can kind of make stronger claims that we're always getting it, given our security assumption holds. And then you have multiple solutions for how do you encrypt at the mempool layer? One is SGXs, one is this thing called timelock crypto where it's like, okay, I'm going to make an encrypted transaction, and then anyone trustless-ly can decrypt it after running some sequential process on an ASIC for a few minutes. And the third one, which we think is the best, is threshold decryption, where you have some committee with some weights and they collectively can decrypt the transaction, where we all, two thirds of us come together, do some things together and then we can get the plain text out. And so that assumption is pretty similar to what is the Tendermint proof of stake assumption, which is that, okay, well, if two thirds of nodes, we trust them all collectively or rather we... Yeah, we trust two-thirds collectively to act honestly whereas if they didn't act honestly we could detect it and slash them. So if they make this trust assumption, then we can get this decryption. We trust them to do this properly.


Sunny Aggarwal  (01:02:49):


That's one of the things that the threshold thing is you do need a committee and that's why it makes a lot of sense in Proof of Stake, or at least in Tendermint-esque proof of stake, because we have an obvious committee to give this job to. Timelock probably makes more sense if you don't have a committee to give this to, but Timelock has all of these UX concerns with it where like, you know, you need to make sure the time locking processes are sufficiently long, so that it doesn't get decrypted in the mempool. You need to make sure that like everyone has to be using the timelock crypto. In threshold it's kind of an optional thing, you don't have to. There's no reason... If you don't want to be threshold encrypted, you don't have to. But in Timelock, it doesn't work like that. You need everyone to be using that system, as long as you're okay with having a committee, which obviously we are in Tendermint, threshold is by far the proper way to do it.


Dev Ojha (01:03:35):


Well, as we mentioned earlier, we have to empirically validate like there is extra bandwidth happening. We think, so preliminary thing is we think that the bandwidth is going to be fine, but like, yeah, we do have to wait till we see it. Empiricism does have some value and so that's like, Let's wait till we see that the bandwidth empirically was not a problem.


Tarun Chitra  (01:03:52):


I mean, I think the main thing is just the latency effect to UX, effectively, in the long run. Do you think that's a valid trade-off for the end user?


Dev Ojha (01:04:02):


So it's actually, the latency shouldn't be much worse, given spam assumptions. It shouldn't be much worse than what's going on today on Osmosis. Which is the sense that your block currently is executed after it's finalized, but we can engineer the threshold encryption so that it's done as soon as the block is finalized as well.


Sunny Aggarwal  (01:04:25):


You know, Tendermint already sort of pipelines, where unlike Ethereum...


Tarun Chitra  (01:04:28):


Ah, I see, I see, you're going to overlap the validators voting on the mempool. Do you separate inclusion and ordering? Do they vote separately on like the set of transactions included versus the order?


Sunny Aggarwal  (01:04:41):


No a proposer includes them. And then they just vote on the ordering that the proposer did. So we're actually building something called vote extension, which our team proposed to Tendermint, we're extending the functionality that Tendermint has. And with vote extensions, you can have every validator contribute additional data along with their consensus vote. So this is where the decryption shares are going to be shared. So that's how we have it happen at the same time. And the other one that we also want to do eventually is actually do, you have to help me come up with a better name for this one as well. This was called joint proposals, it's kind of a lame name. We need better name.


Tarun Chitra  (01:05:21):


That's also, instead of being TradFi, it sounds like you're at the Pentagon, the joint staff.


Sunny Aggarwal  (01:05:26):


The joint proposals idea is just saying that every validator can just include a couple of transactions in their vote. And then the next proposer is required to at least include those transactions in their proposal. And then it's okay if they overlap a little bit, but they include those. And then they can add in more if they want, but it's like, they have to at least include the ones that the validators add in. So that way it prevents it, so one proposer isn't the only one who has access to inclusion. All the validators can contribute to inclusion a little bit.


Dev Ojha (01:05:57):


It's actually kind of interesting in the sense of, both in terms of that idea we talked about earlier about there's different proposer powers. Like one of them is choosing absolute order transactions. And the second is for censorship reasons. Like if you have all the validators getting to collectively add things to a block, you now just need... In some real sense, as long as one, at least a third of them, aren't trying to censor you, your transactions should be able to get in.


Sunny Aggarwal  (01:06:10):


Going back to how we define MEV, which is the power that a single proposer has. The way I guess, we think about MEV, and solving it is, move as much of that power to requiring a two thirds threshold. So our threshold decryption is a system that takes, okay, one proposal can't do it, you need two thirds of colluding validators to do something. Or same thing with this joint proposals, right? Like one proposal doesn't control inclusion, you need two thirds of validators to like...


Tarun Chitra  (01:06:50):


Do you think this can ever scale to more than a thousand validators?


Dev Ojha (01:06:56):


There are some inherent like, N-squareds in here. There might become like N Log Ns if we're lucky.


Tarun Chitra  (01:07:03):


Well, I just feel like you have N-squareds, but you're making the constant factor potentially a lot bigger as N gets larger by adding in the ordering.


Anna Rose (01:07:11):


But do you need a thousand validators? Like, is that a goal of the project?


Tarun Chitra  (01:07:16):


Hey, don't read any Eth2 marketing materials.


Sunny Aggarwal  (01:07:20):


Well, the main N-squared is still just in the bandwidth side and the P2P stuff. But as far as I can tell the threshold side, should not have any N-squared?


Dev Ojha (01:07:29):


When you're doing the key setups part.


Sunny Aggarwal  (01:07:31):


Okay. The DKG, yes. The DKG is the hard part. That's sort of we're working with the Anoma team actually to collaborate, to put together like a DKG that will suffice for what we're trying to do. So you're right, the DKG is the bottleneck.


Dev Ojha (01:07:44):


So yeah, that's actually not ordering here, this is given N-squared. If you want to talk about fair ordering, I don't know if you'd want to actually one of my problems with fair ordering is the sense that... Fair ordering doesn't really move you to this two thirds assumption, in the sense that, you're kind of relying on some mempool information to do this, but you have no auditability here where if I lie, no one can detect me lying.


(01:08:09):


It was very hard to detect. They have to assume that just two thirds aren't lying. Whereas in proof of stake, we've come to this two two-thirds assumption because suppose two thirds do act dishonestly, I can make a double sign evidence and slash you, but doing this for fair ordering is actually really complex. You need to dump a lot of data from your... You have to add a lot of extra bandwidth, that's N-squareds again, and for all full nodes as well in order to get these proofs. And it's kind of like why we also dream instead of like fair ordering, maybe it moves random ordering where we try to say a proposer can have some influence of choosing encrypted data within a block, but not even their order. That order's randomized.


Anna Rose (01:08:55):


Osmosis is live. It's been live, as of recording, I know this is going to come out in a few weeks, but as of recording it has been live for about a week. How have you distributed tokens? What does this project look like? And yeah, should people actually know about it? Because I don't know that everyone who has ATOMs knows about this.


Sunny Aggarwal  (01:09:11):


Yup. So, the goal was we wanted this native token and distribute it to all the LPs and people who contributed to the protocol. And this is what... Look at UNI distribution, [?] distribution everyone does this. And they show that okay, look after four years, this is what the decentralized distribution will look like or whatever. But at T equals zero, it's actually extremely centralized where like the team basically owns all the tokens. And that just does not work for proof of stake. Right? Because you need to have a decentralized distribution from T equals zero. And so this is why we did this, like airdrop to ATOM holders to be like, okay, here's your guys' invitation to come be part of Osmosis and contribute, but it also helps us get this distribution.


(01:09:56):


And I don't know, I think it worked really well actually. So I don't know, people keep saying that airdrops are dead, but I don't know, looking at what happened with Osmosis, I don't think that's true. I think it's because of how we did it. So one of the cool things we did was we invented something called a quadratic fairdrop. And so what that means is we actually airdropped to people based off of the square root of the number of coins in their account. So obviously we can't... we couldn't tell people about it beforehand, otherwise people would split, but this was a nice little thing where it's like what we expect is obviously is the ATOM whales are going to be getting the Whale's share of the LP rewards. So we wanted to put more weighted toward the smaller ATOM holders as well. And that's the point of doing that quadratic nature.


Tarun Chitra  (01:10:39):


So maybe this is another sort of a little philosophically question, but do you think it's possible to make a fair distribution mechanism where the issuers don't hide information about the mechanism?


Dev Ojha (01:10:55):


I'm currently pretty sus about this because it almost feels like, if your definition of fair is based off identity, and until there's some really decentralized identity schemes that we trust or reputation networks, then I always have the fear of sybiling or like trying to game the identity system. So until we have identity or reputation numbers that we are pretty happy with, I don't see how you do it for when the definition of fair is based off of are you distinct humans?


Tarun Chitra  (01:11:25):


Right. I just mean like, do you think there's an impossibility result to that?


Sunny Aggarwal  (01:11:28):


I don't know. I actually have not thought about this much, but I think that there's like, what about like off of people's degen score, right? Like you could do an airdrop of...


Tarun Chitra  (01:11:39):


Now you're trusting the Degen score creator though. Who of course is now incentivized to pay for play for Degen scores.


Sunny Aggarwal  (01:11:48):


Right, right, I have to think about it. I've never thought about this question before, and so I think that's...


Tarun Chitra  (01:11:53):


Sorry, it was a little out of left field, but I thought it was like, because you mentioned that you guys purposely hid this so that people wouldn't split, like do all this stuff. It was kind of like, oh, well, if you just make a tiny extension, like maybe it's just impossible to do without doing that.


Dev Ojha (01:12:09):


I think I disagree in the sense that, it depends on what is identity you want to be rewarding or what's fair. Like, I choose some exhibitionally that's easy, like suppose passport holders of some country. And then as long as there's some database I can be used to verify passports, like that would work. It's when we go to decentralized definitions of fair that it gets much harder. But I think if we had some web of trusts model or robust reputation networks.


Sunny Aggarwal  (01:12:36):


There's a tweet sitting in my drafts, which says DEX, front-running resistance, privacy, web of trust, my five-year plan. So...


Tarun Chitra  (01:12:49):


But there's a turtles all the way down recursive question here, which is, can you bootstrap the identity or web of trust without having some secret information or randomness?


Sunny Aggarwal  (01:13:00):


Yeah. So, okay, this is going to go such a derail. So I built a web of trust.


Tarun Chitra  (00:1:12:59):


Sorry, Henrik, in advance.


Sunny Aggarwal  (00:1:13:03):


I built a web of trust at a hackathon like three years ago. And it was like, we won, Haseeb was the judge actually. And he's like, wow, this is a cool. Question, what's the incentives, like, why would anyone do this? And I'm like, good question. I don't know. And it took me like three years to figure it out until, and I solved it when I saw Circles. Circles is Circles UBI. I don't know if you've had them on or...


Anna Rose (00:1:13:25):


No I haven't actually.


Sunny Aggarwal  (00:1:13:25):


Like you should have them on. Coolest project, most underrated. Well, the problem...


Tarun Chitra  (01:13:36):


Well, you had Martin on.


Anna Rose (01:13:39):


From Gnosis, we didn't talk about it. I didn't know he's, I didn't know about that. Okay.


Sunny Aggarwal  (01:13:45):


It's just like a side project, but what it is they built this like this decentralized UBI that's based off of a web of trust, but I think they are too focused on the UBI side of it right now. I don't think what they've realized is that they created an incentivized web of trust and a decentralized incentivized web of trust. And the way that they designed it is they parameterize it in such a way that they're trying to build a UBI. But like, if you re-parameterize it to be this, incentivize early adopters and yada yada, yada, I think you can actually build a proper web of trust, that's very hard to game and I think there's something really cool that can be done there. And that's why the web of trust, I think there's a lot of privacy things that need to go into making web of trust work properly. And that's why it's the last on the list.


Anna Rose (01:14:31):


Okay. What the heck is ION? I feel like everyone's asking. So ION is this token that is in Osmosis and it has a very similar graphical depiction as OSMO, the native token. And no one knows what it is. Do you guys know what it is?


Sunny Aggarwal  (01:14:50):


I don't know what it is either.


Anna Rose (00:1:14:45):


You don't know what it is either.


Sunny Aggarwal  (00:1:14:49):


I don't know what it is either. It just just happened.


Anna Rose (01:15:00):


It just randomly happened? Okay.


Sunny Aggarwal  (01:15:02):


I woke up one day and it's like, wow, I made this Github commit at 4:00 AM. I don't know what I was doing last night, but like, all right. I guess this is a thing now.


Anna Rose (01:15:10):


Oh, really? Okay. So is this, you don't know what it is yet?


Tarun Chitra  (01:15:12):


Look, don't blow up Sunny's spot as a magician, all right? He has some psychological, like I code in my sleep impairments and them he's just like, he just doesn't want the world to know.


Sunny Aggarwal  (01:15:28):


It's really cool to see what the community is going to try to do with it. Like, I think there's like an entire ION community right now. And I think they're trying to figure out, like, what is this thing? How can we... I think there's a lot of people drafting governance proposals for adding utility to IONs, but in a way that's very symbiotic with OSMO as well. And with ATOMs and like, I think there's a... I had this tweet that I tweeted earlier, which was like the father, the son, and the Holy Spirit. It's like ATOMs, OSMO, and ION.  And it's like, what is the Holy Spirit? I spent time... I went through the Wikipedia page yesterday of the holy spirit and I still don't understand what it is.


Tarun Chitra  (01:16:07):


Sunny Aggarwal is going to be a cult leader, and ION is the entry to his cult. You have to own, you must own this much ION to join the Sunny cult


Sunny Aggarwal  (01:16:21):


I'm working with the Commonwealth team right now, the Commonwealth team, they're actually building like a forum for Osmosis, where like LP,  like a pool-specific forum, so people who LP can chat there. But I also ask them to do like, hey, can you make a telegram group that's like limited by who's like, only by ION ownership.


Tarun Chitra  (01:16:41):


If only we had the Telegram Open Network.


Anna Rose (01:16:51):


Yeah. Could have linked in. All right. So Dev, Sunny, Tarun, thanks so much for coming here and having this conversation, exploring Osmosis. This has been super interesting and very excited about the project and congratulations for launching it so smoothly. And I mean, at least from where I was sitting, it looks like it's going really great. So...


Sunny Aggarwal  (00:1:17:02):


It's great.


Dev Ojha (00:1:17:02):


Thank you so much.


Tarun Chitra  (01:17:10):


Yeah, you guys inspired me to write some shit posts.


Anna Rose (01:17:17):


Cool. All right. So I want to say thank you to Andrey, the podcast producer, Henrik, the podcast editor and to our listeners. Thanks for listening.