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:27): This week I chat with Awa co-founder of Anoma and Namada. We talk about her background in crypto analytics, her shift to working on infrastructure and privacy tech and how the Anoma Project came to be. She also introduces us to Namada, a separate but related network. We go through all the various cryptographic pieces that their team has been developing, many of which have been presented at the zkSummit, zkHack, and in our zkStudy Clubs. We then discuss how these fit into Namada and in the future into the Anoma protocol. But before we kick off, I just wanna share an announcement from one of our partners on the latest zkSummit, the Web3 Foundation. They are hosting an in-person event called Sub0 in Lisbon, at the end of this month. It's a Polkadot developer conference. This year's edition will bring together the global Polkadot community and provide an open introduction to those (00:01:16): looking to learn more about Substrate, Polkadot's framework for building custom blockchains. I've added the link in the show notes where you can learn more and apply. I also wanna let you know that there's a new zkHack multi-week event coming up starting on November 22nd. If you haven't been to any of the previous ones, it's a series of workshops spread out over four weeks with puzzle hacking competitions. Be sure to sign up for our kickoff event and jump into ZK puzzle hacking and workshops with us. Now Tanya will share a little bit about this week's sponsor. Tanya (00:01:47): Today's episode is sponsored by Aleo. Aleo is a new layer one 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 ZKPs to deploy decentralized exchanges, hidden information games regulated stable coins and more. Visit leo-lang.org to start building. That's leo-lang.org. You can also join Aleo's incentivized Testnet III by downloading and running a snarkOS node. No signup is necessary to participate. For questions, join their Discord at aleo.org/discord. So thanks again, Aleo. And now here's our episode. Anna Rose (00:02:37): So today I'm here with Awa, co-founder of Anoma and Namada, welcome to the show Awa. Awa Sun Yin (00:02:42): Thanks for having me Anna Rose (00:02:43): I'm very excited to be having you on the show. I've had two of your co-founders on, there's three of you who are co-founders of Anoma and Namada. I've had Christopher Goes, years ago talking about IBC more and Adrian Brink last year telling us about Anoma sort of the first time we talked about it. So yeah, it's great to of have you join as well. I do wanna say right off the bat that I'm an investor in a Anoma long standing through ZK Validator and I also like to consider Anoma this like a team, I constantly partner on so many things like we've done zkSummit, zkHack, you sponsor the show and anyway, it's just really great to have you on and I'm very excited to actually catch up even for my own understanding. There's been so much that's happened since that last episode with Adrian in terms of cryptographic builds and new libraries and announcements. And I think what I wanna do with this episode is generally bring it all together. Before this episode we talked about how you'd never been on the show, but actually Awa, you have been on the show before (00:03:44): So you were on, this is such a funny episode. So I did this episode, the Zcon0 like combo episode where I interviewed 12 people. So I did the same thing with Str4d just recently. There was so many great people on that episode that it's just because we did such small interviews. I think a lot of people don't really remember. I clearly don't remember Awa Sun Yin (00:04:05): I forgot but yes, I was interviewed at Zcon0. I remember that. Yeah. Anna Rose (00:04:09): Yes, but what I wanna do with the beginning of this interview is definitely understand a little bit about your journey. What were you working on before and what led you to actually work on a Anoma and Namada and the problems that you're trying to solve and generally working in the privacy space. Awa Sun Yin (00:04:25): So the way I got started with this entire decentralized space was I guess less common compared to everyone else you have on this show. Actually my first job in the space was in Chainalysis. Maybe some listeners here do not know about Chainalysis, but actually Chainalysis knows a lot about all your listeners for certain. So it was a very interesting introduction to it. What I was doing there was that towards the end of my graduate thesis, I was looking for data sets to analyze. It was back then in ML and I came into just a company called Chainalysis. They were doing developing tools to de-anonymize blockchain. This is basically their business model and I wrote a couple of papers on how you could use ML to de-anonymize Bitcoin. So it was a really cool intro to the space because it made it very clear how much privacy was lacking in the base layers and how much you could do by deploying some basic statistical analysis or not even very fancy tools or algorithms. So extracting a lot of data about individuals and entities that were using blockchains. I kinda wish I could sponsor people to Chainalysis before they touch any blockchain because I think then we will want privacy much quicker or a lot less people will be using this for serious things. Anna Rose (00:05:43): It was almost like that was your first foray in and a major eye opener. It sounds like this also colored a lot of the work that you did after. Tell me, after you left Chainalysis though, what did you do next? Awa Sun Yin (00:05:55): So towards the end I kinda realized that I started to follow more Ethereum. That's how I came across with Cosmos and them back then and I kinda wanted to be more involved in the actual development of the protocols. This is because the thing that motivated me the most about technology that really led me to choose to be more involved with Layer 1s is that I'm into this entire space because I kinda wanna bring in systems and applications that do not further exploitative paradigms that we currently have with, especially in Web2. We have all the systems that basically give a few parties a disproportionate amount of access and disproportionate amount of power and leverage of users individual data or a bunch of other things. And I kinda wanted to pursue a path where I could actually stop building things and contribute to building systems that can bring alternatives to these explorative paradigms. So then I realized that doing data analysis Chainalysis was probably not the most way to have a big impact and then I saw that still the state of protocols was in very early stage. Like back then proof of stake was still theoretical concept. Right. Anna Rose (00:07:12): What year are you talking here? 2017? Awa Sun Yin (00:07:15): Here I'm talking about, it's 2017, beginning of 2018. Anna Rose (00:07:19): I think that's when we met. I think it was right around that time at Full Node that we would've first crossed paths. Awa Sun Yin (00:07:24): That's right. Anna Rose (00:07:25): Had you left the company then, or were you of in the process of leaving? Awa Sun Yin (00:07:28): I was still part of Chainalysis, didn't leave yet until I started to be more involved with Cosmos and then for Cosmos I was involved in pretty limited capacity and part-time where I met Adrian and Chris and then the history follows. Anna Rose (00:07:45): Cool. But before you did Anoma, you did have another project together, the three of you tell me a little bit about being a validator. Awa Sun Yin (00:07:52): Yeah, yeah. The entire thing is that so I met Adrian and Christopher at the Cosmos/Tendermint and in summer 2018 Cosmos was supposed to launch and it was not very clear whether there would be enough competent validators to operate the network at the minute. And this was still, I mean in summer 2018 proof of stake was still a very early concept. Anna Rose (00:08:16): Totally. Awa Sun Yin (00:08:16): It was theoretically going to work. Now nowadays it's completely given all new chains that launch are following the standard of proof of stake. But back then it was not so obvious and there was definitely not a very developed landscape and ecosystem of different validators. So together we kind of decided to start a validator called Cryptium Labs. This is how I also moved to Switzerland and why we picked Switzerland as well. And the anecdote that maybe Adrian skipped is that actually we are the only validator that is kind of considered National Security Critical for Switzerland. Cool. So it is part of the critical infrastructure of a bunch of Swiss banks. So the story is that one day Adrian was going to data center and then he ran into a few tanks. They were just doing some kind of doing some training and testing how they would defend this data center in case something happened. Anna Rose (00:09:11): Whoa. But wait, it wasn't data security just because of what you guys, that you guys were in the data center, was it? There might have been other things there as well. Awa Sun Yin (00:09:20): It was because there are a bunch of national wide critical financial infrastructure Anna Rose (00:09:24): I see Awa Sun Yin (00:09:25): That also uses that data center. Anna Rose (00:09:27): Cool. Awa Sun Yin (00:09:27): And then that was just entire group was being defended and secured by the military. So, that's like the anecdote. But anyways, Cryptium Labs previously validator, it was actually the first organization or company that we started the three of us and it was a proof of stake validator that focused a lot on security over lifeness because this bunch of early things, those things mattered nowadays everything is on AWS and we were the few that actually ran as much physical infrastructure as possible. So bare metal and use as much physical HSMs as possible and we focus on operating networks that we consider technically interesting in novel. So a lot of Layer 1s. Anna Rose (00:10:09): That was a very different time for the validator community though. I mean I've spoken to Brian Crane about that too, which is back when it first started there wasn't really a clear business model. It was just so unsure if this would be something that could be a business that would be sustainable. So a lot of the people doing it were kind of just experimenting, trying it out, seeing how it went. How was that, I mean in your case, were you all still working somewhere else? I know Chris was still doing IBC research and stuff like that at the time Awa Sun Yin (00:10:41): That's right and Adrian was still part of Cosmos. Later on he joined Web3 before being more involved, but I was working on it basically full time. So the end of Cryptium Labs was just that over time it was really cool to be part of operating infrastructure and the networks of Layer 1s. But sometime in the middle we cannot realize that, want to be more involved with more protocol research and also getting more into some areas like cryptography and zero knowledge proofs. Back then, I think 2019 was the kind of explosion of the ZKVs. So by then, for example, specific to that field is when we started Metastate. Anna Rose (00:11:22): And I remember that it was like this is a validator and yet there's this really crypto heavy blog. I actually remember I'd always post it on zkMesh, which I'm gonna plug right now. By the way, zkMesh is a monthly newsletter that's still out where we put the latest research. I'll put a link to that if anyone Awa Sun Yin (00:11:40): That's true. I remember zkMesh did feature some of the articles that we posted on Metastate's Blog, this is the company name. This way for example, PLONK by Hand was one. A very popular one. Anna Rose (00:11:50): Totally but yeah, I remember that and I remember thinking this is an interesting pivot of for a validator. I mean around the same time I started ZK Validator actually and we fully leaned into, we're just promoting, talking about and yeah, championing this new technology. But tell me from Metastate to Heliax maybe, what was that transition? Was it was Cryptium becoming Heliax or was Metastate becoming Heliax in a way? Awa Sun Yin (00:12:20): So actually Cryptium was just a validator and it just stayed that way. We started Metastate as an independent company. Anna Rose (00:12:25): Oh I see. Awa Sun Yin (00:12:26): And the thesis behind Metastate was just that we're not very clear on ahead of time what would be the business model behind Metastate. But we kind of bet on the people who are able to write Layer 1 protocols, build them and operate them and maintain them. Plus that were knowledgeable among three particular fields, which were distributed systems and consensus, PLCs programming languages and cryptography. Especially in the ZKPs, will be able to make money in the future assuming that those four pillars were going to be crucial for any team that in the future will be if all of this is gonna replace financial system, then a team that has this kind of knowledge and expertise will not have issues making any money. So that was the story behind Metastate and our purpose with it. Anna Rose (00:13:15): And did it become Heliax or did you start something new with the learnings from Metastate? Awa Sun Yin (00:13:23): Actually the team that was Metastate towards the end of 2020, officially on the 1st of February was the one that was brought to Heliax. So I think you could consider that Metastate people moved towards Heliax, we started with a team of 15. Anna Rose (00:13:36): Cool. And that group, it was a research group. You were creating content, you're building sort of like this knowledge base talent base in a way. Were you building something then too? Were you already experimenting or was it more like a research group? Awa Sun Yin (00:13:52): No, I actually built all major protocol upgrades on Tezos. Anna Rose (00:13:56): Oh yeah, this is maybe something to mention because that you, Tezos was a strong connecting point. You were really involved in that community after being involved in Cosmos Awa Sun Yin (00:14:04): After. So I think it was more because actually Tezos was the first proof of state network that launched. Anna Rose (00:14:10): Oh yeah, true. Awa Sun Yin (00:14:11): They had a very unique their own proof of stake model, but it did go live in summer 2018. So that's when we started Cryptium. We kinda decided to just operate that to see how it goes. Anna Rose (00:14:23): Got it. Awa Sun Yin (00:14:23): That's how we got connected to the Tezos ecosystem ad we did get some grants from business foundations build on some of the research that they were also interested in. So all the areas and PLC, ZKPs and Consensus that we're doing, they were interested in as well. But at the same time we also worked together with the core development team and built some of the major changes that upgraded life. Anna Rose (00:14:50): Wow. Awa Sun Yin (00:14:50): Keep billing worth of value. Anna Rose (00:14:52): Good experience Awa Sun Yin (00:14:53): Experience on governance process. Anna Rose (00:14:55): Damn. Awa Sun Yin (00:14:56): Yeah, yeah, yeah. Anna Rose (00:14:57): That's wild. Awa Sun Yin (00:14:58): But this is just to show that I think our background is more, it's actually very full stack in the sense of you see a lot of teams nowadays that are stellar in cryptography. You see a lot of teams that are stellar in Layer 1s and some that really still are in application. But I think what's very unique about Heliax as a team is that we have everything from operating networks, from the validator side. So writing, extending Layer 1s, so like application building, like dapps and everything. Anna Rose (00:15:26): Interesting. Awa Sun Yin (00:15:26): And this has also translated a lot into today's Heliax because we're building Heliax as an organization that is vertically integrated. So we are not building only Layer 1, launch it and say now go have fun, build applications interfaces. We actually simulator with Namada for example. It's not just the protocol and then the tooling and everything around ecosystem. It's also being released with at least one end user interface so people don't have to rely on the command line. Anna Rose (00:15:53): Got it. And actually I think it, it's a really good moment for us to define these different groups that we keep kind of mentioning. So when I introduced you, you are the co-founder of Anoma and Namada. So we've mentioned this a little bit but Heliax. So Heliax is a company full of great engineers with all of this experience. What is Anoma today? Just a note, when I had Adrian on a year and a half ago, we talked about Anoma. So how do you define what a Anoma actually is? Awa Sun Yin (00:16:22): So Anoma is the name of the protocol. Anna Rose (00:16:25): Okay. Awa Sun Yin (00:16:26): It is one of the protocols that we building. The other one is Namada, it is also a protocol. So there is no company organization. Anna Rose (00:16:33): Okay. Do they interact, are they connected? Is Anoma going to be, I don't know, some protocol underpinning what Namada does. Awa Sun Yin (00:16:42): So first I'd like to just give an updated definition of where Anoma is just in a higher level. Anna Rose (00:16:46): Sure, sure. Awa Sun Yin (00:16:47): Just to position the entire thing. So actually Anoma is just new novel general architecture to how you build blockchains. We refer to it as a Generation Three. So it's a general architecture it has a lot of association with privacy, but it's actually not a privacy blockchain in that sense. It is just on the privacy side, it allows you to expose really good privacy permits for application developers. But the right way to think about Anoma is that it is just the next evolution in how you're gonna build Layer 1s to later on support applications with different properties. So novel applications cannot build on existing blockchains or the same applications but fully decentralized. Anna Rose (00:17:30): And then at the same time though, would you then categorize this as something like Substrate? Is it the builder or is it like the Cosmos SDK? Awa Sun Yin (00:17:40): No, if we're back in 2015 and we only had Bitcoin protocols and cryptocurrency protocols, we call this group as scriptable settlement. And then Vitalik came and said I can try to do a few cool applications with Bitcoin but honestly it doesn't work. It is all clunky as f**k and this is just not usable. So here I proposed Ethereum, which is just a new way of building blockchains. So Anoma it is the same, but today Anoma is just building, is just proposing a new way of thinking about how you build the base layer on top of which you can build applications. But it is, Anna Rose (00:18:16): Is it of the way Bitcoin goes from UTXO to account model? Are you going from account model to new account model or privacy account model? Awa Sun Yin (00:18:24): No. So actually the right progression, I'm just gonna tell you an entire evolution of protocols in a nutshell I think is that we look at the first generation marked by Bitcoin as scriptable settlement. So scriptable settlement is actually really good for building cryptocurrencies with different flavors and privacy guarantees . Like with that you see Monero, Zcash, a bunch of cool stuff, but all people don't know in history is that with Bitcoin script you can actually build other dapps and applications like color coins, name coin, beacon stock change. However the issue is that so you can build it and it works. But the issue is that applications will always have trade offs and they will always look clunky, hard to use. So actually Vitalik speaks about this problem in the Ethereum white paper and that gave the room for him to introduce entire new paradigm, which is what we call programmable settlement. (00:19:23): So it is adds more specificity and you're able to program more logic at the settlement layer and this is what gives birth to better versions to offer color coin, which is the modern ERC-20 or it's name coin, which is the modern ENS, way more usable, way more widespread, right? And it also gave birth to a new era of new applications that it was way too hard to build on the scriptable settlement, maybe impossible. And those are things like NFTs, DEXs, AMM, and NFT marketplaces, DAOs, alot of very interesting applications that you see today. And then ever since Ethereum, if you look into all the Layer 1s that were launch ever since, we call them basically programmable settlement++. And this is because if you look at them in essence the model that they introduce for application developers is still the same. It's still this imperative model. Smart contracts called differently but it's the same but they come with different improvements in some particular areas. Like it's faster, it's more scalable in some areas it is more private, comes with different consensus, different civil resistance mechanisms switch from proof of work to proof of stake. But if you look at them and also the applications they built today, they're basically the same. (00:20:38): So this is why you consider everything ever since the Ethereum launch as programmable settlement++. Anna Rose (00:20:43): Okay. And what is Anoma doing different? And maybe you wanted to clarify that because it does it use as sort of UTXO type model but does it better? Awa Sun Yin (00:20:53): That is actually not so important. The background to why Anoma is the third generation is that how we got Anoma, how we got to today's architecture of Anoma. And it is because we looked at some of the most advanced applications in Ethereum world but it generalizes to any other programmable settlement plus plus applications is that they all follow a similar pattern. And you will also see that it has a bunch of downsides, a lot of centralization points. So every application in Ethereum, think of for example all the, Layers 2s think of CoW Swap, think of OpenSea, the NFT marketplace, they all follow the pattern where the user has an intent. So an intent is just a sign message that they send somehow to the application, the same transaction on authorization. That intent is scattered by at the moment a lot of applications make this feasible by a single operator database. That usually becomes centralization point that does some kind of compute to output a state transition on Ethereum. And that gets finally settled on Ethereum (00:21:59): So this is the common pattern of most interesting applications on Ethereum that at the moment the best you can do is to follow this thing where you have the single operator database that gathers the intents, it doesn't compute. That becomes actually the centralization point and chip point and it comes with all the issues. It kind of becomes the version point with this entire technology but there are currently two parts where you either go for the DYDX approach, where you choose launch Layer 1 to decentralize just that part which comes with a lot of complexity but it is a easy way to fix today the problem or go for the other approach where you are ready to operate a very large organization like Conveys and everything. And I guess OpenSea might go for that approach as well. But the main point is that how does Anoma fit into all of this and actually this is the background of how we came to the conclusion - what do applications need before they need a blockchain? And the main point is that if you wanna do kind of party discovery, so any application that needs party discovery where you do not yet know who your other parties are and what it is you're settling with, this is needed for basically any application including DEXs and marketplaces. Anna Rose (00:23:19): Does it affect your ability to do an intention the way you describe that? Because you don't know who your counterparty is. Awa Sun Yin (00:23:25): So today there is no way of doing the centralized kind of party outside of you have always a trusted party where you're sending intents and they're gonna try to do so that Anna Rose (00:23:35): Busy and here you're thinking an order book a little bit like you say I want to buy this at this amount and you're waiting for someone to sell it to you at that amount. Awa Sun Yin (00:23:44): Not exactly. So I'm gonna get that to those design principles in a bit. But the main point of Anoma and why we think of it as the third generation is primarily that it is one architecture. Think of it as Ethereum, but it's just a different protocol at many levels in how it's constructed. And this protocol has the band that allows you to do a decentralized kind of party discovery. It supports intents, the centralized kind of party of discovery, distribute solving, and multi chain settlement. So it also has the settlement part. Anna Rose (00:24:17): So it is, it's just a different way of thinking about it. Decentralized counterparty discovery. It's sort of introducing almost like a different paradigm on how you would then build applications on top of it. Awa Sun Yin (00:24:28): Correct. Anna Rose (00:24:28): You have these different tools. Okay, now I have to ask, is Namada not using that too? Is it not using these principles or is it just tackling a different problem? Awa Sun Yin (00:24:39): So actually Anoma is an architecture for applications, but we kind of realized that early this year. So the story of why we decided to actually release Namada sooner is because there are some parts of Anoma component wise think of Tiger And some audit components that were still in development and there were also a lot of features that were already ready that we could just deployed into an application or into a Layer 1 that could provide a lot of utility today and there are a lot of parts, for example the base ledger, the valid predicate system, especially the MASP, the entire thing that allows the asset diagnostic part. A lot of these things actually were ready and we really wanted to launch Namada sooner. Anna Rose (00:25:27): Okay. Awa Sun Yin (00:25:27): Just because we need a protocol that allows you to gain privacy without caring about what assets you use as a monetary policy. Now more than ever, especially with the recent events. Anna Rose (00:25:39): Let me rephrase what I think you're saying here is you've been building and we're gonna talk about this, a bunch of different cryptography pieces. We haven't always understood how they fit together when they've been released. Awa Sun Yin (00:25:50): Right. Anna Rose (00:25:51): It would be great research papers, very interesting. But we're like okay, why exactly are they doing that? So now what you're saying is you have a few of those pieces in a state where you could release something but you don't necessarily have all the pieces you would need to build out full Anoma. Is this true? Awa Sun Yin (00:26:05): As of today? Anna Rose (00:26:07): Okay, so is then, is Namada sort of your canary network then? Is it like your first and then there's gonna be another one or? Awa Sun Yin (00:26:13): The thing about Namada is that I think the closest case in Layer 1s world is Polkadot with Kusama but it is actually different because Namada is only one with its own scope future set, which is a proof of stake protocol that provides interchain asset diagnostic privacy, so that's the purpose of Namada. It did start from a early version of Anoma. It does come with some features that developers if they look closely, it's basically introduction or stepping stone towards Anoma in the future. However, Namada is gonna just leave as its own chain. It would not have an upgrade path necessarily to Anoma. However it will be really a more intuitive and more immediate introduction. So a lot of concepts that later on will be useful to descend Anoma, practically speaking, looking at how the landscape is today with users, especially if it's some aspects around interoperability like cross change transfers and all these things, IVC and bridges, a lot of bridge exploits. (00:27:18): I kind feel like we're still early stages, even with concepts that we've been talking about for years by now. So I kinda feel like we need to launch a network as well where you prove that there are better designs for Ethereum bridges and there are good ways of leveraging great protocols like ABC for applications to get on other blockchains that you cannot get on the base chain. So I think of Namada as a more intuitive immediate entry point to a lot of these concepts of interoperability but also protocols that are asset diagnostics. So it doesn't matter what the native assets are, it's more about the protocol provides you utility and then you decide which assets wanna benefit from privacy or Anna Rose (00:28:04): And I guess I think we're gonna get into this a little bit later, but because it's a privacy focused project and because it's dealing in interoperability and privacy, you are trying to build up in a way that shielded pool, the candidates, the participants, the assets that live in the sort of shielded environment. Because the more that's in there, the less easy it is to figure out who's who. Is that also part of it? Did you feel like this Awa Sun Yin (00:28:30): This is part of Namada Anna Rose (00:28:31): Yeah. Is that why? But that's what I'm wondering. Did you of feel like if we don't start building this up, if we wait until everything's perfect and release it, you're gonna have to start then to build up those type of pools? Awa Sun Yin (00:28:41): Actually no. It's quite independent. Like so if you need to take away two major features that Namada brings to the table today that no really no other protocols brought so far. The first one is just idea that all assets share one anonymity set. This is enabled by the MASP plus two upgrades that include the convert circuit and this allows you to have one shield set for anything including doesn't matter with the denomination and the origin of the asset. So think of initial set, the native asset tokens from Cosmos, tokens from Osmosis, from Ethereum, NFTs, they all will be part of the same set. So this what means is that the anonymity set will not be weakened or fragmented and then the privacy guarantees are going to be the same for all assets. Because the issue that you have with when you do not have something like a unified shield set is that if your asset has very low transactional volume, it is actually quite trivial to anonymize it by just monitoring the entries and exits. So the limit, this is very small, but if all assets share the same then an NFT that has low volume looks the same as a transaction that pays gases, Anna Rose (00:29:58): Although it's always at the movement outside of the shielded environment that becomes the problem. Awa Sun Yin (00:30:03): That's correct. So this is a downside would be just that they point to the shield set so Namada, that will still be transparent and then if the origin chain is transparent, which is the case for most Layer 1s, then that also becomes where a place where it can observe can get a lot of information. But if you interact within the shield set, so as long as making a shielded set, people will not be able to connect once they exit unless you do some kind of a usability error or you send it to the same account on Ethereum or something like that. So that linkability is broken and as long as you are within the shielded set, which can also just use to do any kind transactions with all the assets in the shielded set, then won't be, no transaction graph will just be removed. Anna Rose (00:30:50): Do you imagine actually any computation happening within that space though in Namada? Awa Sun Yin (00:30:55): As in just like arbitrary computation? Anna Rose (00:30:57): Yeah. Or is it more for the transfer, more for the pool? Awa Sun Yin (00:31:01): So it is possible actually some interesting application that we have been experimenting with recently, and this was inspired by a conversation that Christopher Goes had with Dev Ojha from Osmosis is that actually Namada is a protocol and we are not releasing this with version one, but this is really cool and we could do this, is that you can actually use Namada to as frontend to create shielded actions on auto networks. Anna Rose (00:31:29): Ooh, because it's IBC enabled, maybe because Awa Sun Yin (00:31:32): It's IBC enabled, you have a shield report, assets are already there, there's no linkability for there's going to be, so for example and this is how you work with Osmosis, the way you would use this is that imagine that you wanna do a trade on Osmosis and Osmosis is transparent change. So everything that happens there is kept transparent. But what you can do is via Namada, the shielded pool, you can authorize an action of trade those two assets on Osmosis and then this package gets transmitted over IBC to Osmosis, that trade happens and it gets back to the shielded pool Anna Rose (00:32:11): Just the info that it happened, just a message that it has happened or some sort of token Awa Sun Yin (00:32:17): In this case it'll be for example the tokens the initial token say a sheided die on the Namada wants to be swapped for Osmo on Osmosis. Then the shielded die is sent from Namada to Osmosis by in this case, does Osmosis support die? Just think of Ethereum then I'm not sure if Osmosis supports die. But anyways you wanna try DIE for USCC. So you have already in a precept whole die on Namada and this is the shielded set. So it's fully privates with that account you authorize a trade on Ethereum. So this DEX application in Ethereum that allows you to trade die for USDC. But you trigger the action by sending the message on Namada that that is being transmitted by the trustless Ethereum bridge that we built and that triggers the action on Ethereum. Then the results in the USDC that you send back so you can in the shielded pool Anna Rose (00:33:12): and it gets shielded again on that return but nobody knows kind of the Awa Sun Yin (00:33:17): There's no linkability. Even if you get, you can see how much USDC is being swapped for die on Ethereum. That's transparent and you can also see that there's some USDC being moved over the bridge to Namada going to the shield . This is a really cool application to build using Namada. This is more to answer question of at the moment we don't think we're gonna make, you can make validity predicates to Namada but I think the main purpose is to focus on in the chain asset diagnostic privacy. So start with getting people used to the idea that assets can be the couple from protocols, you can get privacy without having to buy into the monetary policy. You can use, pay for your milk privately, even if you don't need privacy on milk using SEC or Bitcoin no matter how much we love SEC. Anna Rose (00:34:04): Yeah fair. One thing we sort of hinted at, but we didn't go through yet, is the different pieces of cryptography that have been developed. And I kind of want to ask you as we go through this, which parts are in Namada and which maybe all of them are but and also a little go bit into them. Awa Sun Yin (00:34:22): Not all of them are. Anna Rose (00:34:22): Oh not all of them are not, okay Awa Sun Yin (00:34:23): Yeah. Anna Rose (00:34:24): So I wanna start with one VampIR Joshua Fitzgerald is that, I think that's how you say his name, right? Awa Sun Yin (00:34:31): Yes. Anna Rose (00:34:31): Okay. Joshua Fitzgerald had presented this at zkSummit7 in Amsterdam and I remember because there's a lot of awesome names that come out of the Anoma and Namada and so there's Awa Sun Yin (00:34:45): There reason why we named some components of artists and VampIR is definitely one that's gonna keep its name. Anna Rose (00:34:50): So VampIR, let's talk about what that is. So t's a language right and I kind of wondered is it a DSL for writing? Awa Sun Yin (00:34:58): It is, not exactly. Anna Rose (00:35:01): Okay. Awa Sun Yin (00:35:01): So a way we can look at this and then some people from might kill me because it depends of which abstraction you take from what part. But you on one hand have DSLs and higher level languages through which you can write circuits, that's it. So think of example, so think of Circom like lot of high level languages and DSL. I think Leo will still be from Aleo will also be part of this category. And then you have end-to-end proof systems like PLONK, RiscV etc and in the middle sits VampIR. So VampIR is the intermediate representation that allows you to basically transform the higher level languages in DSLs. It is something that any proof system can understand. Anna Rose (00:35:46): So it's not native just to the kind of circuits that you're using then? Awa Sun Yin (00:35:52): No. So VampIR and this is why we want it to have its own name and its own memes and brand is completely agnostic. So we build it in a way as we thought that it would be really high leverage to bring in this part of the entire tooling for writing circuits and ZKP world because there is just no standard. And by having this, it would allow us to basically make all higher level languages be able to compile down to different proof systems independent of what proof systems available today and in the future. So it is completely intended to be a kind of standard but a neutral tool that all ecosystems, languages, and builders can fully benefit from. Anna Rose (00:36:34): Got it. Do you have a DSL as well or would you imagine people writing, I don't know if they have to, but if they're trying to write the circuits in your system, would they then use a different DSL? Could they use Leo and VampIR? Awa Sun Yin (00:36:51): So we are for the full vertical integration for just because applications on Anoma don't look the same as applications on programmable settlement architectures. We actually are building a high level language called Juvix. I think you guys have spoken about this on a different podcast. Anna Rose (00:37:07): Yes. Awa Sun Yin (00:37:07): It didn't make a lot of sense, but the way Juvix integrates is Juvix is a high level language for writing applications on Anoma. Anna Rose (00:37:14): I see. Awa Sun Yin (00:37:15): So it's for all kinds of applications ones that handle private state or not private state, whatever, transparent state. Anna Rose (00:37:21): So you would write in Juvix and then VampIR would convert it or would you not need VampIR? Awa Sun Yin (00:37:27): That's right Anna Rose (00:37:27): Oh you do need, Awa Sun Yin (00:37:27): No you would, it's integrated with VampIR. Anna Rose (00:37:29): Okay. Awa Sun Yin (00:37:30): So if you want to write certain applications that require, for example custom circuits you will be able to do that directly on Juvix as a higher level language. Then goes for VampIR and then it gets compiled onto the corresponding proof system as the application needs. Anna Rose (00:37:46): The next thing I wanna ask about is Taiga, I actually have the name and I have no notes because I don't know anything about it. What is Taiga? Awa Sun Yin (00:37:54): Yeah, yeah, yeah. So Taiga is actually the unified execution environment of Anoma. Think of it as the state machine of Anoma. Anna Rose (00:38:03): Does Namada have that or not? Awa Sun Yin (00:38:06): No, Namada does not come with Taiga. Anna Rose (00:38:07): Okay. So Tiger is a Anoma only actually going back. Juvix would be used for and VampIR. Would that be for both Anoma and Namada? Awa Sun Yin (00:38:15): So for Namada we actually don't need it. Anna Rose (00:38:18): Okay. Awa Sun Yin (00:38:18): Because the circuit has been written as the MESP circuit and we just have been upgrading it. We didn't use it, for parts of it I often compared to and . Anna Rose (00:38:30): Okay. Awa Sun Yin (00:38:32): So just a little bit background, sorry. Why Taiga and how it relates to Anoma, why specific to Anomas architecture? Anoma's architecture has this unique design principle which is it is intent-centric. So users do not sign transactions, users sign which end state they will be happy with. And that end state can be a fixed value, it can be ranges, can be whatever, but they do not preauthorize an execution trace, which is what you do with Ethereum program or settlement architectures. So the only sign for it, I'm happy with a state where I have minus a thousand Eth and plus one Bitcoin. This is what an intent is. Anna Rose (00:39:09): It's not derivative though, is it? It's Awa Sun Yin (00:39:13): Hmm Anna Rose (00:39:13): Well cbeause that idea of the range and the wish, it's like it's often, I just think of derivatives as a bet on the future. It hitting a certain moment and then something happens. Awa Sun Yin (00:39:23): You can totally build applications like that using the intents system is actually gonna be much better to use intents system that how currently some of these derivative marketplace and applications are built. But the main point is that, so that is a big part of how we designed Anoma and there is no other protocol that is intent based at the moment. Anna Rose (00:39:45): Oh interesting. Awa Sun Yin (00:39:46): And how that relates Taiga is that, So we want intent sto be able to be fully private and also fully transparent depending on the application. And we look at it as when you define an intent, if it's fully transparent, then this is just wasm code, it gets executed, it gets wasm, you don't need fancy cryptography for that. But there will be applications which will require different privacy levels for the same application. So at the moment with Taiga we will be able to support transparent, shielded and in the future private intents, the transparent intents, I just like you can read what the contents are, but the shielded intents, the who is kept private, but the what is kept transparent and the best one can do with the ZKPs at the moment. Anna Rose (00:40:33): But you just said that this private one, is there one where both are kept private or no? Awa Sun Yin (00:40:37): That's right. But that relies on some fancy fully homomorphic encryption and we are looking into how long it will take until that is actually usable in the system. But there's actually a lot of things you can already build with the combining transparent and shielded site and that relates to Taiga. So Taiga is able to basically take intents no matter what part is transpareny or private and then execute those. So the background of Tiger is not what is fully transparent, let's make it fully private or you shield it. The background of Taiga is what do application builders need. And for some applications like a Dow, you will need part of it to be transparent. Think of for example the results of the tallying of a latest vote but parts of it to be fully private for example, the individual's votes, they don't need to be transparent. Anna Rose (00:41:29): Interesting. Okay. I wanna keep moving on to another project Ferveo, a DKG protocol. Awa Sun Yin (00:41:36): Yes. Anna Rose (00:41:36): Where does that fit in and is it in Anoma and Namada or only Anoma? Awa Sun Yin (00:41:41): This can be in both. Anna Rose (00:41:42): Okay. Awa Sun Yin (00:41:42): Yeah, so on Anoma, and this relates as well to this entire thing about architecture. Ferveo is just a mechanism that the protocol exposures application builders that makes it really easy to do programmable batching and a bunch of other properties. For example, the fresh encryption scheme just removes the ability for validators observers of the main pool, the transaction main pool to basically do MEV or front running because they gain access to that information ahead of time. So Ferveo on Anaoma is two things I thing that most the ability for validators to do MEV or people who observe the transaction main pool. Here MEV will refer to the MEV that you can get by gaining access to information ahead of others. So this informational asymmetry. And the other part is that it allows you to do other cool things like say for an application, I want a batch to be this many blocks. This is cool for billing applications that allow you to, for example, CoW Swap on Anoma benefits a lot from batches. Any application that where you wanna gather for example votes or you wanna gather bits from an auction, benefits from this kind of batching where you're gonna keep the intents from the users encrypted on the blockchain but encrypted and the only gonna get encrypted at the same time depending on how long the batch is. The only implementation that I know of that's closest to be released on a Layer 1 is Ferveo, which is our implementation. And the paper was sort released this year. It was a collaboration between Joe and Dev, (00:43:24): But we were, the team actually Ferveo was started at Metastate and not at Heliax and we just continued building it. So to my knowledge it's the only implementation of this kind ofscheme that allows you to prevent MEV from validators and observers of the transaction main pool. Anna Rose (00:43:38): So how built is that? You're saying it's already gonna be used in Namada, is it finished? Awa Sun Yin (00:43:45): So I'm not going to confirm that but Namada, we are probably gonna leave it out for a protocol outbreak for Namada at the minute. This is mostly not because Ferveo is not ready as a mechanism, it's actually because the mechanism is implemented on very closely with consensus and there is a part on Namada that relies on AVCI. So this is tended in core stack that is not ready and so we were thinking of this is the point Ferveo in the future protocol outbreak of Nadama. Anna Rose (00:44:15): So you talked about batching and helping prevent MEV or change MEV basically. But first of all, what is it and how is it working in this context? Awa Sun Yin (00:44:24): The intuition is the following. So when you have transactions, they all go to the main pool. So far all transactions are just transparent. Anyone who just takes a look into the current main pools of any blockchain, they can see a lot of stuff in there. And that information can be front run. So for example, before you , then you look into what transactions are available, you reorder them in the way that benefits you the most and everything. So the way Ferveo removes that ability is that transactions before they make it into the main pool, they are encrypted against validators public keys. Anna Rose (00:45:04): What you're talk, I mean I talked about this with Dave and Sonny in our interview on Osmosis, we talked about this decryption and I sort of understood all that, but why are we using the term DKG for this? Because like to me that distributed key generation, it's breaking up a key into multiple things. So this is where I get kind of confused. Awa Sun Yin (00:45:25): This is just an component in the protocol and this is closest to DKG protocols, but I wouldn't know why we're using this otherwise. So Ferveo has two parts. One part is the DKG protocol part and the other part is the threshold encryption part Anna Rose (00:45:42): Oh, I see. Okay. There's something in the technique maybe that's using Awa Sun Yin (00:45:46): Yeah, yeah. But I'm sure DKG is a family of protocols within cryptography that's not only used specific to Ferveo and from running protection and stuff like that because your protocols also used in auto schemes for auto applications. Anna Rose (00:46:01): I see. You just mentioned a trustless bridge to Ethereum, right? Are you doing work on bridges? Is this, I mean Chris having worked on IBC, I feel like I think when I had him on last we talked about what would private bridges look like. Very theoretical, but yeah, are you working on that? Is that part of the sort of strategy of Anoma and Namada to have that? Awa Sun Yin (00:46:25): Yeah. So different first versions of Anoma will benefit from users can transfer their assets from auto chains to Anoma and then they'll just benefit from the kind of features and that exposes. With Namada, this is actually more straightforward. We actually need this because we are not presenting Namada as a chain that creates new assets. It's more about when you have assets that are created in auto transparent change, how do you retro feed privacy? How do you benefit from the privacy of Namada independent of what assets you wanna hold, you wanna use? So in order to make that possible in today's world for any chain that supports modern fast finality and BFD chains, think of for example, any chain that is still used in the customers is the key supports IBC. So that's compatible with the IBC protocol and that is actually the most preferred design for how you do bridging because it just has almost, you do not have any trust assumptions. Even on the layers. Anna Rose (00:47:26): This is the cryptographic bridge, straight up both sides have clients. Awa Sun Yin (00:47:31): You don't even need use a cave bridge for any of this. You basically just have a client on both sides, that's it. So that would be the best. But sadly not all chain that are used today with a lot of assets support fast finality. So an example for that is Ethereum. And the goal was that we really wanted to make privacy accessible for all the people who are using Ethereum and have holding out wholly different tokens, including NFTs in Ethereum. So we looked at the different propositions of bridge signs and there's a lot of things that Namada and Axelar , there's a lot of bridge constructions out there, but we actually decided to build our own. This is a custom bridge design because once prioritize the security for the end user assurance for the people who use this bridge above everything else. And it actually doesn't come at a huge, the transaction system really fast. The E doesn't really come on with a latest trade off. So this bridge designed on a high level, the way it works is that value leaders on Namada will also have to operate a full node on Ethereum. Anna Rose (00:48:41): I see. Is the reason that you decided to build your own a result of some of the hacks that happened in the last year, was it sort of instead of working with a partner that maybe you have a little bit less control over, you would wanna build it yourself? Or was it more just that efficiency or that customization that you wanted? Awa Sun Yin (00:49:01): We would've made the decision regardless of the exploits. Exploits were predictable to be honest. But the issues in a higher level with the issue that you have when you use something like Namada or Alexar is that you do not have control of what happens in event of an next point. You do not have any control of what happens in there. And these are usually operated by another entity. So adds another layer of security through which the users have to reason through and if anything happens, how does the buckets get fixed, how does it get upgraded? They can at any point add arbitrary controls or it freezes assets over the bridge. This just adds a lot more complexity to the end user and allows us to, it removes a lot of our ability to add extra security guarantees. Anna Rose (00:49:56): What do you have to build to actually build this? What are you building? Awa Sun Yin (00:50:00): Oh, the Ethereum bridge. Anna Rose (00:50:01): Yeah. Do you have to build an Ethereum something on the Ethereum side? Awa Sun Yin (00:50:04): We have to deploy a bunch of smart contracts in Ethereum too. Anna Rose (00:50:06): Okay. Awa Sun Yin (00:50:06): Yeah. And then the bridge protocol is a bunch of Rust code and integrated with Namada, and we can also use it later for Anoma. Anna Rose (00:50:15): Okay. Awa Sun Yin (00:50:15): So once it's built, it's kind of cool and this design is actually generalizable to bridge into auto protocols. So I think the design is actually very similar to, we propose you may not know this, we actually proposed a bridge to Zcash. Anna Rose (00:50:30): Oh yeah. Awa Sun Yin (00:50:31): It was published on Zcash and Z cash forum, something like that Anna Rose (00:50:35): I think Chris mentioned this at the zkSummit8 actually. Awa Sun Yin (00:50:38): Oh yeah Anna Rose (00:50:39): Who also gave a talk. I'll also link that in the show notes and stuff, but Awa Sun Yin (00:50:42): Cool. Anna Rose (00:50:42): Okay. So they'd have to build it though. In that case they'd have to build the bridge part. Awa Sun Yin (00:50:48): We could build it ourselves Anna Rose (00:50:49): Or you could build it yourself. But in their case there's no smart contract platform. It's not like you can trustlessly deploy it. Awa Sun Yin (00:50:55): Actually, that's a good point. I think for Zcash would be a little bit different. But for example, for any other chain that is programmable settlement, that does not support IBC, then we could build something very similar to what we build for Ethereum. Anna Rose (00:51:07): Interesting. Awa Sun Yin (00:51:07): Just enable the bridge Anna Rose (00:51:08): In the case of the Ethereum one, are you acting then as a bit of a roll up, are you a privacy roll up? I love those words. Keep blending together Awa Sun Yin (00:51:19): Once shielded actions are enabled. It's basically a shielded roll up. Anna Rose (00:51:24): Okay. Awa Sun Yin (00:51:25): But it's not, it actually provided privacy. Yeah. It's not like a ZK roll up in the sense of ZK roll up actually provide you a lot of scalability, but it's not so much privacy. Anna Rose (00:51:34): This is now leading me to also digging more into Namada and that's what I want to do next because I wanna talk about the multi-asset shielded pool and Namada and the rollout and all that stuff. But now I'm curious, you would sort of mention that it won't have or a Anoma is the whole thing, consensus execution, all of that. Does Namada have its own consensus? Awa Sun Yin (00:51:56): Namada uses just modern BFT kind of main consensus. It does use a really novel proof of stake mechanism. So it comes with a bunch of innovations around, for example, how diffuse are distributed. It follows an advanced version of the F1P distribution model. It allows you to when you receive purpose rewards, you do not have to withdraw them and then restate them because that creates a lot of transactional spam. It just like the protocol, just like auto compounds it unless you wanna unbond them and then do something with it Anna Rose (00:52:28): Okay. But there will be a full validator set for Namada. Awa Sun Yin (00:52:32): Oh yeah. It's a purposefully easy one. Anna Rose (00:52:35): Okay. So then that way it's maybe a little different than some of the roll ups, which are relying on Ethereum as their shared security. In this case it isn't. Awa Sun Yin (00:52:44): Namada is Layer 1 but with a specific purpose. But Anoma is more a general architecture for building depths. However, it is one architecture where it is agnostic how you deploy it. So when we are building easily one part, we're not aim deploy Layer 1, but you can actually leverage Anoma as Layer 1.5 or leverage Anoma as a Layer 2 on Ethereum. For example, Anna Rose (00:53:07): If you just do have to just strip out, you don't need the consensus then Awa Sun Yin (00:53:10): No, no. You don't have to strip out anything. Anna Rose (00:53:12): Oh Awa Sun Yin (00:53:13): You just can, It really depends on what it is the application wants. So Layer 1 would be just in an intent would just start and then die at the end. I mean finish be finalized and settle on Anoma. Right? Fully on chain from beginning from the intented cell. It makes its circumstances and it's fully written ledger. So that would be Anoma as a Layer 1. Layer 1.5 is think of it as if you want application like OpenSea, Bitcoin, CoW Swap, you want to decentralize a very specific component. In the case of related to using the sequencer. That's usually what's centralized in the case of CoW Swap is you wanna make the solvers permission less. So you don't wanna be that the party, the in the case of OpenSea, you wanna decentralized entire part of counterpart discovery how trades which trades are made and matched. (00:54:03): In the case of Bitcoin, you wanna decentralize a lot of things because at the moment the sad thing about programmable settlement is that really cool applications and crowded funding is what Bitcoin offers. A big part of it, is happens and only the final payments from the get the settlement, the theory. Right. That's a shame, for such a beautiful application. So in this case Bitcoin, you will be able to build your QF but fully decentralized. So if your applications that you just want to decentralize a certain part or benefit from Anoma for a specific component of the application, then the way you would use this is that you use Anoma until it trades a transaction for Ethereum and then that transaction makes it to get settled there via the Ethereum bridge. So that would be Anoma's Layer 1.5. Anna Rose (00:54:52): Okay. Going to a Anoma as Layer 2. But then do you still, because I always think of L2s, I mean I know they have committees and sequencers and stuff like that, but they don't need the full validator sets. Right? Awa Sun Yin (00:55:06): So L2s only make sense if you want to rent a Ethereum security in the case of Anoma's Layer 1.5, the transaction still gets settled on Ethereum. But if you wanted to rent the security, what that means is that you trust Ethereum's validators or miners more than you trust all of the chains. And Anoma as related to Ethereum and the way you look like is that it allows, it comes with the verifier of the entire state transition that happened on Anoma, but that only makes sense for if you wanna rent Ethereum security. I think there's a lot of confusion around what L2s are for and what they really give you. And I think that the most compelling case for applications like Anoma and why it would make sense to use Layer 2 to is really if you wanted to get the extra security guarantees of Ethereum to verify the state as actually valid. But you can do that. Anna Rose (00:56:05): Right. I wanna do a little bit more on Namada. I mean we've definitely talked a lot about the pieces that are making up Namada, but the part we didn't go that deep into yet is the multi-asset shielded pool and ASP. I mean, I guess we did talk about it maybe early on, but I think that's the thing that I think people are gonna be able to play with already and we can talk maybe a bit about the values and the ideas that it's trying to actually promote by existing and I think that was, if I think back to earlier, the earlier episode I did with Adrian, I think that was the primary thing that we talked about. It was this multi-asset, the bartering system. Awa Sun Yin (00:56:47): I listen to that episode and I thought, well, Adrian basically pitched Namada just back then. But yes, the applications, the entire things that he mentioned today would just be example applications you can build using Anoma but this entire asset agnostic world, multi chain world with privacy, that is completely brought up to you with Namada. Anna Rose (00:57:11): All right. So let's talk a little bit about this multi-asset shielded pool. What is that? And we're gonna define it now, but it's kind of already been defined in the episode, but what does that look like for user? Awa Sun Yin (00:57:23): So the multi-asset shielded pool is, cryptography wise, it is a custom circuit and it has been upgraded a couple times to enable a bunch of other features on it. Anna Rose (00:57:32): And this is based on Sapling, right? This is a custom Awa Sun Yin (00:57:34): Yes. The initial version, the initial code base was Sapling, and then we just customized it two more times on this to, on one hand, what means it means for the user is that when you make sheiled transfers on Namada, all these assets will be sharing the same shielded set. It's this analogous set, anonymity set. So when you make a shield transfer with the non native token or with a crypto kitty, or with die used to say with Atoms or Osmo, it will all look indistinguishable from any other transaction. And this is an important property so that you do not lose privacy guarantees in case you are transacting with an asset that is very unique or has low volume. So for example, some NFTs, there's just so many of them, or they're pretty unique, actually so in those cases, one transfer in the multi-asset shielded pool in the shielded set actually benefits from the same guarantees as any other transfer. Anna Rose (00:58:38): Having watched the, and I, again, I'm gonna add this in the show notes, but I watched Chris's talk at ZK Summit 8 and there he kind of talked about the way that you define these different objects in the multi-asset shielded pool. It's just by, you have basically a new category of type of token. Awa Sun Yin (00:58:56): Oh yeah. That's a technicality on how the circuit works. Anna Rose (00:58:59): But what I don't understand is with an NFT, is each one a unique token or what if it's an NFT and a set? Because if you think about it, you need a price, like a floor price for the set in a way. I got confused on that one. Awa Sun Yin (00:59:14): So the way things, maybe the unintuitive part is actually within the shielded set, there is a UTXO model that keeps track of the assets, but it doesn't care about the denominations of the assets. So the asset type part is a big change in MSP. Anna Rose (00:59:31): And I think another thing that came to my mind, and this it speaks to the same question though. It's the Oracle, how do you define prices of these different assets that are coming into this space? If there's a full marketplace within it and things are being swapped and intentions like, Awa Sun Yin (00:59:49): Oh, so you cannot actually do anything further than transferring in the issue that's set. So it is not Anna Rose (00:59:56): A DEX? Awa Sun Yin (00:59:57): No. Anna Rose (00:59:57): Okay. Awa Sun Yin (00:59:58): No, just for transfers. Just a shielded set, one unified one that is shared among any kind of asset. Anna Rose (01:00:04): I see. So this is really like because, okay, so you would move an asset maybe from Ethereum over the trustless bridge into Namada. You could move lots of things into it. You could transfer them in that space to other people, I guess. Awa Sun Yin (01:00:17): Yes. Anna Rose (01:00:18): Or to other wallets of yours, and then you could bring it back out it there's no price exchange and this is maybe where this is. Yeah. Okay. Then you don't need an Oracle. That's fine. Awa Sun Yin (01:00:30): Yeah. Anna Rose (01:00:30): Then actually the asset type, maybe this is a detail here, but are asset types, each kind of ERC-20? Awa Sun Yin (01:00:40): It doesn't matter what you asset types you send Anna Rose (01:00:43): But it's more, the questions. Does die have an asset type associated with it that all die would use? Or is it it always has a new value every time something new is sent in, it has a new value. Awa Sun Yin (01:00:54): I'm not sure, but I also not sure it matters. Anna Rose (01:00:58): Okay. Awa Sun Yin (01:00:59): Yeah Anna Rose (01:01:01): Fair. Well, I guess it's something that I can ask Chris at some point. So everything we've talked about though so far, this is still, I think the distinction of Nemada is there's multiple assets that can be used. But what else? Is there any other innovation that's coming along with such a development? Because right now it's sort of sounds a little bit like solutions we've already seen where you just move things into a private space and then move them around. Yeah. Is there anything else that you like that's kind of coming with Namada that we can look out for? Awa Sun Yin (01:01:33): So something that is pretty exciting about Namada is that users can get rewarded for using shielded transactions over transparent ones. And this is in alignment with our vision of the auto tagline of Namada is privacy as a public good. The way we look at philosophically at the shielded set is that privacy is actually not a feature. It is more of a public good that it is non-excludable so nobody should be able to be prevented from accessing privacy features. And on the other hand, it is also antiviral. So the more people actually use and contribute to the traditional set, the more privacy grant these individuals get. So how does Nomada fund privacy for public good, it leverages some mechanisms in the MSP that allows the incentives. So a portion of the protocol inflation is actually directed to fund shield transfers. And it is calculated based on how effectively a contributing solution would set. So it is not made to encourage spamming and the rewards are calculated based on which assets sent to a shielded set and also how long it has stayed there Anna Rose (01:02:47): Are some assets gonna be better rewarded than others? Awa Sun Yin (01:02:52): That's to be the determined, but definitely the MSP is programmed in a way where we can determine what is rewarded based on what parameters. Anna Rose (01:03:00): Cool, cool. Is there also sort of a strategy to expand the shielded set or use bridges into other privacy networks? Awa Sun Yin (01:03:07): The way I look at this is that independent of what assets you like and then which Layer 1s they come from, they can all be part of the same set. So on one hand, by diversity, it allows you to create more larger sets, even if you do not necessarily like the same kind of assets. So that's one way of looking at how you expand the set. But again, a feature next step is that actually privacy sets or shielded sets are competitive. So if there is one that has, there's really large anonymity set, then a new one that has gone is gonna have a hard time competing. Anna Rose (01:03:45): Totally. Awa Sun Yin (01:03:45): And it has this network effect of you're gonna get privacy in the larger set. So there's no really an incentive to go to the short, the small one over this. And this is where our research into private bridging and private AVC comes into play because we would actually enable, we would like to enable, shielded sets to be able to live in differently Layer 1s, depending on which security model they want, they prefer what just wanna do, but without actually having this competitive effect on the set. So if we enable private bridges and private IBC, then all shielded sets would actually be shared independent of which Layer 1 they are part of Anna Rose (01:04:25): Yeah. But that's that sort of challenge of these privacy, that sort of shielded pools or anonymity sets is if you were to create a lot of these privacy networks that don't connect, then each one is gonna have to bootstrap that on top of whatever, a validator set and a user base and all these things. So the lower smaller number in the anonymity set, the less anonymous people are. Awa Sun Yin (01:04:50): Yes. Anna Rose (01:04:51): Because if there's four people and they're doing things, you can figure out who those four might be. Awa Sun Yin (01:04:56): And actually this all comes into play of, so the initial question you asked me about how does Anoma and Namada relate? And we are trying to get to that, but we haven't really answered that. So actually Anoma's long term vision is that we strive for a multi chain world where even Anoma instances and even Namada instances scale fracturally. And we wanna push for a direction that we call homogeneous architecture and heterogeneous security. This means that protocols and applications become just standard and they can be ported across different security domains that are not standard. This why heterogeneous security? Because in a world where applications and the base protocols are the same everywhere, the only thing that is gonna matter is going to be who do you trust? So what is the token? What is the governance around this? And who is the validator set or the miners? That is what composes the security domain. (01:05:55): And it depends on the application and on the user, but I can totally see a world where for financial transactions, some people might trust more the Ethereum security model than they trust the local security model. Whereas in other cases, think of, for example, in Berlin, some businesses might trust more the Berlin security model over the one from a current one that is a little bit fuzzy, where I think it's, it's a front end like Visa, MasterCard, and then a bunch of financial institutions actually, Namada is a first fractural instance of Anoma. Anna Rose (01:06:31): Ah. Awa Sun Yin (01:06:31): So you can think of it as another Layer 1. It should show you that over time there's going to be different fractal instances. Some of them might specialize and then pursue different path, but it is just a stepping stone to this multi chain world of homogenous architecture and heterogeneous security. Anna Rose (01:06:50): Cool. Nice. So thanks so much for sharing this sort of breakdown of the differences and the general landscape. There's always a lot of work coming from the Anoma crowd and crew. So I hope this helped people also to understand where those different pieces live and how they work together and what we're gonna already see with Nemada and what we are still waiting for with Anoma. Do you have anything else you wanna maybe share with the audience? I know that there's possibly a trusted setup coming or something Awa Sun Yin (01:07:20): Oh, right. Actually, there are few things I can share with regards to Namada. Anna Rose (01:07:26): Okay. Awa Sun Yin (01:07:26): Which is the most immediate thing is that we're gonna do trusted setup. It's just because the MSP needs its own parameters and there will be announcements coming up soon. And then we will also be doing public testnet as well. So watch out for those. And with Anoma, I'm pretty excited to start seeing next year some first testnet that kinda show you really the overall architecture transparent way with a few applications. And then it will really demonstrate, it will allow you to kind of imagine what are the differences in application of Anomas and how do they benefit from this architecture that is so different. Anna Rose (01:08:02): Cool. All right. Well thank you so much Awa for coming on the show and sharing with us all of this. Awa Sun Yin (01:08:08): Thanks so much for having me. Anna Rose (01:08:09): I wanna say thank you to the ZK podcast team, Tanya, Rachel, and Henrik, and to our listeners. Thanks for listening.