官方 Wiki 精选丨波卡的 JAM 链解析（下）

Bitget App

交易“智”变

Bitget

资讯中心

Polkadot生态研究院2025/03/14 10:15

作者:Polkadot生态研究院

本文介绍的是波卡的 JAM 链，本文为下部分。

“波卡知识图谱”是我们针对波卡从零到一的入门级文章，我们尝试从波卡最基础的部分讲起，为大家提供全方位了解波卡的内容，当然这是一项巨大的工程，也充满了挑战，然而我们希望通过这样的努力让大家能够正确认知波卡，也让不了解波卡的人方便快速掌握波卡相关知识，今天是该栏目的第 176 期，本文介绍的是波卡的 JAM 链，本文为下部分。

注：我们在上文介绍了波卡 JAM 链的设计理念以及核心功能，本文我们将深入探讨 JAM 链的通用化、网络架构、区块处理优化等特点。

JAM 链的通用化

正如最初的波卡白皮书所述，波卡主要是为特定服务配置量身定制的：提供平行链服务。为了实现这一服务，波卡开发了两个关键子组件：

分布式数据可用性系统

计算审计和保证系统（即具有强大安全保障的 Rollup 系统）

与波卡相比，JAM 减少了特定倾向性，提供了更高层次的抽象和泛化。这有助于根据个人偏好更容易地利用底层组件。
JAM 以无需许可的方式运行，类似于智能合约链，允许个人上传代码并期望其执行。此外，它还托管数据、支持原像查找和管理状态，类似于键值对系统。由于 JAM 缺乏直接接受交易的机制，其创世区块包括一个服务来促进新服务的创建。
JAM 中的服务在代码量、数据量或状态容纳量上没有预定义的限制。它们的能力由密码经济因素决定；存入的 DOT 通证越多，数据和状态的处理能力就越大。例如，平行链服务将 Polkadot1.1 的所有功能整合到 JAM 上的一个服务中，并有可能使其他服务利用波卡的分布式可用性系统以及计算审计和保证系统。

波卡虚拟机（PVM）

PVM 的设计基于 RISC-V 指令集架构（ISA），该架构以其简洁性和多功能性而闻名。RISC-V 指令集架构提供了多项优势：

它易于转译为常见的硬件格式，如 x86、x64 和 ARM 架构。

它得到了 LLVM 等工具的良好支持，详情请参见：

https://llvm.org/
PVM 本身集简洁性和安全性于一身，具有沙盒特性，并提供多种执行保障。它具有确定性，对共识敏感，并且便于进行计量。与其他虚拟机不同，PVM 避免了复杂性和过度主观性。
虽然 WebAssembly（WASM）针对网络用例进行了优化，但在堆栈管理方面存在挑战，特别是在处理延续性（continuations）时。RISC-V 通过将堆栈置于内存中来解决这个问题，能够自然地处理延续性，而不会增加额外的复杂性。
此外，PVM 展现出卓越的执行速度，尤其是在 X64 和 ARM 等传统硬件上运行时，与 WASM 相比，它提供了免费计量等优势。
RISC-V 支持的延续性的融入有望为在 JAM 这样的多核平台上实现可扩展编码建立一个新的标准。异步、并行架构对于硬件和软件平台的可扩展性而言越来越重要，这一趋势预计也将延伸到区块链和共识算法领域。

SAFROLE 算法

SAFROLE（详情请参见： https://wiki.polkadot.network/docs/learn-safrole）是一种区块生产算法，是对 SASSAFRAS 算法（详情请参见： https://research.web3.foundation/Polkadot/protocols/block-production/SASSAFRAS）的简化。
它剔除了可能对平行链有用的某些组件。因此，平行链可能更倾向于使用 SASSAFRAS 而不是 SAFROLE。SAFROLE 将尽可能简化，以达到以下目的：

确保其尽可能少地带有特定倾向性，从而最大限度地拓展未来的潜在用例

遵循以太坊黄皮书的脚步，真正尝试实现尽可能多的版本，以传播专业知识

理解 Polkadot 1.0 端到端的工作原理颇具挑战。有了 JAM 链，能够阅读和理解黄皮书的人将能够相当快速地阅读和理解 JAM 的工作原理。因此，简洁性至关重要。

网络连接

