阈值签名方案与FROST（切尔西·科姆洛主讲）

是的

Yes.

这是个好问题

That is a good question.

我认为这确实涉及到一些讨论，比如我们是否真的需要这些签名速度

And I think that does play into some of the discussion around do we actually there's been a discussion around do we actually need speed in these signatures?

好的

Okay.

我认为围绕零知识证明是否需要速度也有过类似的讨论

And there's been similar discussions, I think, as well around, like, do we need speed in zero knowledge proofs?

嗯

Mhmm.

我记得Penumbra的Henry De Valenz说过一个很有启发性的观点：对于客户端应用来说，所需的最大速度就是用户处理事务所需的时间——这个速度在计算机层面其实很慢

So I think Henry De Valenz, who is with Penumbra, said something which I thought was very useful to think about, which is for, like, a client side application, the most speed you need is enough time for the user to process something, which is kind of slow in terms of, like, computer speed.

嗯

Mhmm.

所以我认为这确实是个值得思考的有用观点。

So I think that that's actually something useful to think about.

是的，如果这是个钱包应用，运行在用户终端上，那么你可能可以容忍长达一秒的处理速度。

So, yeah, if this is a wallet and it's on a user application, like, you can probably tolerate speeds of up to a second.

嗯。

Mhmm.

但如果是其他应用——比如有些公司代表客户持有股份的情况。

But if this is an application so for example, there's companies that hold shares on behalf of their clients.

嗯。

Mhmm.

那么当代理服务器直接执行签名时，速度就很重要了，因为这是计算机与计算机之间的通信。

And so the the agents are servers performing signatures directly, then speed matters because these are just computers talking to other computers.

好的。

Okay.

因此，不同的代理服务器会有差异，速度要求也会随着代理类型的不同而变化。

So the the agents do they differ and the speed requirements differ as those agents differ.

但就

But then also in terms

的

of

复杂性而言，网络基础也可能很重要，因为你会遇到丢包之类的问题。

complexity, network grounds can can be important as well because you have things like packets dropping and and other things like that.

你提到速度和Penumbra很有意思，因为在最近几期节目中，我们和Aileen讨论过同样的话题，我也同样向Henry和Penumbra致敬过，他们的工具能在后台完成所有工作。

It's funny that you mentioned speed and Penumbra because in a recent episode that probably came out a few episodes ago, we talked about the same thing with Aileen, and I made the same shout out to Henry and Penumbra, how their tools do everything in the background.

所以再次致敬。

So shout out once again.

是的。

Yeah.

我认为对假设进行挑战很重要。

I think it's important for assumptions, I think it's important to challenge them.

有时候我觉得我们太过于执着

So sometimes I think we get very caught up

在

in

速度。

speed.

有时候它其实并不重要。

And sometimes it it doesn't matter.

我认为认识到这一点很重要，而且这取决于具体情境。

And I think that's important to to know and it's context dependent.

完全同意。

Absolutely.

另外我认为还有一点很重要，就是在密码学方面，设计密码系统时你希望在每个维度上都实现最高级别的安全性。

Other other things that I think are also important to know is like on the cryptography side, if you're designing cryptography systems, you want the most security possible in, like, every dimension.

但有时候在某些维度上做出安全性的权衡也是可以接受的，比如为了速度或简洁性。

But sometimes those, like, security trade offs are acceptable in other dimensions as well, such as, like, for speed or simplicity.

所以这里存在一种张力，比如Frost就是在交互式安全假设下保证安全的。

So there's been kind of a tension around so Frost, for example, is secure under an interactive security assumption.

那些具有更多网络基础的方案可以在更弱的假设下被证明是安全的。

And schemes that have more network grounds can be proven secure under weaker assumptions.

因此围绕哪些假设是可接受的、用户想要什么、什么更好等问题展开了大量讨论。

And so there's been a lot of discussion around what assumptions are fine, what do users want, what, like, what is better.

我认为从中得出的重要教训是：这取决于具体情况，需要根据上下文来判断。

And I think the the important lesson to come out of this is that it depends and it's it's context dependent.

那么这就是'frost魔法'生效的地方吗？

So is this where the the frost magic happens?

这就是你减少所有这些轮次的方式吗？

Like, is this how you reduce all these rounds?

是的。

Yes.

正是如此。

So exactly.

所以具有更多轮次的方案可以被证明在例如离散对数这样更弱且已被充分理解的假设下是安全的。

So so schemes with more rounds can be proven secure under, for example, discrete log directly, which is a weaker and kind of well understood Yeah.

是的

Yes.

所以Frost需要一个交互式假设

So Frost requires an interactive assumption.

它基于我们所谓的代数一次更多离散对数假设

It's under what we call the algebraic one more discrete log assumption.

仍然在随机预言模型中，所以至少你

Still still in the random Oracle model, so at least, you

嗯

know Mhmm.

就是这样

There's that.

但它是个交互式假设

But it's an interactive assumption.

基本上是说，假设给你l+1个离散对数挑战，并允许你进行l次查询求解，你能给出l+1个解吗？

I mean, it basically says, let's say you're given l plus one discrete log challenges, and you're allowed l queries for solutions, can you produce l plus one solutions?

简单来说，就是你能在允许的查询次数之外，多给出一个解决方案吗？

So basically, can you produce one extra solution than queries that you're allowed?

所以

So

听起来合理。

Sounds reasonable.

我觉得直觉上，这听起来是合理的。

I think intuitively, it sounds reasonable.

这个假设已经存在一段时间了。

This assumption has been out for a while.

没有这个假设，很难证明盲签名的安全性。

It's very hard to prove blind signatures secure without this assumption.

所以这个假设是在盲签名的背景下提出的。

So this assumption was introduced in the context of blind signatures.

再次强调，这是依赖于具体语境的。

