0:00

A quick note before we

0:02

begin today, due to

0:04

some equipment failure, the

0:07

first 15 minutes of

0:09

this episode sound worse

0:11

than you would normally

0:14

expect from our show.

0:16

We think the episode's great

0:18

and still worth bringing to

0:21

you and it gets better

0:23

later, but as you'll hear,

0:26

it's not your headphones,

0:28

it's us. Yeah, so we last talked

0:30

probably over a year ago at

0:32

this point, which is pretty heavily

0:34

focused on what you guys were

0:37

building. We'll get into that a

0:39

little bit later, but the main

0:41

reason I wanted to have you on

0:43

is it feels like we're sort of

0:45

at a turning point with zero

0:47

knowledge systems. There was a huge

0:49

amount of hype from 2018 kind of

0:52

through 2022. It feels like we got

0:54

a little quieter in the last few

0:56

years, but a lot of stuff's actually

0:59

launched and usable. And on Solana, Zero

1:01

Knowledge has actually had a little bit

1:03

of a resurgence. It's actually become a

1:05

chain that has a ton of different

1:08

ZK primitives, a lot of different companies

1:10

building with zero knowledge technology, whereas from

1:12

state compression to privacy layers, to confidential

1:14

computing, all sorts of other types of

1:17

other types of applications. But at the same

1:19

time, a lot of the big name zero

1:21

knowledge players that big on the technology,

1:23

that big on L2 is that we're

1:25

going to be using it, have really

1:28

struggled to sort of find differentiation and

1:30

a reason for people to sort of

1:32

care about what the technology is built

1:34

on how it actually works. So it's

1:36

a whole bunch of stuff I want

1:39

to talk through today, but sort of just

1:41

start off, like, give us a run through

1:43

of like, at the end of the day, like...

1:45

How does zero knowledge technology

1:48

actually work in private tests?

1:50

Yeah, sure. So there's essentially,

1:52

you can think of zero knowledge

1:54

technology as this big term with

1:57

different kinds of technologies. and there's

1:59

zero knowledge proofs, which is the

2:01

one big traditional way you're mostly

2:03

referring to for zero knowledge technology,

2:05

but there's also a secure multi-party

2:08

computation and fully homomorphic encryption. Those

2:10

three basically form what we think

2:12

of as zero knowledge technology. Now

2:14

the security and different properties that

2:17

zero knowledge technology enables come from

2:19

cryptography. at the end of the

2:21

day, right? So there's a lot

2:23

of math, a lot of cool

2:25

math, I have to say, and

2:28

cryptography involved, but the history of

2:30

CK really is that in the

2:32

80s, the first kind of zero

2:34

knowledge proofs have been designed, and

2:36

back in the day those were

2:39

interactive proving protocols. So a zero

2:41

knowledge proof usually involves two parties.

2:43

Me and an example, the prober

2:45

and you, Austin, the verifier, and

2:47

Professor knowledge proof, I'm able to

2:50

convince you of the truth of

2:52

some statement. without having to share

2:54

the statement itself, simply just communicating

2:56

the validity and the truth of

2:59

some expression. And back in the

3:01

day in the 80s, those were

3:03

interactive protocols, so we had to

3:05

perform some complex computation with each

3:07

other to generate a proof. Over

3:10

time, those have evolved into non-interactive

3:12

proving skills. So, 100% makes sense.

3:14

Sort of the hand or butt,

3:16

right? We sort of have systems

3:18

that do some version of this

3:21

today, right? I can give you

3:23

a installer from a closed source

3:25

software provider and it includes a

3:27

certificate that I can verify that

3:29

no one's monkeyed with the code

3:32

without actually looking at the code

3:34

myself because I see this sort

3:36

of certificate that's said, yes, the

3:38

check sum matches or you can

3:41

publish a check some somewhere and

3:43

and I don't actually have to

3:45

see the source code to verify.

3:47

that something is what it says

3:49

it is we have wallets that

3:52

have public private key encryption where

3:54

i can verify that you have

3:56

signed a transaction without having your

3:58

private key so how is this

4:00

similar work different from a lot

4:03

of these encryption methods were familiar

4:05

with today that are used to

4:07

provide some amount of verifiability. Yes,

4:09

so I think, especially in the

4:11

context of what you were referring

4:14

to with some science certificate

4:16

for some software provided by

4:19

a vendor, that is really

4:21

a case of some trusted interaction

4:23

because at the end of the

4:26

day, your source code is supplied

4:28

by some entity. right? And so you

4:30

have this remaining trust of okay I

4:32

trust this entity and I know that

4:34

they've sent it to me so it's

4:36

sort of like an encrypted channel if

4:38

you will right because they've signed this

4:40

the software you can trust to install

4:42

it software because you have a contract

4:44

with their company right and initially were

4:46

to exploit you then you could sue

4:48

them in court. So I think what's

4:50

key and that's something that we're trying

4:52

