1. Intel 软件防护扩展技术 Intel® SGX

Intel® SGX 的设计主旨是为用户应用程序提供可信的执行环境，使得应用程序有能力在用户地址空间中开辟一段特别的，受保护的内存空间，并对这段受保护的内存空间实行严格的访问控制和加密操作来保障数据机密性和代码完整性，确保即使是 Hypervisor、BIOS，操作系统等特权应用都不能随意访问这段地址空间，这一段地址空间被称之为 Enclave（称之为飞地）。

按照文章的前部分介绍，把应用程序部署在云上，需要验证程序确实运行在 TEE 里，具体更多的 SGX 技术细节，请参见 Intel 官方的技术文档。以及 Intel 架构开发者手册。验证包括本地验证和远程验证。本地验证指在同一个平台上，让不同的 Enclave 互相验证 Trusted Computing Base（TCB）。远程验证是指让一个平台中运行的 Enclave 向远端的信赖凭证者 Relying Party 证明自己的 TCB，证明自己运行在 SGX TEE 中，并且没有被篡改，同时证明当前的 CPU SGX 安全版本信息。

SGX 应用程序涉及两部分：安全区和非安全区。开发者或者用户可以把涉及敏感数据的处理、Key 的保护等都放在 Enclave 里面，从而将应用程序的代码、数据划分为受信任和不受信任的组件，因此开发者或者用户需要决定哪些组件应该置于 Enclave 内部，哪些置于 Enclave 外部。

2. Intel 信任域扩展技术 Intel® TDX

Intel® TDX 旨在将虚拟机（VM）与平台上的虚拟机管理程序（VMM）和任何其他非信任域 Trust Domain (TD) 的软件隔离，以保护 TD VM 免受各种软件的安全威胁。

TDX 的设计思路是将整个虚拟机 VM 放在一个 TEE 可信执行环境里，这样不管应用在私有云还是公有云上，不需要再对应用程序和数据做受信任和不受信任的划分和修改，只要操作系统支持就行。

TDX 基本思路就是引入新的 CPU 工作模式，然后通过对内存加密技术，将两个虚拟机用不同的 key 加密，同时 key 由 CPU 来直接进行管理。本质上讲，TDX 是通过两种技术方式来配合实现，一种就是新的 CPU 模式，叫做安全仲裁模式 Secure Arbitration Mode（SEAM），第二种是多密钥内存加密技术方式 Multi-key Total-Memory-Encryption（MKTME）。SEAM 模式使用新的指令，例如 SEAMCALL, SEAMRET, SEAMOPS, TDCALL 等来实现和 TD OS，以及 Host/VMM 交互。同时，提供特定区域的物理内存来保护 Intel TDX Module 代码模块，通过 Intel Authenticated Code Module (SEAMLDR)来装载。多密钥内存加密 MKTME 技术中，MKTME engine 通过 PCONFIG 指令来分配和设置各个 TD VM 的内存加密 Keys。TDX 将内存分为两个部分，私有和共享内存。在 TDX 下还是需要在外部加固的，加固的时候需要共享内存，这部分内存外部是可以读取的，因为有些虚拟化或半虚拟化设备需要和外部通信时，是需要 host 操作系统有能力访问来提供网络等服务的。

对比

当前的 Intel® TDX 认证的本质原理和 SGX 认证类似，也需要提供远程证明来验证其运行在 TEE 环境里。更多详细的 TDX 技术说明，请参见 Intel 官方网站的 Intel® TDX 技术规范和白皮书。

Intel® TDX 和 Intel® SGX 是用来解决不同问题的。TDX 是把整个软件包不做修改直接放到虚拟机上就能实现安全，而 SGX 关注应用层面，通过对飞地 Enclave 来保障机密性和完整性，用户根据业务场景需求可以选择不同的技术。

参考文档

https://www.intel.com/content/www/us/en/developer/tools/trust-domain-extensions/overview.html
https://www.intel.com/content/www/us/en/products/docs/accelerator-engines/software-guard-extensions.html
https://cloud.tencent.com/developer/news/918918

基础信息

官网：https://www.ata.network/
GitHub： https://github.com/automata-network
docs: https://docs.ata.network/

重点关注项目

• https://github.com/automata-network/automata-sgx-sdk
• https://github.com/automata-network/sgx-prover
• https://github.com/automata-network/sgx-scaffold/tree/main
• https://github.com/automata-network/automata-dcap-attestation
• https://github.com/automata-network/SGXDataCenterAttestationPrimitives

