原文：Joining Forces: SHARP
翻译及校对：「Starknet 中文社区」

• SHARP（SHARed Prover，共享证明器）生成聚合 Cairo 程序的 STARK 证明，允许任何应用程序将交易提交到同一证明。想象一个滴滴拼车池，不过是为了拼 STARK 证明。这种「拼车」动态意味着即使是小型应用程序也可以获取 STARK 扩展的巨大力量。

• 只要是用 Cairo 编写的，无论 dApp 多么多样化，SHARP 都可以证明。SHARP 会把大约 22 万笔交易打包成一个在以太坊主网上的单一证明。

• 利用 SHARP 的递归证明能够并行处理和验证多个 STARK 证明，从而提高可扩展性和效率。

• 通过即将到来的 SHARP 动态布局定制，将进一步减少达 30% 的 gas 费用。

扩展以太坊是一段创新之旅，要不断地寻找进一步提升可扩展性的解决方案。2020 年 6 月，StarkWare 推出了基于 STARK 的第一款 L2 扩展解决方案 StarkEx。到 2020 年 9 月又宣布了 Cairo 语言，这是第一个为了最大限度提高 STARK 证明效率而设计的编程语言。Cairo 以及通用计算，为任何业务逻辑和任意计算声明的快速和安全编码证明铺平了道路。随着这项创新，新一波的开发者加入 StarkWare 生态系统。

虽然开发者们希望获得 StarkEx 的可扩展性、安全性和高效率，但他们的大部分项目并没有足够多的交易活动来填满一个 STARK 证明。同样，用户仍然因以太坊网络拥堵导致的 gas 费用上涨的不可预知而困扰。

于是，SHARP 横空出世。

SHARP（SHARed Prover，共享证明器）是个强大的系统，设计用户生成聚合 Cairo 程序的 STARK 证明。Cairo 是种通用计算编程语言，可以在单个证明中容纳各种代码逻辑。SHARP 在链下处理一批交易，并在链上证明它们的计算证明，将所有交易的成本分摊到单个证明中。生成的统一 STARK 证明通过链上 Solidity 验证器合约进行验证，让 SHARP 能够提高吞吐量，降低 gas 费用，并最小化延迟。

例如，SHARP 可以处理来自完全不同程序和逻辑的 Cairo 代码，包括 NFT 铸造到甚至是 Starknet 网络操作系统。只要是用 Cairo 编写的，SHARP 就可以证明，并且它可以在一个证明下聚合各种程序。SHARP 带来的效率使其能够将成千上万的交易打包到主网上一个单一证明中。在链上处理证明的费用在批处理中的所有交易之间分摊，因此打包的交易越多，每笔交易的 gas 费用就越低。

用一个示例来说明这点：

假设你正在和你的姐姐为父母购买礼物：一部新手机、一个杯子和一件T恤。每件礼物都是在不同的线上零售商那里购买的，并且会在不同的日期，用不同尺寸和形状的包装送到你们各自的家里。你们的计划是将每个礼物包装好，然后用邮寄的方式送给父母。

然而，邮局遇到了麻烦。小型和中型的盒子都没有了，只剩下大型能装下任何尺寸的盒子。这就有两个选项：

选项 1：每个礼物到货后都单独用一个大盒子来包装和邮寄。虽然这样可能加快了单个礼物的装运，但是需要包装三个独立的盒子，以及跑三趟邮局去寄出三个独立包裹。所以，这种方法既没有节约时间，也不划算。

选项 2：将所有礼物装在一个大盒子里邮寄。这就意味着你只需处理一个盒子，而非三个。

在这个例子中，SHARP 就是选项 2，可以让资源高效利用，并有着更流畅的时间管理。

尽管 SHARP 是为了 StarkWare 生态系统而生的，但它能够证明任何具备有效执行的 Cairo 程序。在节省时间和成本方面的效率，让 SHARP 成为任何需要创新证明方法的解决方案。

自诞生以来，SHARP 已经经过了几次效率升级。其中最强大的是从线性模型转变为递归模型。

在递归证明中，SHARP 在每个声明到达时就对其进行证明，而不是先收集一批声明填满一个证明，然后才证明这批声明的处理过程。这是验证计算声明的高时间效率的方式，比计算本身要快得多。