to achieve with block trains in general

4:54

with Solana with what beer building but

4:57

any kind of distributed trust

4:59

the systems is removing single points

5:01

of failure, removing trusted entities. So

5:03

verifiable compute is an important aspect

5:05

for that. And that's one of

5:07

the properties that zero knowledge proofs

5:09

and other cryptography schemes can provide.

5:12

So the term zero knowledge proof

5:14

can be a bit misleading because

5:16

a lot of usage of zero

5:18

knowledge proof actually circles around scalability

5:20

and verifiable compute mostly. But there's

5:22

different kinds of properties for a

5:24

zero knowledge proof. One is the

5:27

sukendness of the expression. So that

5:29

basically expresses that there is

5:31

some asymmetry. There's someone generating

5:33

the zero knowledge proof, the

5:35

prover and someone verifying it.

5:37

And there's a computational and

5:40

informational asymmetry between those two

5:42

players. So you can express

5:44

a very complex computation in

5:46

a zero-notish proof, which in

5:48

the case of CK-snarks, as

5:50

this constant, always the same

5:53

complexity. of evaluating and verifying

5:55

the serial solution. And that's

5:57

where scalability comes to play. That's where

5:59

CK came. used as a scaling solution

6:01

because at the end of the

6:04

day can outsource computation to some

6:06

third party and simply verified. Yeah,

6:08

so I don't want to get

6:10

too familiar with the math because

6:12

you're going to blow past me

6:14

pretty quickly. But the concept of

6:17

I am trying to verify something

6:19

without knowing its contents, right? In

6:21

the traditional world, the only way

6:23

that's done is the third party

6:25

vouchers for it. So KYC is

6:28

a great example, right. My accountant.

6:30

vouches that I am an accredited

6:32

investor, I don't have to actually

6:34

show you my bank statements, you

6:36

trust him because of his accreditation.

6:38

How are you able to, like

6:41

at a high level, prove the

6:43

contents of something without revealing what

6:45

that is? So I think there's

6:47

something that can blow your mind

6:49

even more, right? So still knowledge

6:51

rules, just generating this proof and

6:54

submitting it to a third party.

6:56

I would have to sort of

6:58

go into the weeds of it,

7:00

but I think as a concept

7:02

it's easier to understand. So I

7:05

have some secret that I can

7:07

do some mathematical permutations, right? And

7:09

submit a proof of the operations

7:11

that I have performed, right? So

7:13

you know the algorithm that I've

7:15

executed. I know the algorithm that

7:18

I've executed. So we both have

7:20

to share knowledge of the function

7:22

that should be executed, the kind

7:24

of permutation, right? The more... Yeah,

7:26

disturbing concept if we will is

7:29

what we are actually doing. And

7:31

that involves not just me having

7:33

secrets and running something, but instead

7:35

allowing a network of nodes to

7:37

run something over secrets. The network

7:39

doesn't know those secrets. And they

7:42

can generate verifiable output, right? Which

7:44

is even more crazy concept if

7:46

you think about it, right? So

7:48

I think at the end of

7:50

the day, this technology... enables use

7:53

cases that we haven't seen before.

7:55

All of those three protocols enable

7:57

new use cases in a distributed

7:59

set. that make those

8:01

systems way more resilient and

8:03

performant at the same time. Yeah,

8:06

so I want to talk about

8:08

some of the dynamics you

8:10

mentioned around compute face symmetry. So

8:12

most encryption methods we use

8:14

nowadays, most security methods that we

8:16

use nowadays are effectively free

8:18

to verify. Right, signature

8:20

verifications on a Solana

8:23

transaction is basically a short

8:25

of a time as you can get it to be,

8:27

you know, me validating a certificate is valid

8:29

for a website or any other type of

8:31

encryption. It's not a

8:33

computationally intensive task like encrypt my

8:35

messages. So what is it about zero

8:37

knowledge systems that, you know, if

8:39

you talk to folks about zero knowledge

8:42

systems, it feels a little bit

8:44

like nuclear fusion. Like, oh, it's always

8:46

just a few years away from

8:48

mass applicability. So what is it actually

8:50

that requires what not from a math

8:52

side, but what components of the

8:55

system require compute? And why has that

8:57

been such a barrier historically? So

8:59

one of the key problems

9:02

really is that you're

9:04

operating on a completely different

9:06

computer. If you run your

9:08

normal signature verification, those

9:10

algorithms usually are optimized for

9:12

some binary operations that

9:14

your computer can perform. Right.

9:16

And those things are

9:18

realized. There's hardware acceleration. Exactly.

9:20

Yeah. And then you're

9:22

basically operating over numbers and

9:25

bits with zero knowledge proofs

9:27

and all of that cryptography,

9:29

where you want to represent

9:31

some computation that a normal computer can

9:33

operate in a cryptographic way. You

9:35

need to transmute that into

9:37

a different representation and that

9:40

representation involves so -called elliptic curves,

