普拉蒂尤什·米什拉谈微型证明、折叠、低内存SNARK及其他

所以我们决定利用电路特定的可信设置来处理矩阵向量乘法，然后采用标准PIP来执行哈达玛积或自定义门检查。

So we say we're going to use the circuit specific trusted setup to do the matrix vector multiplication, and then we're going to use standard PIP for doing the the Hadamard product or custom gate check.

这要求我们将多项式承诺推广到能够对已承诺多项式施加某些线性约束，从而引出了新型PC方案的概念。

And this required us to generalize polynomial commitments to also allow us to enforce some linear constraints on the committed polynomials and leading to, like, a new notion of PC schemes.

但本质上，这就是高层次的核心技巧。嗯。

But, essentially, like, that's the the high level trick Mhmm.

我们确实做到了。

Which we did.

我们将两项工作结合起来，汲取了双方的精华。

We combined the two lines of work to kind of take the best from both.

非常酷。

Really cool.

Nico，我们该继续讨论下一个预定议题了吗？

Nico, shall we move on to our next topic that we wanted to cover?

好的。

Yeah.

我认为现在是时候了。

I think it's a good time to do so.

清单上的下一个议题是专门关于哈希函数的折叠。

The next one on the list was folding from hash functions specifically.

是的。

Yeah.

用哈希函数进行折叠。

Folding with hash functions.

我是说，我们刚请Binyi上过节目，和他讨论过折叠技术。

I mean, we just had Binyi on the show, and we were talking with him about folding.

我们某种程度上重新定义了折叠。

We kinda did a redefinition of folding.

不过在格密码的语境下。

But in the context of lattices Mhmm.

我是说，格密码本身就被视为后量子安全的。

Mean, lattices build themselves as post quantum secure.

我的第一个问题是，使用哈希函数的折叠技术，你们是否也能获得同样的后量子安全性，还是说安全性会有所降低？

My first question to you, using folding with hash functions, do you get that post quantum secureness as well, or is it a lesser post quantum secure?

比如，怎么

Like, how

比较呢？

does it compare?

是的。

Yeah.

所以这里你能获得的后量子安全保证，与其他基于哈希的SNUCs（如基于fry的小吃）非常相似。

So so the post quantum security guarantee that you would get here is very similar to the post quantum security guarantee that you get for other hash based SNUCs like fry based snacks.

因此，这基本上是相同的安全保证。

So it's kind of exactly the same guarantee.

对于基于哈希的小吃，人们已经做了大量工作来实际证明你能获得这种保证。

In the case of hash based snacks, people have done the legwork to actually prove that you do get this guarantee.

我们目前还没有做到这一点，但借鉴现有工作应该不会是个巨大的挑战。

We have not done it so far, but adapting the existing work should not be like a massive lift.

那么这些研究是否都重新审视了量子随机默克尔模型中的Fetchemir和默克尔树等内容？

So are these all the works that revisit things like Fetchemir and Merkle trees in the quantum random Merkle model?

是的。

Yes.

具体来说，我认为2019年Kieser、Manohar和Spooner的研究表明，将BCS变换应用于IOPs可以得到后量子安全的论证。

So in in particular, I think there is this work in 2019, I think, Kieser, Manohar, and Spooner, which shows that applying this BCS transform to IOPs gives you a post quantum secure argument.

我怀疑同样的思路也可以推广到折叠构造上。

I suspect the same ideas can be lifted to the folding constructions as well.

不过，总的来说，我们目前没有理由认为答案是否定的。

But, yes, so the high level bit is probably we don't have any reason to think the answer is no.

好的。

Okay.

它具体表现如何？

How does it stack up again?

你们是否也在关注格密码相关的研究？

Like, are you following the Lattice stuff as well?

从高层次来看。

At a high level.

我对底层细节不太熟悉。

I'm not so familiar with the low level details.

但我想，格点工作与基于哈希的工作之间的关键权衡或差异在于，我认为在格点环境下可能比基于哈希的累积或折叠方案获得更高的效率。

But, yeah, I think the the key trade off between or, like, the maybe difference between the lattice work and the hash based work is I suspect that you could potentially get better efficiency in the lattice based setting compared to hash based accumulation or folding.

但我想这是以依赖格点假设为代价的。

But I think that this comes at the expense of relying on lattice based assumptions.

嗯。

Mhmm.

而在基于哈希的方案中，你只需要依赖哈希函数。

Versus in hash based setting, you're just relying on hashes.

所以这里存在一个微妙的权衡。

So there's like a slight trade off there.

公平地说，我并没有过多跟进格点方案，但据我所知，目前还没有基于哈希的累积或折叠方案的具体实现。

To be fair, I don't think I've not kept up with, like, the lattice based schemes too much, but at least to my knowledge, there's not been an implementation of the hash based accumulation or folding schemes.

所以具体效率，我认为仍然

So the concrete efficiency, think, is still

存疑。

Questionable.

好的。

Okay.

是的。

Yeah.

尚未确定。

Up in the air.

如果有人正在寻找灵感，这可能是个不错的R Quirk研究方向。

Might be a good R Quirk's inspiration, if anyone's looking for it.

没错。

Yeah.

其实我对这些基于哈希的方案挺好奇的。

I was actually curious with these hash based schemes.

目前许多基于哈希的ZKVMs系统通过递归证明实现了类似折叠或累积的等效操作，比如证明的证明的证明

So we also have and a lot of the ZKVMs out there that are hash based do something equivalent to folding or, like, accumulation just by doing recursive proofs, so, like, a proof of a proof of

一个证明。

a proof.

通常折叠技术的承诺在于：我的折叠验证器比SNARK验证器工作量更少。因此当进行这种证明的证明或折叠的折叠时，在电路中的执行成本会更低。

And usually the promise with folding is my folding verifier is gonna do less work than my snark verifier, So when I do this proof of a proof or this fold of a fold, it'll be cheaper to do in a circuit.

对于基于哈希的累积方案，我不确定的是：基于哈希的折叠验证器真的比SNARK验证器成本更低吗？

With hash based accumulation, I'm unsure, is it really true that the hash based folding verifier is cheaper than the the snark verifier?

这是个好问题。

That's a good question.

我认为这取决于你如何在系统中调整或使用累积机制。

So I think it depends on how you adapt or use accumulation inside your system.

嗯。

Mhmm.

目前ZKVMs实现递归的方式中，递归最昂贵的部分在于处理证明中涉及邻近性检查（或多项式承诺开启）的那部分内容。嗯。

So today, like how the ZKVMs do recursion is that really the most expensive part of the recursion is handling the part of the proof which corresponds to a proximity check or the polynomial commitment opening if you want to Mhmm.

从这个角度来看。

Take that perspective.

这类问题往往最终会主导递归操作的成本，至少在渐进意义上如此，我认为在实际中也是如此。

And that kind of is what oftentimes ends up dominating, at least asymptotically and I think concretely as well, the cost of doing this recursion.

而如今，如果转向非常高效的邻近性证明，比如WAR（嗯）。

And today, if you move to a very efficient proximity proof, like, let's say, WAR Mhmm.

