肖恩·鲍谈SNARKs、可信设置与椭圆曲线密码学

从密码学角度来说，原始仪式无法支持这种模式的原因是，为了安全证明，你必须事先承诺你的秘密——也就是所谓的这些'有毒废料'副产品，不管我们怎么称呼它。

And the reason why cryptographically, the original ceremony couldn't support this was because you had to for the security proof, you had to commit to your secrets, to to your to to this toxic waste, so to speak, or this toxic waste byproduct, whatever we call it.

你必须在仪式开始前就承诺这些内容，这样你就无法在之后改变你要采取的行动。

You had to commit to that before the ceremony began so that you couldn't change your move that that you're gonna make later on.

这样做纯粹是为了让密码学机制能够运作。

And this was just to make the cryptography work.

这显然不是必要的。

It was clearly not necessary.

所以在Sprout之后，我就说过，去他的这个预承诺阶段。

And so after after Sprout, I had I said, screw this commitment this pre commitment stage.

我们干脆把它去掉，另寻他法。

Let's just get rid of it and find something else.

对于powers of tau和sapling多方计算，我们发现只需使用随机性信标就足够了。

For powers of tau and for the sapling MPC, we figured it out that we could just do a randomness beacon, and that was good enough.

但即便那失败了，我认为它也能保障代数群模型的安全。

But even if that failed, I think it was securing the algebraic group model.

后来，Mary Mallers和其他人发现，只需使用Fishlin变换，就能让安全证明通过，因为这样可以得到一条直线提取器。

And then later on, Mary Mallers and and other people have figured out that, oh, you just use Fishlin transforms, and you get the security proof goes through that way because you get a straight line of extractor.

所以关键点在于摆脱那个承诺环节，同时整个仪式还包含多个阶段。

So the the important bit was getting rid of that commitment round, but also the ceremony involved, multiple phases.

最初的仪式，也就是Sprout仪式，共有三个阶段。

So the original ceremony, the sprout ceremony, had three phases.

第一阶段是创建tau的幂次。

The first phase, you create the powers of tau.

所以你实际上是将不同单项式的求值和一个未知的τ编码到椭圆曲线群中。

So you're just in you're encoding some evaluation of different monomials and some unknown tau, into the elliptic curve group.

接着你进行快速傅里叶变换，突然间就具备了在群内创建这些插值多项式的能力。

Then you do a fast Fourier transform, and then all of a sudden now you have the ability to create these interpolation polynomials in the group.

然后你创建正确的插值多项式，再进行另一个阶段——引入几个额外未知数使协议完全按照SNARK需求运作，最后针对最初Zcash使用的SNARK还需完成另一个阶段。

Then you create the correct interpolation polynomials, and then you do another phase which sort of adds another several other unknowns in order to get the protocol to work exactly like the SNARK needs it, and then you had to do another phase in the case of, the the SNARK that we used for Zcash originally.

但后来出现了一种名为GROS 16的新型ZK SNARK，它效率更高，而且能非常简单地压缩成两轮协议。

But there was a new ZK SNARK called GROS 16, which or GROS 16, which, was more efficient, but also you could compact it into two rounds very trivially.

因此你将拥有一个可无限扩展的单轮设置，仅处理单项式，即原始的底层结构。

And so you would have a single round setup that could scale forever, which only dealt with the monomials, the original, the the kind of the bottom layer.

这有点像搭建蛋糕的底层部分。

It's kinda like building a cake or something, the bottom layer.

任何人都可以将其作为基础，来构建他们自己仪式所需的参数。

And anyone could use that as a basis to construct their parameters for their for their own ceremony.

实际上现在有个Rust库叫phase two，任何人都可以用它基于tau幂次进行多方计算，来创建自己的zk-SNARK公开参数。

So right now, actually, there's a a Rust library called phase two, which anyone can use to create their own z k snark public parameters with a multiparty computation using powers of tau as a basis.

我很好奇实际实现时，工作量在SNARK需求与其密码学部分，以及MPC部分之间是如何分配的。

I'm curious on, like, when it comes to actually implementing this, how much of the work is split between the requirements of the snark and, like, the the cryptography of that versus the MPC part of it.

比如参数生成占了多少工作量？

Like, yeah, like, how much of the work is generating parameters?

因为我们总看到，比如在Socrates里，你直接下载就行。

Because we always see, like, in Socrates, for instance, you can just download this.

你在本地电脑生成参数，对公开使用来说完全不够安全。

You generate the parameters locally on your computer, and it's totally insecure for public use.

但生成参数其实相当简单。

But generating the parameters are actually pretty easy.

然而当你想要通过多方计算安全地生成它们时，事情就变得极其复杂。

Whereas it seems like once you want to generate them securely in a multiparty computation, it becomes super complicated.

这是因为多方计算的特性，还是因为以这种方式扩展参数生成本身就非常复杂？

Is it that because of the multiparty computation or because scaling the like, the parameter generation in this way is so complicated.

比如

Like

这很复杂，因为多方计算本身在组织上就是一场噩梦，因为你需要协调各方。

It's complicated because the the multiparty computation itself is a logistical nightmare because you have to coordinate it.

你需要让人们参与进来。

You have to get people involved.

你需要实施它。

You have to implement it.

你必须确保它的安全性。

You have to make sure it's secure.

你可能需要编写多个实现版本。

You have to write multiple implementations maybe.

你必须完成所有这些事情。

You have to do all these things.

而且协议本身也相当耗费资源。

But also and then the protocol itself is is quite expensive.

此外，在多方计算中构建参数与在你自己的机器上进行单独设置构建参数存在很大差异。

But also, there's a big difference between constructing the parameters in a multiparty computation and and constructing them in a, kind of a solo setup that you do on your own machine.

区别在于，当你进行单独设置时，你知晓所有未知数，因此可以非常简单地评估所有多项式在这些未知点上的值，然后进行一系列——虽然计算量很大——但可以在群组中执行多点指数运算。

And the difference is when you're doing a solo setup, you know all of the unknowns, and so you can evaluate all the polynomials at at those unknown at those unknown points very trivially and then just do a bunch of I mean, they're expensive, but you can do a bunch of multipoint exponentiations in the group.

而在多方计算中则不然。

And in the MPC, you don't.

每个参与者都不知道其他人的秘密，因此每个人都必须重复相同的过程，但要处理大量不同的群元素，这使得整个过程变得非常耗费资源。

Every every person doesn't know every other person's secrets, and so they have to each person needs to do that same process, but with lots of different group elements, and it becomes really expensive in that respect.

这就是为什么在多方计算中进行这项操作成本如此高昂的原因。

So that's that's why that's why doing it in an MVC is really expensive.

是啊。

So yeah.

嗯。

Mhmm.

说到可信设置，你之前提到过，让这个过程变得更简单、更易用、整体上更好是你的目标之一。

So speaking of trusted setups, you you said earlier that, like, it was part of your goal to make this easier and more approachable and sort of better in general.

在你发明的其他技术中，还有Sonic，据我理解它的目标是进一步消除所谓的'可信设置'。

And down the line of other things that you've invented, there's Sonic, which is as far as I understand it, aims to get rid of, quote, unquote, the trusted setup even more.

虽然还是需要做设置，但现在可以适用于多个SNARK了。

You still have to do it, but now it applies to multiple snarks.

所以不需要为每个SNARK单独做设置了。

So you don't have to do an individual one for each snark.

我这样理解对吗？

Is that a correct description?

对。

Yeah.

所以我们最初的一个失误——用'失误'这个词合适吗？

So one of the follies of our original is folly the right word?

我不知道。

I don't know.

而我们最初仪式（Zcash那次及后续仪式）的一个缺点就是它专属于Zcash。

And one of the one of the downside of of, one of the downsides of the original ceremony that we did is Zcash and then the following ceremony was that it was specific to Zcash.

所以你无法直接复用那些参数来为自己的应用创建SNARK。