9:42

different functions and finite fields.

9:44

And that makes things much

9:46

more complex because computations now

9:48

are being represented as so

9:51

-called circuits, arithmetic circuits, for

9:53

example, of which you can

9:55

think similarly to fuses in an

9:57

actual chip, right? Yeah. Actual

9:59

circuits. signals. And it's not those

10:01

signals you know from a computer,

10:04

but instead it's finite field signals,

10:06

if you will, that run in

10:08

those fuses. So there's complexities involved

10:10

in representing operations that on a

10:12

normal hardware are efficient in this

10:14

virtual circuit format. So that's really

10:17

one of those problems, where there's

10:19

significant overhead associated. And there's hardware

10:21

acceleration for those things as well,

10:23

but it takes time like that.

10:25

Yeah, I guess that was sort

10:28

of, the scale problem feels like

10:30

it's, it should be more solvable

10:32

than it seems to be. Like,

10:34

between FPGAs and between like the

10:36

way, like, you look at something

10:39

like ACIC acceleration and Bitcoin, and

10:41

that sort of revolutionized what was

10:43

possible in terms of hat-tray there.

10:45

It's not like the Bitcoin folks

10:47

had crazy super corporations organizing venture

10:49

rounds to build ACICS and some

10:52

that did eventually. But with the

10:54

amount of money that's gone into

10:56

ZK research over the years and

10:58

the amount of money that's gone

11:00

into funding, ZK crypto companies, like,

11:03

why is it today that we

11:05

either don't have hardware that's capable

11:07

of doing these things? Like, how

11:09

much of the breakdown is like

11:11

research versus like no one's actually

11:14

just built it yet? That's the

11:16

exact question. I think it goes

11:18

into the direction of why we

11:20

at RQ initially, we're working with

11:22

zero knowledge group. back in the

11:24

day we were called elusive and

11:27

we were doing on-chain privacy with

11:29

zero knowledge proofs but eventually we

11:31

pivoted and I would rather call

11:33

it evolved into using secure multi-party

11:35

computation instead because for us it

11:38

was some limitation that could not

11:40

be overcome yes associated with CK

11:42

and what what we've noticed I

11:44

think is that there's quite a

11:46

lot of teams that also came

11:49

across those limitations and especially on

11:51

the confidentiality and an encryption front

11:53

does just this big limitation of

11:55

you just being able to provide

11:57

privacy for one party that interacts.

12:00

in this approval verifier system, but you're

12:02

not able to build smart contract

12:04

systems, you're not able to aggregate

12:06

data. And so that's one of

12:09

those big limitations that we came

12:11

across. And that's why we decided

12:13

to go down a different cryptographic

12:16

road. Yeah. So talk to me a little bit

12:18

about how that new system works and

12:20

how it differs from some of the

12:23

other zero knowledge technologies we've been

12:25

talking about. So MPZ, as similarly

12:27

to CKK, has actually... they have

12:29

evolved in a parallel fashion basically

12:31

also starting in the 80s. I

12:33

think the fascinating thing about MPC

12:35

really is that it allows a

12:38

set of participants to jointly compute

12:40

a function without having to share

12:42

the individual inputs. And MPC in

12:44

our space mostly gets associated with

12:46

some designer wallet management, right? Right,

12:49

right. I'm breaking my wallet into

12:51

a few pieces and then multiple

12:53

compute puts it together to sign

12:56

a transaction. But MPC really. at

12:58

its core allows a set of

13:00

nodes to jointly run a predefined

13:02

function an algorithm and have individual

13:05

inputs and keep those inputs private

13:08

by producing a shared output.

13:10

And what we're essentially making use

13:12

of also with the research that

13:14

we're doing is with new trust

13:17

models that yeah, have become possible

13:19

with those kind of systems. Because

13:21

initially it was really only honest

13:23

majority which I guess you're familiar

13:26

with, right, but for the folks

13:28

listening. Most Byzantine fault tolerance, practical

13:30

business tolerance systems have this honest

13:33

majority as trust assumption, right? So

13:35

you have some qualified majority that

13:37

has to behave honestly, has to

13:40

behave according to the protocol. And

13:42

yeah, you've seen a breakthrough in

13:44

those kinds of protocols that are

13:46

now allows for dishonest majority,

13:48

which basically inverts it. Only

13:50

one single honest participant required

13:52

to guarantee different properties for

13:54

those computations. So I think

13:56

it's worth diving a little

13:58

bit more into. how that works

14:00

because the blockchain is always and

14:03

most of these systems have always

14:05

had like an objective truth problem

14:07

right where it's like unless you're

14:09

like fairly Catholic like objective truth

14:12

is pretty unknowable right in the

14:14

sense of like you need an

14:16

external reference point to base something

14:18

as being true which is where

14:20

the honest majority assumption comes from

14:22

that you can only like it's the

14:24

whole thing about like you know

14:27

Ethereum classic is actually the real

