密码货币的密码学有什么问题存在

2014 年，我曾在一篇文章和一场演讲中列出了一系列我认为对密码学货币领域的成熟有重大意义的数学、计算机科学和经济学难题。五年过去，沧海桑田，但在这些我们认定重要的事项上，到底取得了多少进展？在哪些挑战上我们成功了，哪些事情上我们失败了、又或者我们转变了看法？本文中我会历数2014年列举出的16大问题，并检视我们的进展。最后，我会给出2019年版的新难题。

我把难题分成了三类：（i）密码学难题，如果可解，应有纯数学形式的解决办法；（ii）共识理论，基本上就是要求对工作量证明和权益证明做改进；（iii）经济学问题，要求创造一种为不同参与方赋予经济激励的结构，并且一般都在协议层以外包含了应用层。虽然进度不一，但我们在所有类别中都看到了重大进展。

密码学问题

1. 区块链可扩展性

当前密码学货币领域面临的最大挑战之一就是可扩展性问题……对 “区块链数据量过大” 的担心是有道理的：如果只有小一部分人才有能力运行全节点，那么这些实体就可以秘密勾结并给自己分配额外的比特币，而其它用户则无力为自己伸张正义，因为只有自己验证区块才能发现非法区块。

问题定义：创造一种区块链结构，既能拥有比特币级别的安全保障，同时用于保证网络功能存续的最强大节点的规模上限会随着交易数量的增加而呈次线性增长。

现状：有大量的理论进步，但有待生产环境检验。

在可扩展性问题上，我们已经在理论上取得了大量进展。五年前，几乎还没有人思考过分片的可能性；现在，分片设计是大家司空见惯的东西了。除了以太坊 2.0，还有 OmniLedger、LazyLedger、Zilliqa，而且新论文几乎每个月都会冒出几篇来。我个人的观点是，在这个点上出现的进展会越来越多。最基本来说，我们已经有多项技术可以让验证者群体对超过单个验证者所能处理的数据安全地达成共识，同时技术还让客户端能够间接地验证区块的完全有效性和可得性，即便是在 51% 攻击的条件下。

下面列举出的可能是这些技术中最重要的一部分：

随机采样：可以随机选出一些验证者组成委员会，使其在统计意义上代表整个验证者群体：

https://github.com/ethereum/wiki/wiki/Sharding-FAQ#how-can-we-solve-the-single-shard-takeover-attack-in-an-uncoordinated-majority-model

错误性证明：让监测到错误的节点向其它节点广播自己发现的错误：https://bitcoin.stackexchange.com/questions/49647/what-is-a-fraud-proof

数据托管证明：让验证者可以概率性地证明自己下载并验证了一些数据：https://ethresear.ch/t/1-bit-aggregaTIon-friendly-custody-bonds/2236

数据可用性证明：当客户端具备区块头的区块体不可用时，让客户端可以探测到错误：https://arxiv.org/abs/1809.09044。也可以看看更新的编码化默克尔树提案。

还有一些更小的进展，比如用收据实现跨分片通信，还有 “常量因子” 强化技术如 BLS 签名聚合技术。虽说如此，完全分片的区块还是没能在现实中出现（尽管部分分片的区块链 Zilliqa 已经开始运行了）。理论上来说，剩下的争议都是细节上的，围绕着与分片组网稳定性、开发者体验和缓解中心化风险的各项挑战；基本的技术可行性看起来不再有疑问。但剩下的挑战都是不可能仅靠理论来解决的问题；只有开发出这样的系统、看到以太坊 2.0 或类似的链实际运行才能解决这些问题。

2. 时间戳

问题：创建一种分布式的激励兼容系统，无论它是区块链上的覆盖层还是区块链本身，能够以高准确度维护一个实时的时钟。所有合法用户的时钟围绕某个 “真实时间” 以 20 秒的标准差呈正态分布……没有任何两个节点的时间差会超过 20 秒。解决方案可以依赖现有的 “N 个节点” 概念；可以通过权益证明或者 non-sybil token 来组织节点（可联系下文的 9 号难题）。这个系统应能不断地提供时间，并且时间在超过 99% 的诚实参与者节点内部时间的 120 秒范围内。外部系统可能最终会依赖这个系统；因此，它应该能在攻击者无视激励措施且控制 25% 的节点条件下保持安全性。

现状：有一些进展。

以太坊在 13 秒的出块时间、无特殊高级时间戳技术的条件下运作得非常好；这个网络只是要求客户端不要接受所引时间戳比本地时间更新的区块。也就是说，这一技术还没有在高强度攻击下接受过检验。最新的网络调整时间戳提案尝试改变现状，它让客户端本地可以在并不知道高精确度的当前时间时对时间达成共识；不过这也还没有被检验过。总的来说，时间戳技术已从研究挑战的前沿退了下来；也许这一点会在众多权益证明区块链（包括以太坊 2.0 等）上线之后改变，到时候我们就能更具体地定位问题了。