So you couldn't just take those parameters and create your own SNARC for your own application.

如果电路不同，你就必须创建新的参数，在自己的设置中创建新参数。

If your circuit was different, you had to create new parameter you had to create new parameters in your own setup.

所以人们真正需要的是通用参数。

So what what people really want are universal parameters.

这样由其他人完成可信设置后，大家都能在自己的项目中使用这些参数，无需自行举行仪式。

So someone else does the trusted setup, and then everyone can use those parameters in their project, and they don't have to perform their own ceremony.

我认为这将极大推动ZK Snark在社区中的使用。

I think that that would explode the usage of ZK Snarks in the community.

是的。

Yeah.

但实现这一目标确实充满挑战。

But getting there is really challenging.

所以在2018年，Jens Groth等人，包括Mary Mallor和Marco Polweiss等研究者，提出了一种通用参数的ZK-SNARK方案。

So in last year, in 2018, Jens Groth and others, Mary Mallor and Marco Polweiss and other people, came up with a universal parameter ZK snark.

这确实非常令人着迷。

And this was really fascinating.

遗憾的是，它的效率非常低下。

Unfortunately, it was really inefficient.

参数规模会随着支持语句的大小（以算术电路中乘法门的数量计）呈二次方增长。

The the parameters the size of the parameters, scaled quadratically with the size of the supported statements in in terms of the number of multiplication gates in the arithmetic circuit.

因此这完全不具备实用性。

So it's just totally inefficient.

而Sonic项目正是试图解决这个问题。

So with Sonic, we're just trying to tackle that.

我们正试图开发一种具有线性规模参数的方案，就像普通的可更新的ZKSnark一样，最终你会得到一个简洁的非交互式证明。

We're we're trying to come up with something that has a linear size parameter just like a normal ZKSnark that's updatable, and and you get a, you get a snark in the end.

这就是Sonic的全部意义所在。

And so that's that's all that Sonic's about.

这还有另一个非常棒的方面。

And there's another facet to this, which is great.

我们拥有通用参数，任何人都可以使用它。

We have a universal parameters, and anyone can use it.

如果能实现可更新性就更好了——新人可以加入贡献，提升安全参数，成为少数贡献者之一后立即退出，这个过程可以无限持续下去。

It'd be nice if it could be updatable in the sense that someone can join, contribute, and improve the parameters of security and be one of the few people who had contributed to its security, then leave immediately, and then people can do this forever.

因此这个仪式基本上永远不会结束。

So the ceremony basically never ends.

在这种情况下，它可以扩展到非常大规模的人群。你可以想象各种场景：人们可能作为合同义务参与贡献，或者出于某些要求，仪式还可以分叉，让人们以不同方式参与等等，这真的很有趣。

And in this case, it can scale to a very large number of people, And there's all sorts of settings where you could imagine people contributing as part of a contract or you could or or some requirement or or whatever or people the ceremony can fork off and people can contribute in different ways or whatever, which is really interesting.

我认为这最终会形成一种从根本上能达到的最高安全级别。

And it it leads to something I think is really fundamentally as secure as you can get.

一旦你拥有通用参数，这几乎是自然而然的结果，因为至少对于ZK SNARKs来说，如果参数是通用的，它们很可能是单项式，而这些单项式在设置过程中很容易更新。

And it kinda comes naturally once you have universal parameters because, at least for ZK SNARKs, if your parameters are universal, they're probably monomials, and monomials are easily updatable inside of, these setups.

因此，Sonic是一个通用且可更新的设置，其参数大小呈线性，最终你会得到一个ZK SNARK。

So, Sonic is a universal and updatable setup where the parameters are linear in size, and, you get a ZK SNARK in the end.

你刚才把Sonic称为一个设置。

You you refer to Sonic there as a setup.

那么Sonic是唯一可信设置的部分吗？还是你需要不同的SNARK？

So is is Sonic the only the trusted setup part of this, or do you need, like, a different SNARK?

我有点好奇这部分具体指什么。

Like, I I'm kinda curious where that lives.

它是SNARK和可信设置之间的重叠部分，还是仅仅是一个可信设置？

Is it is it sort of an overlap between a snark and the trusted setup, or is it only a trusted setup?

界限很模糊。

It's blurry.

Sonic是一个ZK SNARK，带有

So Sonic is is a ZK snark with

好的。

Okay.

一种恰好具有线性规模、可更新且通用的特定设置。

A certain setup that happens to be linear in size and updatable and universal.

明白了。

Got it.

但SNARC要求中的可更新和通用特性是Sonic的固有特性，这正是我们开发Sonic的原因。

So but that that updatable and universal part of the requirements of the SNARC is inherent to this is why we built Sonic.

我们当时正试图实现一个仅需线性规模、可更新且通用参数的SNARC。

We were trying to get a SNARC which only required universal and updatable parameters that were linear in size.

对于那些已经实现了某种形式SNARK（可能来自库）的团队，他们需要做哪些改动？

For those for those groups that have already been that have already implemented some form of SNARK that is maybe from a library, what do they have to do to change that?

他们需要重新部署整个系统吗？

Do they have to re redeploy the whole thing?

他们能否复用部分现有组件？

Do they can they use pieces of it?

一般来说，如果你已经使用了一个ZK SNARK，想迁移到另一个ZK SNARK，那你就完蛋了。

So in general, if you have a ZK SNARK, that you've already used and you want to move to another ZK SNARK, you're you're screwed.

你得... 对。

You have to Yeah.

要么重新做设置，要么彻底修改协议。

Do a new setup or you have to change your protocol completely.

根据你之前的选择，可能连椭圆曲线都得换。

You might even need to change elliptic curves depending on what you did.

所以确实有很多...

So there's a lot of yeah.

会变得一团糟。

It gets messy.

但Sonic你提到了这种可升级性。

With Sonic, though, you sort of mentioned this upgradable upgradability.

你指的是这个意思吗？

Is that is that what you mean?

是不是说，如果你有Sonic，就能像升级一样更换你的snark？

Is that like, if you then had Sonics, would you be able to up like, change your snark?

很多人听你描述Sonic时，会误以为这是可更新的设置。

A lot of people, when you describe Sonic to them, they think, oh, it's updatable setup.

他们以为更新参数后，安全性会突然提升，之前构建的所有证明都会因为我的参与而变得更安全。

That means when I update the parameters, I can all of a sudden, they're more secure, and then all the all the proofs that were constructed before, I know that they were secured because I contributed.

但事实并非如此。

It's not like that.

证明是使用特定时间点的参数构建的。

Proofs are constructed using the parameters as they were at some point in time.

如果你更新参数，确实提高了安全性，但之前构建的所有证明完全不会受益于你的贡献。

And, if you update the parameters, you're making them more secure, but all the proofs that were constructed before do not leverage your contribution at all.

所以可更新性的本质其实是扩展参数构建流程，使其能支持数百人参与和高质量贡献。

So updatability is really fundamentally about scaling the the the process of constructing the parameters so that it can support hundreds of people and very high quality contributions.

但我觉得问题还在于：更新时能否同时切换到不同的电路？

But I think the question is also, when I update, can I change to a different circuit at the same time?

是的。

Yeah.

至少在Sonic中这是通用的，因为它是通用参数，你可以随时切换电路。

So with with the it's universal for at least for Sonic, because it's universal parameters, then you can you can switch circuits anytime you want.

对。

Yes.

我也喜欢可升级性这一点，从避免阴谋论者的角度来看。

I like the upgradability aspect as well from the point of view just avoiding tinfoil hat people.

因为如果有人过来说，不。

Because if someone comes along and says, no.

我不信任这400个人。

I don't trust these 400 people.

他们都串通好了。

They all colluded.

那个人可以自己参与仪式，亲自完成工作，并相信自己没有欺骗自己，因此现在更安全了，他们可以信任这个东西。

That person can themselves enter into the ceremony at that point and do the job themselves and trust that they didn't lie to themselves, and therefore, it's now more secure and they can trust this thing.