14:29

Ethereum. Right, and like the thing

14:31

we all call Ethereum is actually

14:33

a fork, right, of Ethereum, but

14:35

we all have socially decided that

14:37

this is the main one, the

14:39

other one's classic. But like, from

14:41

the computer's perspective, there's no way to

14:43

know which one is quote unquote real

14:45

Ethereum. Yeah, I think that's actually

14:47

an excellent question and most people

14:50

don't don't ask me that question.

14:52

So it's, I think even, even

14:54

the smart question to ask, right,

14:57

because how could... dishonest majority function,

14:59

right, as a concept, because how

15:01

could... Right. Just this one person

15:03

be correct, right, if there's

15:05

only one honest participant. So

15:08

that's also where the connection

15:10

between Arquium and Solana comes

15:12

to play action, because what

15:14

we're saying essentially is Arquium

15:16

is a purely computational network

15:18

that supplies computing capabilities

15:21

that Solana itself cannot

15:23

facilitate. confidential computing,

15:25

generalized confidential computing basically. And

15:27

so we make use of

15:30

this connection with Solana. So

15:32

we have a program on

15:34

Solana that functions basically as

15:37

entry point as mempool for

15:39

computations happening within algorithm.

15:41

And so Solana sort of

15:43

becomes this true player, if we will,

15:46

where there's just the consensus

15:48

over what computation should be

15:50

performed. And so if... Arquium

15:52

with an Arquium, a computational

15:54

cluster, doesn't run a computation

15:56

as it's tasked to do

15:59

on Solana. the corresponding party within

16:01

the cluster, it could be all

16:03

of those nodes or just one

16:05

or zero nodes, right? If anything

16:07

goes wrong, anything doesn't go according

16:09

to protocol, they get punished for

16:11

that. So that's really where

16:13

this connection comes into play

16:15

and where actually blockchain

16:17

forms a system that can

16:19

overcome limitations from very

16:21

theoretical papers. Because now with

16:23

Solana, it becomes possible

16:25

to overcome problems that have

16:27

always existed within those

16:30

papers. Yeah, that's fascinating because

16:32

there's this like trend right

16:34

now, which is like, oh, anything that

16:36

is built on top of something

16:38

should probably become its own L1 or

16:40

at least think about it, right?

16:42

And that usually all you're getting

16:44

is some form of like economic

16:46

security or network effect or something

16:49

along those lines. But this is

16:51

like a real case where the

16:53

security model would be worse if

16:55

it didn't have a blockchain underneath

16:57

it. Exactly. Yeah. And it wouldn't

16:59

make any logical sense to then

17:01

also extend it into an L2

17:04

infrastructure. I really feel like this

17:06

setup will be the future to

17:08

have this big consensus mechanism and

17:10

then have Archeom with

17:12

this honest majority which can

17:14

perform specific kind of executions

17:16

in an asynchronous way but

17:19

doesn't have to find consensus

17:21

overstate. Yeah, that's

17:23

really interesting. So

17:26

from a

17:28

practical tools perspective, what does

17:30

this allow folks to do

17:32

either on or off blockchain

17:34

that they really can't do

17:36

today? So without using

17:38

the term healthcare records.

17:40

Yeah. Yeah.

17:43

So it's funny

17:45

because I think breakpoint

17:47

has thrown me and

17:49

my entire team that

17:51

basically everyone craves some

17:53

form of confidential computing

17:56

within their applications. Yeah. The

18:00

big problems why all of those CK

18:02

infrastructures haven't so far succeeded is that

18:04

they force developers to learn some new

18:07

paradigms, learn some new technology, actually need

18:09

to learn what a circuit is and

18:11

all those kinds of things. We for

18:13

example abstract all of that away from

18:16

developers. So we just say you want

18:18

confidentiality as a developer. So all you

18:20

have to do is you. mark the

18:22

functions and the state within your program

18:25

that should be confidential as confidential. And

18:27

then you let Arquium process that and

18:29

settle it back for you, right? So

18:31

that's what we're trying to achieve. And

18:34

so what folks can have is they

18:36

can have any arbitrary rust program essentially

18:38

be executed in a confidential way. And

18:40

so there's very tangible use cases. I

18:43

think one straightforward use case and has

18:45

been amazing to see, yeah, folks on

18:47

Solana start building that with us in

18:49

our private test net, private markets, right?

18:52

So dark pools, for example, since 30

18:54

to 40% of daily US spot volume

18:56

happens in dark pools, right? And so

18:58

there needs to be an answer for

19:01

that on the blockchain as well. A

19:03

lot of folks I talk with from

19:05

the threat file space actually often say,

19:08

yeah, you know, JP Morgan is actually

19:10

running a private ledger, right? Yes. But

19:12

they can't move to some public ledger

19:14

because of confidentiality assurance. So I think

19:17

that will be a significant step also

19:19

in regards to stable coin payments to

19:21

further enhance their adoption. And that's something

