Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Guy Zyskind: Secret Network – Bringing Privacy to Blockchain

Episode Date: January 9, 2022

Formerly Enigma, Secret Network is a blockchain-based, open-source protocol built using the Cosmos SDK. It uses Trusted Execution Environments on nodes to marry privacy-by-default with smart contracts.We welcomed Guy Zyskind, Founder & CEO of Secret Network, back on the show to chat about the progression of the project into the new protocol and why this is now built on Cosmos, advantages and drawbacks in using Trusted Execution Environments and SGX technology over cryptography only, and why people might want to keep NFTs private.Topics covered in this episode:Guy's background and how he got into cryptoHow Enigma/Secret Network evolvedWhy the Switch to Cosmos?Trusted Execution Environment and SGXThe levels of privacy within the networkWhy CosmWasm?The future of SGX computationSecret contracts interacting with other IBC enabled chainsThe types of applications running on Secret todayNFTs on SecretEpisode links: Episode 246 - EnigmaSecret NetworkDiscordSecret Network on TwitterGuy on TwitterSponsors: ParaSwap: ParaSwap aggregates all major DEXs and makes sure you beat the market price at every single swap and with the lowest slippage - paraswap.io/epicenterChorus One: Chorus One runs validators on cutting edge Proof of Stake networks such as Cosmos, Solana, Celo, Polkadot and Oasis. - https://epicenter.rocks/chorusoneThis episode is hosted by Sunny Aggarwal & Friederike Ernst. Show notes and listening options: epicenter.tv/425

This is Epicenter, episode 425 with guest Guy Ziskind. Welcome to Epicenter, the show which talks about the technologies, projects, and people driving decentralization and the blockchain revolution. I'm Sanya Agarwal, and I'm here with Federica Ernst. And today we're talking with Guy Ziskind, who is the founder of Secret Network, which is a, well, not really a new, but it's actually quite a, you know, it's been around for a long time, actually. And we actually had Guy on, what, maybe four years.

years ago, I think, 2018. And back then, the project was called Enigma. And so since then, it's gone through a, you know, number of evolutions and became what it is today called Secret Network, but still focus on the same mission of bringing private smart contracting to the cryptiverse. So we'll talk about with Guy about Secret Network, but first we'd like to tell you a little bit about our sponsors for the week. Our first sponsor is Paraswap. And with Paraswap, you can beat the market price every single block. It's fast and highly liquid and just launched their version 5, which has a new contract and new APIs. It has a more modular infrastructure which is more gas-friendly and now supports free approvals using Ethereum permit messages. They also recently added

support for Avalanche, Polygon and BSC. And you can always use Paraswop with your ledger device right in ledger life. Go to Paraswop.io and get started. Are your crypto assets sitting idle in your wallet? Start earning rewards. contribute to the network security by staking with Chorus 1, a staking provider securing over $5 billion in assets over 25 decentralized networks, including Solana, Cosmos, Ethereum, and Secret Network. Interested in running your own branded nodes, the managed white label node-as-a-service offering leverages Corriss 1's highly available and proven infrastructure, enabling you to participate directly in decentralized networks. If you have been a loyal Solana delegator with Chorus 1,

Make sure you check your wallets. In the first ever major NFT drop by any validator, Chorus 1 will be dropping over 3,600 exclusive NFTs to its Solana delegators according to their delegation profile in December 2021. But if you missed out on thisirdrop, don't worry. You can still participate in the upcoming airdrops for cosmos chains by simply delegating to Chorus1 nodes. Head over now to corus.1 to begin your staking journey. So, Guy, welcome back onto the show.

As I mentioned, you were here a long time ago back in 2018. And so, you know, hopefully we've gained a few listeners in that time. And so maybe for like any of the newer listeners or maybe didn't listen to the previous episode, you know, can you tell maybe start off with telling us a little bit about your background and how you got involved in crypto? Sure. So first of all, thank you for having me again. It has been a long time, so I'm excited to be here. Epicenter has always been my favorite podcast. About myself, I've been in the crypto space for, you know, since 2013, 2014, depends on how you count.

2014 is really when I dived in. I started grad school at MIT, and there was, just before I started grad school, there was this, like, MIT, Bitcoin Hackathon, which we build a cool product for. This is like pre-Etherium even. And we won that hackathon and that got me kind of like excited and I'm like what we can do with this technology and I went to my professor and told him,

look, I want to focus like my research, my work on this like emerging technology. So, you know, fast forward in a bit I very quickly became interested in, you know, how blockchain can have inherent privacy, not just in the transactional sense, not just in like the Zcash or Manera way or transferring assets with privacy, but if we're thinking about blockchain as like, you know, these more involved like replicated state machines, more involved decentralized cloud computers, then surely there's need to be a way to handle sensitive data

in those Web 3 applications. So I focused on that. I focused my entire research on it. I wrote a few papers. They got a bunch of citations, pretty substantial citations. And that kind of led to the Enigma Project, which I spun out as a company in 2016.