当然。

Sure.

是的。

Yeah.

没错。

Exactly.

我刚意识到我们一直在交替使用'可更新'和'可升级'这两个词。

We keep I I just realized we keep switching the word updatable and upgradeable.

正确的术语是什么？

What is the right terminology?

可更新的。

Updateable.

可更新的。

Updateable.

好的。

Okay.

我们别把外面的人搞糊涂了。

Let's just not confuse people out there.

我一开始就说错了。

I I said it wrong the first time around.

据我所知，Sonic（音速）某种程度上是从你们为sapling升级所做的工作中发展出来的。

So so from what I understand, Sonic kind of Sonic grew out of what you had the work you had put in for the sapling upgrade.

你们某种程度上已经扩展并加入了更多参与者进入第二阶段的信任设置。

You had sort of already extended and and added a lot more participants into that sort of second trusted setup.

然后我猜你们由此意识到，哦，我们还能做得更多

And then I'm guessing out of that, you realized, oh, we could do even more

是的。

Yes.

所以

So

这个新设置。

this new setup.

在Sapling阶段，我们进行多方计算来构建参数时，分为两个阶段。

With with the Sapling, multiparty computation that we performed for constructing the parameters for Sapling, We had two phases.

第一阶段是将这些单项式嵌入参数中，第二阶段是实际构建多项式，再添加一个未知数，最终得到参数。

One where you can where you embed these monomials into the parameters, and then one where you actually construct the polynomials, and then you add another unknown, and then you get your parameters.

我想消除的就是第二阶段，因为无论哪个阶段都可能无限期运行，从而获得可更新的效果。

What I what I wanted to get rid of was that second phase because either of the phases can run indefinitely, and and so you get that updatable effect.

如果去掉包含特定电路多项式的第二阶段，还能获得通用效果。

You also get the universal effect if you get rid of the second phase that's has the polynomials that are specific to your circuit.

实际上，Sonic的目标是——这也是Sonic之前论文的初衷——就是要去掉第二阶段，只留下一个ZK snark，它只需要嵌入在群中的单项式。

So, really, the goal of Sonic was to and and and this was the goal of of paper preceding Sonic was to get rid of that second phase and just have a ZK snark that only required monomials, for example, that were embedded in the group.

很多非常聪明的人提出了各种技术方案，我们基本上就是把它们拼凑在一起，想办法让它运作起来。

So a lot of really clever people came up with, techniques, and we sort of just, jammed them together to figure out how to get it to, to to work.

其实我们还有听众提出的几个相关问题。

So we actually had a few other questions from, our listeners on this.

我们收到了Georgios Constantopoulos的提问，他想知道你们目前是否正在研究进一步改进sonic协议的方法。

So we had one question from Georgios Constantopoulos who is asking if there are, like, further steps to improving the sonic protocol that you're working on right now.

我并没有在正式推进什么项目，只能说在尝试。

I'm not working on any well, I'm trying.

你懂我的意思吗？

You know?

你是在尝试不去推进它，还是在尝试推进？

You're trying not to work on it, or you're trying to work

是在尝试推进它。

on I'm trying to work on it.

我正在尝试提出新想法但屡屡失败，不过有很多其他人提出了非常棒的方案——虽然方向不同，但这些方案确实能优化Sonic协议。

I'm trying to come up with ideas and failing, but there's a lot of other people that are coming up with really good ideas that are kind of orthogonal, but they'll they'll be able to improve Sonic.

其中有件事让我特别兴奋——

One of the things I'm really excited about is okay.

有些团队在努力提升Sonic的效率，同时还有sharks zk协议，这些像子弹证明一样有趣的轻量级snarks，不需要强假设条件就能完成设置，某种意义上还附带snark特性。

So there are there are people trying to make Sonic more efficient, but then there's also sharks, z k sharks, which are these fun fun little snarks, which are kinda like a bulletproof, so it doesn't require strong assumptions in a setup and a snark attached to it in a sense.

我这是过度简化了。

It's I'm oversimplifying.

这些snark鲨鱼？

The snark sharks?

它们就叫鲨鱼。

They're called sharks.

是的。

Yes.

太神奇了。

That's amazing.

而且非常刻意。

Very deliberate too.

Bulletproofs和snarks变成了鲨鱼。

Bulletproofs and snarks become sharks.

没错。

Right.

所以附着在bulletproof上的snark就是用来证明这个bulletproof已被验证过。

So so the snark that's attached to the bulletproof just proves that the bulletproof has been verified.

因此，与其验证可能成本高昂的防弹证明，不如验证简洁非交互式知识论证（snark），这样效率极高。

So instead of verifying the bulletproof, which could be expensive, you verify the snark, and it's really efficient.

如果有人验证防弹证明时失败，而snark验证却成功了，那就说明可信设置是失败的。

And if someone verifies the bulletproof or and if and verification fails and the snark verification succeeds, then you know the trusted setup was a a failure.

你可以把这个结果交给别人并说，嘿，

And so you can give that to someone and say, hey.

看看这个，

Check it out.

可信设置失败了。

The trusted setup failed.

所以我认为这实际上几乎可以消除大多数我能想到的应用场景中对可信设置的需求。

So I think that this is really a and almost obviates trusted setups for most applications that I can think of.

确实存在一些仍需使用snark的应用场景，你可能从防弹证明中得不到任何好处，或者防弹证明部分效率太低等等。

There's there's some applicate applications where you still need snarks, and you probably don't get anything from bulletproofs, and also maybe the bulletproof part of it is too inefficient or whatever.

不过，我认为鲨鱼（sharks）这个概念真的非常非常酷。

But, I think that sharks are really, really cool.

我认为人们会希望看到鲨鱼使用像Sonic这样的可更新通用参数。

And I think people will want to see sharks using updatable and universal parameters like sonic.

所以有鲨鱼加Sonic的组合。

So there's sharks plus sonic.

超音速鲨鱼，我不知道，最终会出现

So supersonic sharks, I don't know, will eventually show up

在某个时候。

at some point.

实际上是的。

And Actually Yeah.

你刚才提到的一点，正是我这期节目想探讨的话题。

So something you just touched on, and a topic I definitely wanna get to in this episode.

你刚才简单提到过，通过这些鲨鱼，你可以检查。

You just sort of mentioned this, like, with these sharks, you can check.

你可以检查可信设置是否失败或已被攻破。

You can check if the trusted setup has failed or been compromised.

从某种意义上说，这引出了你之前在本集中提到的一个话题，但我觉得讨论起来会非常有趣，那就是那个漏洞。

And this, in a way, kinda leads into a topic that you mentioned earlier in the episode, but I think it would be really interesting to talk about, and that is the bug.

这么说对吗？

Is that the right way of saying it?

你称它为漏洞吗？

Do you call it a bug?

这是Zcash之前一篇论文中存在的根本性密码学错误。

It was it was a fundamental cryptographic mistake inside of an a paper that precedes Zcash.

所以我称之为BCTV14漏洞或BCTV14错误之类的。

So I would call it the BCTV 14 bug or BCTV 14 mistake or whatever.

某种类型的错误。

Error of some kind.

这个漏洞其实与可信设置无关吧？

This bug, did it like, it didn't really have anything to do with the trusted setup, though, did it?

你们做的可信设置某种程度上算是成功的吗？

Like, was the trusted setup that you did was successful in a way?

比如，那些‘有毒废料’并没有被发现。

Like, that that toxic waste was not discovered.

没错。

Right.

可信设置的目标是为zk-SNARK构建参数，确保某些变量对所有人都是未知的，并且这些变量会被永久销毁。

So the goal of the trusted setup is to construct parameters for the z k snark such that certain variables are unknown to anyone, and they're destroyed forever.

当然，这个‘永久’是指直到量子计算机出现之类的。

Well, forever until a quantum computer shows up or something.

所以，我认为我们成功实现了这一点。

So, we I think we successfully achieved this.