19:23

barrier. closely working together with core folks

19:26

in the Solana space because Solana has

19:28

the confidential talking program which yeah it's

19:30

only for transfers you can't run a

19:32

market on it exactly has some limitations

19:35

right and so by extending that to

19:37

allow smart contracts programs to have confidential

19:39

balances have confidential interactions between parties that

19:41

makes it so powerful and that will

19:44

allow some confidential lending protocol right and

19:46

will allow for some form of a

19:48

unified liquidity for all

19:50

those folks to

19:53

build applications with that,

19:55

but I think

19:57

DeFi is only the

19:59

first part. We've

20:02

seen a lot of

20:04

folks in Deepin

20:06

as well, be very

20:08

interested in this

20:11

kind of technology, so

20:13

that ranges from

20:15

people just wanting to

20:17

replace some trusted server infrastructure

20:20

with something trustless that

20:22

is being executed on the

20:24

blockchain. So, for example,

20:26

have some proprietary algorithm that

20:28

does some action

20:30

within a Deepin. Have

20:32

that be executed now in

20:34

a verifiable and trustless

20:36

way together with their program.

20:38

And on the more

20:41

complex side of things, I

20:43

think data aggregation and

20:45

also federated learning and machine

20:47

learning is something. My

20:49

take on

20:52

AI XCrypto has mostly

20:54

been that I think

20:56

AI agents sort of are

20:58

glorified bots and most

21:00

of it is fully artificial,

21:02

which makes sense, I

21:05

guess, but it's just the

21:07

superficial forced marriage. But

21:09

I think confidential computing can

21:11

actually be a logical fit

21:13

because we have very

21:15

highly sensitive data that could

21:18

benefit all of us, could

21:20

benefit humanity as a whole.

21:22

If we would find a way

21:24

to safely aggregate that into

21:26

models and then have a

21:28

way to, yeah, for example,

21:30

monetize this data rise, so

21:32

it could be encrypted sensitive

21:34

data that's collected on your

21:36

phone by some Deepin project,

21:38

for example, that then uses decentralized

21:40

confidential computing to train a

21:42

model that in itself remains

21:44

encrypted. So it's stored on the blockchain

21:46

as an encrypted model. And so

21:49

whoever wants to use that model has

21:51

to pay some smart contract, which then

21:53

distributes those funds back to the

21:55

people who gave their data to the

21:57

model. They actually never had to

21:59

give it. it remains their ownership, but

22:01

they provided encrypted data that formed

22:04

that model. So there can be

22:06

new economic incentives to produce more

22:08

high quality data. Yeah, and I

22:11

think down the line then, what

22:13

that will lead to is a

22:16

utopian future, where there's safe HGI

22:18

that runs on Solana, for example,

22:20

right? Because you can have safe

22:23

access control and the most high

22:25

quality data being encrypted. So I

22:28

think that's something where blockchain can

22:30

actually enhance AI, I think. The

22:32

Darkfills piece you talked about is

22:35

really interesting because there's a lot

22:37

of stuff in this space that

22:39

feels like it's transparency first. Yes.

22:42

Right. And there are a lot

22:44

of situations where transparency isn't necessarily

22:47

useful or necessary for a market

22:49

to function. I guess like I

22:51

think a lot about OTC desks,

22:54

right? How there are a huge

22:56

percentage of volume and there's... Literally

22:59

zero. I mean you can see

23:01

the movement on chain but like

23:03

other than that like it's all

23:06

settled and wire transfers after the

23:08

fact and you can't really see

23:10

where price is moving and those

23:13

sorts of things. Do you is

23:15

this technology fast enough today that

23:18

you can really run like a

23:20

central limit order book in a

23:22

confidential compute environment or are we

23:25

really still talking more like maker

23:27

and taker like OTC style systems?

23:30

So there's different approaches and what

23:32

we've seen is teams for example

23:34

using FGE fully homomorphic encryption attempting

23:37

to do that and yeah that's

23:39

not a market with sufficient sufficient

23:41

throughput but that's one of the

23:44

reasons why we decided to use

23:46

secure multi-party computation yeah because that

23:49

yields fast performance now moving from

23:51

an honest majority to a dishonest

23:53

majority trust assumption makes things a

23:56

bit slower because you want to

23:58

operate in the smallest possible trust

24:01

assumption, right? So what to be...

24:03

using is a so-called MPC protocol

24:05

in the pre-processing model, which means

24:08

that when you have a computation,

24:10

order matching, for example, that computation

24:12

now split into two phases. One

24:15

pre-processing phase and one online phase.

24:17

And the pre-processing phase is independent

24:20

of the actual... data being used

24:22

to the encrypted orders and parties,

24:24

whatever, and actually even the function,

24:27

it just is used to generate

24:29

so-called correlated randomness. And

24:31

that correlated randomness is

24:34

then being consumed in

24:36

the second phase, the online phase,

24:38