那么WAR与累积多项式或邻近性声明之间的效率差距，对于多项式开放声明的处理并不会带来显著的效率提升。

Then the gap between WAR and accumulating the polynomial or the proximity claim to the polynomial opening claims will not really net you much of a efficiency benefit.

嗯。

Mhmm.

比如，你会从λ log log n次哈希或Merkle树路径减少到λ次Merkle树路径，大约是四倍的差距。

Like, you will go from lambda log log n hashes or Merkle tree paths to lambda Merkle tree paths, which is like a factor of four.

这个差距不算小，但也不算大。

This is not small, but not Not one.

是的。

Yeah.

这并非微不足道，但也不至于让你重新考虑系统设计或改变实现方式。

It's not one, and it's also, like, not something which necessarily leads to you rethinking your system design and, like, changing how you implement things.

这伴随着其他权衡取舍，我们稍后会讨论。

Come with other trade offs, which we can get into in a second.

但另一方面，像Nova这样的方案——包括其后续的Hypernova等改进——有个显著优势。

But on the other hand, you know, if you look at things like Nova, they have this really nice Nova or Hypernova things, you know, follow-up works.

它们有个绝佳特性：你只需对见证(witness)进行承诺。

They have this really nice property that all you need to do is you need to commit to the witness.

即使使用非常复杂的自定义门电路，也无需承诺额外向量，避免增加证明成本。

You don't need to even if you have, like, very, like, fancy custom gates, you don't need to commit to any additional vectors which might increase your proving costs.

当你从头设计系统以整合这些技术时，在递归证明中只需打开并承诺一条Merkle树路径。

Once you start going down that route and designing your system from the ground up to really just incorporate those techniques, really you will only have to open commit to an open one Merkle tree path inside inside your recursive proof.

这就引出了我们在论文中描述的折叠/积累技术的两大优势：

So this kind of like leads to, I guess, maybe what we described in our papers as two benefits of accumulation of folding.

一是递归验证器的规模会缩小，二是证明原始计算的工作量（不包括递归部分）也会减少。

One is that your size of your recursive verifier gets smaller, and also the work that the prover has to do just to even prove your original computation, excluding the recursive part, that also gets faster.

因此你能同时获得这两方面的优势。

So you get both of these benefits.

嗯。

Mhmm.

现在，如果你只是试图在现有系统中加入累积机制，可能无法获得加速证明者的好处。

And now, like, if you're just trying to throw an accumulation into an existing system, you probably will not get the faster prover benefit.

你仍能获得验证者规模缩小的优势。

You will get the smaller verified benefit.

但正如我们讨论过的，这比起加速证明者的优势来说吸引力稍逊一筹。

But as we discussed, that is, like, a little bit less compelling than the faster prover benefit.

但如果你从零开始设计整个系统来利用这些特性——或者说累积的优势——那么我推测，相比简单的递归，你能获得具体得多的速度提升。

But if you design your entire system from scratch to leverage these properties, will or like the benefits of accumulation, then you you can get concretely, I suspect, much much larger speed ups than just doing naive recursion.

嗯。

Mhmm.

展示这项研究的工作——至少我们注意到的是——针对里德-所罗门码的ARC累积方案。

The work that sort of showcased some of this research, at least the one that, you know, we we noticed was ARC accumulation for Reed Solomon codes.

你能分享一下这方面的情况吗？比如你们发现了什么？

Can you share a little bit about that and how like, what you found?

还有

And

好的。

Yeah.

是的。

Yeah.

其实这个研究的起点要稍早一些，源于一篇名为《无需同态的累积》的论文。

So the starting point for that was actually a little bit prior, and it was this paper called Accumulation Without Homomorphism.

我们最初尝试研究基于哈希的累积方法。

We tried to first investigate accumulation for, I guess, hash based accumulation.

我们在那篇论文中构建的方案确实存在一些局限性。

And the scheme that we constructed in that did have some limitations.

这是首个实现基于哈希累积的方案，但它有个限制：只能折叠或累积到某个固定磅数。

It it was like the first scheme which did hash based accumulation, but it had this limitation that you could only fold or accumulate up to, like, some fixed pound.

当你设置系统时，你会说，好吧。

So when you set up the system, you would say, okay.

我可以折叠，比方说10个snark或10个证明，然后就完成了。

I can fold, I don't know, 10 snarks or 10 proofs, and then I'm done.

现在我甚至没有任何可靠性保证了。

Now I don't have any soundness guarantees even.

而且，你的效率会变得更差。

And moreover, your efficiency would worsen.

比如，如果你提高上限，可以从10提高到20，但现在每一步你都要付出20倍而不是10倍的代价。

Like, if you increase the bound, you could increase the bound, like, from 10 to 20, but now your every step, you're paying, like, 20 x as opposed to 10 x.

这就是最初的工作。

So this was the initial work.

然后ARC基本上可以说是William Wang的智慧结晶，他是纽约大学Benedict的学生。

And then so ARC is basically, I would say, really a a brainchild of William Wang, who's a student of Benedict's at NYU.

关键洞见来自于研究Was it STIRR？

And the key insight came from looking at Was it STIRR?

STIRR

A STIRR.

啊

Ah.

是的

Yeah.

本质上讲，原子同构累积中的核心问题在于我们进行这类抽样检查来验证折叠输出与输入的一致性，而在此过程中我们承受着某种随着操作次数增加而不断累积的正确性误差。

Which essentially said that, like, the the core problem in accumulation with atomomorphism was that we were doing these kinds of spot checks to check that the folded output was consistent with, like, the inputs, and we were incurring some kind of soundness error which kept growing over the number of holdings that you did.

威廉（以及本尼迪克特）的关键洞见在于，他们发现可以实际运用STIR技术来完全避免这种损失，通过利用STIRR中开发的技术来规避额外的正确性误差。

And the key insight that William had was that I guess William and Benedict had was that you can actually leverage techniques from STIR to avoid that loss entirely, avoid that additional soundness error by leveraging techniques developed in in STIRR.

这使得我们最终能够实现折叠方案累积的理想效果——即支持无限次数的折叠操作。

And that allowed us to get, yeah, kind of what you would want out of an accumulation of folding scheme, which is unlimited number of foldings.

为满足大家的好奇心，还有一篇后续论文《线性时间累加器》，其采用了类似方法但运用了WOR中的理念。

For those that are curious, there's also a follow-up paper called Linear Time Accumulators, which kind of does the same thing, but uses ideas from WOR.

因此，STIR WOR实际上是通过优化此处用于累积的具体理念，对WOR进行的改进。

So, you know, STIR WOR is an improvement on WOR by improving the exact ideas that helped here for accumulation.

所以很自然地，接下来我们要做的就是，好吧。

So And the natural thing to do then was to say, like, alright.

让我们在累积方案中也改进这项技术。

Let's improve that technique also in the accumulation scheme.

是的。

Yeah.

所以实际上有两项工作。

So there there are actually two works.

所以Benedict和Alessandra有一篇论文，将ARC推向了一个方向，最终形成了这篇关于线性时间累积的WARP论文。

So one from Benedict and Alessandra, which was which took ARC in in one direction, which led to this paper WARP, which is linear time accumulation.