JAM 的网络连接使用 QUIC 协议（详情请参见： https://en.wikipedia.org/wiki/QUIC）。这使得大量验证者之间能够建立直接的点对点连接。所以从本质上讲，波卡上基本上所有 1000 多个验证器都可以相互保持持续连接，而不会遇到套接字潜在问题。
由于 JAM 链不处理交易，所以基本上不需要闲聊式的信息传播（Gossip），因此也就避免了这种情况。在需要分发非点对点内容，或仅在很小一部分验证器子集中分发内容时，将使用网格扩散（grid-diffusion）的方式。在这种方式中，验证者被排列成一个网格，数据包按行发送，然后该行上的每个节点都将其发送到其所在列的所有成员。

高效区块处理的流水线技术

在像以太坊这样基于状态的区块链中，区块的头部通常包含后状态根（posterior state root），它总结了所有区块计算后的状态。因此，在所有计算完成之前，无法发送头部。然而，一些计算可以在发送头部之前进行，因为这些计算的结果决定了区块的有效性。
在 JAM 中，采用了一种不同的方法，即将前状态根（prior state root）放在区块头中，而不是后状态根。这意味着头部中显示的状态根会滞后一个区块。这样一来，可以先执行约占区块工作量或执行时间 5% 的轻量级计算，然后可以立即分发区块。区块剩余 95% 的计算，主要是累积任务，可以在随后完成。这使得可以在当前区块执行完成之前开始下一个区块。
这种方法可以更有效地利用区块之间的时间。在传统设置（如波卡的 6 秒区块时间）中，必须提供后状态根，因此只有部分时间可用于计算。然而，在 JAM 中使用流水线技术，整个区块时间都可以有效地用于计算，从而最大限度地提高效率。
虽然将整个区块时间用于计算可能并不理想，因为这可能导致持续追赶和区块导入延迟，但与传统设置相比，JAM 的方法为计算提供了更多的时间。这意味着可以实现大约 3 到 3.5 秒的有效区块计算时间，这相比当前的设置有了很大的改进。

架构差异：JAM 与中继链

JAM 与中继链之间的架构差异之一在于功能固定程度的不同。虽然中继链固定了某些元素，如用于定义协议的语言（WASM），但 JAM 在这方面更进一步。例如，它规定了用于编码区块头的类型和哈希方案，使得对这些方面进行改动变得很困难。
然而，JAM 通过其服务模式保留了与中继链中 WebAssembly 元协议所赋予的类似的灵活性。在这个模式中，可升级性的责任转移到了各个服务上，使链本身摆脱了需要升级的负担。做出这一决定有三个主要原因：

优先考虑简单性。维护一条不可升级的链显著降低了复杂性。

中继链倾向于引入复杂功能而不删除旧功能，这使情况变得复杂。由于升级很容易实现，因此几乎没有动力去简化 Substrate SDK。结果，复制波卡变得不切实际。

JAM 固定参数带来的优化潜力。由于清楚地了解 JAM 链必须执行的具体任务以及设置固定参数的能力，因此在网络拓扑和时序等领域的优化变得可行。这与中继链高度可升级特性所带来的挑战形成鲜明对比，在中继链中，由于每次升级都可能带来频繁更改，因此此类优化更为复杂。

尽管存在这些差异，但 JAM 在应用级功能方面仍保留了灵活性，比如 Coretime 销售、质押和治理，所有这些都在服务中管理。此外，JAM 引入了一个新颖的概念，即将通证余额与一项服务相关联，为经济模型调整提供了机会，而这些调整在像中继链这样纯可升级的链中难以轻易实现。

JAM 测试平台（JAM Toaster）

为确保 JAM 达到最初的预期，当前正在进行的努力之一是为 JAM 链建立一个全面的测试环境。与为了控制云计算成本而在不可靠硬件上运行的小规模测试网络不同，该计划需要大量投资。这就是 JAM Toaster 的由来，它本质上是一个测试平台，旨在对 JAM 进行大规模试验和性能评估。这解决了波卡中继链开发过程中遇到的一个早期挑战，即很难理解在如此大规模的网络上运行时出现的效果和动态。以前的尝试仅限于测试网络和 Kusama 网络上的几十个节点，由于访问验证者节点的限制，Kusama 网络缺乏全面的监测能力。
相反，小型测试网络无法准确模拟更大规模部署的网络动态。JAM Toaster 旨在通过支持对由 1023 个节点组成的整个 JAM 网络进行深入研究来弥合这一差距。该平台有助于研究网络行为和性能特征，为开发人员提供有关其平行链预期性能的宝贵见解。