then operations can be performed way

24:41

more efficient. because we have had

24:43

this pre-processing. So one answer to

24:45

the question I think would be

24:47

okay. Since we are using the

24:49

setup, we can, we just need

24:52

to ensure pre-processing takes care, has

24:54

happened. Then we are able to

24:56

facilitate almost as fast as plain

24:58

text operation times for the online

25:01

phase. What we can also do

25:03

is we can make use of

25:05

oblivious data structure, oblivious sorting mechanisms,

25:07

where we can then asynchronously sort

25:09

large order books and crank up

25:12

the speed that way. And then

25:14

there's, I think, I would

25:16

say that performance-wise beer at a

25:18

point where it becomes feasible, but

25:20

yeah, basically I see my task

25:22

and the task of... my team

25:24

and our researchers at Arkham to

25:27

to just similarly to to what

25:29

a fired answer team is doing

25:31

but doing it for MPC to

25:33

just make that as fast as

25:35

possible come up with new cryptographic

25:37

protocols to to batch together communication

25:40

make use of hardware acceleration make

25:42

use of different yeah elliptic curve

25:44

operations we've been tinkering with so

25:46

yeah So I want to get

25:48

into a little bit of the

25:51

differences between fully homomorphic encryption and

25:53

MPC for sort of these use

25:55

cases. So there's sort of like

25:57

you can think about it as like.

26:00

What components do we care about

26:02

being private? Right? So there's like

26:04

the first version we talked about

26:06

that's like software encryption, where it's

26:08

like, I trust you and you want

26:10

to make sure I can verify that

26:12

what you've sent me actually arrived, right?

26:14

And no one like monkeyed with it

26:17

in the middle. There's the stuff you've

26:19

been talking about too, or it's like,

26:21

oh, we need to verify that like,

26:23

like, something exists without proving what

26:25

it is. Right, that's kind of one

26:27

piece we've talked about. And then like

26:29

FGE, the way folks talk about it

26:32

is like, oh, you can, a computer

26:34

can compute a result without knowing the

26:36

inputs or the output of that result,

26:39

which is like we've had black

26:41

box style computing for a while,

26:43

but usually the inputs are known

26:45

and the outputs are known and

26:47

that. process in the middle may

26:49

be like semi-blackboxed but like how

26:51

do these first off is that

26:53

a decent like explanation of how

26:55

this stuff works or like from

26:57

a from how you would interact

26:59

with it perspective and then where

27:01

does MPC versus FHE sort of

27:03

have different advantages and disadvantages?

27:06

So yeah I think this

27:08

idea of blackbox computing really

27:10

describes what both MPC and

27:12

FGE are trying to achieve

27:14

and but also trusted execution

27:16

environments. Yeah. So if you're

27:19

really talking about confidential computing

27:21

and black box operations those

27:23

are the free technologies to

27:25

think about because the K

27:27

allows for verifiability and two-party

27:29

private one-party privacy basically right

27:31

so those free FAGE MPC

27:33

and TES are what what

27:36

we should compare TES for me at

27:38

least from from. Yeah me

27:40

being able to look at Wikipedia

27:42

and news articles and and different

27:45

software exploits Just isn't the way

27:47

to go. Yeah, it seems like

27:49

SGX is hacked every other week

27:52

pretty much Yeah And also

27:54

if you don't have physical

27:56

security on the machines. Yeah,

27:58

it seems like it doesn't

28:00

particularly work. Yeah, I think it

28:03

works in a trusted cloud environment,

28:05

with a trusted software vendor, right?

28:07

Right, with physical security. Exactly, yeah.

28:10

Yeah. And it's also so striking

28:12

when Apple announced their T.E. hardware

28:14

for Apple Intelligence. in their blog

28:17

article they were describing them physically

28:19

guarding the machines exiting the manufacturing

28:21

plant and going to the data

28:24

center and you just have this

28:26

mental picture in mind with someone

28:28

with an assault rifle guarding a

28:31

computer right and you're like is

28:33

it actually this this amazing hardware

28:35

that can can do blackbox operations

28:37

doesn't seem that way right so

28:40

yeah it's sort of feels like

28:42

it being impossible. And to be

28:44

honest, we also have to look

28:46

at cryptography in a critical way

28:49

and have to think about quantum

28:51

resistance, right? So I think that's

28:53

also something that a lot of

28:55

folks, especially in our CK, MPC,

28:57

FGE space, try to ignore. But

28:59

I think that's something that we need

29:02

to work on with faster pace as

29:04

well. But I think these basically, and

29:06

for the folks. who are not as

29:08

familiar as Austin and IR with

29:10

that hardware-based security where basically the

29:13

hardware manufacturer has some privacy and

29:15

security promises that they give to

29:18

whoever purchases this hardware and we've

29:20

just seen this. huge amount of

29:22

exploits over the years a few

29:25

weeks ago. I think the most

29:27

recent one with Intel S3X, Intel's