And then in 2017, we did an ICO, and we started building that network. 2017 we did a token sale for Enigma with the idea of building a network, not necessarily blockchain, but a network that allows it to run privacy preserving computations. And, you know, somewhere between around 2019, we kind of realized that it's now working the best way. That was about the same time that Cosmos was about, I think either just released their SDK or was about to release their SDK. I was really fascinated. I was actually very fascinated by Ternarmine consensus.

And then I looked into the SDK and said, wow, this is, this is like much better. Like, we should be using that. And then we pretty much scratched everything. And then kind of like between end of 2019 and 2020, just like rebuild our architecture around Cosmos SDK. And early 2020, we released, you know, Secret Network. We use a different brand to kind of distinguish it. It had a new coin called Secret.

And then in September 2020, we actually launched like the privacy capabilities. So basically in secret network, you have the ability to run encrypted smart contracts where both the inputs, the contract state, and the outputs remain encrypted, and you can basically build end-to-end decentralized applications with privacy. And the network has been growing substantially since. I think we're one of the bigger cosmos chains today. and yeah, that's kind of like the history from 2014 to 2020. Thank you.

That was very comprehensive. I'd like to dig into the switch to Cosmos. So basically, you said that the Cosmos SDK was just a lot better than your previous technology stack. Can you kind of expand on that a little bit? Yeah, I mean, look, our core offering, our core capabilities is like, how do we build privacy into smart countries? And pre-cosmos, like, you know, there was an option to fork ephirium or do that, but that

really didn't, that didn't really work well and we didn't want to do it. So we started building our own P2P stack, our own, some kind of consensus. It wasn't really consensus because we were relying on ephemium for consensus. But we spent, like, I think 80% of our development, our testing, like building that infrastructure that, you know, it was just a waste of time. Like, that's not what we wanted to focus on. And then Cosmos gave a great SDK. Truth be told, at the time, I think it improved today, but at a time, the SDK was great.

The documentation was horrible. So it took us longer to get, like, fully onboarded and working with Cosmos than we could have, like, today. But still, like, all the parts were there. And instead of like focusing on building a P2P layer and a consensus layer, we have that forgiven. And we can just focus on the other aspects of our technical stack. So how were the reactions from the community when you rebranded and switched tech stacks? So people were confused.

We were selling ourselves for a long time as an L2 to Ethereum, as an L2 to other other chains. Like, at that time, people did not believe in the cross-chain world. Like, everything was like, at least in smart, that related to smart contracts was like, no, no, no, everything has to be on Ethereum. Like, what are you guys doing? So we got mixed reviews, but we didn't care. Not that much.

I mean, it's always better to get good feedback. But, like, we just knew this was the right approach. And I think, you know, in the test of time, it's pretty proven that this was the right course of action. Looking back, is there anything you would have changed in how that process went? There's one element which I think the jury is still out on. So at that time, Kosovozum was just starting on. It was still a prototype as well. We've actually helped Kosovozumwazen quite a bit.

like one of our team members became a co-contributed to Kosovozim. And I think there was a big question, like whether we are doubling down on Kosovozum and WebAssembly or focusing on EVM, which is kind of what Yves Moss is now trying to do. My gut feeling is that, you know, we made the right call. I do think that going to Kosovozum-Wazem-Aweb assembly route is the better approach. feel that that's what Cosmos is consolidating around. So I think it was the right decision, but I'm still not sure. I think we'll know that in a year or two.

Would it be possible, you know, to like for Secret Network to support multiple VMs in the future? Or is, you know, is the goal really to like focus on like, you know, you lose composability benefits and stuff if you start to do that? Yeah, it gets complicated. You most likely lose composability. I'm, we're not a hundred percent sure. Like it may be, it's a matter of effort. So supporting multiple VMs is a lot of effort once you stuck with one.

Now, we can do it, but, you know, we are still a fairly small team in terms of the developers. Now, the ecosystem is big, but in terms of core developers, we're still small. So not show that's like where we want to put our effort in. Maybe. And in that case, yes, you start to run across. problems like composability, other types of like integrations. Yeah, it becomes, there will be trade-offs for sure. So, okay.

Let's talk about the secret network. So there is, if I understand correctly, there is currently 50 nodes. So basically, how is it determined how many nodes can participate? 70, sorry, okay. And why is there an exact number? Right. So we initially we set it to 50 nodes. The reason was that, you know, in our network, one thing I didn't mention that, you know, there's one requirement for running a validator in a secret network that other networks don't need.

And that is you have to use SGX. We use secure enclaves to achieve privacy that combined with like security and encryption protocols. And there is some, some cost. associated to it. So like, you know, if you run it without SGX, it's not like orders. It's not like, you know, multiple times faster, but you do get some, some speed reduction. And so we, we thought that starting with like, you know, 50 nodes, basically smaller than I think the 100 or 150 that Cosmos chose and other changes chose. We felt that was the right number. It wasn't an issue until, like the last six months.

Around six months ago, when the network was starting to grow really fast, like we got a lot of people wanted to become validators. And that's why there was a network vote to increase that to 70 reasons. So you're right. It was 50, but recently it was increased to 70 due to a vote.

