00:00:00
00:00:01
#30 - Decentralized Confidential Computing and Encryption Paradigms
37 Plays11 days ago
Yannik is the co-founder of Arcium, a decentralised network focusing on confidential computing. Yannik's passion for technology started with building mods for video games.
What is Arcium?
Arcium is a decentralized confidential computing network built to allow secure computations over encrypted data. Unlike traditional cloud computing, Arcium does not rely on centralized servers or trusted hardware. Instead, it utilizes cryptographic techniques, specifically Secure Multi-Party Computation (MPC), to ensure that multiple parties can jointly compute functions over data without any party being able to see the actual data. This breakthrough allows for the development of private and secure applications without sacrificing transparency or decentralization.
One of the core concepts Yannik introduces is the Decentralized Confidential Computing Zone (DCZ), a network where nodes can register, trustlessly form clusters, and offer their compute resources to perform confidential operations. The technology Arcium uses leverages existing blockchains as a consensus layer, enabling confidential computations to be integrated directly into smart contracts.
How does Arcium encryption work?
At a high level, Arcium’s innovation lies in the ability to perform computations over encrypted data, ensuring data privacy throughout the process. The idea that data can be processed without being decrypted sounds almost paradoxical, but it is made possible through technologies like Fully Homomorphic Encryption (FHE) and MPC.
While Fully Homomorphic Encryption allows for computations to be done directly on encrypted data, it is slow and computationally expensive, with a performance penalty of up to 1,000 times compared to plaintext computations. In contrast, Arcium uses MPC, a more efficient alternative that divides computations into a preprocessing phase and an online phase.
MPC allows multiple participants in a computation to hold secret shares of data. These shares are manipulated locally before being combined to produce a final output. This method not only ensures confidentiality but also maintains efficiency, which is crucial for large-scale applications like DeFi and AI training.
Why Arcium Chose MPC Over FHE
Arcium’s decision to use MPC, instead of relying solely on FHE, comes down to performance and trustlessness. The inefficiencies of FHE, particularly when dealing with complex operations like multiplications, make it unsuitable for many real-world applications. FHE suffers from noise accumulation, where repeated computations degrade the accuracy of the data. This problem can be partially solved with bootstrapping, but this process introduces further delays.
In contrast, MPC allows for computations to be split between multiple participants in a way that avoids noise accumulation. By using somewhat homomorphic encryption for simpler operations like addition and relying on precomputed randomness for more complex tasks like multiplication, Arcium can achieve near-plaintext speeds without sacrificing security. This efficiency is key to making confidential computing accessible to a wider range of applications and industries.
A Privacy-First Approach for a Decentralized Future
Yannik believes that privacy will be a critical issue as blockchain technology scales into mainstream applications. He points out that while blockchains offer transparency, they often fail to protect user privacy. Everything recorded on a public ledger is visible to anyone, which may not be acceptable for enterprises or individuals who need confidentiality in their transactions.
This Podcast is fuelled by Crypto trading bot platform Aesir. Sign up and use code AESIRPOT20 at checkout for 20% OFF your subscription.
Transcript
00:00:08
Speaker
Arceum in its current form um utilizes primarily secure multi-party computations as this cryptographic primitive that allows for those operations over encrypted state.
00:00:22
Speaker
um And as the name implies, um those kinds of computations require multiple parties. So what we are building with Arceum is a decentralized confidential computing network. um And inside of this DCZ network, I guess, um that's a term we are trying to to coin, I guess, and decentralized confidential computing. um In this network,
00:00:48
Speaker
um nodes can just register, trust us in any other permissionless network, um and can offer their compute resources, essentially, to perform those confidential operations. And then they find um other peers and form clusters. So this entire network um essentially gets um permutated into clusters and those clusters then can have different sizes, can have different trust assumptions and they then run confidential computations.
00:01:23
Speaker
um And our approach essentially is that we're building a stateless confidential computing network um that uses existing blockchains as consensus layers and allows um for confidential operations to be um sort of executed um from those blockchains. So confidential computations can now be part of smart contracts.
00:01:49
Speaker
um and they get scheduled essentially as computations, asynchronously will be executed in our network and then settled back to the corresponding chain and smart contract.
00:02:01
Speaker
um and That would be this high-level overview of of what we're trying to to achieve with Arqiom. And now this concept of being able to to run confidential computations over encrypted state is sort of, if you if you hear it the first time, difficult to grasp um principle, right?
00:02:26
Speaker
how How can someone perform a computation over data without seeing that data and the output being correct? right um so and There's multiple aspects to this um and also multiple aspects um how the technology that we are building relates to ah what you mentioned FHE for example.
00:02:48
Speaker
um The two main parameters um that we we care about and why we chose um our technological approach really are um performance and ah trustlessness. That's the two things that but matter in this context. context right and so i I personally think that um if One builds um encryption and privacy confidentiality technology and using that technology um comes with an enormous performance latency penalty and there will be no use of that technology and.
00:03:30
Speaker
um applications, ah companies, organizations will just opt to use the most efficient solution. And I think that's um that's problematic um because the technology that we're building at the end of the day um for one allows for for enterprises and organizations to maintain privacy. But more importantly, I think every aspect of of privacy will always boil down to the individual. right And so um enhancing technologies um really um are a way, I guess, um to to not land in a dystopia, to allow freedom and
00:04:14
Speaker
and and individuals' privacy. So I think we need to make it as compelling as possible to use these kinds of technologies. And one factor for this is those technologies need to be very efficient, um close enough inefficiency to plaintext execution.
00:04:33
Speaker
um right And that was the thing, ah sorry to interrupt, that was I think one of the main ah points about FHE is that currently it's about 1000 times slower than plain text computation, which only really makes it feasible on niche protocols, and not at large scale, at least not not for now. um So ah one thing that I want to understand from you is your way of doing this, how much more efficient is it compared to that?
00:05:02
Speaker
But I also meant to ask you, um how did you get into this? like how What your journey been like to to end up in in the field of decentralized encrypted computation? I feel that that that's a pretty cool story there.
00:05:18
Speaker
ah right so um
00:05:23
Speaker
In regards to the first question, um you're right. um Fully homomorphic encryption um comes with this enormous computational overhead. um And in some cases that can be 1,000 times lower down.
00:05:40
Speaker
But depending really on the kinds of operations, um it can even be um many more orders of magnitude slower. So um thats that's a problem that that needs to be addressed. And the technology that we're using is very similar, actually, to FHE on a certain level. right And the the technology we're using, MPC, multi-party computations,
00:06:07
Speaker
um in our case, I guess, with the protocols that we're building um utilizes a so-called pre-processing model. So the computation is being split into two phases, a pre-processing phase and an online phase. um And the pre-processing phase is something that happens independent of the computational inputs and algorithms that should be executed that just needs to be executed in order to generate so-called correlated randomness.
00:06:39
Speaker
so um You will understand in a second what correlated randomness means. It's actually on a high level quite simple to understand. But um what' what's what's important to realize about fully homomorphic encryption and the difficulties with that is that um everything boils down to two core operations. You're you're performing additions and multiplications. And additions um can be performed quite easily, homomorphically, and homomorphically means um to be able to have um some value that is encrypted, that is in some encrypted representation, um and you apply an operation of it and it remains in this encrypted representation, right? So there's this homomorphism. So for additions,
00:07:26
Speaker
That's quite, it's possible to to realize that efficiently. Now for multiplications, um a problem that arises with FHE essentially is so-called noise accumulation. So um repeated executions of multiplications introduce noise to the ciphertext and then a so-called bootstrapping protocol is required.
00:07:50
Speaker
to reduce that noise. And that's really um the center of of where where this inefficiency comes from. um And with those two basic operations, um additions and multiplications, you can build all kinds of computations that you want as as core building blocks. um Now, to shift to the technology that we are using, um we utilize something called somewhat homomorphic encryption, um where we only care about the editions to be performed.
00:08:23
Speaker
in this efficient homomorphic fashion. um And for multiplications, we utilize this so-called correlated randomness that with this pre-processing model um is to be assumed to have been generated in the past by the corresponding parties. And then this correlated randomness, which essentially can be seen as a multiplication that um that has been performed in the past And then you're using um there the factors and and the product of that multiplication um and adjust it to some secret values that you now want to compute over um and correct the final output. right So you do ah some heavy lifting in the past, and now you're able to do it efficiently. um So that's the one of the core principles. um And um how multi-party computations work
00:09:21
Speaker
is multiple players in a computation holding so-called secret chairs, and then them running um local operations, like, for example, additions, and then running multiplications where a bit of communication is required between those players. And then at the end, in order to construct a final output, um combining those um resulting secret chairs back together in order to form some output.
00:09:49
Speaker
so um Yeah, I think that's um that would be a a brief brief summary of MPC and FHE in relation. And what this allows um is for very efficient online phase execution. So that comes very close to the plaintext execution, depending on the the protocol being used so there's different kinds of protocols that can be used um based on the trust assumptions that you're willing to take and based on the trust assumptions one can have against those peers or those peers in the computation can have against each other um and so
00:10:33
Speaker
um There's basically two concepts, honest maturity, if you will, right? So more than half of participants in some computation behaving honestly, and that could be the trust assumption against confidentiality, against the privacy of the data. and But there's also a far better trust assumption, which would be dishonest maturity. So um for example,
00:10:57
Speaker
one honest player. So if you have an arbitrarily large set of players in a computation, um you would require that one of those players is not maliciously um playing together with the others to undermine the protocol. And that's really what we are what we are working with with this trust assumption and then allowing anyone to sort of become an honest player to join and um on their own behave honestly, um especially if they are they're executing a computation they care about, they can just run a node and behave honestly and then have zero trust essentially.
00:11:35
Speaker
Right. So going back to the bottom line of ah the performance for your semi-homomorphic encryption is that it's almost as fast as plain text. And what you're doing is you're using the MPC protocol to split this computation across the different nodes, the different validators that would then compute this, orchestrate the output back together, and then present the output to to the end user.
00:12:01
Speaker
um ah with With that process, I'm guessing, and this is ah is kind of going into governance, right? You've mentioned that you are using a dishonest arms majority.
00:12:17
Speaker
dishonest majority So does that assume that there's only a limited number of trusted nodes or or what is the governance paradigm there? So so so the paradigm would really be um for any given Z of N nodes, there is one honest node. That's the trust assumption you would be running with. And so if you have a traditional blockchain um with practical Byzantine fault tolerance, your trust assumption essentially is more than half of nodes in this network.
00:12:55
Speaker
form a correct consensus, right? Or it's you only, um you trusted 60% or honest or 67%, something like that, right? Those are common common systems. And for us, it's the lowest possible trust assumption you can have in a distributed setting. right One single participant should play um according to protocol um in order for this confidentiality to hold. That's the lowest possible trust assumption, but um it can be brought to even zero, um relatively speaking, because if right um I'm part of a computation,
00:13:36
Speaker
I'm convinced that I'm honest, right? So um for me, there would be zero trust. And then for others, yeah would there could be trust. They would have to trust that in a set, there's one honest a player. But what's so beautiful um about using MPC with blockchains is that we can add transparency to the behavior of nodes. We can reduce trust i um by adding additionally to that accountability to their behavior.
00:14:08
Speaker
That's really what um why why MPC and and blockchains this is such a match made in heaven. So what we've added is also... I'm laughing because I was literally thinking about the same term and it was funny to hear you say match made in heaven. I had that in my head. um That's because it is.
00:14:31
Speaker
yeah and um no what um what What we have added as a paradigm, I think, um is a new censorship resistance mechanism as well. um because so um What you can do with RQM is you can create a so-called MXE, MPC execution environment, um which sort of um can be seen as a trustless cryptography-based confidential execution environment as an alternative to hardware-based trusted execution environments.
00:15:11
Speaker
um And for those who assign computation clusters. um But now um we have this ideal trust assumption, which is great, but at the same time, those scientific papers um circling around those system with those very low trust assumptions have one fatal practical flaw, you could say, that um on um at the same time,
00:15:42
Speaker
they enable one malicious player um to deduce the computation. um Because the default security assumption would be um if someone misbehaves, the computation just fails because they they can identify that. and But they can't identify why it failed specifically or what party caused that. And so um that's a very problematic setup.
00:16:10
Speaker
um when being in the distributed setting. right So if you have some application, it really depends on those confidential operations to be executed. um You can't have um this um yeah this high risk of DDoS attacks for for those executions. right And so um the way we we were able to um prevent those attacks is by adding so-called cheater identification. So um this protocol is now, in our case, able to, if a failure occurs, to identify cryptographically what party caused that. And now
00:16:56
Speaker
By combining and that with a blockchain set system, we can have a collateral and slashing mechanism for this kind of misbehavior. And so and we can have these clusters of nodes with this dishonest majority trust assumption that run computations. And if someone misbehaves, a proof is being generated and they get punished. So with that, we can introduce this sort of notion of guaranteed execution within those clusters.
00:17:25
Speaker
Right. That's very cool. that That must have a lot of use cases there. That's very interesting and probably unique application that I haven't really heard before. That's fantastic. So let me take you back to ah how you actually got to this point ah because obviously you have a wealth of knowledge into cryptography, blockchain um and computing. So I just want to understand a little bit about about you and how you how you got into into this industry and into this role.
00:17:50
Speaker
Yeah, so originally, I guess my my journey begins when um and teaching myself programming at an early age. um through building mods for video games. um And then um after after high school, um for some reason, um against um my parents, friends, and everyone's advice, I guess, um I decided to go and study law. um And um although everyone was suggesting
00:18:26
Speaker
Go study math, computer science, physics. um I just wanted to study law because I felt like I already taught myself programming um and now I wanted to do something new. So um I did that for a few years um and remained loyal to my passion of technology and programming and did a lot of legal tech stuff.
00:18:50
Speaker
um and funnily enough, during a small legal tech conference, got in in contact with Ethereum. So I met a lawyer there that was building quite early um smart contracts um for for banking applications. And this lawyer also had this tech background and was just teaching a bit of smart contract um development and was sending everyone some
00:19:22
Speaker
um some some test net um and tokens in order to play around. And so that was my earliest touching point. And then um sometime later, um COVID hit.
00:19:35
Speaker
And I had some lecture-free um lecture-free spare time um during my law studies um and just had a simple idea for an application that I just developed um um for myself, essentially, because it solved an issue that I at at this time had with um using my iPad Pro as a professional working device.
00:20:01
Speaker
um and I programmed that app, and published it to the App Store, and it became this sort of overnight success. um And that made it quite easy for me to then um after, I guess, six more months of um criminal law um to pivot um towards um studying math and computer science.
00:20:25
Speaker
and yeah tab your during studying math and computer science we had a cryptography course and that's where I um met a few of my co-founders and yeah all of us had this interest in blockchain and then um just all of it started.
00:20:46
Speaker
That's a cool story. um What app did you did you build? What was the name of the app and what did you do? but Shift screen um is the is the name of the app.
00:20:57
Speaker
and And it allowed you to connect your iPad and iPhone add to an external monitor and then be able to use it as a true secondary screen. Because at the time, um all that Apple was supporting was mirroring the screen um one-to-one onto this monitor.
00:21:19
Speaker
not even the aspect ratio would would fit. um And with this app, you could have some freely floating windows on our secondary screen and um that that was a big use case during during COVID. And it really felt great to build this application, um publish it to the App Store and then have people from um all over the world, right? Tens of thousands of people just actively using this the small thing that I just just developed for myself, essentially. um Yeah, and having a better life ah with with that application. So I think that was really um on an important moment. And I think I was,
00:22:17
Speaker
19 years old, I think I was when I when i was doing that. so that was I think it was a very important moment, which then allowed me to realize, okay, that's what I want to do. I want to build technology that um solves issues. um yeah Right. That's super cool. Did you do any marketing for it or did you just look put it up on the App Store and people just found the app?
00:22:45
Speaker
um so i was
00:22:49
Speaker
um cold emailing and DMing um um productivity and app influencers and some medium sized ones with a couple of tens of thousands of followers um started just doing videos on it without wanting a single penny from me. um And that just got the ball rolling and um
00:23:20
Speaker
Yeah, i wasn't I wasn't required to spend a single cent on marketing. Funnily enough, it was just people doing ah videos about the app organically. That's very cool. That was crazy. What was the app free to use? One-time purchase, $10.
00:23:41
Speaker
That's super cool, man. Congratulations. that that's That's awesome. That's an awesome ah awesome backstory there. um So then after that, you you've moved into Arkim. You've you've ah thought about Arkim. I'm guessing along with the co-founders, architected the idea. And you've also recently secured an investment from some ah some big crypto investors. Congratulations, by the way. That's fantastic. oh Thank you so much.
00:24:06
Speaker
um so it For Arceum itself, it's also um really a story of of of development. So we originally started um known as elusive. um And what we originally sought out to do was to solve this issue of on-chain um ah transactional privacy, because by default, everything happens transparently on the ledger. And um that limits really the the ability for for blockchains to scale into retail um and to to scale to large applications that can replace um the current Web2 technologies we are using. Because we are really used to a relatively high level of privacy in our everyday lives, right? Although it might not be perfect privacy.
00:24:59
Speaker
um just having Google, um just just giving Google access to our data, right, is different from giving the entire world access to our data because now it's um on our public ledger. And so what we were using ah back in the day was zero-knowledge proofs, of course, um as this um perfect primitive for for these kinds of applications.
00:25:26
Speaker
And at the same time, um we developed a very, very innovative, I really think, ah protocol to solve an issue that arises with zero-knowledge-proof based content privacy compliance. yeah and um right yeah and And so our our direction was, okay, um we want to support privacy um and don't want any centralization, um but still we require ah compliance. And I think um that's also a different take that um that but some other players have had, um especially looking at um at at failures in regards to compliance. um But I think um there is some reason in in our societies
00:26:21
Speaker
why we um wouldn't want bad actors to, for example, have this um completely um anonymous ability to to move assets however they like. So um the solution for this problem for us was using confidential computing with MPC and um essentially what we're building right now and um using those confidential computations to privately and securely screen transactions, encrypted transactions. And then if they found some actor, let's say one week after a transaction has occurred um to be a bad actor, this network could screen the transactions and identify those performed by this bad actor.
00:27:15
Speaker
not revealing any information about. all normal users, but revealing the activities of the bad actor. And with the setup of being able to screen those computations after they have occurred, um it was also possible to introduce a decentralized um consensus mechanism right with high consensus bounds in order to have a correct decision-making process. And so it was very innovative on that front, this protocol,
00:27:48
Speaker
But um when when developing it, we realized and especially building this Cheetah identification system and doing all of this research and engineering work that just limiting this ability to run computations over sensitive encrypted data and most importantly also be able to disclose information about it. right So it's not just encrypted data to encrypted data but in this case it was revealed that um an illicit actor has done something
00:28:25
Speaker
ah So selective disclosure um is so incredibly powerful and has been limited to the single um use case, um which I would argue, comparatively speaking, to what's now possible is quite boring because I mean, compliance is not the most, most interesting subject. So debts that's really the story of Arceum.
00:28:52
Speaker
evolving step by step now into this dedicated network fully focused on building this um highly efficient yet trustless confidential computing technology.
00:29:06
Speaker
Right. That's very cool. And I love the fact that you you can determine who ah ah what a bad actor might be after the transaction has taken place. How do you manage that? and And what do you actually look for? Are you looking for, are you scanning for like wallet activity? And are you trying to associate the wallet with transactions on the chain? Like how does that work? So again, um we're not doing that anymore. That's something that we were planning on doing in the past and building the tech and then we said, okay, let's fully focus on just building confidential computing um with this MPC protocols as technology. um So essentially, um many things would have been possible. The most simple um solution would just be and check if
00:29:58
Speaker
the address um The encrypted address of of some actor that's encrypted in a transaction would be part of um a blacklist, essentially. um That would be the most um simple approach. yeah And then reverse through the graph.
00:30:16
Speaker
Yeah, that that makes sense. A blacklist would would would most likely make sense. yeah i was I was asking because I know there are a few ah there are a few similar systems like that deployed on on other chains. um And I know that they have a certain degree of a failure rate. right that they can They are prone to ah false positives. For instance, if you if if a bad actor was to send you ETH that they've they've taken through ah through a money laundering, like a mixer or something.
00:30:46
Speaker
then your wallet, even though you've done nothing wrong, purely ah you know having that ETH could flag your account as being fraudulent or illicit. Yeah. um and And that's really why um why I think this approach um just makes so much sense because um there can be a more sensible decision making process.
00:31:14
Speaker
because anyone would have been caught in the system, right? Because it happens after the ex post you're able to decrypt. So yeah, that was really the idea. And then just... really just everyday working with this novel concept of encrypted state and running computations over encrypted state and being able to still reveal information or some information about this data to the outside world. Yeah, really just made us realize that
00:31:58
Speaker
um We need to make this a system that can be used both um on the blockchain itself natively for right confidential on-chain use cases, but also um for traditional enterprises to use because combining this um this technology with distributed systems and blockchains makes it so much more powerful. um Those those those um paradigms and we we talked about earlier, right those new paradigms that arise from this combination of both technologies. so That was really um an important realization for us um and made us so passionate about
00:32:48
Speaker
building this um to to large scale. And hence, we are also very happy to have um such great investors on board also believing in this vision um because um it really allows us to use the best aspects of blockchain technology um and build far better systems that wouldn't be possible without utilizing blockchains.
00:33:15
Speaker
Right. Yeah. 100%. There's so much to gain by leveraging that that technology. um Okay. So obviously this is still for you guys, work in progress. um You haven't deployed to the mainnet yet. That's still on your roadmap. um But before we before we get into that, ah tell me a little bit about the specs.
00:33:34
Speaker
Right. It's a dedicated network. um Have you done any testing of the throughput of TPS? And do you have any plans to connect to other chains? And if so, via what protocols are you planning to achieve that? um So right now, we are we're starting to roll out the the first round of of Private Testnet.
00:33:56
Speaker
um I can't give you a precise um transactions per second or in our case CPS computations um per second number. um what um um What's important um is that our network really is chain-agnostic to a certain degree. so um right For the sort of start, we are we're looking at deploying on Solana, um but um there's no reason why Artyom shouldn't be available on all kinds of networks. right
00:34:36
Speaker
And um that's really the power of having this um stateless confidential computing network. So we can access different blockchains um and we can use on-chain computation scheduling on those dedicated networks um in order to be able to facilitate that. And there's no Central state the entire um network would rely on to to be written to that's very powerful because if their state that needs to be updated the state lies on the dedicated blockchain network and there's no
00:35:14
Speaker
Overall, slowdown, no performance um ah penalty coming coming from that, right? if were if we if If we were to support, if we were a mainnet, that wouldn't slow down any of the operations occurring on um Solana mainnet. So I think that's that's important. um And so step by step, we are going to be expanding to different um ecosystems as well, um um but in a sensible way, I guess.
00:35:45
Speaker
um And um one um what's important about the specs, I guess, really is that um we we under the hood allow for the usage of different kinds of backends. So um if we have, for example, confidential on-chain applications for um for DeFi, um that will most likely, um or should,
00:36:17
Speaker
um use a different back-end in Arceum than if you're training an AI model. um and not describe that right Just to clarify, what do you mean by back-end in this context? um So MPC protocol. ok so different Okay. different encryption protocols.
00:36:42
Speaker
um not not Not necessarily encryption per se, but um for example, numbers number support. So if you're talking about um traditionally and um and talking about those traditional-chain operations, you will most likely not have this need for processing a lot of floating point um operations, but that's very necessary if what you're trying to achieve is to and trustlessly train a confidential um machine learning model. And so and there's different specializations and depending on on the need for the application that a developer is um developing and deploying, a different backend is selected and it's possible to switch between those.
00:37:37
Speaker
Right. Got you. Okay. that's That's very cool. And that's useful too, because it keeps it keeps like overheads, performance overheads at ah at a minimum there. um So what are your plans then regarding the developers and and the um businesses that are planning to use Archim? How would one go about building something on Archim? Do you support smart contracts? Do you support an API? Or like what is this interaction between the infrastructure layer and the and the that developer?
00:38:06
Speaker
Yeah, so um what's important to realize about the network itself is that the network really is a purely come a computational network. So what that means for for the developer would be that you can't deploy a smart contract directly with an Arcium. What you can do is you can tell the Arcium network run this confidential computation for me, and it will very efficiently do so. um And we'll be happy to do so, right? And so how can you build a confidential smart contract now? and Well, it's different layers on the technology stack. um And so on the most atomic layer, the network um is, I don't know, I think you could you could call it a sort of um
00:39:00
Speaker
distributed ah confidential operating system that those nodes are running. um And that supports a specific set of of of atomic instructions, um which, again, depending on the backend,
00:39:15
Speaker
if you have those floating point operations. can be um um i mean You could run a logistical regression or you could um do some um large matrix operations um directly, natively, like you would be communicating with a dedicated... Right.
00:39:35
Speaker
ah GPU that and that that has those instructions, but now it's sort of confidential. um And so you have those atomic operations. And a developer could write a program, um circuit sort of, um that um directly um addresses those individual um gates, those individual instructions, like you could write assembly code on your on your machine, so the most low-level code.
00:40:04
Speaker
The developer could, um in theory, add additional optimizations, um but um that's not something that we want the average developer to to be required to do. and so um we We support our DSL language, so our domain-specific language.
00:40:23
Speaker
um On top of that, um that's this higher level language um that's very familiar to use. And so the developer can just access um all functions through through that.
00:40:36
Speaker
Again, building confidential computations. And now one layer above that, um the developer is able to write confidential smart contracts. Because now this functionality gets integrated into a confidential smart contract SDK, which you can use within your smart contract. So for a developer, it's just about adding confidential functions to a smart contract, to an existing smart contract even.
00:41:03
Speaker
um and the The core system that we're working with, and I mentioned it briefly earlier, and is this MXE-MPC execution environment.
00:41:15
Speaker
um and Within that environment, um the developer can create persistent encrypted data objects and different functions like like smart contract instructions um that then get boiled down to those layers below.
00:41:36
Speaker
executed by the network and set it back. And that's how the developer can access Arceum. You can build an off-chain confidential application with Arceum. Right. I was just thinking you could you could just called call the functions from wherever you want, really. You could even deploy your own blockchain on Cosmos or on Polkadot or whatever. So long as you have access to that low level information, you could just use the functions. that That's cool. and And you could also... so So the plan is then to allow um to allow building these um encrypted or private smart contracts, if you will, on Solana. Is is that what you mean when you say it's going to be deployed on Solana? You're meaning that there's going to be a library there except that people can use? Right. That's very cool.
00:42:26
Speaker
yep it's probably just going to be like one function, right? Like compute this. and yeah some output Yeah. So I think the the the beauty um of of this system really also arises from um not being forced to have everything um be confidential, right? Whatever has to be confidential now can be confidential and what should be public can remain public. And so um With this setup, we make it very easy to switch between those two contexts, um if you will.
00:43:02
Speaker
um yeah so i think um That's really what what matters to developers, to be able to on their own define, this should be public, but this should be private while at the same time, not um um forced them to be cryptographers, not forced them to be right experts in the field, right? Because in the past it was really, okay, I want privacy in my application, then I'm just gonna, um now become a serial knowledge proof developer, I guess. um and so yeah
00:43:36
Speaker
um with With what we're trying to achieve, it's really um with those MXEs, those autonomous executing machines that have this um censorship resistance that smart contracts can just call, that off-chain applications can just call um and make it as accessible as possible. um yeah Because that at the end of the day really is the deciding factor between users um and and enterprises and whatever using confidentiality um or not at all.
00:44:12
Speaker
Yeah, ah there's definitely tons of use cases there. um So you've mentioned that you're in the process of launching the ah private um like a private launch for the testnet. Are people able to opt into that or how how would one go about ah engaging with with the testnet at this stage? Could people could anyone write um start running a node if they wish?
00:44:36
Speaker
um Yes. We have different cohorts, if you will, um that we are we are using for them for the testnet. I don't know how many cohorts in Total will have, but um um the demand for those slots to be able to help us um battle test the infrastructure and have access to the development tooling. um
00:45:10
Speaker
is insane, honestly. And and um yeah, that um that makes it very difficult. um But we are we are super excited about that. um And so we've just started with our first group of roughly um a few hundred people. And um many orders of magnitude above that ah wanted to get a chance to join in this this round. But they'll have a chance to join in our future round.
00:45:39
Speaker
um it It's been amazing to see the growth of of um of of that technology. um I think within from the the last in the last few months, our our community on and Discord alone has um has grown from, I don't know, 5,000 members to now close to 50,000, I think. So it's ah wow in and insane numbers and a lot of people wanting to get in and
00:46:09
Speaker
build completely different kinds of um of applications, various use cases. So um I get messaged a lot about ideas people have that they want to want to realize because now they understand with the tech that we are building, it's now possible to um build these kinds of applications in a feasible way um on on the blockchain. So there's teams building on working on dfa DeFi applications, there's deep in teams, there's AI teams, there's machine learning teams, um there's healthcare teams. So um it's really all use cases. um And we're trying our best to onboard as many people as possible, but we'll do so in a sensible way in order to allow
00:47:02
Speaker
um ah I guess good development progress to take place. Yeah, and that makes sense. and that's That's really good for the adoption though. Congratulations. What was I going to ask? um I was going to ask about the um right the the hardware required to run this. um Do you need any specific hardware or can you just um download it and run it on your machine in most cases?
00:47:28
Speaker
so um That's an excellent question. By default, we don't um force any any hardware requirements. um At the end of the day, how this network works is that the user um um could fully um or um um yeah could could essentially fully control who's part of a cluster for their virtual environment. and so on
00:48:00
Speaker
um they will pick um nodes that they trust and they will pick nodes that can facilitate their computations. um But at the same time, um you can use Arceum to also run permissioned clusters. I think that's important, right? So you can create a node and offer it for anyone to use. um And we have this, again, with the collateral staking and slashing mechanism, there's also This design we currently have in our public docs with um um delegation mechanism, which allows for more fair distribution um and more decentralization and allowing smaller operators to to um increase their hardware capabilities. um But um it's it's possible to um offer your computing power, um if you will, for
00:48:59
Speaker
the public use with permissionless clusters, but the two of us could use our laptops and create a permissioned cluster and just run a computation um collaboratively.
00:49:13
Speaker
that some That's um the secondary aspect, I guess. So it's really about um allowing for Autonomous execution environments, those MXEs in our network, um where it's really just a replacement for um traditional um centralized cloud server, I guess, right VPS. um So it's really just confidential operations with no middlemen and no trust involved at the same time. Multi-party computations.
00:49:47
Speaker
um natively have the support for collaboration, right? So and there's this native support of multiple parties computing a function um over sensitive data, being able to gain new insights from that data without having to share a single bit of information with each other. um And that's enormously powerful um because it allows for, I think,
00:50:18
Speaker
best example would be in the medical space um allows for completely new intelligence right you can now um as a as a patient you can now um provide your data for a machine learning model training without having to risk your data while at the same time getting those benefits from everyone doing this um and running this computation and then getting good models that allow for prediction of diseases um which otherwise wouldn't be possible because
00:50:57
Speaker
who would you and trust your sensitive data with, right? So I think this enables by doing more data protection um to get even more valuable insights in many domains.
00:51:13
Speaker
Right. Yeah. Yeah, for sure. um So as you said, you can run it on virtually any machine, um but are the algorithms that are performing the computations over the encrypted data, are they better suited to run on a GPU or a CPU natively?
00:51:33
Speaker
um so The primary limiting factor um really is network bandwidth. That's the limiting factor for um four throughput um for for computations because, as I said, um for the computations, they are still communication required at some point during a conversation. So we think of um of network bandwidth to really be um this this limiting factor for throughput. um At the same time, ah we make use of hardware
00:52:10
Speaker
um hardware um acceleration um to a certain um ah ah degree with with um if you run your um your node with a GPU, it it will definitely be be more efficient. um But it really depends on the use case that this specific node also is targeting again. So if you're speaking about um AI use cases again, and that's why it's also so beautiful that this network has this notion of different back ends because
00:52:42
Speaker
um You might not have a speckled graphics card, but that's not a problem because there's multiple backends um that that you can be running. So um I think it's really um what we are trying to do is to allow for as many um different parties to run nodes as possible because that ah fosters distribution and decentralization. And since computations ah occur in subsets, um it's not a problem because individual slower players won't slow down the entire ah network.
00:53:21
Speaker
And then ah players can special specialize. so So node operators really can specialize on on different kinds of of applications to be facilitated. Right. That's very cool. So when's the mainnet launch? When's it happening? Yeah. um Great question.
00:53:42
Speaker
um Unfortunately, I don't have a great answer to that. um Yeah. um
00:53:50
Speaker
um I should ask my developers that. is So the team is very, ah very hard at work. um we We have an amazing team um full of um hardworking engineers and um and researchers.
00:54:08
Speaker
um So every day we're we're moving closer, um but we'll still be a few working days until then, I guess.
00:54:19
Speaker
Fair enough. Yeah, no, that's understandable. So you've got you've got the private test nets now, which you're you said you're you're just onboarding people in batches, and then the next step is the public test net, right? Yes. And I guess a certain period of testing and measuring and then the mainnet launch. Yeah, exactly. How about the node rewards? ah ah How do people get rewarded? do they get ah like what was the Was the reward mechanism there? I'm guessing that's an important incentive for some. Yeah, that's that's that's important. and um For us, it's really important to essentially just facilitate this peer-to-peer infrastructure. so That means um you as a developer,
00:55:09
Speaker
assigning a cluster this role of processing your confidential computations, creating this virtual environment, means that your per computation pay those nodes. And they equally get rewarded for that. And so there's no Player in between that's the basic basic mechanism and of course then and based on network supply and demand there's a priority fee mechanism but on the most atomic level it would really be um um paper computation.
00:55:45
Speaker
Okay. So that's basically your bandwidth dictates the your rewards effectively if the bandwidth is your bottleneck. Exactly. Exactly. So it's really you um you as the as the node operator.
00:56:00
Speaker
um um Yeah. Setting the the upper bound by by by your hardware um and then Of course, the the mechanism is a bit more complex, but it circles around um you unlocking your hardware um um we've with increased collateral then, um um because there's an increased dependence on you not failing, right? um If you're a part in of more clusters. um and And so that ties into that as well.
00:56:36
Speaker
That's cool. That's cool. um Well, listen, I think you guys are building some amazing tech and I would love to see it in action. I'm going to keep um following along with the project's progress.
00:56:50
Speaker
and Do give me a shout once it goes live because i would love to see some of the use cases or or you know see how it how it works on the main net. um but Is there anything that you want to announce at this stage maybe anything you want to let people know um if there's devs that should be going to check out the website or the twitter or anything like that.
00:57:10
Speaker
um Yeah, so um as I said, we started onboarding the small first very small batch um into into the private testnet. And so if you're interested to um to start working um on on building applications with Archium, now is really the phase to start joining our our developer community because um They're still, um um with this private testnet, this process of going back and forth with with developers and adapting the protocol, adding features, um adding more features to the different backends, really depending on the use cases. So we really have this open community. Feel free to join us.
00:57:58
Speaker
um we have um A lot of community calls as well, where you can ask questions. um So feel free tool um yeah trying to the Archium family.
00:58:10
Speaker
Awesome. Wilson, I think it's been great and um I will follow along with your guys' progress. um Thank you, Janik, for coming to to the pod and you're welcome anytime. I would love to have you again ah post-launch just to kind of discuss the use cases and your journey to mainnet. Thank you so much, Andre. um It was a pleasure. Take care now. Bye, everyone. All right. Take care. Bye.