29:30

trusted hardware for like the third

29:32

time. Yeah. And we even had

29:34

blockchain networks completely rely on that

29:37

and their privacy completely get Yeah,

29:39

researchers were able to completely decrypt the

29:41

secret network back to the Genesis block,

29:43

which is crazy. And the avalanche bridges

29:46

and a bunch of stuff like that.

29:48

Yeah. And so I think if you

29:50

want to build this Technology

29:53

that is future-proof, right, to build

29:55

this open network on which the

29:57

NASTEC can run, right? You don't

29:59

want... on some technology by every

30:01

five years, you need to

30:03

replace it with a new

30:06

trusted system by some other

30:08

manufacturer, you want something future

30:10

proof. So purely cryptographic systems,

30:12

I think is the answer.

30:14

And then the question is,

30:16

FGE versus MPC. FHE, basically,

30:18

as you described, allows you

30:20

to have an encrypted representation

30:23

of some value and perform

30:25

an operation. on that encrypted

30:27

representation of a value and

30:30

remain in that representation, right?

30:32

So it's, you're not exiting,

30:35

you're not decrypting, you remain

30:37

in this encrypted representation, which

30:39

is incredibly powerful. Yeah. It's

30:42

also very hard to think

30:44

through how that, like we don't have

30:46

a model for that. in the physical world.

30:49

Usually there's like a black box,

30:51

like something happens inside the box.

30:53

It's very hard to think of

30:55

like anything else where I can

30:57

perform an operation on something and

31:00

I have no ability to see

31:02

what the thing is. It's very

31:04

interesting. That's true actually, but

31:06

with FGE, powerful concept, and

31:08

the problem really is... It's

31:10

practical limitations and that

31:12

boils down to some

31:14

of the operations that

31:16

you're performing with FGE

31:19

fully homomorphic encryption Homomorphisms

31:21

mathematical homomorphisms basically means

31:23

that Yeah, two operations

31:25

are homomorphic which allows you

31:27

to remain in this representation

31:29

and multiplications as being one

31:32

of those operations are costly

31:34

because for when performing

31:36

those multiplications so-called noise

31:39

is being accumulated. And once

31:41

there's too much noise accumulated,

31:43

it's not possible to use

31:46

that ciphertext anymore. So this

31:48

noise needs to be reduced

31:50

using costly bootstrapping operations. And

31:53

that's mainly what makes FGE

31:55

so incredibly costly, meaning in

31:57

practice many orders of magnitude.

32:00

above your normal execution times

32:02

for whatever operations you

32:04

need to perform. And that's

32:06

of course not just

32:08

some latency penalty. That's also

32:10

computational power overhead, right? That

32:12

you have to work

32:14

with. So that's why we're

32:16

using MPC. Now MPC

32:18

is very closely related to

32:20

FHE. And so what

32:22

we're using is not fully

32:24

homomorphic encryption but somewhat

32:26

homomorphic encryption, which is a

32:28

subset and just makes

32:30

use of one operation being

32:32

homomorphic. And multiplication is

32:34

this very expensive operation we

32:36

are able to make use

32:38

of actually what we discussed

32:40

earlier, this preprocessing. That we

32:43

can make use of that

32:45

and that just makes it

32:47

very, very efficient. But of

32:49

course there's more trade -offs you

32:51

have to think about, right?

32:53

So with FHE, you're in this

32:55

encrypted representation, which is nice,

32:57

but what if you want to

32:59

exit that, right? What if

33:01

at some point under a given

33:03

condition you want to selectively

33:06

disclose some information about the encrypted

33:08

state, which especially becomes important on a

33:10

blockchain because I think you don't

33:13

want everything to be encrypted. I think

33:15

you want to be able to

33:17

move in and out of those representations.

33:19

Right, or even just like you

33:22

can see there being needs to

33:24

check point stuff and to provide

33:26

some amount of external observability at

33:28

like various pipeline points. Yes,

33:30

yeah, I think so too.

33:32

And so that's something that

33:34

MPC natively allows for this

33:36

form of selective disclosure. So

33:38

I feel like, and luckily

33:40

I'm not alone with that

33:42

opinion, but I mean, we

33:44

have one of the leading

33:46

FHE researchers in our team

33:48

and he's also fully convinced

33:50

of MPC being this technology

33:52

that allows for this generalized

33:54

confidential computing, both for on -chain

33:56

applications but also for off -chain

33:58

applications for AI. use cases. So

34:01

I think that's the correct path

34:03

to take and to make use

34:05

of any kind of hardware optimization

34:08

that we can make use of

34:10

both for MPC but also FGE

34:12

and CK. Yeah. So changing topic

34:14

a little bit, you're a co-founder.

34:17

Yes. You guys do a lot

34:19

of low-level research on this type

34:21

of work. Everything we've talked about

34:24

today. is about as far away

34:26

from a commercial product as you

34:28

can think of. How do you