遗憾的是，描述zk-SNARK的论文要求作为参数的一部分生成其他一些东西，但实际上这些对证明者来说并非必要。

Unfortunately, the paper that described the z k SNARC said you had to produce some other things as part of the parameters, which actually weren't necessary, for the prover.

证明者在实际构造证明时并不需要它们。

The prover didn't didn't need them to actually construct proofs.

而我们却构造了它们，结果发现这些参数不仅不必要，甚至情况比不必要更糟糕。

And so we constructed them, and then it it ended up being that they are actually not even it's worse than not necessary.

它们实际上破坏了证明系统的可靠性。

They they actually break the the soundness of the proving system.

所以我们当时没有意识到这一点。

So we weren't aware of this.

我认为如果没有那个错误，仪式在某种意义上会是成功的，因为它能生成安全的参数。

I think if that mistake wasn't there, then the ceremony would would be a success in the sense that it would produce secure parameters.

但我认为第一次仪式确实成功地为一个有缺陷的ZK SNARK生成了参数。

But I I think the ceremony the first ceremony, I'm sure, was successful in producing parameters for a broken ZK SNARK.

不过确实如此。

But yeah.

没错。

Right.

哇。

Wow.

原来是这样。

So that's what it was.

更像是额外产生了一些东西，而你们认为这些东西完全无关紧要。

It was more just like there was extra something extra produced, which you didn't think would be in any way relevant.

那么这个错误是不是指，那些额外的东西可能以某种方式被利用？

And then was was the mistake that, like, that other extra stuff could be used in some way?

是的。

Yeah.

我想我们把这些东西称为‘绕过元素’，因为我们想不出更好的名称了。

So I think we call the we call these things we call them bypass elements because we couldn't come up with anything better than that.

但这些被生成并存在于参数中的元素，能让你绕过所有验证，任意伪造证明。

But there are these elements that are produced, and and exist in the parameters that allow you to bypass everything and just create a false proof, arbitrarily.

你可以把这些绕过元素想象成另一个本应销毁的后门，除了那些已知需要销毁的后门之外。

And you could really think of the bypass elements as a as another trapdoor that you should have destroyed in addition to the existing trapdoors that you knew you should have.

你也可以称它们为‘有害废物’，不过我个人更倾向于叫它们‘绕过元素’。

So you could call them toxic waste as well, but I just call them bypass elements, I guess.

你们是否需要像处理有害废物那样，全部销毁这些绕过元素？

Would you knee would you have needed all of them, like, in the same way with the toxic way?

比如，是所有这些组合在一起才会变得危险，还是这些旁路元素实际上是最后才出现的？

Like, was it only in the combination of all of it that it would be dangerous, or was this, like, actually a was were these bypass elements something that actually came out at the end of it?

对。

Right.

它们出现在最后阶段，是设置过程的一部分。

They're they're at the very end, they appear in as part of the setup.

实际上libsnark的实现删除了这些元素，因为验证者不需要它们，但它们被定义为设置过程中构建的内容。

Now it happened to be that the implementation of libsnark deleted these elements because they weren't needed by the prover, but it was defined as something that was constructed during the setup.

因此MPC生成后又删除了这些元素，因为Libsnarc的证明器需要移除这些元素才能正常工作。

And so the MPC produced it and then deleted it because Libsnarc's prover needed, these elements to be, removed so the prover would work correctly.

所以我们最初做的MPC，其记录中包含了这些元素——我说的这些旁路元素，它们位于记录的开头、中间或某个位置，这些元素可被用来伪造证明。

So the MPC that we did originally, there was a transcript that contained these elements, these bypass elements I'm speaking of at the very, or in the middle of the transcript somewhere, and these elements could be used to create false proofs.

那你们是怎么发现这个问题的？发现后又发生了什么？

So how did you guys discover this, and what what happened after they you discovered it?

内部是怎么...你知道，当发现这个问题后，你们...

What was the internal you know, this is found and then, you know, what do

你们做了什么？

you do?

事情是这样的，我当时在参加金融密码学会议。

So what happened was I was at, Financial Cryptography.

这个会议还有Ariel Gavazan和Zuko参加，这非常有用，因为当我们发现如此严重的漏洞时，能有这两个人在同一会议现场，对正确修复漏洞可能起到了至关重要的作用。

This is a conference along with Ariel Gavazan and Zuko, which is really useful because having those two people at the same conference at the same physical location when we discover such a critical bug was probably incredibly important to actually mitigating the bug correctly.

当时我正在这个会议上，Ariel有时会发消息问我，嘿。

So I was at this conference, and Ariel will sometimes message me and say, hey.

我发现Zcash有个地方看起来不太对劲。

I found a a thing that seems weird about Zcash.

这是不是出问题了？

Is this broken?

我会回答，不是。

I'll say, no.

因为这样或那样的原因，这不是问题。

It's not because of this or that.

然后他告诉我他在论文中发现的那个漏洞，我当时有点怀疑。

And then he told me about this bug that he had spotted in the in the paper, and I was a little suspicious.

我不得不回忆这个机制是如何运作的，所以我就说，不。

I wasn't I had to remember how this thing worked, and and so I was like, no.

我是说，这是一篇老论文了。

It's I mean, this is an old paper.

它发表于2014年。

It's from 2014.

这可能没问题，但我想我还是会查一下。

This is probably okay, but I'll check it out, I guess.

我当面见到他并确认了这个漏洞确实存在。

And I met him in person and confirmed that the bug was real.

于是我打电话给Zuko，我说，嘿。

So I I called Zuko up, I said, hey.

你需要尽快赶回酒店。

You need to get back to the hotel as fast as you can.

情况紧急。

It's an emergency.

而且显然，他以为我指的是有人被绑架之类的事。

And, apparently, he thought that I meant that someone had been kidnapped or something.

所以他让酒店叫了保镖之类的人来查看我们的情况。

So he asked the hotel to ask bodyguards or something to come and check us out.

但其实不是，只是Zcash的证明系统出了问题，如果有人能获取原始协议中产生的这份记录，他们就能无限伪造代币。

But but, no, it was it was just that the Zcash proving system was broken, and and people could counterfeit coins infinitely if they had access to this this transcript that was produced in the original protocol.

所以当祖科来和我们见面时，我们决定删除这份记录。

So when Zucco came and met with us, we decided to delete this transcript.

它原本是公开可查的。

It was publicly available.

直接删除就好，这样就没法——其实下载过的人也不多，大概就十几个吧。

Just delete it, and then no one can there weren't very many people that downloaded it, maybe, like, a dozen.

所以你就把它删了。

And so you delete it.

没人能利用这个漏洞。

No one can exploit it.

我笔记本上存了一份副本，后来也删除了。

I had a copy on my laptop, which we eventually deleted.

在这个过程中，我们想出了暗中修复Zcash漏洞的方法——因为如果公开宣布，我们无法确定有多少人下载了文件或是否被存档。

But and in the process, we come up with some way to actually fix the bug in Zcash covertly because if you tell everyone, then who know we didn't know that there was very few people that downloaded it or where it was or if it was archived.

所以我们担心一旦公开，可能有人会在我们修复前利用这个漏洞。

So we were worried if we went public with anything that someone would exploit it in Zcash before we could patch it.

于是我想出了暗中修复方案：借助Sapling升级的新参数设置来替换旧系统的破损参数。

So I came up with a way to patch it covertly in Zcash by using our new setup to the new setup for the Sapling upgrade to actually replace the parameters for the old system that were broken.

这个方案有合理说辞，所以除了我们三人和Nathan Wilcox（Electric Coin公司的CTO）外无需告知其他人。

And so we did this, and we were able this this had a convincing explanation, so we won't didn't need to tell anyone besides us three and the and Nathan, who's a CTO of of Nathan Wilcox, who's CTO of Electric Coin Company.

我们甚至不用告诉其他四位成员，包括工程师和密码学家，因为这个方案表面上有合理解释。