然后我们团队——也就是我和我的学生们——也提出了另一种构建这种线性时间累积方案的方法。

And then my group here also, so my students and I, we also had an alternate way of constructing this linear time accumulation scheme.

我想，从某种意义上说，ARC未完成的工作是它基于里德-所罗门码，这意味着你必须进行FFT等运算，这会带来类似时间证明的类比，并对可用字段类型产生限制——必须是FFT友好的字段。

So I guess, like, the thing that was left to do from ARC in some sense was that ARC worked with Reed Solomon codes, which mean meant that you had to do things like FFTs, which lead you to have, like, this analog and proof of time and also place constraints on the kinds of fields that you can work with in your FFT friendly fields.

但最近人们开发出了这种称为线性时间可编码的代码，它能提供O(n)编码时间，而不是O(n log n)编码时间。

But recently, people have developed these things called linear time encodable codes, which offer o of n encoding time as opposed to o of n n n log n encoding time.

基本上，WARP和FAX这两项工作都提出，让我们改进ARC，试图解决或弥补这个n log n的时间开销问题，通过采用线性时间可编码的代码，将其降至线性时间。

So basically, both warp and this work fax, they say, okay, let's take ARC and try to fix this or remedy this n log n, prove a time overhead, and bring it down to linear time by working for linear time encodable codes.

所以，是的。

So so that yeah.

只是对你的评论做些补充。

Just expanding on your comments.

其实我很高兴你提到FAX，因为它也源自一篇关于FIX和FAX的论文，这几乎直接关联到我接下来想讨论的话题——你们在邻近证明方面也有研究。

Actually, I'm really happy that you mentioned facts because that also comes from a paper of fix and facts that almost does the link to the next topic I wanted to talk about is you also have works on proofs of proximity.

我们聊了sturrWER，但你们还有FIX。

So we talked about sturrWER, but you have fix.

我想某种程度上，我们一直在讨论这种对偶性。

And I guess in a way, we've been talking about this duality.

每当一方有所改进，就能将其移植到另一方。

Every time there's an improvement on one side, you can port it to the other.

所以你们会有一篇同时研究两者的论文，这很合理。

It makes sense that you would have a paper that looks at both at the same time.

对吧？

Right?

是的。

Yeah.

没错。

Yeah.

那么，我们可以顺势谈谈邻近性证明。

So, yeah, we can segue into talking about the proofs of proximity.

我想我们之前大概提到过邻近性声明，以及这些如何成为SNARKs中的主要瓶颈，但只是简单带过。

So I think we've vaguely mentioned proximity claims and how these are the main bottleneck in SNARKs, but just in, like, one sentence.

如今，当我构建这些基于哈希的SNARKs时，通常证明者会使用某种纠错码对其消息进行编码。

So today, like, when I construct these hash based SNARKs, usually what the prover does is it encodes its messages using some error correcting code.

然后协议的一部分就是要证明这些消息实际上接近于有效的码字。

And then one part of the protocol is to prove that these messages actually are close to, like, valid code words.

好的。

Okay.

所以这部分被称为邻近性证明。

So this this portion is called the proximity proof.

真正推动高效哈希库革命的是这个名为FRI的协议，你们在播客中多次讨论过，几乎所有人都听说过它。

And so, I guess, really what kick started the efficient hash based stock revolution was this protocol called FRI, which we have you know, you guys have talked about multiple times on the podcast, and everybody really in has heard of.

这就像是首个引爆潮流的协议。

This was like the first protocol which kicked things off.

然后我想说的是，我们某种程度上...

And then I would say that we kind of

是的。

Yeah.

我们使用过它。

We used it.

它一直被持续使用。

It just kept getting used.

就像被深度油炸过一样。

There was like deep fry.

虽然有些许变化，但实际上只涉及were或stir这两个词。

There's a little bit of variation, but, it was really only with were or stir.

哪个先出现的，Nico？

Which one came first, Nico?

是WR吗？

Is it WR?

STIR。

STIR.

STIR。

STIR.

所以是的。

So it was yeah.

只有在STIR出现时，我们才真正感受到这种阶段性的变化。

It was only really with STIR where we saw this, like, step change, I feel.

是的。

Yeah.

确实如此。

Exactly.

正如你所说，安娜。

As you said, Anna.

对吧？

Right?

就像，我们顺势而为。

Like, we ran with it.

我们应用了它，但之后并没有真正看到太多新的构建。

We applied it, but then we didn't really see too many new constructions.

然后我们在2024年引入了STIR，这让我们看到一线希望，觉得可以做得更好。

Then we had STIR in, I think, 2024, which gave us some glimmer that, okay, we can do better.

但随后，我们看到在小规模验证场景下涌现了大量工作。

But then, like, we saw, like, a flurry of works in, the small small proof setting.

我们看到涌现了大量关于粘贴折叠的工作。

We saw, like, a flurry of works that was paste fold.

然后，最近出现的Blaze表明，其实你不必局限于只使用Reed Solomon码。

And then, like, recently, there was Blaze, which kind of showed that, okay, you don't actually have to stick to just working with these Reed Solomon codes.

你可以尝试为其他类型的码做近似证明，比如小型近似证明。

You can try to do proximity proofs for, like, small proximity proofs for other kinds of codes.

特别是，Blaze至少为线性时间可编码的码做到了这一点，正如我们讨论过的，它们只需要线性时间编码，而不像准线性或n log n时间的速率可解码。

And in particular, Blaze does this for at least linear time encodable codes, which as we talked about, you know, they only require linear time to encode as opposed to quasi linear or n log n time for rate solvent codes.

但本质上，Blaze展示了对于特定类型的字段IOP（交互式预言近似证明或IOPP），在应用Fierce、Miehren、Merkel树等技术后，可以得到一个证明大小约为λ log² n哈希的结果。

But, like, essentially Blaze show that, okay, you can get for particular kinds of fields IOP, interactive oracle proof of proximity or IOPP, where after you apply, you know, Fierce, Miehren, Merkel trees, and all of these things, you can get something with a proof size, I think it's lambda log squared n hashes, something like that.

家里的每个人都听懂了，他们心里有些主题，完全明白为什么这很好。

Everyone at home is following, and they have the there's some topics in mind, and they know exactly why this is good.

所以λ是一个安全参数。

So lambda is a security parameter.

不过确实。

But yeah.

基本上，它是按log² n的比例缩放的。

So, basically, it's scaled with, like, log squared n.

但如果你看里德-所罗门码这边，斯特恩团队成功将其降低到大约log n log log n乘以λ哈希值的水平。

If But you look at the Reed Solomon side, what Stern were able to do was to bring that down to, like like, log n log log n times lambda hashes.

基本上通过这个因子实现了缩减，带来了约2-3倍的实际提升，这对于希望将这些证明部署在区块链上尤为重要。

So basically, reducing it by this factor, which led to, like, a concrete improvement of, like, two to three x, which is important when you want to, like, put these proofs hopefully on the blockchain.

因此我们在FIX项目中的核心尝试就是：能否将这些优势移植到线性时间可编码的场景中？

So, essentially, what we did in FIX was try to see, can we port these same benefits over to these linear time and quotable code settings?