文档关键信息

TEE 验证器的设计

带有 Scroll 的 TEE Prover 的架构有两个主要组件：

• SGX 证明器。一种链下组件，用于检查安全区域内区块执行后状态根是否与现有状态根匹配，并将执行证明 (PoE) 提交给 SGX 验证器。
• SGX 验证器。确认 SGX 证明器提出的状态转换正确性的 L1 合约。它还验证 Intel SGX 飞地提交的证明报告，以确保证明器的完整性。

Intel SGX 的链上验证

远程认证允许以编程方式验证英特尔 SGX 飞地的属性和完整性。这是建立并确保其执行的任何计算或数据处理都是值得信赖的关键过程。

https://docs.ata.network/tee-overview/tee-prover

多重证明器 AVS 的工作原理

• 任务提交：协议构建者参与 AVS 并提交多重证明任务。在汇总场景中，这包括对 L2 向 L1 提交的批量交易进行采样和证明。
• 验证器注册：独立操作员注册以承担这些任务。操作员利用可重现的构建来运行 TEE 验证器，并通过 Automata 的TEE Compile进行验证，以确保构建过程的完整性。
• 执行和证明：每个操作员（证明者）在其选择的 TEE 平台上执行任务。生成证明以验证执行的正确性和完整性。
• 链上验证：将证明提交至区块链，智能合约充当证明人的角色并在链上进行验证。
• 奖励发放：成功完成任务后，向操作员发放奖励。

https://docs.ata.network/tee-overview/multi-prover-avs-eigenlayer

multi-prover-avs 代码分析

GitHub： https://github.com/automata-network/multi-prover-avs/tree/main

目录结构

═── contract：Solidity合约，包括AVS合约和证明层合约。
│ │ │ ── dcap-v3-attestation：英特尔 SGX 的 Dcap 认证链上验证库。
│ │ ── src：AVS 合约的源文件。
│ └── test：智能合约的测试。
═── operator：运算符实现。
═── aggregator：聚合器实现。
═── sgx-prover：TEE 证明器的 sgx 版本。

AVS任务描述

任务定义：寻求利用可信执行环境 (TEE) 内的独立执行来确定其正确性的状态转换或计算过程。

struct StateHeader {
    uint256 identifier;
    bytes metadata;
    bytes state;
}

这是提交给证明者的状态头结构，下面是详细解释：

• identifier：处理任务的标识符，用于区分不同类型的任务，并用于计算各个算子的贡献
• metadata：描述特定任务的元数据，例如keccak256(abi.encodePacked(chainID, blockNumber))用于证明特定区块高度的区块链状态的任务的元数据
• state：TEE 证明器产生的最终状态，可以是区块链的根状态，也可以是 zk 电路证明的语句

AVS 架构

AVS 的架构包含：

• Eigenlayer 核心合约
• AVS 合同
  • 未来将添加 ServiceManager，允许操作员提交任务、奖励和削减逻辑
• 鉴证合约
  • 管理各种 TEE 证明器的注册/注销和活跃性，它将验证不同 TEE 平台的认证，例如 Intel SGX、AMD SEV、ARM TrustZone 等
  • TEEProverRegister 是运营商和聚合器使用的认证层的接口
• 聚合器
  • 汇总来自操作员的 BLS 签名并将汇总状态提交给 AVS
  • 与自动机证明层交互，检查每个证明者（操作员）的有效性，未能通过证明验证或活性挑战的将被拒绝处理任务，直到其再次有效。
• 操作员
  • 从 TEE 证明者处获取状态证明并将其提交给聚合器
• TEE 证明器
  • TEE 证明器可以证明给定任务的最终状态，例如 zk-rollup L2 的证明器将在 TEE 内部执行区块并在特定区块处生成根状态

AVS 工作流程

以下是工作流程的详细图表

成分：

• 操作员
• 聚合器
• 多功能AVS
• TEE 活跃度合约
• 鉴证合同

工作流程分为两部分：

1. 设置

   • 按照Eigenlayer 的文档进行质押并注册成为 Multi-prover AVS 的运营商
   • 生成证明并注册为 TEE 证明者，不同的 TEE 技术，证明及其生成过程不同。例如，dcap-v3-attestation是验证 Intel SGX Dcap 证明的合约