We didn't have to tell Beyond Us four about this issue, none of the engineers or cryptographers or anyone, because it had an an explanation, so to speak.

最终我们成功修复了漏洞。

So we were able to patch it.

一旦完成修补，接下来就是要为所有受此影响的其他加密货币也进行修复。

And once it was patched, it was a matter of fixing it for all of the other cryptocurrencies that were affected by it as well.

是的。

And yeah.

从发现漏洞到实际修补完成，整个过程耗时相当长。

The first, like, from discovery to actually patch, I mean, was quite a long time.

那段时间是不是一直处于恐慌状态？

Was that a time of just constant panic?

当时知道这件事的只有你们四个人吗？

Or what what was the four of you that knew?

你们当时的情绪是怎样的？

You what was the emotion there?

所以我觉得那一年里我可能老了十岁。

So I think maybe I aged ten years during that one year.

好吧。

Well, okay.

所以从发现漏洞到打补丁之间大约有八个月时间。

So it was about eight months between discovery and patch, I think.

原本没打算拖这么久，但中间出现了延误。

It wasn't intending to be that long, but there was a delay.

但必须对这样一个可能导致整个项目毁灭的漏洞保密，这真的非常非常困难——毕竟这个项目倾注了我们所有心血。

But having to keep such a bug secret, which, you know, could lead to the destruction of the project that you worked so hard on was really, really difficult.

所以每个人...每个人都从那段经历中获得了深刻的情感体验。

So everyone everyone had serious emotional takeaways from that experience, I think.

就我个人而言，2018年几乎没完成什么工作——虽然我确实在忙Sapling的设计开发之类的事。

I personally, I didn't get much done during 2018 because of I mean, I I was working on sapling and designing it and things like that.

其实我贡献的大部分Sapling功能都是在2017年完成的，包括具体实现。

I had done most of the sapling stuff that I contributed to in 2017, the implementation.

2018年主要就是落实各项设计，完成仪式流程，反复检查代码和加密算法，确保不会再有漏洞。

And so in 2018, it was just about implementing things, finishing the design work, and doing the ceremonies and going through everything and making sure that there's not another bug or trying to make sure that there's not another bug in the in the code or something, or in the crypto.

那段时间确实...嗯。

So that was a really yeah.

那真是一段非常艰难的时期。

It was a really difficult time.

我记得这件事。

I remember it.

按我的理解，这个问题的修复是随着Sapling升级一起完成的——当Sapling升级发生时，这个问题就顺带解决了。

So as I understand it, the up the update or, like, the fix for this was part of the sapling I mean, when when the sapling upgrade happened, this issue was sort of, like, taken care of.

但我记得在ZCon Zero大会上，你们当时正在进行Overwinter更新之类的操作。

But I remember at ZCon Zero, you guys were doing this overwinter update or something.

那像是Sapling升级前的过渡阶段。

It was like a part of the sapling like, on the way towards the sapling update.

你们是当时修复的，还是后来才解决的？

Did you fix it then, or did you fix it later?

这个漏洞是在Overwinter升级前夕被发现的。

So the the bug was discovered just prior to the Overwinter upgrade.

准确地说，距离部署只剩一周左右的时间。

Literally, like, a week before it was deployed.

大概是这样

So or something like that.

所以我们没机会在Overwinter升级中实际部署缓解措施

So we didn't have a chance to actually deploy mitigation in Overwinter.

我们最终部署的实际缓解措施依赖于sapling升级

The actual mitigation that we did deploy depended on the sapling upgrade.

我们算是借机搭了便车，这样既能隐蔽处理，又能防止他人独立发现并利用这个漏洞

It was we we kind of piggybacked on it in order to make it covert so that people wouldn't independently discover and exploit the the bug.

所以，是的。

So so yeah.

作为Sapling升级的一部分，Overwinter升级主要是一个后勤性质的升级，旨在改进执行后续升级的流程——那时候我们还称之为硬分叉。

So as part of the sapling upgrade, overwinter upgrade was mostly a logistical upgrade that was intended to improve the process of performing another upgrade back when we used to call them hard forks.

我们曾称之为硬分叉零，但在Zcash社区中我们已不再使用硬分叉这个说法了。

We called it hard fork zero, but we don't call them hard forks anymore in in the Zcash community.

现在称之为网络升级。

Call them network upgrades.

明智的选择。

Wise choice.

我

I

明白了。

see.

我只是想，我猜大部分收听这期节目的听众，尤其是如果他们听过之前我们解释了很多关于可信设置的那些节目，以及我们讨论过Zcash整体模型的内容。

I just wanna like, I I imagine that people listening to this episode for the most part, especially if they've listened back to some previous episodes where we explained a lot of, you know, about trusted setups, and we, you know, where we talked about sort of the Zcash model in general.

就像，我们已经讲过这个漏洞利用意味着什么，但我觉得我还是想在这里再提一下。

Like, we we have covered what the bug exploit would mean, but I think it would I I sorta wanna just say it here.

比如，如果有人真的获取了那段信息，会发生什么？

Like, what what would have happened if someone had actually gotten that that piece of information?

他们需要做些什么才能实现你刚才描述的那种情况，比如在屏蔽账户中挖矿？

Like, what would they have needed to do to actually, what you just described, like mine in the shielded accounts?

所以利用这些绕过元素，你可以破坏证明系统的可靠性，从而构造虚假证明。

So so what you can do with these bypass elements, it breaks soundness of the proving system, and so you can construct false proofs.

那么你能用它做什么呢？

So what can you do with that?

嗯，你可以凭空创造大量货币，然后从受保护的池中取出，或者如果你想的话也可以留在池中，用来购买其他货币之类的东西，从而窃取所有人的资金。

Well, you can create a bunch of money that doesn't exist and then take it out of this shielded pool and, or or keep it in the shielded pool if you want and, use it to buy things like other currencies or whatever and, rob everyone of of their money.

所以如果有人能接触到这个，后果会非常非常危险。

So it's very very dangerous if someone had access to this.

我觉得

I think

他们其实不会真正实施盗窃。

They they wouldn't really rob.

对吧？

Right?

他们不会从其他受保护账户中取钱。

It's not that they would take out money from other shielded accounts.

他们只是会增发货币。

They would just print more.

对吧？

Right?

所以无法区分伪造的货币和真实的货币。

So there's no way to distinguish money that's been counterfeited from money that isn't.

因此，从某种意义上说，首先通过通货膨胀，你实际上是在窃取他人的价值。

And so as a result, in some sense well, first off, by inflation, you're you are in some sense robbing value from other people.

但从另一个角度看，因为你可以动用所有这些钱，而伪造者又无法被识别，系统中诚实的参与者看起来都像潜在的伪造者，你无法分辨谁的钱是真的。

But in another sense, because you can take all this money and then the counterfeiter isn't distinguishable, the the honest participants of the system look like potential counterfeiters and who whose money is real, you don't know.

所以这真是个大麻烦。

So it's a it's a it's a big mess.

实际上，旋转门机制已经解决了大部分问题，因为你可以看到有多少代币从Sprout转移到了Sapling，并且记录了有多少代币被创建。

The, the turnstile actually addresses most of this in that you can see how much how many tokens have moved from Sprout to Sapling and you have an account of how many tokens have been created.

因此，如果Sapling中的代币数量没有超过历史创建总量，情况看起来就是正常的。

And so you know that if there aren't more tokens in Sapling than have ever been created, then things seem good.

问题在于，你不知道是否有人在Sprout中囤积了大量代币，只是在那里等待时机。

The problem is that you don't know if someone is sitting on a huge stack of coins in Sprouts just kinda waiting around.

比如说，我不知道他们在那里拿着那些币能干什么。

Like, I don't know what they would do with those there.

但是

But

所以造假者会兑换他们的钱。

So so counterfeiters exchange their money.

他们就是这么干的。

That's what they do.

