1 00:00:00,360 --> 00:00:04,200 What we were designing was a system where users had this 2 00:00:04,200 --> 00:00:08,080 privacy utilizing 0 knowledge proofs and every private 3 00:00:08,080 --> 00:00:12,280 transaction that one performed generated an encrypted 4 00:00:12,280 --> 00:00:14,280 transaction that was stored on chain. 5 00:00:14,640 --> 00:00:19,080 And then we had a dedicated network of notes that using MPC 6 00:00:19,200 --> 00:00:22,400 was able to screen those transactions essentially. 7 00:00:22,760 --> 00:00:26,480 But importantly, there was no trusted entity that could screen 8 00:00:26,480 --> 00:00:29,040 or block a transaction. It was the network as a whole 9 00:00:29,200 --> 00:00:33,040 that ran secure multi party computations, overdose encrypted 10 00:00:33,040 --> 00:00:37,320 transactions, arbitrary program execution in a confidential 11 00:00:37,320 --> 00:00:41,120 encrypted way, but to also have the program itself be fully 12 00:00:41,120 --> 00:00:45,680 encrypted and to have encrypted random access memory. 13 00:00:45,680 --> 00:00:49,480 This sort of replacement for you purchasing some trusted 14 00:00:49,480 --> 00:00:52,320 execution environment. Now you can use this global 15 00:00:52,320 --> 00:00:54,960 supercomputer to execute anything. 16 00:01:09,080 --> 00:01:12,200 If you're looking to stake your crypto with confidence, look no 17 00:01:12,200 --> 00:01:16,000 further than course one. More than 150,000 delegators, 18 00:01:16,000 --> 00:01:19,120 including institutions like Bit Go, Pantera Capital, and Ledger 19 00:01:19,120 --> 00:01:21,480 Trust Course One. With their assets, they support 20 00:01:21,480 --> 00:01:23,920 over 50 block chains and their leaders in governance or 21 00:01:23,920 --> 00:01:27,000 networks like Cosmos, ensuring your stake is responsibly 22 00:01:27,000 --> 00:01:29,440 managed. Thanks to the advanced MEB 23 00:01:29,440 --> 00:01:32,000 research, you can also enjoy the highest staking rewards. 24 00:01:32,480 --> 00:01:35,520 You can stake directly from your preferred wallet, set up a white 25 00:01:35,520 --> 00:01:39,280 label note, restake your assets on Eigenia or Symbiotic, or use 26 00:01:39,280 --> 00:01:41,560 the SDK for multi chain staking in your app. 27 00:01:41,920 --> 00:01:44,960 Learn more at Chorus .1 and start staking today. 28 00:01:46,320 --> 00:01:49,560 This episode is proudly brought to you by Gnosis, a collective 29 00:01:49,560 --> 00:01:52,040 dedicated to advancing a decentralized future. 30 00:01:52,520 --> 00:01:56,720 Nosys leads innovation with Circles, Nosys Pay and Metri, 31 00:01:56,800 --> 00:01:59,000 reshaping open banking and money. 32 00:01:59,320 --> 00:02:02,440 With Hashi and Nosys VPN, they're building a more 33 00:02:02,440 --> 00:02:04,920 resilient, privacy focused Internet. 34 00:02:05,360 --> 00:02:09,120 If you're looking for an L1 to launch your project, Nosys Chain 35 00:02:09,120 --> 00:02:12,480 offers the same development environment as Ethereum with 36 00:02:12,480 --> 00:02:16,560 lower transaction fees. It's supported by over 200,000 37 00:02:16,560 --> 00:02:20,000 ballot errors, making Nosys Chain a reliable and credibly 38 00:02:20,000 --> 00:02:21,920 neutral foundation for your applications. 39 00:02:22,440 --> 00:02:26,240 Gnosis Dow drives Gnosis governance, where every voice 40 00:02:26,240 --> 00:02:28,960 matters. Join the Gnosis community in the 41 00:02:28,960 --> 00:02:33,360 Gnosis Dow forum today. Deploy on the EVM compatible 42 00:02:33,360 --> 00:02:38,480 Gnosis Chain or secure the network with just one GNO and 43 00:02:38,480 --> 00:02:41,520 affordable hardware. Start your decentralization 44 00:02:41,520 --> 00:02:46,160 journey today at gnosis dot IO. Welcome to epicenter of the 45 00:02:46,160 --> 00:02:48,000 show, which talks about the technologies, projects and 46 00:02:48,000 --> 00:02:51,320 people driving decentralization and the global blockchain 47 00:02:51,320 --> 00:02:53,040 revolution. I'm Sebastian Coutura and I'm 48 00:02:53,040 --> 00:02:54,600 here with my Co host, Felix Lutch. 49 00:02:54,960 --> 00:02:57,200 Today we're speaking with Yannick Shada. 50 00:02:57,200 --> 00:02:59,440 He's the CEO and Co founder of Arkham. 51 00:03:00,000 --> 00:03:04,760 It is a private compute platform that allows for all sorts of 52 00:03:04,760 --> 00:03:09,520 interesting use cases, privacy in crypto and beyond. 53 00:03:09,520 --> 00:03:12,960 So we'll be chatting with him today about Ark M, the 54 00:03:13,000 --> 00:03:15,960 architecture, their use of MPC, and much more. 55 00:03:16,480 --> 00:03:17,640 Yeah. Thanks for joining us today. 56 00:03:19,040 --> 00:03:20,840 Thanks for having me, Sebastian and Felix. 57 00:03:20,960 --> 00:03:23,760 I'm very excited. Yeah. 58 00:03:23,760 --> 00:03:26,920 So tell us a little bit about your background and how you got 59 00:03:26,920 --> 00:03:31,560 involved in in the encryption and privacy space and how do you 60 00:03:31,680 --> 00:03:33,720 how you ended up working on Ark M? 61 00:03:35,200 --> 00:03:40,760 Yeah, sure. So I think the reason why, why 62 00:03:41,360 --> 00:03:45,760 I'm in the space of, of building Arxium, building confidential 63 00:03:45,760 --> 00:03:48,800 computing, decentralized confidential computing and 64 00:03:48,800 --> 00:03:52,040 privacy technology. At the end of the day, it might 65 00:03:52,040 --> 00:03:55,600 boil down to me as a small child reading 1984. 66 00:03:55,640 --> 00:03:58,160 I think that might be the, the honest answer. 67 00:03:58,520 --> 00:04:03,000 I think that that really shaped my my perception of the world 68 00:04:03,000 --> 00:04:08,200 and and my views of how the world should work and how how 69 00:04:08,200 --> 00:04:13,400 privacy and freedom matters. And reading that as a child I 70 00:04:13,400 --> 00:04:15,320 think really, really influenced me. 71 00:04:15,840 --> 00:04:20,320 So at a similar age, I started programming, teaching myself 72 00:04:20,320 --> 00:04:25,200 programming, then studied law for a bit and then through 73 00:04:25,200 --> 00:04:29,560 founding my first start up pivoted to mathematics and 74 00:04:29,560 --> 00:04:32,160 computer science. In the process away from 75 00:04:32,160 --> 00:04:36,920 studying trust law and then through the study of, of 76 00:04:36,920 --> 00:04:40,000 mathematics and computer science, I met my Co founders, 77 00:04:41,280 --> 00:04:45,560 basically one of us caring about elliptic curves at that point 78 00:04:45,560 --> 00:04:48,760 because that's what we what we learned about in university and 79 00:04:48,760 --> 00:04:52,720 then getting into zero knowledge proofs and through the process 80 00:04:52,720 --> 00:04:57,200 of that and they ended up founding Archaeum, which back 81 00:04:57,200 --> 00:05:01,960 then was called elusive. And yeah, with elusive we, we 82 00:05:01,960 --> 00:05:05,520 focused on building transactional on chain privacy 83 00:05:06,480 --> 00:05:12,240 and we found the edit twist I guess of, of adding trust, less 84 00:05:12,600 --> 00:05:17,480 decentralized compliance so that there's both privacy and still 85 00:05:18,160 --> 00:05:20,440 safety on the end of of the users. 86 00:05:20,440 --> 00:05:25,160 So unwanted illicit behaviour could be excluded from from, 87 00:05:25,160 --> 00:05:28,320 from this. Yeah, on chain on chain privacy 88 00:05:28,320 --> 00:05:31,200 architecture. And for that we leveraged 89 00:05:31,320 --> 00:05:34,800 confidential computing with secure multi party computations. 90 00:05:35,920 --> 00:05:38,240 And through the process of designing the system and 91 00:05:38,240 --> 00:05:42,360 building this technology, what we realized is the the huge 92 00:05:42,360 --> 00:05:47,680 potential and the revolutionary potential of being able to run 93 00:05:47,680 --> 00:05:51,600 arbitrary computations over encrypted data without having to 94 00:05:51,600 --> 00:05:56,000 decrypted data first. So data in use can remain fully 95 00:05:56,000 --> 00:05:59,880 encrypted and anything can be processed on top of the data. 96 00:05:59,880 --> 00:06:04,560 And so that was really a pivotal moment, this realization for us, 97 00:06:05,120 --> 00:06:09,480 which then allowed us to to evolve further into Arcum and 98 00:06:09,480 --> 00:06:14,040 fully focus just on providing this what we like to call 99 00:06:14,320 --> 00:06:18,640 distributed global supercomputer that allows for confidential 100 00:06:18,640 --> 00:06:21,440 computing. Awesome. 101 00:06:21,640 --> 00:06:24,360 Thanks for the quick overview. We're going to dive a lot into 102 00:06:24,360 --> 00:06:26,640 Arcum over the course of this. Of course. 103 00:06:26,720 --> 00:06:30,760 I think for me also interesting because that's like how I got to 104 00:06:30,760 --> 00:06:33,160 know you. I think working on Elusive and 105 00:06:33,160 --> 00:06:35,920 also like working in, in the Solana ecosystem. 106 00:06:35,920 --> 00:06:39,240 Can you maybe break down how you, how you start in Solana 107 00:06:39,240 --> 00:06:42,680 and, and couldn't know kind of why you, how you came to the 108 00:06:42,680 --> 00:06:44,600 conclusion to add this like compliance angle? 109 00:06:44,600 --> 00:06:46,240 I think that was like kind of like one of the main 110 00:06:46,560 --> 00:06:51,080 differentiators there in, in, in what you were building or in 111 00:06:51,080 --> 00:06:53,320 Solana. Yeah, sure. 112 00:06:53,400 --> 00:06:58,680 And so I think how we got into Solana is the is the story of of 113 00:06:58,680 --> 00:07:00,560 many teams that are building on Solana. 114 00:07:00,560 --> 00:07:02,920 It was really the the developer ecosystem. 115 00:07:03,200 --> 00:07:10,280 And so the the final Co founder of our team, actually I met the 116 00:07:10,280 --> 00:07:15,280 Solana hacker house. So in the year 22, there were a 117 00:07:15,280 --> 00:07:21,280 lot of hacker houses and and this really allowed developers 118 00:07:21,320 --> 00:07:25,920 wanting to build new interesting projects to meet up to, to talk 119 00:07:25,920 --> 00:07:30,200 with experienced founders and then yeah, test, test the 120 00:07:30,200 --> 00:07:33,720 systems that they were building. So that's what we also did how 121 00:07:33,720 --> 00:07:36,480 we came, came about building on Solana. 122 00:07:37,040 --> 00:07:42,840 And yeah, back in the day with elusive, what we, what we were 123 00:07:43,440 --> 00:07:47,200 building was essentially AC cash like on chain privacy system, 124 00:07:47,200 --> 00:07:51,680 which utilised 0 knowledge proofs as as core primitive. 125 00:07:52,080 --> 00:07:58,120 And the issue that basically all of those systems face at some 126 00:07:58,120 --> 00:08:01,240 point really is compliance concerns, right? 127 00:08:01,240 --> 00:08:06,400 Because we've, we've seen that Tornado Cash essentially, right. 128 00:08:06,400 --> 00:08:11,960 So with Tornado Cash, there were enforcement actions by different 129 00:08:11,960 --> 00:08:16,440 governmental agencies because, yeah, they claimed that Tornado 130 00:08:16,440 --> 00:08:21,200 Cash didn't prevent malicious behaviour on the on the 131 00:08:21,200 --> 00:08:25,160 platform. And if one utilizes mathematics 132 00:08:25,520 --> 00:08:30,120 to provide perfect privacy guarantees, yeah, that's, that's 133 00:08:30,120 --> 00:08:33,480 the issue that they run into. And So what we were designing 134 00:08:34,520 --> 00:08:38,400 was a system where users had this privacy utilising 0 135 00:08:38,400 --> 00:08:42,360 knowledge proofs and every private transaction that one 136 00:08:42,360 --> 00:08:46,760 performed generated an encrypted transaction that was stored on 137 00:08:46,760 --> 00:08:48,720 chain. And then we had a dedicated 138 00:08:48,720 --> 00:08:53,920 network of nodes that using MPC was able to screen those 139 00:08:53,920 --> 00:08:57,160 transactions essentially. But importantly there was no 140 00:08:57,160 --> 00:09:00,320 trusted entity that could screen or block a transaction. 141 00:09:00,320 --> 00:09:04,000 It was the network as a whole that ran secure multi party 142 00:09:04,000 --> 00:09:08,800 computations, overdose encrypted transactions and essentially in 143 00:09:08,800 --> 00:09:12,560 a within a black box. This virtual black box were able 144 00:09:12,560 --> 00:09:16,120 to look into the transactions and assess what happened and 145 00:09:16,120 --> 00:09:20,640 then they could find external consensus over, yeah, malicious 146 00:09:20,640 --> 00:09:23,800 parties that that tries to use that system and then after the 147 00:09:23,800 --> 00:09:28,200 fact reveal, reveal that the corresponding information. 148 00:09:28,560 --> 00:09:35,160 And so that was extremely powerful because yeah, prior 149 00:09:35,160 --> 00:09:39,800 systems really attempted to to add compliance by screening 150 00:09:39,800 --> 00:09:44,800 transactions upfront. And with this systems as a 151 00:09:44,800 --> 00:09:49,840 screening after the fact ex post was possible, which I think 152 00:09:51,040 --> 00:09:55,120 would be the ideal solution. And that's something that is 153 00:09:55,120 --> 00:10:00,400 possible to to build with RKM. But we really realised that, 154 00:10:02,040 --> 00:10:04,440 yeah, I think through the technology that we were 155 00:10:04,440 --> 00:10:07,760 developing and we'll we'll dive more into this later, I guess. 156 00:10:08,480 --> 00:10:12,800 But the complexity of this MPC technology, I think there was 157 00:10:12,800 --> 00:10:16,000 just one area we had to focus on. 158 00:10:16,000 --> 00:10:19,400 And we really saw our strengths in, in building this computing 159 00:10:19,400 --> 00:10:24,000 platform and optimising the compute both for trustlessness 160 00:10:24,000 --> 00:10:27,320 but also performance. And so that's what we ended up 161 00:10:27,320 --> 00:10:30,600 doing. And you know, in the case of, 162 00:10:31,440 --> 00:10:34,720 you know, you mentioned Tornado Cash, like I, when I, when I 163 00:10:34,720 --> 00:10:38,600 heard about that, I, I couldn't help but be reminded of, you 164 00:10:38,600 --> 00:10:40,760 know, the, the cypherpunk stories of the 90s. 165 00:10:40,760 --> 00:10:42,600 And we had Mark Miller on the podcast. 166 00:10:42,600 --> 00:10:46,040 Tell us about how you he used to print the RSA algorithm on 167 00:10:46,040 --> 00:10:48,720 T-shirts because the US government considered that 168 00:10:48,840 --> 00:10:53,560 encryption technologies were, were considered under U.S. law 169 00:10:53,560 --> 00:10:56,560 to be, to be weapons like to be munitions. 170 00:10:56,880 --> 00:10:58,920 And so therefore, you know, you couldn't export them. 171 00:10:58,920 --> 00:11:02,480 And there was this whole, you know, legal threat and sort of 172 00:11:03,480 --> 00:11:06,880 threat of persecution on, on those people in the 90s, you 173 00:11:06,880 --> 00:11:11,520 know, that that were simply just freely expressing ideas and, 174 00:11:11,520 --> 00:11:16,360 and, and more to the point, like just making math public. 175 00:11:17,400 --> 00:11:20,360 And so like, I, I heard that, you know, the tornado cast story 176 00:11:20,360 --> 00:11:23,560 and like it, it felt to me like very similar where, you know, 177 00:11:23,560 --> 00:11:26,680 these guys basically like wrote math that this stuff was the 178 00:11:26,680 --> 00:11:29,040 stuff exists. It cannot be stopped. 179 00:11:29,040 --> 00:11:31,720 And, and I, I think that we'll look back on turn into cash in 180 00:11:31,720 --> 00:11:34,880 the same way that we look back on, you know, the, the sucker 181 00:11:34,880 --> 00:11:36,640 punks in the 90s and what they were doing. 182 00:11:37,560 --> 00:11:41,360 There's really, you know, little one can do to prevent malicious 183 00:11:41,360 --> 00:11:43,280 activity when you're using encrypted technologies. 184 00:11:43,280 --> 00:11:46,080 I think it's like a huge societal debate, but I hope one 185 00:11:46,080 --> 00:11:49,360 that, you know, people that sort of subscribe to the idea that 186 00:11:49,560 --> 00:11:54,040 encryption, you know, is just freedom of speech and, you know, 187 00:11:54,040 --> 00:11:57,760 is sort of like a right. I hope that, you know, those 188 00:11:57,760 --> 00:11:59,320 people will fall on the right side of history. 189 00:11:59,600 --> 00:12:02,560 You know, having you, you, you said earlier you came into the 190 00:12:02,560 --> 00:12:05,080 space and you were kind of inspired to work in crypto, 191 00:12:05,320 --> 00:12:09,040 having read in 1984, you know, how did you, how did it make you 192 00:12:09,040 --> 00:12:13,480 feel that, you know, you were sort of constrained to, to build 193 00:12:13,480 --> 00:12:19,360 a technology that enabled compliance when you, you had 194 00:12:19,360 --> 00:12:24,120 such this, you know, this very strong background and and sort 195 00:12:24,120 --> 00:12:29,520 of ideological pedigree of like non compliance in, in, in, in 196 00:12:29,520 --> 00:12:34,200 that sense. Yeah, so I I think that. 197 00:12:36,640 --> 00:12:43,320 So first of all, yeah, I am 100% on this on this cyberpunk track. 198 00:12:43,920 --> 00:12:47,840 I think one of my greatest accomplishments in the in the 199 00:12:47,840 --> 00:12:52,720 privacy space would be getting my entire family to to your 200 00:12:52,720 --> 00:12:57,400 signal and having the entire family group chat be be present 201 00:12:57,400 --> 00:13:02,040 on Signal instead of WhatsApp. So I think this this compliance 202 00:13:02,040 --> 00:13:06,160 question is an interesting one. And the way I think about it 203 00:13:06,160 --> 00:13:11,960 really is that we gave control in the hands of the people using 204 00:13:11,960 --> 00:13:13,680 it. At the end of the day, there was 205 00:13:13,680 --> 00:13:17,600 no external action of enforcing compliance. 206 00:13:17,600 --> 00:13:23,000 It was essentially being able to have distributed consensus and 207 00:13:23,160 --> 00:13:26,200 giving users the option to use whatever system. 208 00:13:26,760 --> 00:13:30,800 So it's the design that that that we designed back in the day 209 00:13:30,800 --> 00:13:34,960 with illusive really was decentralized compliance. 210 00:13:35,720 --> 00:13:40,240 So no centralized actor should be able to to have any control. 211 00:13:40,360 --> 00:13:42,920 It should be the users that have control. 212 00:13:42,920 --> 00:13:49,160 And I think at the end of the day, and yeah, we never ended up 213 00:13:49,160 --> 00:13:52,800 getting to this point to to see that an action and an experience 214 00:13:52,800 --> 00:13:57,040 those those those game theory and network effects. 215 00:13:57,040 --> 00:14:00,840 But I think at the end of the day, yeah, it boils down to do 216 00:14:01,800 --> 00:14:08,040 users want specific other users using the servers for specific 217 00:14:08,040 --> 00:14:13,440 kinds of of of use cases. And I think it's a bit more easy 218 00:14:14,080 --> 00:14:19,720 to to have these mechanisms with this, yeah, with those financial 219 00:14:19,720 --> 00:14:24,160 mechanisms attached. Whereas it's way more different 220 00:14:24,160 --> 00:14:28,200 if it's just pure, yeah, expression of ideas, right. 221 00:14:28,200 --> 00:14:32,280 So I think that's a system that made sense that at the end of 222 00:14:32,280 --> 00:14:37,520 the day found natural equilibrium between both ends. 223 00:14:37,640 --> 00:14:41,240 Yeah, it's, it's hard not to not to also bring up, you know, the 224 00:14:42,280 --> 00:14:47,560 the whole story around the the Telegram founder who was 225 00:14:47,560 --> 00:14:50,560 arrested in France, I think like last week. 226 00:14:51,800 --> 00:14:54,440 Yeah. Any any thoughts on, on, on 227 00:14:54,440 --> 00:14:57,600 that? And you know what it means for 228 00:14:57,600 --> 00:15:01,160 the for the state of privacy technologies in Europe. 229 00:15:03,040 --> 00:15:07,640 Yeah. I to be honest, it's very, it's 230 00:15:07,640 --> 00:15:12,520 very difficult to say. I think Telegram is, is is 231 00:15:12,520 --> 00:15:16,520 difficult, is difficult for me because on the, on the 232 00:15:16,520 --> 00:15:22,960 encryption side of things, Telegram always, especially in 233 00:15:23,480 --> 00:15:26,840 yeah, more, more mainstream media, I think is being 234 00:15:26,840 --> 00:15:31,280 portrayed as this super encrypted private chatting 235 00:15:31,280 --> 00:15:33,200 platform that that cannot be hacked. 236 00:15:34,000 --> 00:15:38,880 Whereas in reality, there's no default, Yeah, encrypted 237 00:15:38,880 --> 00:15:40,440 chatting between two peers, right? 238 00:15:41,240 --> 00:15:45,520 So I think the story is is difficult. 239 00:15:45,560 --> 00:15:49,480 Yeah, it's, it's, it's interesting to see at least 240 00:15:49,480 --> 00:15:51,160 like, you know, here in France, I've been watching main 241 00:15:51,160 --> 00:15:56,560 mainstream media talk about talk about Telegram as this encrypted 242 00:15:56,560 --> 00:15:59,040 messaging. In fact, they they, they, they 243 00:15:59,040 --> 00:16:00,480 don't even use the word encrypted. 244 00:16:00,480 --> 00:16:03,680 They use this this other word that in French that that doesn't 245 00:16:03,680 --> 00:16:07,840 even mean encrypted. I mean, you know, and it's like, 246 00:16:07,960 --> 00:16:10,840 it's as if they were calling it a, you know, a cyber messenger 247 00:16:10,840 --> 00:16:12,160 instead of an encrypted messenger. 248 00:16:12,960 --> 00:16:16,640 And, and it's, it's really painted as this kind of like 249 00:16:16,640 --> 00:16:19,160 black box thing, right? That you can tell that the story 250 00:16:19,160 --> 00:16:22,040 is spun in such a way when in fact, you know, like anybody who 251 00:16:22,040 --> 00:16:25,320 uses WhatsApp, you know, is in fact using encrypted technology 252 00:16:25,320 --> 00:16:27,840 and anybody who uses Apple messenger is using encrypted 253 00:16:27,840 --> 00:16:29,680 technology. And Telegram is really painted 254 00:16:29,680 --> 00:16:33,400 with this, with this very negative sort of lens. 255 00:16:33,400 --> 00:16:36,640 So it's, it's interesting to see how even the mainstream media 256 00:16:36,640 --> 00:16:39,120 here, and I'm sure probably in Germany and other places as well 257 00:16:39,120 --> 00:16:42,240 as like very biased against these technologies for some 258 00:16:42,240 --> 00:16:43,960 reason. But anyway, not to make this all 259 00:16:43,960 --> 00:16:47,640 about, about that, you know, we do want to talk about RKM and, 260 00:16:47,640 --> 00:16:50,280 and what you guys are building. So let's, let's talk about, you 261 00:16:50,280 --> 00:16:53,320 know, confidential computing. So, you know, what does that 262 00:16:53,320 --> 00:16:57,360 mean and what are the different ways that you know it has been 263 00:16:57,360 --> 00:17:00,920 implemented in the past and what's kind of new about the the 264 00:17:00,920 --> 00:17:02,160 way you guys are going about building it? 265 00:17:03,200 --> 00:17:07,480 So yeah, I think confidential computing has been around for 266 00:17:07,480 --> 00:17:11,200 for quite some time already. And at the end of the day it 267 00:17:11,200 --> 00:17:16,680 means that computations can be performed over encrypted data 268 00:17:17,880 --> 00:17:20,119 without having to decrypted data. 269 00:17:20,119 --> 00:17:23,319 So it's it's about so-called data in use, right. 270 00:17:23,319 --> 00:17:27,960 We have data in REST which just lies encrypted on some hard 271 00:17:27,960 --> 00:17:30,200 drive. But data in use is the data that 272 00:17:30,200 --> 00:17:32,640 actively is is being used in a computation. 273 00:17:32,640 --> 00:17:37,160 And so confidential computing allows for that data in use to 274 00:17:37,160 --> 00:17:39,720 be secure. That's what what confidential 275 00:17:39,720 --> 00:17:44,760 computing tries to achieve. And there's different, different 276 00:17:45,600 --> 00:17:48,720 use cases, I guess for confidential computing. 277 00:17:49,880 --> 00:17:54,680 For one, creating a secure execution environment, right, 278 00:17:54,680 --> 00:17:59,400 having sensitive data, critical, critical business data, for 279 00:17:59,400 --> 00:18:03,200 example, right, that that has to be executed over in in some 280 00:18:03,200 --> 00:18:05,720 cloud environment. And if that data were to be 281 00:18:05,720 --> 00:18:11,560 leaked, bad things could happen to companies, enterprises, 282 00:18:11,920 --> 00:18:15,400 governments or individuals. So building secure execution 283 00:18:15,400 --> 00:18:18,000 environments. At the same time, confidential 284 00:18:18,000 --> 00:18:22,160 computing allows for data collaboration essentially. 285 00:18:22,160 --> 00:18:26,960 So some individuals can have their data remain private while 286 00:18:26,960 --> 00:18:28,600 being able to interact with others. 287 00:18:28,880 --> 00:18:33,520 So those are two core aspects of what confidential computing 288 00:18:33,560 --> 00:18:38,560 tries to achieve. And there are different kinds of 289 00:18:38,560 --> 00:18:44,880 technologies that have been utilised in the past to to 290 00:18:44,880 --> 00:18:47,960 achieve this. And I think the most prominent 291 00:18:47,960 --> 00:18:53,160 one so far has always been trusted execution environments. 292 00:18:53,880 --> 00:19:00,240 And a few months back, I was in in San Francisco at the 293 00:19:00,240 --> 00:19:03,920 so-called Confidential Computing Summit, which essentially is 294 00:19:03,920 --> 00:19:07,920 just a conference of trusted execution environment 295 00:19:09,200 --> 00:19:13,920 manufacturers and Intel, Microsoft, all those folks, 296 00:19:13,920 --> 00:19:18,920 they're praising their trusted execution environment technology 297 00:19:19,400 --> 00:19:21,760 and. Yeah. 298 00:19:22,560 --> 00:19:26,320 I gave a talk there and I called it trusted execution is dead and 299 00:19:26,320 --> 00:19:29,280 we have killed it. And so my take really is that 300 00:19:29,920 --> 00:19:32,960 there's new kinds of technologies now that can 301 00:19:32,960 --> 00:19:36,520 replace those legacy systems that require trust. 302 00:19:36,520 --> 00:19:40,640 So what we're trying to achieve at RTM and what the entire 303 00:19:41,000 --> 00:19:45,040 decentralized confidential computing DCC movement I think 304 00:19:45,400 --> 00:19:49,240 to some degree is trying to achieve is to add more 305 00:19:49,240 --> 00:19:51,960 trustlessness to to confidential computing. 306 00:19:51,960 --> 00:19:54,840 And in our case that's by utilizing multi party 307 00:19:54,840 --> 00:19:59,640 computation. So maybe you can kind of I guess 308 00:19:59,640 --> 00:20:04,640 bring up the T ES already and we have seen over the years a lot 309 00:20:04,640 --> 00:20:09,280 of different types of attacks on these, I think yeah, like side 310 00:20:09,280 --> 00:20:16,640 channel attack kind of supply chain tags and still like. 311 00:20:17,120 --> 00:20:19,960 Like you're saying right in the summit, everyone's talking about 312 00:20:19,960 --> 00:20:22,240 that. I think also in the crypto space 313 00:20:22,240 --> 00:20:27,720 right now, T seems to have another like sort of resurgence 314 00:20:27,720 --> 00:20:34,280 and popularity. Is that or like, you know, why 315 00:20:34,280 --> 00:20:38,320 is that maybe and how does MPC improve on that? 316 00:20:38,320 --> 00:20:42,760 Or like, how do you, yeah, tackle that at Arqum, Like to 317 00:20:42,760 --> 00:20:45,440 sort of maybe explain also a little bit what these types of 318 00:20:45,440 --> 00:20:47,960 attacks actually are? Yeah, sure. 319 00:20:47,960 --> 00:20:51,880 So, so trusted execution environment are dedicated 320 00:20:51,880 --> 00:20:57,280 hardware that comes with security and privacy promises 321 00:20:57,280 --> 00:21:00,120 essentially from from the manufacturers. 322 00:21:00,800 --> 00:21:07,120 So usually that's dedicated hardware chips that have those 323 00:21:07,320 --> 00:21:09,360 secure enclaves is what it's called. 324 00:21:09,360 --> 00:21:14,640 So virtual machines within those chips where data should remain 325 00:21:14,640 --> 00:21:19,600 secure, encrypted and cannot be accessed outside of that of that 326 00:21:19,600 --> 00:21:23,720 enclave and enclave has a code base associated with it. 327 00:21:23,720 --> 00:21:27,920 So only the specific code base can be executed over that over 328 00:21:27,920 --> 00:21:30,520 that state. Which sounds like a great 329 00:21:30,520 --> 00:21:34,240 concept, sounds like a difficult to realise concept. 330 00:21:34,240 --> 00:21:38,400 At the same time, thinking about exploits and hackers. 331 00:21:38,600 --> 00:21:43,080 So those systems suffer from from from many problems. 332 00:21:43,080 --> 00:21:49,200 I think the most easy to grasp problem is that actually the 333 00:21:49,200 --> 00:21:52,600 complexity of building building architectures on top of crossed 334 00:21:52,600 --> 00:21:55,560 execution environments. Anyone who has worked with with 335 00:21:55,560 --> 00:21:59,000 T ES will will tell you that it's very difficult to build 336 00:21:59,720 --> 00:22:04,080 secure code on top of those on class because developers really 337 00:22:04,080 --> 00:22:10,400 have to have to ensure that data is being handled correctly. 338 00:22:10,480 --> 00:22:15,560 And they need to give rigorous attention to detail that the 339 00:22:15,560 --> 00:22:20,960 boundaries between the secure and non secure environments are 340 00:22:20,960 --> 00:22:24,880 being respected. And that also at the same time 341 00:22:25,480 --> 00:22:29,360 brings, yeah, increased time to market, I think because there 342 00:22:29,360 --> 00:22:34,120 needs to be a very, very fought through development processes 343 00:22:34,640 --> 00:22:39,400 and those systems at the same time also on their own come with 344 00:22:39,880 --> 00:22:43,480 quite high costs associated. It's dedicated hardware and 345 00:22:44,720 --> 00:22:48,840 dedicated hardware that requires specialized folks that that are 346 00:22:48,840 --> 00:22:52,280 able to maintain and develop on, on those platforms. 347 00:22:52,720 --> 00:22:56,560 Those are more of the soft factors that I don't like about 348 00:22:56,560 --> 00:22:58,360 working with trust execution environment. 349 00:22:58,800 --> 00:23:03,040 And the bigger problems really are associated with the trust 350 00:23:03,040 --> 00:23:04,400 model. As the name already 351 00:23:04,400 --> 00:23:07,600 communicates, the execution here is trusted. 352 00:23:07,600 --> 00:23:13,760 And the trust model in my opinion is fundamentally flawed 353 00:23:15,160 --> 00:23:19,400 because as you said, Mt ES are really susceptible to a whole 354 00:23:19,400 --> 00:23:24,320 range of, of, of more or less sophisticated attacks. 355 00:23:24,680 --> 00:23:29,920 And I don't know if you guys saw this but 1 1/2 weeks ago or 356 00:23:29,920 --> 00:23:33,360 something like that. I think there was some some 357 00:23:33,360 --> 00:23:38,360 researcher on Twitter that was able to extract the route 358 00:23:38,360 --> 00:23:45,240 provisioning key from some Intel SGX family processors, which is 359 00:23:45,240 --> 00:23:48,960 a key that can be used to to fake so-called attestation 360 00:23:48,960 --> 00:23:51,000 report. So trusted execution 361 00:23:51,000 --> 00:23:55,200 environments require this process of attestation where 362 00:23:55,200 --> 00:23:59,560 they prove to you that they are a real trusted execution 363 00:23:59,560 --> 00:24:02,360 environment and you can trust this environment. 364 00:24:02,360 --> 00:24:05,120 So you can send your data in an encrypted way to the 365 00:24:05,120 --> 00:24:08,200 environment. And this at the station service. 366 00:24:08,920 --> 00:24:11,120 Yeah, requires some third party trust. 367 00:24:13,160 --> 00:24:15,320 Yeah. Regardless, on the processor 368 00:24:15,320 --> 00:24:18,720 side of things, there's side channel attacks and hardware 369 00:24:18,720 --> 00:24:20,880 vulnerabilities. And side channel attacks really 370 00:24:21,680 --> 00:24:27,680 boil down to you as as the person having access to to the 371 00:24:27,680 --> 00:24:32,800 processor or you being able to trust track the execution of 372 00:24:32,800 --> 00:24:36,720 some program execution. And through this process of 373 00:24:36,720 --> 00:24:42,040 being able to look at for example, power consumption or or 374 00:24:42,040 --> 00:24:46,680 tracking other metadata, I guess that gets exposed through the 375 00:24:46,680 --> 00:24:52,000 execution of a program be able to understand the execution path 376 00:24:52,280 --> 00:24:55,160 in our program, right. So if you think of an if else 377 00:24:55,160 --> 00:24:59,400 statement and if some some condition holds something 378 00:24:59,400 --> 00:25:01,760 complex is being executed, it takes one hour. 379 00:25:01,920 --> 00:25:04,400 And the else case the program trust ends. 380 00:25:05,080 --> 00:25:09,360 If the computation takes one hour, you will know, OK, the 381 00:25:09,360 --> 00:25:12,320 condition was true because the first branch was executed. 382 00:25:12,320 --> 00:25:17,800 And so that's, that's the most simple form of performing a side 383 00:25:17,800 --> 00:25:20,840 channel attack, right. And so those processors are 384 00:25:20,840 --> 00:25:24,160 prone to these kinds of side channel attacks and there's 385 00:25:25,760 --> 00:25:30,240 many, many exploits that have occurred in the past and many 386 00:25:30,240 --> 00:25:35,200 fixes for those exploits, but it's always new exploits that 387 00:25:35,360 --> 00:25:39,480 that get identified. So in the blockchain space, 388 00:25:39,480 --> 00:25:42,400 we've seen a number of those kinds of exploits. 389 00:25:42,400 --> 00:25:45,480 Actually, I think the most notable one would have been 390 00:25:46,320 --> 00:25:49,760 secret network. I think there was end of 22 391 00:25:50,360 --> 00:25:53,840 where there I think it was called a seat key or something 392 00:25:53,840 --> 00:25:57,160 like that some some master key that was shared between all all 393 00:25:57,160 --> 00:26:01,720 the notes in the network, all the T ES there was exfiltrated 394 00:26:02,160 --> 00:26:06,560 and then anyone whoever ran a note in the network would have 395 00:26:06,560 --> 00:26:11,000 been able to yeah, we we won't remove the privacy of all 396 00:26:11,000 --> 00:26:14,720 transactions right. So there's this inherent danger 397 00:26:14,800 --> 00:26:19,480 of side channel attacks firmware micro code and SDK box. 398 00:26:19,480 --> 00:26:25,680 It's just this large development stack with incredible complexity 399 00:26:25,840 --> 00:26:28,480 and both on the hardware, but also on the software, firmware 400 00:26:28,480 --> 00:26:33,120 micro code level where at the end of the day humans are 401 00:26:33,120 --> 00:26:36,080 building those systems. And so humans in most cases are 402 00:26:36,080 --> 00:26:38,200 also able to to exfiltrate information. 403 00:26:38,800 --> 00:26:41,120 Those are one kind of of exploits. 404 00:26:41,120 --> 00:26:45,240 But I think more important is as you, as you mentioned, Felix, 405 00:26:45,400 --> 00:26:49,040 supply chains, because when someone trusts a trusted 406 00:26:49,040 --> 00:26:54,560 execution environment, they're trusting a supply chain, usually 407 00:26:54,560 --> 00:26:59,440 proprietary supply chain, which at the end of the day is just a 408 00:26:59,520 --> 00:27:01,400 chain of single points of failure. 409 00:27:02,840 --> 00:27:05,800 Single points of failure that can occur in that station 410 00:27:05,800 --> 00:27:09,440 process, can occur in the manufacturing process. 411 00:27:09,720 --> 00:27:15,400 And I think a very striking example of how trusted the 412 00:27:15,400 --> 00:27:21,080 systems are is when, when Apple unveiled their private cloud 413 00:27:21,080 --> 00:27:24,600 computing platform, which is their own T ES that they they 414 00:27:24,600 --> 00:27:30,720 supply for, for for model inference for their Apple 415 00:27:30,720 --> 00:27:33,120 intelligence. I think something that they 416 00:27:33,120 --> 00:27:37,240 stated in their docs in their release article was something 417 00:27:37,240 --> 00:27:43,560 like, OK, they physically ensure that the, that the machines from 418 00:27:43,560 --> 00:27:48,120 the factory get placed in their, in their data centre, right. 419 00:27:48,120 --> 00:27:51,600 So you can imagine and people standing there with their 420 00:27:51,600 --> 00:27:57,520 assault rifles protecting crates of, of of computer chips, which 421 00:27:57,520 --> 00:28:00,000 is in Zain, right? If that's the trust model that 422 00:28:00,000 --> 00:28:02,840 you're working with, that there has been someone that was able 423 00:28:02,840 --> 00:28:07,480 to physically guard this chip from A to BI think that's not 424 00:28:07,480 --> 00:28:11,760 something that that we should put all of our trust in. 425 00:28:12,120 --> 00:28:14,920 So what I wanted to ask you? About like, because you know, 426 00:28:14,920 --> 00:28:17,520 we've been focusing on SGX here. And I think, like in crypto at 427 00:28:17,520 --> 00:28:23,160 least, you know, SGX has gotten a lot of negative attention 428 00:28:23,160 --> 00:28:27,680 because of the secret hack and, and, and, and some other issues. 429 00:28:27,680 --> 00:28:30,400 And like, I'm, I'm here on the Wikipedia page for, for Intel S 430 00:28:30,400 --> 00:28:32,760 jacks and there's about, you know, a dozen different attack 431 00:28:33,600 --> 00:28:35,200 vulnerabilities that are mentioned. 432 00:28:36,040 --> 00:28:40,040 But so why is it then that, you know, we never hear of like the 433 00:28:40,040 --> 00:28:45,280 Apple tee in our phones being compromised or, you know, even 434 00:28:45,480 --> 00:28:49,120 perhaps more interestingly, like Ledger devices? 435 00:28:49,600 --> 00:28:53,440 You know, they, they claim that, you know, they're super secure 436 00:28:53,440 --> 00:28:58,200 and, and they had like this whole, what they call it the, 437 00:28:58,200 --> 00:29:00,400 the, the, the dungeon or something like that. 438 00:29:00,400 --> 00:29:02,880 You know, their, their, their whole like security lab that 439 00:29:02,880 --> 00:29:06,720 just pries all day at trying to crack a Ledger. 440 00:29:06,720 --> 00:29:09,000 So why? Why are TS different or, or are 441 00:29:09,000 --> 00:29:12,440 they you know, is this just a misconception or lack of 442 00:29:12,440 --> 00:29:18,640 understanding of the technology? Yeah, I, I, I think SJX has 443 00:29:18,640 --> 00:29:22,160 gotten a lot of attention. The architectures are, are 444 00:29:22,160 --> 00:29:26,800 significantly different in the details, of course, but the core 445 00:29:26,800 --> 00:29:30,600 architecture and the core reliance on, on these kinds of 446 00:29:30,600 --> 00:29:37,040 supply chains remains the same. And yeah, I think in general 447 00:29:38,480 --> 00:29:43,400 there's yeah, I think so. So we can, we can go more into 448 00:29:43,400 --> 00:29:47,240 that how I think trusted execution environments can play 449 00:29:47,240 --> 00:29:49,400 a role in the future. I think they can play a role. 450 00:29:49,400 --> 00:29:54,440 But yeah, just this this approach of using these systems 451 00:29:54,440 --> 00:29:57,640 and saying, well, so far we didn't see any exploits. 452 00:29:57,640 --> 00:30:02,200 So we can be sure that we can trust our systems and we can use 453 00:30:02,200 --> 00:30:07,280 them for for all our future. I think that's, that's a flawed, 454 00:30:07,640 --> 00:30:11,840 flawed approach because at the end of the day, it's just the 455 00:30:11,840 --> 00:30:17,480 sort of non provable blind trust in the case of Intel SGX, we've 456 00:30:17,480 --> 00:30:20,280 seen how how fatal this can be really. 457 00:30:21,000 --> 00:30:25,840 And I think what's important. And that's something that I've, 458 00:30:26,600 --> 00:30:30,160 I think never seen anyone talk about when, when talking about 459 00:30:30,160 --> 00:30:35,480 these kinds of supply chains. In the case of Intel SGX, that's 460 00:30:35,480 --> 00:30:40,440 something that, that we've seen with different kinds of, of 461 00:30:40,440 --> 00:30:42,240 teams that, that use the technology. 462 00:30:42,760 --> 00:30:45,680 Was that OK? There's the supply chain and 463 00:30:45,680 --> 00:30:49,520 trust into Intel essentially. And the person that has access 464 00:30:49,520 --> 00:30:51,160 to, to the, to the computer trip. 465 00:30:51,480 --> 00:30:55,880 But there's also someone who deploys the code for the, for 466 00:30:55,880 --> 00:30:59,200 the enclave and they upgrade the code. 467 00:30:59,200 --> 00:31:03,040 They, they, they give updates and they have a private key they 468 00:31:03,040 --> 00:31:07,080 use to, to sign those updates. And so there's a single signing 469 00:31:07,080 --> 00:31:11,480 authority that can update whatever code, they can have 470 00:31:11,480 --> 00:31:14,240 their own local trusted execution environment, update 471 00:31:14,240 --> 00:31:16,080 the code and exfiltrate information. 472 00:31:16,400 --> 00:31:19,640 And at the end of the day, in most crypto projects that use 473 00:31:19,640 --> 00:31:23,240 trusted execution environments, yeah, easy as single point of 474 00:31:23,240 --> 00:31:27,720 failure really is some development agency sitting on 475 00:31:27,720 --> 00:31:32,040 some island, I guess that has a private key that has full 476 00:31:32,040 --> 00:31:35,680 control over everything. I think that's the that's the 477 00:31:35,680 --> 00:31:39,600 most shocking, shocking aspect. And that's overlooked a lot when 478 00:31:39,600 --> 00:31:42,080 when talking about the trust in the manufacturer. 479 00:31:42,200 --> 00:31:46,640 Most most of the times it's. It's even simpler than that. 480 00:31:48,000 --> 00:31:50,600 It's a $5 ranch attack. You just you have to get the 481 00:31:50,600 --> 00:31:53,920 boat to the island. Yeah, exactly. 482 00:31:55,680 --> 00:31:56,920 OK. Yeah, that that's super 483 00:31:56,920 --> 00:32:00,080 interesting. I think, I guess we're we still 484 00:32:00,080 --> 00:32:03,640 haven't even talked about MPC. So, so let's get there. 485 00:32:03,640 --> 00:32:06,200 I guess, you know, we're basically focusing on these 486 00:32:06,200 --> 00:32:09,920 hardware based models, but now we also have like purely 487 00:32:09,960 --> 00:32:15,000 cryptographically based privacy techniques and how do they work 488 00:32:15,040 --> 00:32:18,280 and like what are their trade-offs and, and how do you 489 00:32:18,280 --> 00:32:19,920 like navigate that trade off space? 490 00:32:19,920 --> 00:32:21,720 I guess that's going to be the discussion for the next few 491 00:32:22,600 --> 00:32:24,360 minutes, hopefully. Yeah, yeah, sure. 492 00:32:24,360 --> 00:32:29,320 So essentially the other technologies are 0 knowledge 493 00:32:29,320 --> 00:32:35,080 proofs, fully homomorphic encryption and MPC, 0 knowledge 494 00:32:35,080 --> 00:32:37,160 proofs. We've spent a lot of time 495 00:32:37,160 --> 00:32:41,040 working with zero knowledge proofs are, yeah, great 496 00:32:41,040 --> 00:32:42,960 technology. And at the end of the day, zero 497 00:32:42,960 --> 00:32:46,520 knowledge proofs are even part of those FHE and MPC proving 498 00:32:46,520 --> 00:32:49,360 system. So, but, but CK snarks, CK 499 00:32:49,360 --> 00:32:52,440 snarks those, those more, more prominent proving systems. 500 00:32:53,600 --> 00:32:56,200 Yeah. They don't allow for what we're 501 00:32:56,200 --> 00:32:58,080 trying to achieve. What we're trying to achieve 502 00:32:58,080 --> 00:33:03,080 really is to be able to have some encrypted data, send it to 503 00:33:03,080 --> 00:33:06,520 the some cloud environment, some some blockchain network, 504 00:33:06,520 --> 00:33:09,600 whatever, send it to some some some computer and have it 505 00:33:09,600 --> 00:33:13,680 processed without that party that processes it having access 506 00:33:13,680 --> 00:33:16,080 to the data. And and 0 knowledge proofs are 507 00:33:16,080 --> 00:33:20,520 just two party protocol where one party is the prover that has 508 00:33:20,520 --> 00:33:25,080 access to the data and the second party to verify verifier 509 00:33:25,080 --> 00:33:27,680 not having access to the data. So 0 knowledge proofs on their 510 00:33:27,680 --> 00:33:31,560 own can't allow for those Autonomous confidential 511 00:33:31,560 --> 00:33:35,440 execution environment. FHE fully Homomorphic Encryption 512 00:33:36,240 --> 00:33:39,520 allows for that. Essentially, the definition of 513 00:33:39,520 --> 00:33:48,920 of FHE would be to be able to to execute arbitrary operations 514 00:33:49,040 --> 00:33:52,120 over encrypted data. So there's an encrypted 515 00:33:52,120 --> 00:33:59,040 representation of of some state and with FHE two operations, 516 00:33:59,040 --> 00:34:01,920 essentially additional multiplication are homomorphic 517 00:34:02,600 --> 00:34:06,640 over that representation, which means that they yield an output 518 00:34:06,640 --> 00:34:09,000 that again lies in this representation. 519 00:34:09,000 --> 00:34:13,159 So on. That is a very, very good 520 00:34:13,159 --> 00:34:17,480 concept. And the problem with FHE really 521 00:34:17,480 --> 00:34:23,800 is the practical usage of the technology, because the 522 00:34:23,880 --> 00:34:30,600 multiplications for fully homomorphic encryption result in 523 00:34:30,600 --> 00:34:35,360 noise accumulation, and noise accumulation requires 524 00:34:36,520 --> 00:34:39,120 bootstrapping. So bootstrapping operations 525 00:34:39,120 --> 00:34:42,560 essentially reduce the noise of this encrypted output. 526 00:34:42,800 --> 00:34:46,199 And if there's too much noise, that output can't be, can't be 527 00:34:46,199 --> 00:34:49,280 processed anymore. So bootstrapping is required. 528 00:34:49,679 --> 00:34:56,960 And that results in very high, very high performance latencies 529 00:34:57,000 --> 00:35:01,240 and and computational overhead. And that means that when using 530 00:35:01,240 --> 00:35:07,160 these kinds of FHE systems, there's many orders of magnitude 531 00:35:07,720 --> 00:35:12,800 performance latency associated. And so it's, it's not unusual. 532 00:35:12,800 --> 00:35:19,480 And I think comparing the the MPC protocols that we have with 533 00:35:20,000 --> 00:35:24,840 some FHE operations and it's not unusual for us to see something 534 00:35:24,840 --> 00:35:28,800 like as being faster 80,000 times, something like that. 535 00:35:28,800 --> 00:35:31,880 So incredible performance differences. 536 00:35:31,880 --> 00:35:36,760 And for very, very simple operations, FHE can be used. 537 00:35:37,280 --> 00:35:42,120 But yeah, more complex computations make this 538 00:35:42,120 --> 00:35:45,160 technology fail at the end of the day in in practical 539 00:35:45,160 --> 00:35:48,040 implementations. And so the system that we are 540 00:35:48,040 --> 00:35:51,520 using is multi party computation. 541 00:35:51,800 --> 00:35:57,000 And this multi party computation uses so-called somewhat 542 00:35:57,000 --> 00:36:00,960 homomorphic encryption. SHE and somewhat homomorphic 543 00:36:00,960 --> 00:36:06,520 encryption basically uses the efficient aspects of homomorphic 544 00:36:06,600 --> 00:36:09,520 fully homomorphic encryption that we we also utilized there. 545 00:36:09,840 --> 00:36:14,560 But for multiplications, there's a smart trick associated I guess 546 00:36:14,560 --> 00:36:19,200 that allows us to to efficiently perform those multiplications as 547 00:36:19,200 --> 00:36:22,120 well. And so that's why this 548 00:36:22,120 --> 00:36:26,080 technology makes most sense. And on top of that, what's also 549 00:36:26,080 --> 00:36:31,200 very important to realise with FHE is that moving from 550 00:36:31,320 --> 00:36:34,960 encrypted representation to encrypted representation is very 551 00:36:34,960 --> 00:36:39,200 nice. But if, what if one wants to 552 00:36:39,200 --> 00:36:41,160 move out of the encrypted representation, right? 553 00:36:41,480 --> 00:36:44,440 If we have confidential on applications and we want some 554 00:36:44,440 --> 00:36:48,280 transparent settlement to occur, there has to be a way to 555 00:36:48,280 --> 00:36:53,640 selectively disclose information about the the encrypted state. 556 00:36:53,880 --> 00:36:56,800 And that's not possible with FHE by default. 557 00:36:56,800 --> 00:36:58,800 And with NPC that becomes possible. 558 00:36:59,600 --> 00:37:03,560 And so trust model wise, what's the case is that the trust 559 00:37:03,560 --> 00:37:08,160 models for for systems in practice, it's the same for MPC 560 00:37:08,160 --> 00:37:13,120 and and FHE applications with MPC being many orders of 561 00:37:13,120 --> 00:37:17,240 magnitude faster. And so that's why we arrived at 562 00:37:17,520 --> 00:37:21,960 building those systems with MPC. Super interesting. 563 00:37:21,960 --> 00:37:24,400 And do you think like, I guess in general, this is also 564 00:37:24,400 --> 00:37:27,640 something that fhe can ever address in a way? 565 00:37:27,640 --> 00:37:31,880 Like is it something that, you know, over time the algorithm 566 00:37:31,880 --> 00:37:33,680 will get better And like, I'm probably right. 567 00:37:33,680 --> 00:37:35,920 I mean, but yeah, we'll be curious about that. 568 00:37:36,840 --> 00:37:40,200 That mostly boils down to to hardware acceleration. 569 00:37:40,760 --> 00:37:44,680 So hardware acceleration is is what matters most for that. 570 00:37:45,000 --> 00:37:48,720 There will be significant improvements for sure. 571 00:37:49,520 --> 00:37:53,360 And what's important is that those hardware acceleration 572 00:37:53,360 --> 00:37:58,840 improvements also get utilized by this somewhat homomorphic 573 00:37:58,840 --> 00:38:05,200 encryption system in, in, in, in MPC, MPC still requiring network 574 00:38:05,200 --> 00:38:08,120 communication. That's, that's, that's one 575 00:38:08,120 --> 00:38:11,280 difference requiring some more network communication at the 576 00:38:11,280 --> 00:38:17,440 same time FHE in order to achieve verifiable compute with 577 00:38:17,440 --> 00:38:21,360 FHE, you also require consensus mechanisms. 578 00:38:21,360 --> 00:38:24,920 If you, if you do it in the in the blockchain setting, if 579 00:38:24,920 --> 00:38:29,240 verifiable compute, which is highly important for for any 580 00:38:29,240 --> 00:38:31,960 computation, especially confidential computations. 581 00:38:32,960 --> 00:38:36,520 If, if verifiable computers achieved without using 582 00:38:36,520 --> 00:38:40,480 consensus, there's even more significant performance slow 583 00:38:40,480 --> 00:38:43,320 down South. Hardware acceleration is what it 584 00:38:43,320 --> 00:38:45,880 boils down to. And I think these kind of 585 00:38:45,880 --> 00:38:51,720 hardware accelerations will also be utilisable for for the MPC 586 00:38:51,720 --> 00:38:57,280 protocols, especially with, with recent, yeah, with recent 587 00:38:57,280 --> 00:39:01,680 advancements in those in those protocols greatly reducing the 588 00:39:01,880 --> 00:39:04,920 the need for for network communication. 589 00:39:05,720 --> 00:39:11,480 So there's different, yeah, options to to be able to pack a 590 00:39:11,480 --> 00:39:14,440 lot more data within communication around. 591 00:39:14,440 --> 00:39:20,560 So yeah, I think at the end of the day, FHE will become more 592 00:39:20,560 --> 00:39:25,040 performant. But yeah, at this point in time, 593 00:39:25,080 --> 00:39:29,640 NPC trust makes more sense. So it's always about, yeah, 594 00:39:29,640 --> 00:39:35,800 being able to supply the required privacy technology at 595 00:39:35,800 --> 00:39:38,000 this point in time and for the next years. 596 00:39:38,000 --> 00:39:45,240 And so it's the same with with fusion energy, I guess, right? 597 00:39:45,840 --> 00:39:50,200 We also need energy now and for the next 10 years without having 598 00:39:50,200 --> 00:39:55,840 fusion energy. So does this work with any type 599 00:39:55,840 --> 00:39:57,840 of computation? Can you do? 600 00:39:57,840 --> 00:40:01,720 Can you perform really complex computations using RTM? 601 00:40:01,720 --> 00:40:07,960 And what what languages can one write computations? 602 00:40:07,960 --> 00:40:12,280 And does this implementation support like specific languages? 603 00:40:12,280 --> 00:40:18,280 Can you maybe explain that? How what we're trying to achieve 604 00:40:18,280 --> 00:40:24,440 essentially as as as the wish with RTM and that's why I like 605 00:40:24,440 --> 00:40:29,600 to call it a supercomputer really is for arbitrary program 606 00:40:29,600 --> 00:40:34,080 execution in a confidential encrypted way, but to also have 607 00:40:34,080 --> 00:40:39,680 the program itself be fully encrypted and to have encrypted 608 00:40:39,800 --> 00:40:42,320 random access memory encrypted RAM, right. 609 00:40:42,320 --> 00:40:46,120 So to have a fully encrypted computer, you really have this 610 00:40:46,120 --> 00:40:49,680 sort of replacement for you purchasing some trusted 611 00:40:49,680 --> 00:40:52,520 execution environment. Now you can use this global 612 00:40:52,520 --> 00:40:57,800 supercomputer to execute anything arbitrary programs that 613 00:40:58,920 --> 00:41:01,440 are essentially arbitrary encrypted RAM programs. 614 00:41:02,280 --> 00:41:06,320 The current stage we are at is that we support arbitrary 615 00:41:06,320 --> 00:41:11,720 computation support. And for that we have a dedicated 616 00:41:11,720 --> 00:41:21,120 compiler that compiles arbitrary Rust code into the into the up 617 00:41:21,120 --> 00:41:24,160 code micro code format that our network understands. 618 00:41:24,160 --> 00:41:27,920 Yeah. So one could essentially be be 619 00:41:27,920 --> 00:41:30,520 writing assembly code. So on the up code level, but 620 00:41:30,520 --> 00:41:34,880 what the network understands, but what we offer mainly is the 621 00:41:35,040 --> 00:41:40,560 dedicated, yeah, Rust compiler. Now depending on the use case, 622 00:41:41,520 --> 00:41:43,320 different languages make more sense. 623 00:41:43,320 --> 00:41:48,880 So what we have at Arghum right now is 2 distinct back ends, 2 624 00:41:48,880 --> 00:41:54,440 distinct NPC protocols, 1 NPC protocol that is highly focused 625 00:41:54,440 --> 00:42:00,160 on being as trust less as possible for especially on chain 626 00:42:00,160 --> 00:42:03,040 applications. And we have another back end 627 00:42:03,360 --> 00:42:07,960 that is fine-tuned for floating point operations. 628 00:42:08,000 --> 00:42:14,240 So in order to perform operations over large mattresses 629 00:42:14,240 --> 00:42:19,080 with Floating Points for machine learning and so for that back 630 00:42:19,080 --> 00:42:24,000 end, we we support a Python SDK essentially. 631 00:42:24,560 --> 00:42:28,840 So one can use Tensorflow and pandas like they would normally 632 00:42:29,200 --> 00:42:34,360 and now have it be confidential and have one party holds this 633 00:42:34,360 --> 00:42:37,960 data, another party hold another data and then collaboratively 634 00:42:38,200 --> 00:42:42,200 train. Yes, logistical regression or or 635 00:42:42,200 --> 00:42:50,080 tree boosting model with that. So essentially Rust and Python 636 00:42:50,080 --> 00:42:52,720 for for the machine learning applications is what I would 637 00:42:52,720 --> 00:42:55,280 say, yeah. Awesome. 638 00:42:55,640 --> 00:43:02,240 Let's maybe also take it back to like RQM as this network 639 00:43:02,280 --> 00:43:05,920 overall, right? Like so we talked about, you 640 00:43:05,920 --> 00:43:10,720 know, why you're using MPC and, and confidential computation, 641 00:43:10,720 --> 00:43:15,800 but to achieve this at scale, right, there is a, a network and 642 00:43:15,800 --> 00:43:17,800 there is the crypto component of it. 643 00:43:18,320 --> 00:43:25,440 So can you provide us like a overview over the RQM structure 644 00:43:26,200 --> 00:43:31,160 architecturally as a as a crypto protocol and and how, how that 645 00:43:31,520 --> 00:43:37,120 functions? Essentially RQM itself is a, you 646 00:43:37,120 --> 00:43:40,000 could say stateless computing network. 647 00:43:40,160 --> 00:43:46,640 So we utilise existing lectures, existing blockchains for state 648 00:43:46,640 --> 00:43:49,520 management and computation scheduling. 649 00:43:49,520 --> 00:43:54,680 So you can have your own smart contract on Solana, for example, 650 00:43:54,880 --> 00:43:59,120 that has confidential functionality, and this smart 651 00:43:59,120 --> 00:44:05,200 contract then calls an RQM smart contract that inserts a new 652 00:44:05,200 --> 00:44:08,040 computation within the RQMM pool. 653 00:44:08,360 --> 00:44:11,440 The network picks that up, executes the computation, and 654 00:44:11,440 --> 00:44:13,840 settles it back to the corresponding network. 655 00:44:14,280 --> 00:44:18,240 What's important is that the RQM network itself, you don't write 656 00:44:18,240 --> 00:44:22,960 a smart contract for RQM. You, you can use our smart 657 00:44:22,960 --> 00:44:26,280 contract SDK and build a confidential smart contract, but 658 00:44:26,280 --> 00:44:30,080 the network itself just runs confidential computations and it 659 00:44:30,080 --> 00:44:33,640 picks those up from those dedicated on chain mem pools 660 00:44:33,640 --> 00:44:35,440 that can exist on different letters. 661 00:44:35,440 --> 00:44:37,680 And so I can build a confidential off chain 662 00:44:37,680 --> 00:44:41,480 application and send such a computation request to the mem 663 00:44:41,480 --> 00:44:44,800 pool and it doesn't have to settle back to the to the 664 00:44:44,800 --> 00:44:48,800 dedicated smart contract. Now how the network itself 665 00:44:48,800 --> 00:44:53,600 functions is essentially it's a permissionless network of nodes. 666 00:44:53,600 --> 00:44:59,760 And so the three of us could deploy a node in RTM and we 667 00:44:59,760 --> 00:45:02,520 could open up so-called computation cluster. 668 00:45:02,880 --> 00:45:07,880 So our computation cluster could now be used by anyone to run 669 00:45:07,880 --> 00:45:11,160 confidential computations. Or we could restrict that 670 00:45:11,160 --> 00:45:14,840 computation cluster to say, OK, we don't care about providing 671 00:45:14,840 --> 00:45:17,040 computational services to third parties. 672 00:45:17,160 --> 00:45:20,000 We just want to run our own confidential computations. 673 00:45:20,320 --> 00:45:24,960 So it's fully configurable. You can have clusters containing 674 00:45:24,960 --> 00:45:27,680 nodes from the network. You can run your own node. 675 00:45:28,040 --> 00:45:32,360 And what's so highly important about the trust model associated 676 00:45:32,360 --> 00:45:35,160 there is that it's the dishonest maturity trust model. 677 00:45:35,160 --> 00:45:39,680 So any computational cluster only requires 1 participant to 678 00:45:39,680 --> 00:45:44,000 be honest, one participant that doesn't collaborate with all the 679 00:45:44,000 --> 00:45:46,880 others participants in a malicious way. 680 00:45:46,880 --> 00:45:53,200 So with that trust assumption, you can have arbitrarily sized 681 00:45:53,200 --> 00:45:58,840 computation clusters and associate them with a so-called 682 00:45:59,360 --> 00:46:02,880 MXEMPC execution environment. So that's essentially just 683 00:46:03,440 --> 00:46:07,000 virtual machine instance that you create as a developer. 684 00:46:07,000 --> 00:46:10,040 You create this virtual machine instance where you have 685 00:46:10,040 --> 00:46:12,800 encrypted stage, you have your functions that can be called 686 00:46:14,040 --> 00:46:16,440 essentially analogous to a smart contract if you will. 687 00:46:16,840 --> 00:46:21,720 And that environment has one or more clusters associated that 688 00:46:21,720 --> 00:46:23,640 then process these kinds of computations. 689 00:46:24,760 --> 00:46:30,600 Now the problem one on a theoretical level would run into 690 00:46:30,600 --> 00:46:34,960 is that such a computational cluster has this ideal trust 691 00:46:34,960 --> 00:46:39,200 assumption only requiring the trust that one node is honest, 692 00:46:39,200 --> 00:46:42,320 right? Which for our block trends we 693 00:46:42,320 --> 00:46:45,200 have with with practical Byzantine fault tolerance, we 694 00:46:45,200 --> 00:46:48,200 have the honest majority trust assumption and here dishonest 695 00:46:48,200 --> 00:46:51,320 majority trust assumption. One out of N really is perfect. 696 00:46:51,680 --> 00:46:57,200 But a problem is that this also becomes highly dangerous for 697 00:46:57,400 --> 00:47:02,400 censorship because one malicious party could also censor 698 00:47:02,400 --> 00:47:06,280 computations. And that really has in the past 699 00:47:06,280 --> 00:47:10,440 been a practical limitation for those very efficient and trust 700 00:47:10,440 --> 00:47:15,240 less MPC protocols because, yeah, deploying them in this 701 00:47:15,240 --> 00:47:18,360 permissionless setting could really mean that some malicious 702 00:47:18,360 --> 00:47:21,200 party could just DDoS the operation essentially. 703 00:47:21,720 --> 00:47:25,480 And So what we have is a new kind of cryptographic protocol 704 00:47:25,880 --> 00:47:33,320 that allows to enforce execution and also correct execution for 705 00:47:33,320 --> 00:47:36,160 for these computational cluster. So if you have this 706 00:47:36,160 --> 00:47:41,480 computational cluster and our cluster in this example, and 707 00:47:41,480 --> 00:47:46,000 Sebastian just randomly decides to share some invalid data with 708 00:47:46,000 --> 00:47:51,200 me, at some point I will notice that invalid data has been 709 00:47:51,200 --> 00:47:56,000 shared and I will stop the computation as I'm an honest 710 00:47:56,000 --> 00:47:59,440 participant. The problem now is that by 711 00:47:59,440 --> 00:48:04,360 default, Felix and I wouldn't be able to cryptographically 712 00:48:04,360 --> 00:48:07,560 identify that Sebastian was the one that caused the computation 713 00:48:07,560 --> 00:48:12,000 to fail by sharing a valid data. Now with our new protocol, we 714 00:48:12,000 --> 00:48:17,480 are able and actually everyone in the world viewing our our 715 00:48:17,480 --> 00:48:21,760 computation from the outside is able to identify that Sebastian 716 00:48:21,960 --> 00:48:24,840 is the one that caused the computation to fail. 717 00:48:25,040 --> 00:48:28,640 And what that means now is that we can punish Sebastian for 718 00:48:28,640 --> 00:48:32,400 causing the computation to fail. And so that's where block chains 719 00:48:32,400 --> 00:48:36,360 really come into play, that we are able to enforce execution of 720 00:48:36,360 --> 00:48:41,720 those computations and enforce this kind of correct behaviour. 721 00:48:41,720 --> 00:48:45,800 So we are able to add accountability to those 722 00:48:46,280 --> 00:48:49,760 computations, which makes it incredibly powerful now because 723 00:48:49,760 --> 00:48:54,160 then even smaller sized clusters, yeah, can be 724 00:48:54,160 --> 00:48:57,480 performant run those computations and the the 725 00:48:57,480 --> 00:49:02,160 deployer of of these clusters can can be certain that 726 00:49:02,440 --> 00:49:06,000 execution will occur. And so that's where our staking 727 00:49:06,000 --> 00:49:07,840 and slashing mechanism comes into play. 728 00:49:09,320 --> 00:49:17,000 So compared to other, you know, privacy projects out there, you 729 00:49:17,000 --> 00:49:20,240 know, how do you think RTM is fundamentally different? 730 00:49:20,240 --> 00:49:25,680 Like what, what is really the the, the key differentiator that 731 00:49:25,680 --> 00:49:27,640 you guys are offering as a product? 732 00:49:29,360 --> 00:49:34,520 Yeah, I, I think that really boils down to be trustless and 733 00:49:34,520 --> 00:49:38,920 performant at the same time. Because what we've seen really 734 00:49:38,920 --> 00:49:44,320 in the past is that that systems either require trust, we are 735 00:49:44,320 --> 00:49:49,800 trusted execution environments or have incredible slowdowns 736 00:49:49,800 --> 00:49:51,680 with fully homomorphic encryption. 737 00:49:51,680 --> 00:49:57,960 And this sounds stupid saying that as as the founder of RQM. 738 00:49:57,960 --> 00:50:01,560 But what I've seen in practice and we are right now moving into 739 00:50:02,400 --> 00:50:06,160 our private test net and have teams building with RQM really 740 00:50:06,160 --> 00:50:10,960 is seeing a lot of teams that have attempted building complex 741 00:50:10,960 --> 00:50:17,800 systems with FHE. And yeah, pivoted to using RQM 742 00:50:17,800 --> 00:50:21,480 because on the one hand it's, it's easier to use and on the 743 00:50:21,480 --> 00:50:28,360 other hand, it, it just yields the performance requirements 744 00:50:28,360 --> 00:50:33,640 that applications require. And so I think that's really 745 00:50:33,640 --> 00:50:38,240 what it, what it boils down to. And at the end of the day, all 746 00:50:38,240 --> 00:50:41,080 of that sort of is user experience, although 747 00:50:41,080 --> 00:50:44,200 trustlessness might be more hidden from the end user. 748 00:50:46,280 --> 00:50:49,880 And you know, in terms of applications, you know, 749 00:50:50,160 --> 00:50:53,920 obviously there's applications here in crypto and you know, I'd 750 00:50:53,920 --> 00:50:56,040 love for you to maybe talk a little bit about some of the 751 00:50:56,040 --> 00:51:00,400 applications that you you're seeing and that users, initial 752 00:51:00,400 --> 00:51:06,120 users are are building. But you know, applications here 753 00:51:06,120 --> 00:51:08,920 go beyond crypto. I think, you know, if we're, if 754 00:51:08,920 --> 00:51:11,520 we're talking about the, the trusted execution environment 755 00:51:11,520 --> 00:51:16,680 market, you know, potentially, you know, clients of T EE S you 756 00:51:16,680 --> 00:51:21,720 know, companies that use TES could shift using technologies 757 00:51:21,720 --> 00:51:24,840 like RKM. Maybe also describe some of 758 00:51:24,840 --> 00:51:27,880 those use cases and you know, efforts that you're making to 759 00:51:28,200 --> 00:51:29,720 address that part of the market as well. 760 00:51:30,880 --> 00:51:33,880 Yeah, sure. So I think that's also one of 761 00:51:33,880 --> 00:51:39,200 the more interesting aspects to, to, to building RKM that it's 762 00:51:39,200 --> 00:51:46,040 not just, yeah, solving problems in a crypto space, but solving, 763 00:51:46,720 --> 00:51:51,280 solving problems for the entire world for, for both enterprises, 764 00:51:51,280 --> 00:51:54,120 governments, any kind of of organization. 765 00:51:54,120 --> 00:51:59,200 I think. And that's also essential to, to 766 00:51:59,200 --> 00:52:01,680 the architecture design that we've we've designed. 767 00:52:01,680 --> 00:52:06,120 I mentioned that earlier that you as a developer don't have to 768 00:52:06,520 --> 00:52:09,680 deploy a smart contract or build a smart contract in order to run 769 00:52:09,680 --> 00:52:12,240 confidential computations. You're essentially just 770 00:52:12,280 --> 00:52:15,040 accessing this confidential computing network. 771 00:52:15,520 --> 00:52:20,520 And what that means is that on the crypto side of things, 772 00:52:21,320 --> 00:52:26,080 there's a lot of use cases, especially in Defy and DPN, 773 00:52:27,000 --> 00:52:32,040 there's a lot of teams building, building amazing stuff with, 774 00:52:32,040 --> 00:52:37,560 with our technology. And also I think, and that's I, 775 00:52:37,760 --> 00:52:42,560 I think something that is less important to the crypto space 776 00:52:42,560 --> 00:52:45,400 actually and more important to the, to the traditional 777 00:52:45,400 --> 00:52:50,720 computing space is being able to run confidential AI, more 778 00:52:50,720 --> 00:52:53,600 specifically confidential machine learning with RTM, 779 00:52:54,040 --> 00:52:58,400 because in the past confidential machine learning really hasn't 780 00:52:58,400 --> 00:53:02,360 been possible. And with this MPC based 781 00:53:02,360 --> 00:53:06,840 confidential computing, what's so striking is that completely 782 00:53:06,840 --> 00:53:10,920 new types of digital interactions I guess become 783 00:53:10,920 --> 00:53:17,160 possible because if all of us have isolated data silos, 784 00:53:17,160 --> 00:53:21,400 isolated data sets of highly sensitive data, that it on it's 785 00:53:21,400 --> 00:53:24,040 own is valuable, right? All of us care about our 786 00:53:24,040 --> 00:53:25,920 privacy. We would never share that data. 787 00:53:26,320 --> 00:53:32,640 But this data, if we were able to in some shape or form put it 788 00:53:32,640 --> 00:53:38,000 together and train AI models using, using that data, that 789 00:53:38,000 --> 00:53:41,080 could become very valuable. And I think a very striking 790 00:53:41,080 --> 00:53:42,840 example for that would be healthcare, right? 791 00:53:42,840 --> 00:53:47,280 So very sensitive patient data that now can be utilised in a 792 00:53:47,280 --> 00:53:51,200 trustless way. New models can emerge that can 793 00:53:51,200 --> 00:53:55,480 help all of us without any one of us ever having to expose 794 00:53:55,560 --> 00:53:59,520 their sensitive data. And this really is this 795 00:53:59,520 --> 00:54:03,480 collaborative element. And what we've seen is even 796 00:54:05,280 --> 00:54:08,840 logistic firms, right? So we're, we're talking with 797 00:54:08,840 --> 00:54:14,200 logistic firms that want to improve supply chains regardless 798 00:54:14,200 --> 00:54:15,440 of blockchain. They don't care about 799 00:54:15,440 --> 00:54:16,960 blockchain. All they care about is not 800 00:54:17,320 --> 00:54:20,280 giving their sensitive supply chain data to, to competitors. 801 00:54:20,280 --> 00:54:23,680 But at the same time, they can improve the supply chains. 802 00:54:24,080 --> 00:54:30,640 They can all have the sort of win win situation by using 803 00:54:30,640 --> 00:54:34,480 distrust less, Yeah, confidential computing 804 00:54:34,480 --> 00:54:36,320 technology. So I think that's really the 805 00:54:36,320 --> 00:54:41,400 power of decentralized confidential computing to to 806 00:54:41,400 --> 00:54:43,880 address traditional markets as well. 807 00:54:43,880 --> 00:54:49,080 And that's also what what drives us, that it's not just building 808 00:54:49,080 --> 00:54:53,480 applications for crypto's sake, but building applications for 809 00:54:53,480 --> 00:54:55,520 humanity's sake at the end of the day, I think. 810 00:54:56,920 --> 00:55:02,480 So when, when considering the, you know, the RKM network, like, 811 00:55:02,480 --> 00:55:06,240 I think one of the one of the important things to consider 812 00:55:06,240 --> 00:55:09,160 here, and I'd love to get your take on this is the, the 813 00:55:09,160 --> 00:55:11,760 censorship risk. So, you know, for in the case of 814 00:55:11,760 --> 00:55:17,440 like an application that would handle the healthcare data of 815 00:55:17,440 --> 00:55:22,000 like an entire nation, if we had like a small number of nodes, 816 00:55:22,000 --> 00:55:23,400 there would be a risk of censorship. 817 00:55:23,880 --> 00:55:25,920 And so therefore you'd probably want to have as many nodes as 818 00:55:25,920 --> 00:55:32,040 possible in there. Does are, are there basically so 819 00:55:32,120 --> 00:55:36,040 exit mechanisms to prevent censorship? 820 00:55:36,600 --> 00:55:41,960 And also does does the network performance, is the performance 821 00:55:41,960 --> 00:55:44,280 maintained as the number of nodes scale? 822 00:55:44,280 --> 00:55:49,040 Or do we end up, you know, does that start decreasing as you add 823 00:55:49,040 --> 00:55:52,320 more nodes to the network? Yeah, sure. 824 00:55:52,320 --> 00:55:57,040 So we have, we have multiple mechanisms to to to combat 825 00:55:57,040 --> 00:55:59,240 censorship. I think the the first mechanism 826 00:55:59,240 --> 00:56:05,520 that I outlined earlier this so-called on on a technical MPC 827 00:56:06,360 --> 00:56:08,400 level, it's called cheater identification. 828 00:56:08,400 --> 00:56:10,720 So to be able to cryptographically identify 829 00:56:10,720 --> 00:56:15,800 anyone who, who, who tries to stop a computation from from 830 00:56:15,800 --> 00:56:19,240 occurring and we can we can force everyone game 831 00:56:19,240 --> 00:56:21,560 theoretically to run the computation. 832 00:56:21,640 --> 00:56:24,240 Otherwise they get slashed, they get punished. 833 00:56:24,760 --> 00:56:29,840 Now if such a misbehaviour happens and the misbehaving 834 00:56:29,840 --> 00:56:33,840 party doesn't care about losing all of their staked assets, 835 00:56:35,160 --> 00:56:38,240 there's fall back mechanisms. There's so-called cluster 836 00:56:38,240 --> 00:56:41,320 migration. So to be able to move from one 837 00:56:41,320 --> 00:56:44,840 cluster of nodes to a new cluster, there's also cluster 838 00:56:44,840 --> 00:56:50,400 forking mechanisms so that nodes that want to censor because 839 00:56:50,400 --> 00:56:54,800 maybe there's some, some, some, some kind of computations 840 00:56:54,800 --> 00:56:58,280 happening where one node says, OK, I'm not comfortable 841 00:56:58,760 --> 00:57:00,400 processing these kinds of computations. 842 00:57:00,640 --> 00:57:05,720 So there's really also this tension of of censorship because 843 00:57:06,440 --> 00:57:10,600 we want to force nodes to run any computation at the same time 844 00:57:10,720 --> 00:57:15,480 there might be based on on where the the node is being operated 845 00:57:15,720 --> 00:57:18,600 also legal implications to not be able to, to process certain 846 00:57:18,600 --> 00:57:21,880 computations. And so we have both mechanisms 847 00:57:21,880 --> 00:57:25,720 we can allow for nodes to say, OK, in the future, I will not 848 00:57:25,720 --> 00:57:28,600 want to process more computations for this 849 00:57:28,600 --> 00:57:31,200 corresponding MXE. And they can do that. 850 00:57:31,200 --> 00:57:33,840 They need to pay for the so-called cluster forking them. 851 00:57:34,240 --> 00:57:40,520 And there can also be those forceful migrations if a node 852 00:57:41,160 --> 00:57:45,760 trust doesn't trying to compute the function that they have to 853 00:57:45,760 --> 00:57:48,440 compute. Right. 854 00:57:48,440 --> 00:57:52,400 Maybe taking it back to the use cases for like a potential final 855 00:57:52,400 --> 00:57:55,240 question where we're talking a lot about Arcum being this 856 00:57:55,240 --> 00:57:57,640 platform. And actually you already also 857 00:57:57,640 --> 00:58:01,400 mentioned initially you were building like this confidential 858 00:58:01,520 --> 00:58:03,960 confidentiality thing on on elusive, right, Like kind of 859 00:58:03,960 --> 00:58:06,600 more application focused almost or I guess in general, the 860 00:58:06,600 --> 00:58:08,000 elusive product was more application. 861 00:58:08,520 --> 00:58:12,000 Now you're this platform and obviously if you're a platform, 862 00:58:12,000 --> 00:58:14,480 you have to do like ecosystem building. 863 00:58:14,480 --> 00:58:18,960 You're, you're mentioning you've been speaking to a lot of like 864 00:58:18,960 --> 00:58:21,680 logistics firm, like in health, like traditional businesses. 865 00:58:22,760 --> 00:58:25,480 And I think you also like mentioned, like you yourselves 866 00:58:25,480 --> 00:58:28,320 met in the hacker house right in, in Solana, which I think 867 00:58:28,560 --> 00:58:31,960 quite interesting and probably one of the best ecosystem 868 00:58:31,960 --> 00:58:35,480 building examples in all of crypto in the recent years, 869 00:58:35,480 --> 00:58:37,400 right? Seeing like it brought also you 870 00:58:37,400 --> 00:58:40,240 together and, and just generally how successful Solana has been 871 00:58:41,440 --> 00:58:43,120 with that. So yeah, the question basically 872 00:58:43,120 --> 00:58:46,400 is like how you approaching this, how are you getting people 873 00:58:46,400 --> 00:58:49,640 to build on on the RTM platform? Yeah. 874 00:58:49,640 --> 00:58:55,720 So we currently have way too many people trying to build an 875 00:58:55,720 --> 00:58:58,840 RTM. That's that's the current 876 00:58:58,840 --> 00:59:01,720 status. So a few months back when we, 877 00:59:01,720 --> 00:59:06,600 when we announced RTM, we, we started accepting developer and 878 00:59:06,600 --> 00:59:12,040 node operator sign ups for, for the private test net, which we 879 00:59:12,040 --> 00:59:15,080 started rolling out. And currently we are in the 880 00:59:15,080 --> 00:59:20,720 cohort one phase or the first group of, of developers that get 881 00:59:20,720 --> 00:59:24,560 hands on support from us, get access to, to all of the tooling 882 00:59:24,560 --> 00:59:26,680 and, and can start building applications. 883 00:59:27,200 --> 00:59:31,840 And step by step we are, we're expanding those, those cohorts 884 00:59:31,840 --> 00:59:37,000 and, and adding more teams so folks can join our Discord can, 885 00:59:37,000 --> 00:59:42,600 can register to be able to be accepted to those private test 886 00:59:42,600 --> 00:59:45,960 net development rounds. And then they Get full access to 887 00:59:45,960 --> 00:59:50,920 RQM and can build their applications and get yeah, 888 00:59:50,960 --> 00:59:52,960 development support from from our end. 889 00:59:54,000 --> 00:59:56,640 That's Congrats on the success there for sure. 890 00:59:57,200 --> 00:59:59,280 Yeah, I hope we'll we'll see like a bunch of cool 891 00:59:59,280 --> 01:00:02,240 applications. SAP any anything else from your 892 01:00:02,240 --> 01:00:09,520 point or? No, I'm just like always amazed 893 01:00:09,520 --> 01:00:13,880 that like these technologies, you know, as great as they are, 894 01:00:14,560 --> 01:00:18,880 you know, the, the technologies that we really need, you know, 895 01:00:18,880 --> 01:00:22,280 like private compute, more privacy technologies are not the 896 01:00:22,280 --> 01:00:28,600 ones in crypto that, you know, get the most attention or get 897 01:00:28,600 --> 01:00:31,080 the most capital. And so I'm, I'm just really glad 898 01:00:31,080 --> 01:00:37,760 to see RKM like, you know, raise 5.5 million recently and hear 899 01:00:37,760 --> 01:00:42,200 from some pretty big VCs and, and hopefully like take this 900 01:00:42,200 --> 01:00:44,080 technology to market 'cause I think it's, it's really 901 01:00:44,080 --> 01:00:46,680 important. You know, I also at some point, 902 01:00:46,680 --> 01:00:48,880 you know, brought all my family to signal and thought that was a 903 01:00:48,880 --> 01:00:50,080 really big achievement. Yeah. 904 01:00:51,000 --> 01:00:54,560 Even though, you know, Signal might be back doored and we have 905 01:00:54,560 --> 01:01:00,400 no real way of finding out, you know, but yeah, I think like, 906 01:01:00,400 --> 01:01:03,720 this stuff is important and and it's also political. 907 01:01:03,720 --> 01:01:06,240 I think we shouldn't, we shouldn't forget that like, 908 01:01:06,240 --> 01:01:09,520 encryption is a political issue, more than just a technological 909 01:01:09,520 --> 01:01:11,000 issue. And so I'm glad we can talk 910 01:01:11,000 --> 01:01:13,360 about here on this podcast. Thanks for coming on, Yanique. 911 01:01:14,080 --> 01:01:18,440 Thanks for having me guys. Thank you for joining us on this 912 01:01:18,440 --> 01:01:20,840 week's episode. We release new episodes every 913 01:01:20,840 --> 01:01:22,840 week. You can find and subscribe to 914 01:01:22,840 --> 01:01:26,600 the show on iTunes, Spotify, YouTube, SoundCloud, or wherever 915 01:01:26,600 --> 01:01:29,000 you listen to podcasts. And if you have a Google Home or 916 01:01:29,000 --> 01:01:31,800 Alexa device, you can tell it to listen to the latest episode of 917 01:01:31,800 --> 01:01:35,800 the Epicenter podcast. Go to epicenter.tv/subscribe for 918 01:01:35,800 --> 01:01:37,480 a full list of places where you can watch and listen. 919 01:01:37,480 --> 01:01:40,400 And while you're there, be sure to sign up for the newsletter so 920 01:01:40,400 --> 01:01:42,800 you get new episodes in your inbox as they're released. 921 01:01:43,640 --> 01:01:46,040 If you want to interact with us guest or other podcast 922 01:01:46,040 --> 01:01:47,680 listeners, you can follow us on Twitter. 923 01:01:48,040 --> 01:01:49,560 And please leave us a review on iTunes. 924 01:01:49,560 --> 01:01:52,040 It helps people find the show and we're always happy to read 925 01:01:52,040 --> 01:01:54,400 them. So thanks so much and we look 926 01:01:54,400 --> 01:01:55,560 forward to being back next week.