2. 在职的

   • 除了操作员处理任务之外，他们必须定期完成活性挑战，否则将被视为无效，其提交将被聚合器拒绝
   • 算子获取新任务并在 TEE 内部完成计算
   • 操作员签署最终状态并将其与签名一起发送给聚合器
   • 聚合器将在接受运营商的提交之前获取其有效性
   • 聚合器聚合所有 BLS 签名并提交给 AVS 服务管理器

TEE 委员会和法定人数

TEE 委员会是一组负责处理特定类型任务的法定人数。例如，在特定区块高度证明 Zk-Rollup 的根状态。操作员无需主动选择委员会，而是通过加入法定人数自动属于委员会。引入有利于TEE Committee操作员和任务更有组织的结构化。并为未来的增强奠定了基础，包括奖励机制和法定人数之间权益分配的约束。

TEE Quorum的概念与 Eigenlayer 使用的 Quorum 定义一致，但每个 Quorum 都与一个 TEE 平台相关联，例如 Intel SGX。每个 Quorum 都属于一个委员会，操作员可以选择加入任何 Quorum，但只有拥有必要证明的操作员的投票才会被聚合器接受。

如果您有兴趣加入以太坊主网上的 Multi-Prover AVS，请访问Operator 设置存储库。入职指南可在此处获取。

从源代码编译

操作员

go build -o out/operator ./cmd/operator

聚合器

go build -o out/aggregator ./cmd/aggregator

相关文档

https://scroll.io/blog/scaling-security
https://blog.ata.network/verifiability-as-the-missing-piece-for-ai-agents-in-web3-504839dca893
https://blog.ata.network/towards-a-common-tee-stack-71a7812a4bf9
https://blog.ata.network/automata-joins-the-superchain-ecosystem-launching-on-optimisms-op-stack-da25840cc658
https://atanetwork.notion.site/Multi-Prover-AVS-with-TEE-545319c42885489196142d966f0ede86
https://gramine.readthedocs.io/en/stable/attestation.html
https://sgx101.gitbook.io/sgx101

网站：https://attest.org/
docs: https://docs.attest.org/docs/welcome
github: https://github.com/ethereum-attestation-service

随着本白皮书的发布，Neon EVM 引入了多项功能，以统一 Solana 与部署在 Neon 上的 EVM dApp 之间的用户体验。此版本遵循Solana 网络扩展方法中描述的愿景，并描述了 Neon EVM 基础设施的发展方式。

本文描述的概念将会在 SDK 中实现，具体如下：

• Solana 签名支持：使 Solana 用户能够使用他们现有的 Solana 钱包签署 Neon EVM 交易，从而无需 EVM 签名和钱包。
• 链上内存池：引入链上系统，无需依赖外部工具即可高效地安排和执行 Neon EVM 交易。
• 关联 Neon 账户：创建抽象 Solana 地址的 Neon 账户，并实现 Solana 用户和 Neon EVM 之间的无缝交互。
• Neon 交易的受控树：实现交易的原子和并行执行方法，管理状态变化并聚合复杂交互的结果。
• 基于意图的执行：提供一种处理交易意图的机制，尽管 Solana 存在局限性，但仍能提高 EVM 合约和 Solana 程序之间的互操作性。

点击此处阅读完整白皮书

挑战：为 Solana 用户解锁以太坊 dApp

Solana 和以太坊是领先的 L1 区块链之一，各自都拥有活跃的 dApp 生态系统和性能优势。然而，这两个环境尚未相互交互，主要是由于编程语言、开发工具和基础设施的差异。

虽然 Neon EVM 允许 EVM dApp 为类似以太坊的用户访问 Solana 代币，但之前的解决方案涉及多个钱包的管理。在 Neon EVM 上执行交易需要使用 secp256k1 椭圆曲线的 EVM 签名，因此必须使用 MetaMask 等 EVM 钱包。这一要求对习惯于 Solana 中使用的 ed25519 签名的 Solana 用户以及无法使用 Phantom、Backpack 和 Solflare 等 Solana 钱包的用户来说是一个重大障碍。

通过下面提出的解决方案，EVM 开发人员可以通过减少碎片化和简化入职培训来原生地利用 Solana 用户群。

探索“Solana-Native”功能

白皮书介绍了 Solana 的各种原生功能。需要关注的五个关键功能包括：