如果有人在造假，最终会被发现，因为总会有人将钱从废料区转移到树苗区，而转移的金额会超出应有数量，这样就会被察觉。

They and so so if there's more, if there's if someone's counterfeiting, it will be discovered because someone will have moved their money from scrap to sapling at some point, and there was more money being moved than there should have been, and so you'll discover it.

也可能存在一种旋转门检测不到的造假者——比如只伪造特定数量假币，并且只将其中的一小部分兑换成其他货币之类的造假者。

You could also have a counterfeiter potentially who this this turnstile that it doesn't detect, like a counterfeiter that only creates a certain amount of counterfeit funds and only takes a certain a small amount of it out and exchanges it for another currency or whatever.

而且，这个伪造金额恰好小于整个网络参与者因私钥丢失等原因造成的损失金额时

And, it's that that amount happens to be less than the amount that is lost, for example, by all the participants in the network because people lose their private keys or they

确实。

just Yeah.

随便吧。

Whatever.

所以你完全可以做到不被发现。

So you could you could totally do it undetected.

其实今天我也不确定萌芽屏蔽池里有多少代币，但我认为从未有人利用过这个漏洞，因为任何理性的造假者——理性但邪恶的造假者——可能会一次性尽可能多地套现而不被发现。

I think today actually, I'm not really sure how many coins are in the sprout shielded pool, but I I don't think it was ever exploited because I think any rational counterfeiter, rational but evil counterfeiter would, probably just take as much money as they could possibly sell at a time without being detected or something like that.

感觉他们会试图把代币转移到新芽池，成为第一个转移并抛售的人。

It feels like they would try to move the tokens over to, Sapling as like, be the first to ever move it over and then sell it.

因为这样一来，他们被发现的间隔时间就更长。

Because, like, then they they have a longer time before they get detected.

而当那些动作慢、不一定紧跟协议发展的老实人开始转移代币时，最终会有正经用户转移代币导致账目失衡。

Whereas this once the legit people, you know, who are slow and don't necessarily follow all protocol developments start moving their coins over, eventually, some legit person moves their coins over and the the balance tips over.

对吧。

Right.

但那个邪恶的首发者早就转移并抛售了全部代币

But the the the first guy, the evil guy, has already moved all their tokens and maybe sold them on

在交易所上。

an exchange.

因为坏人可以想造多少就造多少。

Because the evil guy can make as many as they want.

我认为坏人最理性的做法就是一旦发现漏洞并能够利用，就立即开始伪造。

I think the the rational thing to do for the evil guy is to literally counterfeit as soon as you discover the the vulnerability and are able to exploit it.

尽可能多地伪造货币，并在不被交易所发现的情况下以最快速度卖出。

Literally counterfeit as much money as you can possibly counterfeit and sell it as fast as the exchanges, will allow you to do so without being detected.

而这种情况根本没有发生过。

And I that didn't happen at all.

因此，结合其他一些原因，我相当确信从未有人独立发现过这个漏洞，也从未有人利用过它。

So I'm pretty convinced on top of some other reasons, that that no one ever independently discovered it and that no one ever exploited the vulnerability.

现在为了明确起见，听起来世界上仍然存在一个sprout设置。

If this is so now just to to be clear, it sounds like there's still a sprout setup that exists in the world.

正如你提到的，这就像是一个分叉。

Because as you mentioned, it's like a fork.

对吧？

Right?

所以Sprout版本还在某个地方存在。

So there still is sprout somewhere.

然后还有Sapling的分叉或更新升级。

And then there's the Sapling fork or update or upgrade.

但有没有人能在事后利用这一点，并设法将其转移？

But could somebody actually exploit this after the fact and somehow move it over?

比如，如果有人还在使用Sprout版本，而现在这一切都已公开，他们能否利用这一点以任何方式影响新链？

Like, if somebody's still working in the Sprout version and they like, this has all been published and it's out there now, could they use this and in any way affect the the new chain?

在Zcash中不行。

So not in Zcash.

这就是Sapling升级中包含的缓解措施的全部目的——彻底阻止人们这样做。

That was the whole purpose of the the mitigation that was included in in Sapling was to prevent people from doing this entirely.

在其他仍基于Sprout的加密货币中（虽然不多，但确实有几个），确实存在利用这一点伪造资金的方法。

In other cryptocurrencies that still are based on Sprout, which there aren't very many, but there's a couple, then, yes, there is there is a way to exploit that to create counterfeit funds.

我们尝试向——我是说，你不可能向所有这些项目都一一披露，嘿。

We tried to disclose to I mean, you can't disclose to every one of these projects, hey.

这里有个漏洞。

Here's this bug.

你得有所选择，判断哪些团队足够可信，可以告诉他们，嘿。

You have to kinda pick and choose, who you think is is trustworthy enough to tell them, hey.

这里存在漏洞。

There's a bug.

你们需要修复它。

You have to fix it.

因此我们在公开披露前（大概是二月份公开的），选择了Zcash以外的几个项目让他们修复，作为我们披露流程的一部分。

And so we chose a couple projects outside of Zcash and had them fix it, as part of our disclosure process before we went public, in in February, but or whenever we went public.

不过确实如此。

But yeah.

我记得是二月份。

I think it was February.

但不是。

But no.

但我的意思是，你提到了这个迁移。

But what I mean is you sort of mentioned this movement.

就是说，你需要将资金从Sprout转移到Sapling。

Like, you have to move your funds from Sprout to Sapling.

Frederick，你提到过这个，就是那个转门机制。

Frederick, you said this, the turnstile.

但是，Sprout交易现在已经无效了。

But, Sprout transactions are not valid anymore.

所以你现在可以生成一个Sprout交易，但

So you can, like, generate a Sprout transaction today that

好的。

Okay.

是的。

Yeah.

明白了。

Got it.

顺便说一句，肖恩，这真的很有趣，非常感谢你分享这些经历，我能想象那一定相当痛苦。

It's so by the way, Sean, this is really interesting, and thank you so much for sharing this stuff with you because I can imagine it was quite traumatic.

所以，真的非常感谢你能来分享这些。

So, yeah, really thank you for for kind of coming on and sharing that.

挺好的。

It's nice.

实际上，谈论这些某种程度上具有疗愈效果。

It's kind of, therapeutic, actually, to talk about.

哦，很高兴听你这么说。

Oh, I'm glad to hear that.

好的。

Cool.

实际上，这让我想到了下一个问题。

Actually, that sort of leads me to the next question.

现在时间已经过去了一些，回头来看，你对此的主要收获是什么？

Now that some time has passed though, like, what's your what's your takeaway looking back on this?

嗯，这个嘛

Well It's

某种程度上，你总是可以说，比如，你必须更努力地工作。

sort of like, you can always say, like, you have to work harder.

你必须更仔细地观察，但是，确实存在人为失误。

You have to look closer, but, like, there is human error.

是的，确实存在这种情况。

There is it is yeah.

我只是好奇，你对这个怎么看？你是怎么想的？

I'm just curious, like, how do you like, what what do you think of that?

我的意思是，我不会用'你必须更仔细看'或者'你必须怎样'来回答。

So I mean, I I I won't I won't answer with, oh, you have to look harder, you have to whatever.

但我会回答，这恰好发生在我们没有重新实施的那个环节上。

But I will answer with it this happened to be in the one spot where we didn't reimplement it.

我们重新实现了之前学术原型中几乎所有的内容，包括Zcash的所有代码。

We reimplemented almost everything of the academic prototype that was before us, all the all the all the code for Zcash.

但我们唯一没有处理的就是ZK SNARK的这个具体部分。

But the one thing that we didn't tackle was the this actual this spot of the ZK SNARK.

所以如果我们当时处理了这部分，我想我们本可以发现这个问题，或者改用其他ZK SNARK方案之类的。

And so if we would have done that, I think that we would have discovered it or switched to a different ZK SNARK or something like that.

但我们当时资源有限，所以就决定直接使用它。