And I do think we'll I think we'll extend it over time. We're also, a lot of our work for the next year is around, on improving like the VM and like, you know, making that work faster. And I think as we do it, I'll be easier to grow the number of nodes. Guy, I think probably about more than 50% of the listenership are familiar with what SGS is. But maybe for the rest, can you, in a nutshell, explain what a trusted execution environment is and what kind of trusted execution environment SGX is?

Sure. So a trusted execution environment basically is kind of like a segregated piece in like your process or your memory, which basically is completely walled out from anything else happening in that system. And no one can probe into it, not even the person owning that physical machine. It's essentially a generalized hardware wallet. You know, a hardware wallet is essentially a piece of hardware where it allows you to run one computation, which is to sign transactions, but you can't probe into that wallet and actually extract the sensitive data,

which is the private key. So SGX works very similarly, but it allows you to run any kind of computation, and then any data that you push into that enclave, into that trusset execution environment can't actually be seen by anyone, not even the validator running the machine. Just one quick note, there are different kinds of trusted execution environments. Pretty much any big vendor today that's building processors has a version of it.

So Arm has a version, Intel has a version. It's called SGX. That's what we're using right now. and AMD has its own version. How does the network know whether the nodes trust execution environment is legitimate? Right. So that's one of the first things that we did. We build a registration protocol.

So that's where we kind of diverge from like normal cosmos. So when you join as a new validator in our network, essentially you need to go through a registration process before you can start to validate blocks. So what you would do is you would run some code that we wrote inside of your trust and execution environment and that code basically says it generates a like a key, a keeper, right, a private and a public keeper. And then the enclave signs it. it's a process called remote attestation.

And then like the remote attestation, the signature over the generated public key, that blob of information is then posted on chain as a proof that you run in a genuine enclave. So essentially, SGX and other systems, they basically allow you to verify, externally that a computation

has happened inside of the enclave it corresponds to a specific piece of code and it ran correctly and it ran on a genuine enclave and now that's been put on chain everyone can validate that

that new validator is running a secure enclave they generated this keeper inside of the enclave So the private key and the public key is as interesting, but the private key that was generated never left the enclave. Okay. And now any other validator can basically take that information,

take that the publicly know that this was done in a genuine enclave and encrypt it, encrypt some kind of shared seed, shared seed that all validators share and put the encrypted seed on the blockchain. Now the validator that's registering can complete the registration

by taking that encrypted seed because we know that the private key for that only lives in the enclave, we know that the validator can actually decrypt that seed and seed. They pull it inside of their enclave and they decrypted there.

And now it's, you know, it's an ongoing process. And then you validate all that comes in, go through that process, and you get into a system that the base seed is shared by all enclaves. They've been vetted.

And now, and now using that seed, you can derive new keys that, again, only the enclave can actually use to decryptive. stuff and our information coming from the outside, you can use using those keys.

Again, all of them will tend to the base entropy from that seat. You can use it from the outside to encrypt stuff and then send it to the validators' enclaves. I hope that's not too dense. I don't know. If anything is confusing, I mean, feel free to ask for clarifications. I think I'll just follow up on this. So does this process, I mean, it sounds like magic a little bit.

So does this process actually work without relying on the attestation of Intel or whichever chip manufacturer you're using? So basically can the secure enclave prove that it's not being watched or how exactly do you come by that attestation? So the initial registration part does rely on Intel SG. It's called Intel. ISV, I can't remember the Intel service verification. I can't remember the acronym. But it does rely on Intel to basically say, look, we have like that signature, that remote attestation, which is essentially signature, is from a genuine enclave that, you know, we

manufactured. Now, I do believe that in the next version of SGX, which we are working on, including, there's flexibility in that. Like, there's ways to do it without actually going remotely to inter servers. We have not implemented that yet, but it does exist. That said, the process that we're generating, that we're generating, you know, a private key and a public key per inside of the. enclave does mean that we only have to do it once for every validator, and in that point,

the network can really kind of like self-manage and self-sovereign. Cool. Can I follow up again on the SGX? So basically, if I have a consumer notebook, would that typically have an SGX? Or would I have to buy a special computer to actually have that included? It used to be the case. That is actually something. that, you know, our network has an infrastructure committee,

which basically checks, like, at all times, like, what are the supported hardware and what you need. I think, to be fair, like, we can talk philosophically if that's the right direction, but to be fair, it seems that a lot of validators are becoming more professionals, so they're running, they're not running notebooks anyway.

They're running, you know, serious server infrastructure. again, a philosophical question. But it used to be the case that like any notebook would actually have SGX support. But Intel, I think in their latest chips, have decided to only do that, only enable that in servers. So the answer is no, no longer, or at least new notebooks do not support SGX as far as I know. but again, I think it's less of a problem because everyone in our system in our network are like

mostly professional validators that are running servers anyway. Do you know what caused Intel to like sort of reverse direction on that? So we have pretty good ties with Intel. I've asked that. I didn't get like a fully clear answer. Like I think that's something