我们采用了Blaze中提出的核心思想——代码转换技术，这项技术可能在前期的几项理论工作中也有体现。

And so what we took was this core idea which had appeared in Blaze and maybe a couple of predecessor theoretical works, which is code switching.

如果大家没有其他优先问题的话，我们可以稍后详细讨论这个技术点。

And so we can talk about that in a little bit if there's not other questions that you want to go over first.

我想预留些时间讨论非区块链应用，毕竟我们在节目开头提到过这些内容。

I mean, I definitely wanna keep some time for the non blockchain applications because we did tell those early in earlier in the show.

不过确实想请教：能否简要说明FICS如何应用代码转换技术？

But, yeah, curious about maybe a few words on on how FICS applies code switching.

FACS系统也采用这种技术吗？

Does FACS do it too?

是的。

Yes.

FICS和FACS都采用了代码转换技术。

So both FICS and FACS do code switching.

简而言之，Reed Solomon码具有非常优良的结构特性，能让你高效实现类似fry中的折叠操作。

So, essentially, like, the summary is that Reed Solomon codes, they have this really nice structure, which allows you to do things like folding in fry very efficiently.

但线性时间可编码的码通常不具备这种优良结构。

But linear time encodable codes, they generally don't have this kind of nice structure.

代码转换本质上是一种技术方案，它表示：好吧，

So code switching is basically this technique which says, okay.

我们确实没有这种结构。

We we don't have the structure.

我们要做的就是证明我们的码字实际上接近这个码。

What we're just gonna do is kind of just prove that our code words are actually close to the code.

我们将为此设计专门的证明方案。

We're going to design specialized proofs for this task.

Blaze采用了一种方式实现这一点。

So Blaze does that in one way.

而在fix中，我们采取了另一种方法。

And in fix, we take an alternate approach.

我们设计了新的代码转换技术，并证明现有技术均可纳入统一框架，从而为广泛类别的线性时间可编码代码实现代码转换，同时继承了STORE和WOR的证明规模优势。

We design new code switching techniques and also show that existing code switching techniques can all be put in like one framework, which allows you to do code switching for a large class of linear time encodable codes and kind of brings over these proof size benefits that you got with STORE and WOR.

现在这些优势也延伸到了线性时间可编码代码领域。

Also, now to these linear time encodable codes.

这项研究最终在最近发布于ePrint的论文中达到顶峰，使我们甚至能消除log log n因子，实现λ log n哈希值的证明规模。

And then it's kind of culminated in this very recent work which went up on ePrint, which allowed us to kind of even get rid of the log log n factor and get proof size of, like, lambda log n hashes.

那项研究是什么？

What was that work?

这篇论文名为《查询最优IOPPs》。

So this is a paper called Query Optimal IOPPs.

这就是IOPPs。

This is the IOPPs.

好的。

Okay.

交互式预言机邻近证明。

Interactive Oracle Proofs of Proximity.

对。

Yeah.

所以我们实际上证明了这类邻近证明能达到的最佳证明大小，因此我们称之为最优。

So so we actually show that kind of this is the best kind of proof size that you can get for these proofs of proximity, which is why we called it optimal.

但目前这主要还是一项理论研究。

But it's mostly a theoretical work for now.

我不认为这些想法会带来完全更优的证明大小。

I don't think the ideas would lead to completely better proof sizes.

FIX和FACTS分别代表什么？

What what does FIX and FACTS stand for?

看起来像是缩写词。

Like, they look like acronyms.

是的。

Yeah.

好问题。

Great question.

我们某种程度上是从FRI这个名字获取了灵感。

We kind of took inspiration from the FRI name.

所以FRI就像是快速读取所罗门IOPP。

So FRI is, like, fast, read Solomon, IOPP.

嗯。

Mhmm.

所以我们就是，通过代码切换实现快速IOPP，然后这就变成了

So we just were, fast IOPP via code switching, and that became

我们的房子。

our house.

好的。

Okay.

这就是它的含义。

That's what it is.

另一个则是快速

And then the other one would be fast

累积。

a Accumulation.

好的。

Okay.

我得说这创意性不太强。

It's not too creative, I would say.

缩写形式看起来挺酷的。

It looks cool in short form.

是啊。

Yeah.

就像'棍棒石头'对应'修正事实'的感觉。

It's like sticks and stones are like fix and facts.

这大概就是我想表达的意思。

Was, like, kinda what I was going for.

不错。

Nice.

简单来说，你提到了代码转换，但我们为什么要

Very briefly, you talked about code switching, but why do we want

进行代码转换呢？

to switch codes?

所以核心理念是，我可以从一个关于基本情况的声明转换——比如这个代码词接近代码一中的内容。

So the idea is that I can go from a claim about basically, like, this code word is close to code one.

我可以将其简化为另一个声明——比如这个代码词接近代码二中的某个声明。

I can reduce that to a claim about, you know, co this other code word is close to a claim in code two.

现在代码二可以是更小规模的代码，也可以是像里德-所罗门码这样我们已经拥有现成IOPPs的编码。

Now code two can be either like a smaller size code or it could be something like a Reed Solomon code for which we already have existing IOPPs.

因此通过实现从代码一到代码二的声明转换，我们就能通过缩小规模或调用现有工具来推动进展。

So by being able to switch, you know, claims from code one to code two, we're able to kind of make progress either by reducing the size or, you know, co being able to invoke tools that we already do.

所以Fix基本上两者兼顾。

So fix kind of does both.

我们通过代码转换来缩小规模，一旦足够小，就直接调用类似star或word的方法。

We use code switching to reduce size, and then once it's small enough, we directly invoke something like star or word.

我明白了。

I see.

这样的话，我们就不必在意使用的是里德-所罗门码，因为问题规模已经比原问题小很多了。

And so in that case, we don't care that we're doing Reed Solomon codes because the problem is already smaller than the original one.

是的。

Yeah.

我们调用得足够频繁。

We invoke it like enough.

我们通过调用缩小规模的代码转换，将规模降至约n/log n，此时Reed Solomon码能在线性时间内处理。

We invoke the size reducing code switching to get us down to like n over log n size, and then at that point, Reed Solomon codes are linear time.

总结一下关于优化简洁非交互式知识论证的话题，我之前提到的最后一点是：如何在内存受限的环境中为简洁非交互式知识论证设计证明者。

So wrapping up on our topics of making better snarks, The last one that I listed or mentioned earlier was how do we get proovers for snarks in an environment where you have, like, restricted memory.

所以提到这个是因为它确实有。

So mentioned this because it has yeah.

有几篇论文。

A few papers.

没错。

Exactly.

这种场景下有什么例子？

What's an example of that setting?

是的。

Yeah.

对。

Yeah.

我认为这是近期人们开始关注的一个非常令人兴奋的领域。

So I think that's a very exciting area that people have been starting to focus on recently.

但这实际上是由应用场景驱动的——你需要在非常受限的设备上生成证明，比如网页浏览器、手机，或者甚至更受限制的设备。

But it's really motivated by applications where you want to produce proofs on very constrained devices, like, let's say, your web browser or your phone, or maybe even more restricted than that.