So again, it's it's context dependent.

嗯，我想。

I think Mhmm.

我个人认为这个假设是合理的。

I I personally feel this assumption is reasonable.

特别是在实际应用中，这是一个不错的权衡。

And especially in a practical setting, it's it's a fine trade off.

但重申一次，这取决于具体情境。

But again, it's it's context dependent.

最后我想问一个问题。

One last thing I wanted to ask.

当我们开始进行阈值签名时，签名者是使用自己生成的私钥，还是需要共享密钥份额？

When we start a threshold signature, do the signers have their private key that they generated on their own, or do they have to somehow have shares of a key?

比如，我们的起点是什么？

Like, where do we start from?

是的。

Yes.

关于初始设置的问题确实非常关键。

The bootstrapping question is a very important question to ask.

是的。

Yeah.

所以签名者必须通过秘密共享密钥来完成初始设置。

So so signers have to bootstrap with a secret shared key.

采用的是Shamir秘密共享方案。

It's Shamir secret shared.

基本上，每个参与方都持有一个数据点。

So basically, every party has a point.

他们的份额本质上是多项式上的一个点。

Their share is essentially a point on a polynomial.

而这个联合私钥就是该多项式的常数项。

And the secret key, this joint secret key is the constant term of that polynomial.

当你组合签名份额时，实际上是在隐式地对多项式进行插值计算，以获取多项式上其他未知点的值。

And when you combine signature shares, what you're doing implicitly is polynomial interpolation to some other point on the polynomial, which is unknown.

实际上，这个魔法非常简单：给定多项式上的t+1个点，你就能找到多项式上的任何其他点。

So really, the magic, it's very simple, is given t plus one points on a polynomial, you can find any other point on the polynomial.

这就是幕后发生的全部事情。

So that's all that's happening under the hood.

因此，我们通过使用普通的Shamir秘密共享（需要一个可信的第三方分发者）或其他多方协议（我们称之为分布式密钥生成方案）来进行初始化。

And so we bootstrap by using either just plain Shamir secret sharing using a trusted dealer or another multi party protocol, which is what we call a distributed key generation scheme.

具体来说，就是所有参与方共同参与这个过程。

And so what that is is, again, you have all the parties, they're all participating.

该协议的输出结果是每个参与方持有的私钥分片，这些分片组合成一个无人知晓但所有参与方共同贡献的私钥。

And the output from that protocol is secret key shares that every party holds that combine to some secret key that no party knows, but all parties have contributed to.

这有点像是一个神奇的黑色盒子。

So it's kind of like a magic black box.

每个参与方都投入一些随机性。

Every party throws in some randomness.

最终，他们各自获得私钥分片，这些分片组合成一个实际上无人见过的私钥。

And at the end, they all get secret key shares that combine to a secret key that no one has actually seen.

所以我仍然不太清楚的是，在Zcash这样的系统中，你们是在某个地方实现这个吗？

So the thing I'm still not entirely clear on is almost like in a system like Zcash, do you implement this somewhere?

还是在应用层面？

Or is it on an app?

比如，是在钱包层面吗？

Like, is it on a wallet level?

我理解这项研究被创造出来，但不太清楚它具体应用在哪里。

Like, I understand the research being created, but I don't really know where it fits in.

嗯。

Mhmm.

是的。

Yeah.

Zcash基金会已经实现了Frost协议，以及一个分布式密钥生成方案和可信经销商Kijan。

So Zcash foundation has implemented Frost and also a DKG and trusted dealer Kijan.

然后应用程序可以引入它

And then applications can pull it in

好的。

Okay.

根据需要。

As they need to.

所以如果你是Zcash用户，你会把这个功能集成到你的应用中。

So if you're Zcash pull it, you will pull this into your application.

团队目前正在努力让这个功能的调用变得更简单一些。

And the team right now is doing some work to make pulling that out a little easier.

他们正在开发演示程序和其他类似的东西。

So they're working on demos and other things like that.

但这更像是一个核心库，然后被集成到各种应用中。

But this is kind of like a core library, and then it's pulled into various applications.

不错。

Nice.

这也是为什么它能在CCache之外使用，因为它本质上是协议无关的。

And this is why it's being used outside of CCache as well because it's essentially protocol agnostic.

因此你可以将其集成到其他可能需要实现Schnorr签名的钱包中。

So you can you can pull it into to, like, other wallets that maybe need to implement Schnorr signatures.

正如你所说，通常应用程序要么创建冗余备份，要么确保如果你丢失了一个密钥分片，你还有更多备份，并且有人为你保管它们。

And like you said, usually, the applications will be either creating redundancies or making sure that if you lose one of your key shares, you have more and someone stores them for you.

是的。

Yes.

比如账户恢复或多签机制，通过分散信任，要求多方共同签署。

So account recovery or multisix, like distributing trust, having multiple people having to sign.

是的。

Yes.

有件事非常重要需要说明——虽然我们最初在Frost论文里没写这部分，但其实存在密钥分片恢复的技巧。

So something that's very important to know so we didn't write this in the Frost paper originally, but there's tricks for doing share recovery.

如果某一方丢失了其分片，现有协议可以通过重新推导该分片或创建新分片，帮助该方恢复其签名密钥。

So if one party loses its share, there's established protocols out there for rederiving that share or creating new shares so that that party can recover their signing key.

同时也有协议可以为新参与方生成新的密钥分片。

And there's also protocols for generating new shares for new parties.

所以如果你在听并且有疑问，比如，我是否只有固定数量的份额，还是这是动态的？

So if you're out there and you have questions about, like, okay, do I have just a set number of shares, or is this dynamic?

答案是肯定的。

The answer is yes.

它是动态的，而且有相应的协议。

It's dynamic, and protocols exist for that.

你刚才多次提到多方参与，但我们还没明确说这是否属于多方计算。