Neon EVM 中的 Solana 签名支持

为了消除 Solana 用户管理额外 EVM 钱包的需要，Neon EVM 修改了其交易验证流程以接受 Solana 的 ed25519 签名。此修改包括：

• 签名验证适配：调整 Neon EVM 以识别和验证 ed25519 签名。
• 自定义交易类型：利用交易类型属性定义与 Solana 签名兼容的自定义交易类型，并遵守 EIP-2718 的类型化交易信封。

从技术上讲，Solana 用户的 EVM 地址 (ethAddress) 是使用 Keccak-256 哈希函数应用于 Solana 公钥 (solanaPublicKey) 得出的。地址派生公式为：

此方法采用哈希的最后 20 个字节来形成与 EVM 兼容的地址，从而确保唯一且抗冲突的映射。然后使用 Neon EVM 中的 Solana 原生加密库来验证 Solana 签名，从而确保安全验证。

好处

• Solana 用户可以使用现有的 Solana 钱包（例如 Phantom/Backpack/Solflare）签署 Neon 交易。此集成减少了用户与 Solana 上的 EVM dApp 交互所需的步骤，并将资产保留在熟悉的 Solana 钱包环境中。
• 使用 Solana 钱包无需转移资金，只需将 SOL 用作 gas 代币和 Solana 网络 RPC。从用户的角度来看，资产交换是通过发送 SPL 代币并接收所选资产的 SPL 代币来执行的。

创建关联 Neon 账户，统一资产管理

Neon EVM 通过整合 Solana 和 Neon EVM 生态系统来解决流动性分散问题，使用户能够与兼容 EVM 的 dApp 进行交互，而无需进行不必要的资产转移。以前，用户依靠 NeonPass 将 SPL 代币从 Solana 钱包转移到 Neon EVM 账户，这使资产管理变得复杂，流动性也变得分散。现在，随着 ERC20forSPL 合约的引入，这一过程得到了简化，该合约无缝连接了两个生态系统。

拥有 Solana 钱包的用户通过关联代币账户 (ATA) 管理其 SPL 代币。Neon EVM 使用 Keccak-256 哈希将其 Solana 公钥映射到与 EVM 兼容的地址，从而创建一个关联的 Neon 账户，其中包含与 EVM 兼容的地址、Solana 公钥、交易计数器、链标识符和内部余额的字段。

当用户与 Neon EVM 上的 dApp 交互时，ERC20forSPL 合约首先检查其内部余额。如果余额不足，它会查询 Solana 上用户的 ATA 以检索必要的 SPL 代币。此过程消除了 NeonPass 转账的需要，并允许用户在 Neon EVM 中操作，同时将资产保留在 Solana 上。

好处

• 简化资产管理：用户可以控制其 Solana 钱包中的资产，而无需中间转账（例如通过 NeonPass）。
• 降低交易成本：通过利用链上余额查询并避免冗余传输，用户在与 EVM dApp 交互时可以降低成本。

使用链上内存池实现高效的交易管理

高效的交易调度和执行管理对于流畅的用户体验至关重要。Neon EVM 实现了链上内存池来存储和管理已调度的 Neon 交易。这允许 Solana 用户直接从他们的 Solana 钱包调度 Neon EVM 交易，Neon 代理会代表他们检测和执行这些交易。

TreeAccount 是一个专用帐户，具有预定的 Neon 交易、余额和执行状态。它包括以下内容：

• 付款人的 EVM 地址：与 Solana 用户关联的 EVM 地址。
• 最后一个槽位：修改帐户的最后一个 Solana 槽位。
• 链 ID：链命名空间的标识符。
• Gas Limits：允许执行的最大气体量。
• 余额：为执行交易而保留的资金。
• 交易清单：预定的 Neon 交易及其执行详情。

交易调度协议涉及用户向 Neon EVM 程序提交 Neon EVM 交易，该程序会验证并将其添加到链上内存池中。然后，Neon 代理会监控内存池并相应地执行交易。

对于超出 Solana 大小限制的较大交易，只有交易哈希存储在链上，完整交易会发送到链下 Neon 代理。这种方法可以实现可扩展性并高效处理较大的交易，而不会影响网络性能。

好处

链上内存池增强了可扩展性，确保了交易完整性，并保持了状态更改的原子性。用户受益于高效的交易管理，开发人员可以利用此系统创建更复杂、响应更快的 dApp