或许极端情况下，你可以想象在YubiKey上实现。

Maybe to the extreme, you can take it like on the YubiKey.

能在YubiKey上完成验证吗？

Can you do proving on a YubiKey?

嗯。

Mhmm.

那会非常酷。

That would be really cool.

我们还没达到那一步。

We're not there yet.

但总的来说，这种低内存验证主要研究如何在验证者只有少量内存的情况下完成验证。

But, yeah, in generally kind of this low memory proving is focused on trying to do proving when your prover has only a small amount of memory.

比如尝试用那点有限的内存来验证可能很庞大的计算。

Like, trying to prove maybe large computations in that small amount of memory.

我认为这个方向最近变得有趣，是因为长期以来我们都专注于缩短验证时间，而现在这方面已经取得了不错进展。

I think it's become interesting recently because for a long time, were focused on improving poover time, but now we have made good progress on that.

所以现在我们某种程度上被单台机器或设备的内存容量所限制。

So now we kind of end up being bottlenecked by the amount of memory on a single machine or device.

对。

Right.

我们之前请过Ligero的Mutu上节目，他非常自豪地宣传Ligero运行证明器时不需要太多内存。

So we've had Mutu on the show from Ligero, who very proudly advertises that Ligero doesn't need much memory to run the prover.

所以我在想，这是个已解决的问题吗？还是说我们要追求越来越小的内存占用？

So I was wondering, it a solved problem, or do we wanna go smaller and smaller and smaller?

是的。

Yeah.

Muthu的研究基础证明系统应该是Layhatron。

So so Muthu's work, I think, is Layhatron was the underlying proof system.

他们做了非常精妙的系统设计与证明系统协同设计，从而实现了这种被称为流式证明器的方案——这个我们可以稍后再详细讨论。

So they they do, like, a very clever system design and proof system co design, which allows them to get this kind of prover, which is called a streaming prover, which we can talk a little bit more about later.

嗯。

Mhmm.

但据我理解，这种方法的缺点在于最终会得到一个线性时间的验证器。

But I think, at least as far as I understand, the downside of that approach is that you end up with a linear time verifier.

至少对于Lihero来说是这样，我不确定这是否是该方法固有的问题。

And at least for Lihero and I'm not sure if this is inherent to this approach.

可能是的。

It might be.

至少对Lihero而言，它还会产生平方根级别的证明大小，这对许多具体应用来说可能已经足够。

At least for Lihero, and it also gives you, like, a square root proof size, which might be fine for a lot of applications concretely.

但确实意味着验证器的运行时间与原始计算规模呈线性关系。

But, yeah, it does mean that the verifier is linear time in the original size of the computation.

我认为当你开始关注更小的证明尺寸和非常简洁的验证器时，这仍然是一个开放性问题，确实，包括我和我的学生们在内的许多人都在努力推进这方面的研究。

I think once you start caring about smaller proof sizes and very succinct verifiers, it's I think it's still an open open question, which, yeah, we've been like, lot of proofs have been trying to make progress on, including my students and I.

有哪些突破性进展使得这种低内存SNARK结构成为可能？

What are some of the breakthroughs that have come around to allow for this low memory SNARC construction?

是的。

Yeah.

所以我认为，实质上我们已经知道一种非常高效的方法，那就是通过递归来实现。

So I think I mean, in substance we did already know one way to do this very efficiently, which is via recursion.

好的。

Okay.

如果采用递归或折叠技术，你只需为单个步骤的规模付费，而不是整个计算过程。

If you do recursion or folding, then you only ever pay for the size of one step as opposed to the entire computation.

是的。

Yeah.

比如，我记得MENA在早期总是...你知道的，规模一直很小。

Like, I think MENA back in the day was always kind of, you know, was very small.

对。

Yeah.

这样就能得到较小的证明规模。

And then that that gets you, like, small proof sizes.

但缺点是，对于递归展开技术，我们在某种程度上对其安全性还没有很好的把握。

The downside is that with recursion unfolding, in general, we don't have a very good handle on the security in some sense.

比如，我们的安全性证明或可靠性验证仅适用于固定步骤数的情况，而这与我们在现实世界中的使用方式不符。

Like, we're our proofs of security are only or soundness are only for, like, a constant number of steps, which is not how we use these things in the real world.

是的。

Yeah.

顺便说一下，这也是我们最近与Biny的节目中提到的内容。

This is also something we mentioned, by the way, on our recent episode with Biny.

所以对那些想了解更多关于这些安全特性细节的人，我强烈推荐那一期节目。

So for those interested in more details about these security properties, I really recommend that episode.

好的。

Yeah.

我们会附上链接。

We'll link to that.

对。

Yeah.

没错。

Yeah.

而且这也逐渐成为更受关注的问题，比如这次针对基于GTR的证明系统的攻击，哦，确实。

And it's kind of also become more of a concern, but like this attack on GTR based proof systems Oh, yeah.

因为需要在电路内部使用哈希函数。

Which because you need to use hashes inside the circuit.

不过无论如何，这些方法确实有效。

But anyway, so those things work.

它们确实存在一些理论上的局限性。

They do have certain both theoretical limitations.

还有安全方面的限制。

And security ones.

以及安全方面的限制。

And security ones.

是的。

Yeah.

我认为，总的来说，如果你不想采用递归方法，那么这是否就是你能做到的最佳方案，这个问题也很有趣。

I think I think in general, it's also interesting to see if you don't want to go for recursion, like, is the best that you can do?

你们会遇到一些障碍吗？

Are there, like, some barriers that you run into?

所以我想，在这种情况下，我们（主要是我的学生们和我）不得不构建这些整体式的SNARK。

So I guess in that vein, what we've had to do, I guess my students and I, is to construct kind of these monolithic SNARKs.

我们试图证明整个电路，而不是将其分割成小块分别证明。

We're just trying to prove a full circuit instead of breaking it up into chunks and proving each chunk separately.

我们当时有两种方法。

And there we had two approaches.

第一种方法就是这篇名为《Scribe》的论文。

The first approach is this paper called Scribe.

其核心思想是：即便在许多内存有限的设备上，它们通常都拥有较大的磁盘空间。

And the idea there was that, okay, even on many devices which do have limited amount of RAM or memory, what they do often have is like a large amount of disk space.

对吧？

Right?

即使是入门级iPhone也有几十GB的存储空间。

Gigabytes even in like your entry level iPhone.

因此，我们的设计思路是让证明程序将状态数据存储在磁盘而非内存中，并通过协议设计确保这种内存访问方式依然高效。

So what we did was design the prover where instead of storing all of the prover state in memory, we were able to store it on disk, and we made sure to design protocol in such a way that accessing that memory was efficient.

通常来说，磁盘访问效率是足够高的。

So normally, ax accessing the disk was efficient.

正常情况下，磁盘访问速度比内存慢得多，至少相差十倍。

So normally, accessing disk is like way slower than accessing memory, like 10 x at least.

但我们设计的算法能够完全抵消这种性能开销。

But the algorithms that we designed were able to kind of completely mask the overhead.

具体来说，我们在这个模型中设计了这种版本的Hyperplunk，证明者状态存储在磁盘上，但与内存证明相比，其开销仅增加了约10%。