And you've you've mentioned sort of multiple parties throughout this, but we haven't actually said, like, multi party computation.

它属于这个范畴吗？

Does it fall under that category?

还是说我们只是并行工作，它们只是相似？

Or are we working, like, beside are they just similar?

是的。

Yes.

所以答案是肯定的。

So it is yes.

从技术上讲，阈值签名是多方计算的一种特殊形式。

So technically, threshold signatures are is a special form of multiparty computation.

我认为有必要区分一下，因为当你提到多方计算时，这可以泛指通用计算。

I think it's nice to distinguish because when you say a multiparty computation, this can be done generically.

本质上你可以将任何函数分配给多个参与方来执行。

So you can essentially take any function and distribute it among parties.

而且有通用的工具可以实现这一点。

And there's generic tools for doing this.

这些通用工具也可以用于实现阈值签名，但通常效率较低。

Those generic tools could also be used to do threshold signatures, but they're generally less efficient.

好的。

Okay.

这种情况在其他密码学领域也很常见，你可以设计通用工具，但效率较低。

And so and this is common in, like, other kinds of cryptography where you can design generic tools, but they're less efficient.

或者你可以针对特定用例设计专门的方案，这样就能针对该用例进行优化，通常效率会更高。

Or you can design, you know, schemes that are for specific use cases, and then you can tailor them for that specific use case, and they tend to be more efficient.

所以我觉得区分一下挺好的。

So I think it's kind of nice to distinguish.

希望有一天我们能拥有通用的多方计算技术，可以处理所有问题。

Hopefully, one day, we'll have generic MPC that can just MPC everything.

特别是在全同态加密领域，人们正朝着这个方向努力，这非常令人兴奋。

And people, especially in the FHE world, are moving in that direction, which is very exciting.

但目前我们只有非常简单的门限签名方案，这是非常定制化的。

But right now, we have the very simple threshold signature case, which is quite tailored.

明白了。

Got it.

很高兴能提出这个问题，顺便感谢奈杰尔·斯马特最终介绍我们认识。

I'm glad I got to work that question in because, just a shout out to Nigel Smart, who did finally introduce us.

正是他最终促成了这次联系，也是他推荐的。

He was the one who finally made the connection and he had recommended.

我们之前做过一期，实际上是两期关于多方计算的节目，其中一期相当新。

We've done an episode in the past, or actually two episodes on MPC, but a pretty recent one.

所以我们可以把那个链接也放上。

So I can we can also link to that.

是的。

Yes.

绝对可以。

Absolutely.

而且，我对Zama等机构的工作感到非常兴奋，他们正在实现通用的多方计算（MPC）和全同态加密（FHE），这些都是非常强大的工具。

And, yeah, I I am really excited for what places like Zama are doing and having, yeah, having generic MPC and, like, FHE is a really strong tool.

我认为看到它们未来的发展会非常令人兴奋。

And I think it will be it's really exciting to see where it'll go in the future.

太酷了。

So Cool.

希望有一天全同态加密能应用于一切，那样我们所有问题就都迎刃而解了。

Hopefully, we can have FHE for everything and, you know, all of our problems will be solved.

轻而易举。

Easy.

尽管越来越像是组合技术，比如零知识证明（ZK）与全同态加密（FHE）的结合。

Although what it looks more and more like is it seems like combos, like ZK and FHE.

嗯。

Mhmm.

总之

So anyway

回到Frost协议的话题。

So back to Frost.

你提到Frost的开发源于Zcash的实际需求。

You said Frost was developed coming from the use case that Zcash needed.

这是一种标准技术吗？

Is this kind of a standard technique?

我想问的是，这个协议是否正在被标准化以供其他人使用？

Is this, I guess, being standardized for other people to use?

是的。

Yes.

我们为CFRG（互联网工程任务组内的密码学研究论坛）撰写了一份信息性草案。

So we wrote an informational draft for the CFRG, the cryptography forum research group within the IETF.

我们这么做的原因实际上是因为我们发布了Frost协议。

The reason why we did it actually was because we put out Frost.

然后我收到很多人发邮件说他们正在实现Frost，但他们在数据序列化等方面做出了略微不同的实现选择。

And then I had a lot of people emailing me to say that they were implementing Frost, but they were implementing it in slightly different ways and making slightly different choices around things like serialization of data.

哈希函数。

Hash function.

对，就是这样。

Just yeah.

我知道这些细微差异可能会在未来造成混淆，甚至可能引发错误。

Like slight variations that I knew down the line would potentially be confusing and then potentially having bugs as well.

所以我当时

So I Was

这对你来说压力很大吗？

that very stressful to you?

嗯，大体上是这样分开的。

Well, mostly apart like that.

我是说，这其实挺让人兴奋的。

I mean, it was exciting.

但同时我也担心，一方面会出现很多兼容性问题。

But also, I I was worried that well, one, we would have a lot of incompatibilities.

嗯。

Mhmm.

实际上有审计人员告诉我，他们已经发现了一些漏洞。

And I actually had auditors tell me that they had seen bugs pop up.

嗯。

Mhmm.

比如有人告诉我，他们看到一个Frost实现中nonce是像EDDSA那样确定性派生的。

So for example, someone told me that they saw an implementation of Frost where the nonces were being derived deterministically as they're done in EDDSA.

也就是说nonce不是随机采样，而是通过哈希签名密钥和消息生成的。

So instead of sampling nonces at random, the nonces were generated by hashing the seeker key in the message.

如果你习惯了单方EDDSA，这就是你的做法。

So if you're used to a single party EDDSA, this is what you do.

你通过哈希消息和密钥来生成私有的nonce值。

You hash the message and the secret key to generate your nonce, which is private.

所以这完全合理。

So that's totally reasonable.

但在Frost环境下，这会导致两次签名会话中出现密钥恢复攻击。