这是通过并行处理传入的声明来实现的，可以绕过之前的可扩展性障碍，这些障碍要求在接收到所有单个声明后，才能证明组合的声明。现在，不仅 SHARP 可以证明数千个交易的正确性，而且还可以使用相应的 STARK 验证器验证多个 STARK 证明。这可以生成一个单一证明，证明多个上游证明的有效性。

递归实施后，SHARP 会立即证明传入的声明。这些证明本身可以被反复证明并合并成递归证明。这个递归证明过程实施到最后，最终的证明被提交给一个链上 Solidity 验证器合约。这就像一个嵌套模式：一个 Cairo 程序验证上游的证明，这反过来又产生了一个新的证明，STARK 验证器确认它们的有效性。

在之前的比喻中，邮局最初只提供一个标准的盒子大小，但递归的 SHARP 引入了一个突破口，提供了不同大小的小盒子，每个都特别指定给一个单独的物品。虽然这些盒子并没有精确地按照每个特定物品的大小定制，但这种创新的方法使得礼物在到达时可以被装入小盒子中，消除了未使用空间的不必要的费用，并减少了延误。小盒子可以在所有礼物准备好后立即进行包装和准备发货，而不是等待所有三个礼物到达后再把它们装入一个大盒子中。

StarkWare 团队目前正在开发动态布局作为 SHARP 服务的定制。有了动态布局，证明器将计算每个特定逻辑所需的资源，并据此生成一个定制的证明。

再次与之前的邮局比喻来类比，动态布局可以看作是定制包装盒的想法。这些定制的盒子可以完美适配每个礼物的形状，确保你只需支付所需的确切尺寸，避免不必要的费用。同样，有了动态布局，将为每个逻辑和它需要的特定计算资源创建一个定制的证明，确保你只为你使用的计算付费。只要是用 Cairo 编写的，SHARP 就能进行准确证明。

StarkWare 团队希望在下一个 SHARP 版本中引入这种适应性和效率方面的改进。动态布局的目标就是大幅降低 gas 费用。

通过利用基于 STARK 的递归证明生成功能，这项技术将大大提高以太坊网络的可扩展性和效率。

可以在这里了解更多关于 StarkEx 和 Starknet 的内容。

原文：Joining Forces: SHARP
翻译及校对：「Starknet 中文社区」

• SHARP（SHARed Prover，共享证明器）生成聚合 Cairo 程序的 STARK 证明，允许任何应用程序将交易提交到同一证明。想象一个滴滴拼车池，不过是为了拼 STARK 证明。这种「拼车」动态意味着即使是小型应用程序也可以获取 STARK 扩展的巨大力量。

• 只要是用 Cairo 编写的，无论 dApp 多么多样化，SHARP 都可以证明。SHARP 会把大约 22 万笔交易打包成一个在以太坊主网上的单一证明。

• 利用 SHARP 的递归证明能够并行处理和验证多个 STARK 证明，从而提高可扩展性和效率。

• 通过即将到来的 SHARP 动态布局定制，将进一步减少达 30% 的 gas 费用。

扩展以太坊是一段创新之旅，要不断地寻找进一步提升可扩展性的解决方案。2020 年 6 月，StarkWare 推出了基于 STARK 的第一款 L2 扩展解决方案 StarkEx。到 2020 年 9 月又宣布了 Cairo 语言，这是第一个为了最大限度提高 STARK 证明效率而设计的编程语言。Cairo 以及通用计算，为任何业务逻辑和任意计算声明的快速和安全编码证明铺平了道路。随着这项创新，新一波的开发者加入 StarkWare 生态系统。

虽然开发者们希望获得 StarkEx 的可扩展性、安全性和高效率，但他们的大部分项目并没有足够多的交易活动来填满一个 STARK 证明。同样，用户仍然因以太坊网络拥堵导致的 gas 费用上涨的不可预知而困扰。

于是，SHARP 横空出世。

SHARP（SHARed Prover，共享证明器）是个强大的系统，设计用户生成聚合 Cairo 程序的 STARK 证明。Cairo 是种通用计算编程语言，可以在单个证明中容纳各种代码逻辑。SHARP 在链下处理一批交易，并在链上证明它们的计算证明，将所有交易的成本分摊到单个证明中。生成的统一 STARK 证明通过链上 Solidity 验证器合约进行验证，让 SHARP 能够提高吞吐量，降低 gas 费用，并最小化延迟。