that's very internally important for them. But my thinking is, that, you know, they want to focus on high, like using SGX and Enclave and confidential computing in very, very high loads, and that works better with servers. Like they want companies to provide their services, you protected by things like SGX and enclaves. Less so, originally, originally, the idea of putting SGX as far as I know in every computer was so that, you know, let's say there's,

like a company gives you an agent software that you run locally, not on the server, and that agent, you know, would run inside of an enclave locally, so you as the end user and the customer are comfortable that your software hasn't been tempered with. I think that that didn't be, like that didn't pan out as a good business direction, and it was just costing them more money than it was, you know, giving them. Also as a little bit of a DRM solution.

I remember that was sort of like one of the things that they were pitching early on. So only the validators need a, you know, so I guess there's like different classes of users. So to use secret network, you know, I don't need to have a SGX in my own computer to just be a client. But so I guess two questions. one is would if I just want to run a full node, uh, not as a non-validator, do I still need an SGX?

And two, um, what, what kind of, how does the security model change from when you're not running. If you, if you, you know, if you don't have an SGX and you're,

you're, you know, rely, relying on, a validator. So I guess, you know, one, on one side, I feel like, you know, maybe you can even improve the like client security model from normal because you can, you know, rely on certain aspects of the SGX to improve that.

But on the other hand, how does, yeah, I guess more interesting is how does the privacy model change then? I mean, first of all, this was mostly for simplicity. Like we thought about doing like a hybrid model where full nodes don't, are like somewhere between a light client and a full node and don't actually have to run SGX. It was too complicated. I mean, so we can't do it again. It's a cost-benefit analysis.

And so for now, even full nodes need to run SGX. Obviously, end users and clients, they don't need to. They don't need to in all. Can you talk about how the like client would work? Because I know this has been a big issue in many privacy coins, like in Zcash especially, where you can't, you know, there is no light client that exists for Zcash. So is there a light client that exists for secret? Not really, but like, you know, when it comes to like specific things, so like, like, there's a concept of viewing keys and pretty much anything that's encrypted, like you can give a viewing key, for example, to Kepler and then like, you know, they can get like read only access to like import information.

So that's usually the way that we solve it. But no, there's no proper light client yet. Yeah, okay. So then back to the previous question. So like what does the, so how do I like, what kind of privacy guarantees do I get when I request, when I try to use secret network? Like does the validator that I'm sending my transaction or like the validator that I'm querying information from can they learn about like my data? No, the validators for sure can't. you know, there's side-channel information

and sacred itself the coin is not private. So there's side-channel information from that, like in many systems. But no, when you send your information to a validator and then when it's, you know, run and edit it to a blog, like the inputs, the state and the outputs,

they're encrypted, they're only being decrypted inside of the enclave. So, like, you, like, there's, there's nothing that you miss. And we basically, for correctness, like we still take all of the benefits of tendamim because because of the key sharing process that is, because of what I said in the beginning, when you register, you get a randomly generated seat, but then that seed is used to pseudo-randomely and deterministically generate like the same set of keys for all nodes,

for all computations, for everything that's going on. So consensus doesn't break. Like all all validators, even if they don't see what they compute at the end of the day, like the blocks that they're producing, the transactions, the outputs, like all of them aren't the same.

I guess my question is, but if I'm querying data from the blockchain. So if I'm, so you know, you mentioned this viewing keys. Like, so if I'm asking a, you know,

I'm querying a note saying, hey, I want to know, know what my balance in my account is. Who can, can anyone see that, I guess two things. One, can they see that I'm asking for a balance and from what token? And then two, can they actually see the balance itself? No, yeah.

So let's take the example of asking for querying for like a token balance. So they would see that a certain secret wallet and they can see the address of the secret wallet is a querying for a balance. They will not see, they will know which token they're querying because each token is its own like contract. But A, they would not be, they would not know that you're querying for a token. They would just know that you're interacting with the token contract from the secret address.

And then the query would basically, you know, it would pull the your back. balance from the state, the validator won't see it because like that part happens inside of the enclave. Then before releasing it outside of the enclave, I mean, there's kind of like for each, for each query or each transaction, there's kind of like a derived key between the user and the enclave that only the enclave itself can see and the user can see. So what happens is the enclave uses that to encrypt the query result inside of the enclave for the user and then release that.

So only the user can client site decrypted information. The other part is that there's a viewing key. So you can share a viewing key such that, for example, another service could get some kind of read-only access and can also decrypt the information from a query. But those are the only parties that can actually see the results. either the user or whomever they gave a view in Q2. Does that make sense?

Thank you. That's super interesting. Yeah, it makes total sense. I imagine there are particular challenges to building the user experience, building, you know, as a fully private chain. What are those? So there are actually several challenges, both from a developer and a user.

From a user perspective, right, like whenever you're doing something, you first have to give a view and key permission for the wallet. Like, let's say there's a new token. So now there's another click where you need to create a viewing key for that new token

and then, you know, let your wallet or the application use it in some way. Usually your wallet. And that's just like another click. People are not often used to it because it's like only in secret network pretty much. That's something that we're working on. And recently we've enabled the ability to use permits.