用于复杂交互的受控事务树

为了克服 Solana 的即时状态应用和对交易还原的缺乏支持（这阻碍了 EVM 合约和 Solana 程序之间的复杂交互），Neon EVM 引入了 Neon 交易的受控树。该机制通过在树结构中组织交易来管理复杂的交互场景，其中每个节点代表一个 Neon 交易，父子关系定义执行依赖关系。

主要特点包括：

• 原子交易：每个 Neon 交易都是原子的，在完成时存储状态变化。
• 并行执行：没有依赖关系的事务可以并行执行，优化性能。
• 结果聚合：合约可以生成多个交易，并在后续交易中聚合结果。

好处

• 这项创新使开发人员能够构建更复杂、更集成的应用程序，通过实现受控状态变化的原子和并行执行来克服限制。
• 它可以增强交互的稳健性，并通过防止由于单个错误而导致的整个交易失败来改善用户体验。

基于意图的条件交易执行

Neon EVM 采用了意图驱动执行，为用户和开发者提供了根据特定条件或市场状态执行交易的灵活性。意图被定义为指定执行条件的简单 EVM 代码，遵守静态调用规则（不能修改状态）。Neon 代理会在执行交易之前评估这些意图。如果条件不满足，则跳过交易，用户无需支付任何费用。

此功能可以实现：

• 自动交易策略：仅当市场条件满足特定标准时才执行交易。
• 条件操作：当链上发生特定事件时执行诸如代币交换之类的操作。

好处

基于意图的执行可以更好地控制交易执行，提高资源效率，并减少用户不必要的成本。它增强了 dApp 对实时情况的灵活性和响应能力。

结论

征求反馈和协作：这份白皮书启动了 Neon EVM 的 Solana 原生演进，寻求不同视角的意见，并促进以太坊和 Solana 社区的开发者参与。
在这里，我们发布了第一稿，并邀请构建者社区积极贡献并开始评估您 dApp 上的实施情况。白皮书可在此处访问。

白皮书的第一个功能——即将发布的 Solana 签名钱包 SDK——已付诸实践。Solana 签名功能在 EVM 端已完成，并在代理端部分实现——目前正在测试和审核中。此外，敬请期待即将发布的用例和演示版本！

加入我们，在 Solana 上构建 dApp 的未来。立即探索 Neon EVM！

关于 Neon EVM
Neon EVM 是同类产品中的第一个，是 Solana 上的网络扩展，旨在将以太坊虚拟机 (EVM) 兼容性无缝集成到 Solana 的高性能生态系统中。通过在 Solana 的基础层内本地运行，Neon EVM 为以太坊开发人员提供了一种快速、高吞吐量的途径，可以在 Solana 上部署他们的 EVM dApp，而无需用 Rust 重写他们的合约。

有关 Neon EVM 和未来更新的更多信息，请访问neonevm.org并通过Twitter或Discord与社区联系。

原文：https://neonevm.org/blog/Enabling-Solana-Users-to-Access-EVM-dApps-Running-on-Solana

零知识简洁非交互式知识论证 (Beam-SNARK) 是一种开创性的方法，它允许人们在不透露任何其他信息的情况下证明陈述的真实性。但这为什么有用呢？

零知识证明有广泛的应用场景，例如：

1. 关于私人数据的证明陈述：

• 确认某人的银行余额超过某个限额，但不透露具体金额。
• 核实银行在过去一年内没有与特定实体进行过交易。
• 匹配 DNA 样本但不透露完整的基因图谱。
• 显示高于一定值的信用评分但不透露详细信息。

2. 匿名授权

• 证明用户有权访问网站的限制区域，而无需分享其身份（例如登录凭据）。
• 确认在授权地区的居住权但不透露具体位置。
• 在不透露身份的情况下验证有效地铁通票的所有权。

3. 匿名支付：

• 无需关联身份即可进行付款。
• 不披露收入而纳税。

4. 外包计算：

• 委托复杂的计算，同时确保结果正确，无需重复工作。
• 将区块链模型从通用计算转变为一方计算、其他方验证的模型。

零知识证明的底层数学和密码学简直就是奇迹。自 1985 年开创性的论文“交互式证明系统的知识复杂性”以来，该领域已经活跃了四十多年。非交互式证明的引入在区块链环境中尤为关键。

在任何零知识证明系统中，都有两个关键参与者：

