Anna Rose (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 Anna Rose (00:27): This week, Kobi and I chat with Shumo Chu the co-founder of Manta network. We discuss the origin story of the project, how they aim to bring privacy to web three, the unique accessibility that being a Polkadot parachain enables. The work they do on building ZK, tooling, and libraries for the general ZK community, their plans for a multi-asset shielded pool, a quick look into the future. They have planned for the project and more, but before we start in, I wanna highlight a new video series we have launched this summer called the ZK whiteboard sessions. It's produced by ZK Hack as well as the ZK crew from Polygon. In it, hosts, Bob and, and Brendan interview top experts in the ZK space and explore the most important concepts in building blocks in ZK. I'll add a link to this in the show notes. It's definitely a great resource to check out. Now I wanna invite Tanya to share a little bit about this week's sponsor. Tanya (01:15): Today's episode is sponsored by Anoma. Anoma a set of protocols that enables self-sovereign coordination. Their unique architecture facilitates the simplest forms of economic coordination, such as two parties transferring an asset to each other as well as more sophisticated ones, like an asset agnostic bartering system involving multiple parties without direct coincidence of ones or even more complex ones, such as N party collective commitments to solve multi-polar traps where an interaction can be performed with an adjustable zero knowledge privacy. Anoma's first fractal instance, Namada is planned for later in 2022, and it focuses on enabling shielded transfers for any assets with a few second transaction latency and near zero fees visit anoma.net for more information. So thanks again Anoma. Now here is Anna and Kobi's interview with Manta Network. Anna Rose (02:05): Today we are here with Shumo Chu co-founder of Manta Network. Welcome to the show Shumo. Shumo Chu (02:11): Very happy to be in the show. I'm a big fan of this ZK podcast myself and happy to be here. Anna Rose (02:17): Cool. As my co-host for today, I've brought back Kobi. Welcome to the show again, Kobi. Kobi (02:22): Hello, glad to be here. Anna Rose (02:24): All right. So Shumo let's jump in. I think it would be great for us to learn a little bit about you. What were you doing before Manta and what led you to this project? Shumo Chu (02:34): Awesome. Yeah. My name is Shumo Chu. I'm the co-founder of Manta network. Before Manta I study computer science more specifically distributed system and the formal method in university of Washington, got my PhD degrees and thinking I see a great potential in web3 space. And then,kind of thinking the best way to know space is actually join company. Then I join a cryptocurrency company called Algorand in Boston, right. And there,I met many wonderful colleagues of some of them,already appear in ZK podcasts, like Sergey. Anna Rose (03:10): Yeah. Totally. Shumo Chu (03:12): Yeah. And I think spended one for one year there, my role there is basically a developing the Python DSL for the smart contract platforms. Right. Basically I almost single it done the Python DSL for the smart contract. And then I kind of get back to academia then doing like ZK compiler and the ZK plus machine learning research at university of California, Santa Barbara, and then decided to full time at Manta to building the privacy layer for web3. Cool. That's kinda a brief, yeah, Anna Rose (03:48): It's quite a journey. It does sound like Algorand has created a group of really kind of interesting research, cryptography focused folks who've gone out to do other things. What was it about working there that you think kind of made for these entrepreneurial cryptographers to emerge? Shumo Chu (04:08): I think in general, I think Algorand is doing great in terms of curating people in tech. I think a lot of times matters a lot, not only the company also like who you hangout with. Right. So for example I know a lot of great cryptographers and also kind of on my side, I'm learning ZK from my like Algorand days. Right. So there are sometimes I kind of just like writing into Georgios one of the co-founder of Axelar. He, he just saw me just like reading the papers about pairings, all these kind of things. Right. So I think basically at that time I get a sense of what is the cryptographic, like, how should we using the cryptographic lens of thinking things and then kind of realize the power of ZK that kind of, I have to say like it's I would never do this if I'm not joining Algorand and also like kind of hanging out and then learn from a group of awesome people there. Kobi (05:05): Cool. So were you working on any privacy on Algorand? Shumo Chu (05:09): I didn't do anything particularly in privacy because I do have a kind of like academic programming language background. It does give me way kind of like formalizing things and thinking things formally my day job at Algorand is basically building the smart contract language for them. But my light job is actually study cryptography. Anna Rose (05:32): Nice. I actually wanted to ask you Shumo, cuz I sort of, I assumed you're kind of a cryptographer, but actually how would you define your skill set? Are you cryptography research? Are you applied cryptography? Are you more engineering? Shumo Chu (05:47): I think there is analogy like you are like a Fox and also a hedgehog, right? I'm kinda like more kind like fox person. I think I basically get a hand of everything of the technical development of Manta is doing as mostly in the intersection of distributor system cryptography and also like smart contract platform building and also a little bit,like operations and also setting the strategic goals for the project basically. Yeah. Anna Rose (06:17): Who is the team today? Who's building Manta, like who are your peers? Like how big is this company? I'm really curious. Shumo Chu (06:25): Yeah, so we have a team of awesome people. I think till today we have 24 people and mostly our engineers, we have about like a, and maybe get the exact number wrong like 17 to 18 engineers and basically in different like specialties there is applied crypto and there is a, a runtime distributive systems and there is a full stack/like client software and then there's double that's overview and some of them are on Twitter, like our CTO, Brendan he's on Twitter, please follow him. And, yeah, cool. Kobi (07:06): Shumo it would be great if you can describe a bit the origin story of Manta, maybe even around the original paper of the anonymous swaps that you folks release. Shumo Chu (07:17): Yeah. That's, that's great. So I think of, we start Manta right then we're thinking, what is the meaningful problem we're going to tackle in the space, right. And privacy is one of the most foundational problem. I think this exactly even like more today, but how can we tackle privacy problems? We have seen, there is already some attacks on the privacy problems, for example, like Zcash, like Monero, right. But then basically our view is yes, Zcash is great. We have a huge respect for Zcash team. The problem here is that this entire web3 world kind of need more things. People not only need to like transfer their balance, privately people want to do defi and one the most prominent usage is decentralized exchanges. Right? So that's kind of the original vision of the Manta. And then basically I kind of get back to the drawing board and of course the starting point of the study is actually try to really, really understand what the Zcash paper did. Right. And then to see, Hey, can we actually generalize that to actually adding a decentralized exchange scheme? And we find we could, and also we can do decentralized exchange privately and also we can making the LP token privately as well. That's kind of the original of the paper. Yeah. Kobi (08:43): Shumo, what was the original deployment target from Manta? Like when you were thinking about this, the decentralized exchanges, were you already thinking about, you know, Polkadot where it is today or what were you thinking by then? Shumo Chu (08:56): I think that time basically like our requirement is pretty clear, so we want to have a relatively fast consensus so that the performance is good. Basically, and second is have a relatively good runtime and we want to have a high performance virtual machines. And then by then the choices really like Cosmos and Polkadot, right. It's basically 2020, like October-ish we started the project and we did basically a few evaluations like the person constant Polkadot and Cosmos. And at the end day, like our team just like full of rust programmers, we just like to programming rust and really like the substrate. Kobi (09:37): That's a good choice. Shumo Chu (09:38): Like subs, sub substrate, blockchain frameworks is really like, I think people in Parity did amazing job to get a, like a blockchain deployment suit as a substrate. Right. So that's basically why we choose Polkadot. Anna Rose (09:52): Do you wanna share a little bit about the landscape, almost like the Manta landscape in Polkadot, I wanna sort of set the stage. You have two different networks and Polkadot always has sort of the Canary or Kusama and Polkadot. So maybe we can just sort of like map out a little bit. What does Manta actually look like right now in that Polkadot setup? Shumo Chu (10:13): Perfect. Yeah, that's a really great question. And maybe I can talk a little bit about like where the Manta's vision get a little bit more generalized than just a do a private payment in decentralized exchange. Right? So the Polkadot has this notion of Canary network people most know like Kusama as a Canary network of Polkadot so it's a little bit history, like Kusama used to be actually a, an Incentivized Testnet. Anna Rose (10:39): Incentivized Testnet. Kind of, although I feel like they always push back when you tried to call them and incentivized Testnet, but, yeah. Shumo Chu (10:46): Is just like the origin when the Kusama just first launched it's un-incentivized. It's not incentivized. Oh, unincentivized. So if you used have a token yeah. It's actually have a faucet used, have to faucet. It's very interesting. Like, I guess the people get the faucet tokens are very happy right now. Anna Rose (11:05): Wow. Really? Wait when it first launched, there was a faucet. I actually didn't know that. Shumo Chu (11:10): Yeah, yeah, yeah. So, and then I think basically people saying it's good idea. It's the thing is if the token doesn't have any, any economy values it just gives a developer different mental mode of deploying things. So basically people think, Hey, it's a good idea to have a Canary network is kind of expecting to be chaos. And and then that's Kusama. I think we're following the same, same their principle as like a Web3 Foundation and Parity for the Polkadot. Right. So basically we have like a Kusama-based network called Calamari and we have we're going to launch a Polkadot based network called Manta network. And these share exactly same codebase and have the exact same set of features. And it actually share the same binary. Yeah. Anna Rose (12:02): But Calamari is sort of advanced it's further along somehow. Right. Like you've already deployed more things there. I mean it's live. Yeah. And Manta isn't. Shumo Chu (12:10): Yeah. Yeah. So basically the deployment sequence is that we deploy the features first in we call dolphin Testnet is actually going through several iterations of the Testnet and then to Calamari and then to Manta. Kobi (12:23): So Dolphin is like a private Testnet that only you run on? Shumo Chu (12:27): Dolphin is a public Testnet anyone can try. It's actually working pretty well. The Testnet V2, we already have more than like a 150K transactions have more than 20K active users in the Testnet. I think it's just a very cool experience. You can actually see similar private payments experience on that like highly recommend you guys try it and it's actually just go to Manta Network. Then you can just click to try it. Anna Rose (13:03): Yeah. I have one more question about the Testnet in a multichain, like in the parachain model where you have various parachains that have launched, they have their Canary version on Kusama. They will also have testnets when you're deploying. Like, is it the Testnet that's actually somehow like playing with XCM to another network's testnet and if so, like what are they going through? Is there a Testnet relay chain too? Shumo Chu (13:30): Yes. Yes. There's infrastructure called the Rococo. That's kinda run by parachain team. Yeah. Anna Rose (13:35): Yeah. Shumo Chu (13:36): Okay. I think there are some project, their testnet don't join Rococo, but we actually joined Rococo so that we can test XCM messages with other teams. This is actually our kind daily workflow. We have tested with the Moonbeam team with Akala team, for example. Anna Rose (13:52): Nice. I think later on we're gonna go a little deeper into like the status of the project, but before we did that, like, I think you had mentioned, you know, doing privacy, what role does a project like Manta have in this ecosystem? What kind of privacy could you bring? Yeah. What would be the use case that you could imagine? Shumo Chu (14:13): I think there are several questions. Let me try to unpack them first. Is that what is Manta vision? Right. I think basically our vision is trying to bring privacy to all the different kind of applications to in the web3 space, right. Not limited to payment, decentralized exchange, and can elaborate a little bit more on like where the Manta project is going like in the following. Right. But, but this is basically our, our vision and what is our current product that is already launching Testnet it's basically a shielded payment protocol that support multiple assets in Polkadot and also I guess, bridge asset toPolkadot ecosystem. So basically the role of the Manta and Calamari is to be a privacy. You can think of kind of like a privacy as a service for all the like Polkadot ecosystem parachains and also bridged asset on Polkadot. Shumo Chu (15:10): We basically can privatize any kind of asset. And also all these assets are in the single shielded pool in the sense that one, one feature we have is that we actually can shield it the asset ID as well, which means all this kind of long tail asset will enjoy same level of privacy as a mainstream asset in the shielded pool. Right? So that's, that's the world we're currently are. And in the future, I'm happy to talk about that a little bit. We're actually launching like a native programmable layer for the smart contract and this programmable layer will be EVM equivalent. So in a sense that it will be compostable and also EVM equivalent smart contract layer directly on the private asset. Kobi (16:00): Nice. So this is kind of where your philosophy, diverges from the current, let's say Zcash philosophy or zcash focus where their current focus is on the single asset where you have, you know, transparent and shielded, but it's all like a single asset. I think there's no big effort in bridging anywhere. And you, you actually chose to focus on that and also your, your kind of touching on composability. So I guess what else would you consider that you diverged from Zcash what are big differences that you have? Shumo Chu (16:41): I always tell the team using that analogy. Right. I think again, right. I think Zcash, those guys are doing great. I think Zcash is like a Bitcoin, right? Like you. Anna Rose (16:51): They blaze the trail. Shumo Chu (16:52): intact, firstly, blaze the trail. And secondly, and like, Zcash has amazing defensive devs for their protocol designs. Right. So a lot of people like, and they appreciate that. Like they have a lot of defensive depths and we're kind of like a, we kind of, we kind of position ourself more like Ethereum, right. We want to support all the assets people love. We want to support all the activities people love in the Web3 space, like DeFi, NFT, metaverse, gaming, you name it. Right. I think there is inherent need for all these spectrums of activities for the privacies. So that we are a little bit more adaptive and try to bring, I think, I guess this is also related to our future reason that are going to bring the programmability to the private asset as well. I mean, you can think of analogous to kind of Ethereum brings programmability to the cryptocurrencies and we're bringing the programmability to private assets. Kobi (17:49): Yeah. That makes sense. Anna Rose (17:49): Do you wanna talk a little bit about Mantapay? Yeah. And like, what is it? Cause I think so far we've been talking primarily about Manta network or like the company or Calamari, but yeah. What does Mantapay? Right. Shumo Chu (18:01): So Mantapay basically is a first project. We are launching, it's already live in Testnet have experienced two variants and the kind of rough estimation is that it's going to be live in Calamari next month. So we are kind of doing the trusted setup code right now. And we're going to do the trusted setup pretty soon. So like from high level, it's basically a multi-asset shielded pool protocol and I guess from the feature side, right. So support multi-asset and you can mint your public asset to the private asset and you can do a shielded transfer. We do have a kind of like a Zcash style shielded address system. And this shielded address system first is reusable, right? Like for example, if you are for lack of better word hungry artists, you want to post your private shielded address over the internet to receive some donations you could, right. So it's a reusable public address. And also each shielded address come with a viewing keys in the sense that the viewing case give you the viewing powers of history so that you can do selective disclosure and regulation compliance Anna Rose (19:16): For audits and stuff. Shumo Chu (19:16): And without, yeah. For audits and without giving giving the spending power. I think that feature is quite useful for even your commercial settings, for example, your running a DAO or running a company, you have a person in charge of spending. You do want the spending history kind of audible. Right. So I think that's from feature level, what is Mantapay and from the implementation level, we do like our amazing crypto team do spend a lot of time optimizing the speed. Right? So actually one of our kind like technical advantage here is that we believe we have a very efficient, probably the most efficient implementation in the industry in terms of the constraint. And we have a very streamlined protocol. So it only takes about like 20K like a RNCs constraint for the ZKP circuits. And this basically translate to a blazingly fast a proover time. Our a proover time is just like two second. So it's basically doesn't add any lag for your transaction. People's day to day, like private transaction experiences. Anna Rose (20:25): It's not bad. Wait, before we go into the sort of details of this is Mantapay a product. Like I just, I'm trying to figure out, is it an application that lives on top of the Manta Network? Shumo Chu (20:36): Yeah, that's a, that's also excellent question. Thanks for asking this. Right. So it can have different forms. So first the Mantapay protocol is running on Manta Network, right? So you have to use Manta network to have the private payment, but thanks to XCM right. Basically support all the Polkadots ecosystem parachain asset and bridge asset. Right? So first layer and second layer from an end user point of view, like how I'm going to use Mantapay, right. So you could use our DApp, right. You bridge the asset to our DApp and use that. That's perfect. And actually we're also developing SDKs and also functionalities to other parachain DApps, give you an example. Like, so for example, if you are adapt in the Moonbeams, you just use our SDKs. You can let your users to one click like privatize your asset, right? So this is all thanks to the wonder for XCM question, communication mechanism baked in, in the Polkadot ecosystem. Kobi (21:37): How does SDK look like? Like what is the interface that the users are getting? So let's say Moonbeam developers, are they getting something like, I want to make a private transfer and then it automatically uses XCM to go to the Manta network. Like how does it work? Shumo Chu (21:56): So SDK in our current environment design, basically, let's say, if you are dev on Moonbeam, and you want to privatize your assets, you basically click the privatization. We provide the XCM codings of what does a privatized mean. You can think of this is basically streamline two things in, in the same XCM call. The first thing is that transfer their tokens from Moonbeam to Manta. And second is also feeding the zero knowledge proof in the XCM code as a message passing. And then on our side, we interpret that as a private adaptation and generate private tokens for the users. Kobi (22:36): Mm-Hmm, that's cool. Anna Rose (22:37): Going back to Zcash. Do you think that another privacy, blockchain, maybe like Zcash or I don't know, like Penumbra or something, could they ever lock into the Polkadot system and do anything like this? Or is it really like by being a parachain that you have that advantage of like actually being able to use XCM and it does something different than what they would be able to do? Shumo Chu (23:01): I think the question is which kind of advantages XCM brings us. So in principal, right. You can always do things like other, for example, like Zcash, Penumbra, as you mentioned if there is a message passing bridge to them, could do the similar things but the advantage of the XCM is this cross chain communication mechanism first it's baked in. Right. So it's supported by relay chains. So have much better security guarantees, basically. You don't have to worry about the bridge security vulnerabilities. And secondly, right. It's very like programmable, right. I think Rob talked about XCM here, right? It's very programmable in the sense that it just like much easier for the parachain developers to do that. I think it's always possible to using bridges I think about XCM is basically a high security message passing and has a certain level of programability high performance spread data in the Polkadot ecosystem. Yeah. Uit does give a little bit of advantages in this regard. Yeah. Anna Rose (24:10): Do you see yourself though, also using like other bridges for your privacy, like going outside of Polkadot? Shumo Chu (24:18): Yes. Right. So then we support the tokens outside the Polkadot ecosystem. Right. If we want to support that in our kind like Polkadot deployment, we want to do that. But I think we are like looking to grow Manta to a multichain project in that sense. Right. So, because I think the inherent reason here is that there are some security concerns over bridges, right. Also at least as a current state of bridges the things you can do is still quite limited, not as good as native deployment. Right. So we actually partnered with Axelar like on the bridge deployment and Polkadot ecosystem. Anna Rose (25:01): Because you guys used to work together Axelar? Sergei or what? Shumo Chu (25:05): Yeah. We used to work together. And also, I think it's more about we trust their engineering capabilities. They can making things secure. Right. So, yeah. Anna Rose (25:14): Yeah. You sort of mentioned this multi-asset shielded pool and I might be thinking about something that's not related, but it sort of made me think a little about the work that Anoma does. I know that they often will mention this, like multi-asset is it in any way related? Kobi (25:28): They even have a project that's called MASP like, Shumo Chu (25:32): Oh yeah, yeah, yeah, yeah. It's, it's very, it's very similar, so. It's kind of interesting. So when we first developed ideas actually didn't know they exists. So the, the original MASP design is before Manta paper. But I guess I just don't know the paper exists kind reinvented the wheel actually. And then once, once we actually write the paper, oh, we say, Hey, like this like Zcash people actually did this, like a multi-asset shielded pool, but the design I would, wouldn't bore you into the designs. The design is a little bit different. Okay. But in general, in the high level, it's it's very, very similar, Anna Rose (26:07): But is it similar to Zcash or Anoma? Was Zcash the first people to do it, or? Shumo Chu (26:12): So this multi-asset shielded pool is originally designed by Zcash. Oh, okay. And then kind of Anoma forks that Anna Rose (26:21): Oh, okay. That's the history. Yeah. Shumo Chu (26:24): Yeah. Yeah. Also like, I think Anoma guys are amazing. It's actually properly credit that as well. Right. So I think in our in our case, we have no idea when we first read the paper, we have no idea. This thing exists. And after read the paper, Hey, we find this actually we add reference of multi shielded to the paper. The second version of the paper when we revised paper. Yeah. But in general, it's a very, very good design in the sense that I think it's the way to go. If you want to have a multi-asset privacy in the sense that there are going to have some like mainstream asset and longtail asset. Right. And then if you put that into a single pool, then this longtail asset will have the same level of privacy as this mainstream asset. Okay. That's that, that's, that's basically the, the design benefit you, you have for the multi-asset shielded pool. Anna Rose (27:19): And I guess what you're saying here a little bit is, you know, when you think of a shielded pool so far, we do think of them as all having the same, like asset type and then like, say there isn't very much liquidity in it, then you can often sort of spot things coming in and out of it, when you say long tail, you're talking about like, things that have low liquidity, there'd only be like once in a while something put in or taken out, but wouldn't, you still be able to see either side of that, like, wouldn't you still be able to track that like, well, they're long tail. There's very little of it. Like how could you not still reveal? Shumo Chu (27:50): That's that's a very, very good observation. So like putting in, getting out right. This, you still see the asset ID. There's no way you can hide that because while end of the pipe is public, but the, the privacy benefit you get is basically from token transfer, let's think of a multi-asset design that you actually disclose the asset. Then you actually know like, what asset is being transferred. If the asset ID is public. Right. And let's say, Anna you are the only one who have this very niche asset and people can directly see your transfer. Right. So I think that's concrete benefit. We, for the multiasset shielded pool have here. Kobi (28:31): Yeah. I guess like, as long as you keep your assets in the shielded pool for a long time, then you, you will be able to, to at least wait until other users join and say something like that, more of this asset. So don't go out too quick, I guess. Shumo Chu (28:47): Yeah. Anna Rose (28:48): But in this case, is it also that within that shielded pool, there's just like more stuff happening. Like, can you do more with it? Could you use it to do things so therefore like, yeah, it's maybe less about like the ownership of the asset, what you could do with it. Shumo Chu (29:04): That's another excellent question. Basically need to the future direction we're going. We want to basically have a general program mobility for the private asset itself as it is without ever converting the back to the public asset. We can have a very good design here, actually. Well try to get the like EVM Testnet out for the private asset this year, but in general we think that's could do and should do. And that's where in, in our view, the privacy like webstream project should moving towards, because I think it's really about a like user experience problem, right? So I think it's great. We can privatize this asset and transfer to our friends and privatize that to public token, get some utilities, but in general, to be able to actually make privacy more mainstream and to protect more people's privacy, we just need to lower the entry barrier in the sense that people can just use a private asset as they're using normal asset and we think that's perfectly doable. Shumo Chu (30:15): And then basically the way you do it, that basic new gives a private asset, same utility as a public asset. Where for example, you can like buy NFTs, you can do DeFi and you can use that in all the metaverse applications. Right? So I guess one interesting thing we think here is that let's imagine in the future web3 world, basically our stance that we think privacy is not a good to have thing. It's actually requirement, let me give you several, several concrete use cases, right? So of course we want privacy in defi because that's your like most important privacy parts, the financial privacy, there are many, many other use cases. I think one use case for example, is NFT, right? I think the current way, the NFT is actually have a biggest privacy leakage in the sense that I have my NFT as my PFP, I submit my address to Twitter to verify my PFP. That's a direct leakage. Of your idea, your personal identity with your unchain address. Right? So this leakage is just so huge, right? So think of you have a ZK-based private NFT. You can still showing off, Hey, I have this like wonderful NFTs, then you just verify that using Zero knowledge proof. Right? So you, you get all the functions, but you actually will have privacy. Anna Rose (31:49): Yeah. There's actually two places where you could do that. Even you could privately prove that you own like an NFT or something in a collection potentially to, to get access to something. Or I think in your case, you're saying you would not know to which address that NFT actually belongs. Shumo Chu (32:07): Yeah. Yeah. So you, you, you can still, Hey, this is my public profile, right. Isn't I show that I own this NFT, but it doesn't necessarily have to link to your Ethereum, or like a Polkadot addresses. Right. And just before we move next, allow me to show you another like applications we have in mind. Right. So for example, like in the future of the decentralized organization, like DAO, right. Very simple applications, like payroll actually requires privacy, kinda like any, like organizations. I'm not happy my colleague just earned like a 10 bucks more, more than in the single mine. Right. So I think you can see, right. So basically we're envisioned in the future, like the, the privacy is actually inherent need. If we are buying this web3 space are going to be more important in people's daily lives than we think you need privacy from the first principle. Right. Anna Rose (33:05): Basically that's where comes from. Anna Rose (33:09): Okay. Now I wanna spend a bit of time diving a little bit more into the tech stack. And you had sort of mentioned a few things you'd mentioned the Poseidon implementation that you did. I mean, did you take the work that had already been done and use it, or did you do something to that? Like there had been sort of these, what was it like hash competitions a few years ago where they were trying to find these, like, do you remember this Kobi? Kobi (33:32): The SNARK friendly hash function competition that was organized by the Ethereum foundation? I think. Anna Rose (33:38): Cool. Cool, cool. Yeah. Were you taking kind of the outcome of that Shumo and then putting it to work or were you doing something to it? Shumo Chu (33:45): So we definitely kind of standing on the like a shoulder of giants. So there is a hedging competition and there is a Poseidon paper by like a Dimitri and many other great cryptographers. And also I think in our implementations, we actually look into Filecoin's, a Poseidon implementation called Neptune. It has very, very good specs, right? So basically we look at all these, those papers and implementations and then our own team make our own implementation using Arkworks as the bucket. I think one thing I want to say a little bit here is that our team actually building our own like ZK infrastructure called OpenZL. So it's not really anything like super fancy, but it's basically built a like intermediate representation layer, kind of a proof system agnostic. And this has been proven very, very helpful in our internal, like R&D. Shumo Chu (34:45): The most reason is that we think the most circuit logic are kind of building in these OpenZL, we call Eclair this like intermediate representations. And then it compiled to both, for example, Arkworks Groth16, it compelled to ZK garbage plug in the future. It could compare to Nova, which is new proof system, right? Because we see catalyst more slow, like trajectory of proof system, new and better proof coming out all the time. And we want to build a IR that can using this proof system as a compilation project and partially the, our get back to the Poseidon implementation, right. Our Poseidon implementation, the high level logics actually implemented using our IR. And then we did a compilation to both ZK Garage PLONK, and also to like arts works Groth 16 R1Cs. I think these Arkworks R1Cs variant of the Poseidon is super, super efficient. Yeah. Anna Rose (35:49): I feel like I'm hearing more and more projects like this, or like ideas around this, these sort of intermediate compilers, whatever that role is sort of in between languages to be able to speak to different languages. I mean, I've heard about it within maybe just like regular blockchain in the past, but now I'm hearing about it more and more in the ZK space. Like, would you put something like CirC kind of in that category? Kobi (36:11): I think CirC is a great example of something similar. Like there were also thinking about having this different backends right. And supporting different proving systems and so on. I think it's, it's very interesting that you're working on it because it's not a small challenge, right. Like to translate something that is expressible using hashes, let's say, or I don't know, modifiers or whatever, to both R1Cs and PLONK in an efficient manner. It's I think something that is still like, kind of an open problem. Shumo Chu (36:48): Aha. I think maybe I can talk a little bit more on that by the way, this is not done by me, this is done by like our CTO, Brendan. So I think in high level you could do that the way you do that is that we get a lot of inspiration from LVM, right. The thing you want to build is extensible structure. So basically our compilation tool chain has two layers. The first layer is eclair. It's a proof system agnostic, IR that describes the high level logic. Kobi (37:16): How, how does it look like what would be the opcode? Shumo Chu (37:19): It's just a rust. It's just a Rust there's no opcode. Yeah. Kobi (37:22): What, what, I mean, like in the rust, do I write like this is eight times vehicle zero. Do I write like I'm hashing using shadow 50 C? Like what do I write? Shumo Chu (37:32): So I think it's, it's closer to letter, but we, we have a kind of a try to maximize the, the usage of the rust, generic. We have a notion of the compiler. So in the sense that all this backend, whatever, this support expressing the rust trade interface, and then plug in as a like generic argument as a compiler. That's why I mentioned LVM right. It's really sensible in, in the sense that we can be using this to staging different like expressions of the computation logic, different layer. Right. So it's, I think to the first optimization, you can think of something like the rust DSL. We don't have a frontend yet. Right. So I think it's just like currently just like internal purpose, but we, we do want to make it open source and we actually applied for like a Polkadot ecosystem fundings to make it public good. Shumo Chu (38:23): But get back to the technical design, right. Basically there are two layers. The first layer is expressing the computation logic. The second layer is where the optimization comes through. Right? The thing is you do want to express proof system specific optimizations, right? This kind of in our notion, we call it a compiler. Basically you plugins compiler and you express the proof system specific optimizations in the second stage in the sense that it's not completely agnostic. Right. So basically we write adapters for RNCs for basically Groth16 based on RNCs. We write adapters for PLONK, right? So this adapter actually not in generic level and can be application level adapters as well. Basically, that's a thing, right? So you could express Poseidon specific optimizations in these adapters. That's why I kind of bring the extensive design of LLVM here. If you're familiar with the LLVM right. Shumo Chu (39:26): It's kind like a building some like a extensions and back end of the LLVM. So it's actually helps the team a lot, the developer effort already pays off in the sense that we're kind of evaluating whether we're using Plonk or using Groth16. Right. And I, after we benchmark it showed like overwhelming advantages to actually using Groth16 as a proof backend and our team being able to basically switch the backend in like 1.5 hour from Plonk to Groth16, for example, that's actually give us a lot of confidence, keep building this infrastructure. Yeah. Kobi (40:05): Nice. So like this kind of specific optimization that you mentioned, I guess they could use things like custom gates or lookups things of that sort. Shumo Chu (40:15): Yeah, exactly. For example, in the application specific adapters for Plonk we actually leverages like higher than standard weights, customized gates in pounk to have a more optimized plonk implementation as well. For example, Anna Rose (40:31): You just mentioned actually use, use the term ZK Garage plonk, which I don't know if our listeners are that familiar with ZK Garage, but I know you've been very, very involved in that effort. Do you wanna just explain a little bit what that is? And actually I wanna know, is that a new name for plonk for a type of plonk ZK Garage plonk? Cause I hadn't heard it anyway. First explain ZK garage though. Shumo Chu (40:52): ZK Garage is a community driven effort to build a public good plonk. There are several people involved. I wish I can take all the credit, but the truth is I'm just one of the, I'm just one of the contributors majorly lead by Luke Pearson, one of the Polychain partners. And also there are a lot of amazing people all over the places from project like Ethereum Foundation, like Anoma you just mentioned, I think Kobi's kind of active in the, at least in the discussion. Kobi (41:23): Guilty. Yeah. Shumo Chu (41:25): I think it's a really nice, common good Plonk implementations. I think two of our team members Todd our cryptographic engineers and also our CTO Brendan. They all contribute to ZK Garage Plonk. And I think also they did a, at least quite a few educational tutorials for plonk. Like for example, one of our cryptographic engineer, Todd, he actually give like general ZK tutorial based on that. On the line hack organized by Columbia students. Yeah. Nice. I think it was another ZK podcast perhaps, but Anna Rose (42:02): I think you might be right. Shumo Chu (42:03): I just briefly introduced the community effort here. Yeah. Anna Rose (42:06): Cool, cool. And actually I think I call it like ZK Garage because of my north American accent. But given that Luke is British, I believe that it would be a ZK Garage, I think is more how he pronounces it. Am we right? Something like that. Anyway, maybe I'm doing it totally not justice. And we should probably have him on the show to talk more about this at some point. Okay. Yeah. But so is that, but is that now a type of plonk, you know, people have used the word plonk in various ways, but would that be almost like a standalone distinct plonk if it's a ZK garage plonk? Kobi (42:42): Yeah, I guess in some sense we have like a few plonk implementations going around. Right. so you could have chosen any of those, like the Halo2, one, or now the Espresso one. Let's say what, why ZK garage? Shumo Chu (42:57): From our view. Right. So we want to having like a optimized plonk implementation first. Right. So I think basically instead of using all these like plonks, we do have some of our own ideas of actually how to do the plonk implementations. I think plonk is very kind of like a, like you said, it's a it's umbrella of many different things. Basically there is a plonk original paper and there are a few other papers adding things, for example, like a turbo plonk. And then there is a paper called the plookup, right. Basically kind of doing the Lu in the plonk side. The ultimate reason why using ZK garage plonk is that we see like pure community-driven like independent projects that have a long term maintainabilities for going forward. That was at a stage we are kind leaning towards using Plonk. And we also want basically our team to be part of the design and the, also the implementation of the plonk. I think our team still are very happy to contribute to the, the ZK Garage plonk today. Even if yeah. Our production moved from plonk to groth16. Anna Rose (44:09): I sort of wanna go back one step back to that compiler role because I did wonder since I am hearing about more and more projects trying to do this, like, would it not make sense for there to be a standardized version of that? Like why is it good that everybody's kind of developing their own glue between these different pieces? Kobi (44:31): Yeah. This is the place where you put the XKCD comic where, you know, you have 14 standards, so it's time to make a new standard. Yeah, no, you have 15. Shumo Chu (44:39): I think there definitely is. It's just like, I'm more like a practical person, right? So from the practical point of view, if you have a product shipment, I right. You do want to say, Hey, like your team have a clear understanding of how things are going in some sense, it's not that bad. Right? So basically like we have good communication with Anoma team about their VAMP-IR, we basically learn from them. And the reason that we, we decided not using VAMP-IR is that we have very, very different design code. For example, the, the I work using is not VAMP-IR, it has dramatic different design goals. We also talk to Filecoin team. So they have a new language called Lark. Right. So you can think of that as a different language. Let me just briefly compare vamp-IR andthe eclair we're doing and Lark, right. Shumo Chu (45:27): Lark is very high level language. It's basically lisp. Right. It's great for like people who actually doesn't understand anything about ZKP. Right. But it's actually misses at least in my view, some of no level optimization opportunities, right. That's a Lark and VAMP-IR is on the opposite. Right. I think VAMP-IR is great, like intermediate representations. Right? So, and we're actually thinking in a long term where potentially can compel our eclair into Vamp-IR. The eclair were design. We just like vaguely named the IR it's more like a library. And the I extensive framework that I just talk about several minutes ago, basically to allow you to freely express both high level like semantics and low level optimizations, for lack of better word. It's more like a LLVM framework rather than a dedicated IR. Right. So you can see, we are aware of the different development in the space. It just like currently we don't have anything that we can use fulfill our need similar need. That's why we're building this like eclair and OpenZL library in general. Basically. Anna Rose (46:37): That's interesting. I mean, I'd sort of already mentioned CirC from Alex Ozddemir, which I guess falls in a similar category. I don't know if you are aware of it or if you've like talked to him about that. Shumo Chu (46:47): Yeah, yeah, of course, of course. Anna Rose (46:48): But iIs that at a different place as well? Like where on that spectrum, would you put it actually. Shumo Chu (46:53): CirC is kind of in the similar to vampire. Okay. Vampire to some extent, but I, I wouldn't say CirC is the same as vampire as well, right. Because CirC you have a, you know, there is a thing called SMT solver, right. Basically you can think of it's as a, like B the set, right. They have this kind of like a fancy solver based optimization design baked in CirC as well. Right. So it's a little bit more research oriented for CirC. I'm not saying that it cannot be, get getting production it's more, a little bit like research oriented because you have potential to having like a S and T server based optimization baking the CirC. Right. So, but in terms of the spectrum, the closest thing to CirC is actually the Vamp-IR that Anoma is building right now. Basically Anna Rose (47:39): Got it. I know of at least one more project, but I think they might still be in stealth, but I do wonder like just general ZK DSLs, this map of how things are working together. Do you also have to include the kind of individual project DSLs into that? Or is this kind of compiling living in a different part? Like it's almost the question here is like, would other languages also be interacting potentially with your IR you're calling it, I guess, intermediate representation. Is that what that stands for? Shumo Chu (48:12): Yeah. Yeah, exactly. That's a very, very good question. I can like elaborate a little bit more here. Basically we definitely could have a higher level, like from it, right? So it's basically because like our team of cryptographers, they are like a ZK expert, right? We are able to write this low level primitives and also to do dramatic optimizations so that our ZK circuit fast. Right. I think we can definitely build in a higher level abstractions on top of that. And also for example, there are some frontend languages we can plug in things like Circom and Cairo, for example, right? So this is definitely doable. And in terms of the language design point of view, I can only speak for myself. I can like Cairo a little bit better because it actually exposes the, like a fun field as a raw element, the primitive data type, at least allow you to having in some expressivity of the optimizations in the higher level language, for example, compared with Circom, but in principle, right? All these things can be compiled. Right. And I see if there is not enough interest. And also again, like our like IR stack will be a part license as a public good project would definitely welcome people to help us to actually build a higher level stack. But currently our team will be focused on the infrastructure, the libraries, the backend to make it rock solid. Right. So I think I definitely see the possibilities and what we're also open to collaborations basically. Yeah. Anna Rose (49:42): Got it. You just sort of mentioned Cairo, but everything we've been talking about is SNARKs so do you have any like STARK or FRI, anything in your stack that sort of touches that? Shumo Chu (49:55): So currently don't mostly for efficiency reasons and also the proof size reasons. Right. So I talk about Cairo because Cairo is high level language. Right. Okay. That's a beauty of abstractions. So you can compile Cairo to SNARK. There's, there's nothing kind of like, like 100 inherent like Cairo or some fragment of the Cairo, like a high level language design, like Cairo, you can compile that to SNARK. There's no inherent reason you cannot do so. Right. So that's, that's what I'm talking about. Yeah. Kobi (50:26): Yeah. I even heard about some projects that are trying to do that, so it is definitely doable and interesting. Shumo Chu (50:34): Yeah. Yeah. Anna Rose (50:34): Yeah. You sort of mentioned that you're doing a trusted setup, but I'm curious, like you already have Calamari live, have you already done a trusted setup for that? And you're making a new trusted setup for Manta Network network deployed on Polkadot or like yeah. What is the trusted setup for that you just described? Shumo Chu (50:52): So Manta and Calamari while using this exactly the same as ZK circuit. And as a Calamari, we doing the like trusted setup either later this month or beginning next month for Calamari. Basically. Anna Rose (51:04): Okay. But how does it run already? Like what are you running then? Because it's live, but there's no trusted setup underneath the hood. You haven't done one yet, basically. Shumo Chu (51:13): So this is basically the like modular and also the runtime upgrade. The current Calamari run as a, kind of like a generic, like parachain it's joined the Kusama networks, but the Mantapay hasn't been deployed to Calamari yet. Anna Rose (51:29): So is it not private right now? Shumo Chu (51:31): So yeah. So the current kind Manta paper, the Mantapay is going to be deployed on the Calamari sometime next month. Right. So, but that's after the trusted set up, basically. Anna Rose (51:41): Okay. So like the SNARK portion of Calamari is not deployed currently. It will come soon. Yeah. So, okay. Shumo Chu (51:49): So the current Calamari it has it's native tokens. It has a governance. We already remove sucs. Basically all the kinda like a shenanigans that getting a Parachain up and running all the DevOps, all the decentralized validators there. Anna Rose (52:05): Okay. Okay. I see. I see. Kobi (52:07): So in order to introduce the, let's say the SNARK portion after the setup, you will have to do this kind of governance proposal to get that happen? Shumo Chu (52:17): Right. So this is a runtime upgrade, goes through the governance proposals. So I guess this is another thing that kind of advantage in using a Polkadot on substrate, right? So basically you, the runtime upgrade is part of the infrastructure. So for many other chance, I know it's just a little headache to do the runtime upgrade adding features, but here just like a daily standard practice. Kobi (52:43): Can we touch on the general purpose privacy that you're planning for the future? This kind of composable thing. Shumo Chu (52:51): Yeah. Perfect. So, yeah, like I said, right, so we basically, we have a bullet proof private payment protocols already working, and the next step is getting programmability to this private asset. Instead talking that from tech point of view, maybe I should talk from what does this brings to developers and users, right. I guess the first is that to the developers, you can deploy your favorite solidity-based smart contract into the platform. And this can directly manipulate the private asset in the sense that the private asset will be providing as the same interface as ERC20, which for fungible tokens and ERC721 and ERC1155 as for NFTs and potentially many more as a compostable interface. So ZK app developers, they don't have to learn ZK, they can just write a solidity DApp. And this step can seamlessly working on the private asset that's to the developers and to the users. Shumo Chu (54:01): And you don't have to worry about that. As long as you are using the depths are adopting this private asset. We actually spread some effort developing the wallet infrastructure to putting things, for example, putting the ZKP generator into a wallet like , like a Metamask snap. Right. So you don't have to worry about that. You just use the private asset as if you are using public asset, right? So that's an end goal. And we are actually pretty close to that to get these private like where you coin the term right now, because it's a little bit confusing. It's not ZK EVM because ZK EVM doesn't have privacy. And also we're not privatized entire part of the EVM. If you guys having some ideas of what is the term here, and we're happy to listen, for lack of better word, let's call it this new like a EVM design that support composable privacy. It's quite a known word. So that's basically the high level goals we want to want to achieve here. And I think nowadays it's popular to see things like alpha leak. It's I think we're definitely trying to disclose more information, including the design and how does things work and also how like, when people can play with the Testnet in the following months and I guess keep an eye on us. Yeah. Pretty excited. Anna Rose (55:25): It's funny. Cuz I think a naming standard you could employ if you wanted to, like, it used to be ZK rollup and then there was like ZK ZK rollup, which was like the private ZK rollup. But I know you said it's not exactly EVM, but like ZK, ZK, EVM, maybe. I don't know. I maybe I've even heard that. Shumo Chu (55:45): Since Anna, this is one of the candidate who are going to consider maybe we'll we'll send you an NFT if that's Anna Rose (55:52): Private only that's private. Yeah. Shumo Chu (55:54): It's private NFT. Yeah, exactly. Exactly. Exactly. Yeah. Anna Rose (55:58): All right. Shumo, I wanna say a big thank you to coming on the show sharing with us Manta and it's kind of journey to now and what you've planned. Shumo Chu (56:06): That was great talking to you. Shumo Chu (56:07): Thank you. Doing so much work for the entire space. Yeah. Anna Rose (56:10): Ah, cheers. I wanna say thanks again, Kobi for co-hosting with me. Kobi (56:15): Happy to be here. Shumo Chu (56:16): Thank you Kobi. Anna Rose (56:18): And I wanna say a big thank you to the ZK podcast team. Tanya, Chris, Rachel, and our kind of guest editor for this particular episode, David. So thank you, David, for taking over from Henrik and to our listeners. Thanks for listen.