I'm actually not even the best person to explain those. Like that is even still new to me. But they make the process much easier. It's much more automated, basically. It's like you don't have to create it. A priori, it's much more automated in that sense. So that's one challenge. The other challenge that this creates is, in many cases, you know, let's say there's a big

NFT drop, right? And everyone are coming at the same time and they want to mean their NFTs. Well, they first have to like create viewing keys to see those. Again, this is mostly solved with permits. But if you're not using permits, then that creates like a lot of transactions immediately on the network. and we have seen that create some, let's say, difficult stress on the network that in other networks you don't see because you don't have that functionality. So that's like another challenge.

And the third challenge is, you know, a lot of, like if you look at Terra and other networks, a lot of them, they cash the information. So, you know, let's say you interact with the contract, and there's a lot of the same queries. There's mostly reads, just a few rights. So they would cache it, honestly, on a centralized server to kind of reduce the query load from the network. But here, because every user have access to only, like, one row, like their row of information. No one can see the full, like the full state. and usually each user just queries their own row, you get a lot of, again, a lot of queries which you cannot cache.

And that creates making optimization really, really, really hard. I don't think there's a perfect solution there. We're doing quite a lot of work there to improve. But I think that's part of the cost of running with privacy enabled. How about from the developer standpoint of view? Like, can I, you know, so, you know, as we mentioned, cosmwasum is like, you know, becoming sort of the standard across many cosmos chains, especially like Terra.

Can I just go take a Terra contract and just one click redeploy it onto Secret Network? Or is there sort of additional hurdles that developers have to, like, go through in order to make their contracts, uh, design working with the. privacy models. Very few hurdles. Most of them are just like because of like ecosystem tools. So you know, Terra is Terrajs. We have secret jazz.

But it's pretty much the same thing. We've done it. Other people have done it. It's really simple. It's simple than most people think. I think that's the biggest benefit that, you know, we're all, we're all converging to the same like, you know, model with cosomazum, where it's, like very, very easy to cross-deploy.

And actually, one of our things that we want to do in Q1 is we want to give a very, a very easy guide on, if you deployed your app on Terra, here's how to convert it to secret in like, you know, five minutes. Do I, what about, like, for, like, how do I define this, like, viewing restrictions, right? Because, you know, I'm sure on most cosmossom contracts, anyone can just query any part of a contract. Here, obviously, I have to add additional restrictions. restrictions to say, you know, if you're trying to query this balance, you actually have to be the

owner of this balance. So are there like additional sort of, I guess in the view, the read functions of the contract, I just have to add more a little bit more restrictions there or is there anything more complicated than that? I mean, that's, again, if you want privacy, if you want to do like more selective access control stuff like that, and yes, that you need to add, that is up to you. I mean, technically you don't have to do them. it would work without it.

But if you want to use these functionalities, then you have to make slight changes, yes. But again, they're not big. They're usually not big. Can I, when using secret, can I, do all contracts have to execute inside the SGX? So let's say there's some things that are just like, you know, because obviously, actually maybe one thing before regarding that is like, how does computation, you know,

expensiveness work in relative compared to something, you know, that, you know, if all the cause, you know, I know one of the big issues with, not issues, but you know, one of the restrictions with SGX is you have like, you know, it's definitely slower than running on a normal, on a normal CPU. You can't do like, can you do like hyper, like, you know, multi-threading and like you have less RAM and stuff?

So can you talk us a little bit about some of the restrictions that a developer might have there? Sure. So it's single-threaded, but I think most executions in Cosmos, Cosal, was a war-sender-threaded until recently. We are working right now on adding multi-threaded support. That's actually almost done. So we are going to support multi-threading in SGX. It wasn't trivial, but that's one of the optimizations we're doing. The memory issue, there's enough memory, but in memory, but in memory, many cases, because of the way SGX works, then, you know, you have, you have a lot of, like, cash misses. And, you know, if you, if you, if you don't, like, you know, efficiently load

information inside of the enclave and outside, then that could take a really long time. I think in our profile, and we saw that, like, you know, every time we open an enclave, we loaded the, we reloaded the contract, that is taken in some cases, I think, like, the majority of time spent in running the execution. So, yes, the considerations there, it's not trivial. We are slowly improving these and resolving these, and I think we're in a much better position. The slowdown is not that bad today, but it's going to really improve in the next year.

That's one thing. The other thing, which is slightly an issue, is, you know, because of, because of, like, SGX doesn't, for security. security reasons, it doesn't allow it to use like standard libraries and stuff like that. And so, like, using something like Wasmail, which is the go-to

I guess interpreter or just in time compiler for running wasam code. And that's what I think that's what Cosom Wasam uses natively. Like, we couldn't use that, not easily. So we

replaced that, that took a lot of effort, but we replaced that with Wasmi, which is more like a pure interpreter, and that works, but that is much slower than Wasmail as well. So again, one of our things on the to-do list is to go back, reintegrate Wasmer in a way that is supported by SGX. So can I then, like, so then in that case, like, if there is, can I opt to have certain contracts not run in the SGX, where, like, let's say there is. just, you know, heavy computation functions that, you know, I have no reason to keep private.

