作者:Vitalik
翻译&校对:阿剑、陈亮&阿剑
来源：以太坊爱好者
特别感谢JustinDrake和JinglanWang的反馈。
2014年，我曾在一篇文章和一场演讲中列出了一系列我认为对密码学货币领域的成熟有重大意义的数学、计算机科学和经济学难题。五年过去，沧海桑田，但在这些我们认定重要的事项上，到底取得了多少进展？在哪些挑战上我们成功了，哪些事情上我们失败了、又或者我们转变了看法？本文中我会历数2014年列举出的16大问题，并检视我们的进展。最后，我会给出2019年版的新难题。
我把难题分成了三类：密码学难题，如果可解，应有纯数学形式的解决办法；共识理论，基本上就是要求对工作量证明和权益证明做改进；经济学问题，要求创造一种为不同参与方赋予经济激励的结构，并且一般都在协议层以外包含了应用层。虽然进度不一，但我们在所有类别中都看到了重大进展。
密码学问题
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签名聚合技术。虽说如此，完全分片的区块还是没能在现实中出现。理论上来说，剩下的争议都是细节上的，围绕着与分片组网稳定性、开发者体验和缓解中心化风险的各项挑战；基本的技术可行性看起来不再有疑问。但剩下的挑战都是不可能仅靠理论来解决的问题；只有开发出这样的系统、看到以太坊2.0或类似的链实际运行才能解决这些问题。
2.时间戳
问题：创建一种分布式的激励兼容系统，无论它是区块链上的覆盖层还是区块链本身，能够以高准确度维护一个实时的时钟。所有合法用户的时钟围绕某个“真实时间”以20秒的标准差呈正态分布……没有任何两个节点的时间差会超过20秒。解决方案可以依赖现有的“N个节点”概念；可以通过权益证明或者non-sybiltoken来组织节点。这个系统应能不断地提供时间，并且时间在超过99%的诚实参与者节点内部时间的120秒范围内。外部系统可能最终会依赖这个系统；因此，它应该能在攻击者无视激励措施且控制25%的节点条件下保持安全性。
现状：有一些进展。
以太坊在13秒的出块时间、无特殊高级时间戳技术的条件下运作得非常好；这个网络只是要求客户端不要接受所引时间戳比本地时间更新的区块。也就是说，这一技术还没有在高强度攻击下接受过检验。最新的网络调整时间戳提案尝试改变现状，它让客户端本地可以在并不知道高精确度的当前时间时对时间达成共识；不过这也还没有被检验过。总的来说，时间戳技术已从研究挑战的前沿退了下来；也许这一点会在众多权益证明区块链上线之后改变，到时候我们就能更具体地定位问题了。
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。而且我们已经做到了！SNARKs越来越被充分理解了，甚至已经被用在多条区块链中。而且SNARKs是非常有用的，无论是作为隐私保护技术，还是作为可扩展性技术。不过还是有些效率上的问题，创造一种算术友好型的哈希函数是一个；高效证明随机内存存取是另一个。进一步来说，还有一个未解决的问题是，是不是此类方案的证明时间都遵循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比特的安全性，并且具有最优大小及其他属性。
现状：有一些进展。
自2014年以来，这个题目下出现了两项进展：SPHINCS，一种“无状态”的签名方案。该方案在《难题》一文出版后不久就出现了，提供了一种仅基于哈希函数的签名方案，签名大小在41kB左右；STARKs也已经被开发出来了，所以人们可以基于STARK技术实现相近大小的签名。不仅是签名方案，连通用型零知识证明技术，都可以仅用哈希函数实现出来，这是我在5年前完全没有料到的事，我很高兴能见识到这一切。虽然说，签名的大小仍然是一个问题，但人们也在不断付出努力减少证明的大小，而且看起来进一步的进展效果会越来越强。
基于哈希函数的密码学中尚未解决的主要问题是签名聚合，就是类似于BLS签名方案所提供的功能。已知的是我们可以对许多Lamport签名方案生成STARK，所以一个更有效率的签名方案可能就快出来了。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。