But in the frost setting, this leads to a secret key recovery attack and two signing sessions.

哇哦。

Woah.

如果你这么做，简直就是彻底崩溃。

So it's like a total break if you if you do this.

这是ROS论文中的不安全问题吗？

Is this the insecurity of ROS paper?

不是。

No.

所以是不同的？

So Different?

好的。

Okay.

是的。

Yeah.

ROS问题归根结底取决于方案的实际设计方式。

ROS comes down to how the scheme is actually designed.

因此Frost是最早能防御ROS攻击的方案之一。

And so Frost was one of the first schemes that was secure against ROS.

这得益于Frost方案本质上采用了两个随机数。

And it's because of how Frost essentially has two nonces.

你在第一轮对话中做哈希运算，生成全局随机数，从而规避ROS攻击。

You hash in the transcript from the first round, and then that becomes your overall nonce, and that avoids ROS attacks.

但如果你采用确定性方式生成随机数导致密钥恢复攻击，纯粹是因为对手能介入挑战环节。

But the the key recovery attack if you derive your nonsense deterministically is just because the the adversary has input into the challenge.

嗯。

Mhmm.

所以本质上，只要攻击者不按确定性协议执行，而诚实参与者遵循协议，就存在一个简单的密钥恢复技术。

So essentially, as long as the adversary changes doesn't follow the protocol deterministically, but the honest player does, there's a trivial key recovery tech.

哎呀。

Oops.

这是你无法检测到的。

That's that you can't detect.

有人告诉我这个时，我就想，哦，不。

So someone told me this, I was like, oh, no.

如果我们真能有些对策就好了。

It would be great if we actually had something.

因为研究论文并不会包含精确的工程细节。

Because a research paper isn't written with, like, exact engineering details.

它基本上只需展示足够的内容来证明方案的安全性。

It's basically enough to show what's going on so that you can prove the scheme secure.

但这些细节对工程师来说还不够充分，无法据此做出诸如序列化或排序等重要决策。

But it's not enough details for engineers to follow to make really important decisions like serialization or ordering or other, like, that are somewhat important.

所以这就是为什么我们决定撰写这份信息性草案的原因

So so That's why we decided to write this informational draft basically

嗯。

Mhmm.

因为人们正在实施它，我们想要一些更有用的内容。

Because people were implementing it and we wanted something that was more useful.

所以那个过程现在即将结束。

So that that process is wrapping up right now.

而且很巧的是，NEST也发布了征集，或者说他们很快就会发布关于阈值方案的最终征集。

And conveniently, NEST has also put out a call or they're very soon to putting out a final call for threshold schemes as well.

我们基本上会把提交给CFRG的内容转化为NIST的提交材料。

And we'll be basically taking what we submitted to CFRG and turning that into a into a NIST submission.

但是NIST需要选择那个方案吗？

But then with NIST, does NIST need to choose that?

然后它某种程度上会成为标准，但你们要面对其他类型的

And then it becomes sort of the standard, but you're kind of up against other types of

所以这次阈值方案的征集与NIST在后量子密码征集中的做法不同。

So this threshold call is different than what NIST did for the post quantum call.

好的。

Okay.

对于单方签名方案，我认为进行统一竞赛更容易，因为你可以定义API接口、输入输出等标准。

So for single party signatures, it's I think it's easier to have a kind of uniform competition because you can do things like define what the API is, define what the inputs and outputs are.

这正是NIST后量子密码竞赛采用的方式。

And this is what was done for the NIST post quantum competition.

对于阈值签名方案来说会更困难，因为实际方案内部存在很大差异。

For threshold signatures, it's a little harder because there's so much variation within the actual schemes itself.

因此即便对于阈值化的EDDSA方案，它们最终可能都会输出一个单方EDDSA签名。

So even though for thresholdized EDDSA, they all might be putting out a single party EDDSA signature.

但各个方案的具体实现机制却大不相同。

The internals of the scheme are all quite different.

我认为目前NIST正在决定他们将采取什么行动。

I think right now, NIST is trying to decide what they'll do.

但这次征集基本上是说：请向我们提交比论文更详细的方案细节。

But this call is basically, send us your schemes in more detail than in the paper.

然后具体后续步骤，据我了解仍在商议中。

And and then the and is still being decided as I understand.

明白了。

Got it.

所以，嗯。

So so yeah.

在NIST负责统筹此事的Luis，会是个很适合上节目的嘉宾人选。

So Luis, who's at NIST, who's sort of organizing all of this, would be a great person to have on the show.

他对整体背景、实施计划和发展方向有更全面的把握。

So he has more context and a plan and vision for where this will go.

希望你们能邀请他上节目来回答这些问题。

So hopefully, you can have him on and ask him these questions.

或许我们可以开发一个关于标准化的应用。

Maybe we could do an app on standardization generally.

我们还从未采访过NIST的人。

We've never talked to anyone from NIST.

是的。

Yes.

他将是一位能深入了解他们工作意图的绝佳人选。

He would be a great person to have insight into what they're trying to do.

那么我们现在或即将拥有一项FROST标准。

So we now have or soon to be a frost standard.

接下来是什么？

What comes next?

Chelsea Kommeler的其他工作内容是什么？

What's the rest of Chelsea Kommeler's work?

嗯，希望我才刚刚开始。

Well, hopefully, I'm just getting started.

我对未来有着宏伟的规划。

So I have grand, you know, grand plans for the future.

但这个过程教会我的一点是——正如我之前提到的——将密码学投入实践时需要权衡不同因素。

But I guess one thing that this process has taught me, and I kind of referred to this before, which is there's different trade offs in deploying cryptography for into practice.

嗯。

Mhmm.

我主要考虑的权衡因素包括易用性、安全假设和性能表现。