And in particular, we designed like this version of Hyperplunk in this model where the prover state is on disk, but the overhead compared to in memory proving was like 10%.

好的。

Okay.

这就是你之前提到的流式证明器吗？

Is this what you described earlier as a streaming prover?

是的。

Yeah.

流式证明器的全称。

So streaming prover Full name.

是的。

Yeah.

这实际上是理论计算机科学和流算法中的一个完整研究领域。

It's actually entire area of research in theoretical computer science and streaming algorithms.

不错。

Nice.

但流式证明器是对此的进一步限制，它规定证明器只能拥有少量内存，并且必须通过流式方式访问见证数据和电路描述。

But a streaming prover is, yeah, a further restriction of this, which just says that this prover is only allowed to have some small amount of memory, and it can access the witness and the circuit description via stream.

也就是说，它必须按顺序读取见证数据的第一位，然后丢弃它再读取下一位，依此类推。

So sequentially, it could read, like, the first bit of the witness, and then it has to throw it away and read the next bit, and so on and so forth.

这是一种非常严格的模型。

This is a very restrictive model.

而我们提出的方案是：你不需要丢弃这些数据。

What we said was, You don't have to throw it away.

你可以直接将处理过的那部分见证数据或其他内容写回磁盘，这样将来需要时就能再次读取。

You can just write back that bit of witness or whatever you processed to disk so that if you need it again in the future, you can read it again.

嗯。

Mhmm.

我想流式证明者实际上比内存密集型的要慢一些。

I guess streaming provers, they actually are slower than the memory intensive ones.

但通过我们的构建方法，我们能够从渐进和具体两个层面将开销降低到仅10%。

But with our construction, we were able to kind of both asymptotically and concretely bring the overhead down to just 10%.

顺便问一下，这就是你们将其命名为'scribe'的原因吗？

By the way, is that why you called it scribe?

因为它既是流式的，又允许写入操作？

Because it's streaming and it's also allowed to write?

是的。

Yes.

之所以叫scribe，正是因为它会记录下内容。

It's scribe because it writes down.

不错。

Nice.

第二种方法是什么？

What's the second approach?

所以第二种方法实际上是坚持流式处理。

So so the second approach actually is to stick to streaming.

这是另一项名为'Sumcheck的时间空间权衡'的研究。

And this was this other work called the time space trade offs for Sumcheck.

Sumcheck协议现在基本上是所有高效SNARK的工作成本核心。

So the Sumcheck protocol is like kind of now the work costs of all efficient SNARKs essentially.

是的。

Yeah.

但我们使用的算法大致可分为两类。

But the algorithms that we use for it, they kind of fall into two categories.

要么使用极小空间但会导致类似n log n的证明时间，具体表现为Sumcheck约30倍的开销。

Either you use a very small space, but then you incur like n log n proving time, which concretely translates to like a 30 x overhead for the sum check.

或者你使用线性空间并采用线性时间，这已经是能达到的最佳情况了。

Or you use like a linear amount of space and you take linear time, which is the best you could hope for.

因此我们试图研究，如果采取折中方案会怎样？

And so we were trying to investigate, okay, like what if you have a middle ground?

比如使用中等而非极小的空间量，能否取得更好的效果？

Like you use like not tiny amount of space, like a medium amount of space, can you do better?

这项研究的灵感来源于EPFL的Alessandro团队发表的Blendy论文。

And so the predecessor, like, maybe the inspiration for this was this paper called Blendy from Alessandro's group at EPFL.

随后我和学生们接手了这个方向，联系了他们并达成共识：

Then my students and I kind of picked that up and, you know, we reached out to them and we were able to say, okay.

Blendy的研究成果是否已经达到最优？

Are the results in Blendy the best you can do?

而且那些成果仅适用于特定类别的SumCheck，与实际协议应用场景并不完全吻合。

They were also, like, only for a particular class of SumCheck, which is not actually how we use it in protocols.

我们成功将其推广到协议实际应用的SumCheck场景，证明确实可以超越之前提到的两种极端方案。

So we were able to generalize that to actually how we use SumCheck in protocols and showed that, yeah, you can do better than kind of the two extremes that I'd mentioned earlier.

你可以获得几乎与高内存版本一样快的性能。

You can get something which is almost as fast as the high memory version.

我认为在实际应用中，速度仅慢两倍，但内存使用量在大规模情况下可能减少100倍。

Like, I think in practice only two x slower, but using, I don't know, like, 100 x less memory for large sizes.

而且我认为最酷的部分是我们证明了这基本上就是你能达到的最佳状态。

And we also I think the cool part is we were able to show that kind of this is the best that you can do.

如果你想使用特定数量的内存，就必须承受大约两倍的开销。

If you want to use a particular amount of memory, you must incur, let's say, this two x overhead.

你无法做得比这更好，我认为这在SNARK领域是相当罕见的情况。

You can't do better than that, which I think is kind of a rare occurrence in in SNARKs.

我们通常不会有这类下限约束。

We don't usually have these kinds of lower bounds.

那么这两种低内存SNARK构造方案，是否与Lihero或我们节目中讨论过的其他系统有相似之处？

So these two approaches, both low memory SNARK constructions, are either of them similar to Lihero or to other systems that we've maybe talked about on the show?

我认为你可以借鉴Lihero的思路应用到这里，或许能打造出更优秀的整体系统。

I would say you can take ideas from Lihero and apply them here, and maybe hope to get like a better system overall.

嗯。

Mhmm.

或许通过采用我们的时空权衡新算法，能够突破Lihero的一些限制。

Maybe some limitations of Lihero can be lifted by using, for example, our time space trade off, the new subject algorithm.

具体来说，Lihero这类基于哈希流的SNARK系统存在一些难以逾越的障碍。

Actually, concretely, there are some barriers to what you can do with Lihero style systems where you have these hash based streaming SNARKs.

我来转述一下。

I'll paraphrase.

你必须在证明规模上做出妥协——要么无法实现极小的（如polylogarithmic级别）Fry式证明规模，

You must either have not small proof size, like not polylogarithmic, like tiny proof size, fry style proof size.

要么就得放弃流式证明者的特性，

You can either have that or you can have streaming provers.

二者不可兼得。

You can't have both at the same time.

但如果采用这种scribe模型，实际上可以同时实现这两个目标。

So, like, if you take this kind of scribe model, then you can actually do both.

或者说我们认为你可以两者兼得。

Or we think that you can do both.

这是我们正在跟进的研究工作，我们希望证明你确实可以同时获得非常小的证明和低内存的验证者。

This is like some follow-up work that we're working on, and we're hoping to show that you can actually get both very small proofs and low memory approvers.

很棒。

Cool.

所以，是的，我认为这是一个值得未来探索的有趣方向。

So, yeah, I think that's like a interesting direction for people to investigate in the future.

我想我们已经讨论了迄今为止的工作以及Nico你最初提出和Pratush你提到的这些主题。

So I think we've covered the work to date and some of these themes that, Nico, you first presented and Pratush, you'd brought up.

还有一类你们在节目开头谈到的内容，就是非区块链领域，某种程度上偏离了我们节目主要讨论的问题空间。