Can I, you know, reduce my gas costs by running those not in the SGX? Not right now, but that's a fantastic idea. From like a scalability perspective then here, right? Where would you place like the limits of where like SGX computation can go? Like, you know, we have a spectrum, you know, like, you know, like, you know, like, like, like, Do you think it will, is SGX computation today, like is it, can you do more than you can in the EVM? Or, you know, could it ever get to native Cosmwasum scale or like even Solana style scale? Where do you see like the limits are going to, or, you know, assuming you can get all these optimizations you want, where do you think it'll end up landing?

Yeah, I think that won't be an issue. I think these are engineering challenges and I think at the end of the day, the slowdown, there will be slowdown. It won't be meaningful. I think the one place where I'm not sure is in cases where you need to access, you know, let's say, arrays of information. Like, you know, you want to access like, like, you want to run through all of the users at the same time. That might be the only place where I think it's going to be problematic at the end, but everything else I think is, you know, we can resolve it and we will resolve it.

So secret network is IBC enabled, right? So basically how does the secret part work across different cosmos-based blockchain? So can you kind of can any IBC enabled blockchain query smart contracts or what how does it work? So right now we kind of did what Tara did and I think most chains. Sonny, I don't know if you remember, but you and her co-founder with Osmosis, you gave us the tip to do this. We only enabled, like, you know,

sending native assets on IBC right now between chain to chain. We do not support calling one contract on our chain and on another IBC chain. That is something that's going to happen in, let's say, IBC 2.0 upgrade. upgrade, which is going to happen sometime in 2022. But so far, what you can do is you can transfer assets and you can also do something which

we are doing. Like, for example, you can take Osmo or Adam or Luna or UST and you can transfer them to our chain and then via ABC and then you can wrap them as a token and that token gives you privacy. So for example, if you want to trade your Osmo privately, then you can move it to secret network, wrap it, where I can have a UI to do it very simply, and then you can transact with it, you can split the different wallets,

you can add it to Secret Swap, which is our AMM, and trade there and convert to something else, and then you can, you know, exit back in I. You can unwrap it and exit back through IBC to whatever chain in IBC that you want. So those are the capabilities that are enabled right now. And I was wondering, so can you use the SGX to do multi-party computation? I mean, technically what we're doing is multi-party computation, but we are using SGX. If the question is whether we can do multi-party computation like in its pure cryptographic form,

then I would say that's a very different implementation. we can do it. It can use SGX to simplify something. So some element of SGX can, you know, make the NPC protocols that you use simpler because, you know, you can try, if you take an assumption, for example, that SGX, you know, can protect correctness

and, you know, whoever is running the code inside of an al-Aclave will not break protocol. So you can use more like what we know is semi-but, honest but curious protocol. which basically assume participants would try to leak data but they will not change the protocol. So again, SGX can help us

in developing like these kind of solutions in a much simpler and more scalable way. But, you know, they're another tool. They're not like, it's not that you get MPC for free. It's still a very complicated thing to do. And, you know, we talked about scalability so much. I think MPC for general purpose computations unfortunately the the the the the the the the the the the the cost reduction the sorry the the the the the cost

increase and the speed reduction would be so heavy that I doubt any developer would use that unfortunately today so yeah you know I think one of the interesting things that I you know how what I see a secret network is doing in a lot of ways is you know I think the SGX as a compute system, like, you know, it provides you basically, like, high levels of, you know, safety and privacy, but on its own, it never, it doesn't provide liveliness. And so one of the things I see it as, you know, I pitch secret network as when I explain it to people is like, I call it like, it's like a distributed SGX, right, where it adds liveliness to, to the, to the SGX platform. And like, so, you know, one thing is, like, could we start to,

we also use it for things like being a custodian, for example. So, you know, I think like, for example, I know the avalanche bridge to Ethereum is basically running on a single SGX right now, which is kind of crazy to me. But like, you know, partially, it's kind of crazy mostly because, you know, if it's a single SGX, you know, it could have a lot of, you know, liveless issues where, like, sure, you can trust the SGX as safety properties, but if that machine breaks down, like, we're in for a lot of trouble, right? And so, like, could we use the secret network as a distributed custodian in that sort of way? I think we can.

And we actually have some grants that are, you know, taking that direction. We have a developer, a co-developer called Asaf. He just made an interesting tweet about how, like, DOWS can now control, like, you know, private keys inside of their contracts. And then with IBC and other things, like, essentially. like do stuff on other chains through the Dow because it controls, you know, the, the, the keys and yes, and liveness, liveness is pretty much guaranteed. So by the way, I like your pitch. I'm going to, I'm going to steal that if that's okay.

So here's the other part that, you know, the big question I have for SGAX. And so, you know, you know, I, you know, we've worked a lot on like front running resistance related things and like mempool privacy. And I know that's like something that the SGX also, you know, secret network provides in a lot of ways. But for me, one of the biggest concerns I've had with like the SGX is, you know, we see that like there seem to be on a semi-regular basis, like flaws found in the SGX and the SGX and like, you know, people are able to find vulnerabilities. And, you know, in my opinion, how I see it is like right now, the the value in finding a vulnerability, like, you know, there isn't even that high of a benefit.