So the trade offs I sort of think about are things like usability, security assumptions, and then performance.

这些就是设计方案时需要权衡的不同维度，每个维度上都有各自的取舍。

So those are kind of the the different axes when you're designing a scheme and you have different trade offs along the along those different axes.

嗯。

Mhmm.

之前我提到人们使用Frost时采用确定性方式，这存在明显漏洞。是的。

So before I talked about how people were using Frost deterministically, trivially broken Yep.

关于如何实现确定性Frost的问题，我已经思考了很久。

I've been thinking about how to do deterministic frost for a long time.

这是个非常棘手的问题。

And it's a very hard problem.

要以安全的方式实现这一点极其困难。

It's extremely difficult to do it in a way that's secure.

已有研究致力于实现确定性的阈值Schnorr签名。

There's been work done to do deterministic threshold Schnorr signatures.

基本上，这些研究需要用到通用SNARKs或通用MPC等工具。

And basically, those works require things like generic SNARKs or generic MPC.

虽然可以实现确定性的阈值SHOR签名，但需要某些重量级工具支持。

So you can do deterministic threshold SHOR, but it requires some kind of heavyweight tools.

退一步说，我们之所以追求确定性阈值SHOR签名，不仅是为了避免依赖随机源生成签名，还因为签名者可以保持无状态。

I guess so even taking a step back, when I say deterministic threshold SHOR, the reason why this is something we want is not only because you can not have to rely on fresh sources of randomness when you're generating your signature, but also because signers can be stateless.

简单来说，完成一轮操作后无需保存任何状态。

So basically, you perform a round and you don't have to save any state.

进行下一轮操作时，可以直接重新推导出所有状态。

And then you perform your next round and you can just rederive all of the state.

从实现角度来看这很棒，因为你不需要在数据库中缓存任何东西。

So from an implementation perspective, this is great because you don't have to cache things in a database.

对数据库加锁。

Take a lock on the database.

在数据库中查找内容。

Look up the thing in the database.

谨慎地删除信息

Carefully delete information

是的。

Yeah.

如果不删除这些信息，你的私钥就会泄露。

That if you don't delete it, your secret key is leaked.

解锁数据库。

Unlock the database.

所以我们确实很想要这种方案，我认为这些机制在实践中其实相当有吸引力。

So so we really want like, these games are actually quite attractive, I think, in practice.

但目前它们需要重型工具。

But currently, they require heavyweight tools.

是的。

Yeah.

所以我即将开展一些工作，我很想看看从业者对此的看法。

So I have some upcoming work, which I think I'm I'm interested to see what practitioners think about it.

基本上，这项工作名为ERCTIC，我觉得很不错。

So basically, the work is called ERCTIC, which I'm I think is nice.

主题性的。

Thematic.

对。

Yeah.

说不。

Say not.

是的。

Yes.

它也是一个缩写词吗？

Is it also an acronym?

不是。

It's not.

我实在想不出一个像DTS这样能组成好词的缩写。

I couldn't I couldn't think of an acronym with, like, DTS came into, a nice word.

我花了很多时间思考这个问题。

I spent a lot of time thinking about it.

但'北极'（Arctic）是我能想到最好的名字了。

But ark Arctic was the best I could call.

和思考论文的时间相比呢？

How much compared to the time thinking about the paper?

我是说，没那么多。

I mean, not as much.

我确实努力尝试过构思一个缩写，但就是没成功。

I did I did try hard to make an acronym and just just failed.

我一直在市场上寻找好的方案名称。

I'm always on the market for like good scheme names.

好吧。

So Okay.

说吧

Just tell

以后如果你有好方案名称就告诉我。有很多变体

me your good scheme names in the future if you have There's lots of variation

关于能融入这一切的寒冷事物。

on cold things that could fit into all of this.

是的。

Yes.

所以我将来会关注这个市场。

So I'm I'm on the market for it in the future.

不错。

Nice.

是的。

Yeah.

基本上，Arctic是Schnorr签名的一个确定性阈值。

So basically, Arctic is a deterministic threshold to Schnorr signature.

而且非常简单。

And it's very simple.

它不需要通用的多方计算或类似通用序列知识证明的东西。

It doesn't require generic MPC or things like generic serial knowledge proofs.

但它做出的权衡是需要假设有更多诚实签名者。

But the trade off that it makes is that it requires a larger number of assumed to be honest signers.

基本上，Frost的安全模型是：你可以有t个签名者，其中最多t减1个被假设为诚实。

So basically, for Frost, the security model that it's secure under is you can have t signers and up to t minus one of them are assumed to be honest.

所以一个诚实方就足够了。

So one honest party would be enough.

没错。

Exactly.

嗯

Mhmm.

所以这是一个非常好的安全模型，你可以据此进行推理。

So and that's like a very nice security model that you can can reason about.

因此你只需要一个诚实方。

So you have one honest party.

对于Arctic来说，它假设总共有2t-1个参与方，其中t-1个被假定为不诚实。

For Arctic, Arctic assumes total two t minus one parties, where t minus one of them is assumed to be dishonest.

嗯

Mhmm.

所以我们真正要求的是：在你的所有签名者中，大多数必须是诚实的。

So really what we require is out of your total set of signers, the majority of them are honest.

对

Right.

所以我们从单个诚实方变成了多数诚实方。

So we go from single honest party to majority honest.

是的。

Yes.

好的。

Okay.

但真的可以只是51%诚实这样吗？

But could it really just be like 51% honest kind of?

就一点点？

Just a little bit?

是的。

Yes.

只需要再多一点点诚实。

Just a little bit more honest.

好的。

Okay.

这不是66%的情况。

You're it's not a 66 situation.

不是。

No.

没关系。

It's Okay.

大约是51%的诚实度。

It's like 51% honest.

这很有趣，因为我们已经在加密货币中有了类似的假设。

