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.