But we were resource constrained, and so it was just a matter of, you know, use it.

这个协议已经推出几年了，所以某种程度上是可信的。

This this protocol was out for a a couple years, so it was somewhat trustworthy.

已经有人研究过它。

People had looked at it.

还有人基于它开发了其他同样存在缺陷的协议。

People had based other protocols on it that were also broken.

这些我们当时并不知道，这确实是个不幸的失误。

So which we didn't know, but it was just it was just a an unfortunate mistake.

我不知道除了投入更多资源和人力预防之外，还能怎么解决这个问题。

I don't I don't know that you can't really address it much except adding more resources and more people to prevent it.

嗯。

Yeah.

说到重新实现这类事情，我们Parity正在与Zcash基金会合作开发Rust版本的Zcash实现。

Speaking of reimplementing things and sort of on this line, I mean, we at Parity are working with together with the Zcash Foundation to write Rust implementation of Zcash.

虽然并非完全重写所有部分（我们仍在使用Bellman），但我们之前已经重写过比特币实现。

And while it it's not reimplementing everything, we're still using Bellman, but we've reimplemented Bitcoin since before.

对于这种基金会和公司各自维护不同实现的情况，你怎么看？

What's your take on this sort of having multiple implementations and the foundation having one implementation and the company having one?

这是好事还是坏事？

Is this good or bad or,

嗯。

Yeah.

我想问的是，你具体从事哪个领域？

I think for What's your field?

在货币领域，拥有多种实现方案是非常好的。

Currencies, having multiple implementations is great.

这很可能会增加人们在其中某个实现中发现致命漏洞的概率，我认为。

It will very likely increase the chance that someone will discover a fatal bug in one of the implementations, I think.

多重实现对于几乎所有我能想到的事物来说通常都是件好事。

Multiple implement implementations is generally a good thing for almost every everything that I can think of.

是的。

Yeah.

这也很耐人寻味，就像某种轮回。

It's interesting too, like, that it comes back.

挺有意思的。

It's funny.

其实在这次访谈前半段，我们就讨论过学术型实现与工程型实现的话题。

And so in this interview earlier on, we were just talking about this academic academic implementations and sort of the engineer implementations.

正如你所说，除了那部分你们尚未重构的内容外，其他每个环节都...

And as you described, it was like every piece except for that that you hadn't redone or whatever.

这是在未重做的版本中发现的。

This was found in the in the one that wasn't redone.

你觉得这可能就是解决方案吗？弗雷德里克，就像你提到的，让人们多次重写所有内容似乎是确保安全的最佳方式。

And do you think that that maybe is the solution to have this is kinda going to your point, Frederic, that like just reimplementing, just having people rewrite everything multiple times is sort of the the best way to assure it's safe.

这是一种方式。

It's it's one way.

显然，拥有可验证的正确代码是另一种方式。

Obviously, having verifiable verifiably correct code is is another way.

但我想说的是，学术代码的编写是为了推出原型，以便向期刊或会议提交论文时声称你有一个实现。

But I think the the point I'm making is that the academic code was written to get a prototype out so that you could tell the journal or the conference that you're submitting your paper to that I have an implementation.

它不是为了承载数十亿美元的价值而设计的。

It wasn't, I want to put a billion dollars on top of this implementation incorrect.

我们发现学术原型中还存在其他致命错误，不仅在代码中，也在加密算法中，但我们已经替换了这些部分。

So going we found other fatal bugs in the the academic prototype of even in just the code, also in the crypto, but even in just the code, which that that we replaced.

所以我认为，如果要使用学术原型，你不仅需要精通加密算法，还需要彻底废弃所有旧代码，因为学术原型中充满了错误。

And so I think it's if you're gonna use academic prototypes, you really need to just you need to master the crypto, and you also need to completely destroy all the old code because academic prototypes are laced with with mistakes.

这并不是因为学术界的人——我不是在责怪任何人。

It's it's it's not because the academics are there's an I'm not trying to blame anyone.

只是学术界的人都在创建原型。

It's just that's the the academics are creating prototypes.

他们甚至会在README文件的最顶部写明。

They're they're literally putting at the top of their readmes.

“看在上帝的份上千万别用这段代码”。

Do not use this code for the love of God.

“你会把一切都搞砸的”。

You're going to you're going to screw everything up.

“求你别用”。

Please don't don't.

“求你了”。

Please.

所以我们真的需要在学术代码进入生产环境前彻底重写它们

So it's really we we need to destroy all academic code before it ends up in production.

我认为仅此一项就能让事情变得更高效一些。

I think that that alone will help make things a little more efficient.

有更多人参与代码工作也是件好事。

It's also nice to have more people tackling the code.

每次你重新实现某个功能时，有人就能深入了解代码的每个方面，从而能识别出错误和问题之类的。

So every time you reimplement something, someone learns every facet of the code, and so they can identify bugs and mistakes and stuff.

所以我想，这两方面都有一点吧。

So there there's a bit of both, I guess.

还有另一个我非常感兴趣的工作领域是你研究过的BLS12-381曲线和Job曲线。

There's another area of work that I'm very interested in that you've worked on, and it's BLS twelve three eighty one, the curve and the job job curve.

而且它也处于工程与学术的交界地带。

And it's it's on this boundary of engineering and and academia as well.

我一直以为这是某个密码学研究者坐在扶手椅上设计的椭圆曲线，但实际是你在创造它们。

Like, I always thought it was a crypto researcher somewhere sitting in their armchair designing this elliptic curve, But here you are making them.

那么，设计和制作一条椭圆曲线需要考虑哪些因素呢？

Like, what goes into designing and making an elliptic curve?

说实话，BLS12-381这条源于椭圆曲线的曲线能发展成如今进行椭圆曲线配对相关操作的首选曲线，这让我有点意外。

So I'm actually a little bit surprised that BLS twelve three eighty one's, which is appearing from the elliptic curve, is actually has grown into this really popular elliptic curve for doing anything regarding elliptic curve pairings.

最初我们只是想设计一条比现有曲线更安全的曲线，因为我们当时Sprout系统中使用的曲线面临某种潜在攻击（虽然目前还无法实现），理论上未来如果有人找到方法，其安全性可能只有100比特甚至更低。

Originally, we were just trying to come up with a curve that was more secure than the curve that we currently had because the curve that we current the the the one that we had in Sprout under some attack, which isn't possible yet, but theoretically, in in the future, if someone figures out a way to do it, it would have a 100 bits of security or less than a 100 bits, something like that.

我们想设计一条在保持效率的同时，安全性略高于原有曲线的方案。

We wanted to make a curve that was a little bit more efficient than that or, sorry, a little bit more secure than that without losing the efficiency.

于是在Sprout升级完成后，我研究了现有曲线的分类体系和各种设计约束条件，最终设计出符合我们所有需求的方案。

And so we and so I I just after the sat Sprout upgrade, I just looked at the, taxonomy of available curves and, the different design constraints and came up with one that kind of fit all the pieces that we needed.

同时，在其中嵌入一条椭圆曲线其实并没有太大难度。

And then at the same time, building an elliptic curve that's embedded within it, was not really much of a challenge.

本质上就是把学术理论付诸实践，在满足所有约束条件的同时尽可能提高效率。

It's just taking these academic ideas and applying everything and trying to make it really efficient and, follow all the constraints.

这其实并不算特别困难。

It's not that it's not that hard.

但不知为何，就是没什么人去做这件事。

For some reason, people just don't do it.

我不明白... 别害怕。

I don't I don't understand the just don't be don't be afraid.

创建你自己的椭圆曲线。

Make your own elliptic curve.

继续吧。

Go ahead.

我真的没看出来。

I really don't see that.

你能描述下刚才说的‘曲线套曲线’是什么意思吗？

Would you describe what you just said there where it's like a curve in a curve?

这是递归的，还是另一种...

Is that recursive, or is that a different

是嵌套的。

it's nested.