And and so it's interesting because we do have assumptions like that already in cryptocurrencies.

比如在共识机制中。

So for things like consensus.

在其他领域，我们也有类似51%诚实度的假设。

So in other places, we have, like, 51% honest as an assumption.

但迄今为止，在门限签名领域，我们还没有真正探索过这类假设。

But so far in in threshold signatures, we haven't really explored those kind of assumptions.

所以在Arctic项目中，我们基本上就是说，好吧。

And so with Arctic, basically, we we say, okay.

如果你能接受这类假设，就可以采用无状态方案。

If you're fine with those kind of assumptions, you can have a stateless scheme.

这相当简单。

That's pretty simple.

因此，这又取决于实施者来决定他们能接受哪些权衡。

So then, again, it's up to implementers to say what trade offs am I fine with?

我是愿意部署更多签名者，从而获得一个更简单但具备这些良好安全特性的方案？

Am I fine with deploying more signers and then having a simpler scheme that has, like, these nice security properties?

还是说我确实需要那种'除一人外全部诚实'的严格条件？

Or do I really need that, like, all but one honest?

关于你提到的最后一个维度——速度，Arctic在速度方面表现如何？

About your your last axis, speed, how how does Arctic perform in terms of speed?

它相当快。

It's pretty fast.

还是两轮协议，还是需要更多轮次？

Is it still two rounds, or is it a bit more?

它需要两轮。

It's it's two rounds.

我想这很理想。

So I guess Lovely.

所以这里存在一个权衡。

So there there's a trade off.

对于25人以下的小组来说，它相当快。

So for groups under, like, size 25, it's pretty fast.

这里有一个权衡。

There's a a trade off.

而对于更大的群体，需要通用知识证明的MUSIC DN会更快。

And, like, for larger groups, MUSIC DN, which requires generic as your knowledge proofs, MUSIC DN is faster.

所以这里存在一个交叉点。

So there there's a crossover point.

但我们看到的是，对于规模较小且能接受51%诚实成员的小组，可以采用更快的方案。

But what we see is, okay, for smaller sized groups where you're fine with 51% honest, you can have a a faster scheme.

但话说回来，我觉得把这些权衡点明确列出来，然后思考我们能接受什么，这很有意思。

But again, I think I think it's interesting putting out these axes more explicitly and then thinking about, like, what are we fine with?

但至少我们拥有所有可选方案。

But at least we have, like, all of the options.

而且，你知道，应用程序可以说'我不知道'。

And, you know, applications can say, I don't know.

我们不介意实现防弹证明（bulletproofs）。

We don't mind implementing bulletproofs.

而且，我们也能接受某些方案速度较慢。

And, like, we're fine with something being slower.

用Music DN方案也没问题。

Music it Music DN is fine.

或者对我们来说，实现简单更重要，因为我们担心出现漏洞。

Or simplicity of the implementation is important to us because we're scared about bugs.

嗯。

Mhmm.

对于小型群体我们希望速度更快，那么类似Arctic的方案会是更好的选择。

And we want something to be fast for smaller groups, then something like Arctic is a better choice.

你刚才提到，我听到更多关于确定性和无状态性的讨论。

You've sort of said, I've I've heard more about deterministic, but also stateless.

这两者是不是同一个概念？

How like, are those the same thing?

它们之间有关联吗？

Are those connected?

是的。

Yes.

确定性是实现无状态性的手段。因此我们采用确定性方案，或者你可能会读到关于确定性阈值Schorr方案的内容。

So determinism is the means to statelessness in this So we have a deterministic scheme, or you might read about deterministic threshold Schorr schemes.

当我们说确定性时，意味着该方案同时也是无状态的。

But when we say deterministic, that means that the scheme is also stateless.

因为基本上，给定一个输入，我可以推导出某些状态，并且你知道它在某个回合的情况。

Because basically, given an input, I can derive some state And you know what and it some round.

嗯。

Mhmm.

而且你知道它是什么。

And you know what it is.

然后我有了这一轮。

And then I have this round.

保存 是的。

Save Yes.

状态在其他地方。

State somewhere else.

好的。

Okay.

没错。

Exactly.

所以如果你给这些不同的轮次输入相同的内容，你就可以确定性地推导出那个输出。

So if you're given the same inputs to these different rounds, then you can deterministically derive that output.

酷。

Cool.

但它们其实是被随意混着用的。

So but they they are, like, kind of thrown around interchangeably.

所以这是个很好的问题。

So it's a good it's a good question.

这项工作什么时候发表？

When is this work coming out?

等我上传论文到电子版上就好。

As soon as I put the paper up on e print Okay.

希望这周就能完成。

Which is hopefully this week.

哦，太棒了。

Oh, cool.

不。

No.

抱歉如果

Sorry if

这是节目笔记里林肯提到的内容。

it's something that's in Lincoln in the show notes.

是的。

Yeah.

等这期节目发布时，我们应该已经拿到它了。

By the time this comes out, we should have it.

对。

Yes.

那就太好了。

That would be great.

是啊。

Yeah.

我确实很好奇。

I really am curious.

这算是我的一种直觉，我觉得实施者会对这类内容感兴趣。

This was kind of a hunch that I thought something like this would be interesting to implementers.

所以我非常期待听到实践者的反馈或想法。

So I'm I'm very curious to hear feedback or thoughts from from people working in practice.

就像当人们看到并思考这个问题时，如果他们有任何疑问，我很乐意与大家讨论。

So like as people see it and think about it, if they have questions, I would love to talk to people about it.

酷。

Cool.

在这里，你提到了‘不存在的’这个概念在讨论中，但我们还没具体定义过在这个特定情境下‘不存在的’意味着什么。

In this, you talk about this concept of dishonest, but I don't think we've really talked about what that would mean to be dishonest in this particular case.