Right now it's been mostly like, you know, just academic research teams that have been finding these vulnerabilities. But, you know, as there's more and more economic value that's happening, and, you know, if you can extract MEV by breaking the security model of an SGX and extract billions of dollars of MEV, that's essentially a billion dollar bounty on breaking the SGX. And is that like, do you think that, the SGX can sustain that level of security budget? I mean, I guess it's, you know, I'm speaking from a position. I do believe that's the case.

I do believe for many, many use cases, that's definitely the case. I like the idea that Secret Network is the biggest honeypot for testing secure enclaves at scale. So far, we didn't have problems. and, you know, anytime there's a flaw, we immediately patch it, and through a network upgrade, you know, you make sure that everyone is patched. We are very, very strict about it, even stricter than most other players I've seen using SGX. But I guess it's to be seen. From my perspective, look, as you know, my background is in cryptography, MPC.

Like, I am very, very much excited in the future. to include other kinds of technologies that are, you know, more cryptographic in nature into secret network. At this point, like, I'm more concerned that, you know, developers would not be willing to take the slowdown and the cost increase of using purely cryptographic technologies, and many of them have other issues and constraints that people often overlook when they present them. So to us it's a, it's a balancing act. Like, we do feel this is the best solution for the problem right now.

We like the idea that it allows us to check, you know, things at scale with high value. And then, you know, over time, hopefully that would help us to make our system enclaves, SGX specifically, enclaves in general, more and more robust. But at the end of the day, like, if the technology allows, if the users and developers demand it, like, I would be super excited to look again at MPC and even home-offer encryption solutions, at least to, you know, to some aspects and some use cases that are being built on our network. And I really want to talk about the ecosystem, but now I have to follow up again. Damn you, Sonny. So basically, if I'm a node in the network.

And I, how would I know or how would I find out about the fact that some SGX was compromised or is being viewed by something that's not the SGX? I mean, so basically how would I catch on? Or I mean, how, is there like, is there a canary in the coal mine somewhere? Because basically with a lot of the shielded protocols, there's no way to actually do check sums, right? the ones there's so first of all I do want to say that most vulnerabilities they're academic researchers and they are way way way overblown

there's been very few of them especially the ones in the early days which were I think devastating and easy to exploit not in a or not easy but like you know possible to exploit not in a

laboratory setting. But putting that aside, you know, once there's, once there's, you know, an SGX issue, then we can trigger a hard fork. We can ask everyone to re-register, you know, the registration protocol that we mentioned. We can trigger a hard fork or post like an enclave update. And then everyone has to re-register. Every outfog that happens, everyone has to go through the registration protocol again. And at that point, if they are now running the fully patched, you know, version of their SGX in terms of firmware and software, then they won't be able to register. So that's, and that's how people know. Like, you know, there's a hardfuck in the network.

Yeah. So, but that's only if it, if it's brought to your attention, right, that there is a vulnerability in the SEP. Jack. So basically how would I, how would you find out that there's a vulnerability if it's not, you know, someone, you know, white or gray hat who kind of makes this publicly available information? Yeah, I see your question. If someone want to find a vulnerability, it's a black head. They, they don't disclose these. Intel isn't aware of it. We're not aware of it. Then what happened? Could that could not exist? The answer is yes. I mean, I there's no, there's no way to protect against that, you know, very much like with the Zcash, like, you know,

a publication there was a math equation error and you could have done like, like you could leak the keys if I remember correctly. And if someone had found it and not disclosed it and someone did, then they could exploit it. So there's no way we would know in that situation. Okay, there's no way to know. Okay, cool. So let's move on. on to the ecosystem.

So tell us about the kind of applications that are currently running on secret network. Yeah, I'm pretty excited about, we have a few dexes that are front-running resistant. They're doing fairly okay, not as great as osmosis, but they are used. I'm an avid user of them. The front-running resistance is really cool. The privacy aspect is really cool. we have over 100 million, I think, of assets, maybe even, I mean, maybe more,

depends on our account, in our network that have either originated by projects in our network or have been brought from Ethereum because we have an Ethereum bridge from Binus Smart Chain because we have a Binance Small Chain and from other IBC and Apple Networks. So a lot of use cases around that. then there's, we've released the secret NFT standard,

which basically allows you to, you know, launch NFT, NFT collections. And it's the point of being a secret NFT is that, you know, you can define private metadata such that only the owner can actually see the data. And that owner can give viewing access to other parties, if so, they choose. And where, you know, there's, a big, well-published, we announced yesterday with Cretton-Tarantino, that there's an auction for his original screenplay of Pulp Fiction, which is something that no one has ever seen.