本质上，你有一条像BLS12-381这样的椭圆曲线，它有一个标量域——你的算术电路就是构建在这个标量域上的，而且你可以在任何域上构造任意曲线。

So, essentially, you have an elliptic curve like BLS twelve three eighty one, which has a scalar field, which is where you do all the your arithmetic circuit is built over the scalar field, and you couldn't you can construct arbitrary curves on any field.

所以你只需在那个域上构建另一条曲线，我称之为嵌入曲线，但不知道还能怎么称呼它。

So you just construct another curve under on that field, and I call it an embedded curve, but I don't know what else to call it.

于是那条曲线就会是跳跃跳跃的。

And and so that that that curve would be jump jump.

我这边也有听众的两个问题，实际上是来自杰夫·伯吉斯的。

I have two two questions from a listener on this one as well, actually, from Jeff Burgess.

我想提问主要是因为这些问题暗示了如何思考这类曲线以及相关的工程实现工作。

And I really only wanna ask them because I think they hinted sort of how to think about this and how to work with curves, like what the engineering effort that goes into it.

两个问题是：我们何时能实现对此曲线的哈希运算？何时能在此曲线上实现恒定时间运算？

So the two questions are, when do we get hashing to this curve and when do we get constant time arithmetic in this curve?

我一直在开发一个具有恒定时间特性的BLS12-381实现。

So I've been working on an implementation of BLS twelve three eighty one that has constant time.

所有运算。

Everything.

所有运算都是恒定时间的，甚至包括通常不需要的配对运算。

Everything is constant time, even the pairing, which is not necessary usually.

这就是我正在研究的内容。

So so that that's something I'm working on.

这完全可行。

It's totally feasible.

关于曲线哈希，Dan Benet等人最近发表了一篇新论文，提出了一种快速实现曲线哈希的技术。

Hashing to the curve, there was a new paper by Dan Benet and someone else where they had come up with a technique for doing fast hashing to the curve.

这非常令人兴奋，我计划学习其原理并实现它。

And so that's really exciting, and I plan to learn how that works and implement it.

所以它即将到来。

So it's it's on a it it it's coming up.

虽然LS12-381最初是为Zcash设计的，但它可以被任何项目使用。

And and the LS twelve three eighty one, although it was designed for Zcash originally, it can be used by anything.

它也可以被那些只需要BLS签名（这些可快速聚合的签名等特性）的项目使用。

It could be used by projects that just want to have, BLS signatures, which are these really fast aggregatable signatures and and things like that.

可以说，它已经自成一体了。

So, you know, it's it's taken a life on its own.

我认为现在很多处理这类随机信标链的项目，它们都旨在某种程度上使用VLS签名，通常涉及12-3-8-1曲线。

I think a lot of projects that are now dealing with these sort of random beacon chains, they're aiming to have VLS signatures in some regard than usually dealing with twelve three eight one.

嗯。

Mhmm.

是的。

And yeah.

所以听起来这些问题有点像混合体，就像Dan Bonnet和他的研究团队在努力寻找一种哈希方法的同时，也在解决实现恒定时间的工程难题。

And so it's sort of it sounds like it's a bit of these questions, it's a bit of mix, again, of, like, Dan Bonnet and his research team are working on trying to figure out a way to do hashing while you're plugging away at the engineering things of getting constant time.

我们已经实现了对BLX12-3-8-1曲线的哈希映射。

We'd already implemented hashing to to BLX twelve three eighty one.

这在理论上是恒定时间的。

That is theoretically constant time.

只是效率不如Dan Bonnet论文中的方法。

It's just not as efficient as Dan Bonnet's paper.

我们还没

We hadn't

哦，有意思。

Oh, interesting.

所以它实际上已经被实现了。

And and so it's been actually implemented.

虽然它没有被集成到我对BLS12-381的实现中，但在其他几个衍生版本中已经实现了。

It wasn't integrated into my implementation of BLS twelve three eighty one, but it was implemented in a couple others that have spawned off.

人们已经创建了自己的实现版本。

People have made their own implementations.

因此，向该群组的哈希映射已经存在。

And so there was there was already hashing to the group.

只是现在这篇新论文出来了，效率更高，在大家开始以特定方式使用哈希前，可能都应该转向这个新方案——毕竟理想情况下我们希望它能标准化等等。

It's just now that this new paper came out and it's much more efficient, everyone should probably move to that new thing before everyone starts using hashing in a specific way because, ideally, we'd like it to be pretty standardized and and so on.

是的。

Yeah.

你真的参与那些标准讨论了吗？

Are you are you really involved in that standards talk?

比如，我知道有很多人正在推动零知识证明标准的制定。

Like, I know that there's a lot of people who are trying to get some ZK standards going.

是的。

Yeah.

我曾担任第一届和第二届ZK证明研讨会的协调人兼委员会成员。

I was one of the, moderators slash, committee members of the ZK proofs workshop, the first one and the second one.

第二届研讨会就在这个月（四月）初刚举办。

And the second one was just earlier this month in April.

所以我认为现在标准化某些内容还为时过早，比如椭圆曲线——不同项目需要不同的椭圆曲线。

So I guess part of the the those stand I think it's a little too early to standardize on certain things like elliptic curves, everyone needs a different elliptic curve.

以太坊不幸地采用了Zcash最初使用的旧曲线，因为他们当时急需一个现成方案以便...

Ethereum's, regrettably is using this old curve that Zcash originally used because they just needed something so that they could they

他们采用它是为了实现与Zcash的互操作性，结果Zcash自己却换了算法。

could They put it in because they wanted interoperability with Zcash, and then Zcash changed.

其实我当时反复警告过他们：喂...

Well, I I I did try to warn them, hey.

出于安全性等因素考虑，你们或许应该改用BLS曲线，而且我们Zcash也准备切换使用它们。

You should probably use BLS curves instead because of of the security thing and everything else, and we're gonna switch them in Zcash.

实际上，目前有几项关于以太坊下次升级的提案正在讨论中。

There's actually a couple of proposals on the table for the next upgrade to Ethereum to add there's there's a couple of different ones.

他们想要一种适用于任何椭圆曲线的通用配对函数，另一种则是针对BLS12-381曲线。

They want one generic sort of pairing over any elliptic curve type of function and another one for, I think, BLS twelve three eighty one.

是啊。

Yeah.

所以现在的情况是，似乎每个人都在选择不同的曲线。

So so so it's it's really everyone seems to be picking different curves.

举例来说，BLS12-381并非万能方案——如果你需要进行配对嵌套递归之类的操作呢？

For example, a BLS twelve three eighty one isn't the end all be all because what if you wanna do in a nested recursion of pairings or something like that?

那就必须使用ZEXY论文里提到的那些曲线。

Well, then you have to use the curves that were in ZEXY.

又或者如果你想要实现无限递归呢？

Or what if you wanna do indefinite recursion?

那么你就需要使用MNT四或MNT六循环，比如在CODA中使用的这种。

Then you have to use this MNT four or MNT six cycle that's used in, for example, CODA.

所以每个人可能都会选择不同的曲线，在性能、安全性和特定功能之间做出不同的权衡，因此目前很难在曲线上实现标准化。

So everyone's gonna have a different curve probably with different trade offs of performance and security and features of certain kinds, and so it's really difficult right now to standardize on a curve.

但我们可以暂时在语言和技术等方面达成标准化共识。

But what the what we can standardize, I guess, on right now is language and techniques and things like that.

这样我们就能达成一致：如何严格构建曲线以避免后门或其他可能被利用的漏洞。

So we can we can come to an agreement of this is how you construct a curve rigidly to avoid backdoors or whatever other kind of possible things that you could screw around with.

解释清楚所有细节。

Explain everything.

这是针对某些特定话题应该使用的术语等等。

This is the term you should use for for some particular topic and so on.

所以目前标准化工作的重点一直放在这方面。

So that's currently what the standardization effort has been focused on.

除此之外没有太多

There isn't much else to