我的意思是，我们有时知道验证者的‘不存在的’行为是什么。

I mean, we know what dishonesty is for validators sometimes.

知道。

Know.

不过确实。

But yeah.

这里的不诚实具体指什么？

What what is dishonest here?

是的。

Yeah.

这是个很好的问题。

That's a good yeah.

这是个好问题，因为我们经常随意使用这个术语。

It's a good question because we also throw that term around a lot.

它通常只是指你对他们将如何与协议互动没有任何假设的人。

It generally just means someone who you have no assumptions about how they will interact with the protocol.

所以他们可以诚实地遵守协议。

So they could follow the protocol honestly.

他们可能表面上诚实地遵守协议，但暗中存储额外信息。

They could appear to follow the protocol honestly, but like store extra stuff.

通常都带有某种不良目的，比如恢复密钥或伪造输出之类的。嗯。

You know, generally with some like nefarious goal in mind, like recovering the secret key or outputting a forgery or Mhmm.

你知道，比如实施拒绝服务攻击。

You know, provide performing denial of service attacks.

但从技术上讲，当我们使用这个词时，它只是指一个你无法保证其在协议中如何行动的参与方。

But technically, when we use that word, it just means a party for which you have no guarantee how they will act within the protocol.

这些代理会在哪些环节进行不诚实行为？

Where would would these agents act dishonestly?

是在回合之前还是之后？

Is it like in the rounds before after?

对。

Yeah.

所以可能发生在任何时间点。

So it could it could be any time.

假设我是个攻击者。

So I'm an adversary.

我已经控制了比如说两名参与者，并且掌握了他们的密钥。

I have corrupted, let's say, two participants and I know their secret keys.

我可以与诚实方发起签名轮次并严格遵循协议流程。

I could initiate signing rounds with honest parties and follow the protocol exactly.

然后我可以获取所有人的信息，并试图利用这些信息进行恶意操作。

And then I could take everyone's information and then I could try to do something nefarious with it.

之后吗？

Afterwards?

好的。

Okay.

之后。

Afterwards.

我可以利用我的私钥对它们进行某些操作，比如翻转比特位之类的。

I could take my secret keys and do something to them, like flip the bits or something.

然后我可以诚实地参与签名协议，接收数据后试图进行恶意操作。

And then I could participate in the signing protocol, honestly, take the stuff that I received and try to do something nefarious with it.

所以这确实非常棘手。

So it's really it's very tricky.

我认为为这类方案编写证明相当困难，因为腐败方可能采取的行为存在许多微妙之处。

And I think writing proofs for these types of schemes is quite hard because there's a lot of nuance in what a corrupted party could potentially do.

所以无论是协议开始前、进行中，还是结束后，任何阶段都可能出现问题。

So it's anything from before it starts, while the protocol is going on, or even afterwards.

当我们说诚实多数时，是指这些参与者在整个协议过程中都保持诚实吗？

And when we say honest majority, do we mean these actors act honest throughout the protocol?

还是说在每一轮中，必须保证多数人是诚实的？

Or do we say at each round, a majority of people have to be honest?

是的。

Yeah.

所以当我说诚实多数时，我指的是有T个参与者严格按照协议执行。

So when I say, like, honest majority, what I mean is that there are T participants who follow the protocol as described.

好的。

Okay.

对。

Yes.

在整个协议执行期间。

Throughout the protocol.

嗯。

Mhmm.

所以实际上，这意味着有T台机器的私钥未被泄露。

So practically, what this means is there's T machines whose secret keys have not leaked.

嗯。

Mhmm.

这实际上就是它的实际含义。

Like, this is practically how it how it translates.

但当你撰写证明时，这正是建模时需要考虑的。

But, like, when you're writing the proof, this is kind of what you need when you do the modeling.

是否有任何方案考虑了诚实参与方集合在回合间变化的情况？

Are there any schemes that consider the case where the set of honest parties changes between rounds?

是的。

Yes.

是的。

Yeah.

确实存在考虑自适应安全性的方案。

So there are schemes that consider adaptive security.

嗯。

Mhmm.

这正是你所讨论的情况。

And this is exactly what you're talking about.

静态和自适应这两个术语，我认为更像是带有实践视角的理论术语。

So static and adaptive is, I would say, kind of a more theoretical term with, like, a practical lens.

所以当我们撰写证明时，一个非常简便的方法是假设有N个参与方。

So when we write proofs, something that's very easy when writing the proof is saying, let's say you have N parties.

在证明开始时，假设第一到第五个参与方是腐败的。

And at the beginning of the proof, say parties one through five are corrupt.

这些就是不诚实的参与方。

And those are the dishonest ones.

而诚实的参与者是最后一方，在整个证明过程中世界保持不变。

And the honest ones are the last party and the world stays the same throughout the proof.

但这实际上并非实践中发生的情况。

But that's not actually what happens in practice.

实践中可能出现的情况是，攻击者先攻陷一台机器，然后实时决定接下来要攻陷谁。

What happens in practice is you can have an adversary that corrupts one machine and then it determines on the fly who it wants to corrupt afterwards.

这本质上就是适应性安全——在整个协议执行期间，攻击者可以自由选择攻陷对象。

And this is essentially adaptive security where throughout the protocol, the adversary can choose who it corrupts.

从证明撰写的角度来看，这种模型要难建模得多。

From a proof writing perspective, this is much harder to model.

嗯。

Mhmm.

听起来...所以我确实认为静态撰写证明有其优势。

Sounds like So I do think there's, you know, benefits for for writing proofs statically.

但适应性模型更接近我们实际观察到的情况。

But the adaptive model is closer to what we see in practice.

哇。

Wow.

那你们有自适应Frost协议的变体吗？

So do you have a an adaptive frost variant?

我认为我们可以证明Frost协议具有自适应安全性。