• 证明者：想要让验证者相信某个陈述的真实性的人。
• 验证者：无需获取任何额外知识即可检查证明者主张的有效性的人。

该系统必须满足三个核心属性：

1. 完整性：如果陈述是真实的，则证明者可以说服验证者。
2. 健全性：作弊的证明者无法让验证者相信错误的陈述。
3. 零知识：交互仅揭示陈述是否真实，而不揭示其他任何内容。

Beam-SNARK 将这些原理应用于通用计算，为实际应用提供了一个优雅的解决方案。

证明的媒介

为了理解 Beam-SNARK，让我们从一个简单的例子开始，而不深入研究零知识或交互性。

假设我们有一个 10 位的数组，并且我们想要向验证者（例如，程序）证明所有位都设置为 1。

假设我们有一个长度为 10 的位数组，并且我们想要向验证者（例如程序）证明所有这些位都设置为 1。

验证者每次只能检查一位。为了验证该声明，验证者可以按随机顺序检查位：

• 一次成功检查后，验证者对该声明的信心为 10%。
• 如果某个位为 0，则该断言立即被推翻。
• 为了获得更高的置信度（例如 50% 或 95%），验证者必须执行更多检查，与阵列的大小成正比。这种方法对于大型数据集来说不切实际。

相反，我们可以利用具有独特属性的多项式。多项式在图形上显示为曲线，由数学方程定义。

上图曲线对应多项式：f(x) = x³ — 6x² + 11x — 6。多项式的次数由其 x 的最大指数决定，在本例中为 3。

多项式有一个优点，即如果我们有两个次数最多为 d 的不相等多项式，它们最多只能在 d 个点处相交。例如，让我们稍微修改一下原始多项式 x³ — 6x² + 10x — 5，并将其可视化为绿色：

如此微小的变化会产生截然不同的结果。事实上，不可能找到两个不相等的多项式，它们共享一条连续的曲线块（单点块的情况除外）。

此属性源自查找公共点的方法。如果我们想找到两个多项式的交点，我们需要使它们相等。例如，要找到多项式与x轴的交点（即f ( x ) = 0），我们使x ³ — 6 x ² + 11 x — 6 = 0相等，并且该等式的解将是这些公共点：x = 1、x = 2 和x = 3，您也可以清楚地看到，在上图上蓝色曲线与x轴线相交的位置，情况确实如此。

同样，我们可以将原始多项式和修改后的多项式相等来找到它们的交点。

所得到的多项式是 1 阶的，显然有一个解x = 1。因此只有一个交点：

对于任意次数为d 的多项式，任何此类方程的结果始终是次数最多为d的另一个多项式，因为没有乘法可以产生更高的次数。例如：5 x ³ + 7 x ² — x + 2 = 3 x ³ — x ² + 2 x — 5，简化为 2 x ³ + 8 x ² — 3 x + 7 = 0。代数基本定理告诉我们，次数为d 的多项式最多可以有d 个解（更多内容见下文），因此最多有d 个共享点。

因此，我们可以得出结论，在任意点处对任何多项式的求值类似于对其唯一身份的表示。让我们在x = 10 处求值示例多项式。

事实上，在所有要评估的x选择中，只有最多 3 个选择在这些多项式中具有相同的评估，而所有其他选择都会有所不同。

这就是为什么如果证明者声称知道某个多项式（无论其度数有多大），而验证者也知道的话，他们可以遵循一个简单的协议：

• 验证者为x选择一个随机值，并在本地评估多项式
• 验证者将x提供给证明者，并要求其计算相关多项式
• 证明者在x 处评估多项式，并将结果提供给验证者
• 验证者检查本地结果是否等于证明者的结果，如果是，则该语句具有很高的置信度

例如，如果我们考虑x的整数范围从 1 到 1⁰⁷⁷，则评估不同的点数为 1⁰⁷⁷ — d 。因此， x意外“击中”任何d个共享点的概率等于（这被认为是可以忽略不计的）：

注意：与低效的位校验协议相比，新协议仅需要一轮，并且对该声明具有压倒性的信心（假设 d 足够小于范围的上限，则几乎为 100%）。

这就是为什么多项式是 Beam -SNARK的核心，尽管也可能存在其他证明媒介。

原文：https://medium.com/@Moonchain_com/why-and-how-beam-snark-works-94f703cf1413