JAM 与 Substrate

基准测试与计量

在使用 JAM 时，基准测试（或性能测试）是可选的。虽然有时可能仍然需要基准测试，但JAM 的计量系统通常可以省去频繁进行基准测试的需求。JAM 运行在一个计量系统上，允许用户在计算任务完成后评估其工作量。此外，还有一个控制计算的理论机制，通常在区块构建时实现。
然而，在某些情况下，基准测试仍然相关。例如，当计量被认为对某些用例过于保守时，可能需要基准测试来提高性能。此外，对于需要较长执行时间的任务，基准测试可以确保它们不会运行过长时间。

跨链消息传递（XCMP）

接下来是 XCMP，JAM 要求完全支持 XCMP。这是因为在中继链中，通过候选收据传递的数据量比所有平行链始终传输所有数据时的实际量要多。JAM 严格遵守规则，即使是对于平行链服务，也包括在“精炼”和“累积”阶段之间数据传输的限制。目前，使用水平中继链消息传递（HRMP，详情请参见： https://wiki.polkadot.network/docs/learn-xcm-transport#hrmp-xcmp-lites）时，所有消息都通过中继链传输，数据有效载荷限制在 4kB 或以下，这可能不太现实。因此，XCMP（即只有消息头通过链进行中继，而实际消息数据在链下传输）成为一项必要且期待已久的改进。

协定（Accords）

协定（详情请参见： https://wiki.polkadot.network/docs/polkadot-direction#xcm-and-accords）本质上融合了状态和逻辑，类似于智能合约，每个平行链旁边都存在多个实例。它们促进了实例间的消息交换，并实现了与平行链的同步交互。协定在平行链间缺乏信任的场景中发挥作用，如通证转移。与现有的涉及储备中介的方法不同，协定简化了平行链间的直接通证转移，消除了对损害信任的中介的需求。此外，协定还可以作为跨链消息（XCM）转发机制，确保消息在通过第三方中介转发时保持完整性，因此无需明确的来源标记。

提升效率

最后，JAM 链采用更广泛、特定倾向性更低的方式来利用底层共识机制，这有利于实施更具创新性的解决方案。例如，对于像零知识证明这样的复杂任务，JAM 链使得分布式可用性变得更加实际和高效。此外，JAM 支持混合资源消耗模型，其中工作包可以包含计算密集型任务和数据密集型操作。通过将具有不同资源需求的服务相结合，比如将需要大量计算的服务与需要高数据可用性的服务配对，JAM 优化了验证者资源的利用，从而降低了成本。这种灵活的方法使得可以将分布式可用性和（简洁非交互式知识论证）SNARK 验证等任务与平行链工作量相结合，在降低成本的同时提高效率。

JAM 链的增强和兼容性

JAM 的设计优先考虑与现有 Polkadot 1.0 平行链的兼容性。虽然它保持了与 Polkadot SDK 的兼容性，但波卡验证器功能（PVF）进行了重新定向。它不再以 WebAssembly 为目标，而是将以 PVM 为目标。这一转变之所以得以顺利进行，是因为 PVM 是对 RISC-V 的微小修改，而 RISC-V 已被确立为 LLVM 的官方目标。因此，PVM 可能会在 JAM 部署之前成为 LLVM 的官方目标。
除了作为平行链的宿主外，JAM 还引入了重大改进。它有望简化基准测试工作，并减轻未来的基准测试需求。此外，JAM 引入了协定的概念，即多实例、多分片的智能合约，用于管理和执行平行链间的特定交互协定。此外，完全支持 XCMP 至关重要，它能够消除通常由 XCM 实现的平行链之间信息传输的限制。
在 Agile Coretime 方面，JAM 链与现有设置保持兼容。然而，它引入了针对 Coretime 的能力，即核心时间的目标对象不仅可以是平行链，还可以是任意的工作包集合。这种灵活性增强了 JAM 生态系统中资源分配的通用性和效率。

原文出自 Polkadot Wiki，详情可査看： https://wiki.polkadot.network/docs/learn-jam-chain

欢迎大家加入我们 Polkadot 生态研究院的电报：

https://t.me/polkadot_eri