I think we can prove frost adaptively secure.

这也是直接针对Frost协议的。

It's also direct Frost.

这个证明非常困难。

The proof is very hard.

好的。

Okay.

我们正在努力解决这个问题。

It's very we're working on it.

目前正在研究中，但这并非易事。

It is a work it is currently being worked on, but it is nontrivial.

嗯。

Mhmm.

是的。

Yeah.

所以这是个有趣的研究问题：当你假设适应性安全时，会面临哪些理论上的权衡取舍。

So it's an interesting research question around what theoretical trade offs do you have when you assume adaptive security.

那么再问一次，如果我们有更简单但仅具备静态安全性的方案，这样会更好吗？

So again, like, if we have simpler schemes which are statically secure, is that better?

我认为这是个值得思考的有趣问题。

I think that's an interesting question to to think about.

就像，如果你在证明中假设了适应性安全，但方案效率较低，这意味着什么？

And like, if you're assuming adaptive security in the proofs, but you have a less efficient scheme, what like, what does that mean?

而且，你知道，这对我们所有人来说都是个值得探讨的有趣话题。

And, you know, that's kind of an interesting conversation for all of us to have.

很棒。

Cool.

我想问个问题，不是关于新工作，而是我们刚才在讨论Frost之前提到的潜在应用场景。

So I want to ask a question about not this new work, but the work we were just talking about before Frost, before we sign off, which is on potential use cases.

就像我们稍微提到的，这些系统的安全性以及人们实际已经实现了它们。

Like we sort of mentioned, you know, security of these systems and that people had actually implemented them.

我很好奇你能否分享一下那些具体的实现案例。

I'm curious if you could just share any of those implementations.

是的。

Yeah.

关于Frost我最喜欢的是它已经发展出自己的生态，人们围绕它做了很多工作。

So the thing I love about Frost is it's kind of evolved into its own thing and people are doing lots of stuff about it.

然后我是在Twitter上了解到这些的，在我看来这是最棒的事情。

And then I learned about it on Twitter, which is like the best thing in my opinion.

这太酷了。

It's so cool.

有个令人兴奋的项目叫Frost Snap。

So one project that's seemed exciting is Frost Snap.

这个名字真的很有趣。

So the name is really fun.

看起来他们正在为比特币生态系统和硬件实施Frost协议。

And it seems like they're implementing Frost, like, for the Bitcoin ecosystem and hardware.

哦，很酷。

Oh, cool.

再次强调，我觉得这很棒，因为我其实并不认识他们。

Again, I think it's amazing because, like, I actually don't know them.

我只是在Twitter上关注了他们的工作，我认为非常出色。

I just watched their work on Twitter, and I think it's it's great.

所以

So

我见过这些。

I've seen these.

那是一张照片，上面有些可以插在手机上的小设备，它们之间也能互相连接。

It was a picture of, like, little things that plug into a phone, and they can plug into each other as well.

哦，酷。

Oh, cool.

共同生成签名。

Together generate a signature.

哦，酷。

Oh, cool.

是啊。

Yeah.

让他们上节目会很有趣。

They'd be fun to have on the show.

所以，是啊。

So Yeah.

我很想听听他们具体是怎么做的。

I would I would love to hear how they're actually doing it.

这类签名方案有没有与零知识证明结合使用的案例？

Are there ever cases of these kinds of signature schemes being used together with ZKPs?

我先为这个问题提供一点背景信息。

And I'll give you just a bit of context to this question.

就像我们已经看到许多MPC与ZKP或FHE与ZKP的交叉应用案例。

Like we have seen a lot of crossovers with general MPC and ZKPs or FHE and ZKPs.

所以我很好奇，像Frost这样的方案能否与ZK结合使用？

So I'm just curious if like, can something like Frost be used with ZK?

我的意思是，显然它已经在Zcash中使用了，所以存在某种关联，但我不确定它是否真的在与ZKP共同使用？

I mean, obviously it's used in Zcash, so there's some connection, but I don't is it really kind of being used together with ZKPs?

是的。

Yeah.

我认为这是个有趣的问题，也是目前仍在探索的领域。

So I think this is an interesting question and something that's still being explored.

在Zcash的应用场景中，有趣之处在于Frost是在签名层面使用的。

So in the Zcash setting, it's interesting because Frost is used at the signing level.

即由签名者对交易进行签名。

So signers sign a transaction.

但证明者可以是独立的实体

But then the prover can be a separate entity

嗯

Mhmm.

它不需要被信任持有秘密签名密钥

That isn't trusted to hold the secret signing key.

因此你可以构建一个多签名者单证明者的场景

So you can have a setting where you have many signers and one prover.

哦，好的

Oh, okay.

我认为这种架构和系统设计非常精妙，它将不同角色分离，使签名密钥与证明功能得以区分

And that's, I think, a very nice architectural and system design and that these roles are separate so that you can set it separate out the signing key from the the prover functionality.

所以这就是Zcash目前的实现方式

So so that's what what Zcash is doing.

多方零知识证明生成领域已有相关研究

There has been work into multi party zero knowledge proof generation.

所以这方面已有一些研究。

So there's some work.

我们可以把链接放在节目说明里。

We can link it in the show notes.

但确实存在这样的研究：将你的见证数据、秘密见证数据，在多个证明者之间进行秘密共享。

But there's some work where you take your witness, your secret witness, and you secret share it among provers.

然后这些证明者以分布式的方式生成证明。

And then the provers generate the proof in a distributed manner.

接着他们将证明回传给你，由你进行组合。

And then they send it back to you, and then you combine it.

这个这个设计很有意思，我认为。

That's that's interesting, I think.

这项研究的缺点是必须将见证数据外包给其他参与方。

The downside of that work is you have to outsource your witness to other parties.

好的。

Okay.