3. 通用的计算过程证明

问题：创建程序 POC_PROVE（P，I） -》 （O， Q） 以及 POC_VERIFY（P，O，Q） -》 {0， 1} ，使得 POC_PROVE 以 I 为输入运行程序 P ，可以返回程序输出 O 以及一段计算过程证明 Q ；当 POC_VERIFY 以 P 、O 、Q 为输入时，可输出结果，表明 Q 和 O 是不是 POC_PROVE 算法使用程序 P 生成出来的。

现状：大量理论进展和实际进展。

这个基本上就是说，要构建一个 SNARK（或者 STARK 或 SHARK，等等）。而且我们已经做到了！SNARKs 越来越被充分理解了，甚至已经被用在多条区块链中（包括以太坊上的 tornado.cash 项目）。而且 SNARKs 是非常有用的，无论是作为隐私保护技术（Zcash 和 tornado.cash），还是作为可扩展性技术（例如 ZK Rollup、STARKDEX 以及 STARK 化的纠删编码数据根）。 不过还是有些效率上的问题，创造一种算术友好型的哈希函数是一个（看 此处 和 此处 了解那些突破性的候选方案）；高效证明随机内存存取是另一个。进一步来说，还有一个未解决的问题是，是不是此类方案的证明时间都遵循 O（n * log（n）） 的限制，还是说，有某种办法可以构建一个简洁的证明，开销仅呈线性增长，就像 bulletproofs 一样（但它的验证时间也会呈线性增长）。此外，这些现有方案有 bug 的风险也是一直存在的。总而言之，问题都是细节上的，在问题的基本层面已经没有疑问了。

4. 代码混淆

密码学难题的圣杯是创造一个混淆器 O：对给定的任意程序 P，该混淆器能产生一个次级的程序 O（P） = Q，只要给出相同的输入，P 与 Q 会返回相同的输出，并且更重要的是，Q 不会暴露 P 的任何信息。这样话，人们就可以在 Q 中隐藏口令、秘密的加密密钥，或者仅仅是用 Q 来隐藏算法本身的工作方式。

现状：进展缓慢。

翻译成大白话，这个问题就是说，我们想要一种方式来 “加密” 一个程序，使得加密后的程序能对同样的输入给出相同的输出，但原程序内部的机理又是完全隐藏起来的。这种技术的一种用场是一段包含一把私钥的程序，仅允许这把密钥对特定消息签名。

代码混淆方案对区块链协议来说是非常有用的，虽然用起来会比较微妙，因为我们必须面对这样的可能性：一个在链上的混淆过的程序可能会被复制并用在一个完全不同的环境中，由此产生许多不同的结果。让我很感兴趣的点在这里：我们可以用包含一些工作量证明的、混淆后的程序来代替运营者，从而能在抗串谋工具中移除中心化的运营者，因为在确定单个参与者的行动时，使用多个输入、运行多次程序的开销会非常大。

不幸的是，到目前为止，这还是一个难题。在这个问题上不断有人付出努力，一方面是创造一些建构（例如这个），尝试减少对那些我们不知道其实用性的数学对象（例如通用性密码学多重线性映射）的假设，另一方面是尝试做出有用数学对象的有用实现。不过，所有这些路径距离我们的目的——创建出可行且在已知条件下安全的代码混淆器——非常遥远。请看 https://eprint.iacr.org/2019/463.pdf 以了解对该问题的更一般化的概述。

5. 基于哈希的密码学

问题：创造一种签名算法，除了依靠哈希函数的随机特性以外没有别的安全假设；哈希函数对古典计算机保持 160 比特的安全性（即，根据 Grover 算法，对量子计算机保持 80 比特的安全性），并且具有最优大小及其他属性。

现状：有一些进展。

自2014年以来，这个题目下出现了两项进展：（1）SPHINCS，一种 “无状态” 的签名方案（“无状态” 的意思是，即使多次使用，也无需保存像 nonce 那样的计数信息）。该方案在《难题》一文出版后不久就出现了，提供了一种仅基于哈希函数的签名方案，签名大小在 41 kB 左右；（2）STARKs 也已经被开发出来了，所以人们可以基于 STARK 技术实现相近大小的签名。不仅是签名方案，连通用型零知识证明技术，都可以仅用哈希函数实现出来，这是我在 5 年前完全没有料到的事，我很高兴能见识到这一切。虽然说，签名的大小仍然是一个问题，但人们也在不断付出努力减少证明的大小（例如最近的 DEEP FRI），而且看起来进一步的进展效果会越来越强。

基于哈希函数的密码学中尚未解决的主要问题是签名聚合，就是类似于 BLS 签名方案所提供的功能。已知的是我们可以对许多 Lamport 签名方案生成 STARK，所以一个更有效率的签名方案可能就快出来了。（如果你还在思考基于哈希函数的公钥加密方案是否可能，答案是，不行，因为攻击者只需付出诚实用户平方级的成本就可以攻破这样的方案。）