There is another category that you were talking about at the beginning of the episode, which is like non blockchain, the sort of move away from, you know, the problem space that we we mostly talk about on this show.

你们在那边主要做哪些工作呢？

What are the kinds of things you're doing over there?

而且，是的，我猜那边应该也有一些合作在进行。

And and, yeah, I I'm assuming there's also some collaborations happening there.

是的。

Yeah.

也许你可以分享一些那些计划。

Maybe you can share a few of those initiatives.

对。

Yeah.

没错。

Yeah.

我想，到目前为止我们讨论的所有内容都主要集中在SNARC构建方面。

So I guess, like, all of the things that we talked about so far are very much on the SNARC construction side.

是的。

Yeah.

另一方面，在应用前沿，我一直在与一些合作者研究可能不严格属于区块链应用的领域。

On, like, the other side on application front, I've been looking at with some collaborators at maybe non strictly blockchain applications.

我认为它们对区块链用例也有应用价值。

I think they have applications to blockchain use cases as well.

不过，是的，其中一个方向是与宾夕法尼亚大学的教授Sebastian合作，旨在证明当你有一份已提交的文件时，它确实符合某种特定结构。

But, yeah, like, one direction has been this is in collaboration with Sebastian, who's a professor at Penn, on proving that if you have some kind of committed document that it actually satisfies some kind of structure.

例如，这可能是一份包含特定条目的有效JSON文档，或是一个有效的C语言文件，诸如此类。

So for example, it's a valid JSON document with a particular entry, or it's a valid c file, or something along those lines.

所以任何能被上下文无关文法捕获的内容都可以。

So anything which can be captured by a context free grammar.

这类似于证明某种特定语言吗？

Is it like proving a certain language?

还是说这是在声明这份文件是用XYZ语言编写的？

Or like is it saying this is written in x y z?

或者它的范围比这更广泛？

Or is it more general than that?

是的。

Yes.

总的来说，这是在证明文件符合特定文档格式的规范或结构。

In general, it's proving that it matches the specification or format of a particular document format.

也就是说，看起来像一个C文件或JSON文件。

So, like, looks like a c file or looks like a JSON file.

至于这项技术的应用场景，我们在论文中已经讨论过一些。

And the applications for this, you know, we discussed a few in the paper.

其中一些应用与区块链相关领域密切相关。

Some of them kind of relate back to very blockchain adjacent applications.

比如当前的ZK TLS技术，当你从服务器获得响应时，你只是假设它是格式正确的响应。

So, like, ZK TLS right now, when you get a response from the server, you just assume that it's a properly formatted response.

而且你知道，响应中的电子邮件字段总是位于相同的位置。

And, you know, the email field in the response would always be at the same location.

但如果服务器——它对你的应用一无所知——即使稍微改变了响应格式，那么你所有关于ZK TLS应用的保证可能就都失效了。

But, you know, if the server, you know, who is does not know anything about your application, changes the response format even a tiny bit, suddenly now maybe all your guarantees about your ZK TLS application go out the window.

是的。

Yeah.

同样适用于像ZK登录或Aptos无密钥这样的技术，它们都依赖于JWT令牌的特定格式。

Similarly for things like ZK login or Aptos keyless, which rely on, like, particular formatting of the JWT tokens.

是的。

Yeah.

我们可以添加一些相关链接。

We can add some links to that.

我们在节目中已经和几个团队讨论过这个话题了。

We covered that on the show with a couple of those teams.

因此CORAL在这里的作用是，你实际上可以获得一个证明，表明现在服务器或其他来源的响应确实与你指定的规范完全匹配。

And so where CORAL would come in here would be that you actually can get a proof that now this response from the server or whatever actually matches this exact specification that you wanted.

这样你就能获得更强的保证。

So you can get like a stronger guarantee that way.

它还能证明文件内容而不仅仅是格式吗？

Does it also prove statements about the contents of the file or just the formatting?

是的。

Yeah.

所以你可以证明它包含，我不知道，嵌套两层的电子邮件字段，其中有，我不知道，Prathyush@penn.com或任何内容，或者penn.edu的电子邮件在那里。

So you can prove that it contains, I don't know, nested two levels deep, an email field which has, I don't know, Prathyush@penn.com or whatever, or penn dot edu has the email there.

这很酷。

That's cool.

这项工作的标题是CORAL，快速异步非交互式零知识CFG证明。

The title of this work, CORAL, Fast Async Non Interactive Zero Knowledge, CFG Proofs.

CFG是指上下文无关文法吗？

Is CFG, that's context free grammar?

是这个意思吗？

Is that what that stands for?

是的。

Yes.

这是Sebastian团队之前关于正则表达式或正则表达式匹配证明的后续工作，人们也曾在与区块链相关的轻量级应用场景中使用过。

It's context And free it's just like a follow-up book, I guess, that Sebastian's group has done previously on reg ex or proofs of reg ex matching, which people have also used in very thin blockchain adjacent application contexts.

嗯。

Yeah.

我注意到论文作者中还有来自Brave的人，这让我很感兴趣。

I was interested to see authors from Brave as well on that paper.

那么这家浏览器公司，他们是在研究这类ZKTLS证明吗？

So the the browser company, are they looking into these sort of ZKTLS proofs?

就是说，这就是他们在这里的原因吗？

Like, is that why they're here?

是的。

Yes.

我想索菲亚——Brave的合著者，她和她的合作者一直在研究一些ZKTLS相关的工作。

I think Sofia, who's who's the co author from Brave, she and her collaborators have been working on some ZKTLS work.

不错。

Nice.

所以她建立了CORAL与现有ZKTLS协议局限性之间的联系。

So she made that connection and that link between CORAL and this limitation of existing ZKTLS protocols.

听起来和他们一起探索这个会很有意思。

That sounds like that would be really fun to explore with them, actually.

这就像，你知道，一个拥有用户的团队——现在是由浏览器生成ZKTLS，不像我们接触过的大多数团队，那些是ZK TLS团队主动去适配浏览器。嗯。

This is like, you know, a team with with users who are now it's like the the browser producing the ZKTLS, unlike most of the teams that we've talked to, which are ZK TLS teams kind of approaching browsers Mhmm.

可能作为客户。

Potentially as customers.

是啊。

Yeah.

那会非常酷。

That would be really cool.

你提到这是塞巴斯蒂安团队之前工作的延伸，我现在想起来有一篇叫《Reef》的论文。

So you mentioned this is an extension of previous work from Sebastian's group, and I now remember there's a paper called Reef.

是正在扩展的那个吗？

Is is that the one that's being extended?

是的。

Yes.

所以我们称它为Cora。

That's why we called it Cora Okay.

因为它推广了Reef。

Because it generalizes Reef.

非常棒。

Very nice.

所以它使用了Nova。

And so it uses Nova.

对吧？

Right?

就像，在它的底层。

Like, deep inside it.

是的。

Yeah.

没错。

Yeah.

所以，是的，它

So, yeah, it

使用了我们修改过的Nova版本。

uses, like, our modifications of Nova.

我很好奇。

I'm curious.

你们还研究过或正在开发哪些