34:31

think about balancing, when you're working

34:33

at this type of like fairly

34:35

groundbreaking technology, and a lot of

34:37

it being math, right? There's no

34:40

moat around math. You publish the

34:42

paper, it's out, everyone will use

34:44

it, right? How do you think

34:47

about building a product and a

34:49

business around this type of like

34:51

low level research? So I think

34:54

it's really important to... to have

34:56

a team that can satisfy both

34:58

ends of what's required to build

35:00

a product. It's this low-level research

35:03

being able to do the mathematics,

35:05

but at the same time, as

35:07

we discussed earlier, be able to

35:10

build programming interfaces, the developers can

35:12

just use. It doesn't make any

35:14

sense to build the best cryptography

35:17

and then, yeah, hand a research

35:19

paper to the developer and be

35:21

like, okay. read this manually, read

35:23

this research paper and then afterwards

35:26

you'll be able to to add

35:28

confidentiality. And so what we're working

35:30

on really is to have this

35:33

most accessible kind of confidential computing

35:35

because otherwise why would anybody use

35:37

it right? So I think that's

35:39

that's important striking this this balance

35:42

and to be honest. those low-level

35:44

researchers and PhDs often tend to

35:46

not find the most practical things.

35:49

And so it's important to have

35:51

also folks who, I mean, including

35:53

us when we were building a

35:56

lucid, but now in the meantime,

35:58

have more folks from the Solana

36:00

ecosystem be part. of our team

36:02

who then think like a developer,

36:05

right? They think like the end

36:07

user. And so I think in

36:09

general building a business around this

36:12

for us means building Arquium as

36:14

a global supercomputer and allowing anyone

36:16

to access that supercomputer for confidential

36:19

computations. And the supercomputer just needs

36:21

to be as accessible as possible

36:23

because then any kind of application

36:25

can have confidential computing. And what

36:28

do you see as sort of

36:30

technologies that are worth paying attention

36:32

to over the next few years

36:34

within this domain? It feels like

36:36

every few years there's a new

36:38

classification of something that gets stuck

36:40

on people's minds, raises a bunch

36:43

of money, maybe it works, maybe

36:45

it doesn't, but what are you

36:47

looking out as sort of some

36:49

of the advances coming to either

36:51

MPC or CK technology in general?

36:53

That's a very good question. Or

36:55

do we kind of have it?

36:58

We just need to make it

37:00

faster. So we have a lot of

37:02

what we need actually. I think

37:04

so too. And it's not just

37:06

about making it faster. It's also

37:09

about building those things. And as

37:11

I said, making them accessible. I

37:13

think that's one of the big

37:15

problems with CK, I think. Also,

37:18

what's not accessible is

37:20

requiring developers to learn a

37:22

new DSR. That's also not

37:24

accessible. And we've seen CK

37:26

teams that now introduce a

37:28

new domain-specific language that developers

37:30

need to learn. I think that's one

37:32

of the superior approaches that Solana has

37:34

taken as well. To by default, say,

37:37

hey developer, use rust, which is this

37:39

general programming language, which over the time

37:41

that Solana adopted it, has been adopted

37:43

by so many people in parallel, right?

37:46

So I think that was one of

37:48

the most logical decisions to make. to

37:50

be made and we are trying to

37:52

do it in the same way to

37:55

allow developers to add confidentiality

37:57

where they are at right now but that

37:59

takes time, tooling takes time and

38:02

optimization takes time as well.

38:04

So be it hardware acceleration,

38:06

be it communication optimization, be

38:09

it optimizing network communication protocols,

38:11

there's just a lot of

38:13

things that need to be

38:16

optimized. I think what I

38:18

personally would be or am

38:20

most excited about really is

38:23

protocols that optimize. network communication.

38:25

I think because that's one

38:27

of the big bottlenecks, optimizing

38:30

network communication, and the biggest

38:32

thing for me is oblivious

38:34

data structures. Because what my

38:37

vision really is, and that

38:39

might not be super relevant

38:41

for blockchain applications, I guess,

38:44

but my vision really is

38:46

to allow for fully encrypted

38:48

RAM programs. So it's not

38:51

just some small functionality, but

38:53

it's... anything your computer can

38:55

execute and it's not like

38:58

you pay gas for the

39:00

computation and then it's done

39:02

but it's run for the

39:05

next 10 years in a

39:07

confidential way right that's yeah

39:09

and and that requires complex

39:12

sort of encrypted data structures

39:14

that can have arbitrary size

39:16

and so yeah I think

39:19

that's what I'm most excited

39:21

about in that space. Excellent.

39:23

Well Henick thank you for

39:26

coming on validated. Thanks for

39:28

having me. Appreciate it. Valedated

39:30

is produced by Ray Belli

39:33

with help from Ross Cohen,

39:35

Brandon Hector, Amira Valiani, and

39:37

Ainsley Medford. Engineering by Tyler

39:40

Morissette.