java怎么开发saas（Aleo联合创始人HowardWu出席ZKP编程语言在线会议）

近期Aleo 联合创始人Howard Wu参与了一场关于ZKP（零知识证明）的编程语言在线会议，这场在线会议汇聚了来自行业顶级项目的8位专家，他们都将在各自的领域分享自己的观点。

ZKP是区块链领域及其他领域最重要的技术之一。

在过去的5到10年中，我们看到ZKP在理论和实践方面都取得了巨大的进步，但在应用程序中使用它们对开发人员来说并不容易，很多区块链初创公司和组织正在努力解决这一问题

以下是ZKP编程语言内容精华部分：

我们应该如何在各种语言中进行选择？

Shahar：应该考虑3个方面：新语言入门成本、可扩展性需求和生态系统支持。

Howard：用例是关键：根据应用程序的功能和属性决定语言。例如：明智地选择链上与链下。广泛持久的数据存储或可共享程序应该在链上，快速准备或单人确定性游戏应该在链下。

Gautam：我们选择的是生态系统而不是语言。例如，对于Cairo，我们实际上选择了StarkWare，而对于Leo，我们选择了Aleo。

通过设计，某些语言低估了底层机制是zkSNARK的事实，例如，如果它在 zkSNARK电路内编码完整的虚拟机。该语言编译为虚拟机的指令集，因此开发人员可能不知道背后的zkSNARK电路。相比之下，一些语言/API使开发人员能够构建专门的zkSNARK电路。

Daniel：开发人员的选择有限，因为他们本质上是在考虑Gas成本和平台规格等因素来选择生态系统。未来，开发人员不应受制于流行的领域特定语言。

像zkEVM这样的通用系统会在未来取代ZK特定的语言吗？

Wei：zk-VM旨在扩展提议，但特定领域的语言可以更好地适应支付等特定问题。泛化系统和ZK特定语言应该在未来共存。

Shahar：CPU不能代替集成电路，就像通用程序不能代替需要低级和更高效的特定语言一样。

Gautam：VM的内存和跟踪开销很大，因此并非所有协议都应该通过通用系统来提高效率。

Daniel：zkEVM的Prover效率不应该成为未来更好的并行化的问题。排序是目前的主要瓶颈，应该根据排序性能来选择语言。

验证用 ZKP 编写的程序有哪些挑战？

Yanju：我们可以做不同的验证方式。例如，间接定理证明器和自动形式验证。

间接定理证明器需要专家指定所需的属性，自动形式验证使用符号执行将程序从目标语言转换为逻辑公式。编写规范的开发人员友好的方式是一个挑战，我们没有一个大的素数理论来有效地计算验证。

Shahar：实际上在ZKP中验证程序更容易，因为我们编译了程序之后就无法更改，所以我们可以依靠证明来保证程序的正确性。

Howard：有两种方法可以考虑对这个领域的程序进行验证。

首先，一个验证编译器。您希望通过正确编译和综合电路来确保编译器本身输出正确的程序，但构建一个程序一直具有挑战性。

其次，程序的一次性证明，是一个更容易处理的问题。开发人员只需要确保程序本身根据高级描述正确合成即可。但是，一次性证明可能会增加复杂性。

在多语言多链上开发的未来是什么？

Daniel：今天，EVM 是我们所拥有的最接近通用标准的东西，但它还不是理想的语言，尤其是对于 ZK-rollup。

Howard：我们最终可能不会得到一个很好的答案，但我们会有很多好的解决方案和平台。类似于REST API的东西将会出现，允许不同的链和语言相互交互。

当有多个语言框架来执行ZKP时，如何避免“孤岛”？

Joshua：使用中间表示，比如 Vamp-IR，肯定是有帮助的。开发人员应该分享他们编写不同电路的手工技巧，并在中间层中使用它们。

当新的证明系统频繁出现时，如何平衡快速采用和安全稳定性？

Howard：VC应该资助一家在ZKP系统上做SparkNotes的初创公司，因为很难跟踪所有新的证明系统。直接阅读特定证明系统的目标、属性和权衡将是有益的。当PLONK刚问世时，并没有正式的同行评审过程，它是出于需要而发明的。新系统的价值可能不是建立在学术严谨的基础上，而是业内人士积累知识的结果。

Shahar：如果新系统能够提供关键功能，那是值得的。否则，最好使用万无一失的东西。

最后重要的部分

Aleo第二期社区大使计划审查结果即将公布，官方预定时间是一个月（也就是7月初），目前在Discord频道尚未有准确时间，大家可以持续保持关注，等待结果出炉，按照官方提示完成KYC