It's like in his handwriting, there's a lot of things and details about the original script, notes to himself, like markups, markdowns, like, you know, comments, stuff that hasn't been in the final movie. And that has been something that he kept private for 25 years. And now we're selling those as secret NFTs. And essentially, that's going to be in an auction in two weeks. And only the people who buy it would be able to see it. And then, you know, they can decide if they want to give access to other people or not.

So that's another use case. There's just a slew, like so many NFT use cases right now. There's a marketplace called Stash that launch. a month ago and there's been I think like two dozens of NFT drops and there's like new one every day and each one of them use like the the privacy aspects in very very interesting ways there are a few games building on our network and I think what we can provide that other networks can provide is that we can allow you to build your games with like hidden hidden game state on chain.

So, for example, if you do poker, you can do it fully on chain because you can keep the cards themselves, you know, private for each participant until the right moment. So we've seen a lot of that. And we're actually seen, there are the DFI use cases, so there's private lending coming out this month by a company called Sienna and other, there's shade, which is going to be the first privacy preserve every stable coin. algorithmic stable coin. It's kind of a mix between Olympus Dow reserve currency and a fully pegged privacy

preservative stable coin. And then there are a bit more lofty ideas that I think are just going to be, they're going to take time to be adopted, but I'm really excited about them. There's Data Vault, which is a secure data marketplace for all kinds of use cases. There's a doctor trying to work on putting some form of medical data on the blockchain and allowing like physicians to look into that. There's a company building credit scoring solution so that, you know, privacy preserving credit scorer so you can do maybe like stuff like under collateralized loans on the blockchain.

So a lot of things are like being built right now. Yeah, I think that's really cool. you know, I think, well, you know, a lot of these use cases makes a lot of sense. One thing I do want to ask, though, is like, you know, for the NFTs, it seems like, you know, at least from my social networks and stuff, you know, I see a lot of people are pretty excited about like the NFTs happening on Secret Network. Why do NFTs really want that much privacy? You know, it seems that usually NFTs are mostly about status signaling and I want people to know

that I own the, like, hey, check out and look at my collection of NFTs. What is sort of what's driving the user demand behind like private NFTs? Well, first of all, you can do really interesting things that you can do. Like we're just scratching the surface. So like, you know, there's like the, they're like now redacted drops. Well, you know, you see you can brag that you have the NFT. You see it with a watermark or low resolution or a part of it is redacted. It's like a redacted club.

Like the eyes are redacted and stuff like that. But then the full picture. you see for yourself, there was secret punks where like, you know, the background was, was only the owner could see. There's secret skulls, which created a really interesting economic dynamics. The idea was that you mint or excavate a skull, and that has its base properties, that's visible, but now you have several times where you can reveal traits, like one by one. And that created an interesting economic dynamic where people were like, okay, maybe the things that are worth the most is just selling a fully hidden sky with all the traits still hidden.

Or maybe I reveal like one trait, you know, kind of like in blackjack, I got like a really, really rare trade. But maybe the other ones are like, you know, they're crap and it's not really worth that much. So now there's an interesting game theory. Do I sell it now? or do I keep opening and hopefully even increase the value farther? So there's a lot of interesting things you can do that you can't do with normal NFTs. And if you want status, then again, you can reveal a portion or a low resolution version. Or you can reveal the whole thing.

That's fine. There's Adder's collection, which does reveal the whole thing. But then the private metadata is you added your telegram handle, and that adds you to a secret chat. that no one else can know about or be added to. So, you know, it's an interesting experiment, I feel. And with Credit Tarantino, I can tell you 100%. He's been approached by a lot of NFT companies and providers, and he said no to all of them,

because he said, what is the point of me uploading something that is already public, and then everyone can see it and download it? And then why would anyone buy that if they can already get, like, you know, get a copy of it. And the idea of like keeping it a secret until the first person buys it, that really clicked with him. And we got that feedback from a lot of artists

since then that we talk to. So apparently there's a need. So, Guy, thank you so much for coming on. Where can people learn about secret network and find the docs and find the grant program and so on? Right. So if you go to secret dot network, And that's SCRT.network.

You should be able to find pretty much everything that, you know, you need. And then you can find there's the ad secret network at Twitter. And we have a Discord. And you can follow me at Ed Guy Zis, G-U-Y-Z-Y-S on Twitter. And if you want to apply for a grant, you know, just hit me up on Twitter personally. or come to our Discord, come to the Dev Channel or the general channel, say, hey, we have a grant idea, we want to talk about it, and either myself or one of the team members will talk to you. Perfect. Thank you, Guy.

Thank you very much. Thank you for joining us on this week's episode. We release new episodes every week. You can find and subscribe to the show on iTunes, Spotify, YouTube, SoundCloud, or wherever you listen to podcasts. And if you have a Google Home or Alexa device, you can tell it to listen to the latest episode of the Epicenter podcast. Go to epicenter.tv slash subscribe for a full list of places where you can watch and listen. And while you're there, be sure to sign that for the newsletter, so you get new episodes in your inbox as they're released.

If you want to interact with us, guests or other podcast listeners, you can follow us on Twitter. And please leave us a review on iTunes. It helps people find the show, and we're always happy to read them. So thanks so much, and we look forward to being back next week.