例如，SHARP 可以处理来自完全不同程序和逻辑的 Cairo 代码，包括 NFT 铸造到甚至是 Starknet 网络操作系统。只要是用 Cairo 编写的，SHARP 就可以证明，并且它可以在一个证明下聚合各种程序。SHARP 带来的效率使其能够将成千上万的交易打包到主网上一个单一证明中。在链上处理证明的费用在批处理中的所有交易之间分摊，因此打包的交易越多，每笔交易的 gas 费用就越低。

用一个示例来说明这点：

假设你正在和你的姐姐为父母购买礼物：一部新手机、一个杯子和一件T恤。每件礼物都是在不同的线上零售商那里购买的，并且会在不同的日期，用不同尺寸和形状的包装送到你们各自的家里。你们的计划是将每个礼物包装好，然后用邮寄的方式送给父母。

然而，邮局遇到了麻烦。小型和中型的盒子都没有了，只剩下大型能装下任何尺寸的盒子。这就有两个选项：

选项 1：每个礼物到货后都单独用一个大盒子来包装和邮寄。虽然这样可能加快了单个礼物的装运，但是需要包装三个独立的盒子，以及跑三趟邮局去寄出三个独立包裹。所以，这种方法既没有节约时间，也不划算。

选项 2：将所有礼物装在一个大盒子里邮寄。这就意味着你只需处理一个盒子，而非三个。

在这个例子中，SHARP 就是选项 2，可以让资源高效利用，并有着更流畅的时间管理。

尽管 SHARP 是为了 StarkWare 生态系统而生的，但它能够证明任何具备有效执行的 Cairo 程序。在节省时间和成本方面的效率，让 SHARP 成为任何需要创新证明方法的解决方案。

自诞生以来，SHARP 已经经过了几次效率升级。其中最强大的是从线性模型转变为递归模型。

在递归证明中，SHARP 在每个声明到达时就对其进行证明，而不是先收集一批声明填满一个证明，然后才证明这批声明的处理过程。这是验证计算声明的高时间效率的方式，比计算本身要快得多。

这是通过并行处理传入的声明来实现的，可以绕过之前的可扩展性障碍，这些障碍要求在接收到所有单个声明后，才能证明组合的声明。现在，不仅 SHARP 可以证明数千个交易的正确性，而且还可以使用相应的 STARK 验证器验证多个 STARK 证明。这可以生成一个单一证明，证明多个上游证明的有效性。

递归实施后，SHARP 会立即证明传入的声明。这些证明本身可以被反复证明并合并成递归证明。这个递归证明过程实施到最后，最终的证明被提交给一个链上 Solidity 验证器合约。这就像一个嵌套模式：一个 Cairo 程序验证上游的证明，这反过来又产生了一个新的证明，STARK 验证器确认它们的有效性。

在之前的比喻中，邮局最初只提供一个标准的盒子大小，但递归的 SHARP 引入了一个突破口，提供了不同大小的小盒子，每个都特别指定给一个单独的物品。虽然这些盒子并没有精确地按照每个特定物品的大小定制，但这种创新的方法使得礼物在到达时可以被装入小盒子中，消除了未使用空间的不必要的费用，并减少了延误。小盒子可以在所有礼物准备好后立即进行包装和准备发货，而不是等待所有三个礼物到达后再把它们装入一个大盒子中。

StarkWare 团队目前正在开发动态布局作为 SHARP 服务的定制。有了动态布局，证明器将计算每个特定逻辑所需的资源，并据此生成一个定制的证明。

再次与之前的邮局比喻来类比，动态布局可以看作是定制包装盒的想法。这些定制的盒子可以完美适配每个礼物的形状，确保你只需支付所需的确切尺寸，避免不必要的费用。同样，有了动态布局，将为每个逻辑和它需要的特定计算资源创建一个定制的证明，确保你只为你使用的计算付费。只要是用 Cairo 编写的，SHARP 就能进行准确证明。

StarkWare 团队希望在下一个 SHARP 版本中引入这种适应性和效率方面的改进。动态布局的目标就是大幅降低 gas 费用。

通过利用基于 STARK 的递归证明生成功能，这项技术将大大提高以太坊网络的可扩展性和效率。

可以在这里了解更多关于 StarkEx 和 Starknet 的内容。