,

Web3 如此重视零知识技术的基本概念，以至于现在它已经成为了一个基础，成为每项开发的焦点。 但其可扩展性、安全性和隐私优势并不使其值得信赖。

人们没有认识到，在 Web3 环境中，零知识 (ZK) 技术仍然相当新，而且并非没有缺陷。 开发人员正在积极解决ZK技术当前的问题，但该领域的创新本质意味着他们的概念化速度往往比构建速度快。

在没有充分理解ZK技术问题的情况下继续信任它，对于可持续的 Web3 未来来说是危险的。 在盲目依赖这项技术之前，我们需要彻底检查它及其潜在的缺点。

Web3 中不应该存在英雄——任何技术都不应该受到崇拜。

在理想的未来，zk技术将在所有链上活动中发挥更加综合的作用。 然而，该技术目前几乎作为附加功能或配件存在，而不是能够从根本上支持链上执行的东西。 这是因为正在开发的领域和产品仍然相对较新。

但 ZK技术领域已经发展到了使其自身面临过度复杂化风险的地步。 ZK 构建者和 Web3 用户之间的知识差距越来越大。

ZK 技术开发面临的其他问题包括在不影响项目完整性的情况下优化上市时间。ZK 证明和电路目前缺乏可访问性，因为开发人员需要学习特定领域语言 (DSL) 才能进一步证明这些计算。

这是一个知识密集型的过程，最好的例子就是 Scroll 的 pre-alpha 测试网和主网启动之间几乎花费一年半的时间。 通过花时间进行正确的实施和代码审核，Scroll 的上市时间可能会因为通过一些定制的 Halo2 相关 zkDSL 实施的 zkEVM 电路代码的深入审查过程而受到阻碍。

这是一个问题，因为全球只有少数人拥有 DSL 和密码学的第一手知识。 随着我们让更多的开发人员使用先进的ZK技术，我们需要确保ZK技术的每个组件都是可独立验证的。

然后，还有可配置性的挑战。 每一次必要的升级最终都是对新构建的系统的彻底检修，而不是开发人员在现有框架上构建的意义上的“升级”。

支持ZK 的项目已经在致力于开发能够简化开发人员构建过程的解决方案。 这将有助于解决关键问题，包括上市时间缓慢、作为独立方生成证明的成本、电路的可配置性以及学习特定密码语言的要求。

构建更简单的方法来尽可能轻松地将代码编译成功能齐全的电路对于确保支持 ZK 的应用程序的可组合性至关重要。 编译器等工具可以快速帮助验证代码的功能。 开发人员还可以使用多种编码语言来开发更高效的应用程序。

继续关注可扩展性和安全性会影响该领域正在进行的其他问题的关键工作。 ZK 技术的缺陷被忽视只是因为该行业迫切需要可扩展性和安全性，而忽视了成本和复杂性的缺点。

事实是，ZK技术需要让自己变得简单。 即使开发人员不是密码学或电路设计专家，他们也应该可以使用该技术。

ZK基础设施提供商需要创建工具，使构建支持ZK的应用程序变得更容易，并简化开发人员的构建过程。

简化生产程序并降低与基础设施相关的成本是解决这些问题的一种方法。 另一个可能的方法是为希望进入该领域的开发人员提供更多资源和支持，例如教育计划和指导机会。

归根结底，即使有了ZK技术，也不要仅仅信任，还要验证。

这超出了基线交易结算的范围，它应该适用于我们用来构建或编译代码的工具，并且开发人员和用户应该更多地认识到这一点，以鼓励项目之间的完整性。