What other non blockchain applications have you

非区块链领域的应用？

been looking at or or working on?

是啊。

Yeah.

我认为一个令人兴奋且与Coral略有不同的是，我们一直在研究可验证数据库查询的证明系统，也就是用于可验证数据库查询的这套证明体系。

So I think one exciting one, slightly different from Coral, is we have been working on this proof for verifiable database queries, so this proof system for verifiable database queries.

这个想法的核心在于，有一个数据库所有者提供对数据库的承诺，其中包含2包含标准数据库中应有的所有内容。

And the idea there is that you have a database owner who provides a commitment to the database, you know, which contains whatever you would have, I guess, in a standard database.

然后你可以让客户端和服务器进行交互。

And then you could have client and server who interact.

每当客户端想要查询数据库时，服务器现在可以提供保证，嘿，这就是数据库的查询结果。

And whenever the client wants to make a query into the database, the server can now provide a guarantee that, hey, this is the result of the database.

更重要的是，这里有一个证明可以显示这个结果是正确的。

And moreover, here's a proof which shows that this result is correct.

明白吗？

Okay?

而且我在回答你的查询时没有作弊。

And I did not cheat in answering your query.

这个验证是基于最初提供的数据库承诺进行的。

And this is verified with respect to that commitment to the database that was provided originally.

所以这就像是一个高层次的应用。

So it's like the high level application.

之前已经有几项关于这方面的研究。

And there's been a few works on this previously.

我记得第一个是2017年左右Yupeng Zhang提出的可验证SQL。

The first one I think was this verifiable SQL back in 2017 or so from Yupeng Zhang.

他现在好像在UIUC。

It's like UIUC now.

不过，是的，我认为这一系列工作即使对于不算太复杂的查询和不算太大的数据库，也产生了相对较高的开销。

But, yeah, I think the line of works, they incurred relatively high overheads even for, I would say, not too complex queries and for not too large databases.

所以我们正在进行这项工作，试图大幅降低这种开销。

So we have this kind of ongoing work which tries to reduce that overhead a lot.

而且我认为我们已经能够实现亚分钟级别的证明，对于相当大型数据库上的复杂查询。

And I think we're able to get sub minute, I don't know, proofs for complex queries on, like, I would say fairly large databases.

有意思。

Interesting.

是的。

Yeah.

我记得也看过Matteo Campanelli关于这个主题的论文。

Remember seeing a paper by Matteo Campanelli on on that topic as well.

那么你的意思是说？

And so is this what you're saying?

在某些情况下，我们是否应该主张设计更考虑应用场景的证明系统，而不是使用我们已经熟悉并喜爱的snarks？

Was we're advocating for, in some contexts, it might be better to design our proof systems with the application in mind rather than using the snarks that we already know and love?

是的。

Yeah.

没错。

Yeah.

这正是那个观点的来源。

So that's exactly where that comment was coming from.

对。

Yeah.

是的。

Yeah.

因为我们在这个项目中所做的，实际上是设计了高度专业化的PIOP（多项式交互式Oracle证明），专门针对核心SQL操作符。

So because what what we do for this project is actually we design very specialized op like, PIOPs essentially for the core, like, SQL operators Yeah.

比如连接、选择、分组等操作。

Like joins selections and group buys and all of these things.

正因如此，通过不采用电路方法，我们相比基于电路的方案配合尖端SNARK技术，能够实现数量级的加速。

And because of that, and by not going via the circuit approach, I think we're able to get like orders of magnitude speed ups compared to like a circuit based approach and throwing a state of the art snark at it.

正好谈到这个技术可能的应用场景，我不确定链接是否正确，但前几期我们做过一期关于Turnkey的节目，那是个类似TEE的解决方案。

Just on the topic of where this might be used, and I don't know if this is the correct link, but a few episodes ago, we did an episode on Turnkey, which was like a TEE solution.

他们提到过不信任数据库的问题。

They talked about like not trusting the database.

嗯。

Mhmm.

我在想类似你们的技术是否能在他们的场景中派上用场。

And I wonder if something like this could be helpful in in their situation.

不知道你们是否——可能我联想得有点牵强——你们有听说过相关情况吗？

I don't know if you've like, I I I might be making a connection that isn't there, but I don't know if you've heard anything about that.

我还没听那期播客。

I did not listen to that podcast episode yet.

它在待办清单上。

I it's on the backlog.

我认为总体来说，这项技术在很多应用场景都会很有帮助。

I think I think in general, like, there's lots of applications where this would be helpful.

有一个区块链应用，我认为正在被一些行业人士探索。

There's one blockchain application, which I think is being explored by some industry folks.

所以我认为拉格朗日实验室，这基本上就是他们最初尝试做的事情，哦。

So I think the Lagrange Labs, this was like what they had started off trying to do, basically Oh.

试图提供这样的功能：你将历史区块链状态视为一个数据库。

Trying to provide like, you you view the historical blockchain state as a database.

然后因为智能合约获取这些历史状态的访问成本很高，你就改为提供一个证明，表明这里有一个状态，并且这个状态相对于区块链的承诺（不知道是对区块还是什么的承诺）是有效的。

And then because smart contracts, it's very expensive to get them access to this historical state, You instead just give them a proof that here's a state and here's a proof that the state is valid with respect to the, I don't know, commitment to this to the blockchain, to the blocks or whatever.

嗯。

Mhmm.

所以这就是之前提到的协处理器概念。

So this is the whole coprocessor narrative from a while back.

对吧？

Right?

是的。

Yeah.

算是吧。

Kind of.

对。

Yeah.

所以这是一个应用方向，我记得有家公司叫Space Time Labs之类的。

So that that's one application that I think space there's a company called Space Time Labs or something like Yeah.

这家公司已经存在一段时间了。

That's been around for a while.

是的。

Yeah.

他们一直在研究这个应用。

So they've been looking at this application.

还有家叫Proovably的公司。

And there's also a company called Proovably.

我之前提到的Mateo论文，合著者就来自Provably公司，他们也是做这个的。

So this Mateo paper that I mentioned, I think, with coauthors from Provably, and that's also what they do.

我明白了。

I see.

有意思。

Interesting.

是啊。

Yeah.

所以我觉得这是个非常有趣的应用，因为你确实拥有非常受限的验证者。

So I think that's like a very interesting application because you do actually have very constrained verifiers.

我们为这个系统考虑的另一个应用，基本上就是提供一种删除证明。

Another application that we've been thinking about for this system is basically to give you, like, a proof of deletion.

比如，在非区块链环境下，像GDPR规定的那样，如果我提出一个请求...

So, like, in a non blockchain context, like, under GDPR, if I make a request Yeah.

要求你删除我的数据，目前你只能相信公司的承诺，审计员需要花费高昂成本进行核查，或者只是做些抽查。

That you delete my data, right now, you have to take the company's word for it, and auditors have to do like a really expensive job of like checking this or they just, you know, do some spot checks.

但现在可以让公司提供一份证明，展示这是我的数据库，这是更新后的承诺，我会公开发布让所有人看到。

But now you can have the company give you a proof that here is my database and here's the updated commitment, which I'm gonna publish for everyone to see.