What we were designing was a system where users had this privacy utilizing 0 knowledge proofs and every private transaction that one performed generated an encrypted transaction that was stored on chain. And then we had a dedicated network of notes that using MPC was able to screen those transactions essentially. But importantly, there was no trusted entity that could screen
or block a transaction. It was the network as a whole that ran secure multi party computations, overdose encrypted transactions, arbitrary program execution in a confidential encrypted way, but to also have the program itself be fully encrypted and to have encrypted random access memory. This sort of replacement for you purchasing some trusted execution environment. Now you can use this global supercomputer to execute anything.
If you're looking to stake your crypto with confidence, look no further than course one. More than 150,000 delegators, including institutions like Bit Go, Pantera Capital, and Ledger Trust Course One. With their assets, they support over 50 block chains and their leaders in governance or networks like Cosmos, ensuring your stake is responsibly managed. Thanks to the advanced MEB research, you can also enjoy the highest staking rewards.
You can stake directly from your preferred wallet, set up a white label note, restake your assets on Eigenia or Symbiotic, or use the SDK for multi chain staking in your app. Learn more at Chorus .1 and start staking today. This episode is proudly brought to you by Gnosis, a collective dedicated to advancing a decentralized future. Nosys leads innovation with Circles, Nosys Pay and Metri, reshaping open banking and money.
With Hashi and Nosys VPN, they're building a more resilient, privacy focused Internet. If you're looking for an L1 to launch your project, Nosys Chain offers the same development environment as Ethereum with lower transaction fees. It's supported by over 200,000 ballot errors, making Nosys Chain a reliable and credibly neutral foundation for your applications. Gnosis Dow drives Gnosis governance, where every voice matters. Join the Gnosis community in the
Gnosis Dow forum today. Deploy on the EVM compatible Gnosis Chain or secure the network with just one GNO and affordable hardware. Start your decentralization journey today at gnosis dot IO. Welcome to epicenter of the show, which talks about the technologies, projects and people driving decentralization and the global blockchain revolution. I'm Sebastian Coutura and I'm here with my Co host, Felix Lutch. Today we're speaking with Yannick Shada. He's the CEO and Co founder of Arkham.
It is a private compute platform that allows for all sorts of interesting use cases, privacy in crypto and beyond. So we'll be chatting with him today about Ark M, the architecture, their use of MPC, and much more. Yeah. Thanks for joining us today. Thanks for having me, Sebastian and Felix. I'm very excited. Yeah. So tell us a little bit about your background and how you got involved in in the encryption and privacy space and how do you how you ended up working on Ark M?
Yeah, sure. So I think the reason why, why I'm in the space of, of building Arxium, building confidential computing, decentralized confidential computing and privacy technology. At the end of the day, it might boil down to me as a small child reading 1984. I think that might be the, the honest answer. I think that that really shaped my my perception of the world and and my views of how the world should work and how how
privacy and freedom matters. And reading that as a child I think really, really influenced me. So at a similar age, I started programming, teaching myself programming, then studied law for a bit and then through founding my first start up pivoted to mathematics and
computer science. In the process away from studying trust law and then through the study of, of mathematics and computer science, I met my Co founders, basically one of us caring about elliptic curves at that point because that's what we what we learned about in university and then getting into zero knowledge proofs and through the process of that and they ended up founding Archaeum, which back
then was called elusive. And yeah, with elusive we, we focused on building transactional on chain privacy and we found the edit twist I guess of, of adding trust, less decentralized compliance so that there's both privacy and still safety on the end of of the users. So unwanted illicit behaviour could be excluded from from, from this. Yeah, on chain on chain privacy architecture. And for that we leveraged confidential computing with secure multi party computations.
And through the process of designing the system and building this technology, what we realized is the the huge potential and the revolutionary potential of being able to run arbitrary computations over encrypted data without having to decrypted data first. So data in use can remain fully encrypted and anything can be processed on top of the data.
And so that was really a pivotal moment, this realization for us, which then allowed us to to evolve further into Arcum and fully focus just on providing this what we like to call distributed global supercomputer that allows for confidential computing. Awesome. Thanks for the quick overview. We're going to dive a lot into Arcum over the course of this. Of course. I think for me also interesting because that's like how I got to
know you. I think working on Elusive and also like working in, in the Solana ecosystem. Can you maybe break down how you, how you start in Solana and, and couldn't know kind of why you, how you came to the conclusion to add this like compliance angle? I think that was like kind of like one of the main differentiators there in, in, in what you were building or in Solana. Yeah, sure. And so I think how we got into Solana is the is the story of of many teams that are building on Solana.
It was really the the developer ecosystem. And so the the final Co founder of our team, actually I met the Solana hacker house. So in the year 22, there were a lot of hacker houses and and this really allowed developers wanting to build new interesting projects to meet up to, to talk with experienced founders and then yeah, test, test the systems that they were building. So that's what we also did how we came, came about building on Solana.
And yeah, back in the day with elusive, what we, what we were building was essentially AC cash like on chain privacy system, which utilised 0 knowledge proofs as as core primitive. And the issue that basically all of those systems face at some point really is compliance concerns, right? Because we've, we've seen that Tornado Cash essentially, right.
So with Tornado Cash, there were enforcement actions by different governmental agencies because, yeah, they claimed that Tornado Cash didn't prevent malicious behaviour on the on the platform. And if one utilizes mathematics to provide perfect privacy guarantees, yeah, that's, that's
the issue that they run into. And So what we were designing was a system where users had this privacy utilising 0 knowledge proofs and every private transaction that one performed generated an encrypted transaction that was stored on chain. And then we had a dedicated network of nodes that using MPC was able to screen those transactions essentially. But importantly there was no trusted entity that could screen or block a transaction.
It was the network as a whole that ran secure multi party computations, overdose encrypted transactions and essentially in a within a black box. This virtual black box were able to look into the transactions and assess what happened and then they could find external consensus over, yeah, malicious parties that that tries to use that system and then after the fact reveal, reveal that the corresponding information.
And so that was extremely powerful because yeah, prior systems really attempted to to add compliance by screening transactions upfront. And with this systems as a screening after the fact ex post was possible, which I think would be the ideal solution. And that's something that is possible to to build with RKM. But we really realised that, yeah, I think through the technology that we were developing and we'll we'll dive more into this later, I guess.
But the complexity of this MPC technology, I think there was just one area we had to focus on. And we really saw our strengths in, in building this computing platform and optimising the compute both for trustlessness but also performance. And so that's what we ended up doing. And you know, in the case of, you know, you mentioned Tornado Cash, like I, when I, when I heard about that, I, I couldn't help but be reminded of, you know, the, the cypherpunk stories of the 90s.
And we had Mark Miller on the podcast. Tell us about how you he used to print the RSA algorithm on T-shirts because the US government considered that encryption technologies were, were considered under U.S. law to be, to be weapons like to be munitions. And so therefore, you know, you couldn't export them.
And there was this whole, you know, legal threat and sort of threat of persecution on, on those people in the 90s, you know, that that were simply just freely expressing ideas and, and, and more to the point, like just making math public. And so like, I, I heard that, you know, the tornado cast story and like it, it felt to me like very similar where, you know, these guys basically like wrote math that this stuff was the stuff exists. It cannot be stopped.
And, and I, I think that we'll look back on turn into cash in the same way that we look back on, you know, the, the sucker punks in the 90s and what they were doing. There's really, you know, little one can do to prevent malicious activity when you're using encrypted technologies. I think it's like a huge societal debate, but I hope one that, you know, people that sort of subscribe to the idea that encryption, you know, is just freedom of speech and, you know,
is sort of like a right. I hope that, you know, those people will fall on the right side of history.
You know, having you, you, you said earlier you came into the space and you were kind of inspired to work in crypto, having read in 1984, you know, how did you, how did it make you feel that, you know, you were sort of constrained to, to build a technology that enabled compliance when you, you had such this, you know, this very strong background and and sort of ideological pedigree of like non compliance in, in, in, in that sense. Yeah, so I I think that.
So first of all, yeah, I am 100% on this on this cyberpunk track. I think one of my greatest accomplishments in the in the privacy space would be getting my entire family to to your signal and having the entire family group chat be be present on Signal instead of WhatsApp. So I think this this compliance
question is an interesting one. And the way I think about it really is that we gave control in the hands of the people using it. At the end of the day, there was no external action of enforcing compliance. It was essentially being able to have distributed consensus and giving users the option to use whatever system. So it's the design that that that we designed back in the day with illusive really was decentralized compliance.
So no centralized actor should be able to to have any control. It should be the users that have control. And I think at the end of the day, and yeah, we never ended up getting to this point to to see that an action and an experience those those those game theory and network effects. But I think at the end of the day, yeah, it boils down to do users want specific other users using the servers for specific
kinds of of of use cases. And I think it's a bit more easy to to have these mechanisms with this, yeah, with those financial mechanisms attached. Whereas it's way more different if it's just pure, yeah, expression of ideas, right. So I think that's a system that made sense that at the end of the day found natural equilibrium between both ends.
Yeah, it's, it's hard not to not to also bring up, you know, the the whole story around the the Telegram founder who was arrested in France, I think like last week. Yeah. Any any thoughts on, on, on that? And you know what it means for the for the state of privacy technologies in Europe. Yeah. I to be honest, it's very, it's
very difficult to say. I think Telegram is, is is difficult, is difficult for me because on the, on the encryption side of things, Telegram always, especially in yeah, more, more mainstream media, I think is being portrayed as this super encrypted private chatting platform that that cannot be hacked. Whereas in reality, there's no default, Yeah, encrypted chatting between two peers, right? So I think the story is is difficult.
Yeah, it's, it's, it's interesting to see at least like, you know, here in France, I've been watching main mainstream media talk about talk about Telegram as this encrypted messaging. In fact, they they, they, they don't even use the word encrypted. They use this this other word that in French that that doesn't even mean encrypted. I mean, you know, and it's like, it's as if they were calling it a, you know, a cyber messenger instead of an encrypted messenger.
And, and it's, it's really painted as this kind of like black box thing, right? That you can tell that the story is spun in such a way when in fact, you know, like anybody who uses WhatsApp, you know, is in fact using encrypted technology and anybody who uses Apple messenger is using encrypted technology. And Telegram is really painted with this, with this very negative sort of lens.
So it's, it's interesting to see how even the mainstream media here, and I'm sure probably in Germany and other places as well as like very biased against these technologies for some reason. But anyway, not to make this all about, about that, you know, we do want to talk about RKM and, and what you guys are building. So let's, let's talk about, you
know, confidential computing. So, you know, what does that mean and what are the different ways that you know it has been implemented in the past and what's kind of new about the the way you guys are going about building it? So yeah, I think confidential computing has been around for for quite some time already. And at the end of the day it means that computations can be performed over encrypted data without having to decrypted data. So it's it's about so-called data in use, right.
We have data in REST which just lies encrypted on some hard drive. But data in use is the data that actively is is being used in a computation. And so confidential computing allows for that data in use to be secure. That's what what confidential computing tries to achieve. And there's different, different use cases, I guess for confidential computing.
For one, creating a secure execution environment, right, having sensitive data, critical, critical business data, for example, right, that that has to be executed over in in some cloud environment. And if that data were to be leaked, bad things could happen to companies, enterprises, governments or individuals. So building secure execution environments. At the same time, confidential computing allows for data collaboration essentially.
So some individuals can have their data remain private while being able to interact with others. So those are two core aspects of what confidential computing tries to achieve. And there are different kinds of technologies that have been utilised in the past to to achieve this. And I think the most prominent one so far has always been trusted execution environments.
And a few months back, I was in in San Francisco at the so-called Confidential Computing Summit, which essentially is just a conference of trusted execution environment manufacturers and Intel, Microsoft, all those folks, they're praising their trusted execution environment technology
and. Yeah. I gave a talk there and I called it trusted execution is dead and we have killed it. And so my take really is that there's new kinds of technologies now that can replace those legacy systems that require trust. So what we're trying to achieve at RTM and what the entire decentralized confidential computing DCC movement I think to some degree is trying to achieve is to add more trustlessness to to confidential computing. And in our case that's by utilizing multi party
computation. So maybe you can kind of I guess bring up the T ES already and we have seen over the years a lot of different types of attacks on these, I think yeah, like side channel attack kind of supply chain tags and still like. Like you're saying right in the summit, everyone's talking about that. I think also in the crypto space right now, T seems to have another like sort of resurgence and popularity. Is that or like, you know, why is that maybe and how does MPC improve on that?
Or like, how do you, yeah, tackle that at Arqum, Like to sort of maybe explain also a little bit what these types of attacks actually are? Yeah, sure. So, so trusted execution environment are dedicated hardware that comes with security and privacy promises essentially from from the manufacturers. So usually that's dedicated hardware chips that have those secure enclaves is what it's called.
So virtual machines within those chips where data should remain secure, encrypted and cannot be accessed outside of that of that enclave and enclave has a code base associated with it. So only the specific code base can be executed over that over that state. Which sounds like a great concept, sounds like a difficult to realise concept. At the same time, thinking about exploits and hackers. So those systems suffer from from from many problems.
I think the most easy to grasp problem is that actually the complexity of building building architectures on top of crossed execution environments. Anyone who has worked with with T ES will will tell you that it's very difficult to build secure code on top of those on class because developers really have to have to ensure that data is being handled correctly. And they need to give rigorous attention to detail that the boundaries between the secure and non secure environments are
being respected. And that also at the same time brings, yeah, increased time to market, I think because there needs to be a very, very fought through development processes and those systems at the same time also on their own come with quite high costs associated. It's dedicated hardware and dedicated hardware that requires specialized folks that that are able to maintain and develop on, on those platforms.
Those are more of the soft factors that I don't like about working with trust execution environment. And the bigger problems really are associated with the trust model. As the name already communicates, the execution here is trusted. And the trust model in my opinion is fundamentally flawed because as you said, Mt ES are really susceptible to a whole range of, of, of more or less sophisticated attacks. And I don't know if you guys saw this but 1 1/2 weeks ago or
something like that. I think there was some some researcher on Twitter that was able to extract the route provisioning key from some Intel SGX family processors, which is a key that can be used to to fake so-called attestation report. So trusted execution environments require this process of attestation where they prove to you that they are a real trusted execution environment and you can trust this environment. So you can send your data in an encrypted way to the
environment. And this at the station service. Yeah, requires some third party trust. Yeah. Regardless, on the processor side of things, there's side channel attacks and hardware vulnerabilities. And side channel attacks really boil down to you as as the person having access to to the processor or you being able to trust track the execution of
some program execution. And through this process of being able to look at for example, power consumption or or tracking other metadata, I guess that gets exposed through the execution of a program be able to understand the execution path in our program, right. So if you think of an if else statement and if some some condition holds something complex is being executed, it takes one hour. And the else case the program trust ends.
If the computation takes one hour, you will know, OK, the condition was true because the first branch was executed. And so that's, that's the most simple form of performing a side channel attack, right. And so those processors are prone to these kinds of side channel attacks and there's many, many exploits that have occurred in the past and many fixes for those exploits, but it's always new exploits that
that get identified. So in the blockchain space, we've seen a number of those kinds of exploits. Actually, I think the most notable one would have been
secret network. I think there was end of 22 where there I think it was called a seat key or something like that some some master key that was shared between all all the notes in the network, all the T ES there was exfiltrated and then anyone whoever ran a note in the network would have been able to yeah, we we won't remove the privacy of all transactions right. So there's this inherent danger of side channel attacks firmware micro code and SDK box.
It's just this large development stack with incredible complexity and both on the hardware, but also on the software, firmware micro code level where at the end of the day humans are building those systems. And so humans in most cases are also able to to exfiltrate information. Those are one kind of of exploits.
But I think more important is as you, as you mentioned, Felix, supply chains, because when someone trusts a trusted execution environment, they're trusting a supply chain, usually proprietary supply chain, which at the end of the day is just a chain of single points of failure. Single points of failure that can occur in that station process, can occur in the manufacturing process.
And I think a very striking example of how trusted the systems are is when, when Apple unveiled their private cloud computing platform, which is their own T ES that they they supply for, for for model inference for their Apple intelligence. I think something that they stated in their docs in their release article was something like, OK, they physically ensure that the, that the machines from the factory get placed in their, in their data centre, right.
So you can imagine and people standing there with their assault rifles protecting crates of, of of computer chips, which is in Zain, right? If that's the trust model that you're working with, that there has been someone that was able to physically guard this chip from A to BI think that's not something that that we should put all of our trust in. So what I wanted to ask you? About like, because you know,
we've been focusing on SGX here. And I think, like in crypto at least, you know, SGX has gotten a lot of negative attention because of the secret hack and, and, and, and some other issues. And like, I'm, I'm here on the Wikipedia page for, for Intel S jacks and there's about, you know, a dozen different attack vulnerabilities that are mentioned.
But so why is it then that, you know, we never hear of like the Apple tee in our phones being compromised or, you know, even perhaps more interestingly, like Ledger devices? You know, they, they claim that, you know, they're super secure and, and they had like this whole, what they call it the, the, the, the dungeon or something like that. You know, their, their, their whole like security lab that just pries all day at trying to crack a Ledger.
So why? Why are TS different or, or are they you know, is this just a misconception or lack of understanding of the technology? Yeah, I, I, I think SJX has gotten a lot of attention. The architectures are, are significantly different in the details, of course, but the core architecture and the core reliance on, on these kinds of
supply chains remains the same. And yeah, I think in general there's yeah, I think so. So we can, we can go more into that how I think trusted execution environments can play a role in the future. I think they can play a role. But yeah, just this this approach of using these systems and saying, well, so far we didn't see any exploits. So we can be sure that we can trust our systems and we can use
them for for all our future. I think that's, that's a flawed, flawed approach because at the end of the day, it's just the sort of non provable blind trust in the case of Intel SGX, we've seen how how fatal this can be really. And I think what's important. And that's something that I've, I think never seen anyone talk about when, when talking about
these kinds of supply chains. In the case of Intel SGX, that's something that, that we've seen with different kinds of, of teams that, that use the technology. Was that OK? There's the supply chain and trust into Intel essentially. And the person that has access to, to the, to the computer trip. But there's also someone who deploys the code for the, for the enclave and they upgrade the code. They, they, they give updates and they have a private key they
use to, to sign those updates. And so there's a single signing authority that can update whatever code, they can have their own local trusted execution environment, update the code and exfiltrate information. And at the end of the day, in most crypto projects that use trusted execution environments, yeah, easy as single point of failure really is some development agency sitting on some island, I guess that has a private key that has full
control over everything. I think that's the that's the most shocking, shocking aspect. And that's overlooked a lot when when talking about the trust in the manufacturer. Most most of the times it's. It's even simpler than that. It's a $5 ranch attack. You just you have to get the boat to the island. Yeah, exactly. OK. Yeah, that that's super interesting. I think, I guess we're we still haven't even talked about MPC. So, so let's get there.
I guess, you know, we're basically focusing on these hardware based models, but now we also have like purely cryptographically based privacy techniques and how do they work and like what are their trade-offs and, and how do you like navigate that trade off space? I guess that's going to be the discussion for the next few minutes, hopefully. Yeah, yeah, sure. So essentially the other technologies are 0 knowledge proofs, fully homomorphic encryption and MPC, 0 knowledge
proofs. We've spent a lot of time working with zero knowledge proofs are, yeah, great technology. And at the end of the day, zero knowledge proofs are even part of those FHE and MPC proving system. So, but, but CK snarks, CK snarks those, those more, more prominent proving systems. Yeah. They don't allow for what we're
trying to achieve. What we're trying to achieve really is to be able to have some encrypted data, send it to the some cloud environment, some some blockchain network, whatever, send it to some some some computer and have it processed without that party that processes it having access to the data. And and 0 knowledge proofs are just two party protocol where one party is the prover that has access to the data and the second party to verify verifier
not having access to the data. So 0 knowledge proofs on their own can't allow for those Autonomous confidential execution environment. FHE fully Homomorphic Encryption allows for that. Essentially, the definition of of FHE would be to be able to to execute arbitrary operations
over encrypted data. So there's an encrypted representation of of some state and with FHE two operations, essentially additional multiplication are homomorphic over that representation, which means that they yield an output that again lies in this representation. So on. That is a very, very good
concept. And the problem with FHE really is the practical usage of the technology, because the multiplications for fully homomorphic encryption result in noise accumulation, and noise accumulation requires bootstrapping. So bootstrapping operations essentially reduce the noise of this encrypted output. And if there's too much noise, that output can't be, can't be processed anymore. So bootstrapping is required. And that results in very high, very high performance latencies
and and computational overhead. And that means that when using these kinds of FHE systems, there's many orders of magnitude performance latency associated. And so it's, it's not unusual. And I think comparing the the MPC protocols that we have with some FHE operations and it's not unusual for us to see something like as being faster 80,000 times, something like that. So incredible performance differences. And for very, very simple operations, FHE can be used.
But yeah, more complex computations make this technology fail at the end of the day in in practical implementations. And so the system that we are using is multi party computation. And this multi party computation uses so-called somewhat homomorphic encryption. SHE and somewhat homomorphic encryption basically uses the efficient aspects of homomorphic fully homomorphic encryption that we we also utilized there.
But for multiplications, there's a smart trick associated I guess that allows us to to efficiently perform those multiplications as well. And so that's why this technology makes most sense. And on top of that, what's also very important to realise with FHE is that moving from encrypted representation to encrypted representation is very nice. But if, what if one wants to move out of the encrypted representation, right?
If we have confidential on applications and we want some transparent settlement to occur, there has to be a way to selectively disclose information about the the encrypted state. And that's not possible with FHE by default. And with NPC that becomes possible. And so trust model wise, what's the case is that the trust models for for systems in practice, it's the same for MPC and and FHE applications with MPC being many orders of magnitude faster. And so that's why we arrived at
building those systems with MPC. Super interesting. And do you think like, I guess in general, this is also something that fhe can ever address in a way? Like is it something that, you know, over time the algorithm will get better And like, I'm probably right. I mean, but yeah, we'll be curious about that. That mostly boils down to to hardware acceleration. So hardware acceleration is is what matters most for that. There will be significant improvements for sure.
And what's important is that those hardware acceleration improvements also get utilized by this somewhat homomorphic encryption system in, in, in, in MPC, MPC still requiring network communication. That's, that's, that's one difference requiring some more network communication at the same time FHE in order to achieve verifiable compute with FHE, you also require consensus mechanisms.
If you, if you do it in the in the blockchain setting, if verifiable compute, which is highly important for for any computation, especially confidential computations.
If, if verifiable computers achieved without using consensus, there's even more significant performance slow down South. Hardware acceleration is what it boils down to. And I think these kind of hardware accelerations will also be utilisable for for the MPC protocols, especially with, with recent, yeah, with recent advancements in those in those protocols greatly reducing the the need for for network communication.
So there's different, yeah, options to to be able to pack a lot more data within communication around. So yeah, I think at the end of the day, FHE will become more performant. But yeah, at this point in time, NPC trust makes more sense. So it's always about, yeah, being able to supply the required privacy technology at this point in time and for the next years. And so it's the same with with fusion energy, I guess, right? We also need energy now and for the next 10 years without having
fusion energy. So does this work with any type of computation? Can you do? Can you perform really complex computations using RTM? And what what languages can one write computations? And does this implementation support like specific languages?
Can you maybe explain that? How what we're trying to achieve essentially as as as the wish with RTM and that's why I like to call it a supercomputer really is for arbitrary program execution in a confidential encrypted way, but to also have the program itself be fully encrypted and to have encrypted random access memory encrypted RAM, right. So to have a fully encrypted computer, you really have this sort of replacement for you purchasing some trusted
execution environment. Now you can use this global supercomputer to execute anything arbitrary programs that are essentially arbitrary encrypted RAM programs. The current stage we are at is that we support arbitrary computation support. And for that we have a dedicated compiler that compiles arbitrary Rust code into the into the up code micro code format that our network understands. Yeah. So one could essentially be be
writing assembly code. So on the up code level, but what the network understands, but what we offer mainly is the dedicated, yeah, Rust compiler. Now depending on the use case, different languages make more sense. So what we have at Arghum right now is 2 distinct back ends, 2 distinct NPC protocols, 1 NPC protocol that is highly focused on being as trust less as possible for especially on chain applications. And we have another back end that is fine-tuned for floating point operations.
So in order to perform operations over large mattresses with Floating Points for machine learning and so for that back end, we we support a Python SDK essentially. So one can use Tensorflow and pandas like they would normally and now have it be confidential and have one party holds this data, another party hold another data and then collaboratively train. Yes, logistical regression or or
tree boosting model with that. So essentially Rust and Python for for the machine learning applications is what I would say, yeah. Awesome. Let's maybe also take it back to like RQM as this network overall, right? Like so we talked about, you know, why you're using MPC and, and confidential computation, but to achieve this at scale, right, there is a, a network and there is the crypto component of it.
So can you provide us like a overview over the RQM structure architecturally as a as a crypto protocol and and how, how that functions? Essentially RQM itself is a, you could say stateless computing network. So we utilise existing lectures, existing blockchains for state management and computation scheduling.
So you can have your own smart contract on Solana, for example, that has confidential functionality, and this smart contract then calls an RQM smart contract that inserts a new computation within the RQMM pool. The network picks that up, executes the computation, and settles it back to the corresponding network. What's important is that the RQM network itself, you don't write
a smart contract for RQM. You, you can use our smart contract SDK and build a confidential smart contract, but the network itself just runs confidential computations and it picks those up from those dedicated on chain mem pools that can exist on different letters. And so I can build a confidential off chain application and send such a computation request to the mem pool and it doesn't have to settle back to the to the
dedicated smart contract. Now how the network itself functions is essentially it's a permissionless network of nodes. And so the three of us could deploy a node in RTM and we could open up so-called computation cluster. So our computation cluster could now be used by anyone to run confidential computations. Or we could restrict that computation cluster to say, OK, we don't care about providing computational services to third parties. We just want to run our own confidential computations.
So it's fully configurable. You can have clusters containing nodes from the network. You can run your own node. And what's so highly important about the trust model associated there is that it's the dishonest maturity trust model. So any computational cluster only requires 1 participant to be honest, one participant that doesn't collaborate with all the others participants in a malicious way.
So with that trust assumption, you can have arbitrarily sized computation clusters and associate them with a so-called MXEMPC execution environment. So that's essentially just virtual machine instance that you create as a developer. You create this virtual machine instance where you have encrypted stage, you have your functions that can be called essentially analogous to a smart contract if you will.
And that environment has one or more clusters associated that then process these kinds of computations. Now the problem one on a theoretical level would run into is that such a computational cluster has this ideal trust assumption only requiring the trust that one node is honest, right? Which for our block trends we have with with practical Byzantine fault tolerance, we have the honest majority trust assumption and here dishonest
majority trust assumption. One out of N really is perfect. But a problem is that this also becomes highly dangerous for censorship because one malicious party could also censor computations. And that really has in the past been a practical limitation for those very efficient and trust less MPC protocols because, yeah, deploying them in this permissionless setting could really mean that some malicious party could just DDoS the operation essentially.
And So what we have is a new kind of cryptographic protocol that allows to enforce execution and also correct execution for for these computational cluster. So if you have this computational cluster and our cluster in this example, and Sebastian just randomly decides to share some invalid data with me, at some point I will notice that invalid data has been shared and I will stop the computation as I'm an honest
participant. The problem now is that by default, Felix and I wouldn't be able to cryptographically identify that Sebastian was the one that caused the computation to fail by sharing a valid data. Now with our new protocol, we are able and actually everyone in the world viewing our our computation from the outside is able to identify that Sebastian is the one that caused the computation to fail. And what that means now is that we can punish Sebastian for
causing the computation to fail. And so that's where block chains really come into play, that we are able to enforce execution of those computations and enforce this kind of correct behaviour. So we are able to add accountability to those computations, which makes it incredibly powerful now because then even smaller sized clusters, yeah, can be performant run those computations and the the deployer of of these clusters can can be certain that
execution will occur. And so that's where our staking and slashing mechanism comes into play. So compared to other, you know, privacy projects out there, you know, how do you think RTM is fundamentally different? Like what, what is really the the, the key differentiator that you guys are offering as a product? Yeah, I, I think that really boils down to be trustless and
performant at the same time. Because what we've seen really in the past is that that systems either require trust, we are trusted execution environments or have incredible slowdowns with fully homomorphic encryption. And this sounds stupid saying that as as the founder of RQM. But what I've seen in practice and we are right now moving into our private test net and have teams building with RQM really is seeing a lot of teams that have attempted building complex
systems with FHE. And yeah, pivoted to using RQM because on the one hand it's, it's easier to use and on the other hand, it, it just yields the performance requirements that applications require. And so I think that's really what it, what it boils down to. And at the end of the day, all of that sort of is user experience, although trustlessness might be more hidden from the end user.
And you know, in terms of applications, you know, obviously there's applications here in crypto and you know, I'd love for you to maybe talk a little bit about some of the applications that you you're seeing and that users, initial users are are building. But you know, applications here
go beyond crypto. I think, you know, if we're, if we're talking about the, the trusted execution environment market, you know, potentially, you know, clients of T EE S you know, companies that use TES could shift using technologies like RKM. Maybe also describe some of those use cases and you know, efforts that you're making to address that part of the market as well.
Yeah, sure. So I think that's also one of the more interesting aspects to, to, to building RKM that it's not just, yeah, solving problems in a crypto space, but solving, solving problems for the entire world for, for both enterprises, governments, any kind of of organization. I think. And that's also essential to, to the architecture design that we've we've designed.
I mentioned that earlier that you as a developer don't have to deploy a smart contract or build a smart contract in order to run confidential computations. You're essentially just accessing this confidential computing network. And what that means is that on the crypto side of things, there's a lot of use cases, especially in Defy and DPN, there's a lot of teams building, building amazing stuff with,
with our technology. And also I think, and that's I, I think something that is less important to the crypto space actually and more important to the, to the traditional computing space is being able to run confidential AI, more specifically confidential machine learning with RTM, because in the past confidential machine learning really hasn't
been possible. And with this MPC based confidential computing, what's so striking is that completely new types of digital interactions I guess become possible because if all of us have isolated data silos, isolated data sets of highly sensitive data, that it on it's own is valuable, right? All of us care about our privacy. We would never share that data. But this data, if we were able to in some shape or form put it together and train AI models using, using that data, that
could become very valuable. And I think a very striking example for that would be healthcare, right? So very sensitive patient data that now can be utilised in a trustless way. New models can emerge that can help all of us without any one of us ever having to expose their sensitive data. And this really is this collaborative element. And what we've seen is even logistic firms, right? So we're, we're talking with logistic firms that want to improve supply chains regardless
of blockchain. They don't care about blockchain. All they care about is not giving their sensitive supply chain data to, to competitors. But at the same time, they can improve the supply chains. They can all have the sort of win win situation by using distrust less, Yeah, confidential computing technology. So I think that's really the power of decentralized confidential computing to to address traditional markets as well.
And that's also what what drives us, that it's not just building applications for crypto's sake, but building applications for humanity's sake at the end of the day, I think. So when, when considering the, you know, the RKM network, like, I think one of the one of the important things to consider here, and I'd love to get your take on this is the, the
censorship risk. So, you know, for in the case of like an application that would handle the healthcare data of like an entire nation, if we had like a small number of nodes, there would be a risk of censorship. And so therefore you'd probably want to have as many nodes as possible in there. Does are, are there basically so exit mechanisms to prevent censorship? And also does does the network performance, is the performance maintained as the number of nodes scale?
Or do we end up, you know, does that start decreasing as you add more nodes to the network? Yeah, sure. So we have, we have multiple mechanisms to to to combat censorship. I think the the first mechanism that I outlined earlier this so-called on on a technical MPC level, it's called cheater identification.
So to be able to cryptographically identify anyone who, who, who tries to stop a computation from from occurring and we can we can force everyone game theoretically to run the computation. Otherwise they get slashed, they get punished. Now if such a misbehaviour happens and the misbehaving party doesn't care about losing all of their staked assets, there's fall back mechanisms. There's so-called cluster
migration. So to be able to move from one cluster of nodes to a new cluster, there's also cluster forking mechanisms so that nodes that want to censor because maybe there's some, some, some, some kind of computations happening where one node says, OK, I'm not comfortable processing these kinds of computations.
So there's really also this tension of of censorship because we want to force nodes to run any computation at the same time there might be based on on where the the node is being operated also legal implications to not be able to, to process certain computations. And so we have both mechanisms we can allow for nodes to say, OK, in the future, I will not want to process more computations for this corresponding MXE. And they can do that.
They need to pay for the so-called cluster forking them. And there can also be those forceful migrations if a node trust doesn't trying to compute the function that they have to compute. Right. Maybe taking it back to the use cases for like a potential final question where we're talking a lot about Arcum being this
platform. And actually you already also mentioned initially you were building like this confidential confidentiality thing on on elusive, right, Like kind of more application focused almost or I guess in general, the elusive product was more application. Now you're this platform and obviously if you're a platform, you have to do like ecosystem building. You're, you're mentioning you've been speaking to a lot of like logistics firm, like in health, like traditional businesses.
And I think you also like mentioned, like you yourselves met in the hacker house right in, in Solana, which I think quite interesting and probably one of the best ecosystem building examples in all of crypto in the recent years, right? Seeing like it brought also you together and, and just generally how successful Solana has been with that. So yeah, the question basically is like how you approaching this, how are you getting people to build on on the RTM platform? Yeah.
So we currently have way too many people trying to build an RTM. That's that's the current status. So a few months back when we, when we announced RTM, we, we started accepting developer and node operator sign ups for, for the private test net, which we started rolling out. And currently we are in the cohort one phase or the first group of, of developers that get hands on support from us, get access to, to all of the tooling and, and can start building applications.
And step by step we are, we're expanding those, those cohorts and, and adding more teams so folks can join our Discord can, can register to be able to be accepted to those private test net development rounds. And then they Get full access to RQM and can build their applications and get yeah, development support from from our end. That's Congrats on the success there for sure. Yeah, I hope we'll we'll see like a bunch of cool applications. SAP any anything else from your
point or? No, I'm just like always amazed that like these technologies, you know, as great as they are, you know, the, the technologies that we really need, you know, like private compute, more privacy technologies are not the ones in crypto that, you know, get the most attention or get
the most capital. And so I'm, I'm just really glad to see RKM like, you know, raise 5.5 million recently and hear from some pretty big VCs and, and hopefully like take this technology to market 'cause I think it's, it's really important. You know, I also at some point, you know, brought all my family to signal and thought that was a
really big achievement. Yeah. Even though, you know, Signal might be back doored and we have no real way of finding out, you know, but yeah, I think like, this stuff is important and and it's also political. I think we shouldn't, we shouldn't forget that like, encryption is a political issue, more than just a technological issue. And so I'm glad we can talk about here on this podcast. Thanks for coming on, Yanique. Thanks for having me guys. 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/subscribe for a full list of places where you can watch and listen.
And while you're there, be sure to sign up for the newsletter so you get new episodes in your inbox as they're released. If you want to interact with us guest 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.