波卡放大招：JAM链横空出世，要革谁的命？

JAM链的通用化、网络架构与区块处理优化

本文将深入探讨波卡JAM链的通用化设计、网络架构以及区块处理优化等关键特性，继前文对JAM链的设计理念和核心功能进行介绍后，本文将进一步剖析其技术细节。

JAM链的通用化

波卡现有架构的局限性

最初的波卡白皮书设想波卡主要为特定服务定制，即提供平行链服务。为了实现这一目标，波卡开发了两个关键组件：分布式数据可用性系统和计算审计与保证系统（一种具有强大安全保障的Rollup系统）。

JAM链的抽象与泛化

与波卡相比，JAM链减少了对特定服务的倾向性，提供了更高层次的抽象和泛化。这种设计使得开发者可以根据自身需求，更灵活地利用底层组件。

JAM链的服务模型

JAM链以无需许可的方式运行，类似于智能合约链，允许开发者上传代码并期望其执行。同时，JAM链还提供数据托管、原像查找和状态管理等功能，类似于键值对系统。由于JAM链不直接接受交易，其创世区块包含一项服务，用于促进新服务的创建。

资源分配的密码经济学模型

JAM链中的服务在代码量、数据量或状态容量上没有预设的限制。服务的性能由密码经济因素决定：质押的DOT通证越多，服务处理数据和状态的能力就越强。例如，平行链服务可以将Polkadot 1.0的所有功能整合到JAM链上的一个服务中，并有可能使其他服务利用波卡的分布式可用性系统以及计算审计和保证系统。

波卡虚拟机（PVM）：简洁、安全且高效

PVM基于RISC-V指令集架构的优势

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

• 易于转换为常见的硬件格式，如x86、x64和ARM架构。
• 得到了LLVM等工具的良好支持（参见https://llvm.org/）。

PVM的特性：沙盒、确定性与可计量

PVM本身集简洁性和安全性于一身，具有沙盒特性，并提供多种执行保障。它具有确定性，对共识敏感，并且便于进行计量。与其他虚拟机不同，PVM避免了复杂性和过度主观性。

PVM与WASM的比较

虽然WebAssembly（WASM）针对网络用例进行了优化，但在堆栈管理方面存在挑战，特别是在处理延续性（continuations）时。RISC-V通过将堆栈置于内存中来解决这个问题，能够自然地处理延续性，而不会增加额外的复杂性。

延续性与多核平台的可扩展性

此外，PVM展现出卓越的执行速度，尤其是在X64和ARM等传统硬件上运行时，与WASM相比，它提供了免费计量等优势。

RISC-V支持的延续性的融入有望为在JAM这样的多核平台上实现可扩展编码建立一个新的标准。异步、并行架构对于硬件和软件平台的可扩展性而言越来越重要，这一趋势预计也将延伸到区块链和共识算法领域。

SAFROLE算法：简化区块生产

SAFROLE与SASSAFRAS算法的对比

SAFROLE（详情请参见：https://wiki.polkadot.network/docs/learn-safrole）是一种区块生产算法，是对SASSAFRAS算法（详情请参见：https://research.web3.foundation/Polkadot/protocols/block-production/SASSAFRAS）的简化。

它剔除了可能对平行链有用的某些组件。因此，平行链可能更倾向于使用SASSAFRAS而不是SAFROLE。

SAFROLE的设计目标

SAFROLE将尽可能简化，以达到以下目的：

• 确保其尽可能少地带有特定倾向性，从而最大限度地拓展未来的潜在用例。
• 遵循以太坊黄皮书的脚步，真正尝试实现尽可能多的版本，以传播专业知识。

简洁性与易于理解的重要性

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

网络连接：QUIC协议与网格扩散

QUIC协议带来的优势

JAM的网络连接使用QUIC协议（详情请参见：https://en.wikipedia.org/wiki/QUIC）。这使得大量验证者之间能够建立直接的点对点连接。所以从本质上讲，波卡上基本上所有1000多个验证器都可以相互保持持续连接，而不会遇到套接字潜在问题。

JAM链无需Gossip协议的原因

由于JAM链不处理交易，所以基本上不需要闲聊式的信息传播（Gossip），因此也就避免了这种情况。

网格扩散的应用场景

在需要分发非点对点内容，或仅在很小一部分验证器子集中分发内容时，将使用网格扩散（grid-diffusion）的方式。在这种方式中，验证者被排列成一个网格，数据包按行发送，然后该行上的每个节点都将其发送到其所在列的所有成员。

高效区块处理的流水线技术：提升计算效率

传统区块链的区块处理方式

在像以太坊这样基于状态的区块链中，区块的头部通常包含后状态根（posterior state root），它总结了所有区块计算后的状态。因此，在所有计算完成之前，无法发送头部。然而，一些计算可以在发送头部之前进行，因为这些计算的结果决定了区块的有效性。

JAM链的前状态根方法

在JAM中，采用了一种不同的方法，即将前状态根（prior state root）放在区块头中，而不是后状态根。这意味着头部中显示的状态根会滞后一个区块。这样一来，可以先执行约占区块工作量或执行时间5%的轻量级计算，然后可以立即分发区块。区块剩余95%的计算，主要是累积任务，可以在随后完成。

流水线技术的优势

这使得可以在当前区块执行完成之前开始下一个区块。这种方法可以更有效地利用区块之间的时间。

有效区块计算时间的提升

在传统设置（如波卡的6秒区块时间）中，必须提供后状态根，因此只有部分时间可用于计算。然而，在JAM中使用流水线技术，整个区块时间都可以有效地用于计算，从而最大限度地提高效率。

虽然将整个区块时间用于计算可能并不理想，因为这可能导致持续追赶和区块导入延迟，但与传统设置相比，JAM的方法为计算提供了更多的时间。这意味着可以实现大约3到3.5秒的有效区块计算时间，这相比当前的设置有了很大的改进。

架构差异：JAM与中继链

功能固定程度的不同

JAM与中继链之间的架构差异之一在于功能固定程度的不同。虽然中继链固定了某些元素，如用于定义协议的语言（WASM），但JAM在这方面更进一步。例如，它规定了用于编码区块头的类型和哈希方案，使得对这些方面进行改动变得很困难。

JAM链服务模式的灵活性

然而，JAM通过其服务模式保留了与中继链中WebAssembly元协议所赋予的类似的灵活性。在这个模式中，可升级性的责任转移到了各个服务上，使链本身摆脱了需要升级的负担。

简化、避免复杂功能堆积与优化潜力

做出这一决定有三个主要原因：

• 优先考虑简单性。维护一条不可升级的链显著降低了复杂性。
• 中继链倾向于引入复杂功能而不删除旧功能，这使情况变得复杂。由于升级很容易实现，因此几乎没有动力去简化Substrate SDK。结果，复制波卡变得不切实际。
• JAM固定参数带来的优化潜力。由于清楚地了解JAM链必须执行的具体任务以及设置固定参数的能力，因此在网络拓扑和时序等领域的优化变得可行。这与中继链高度可升级特性所带来的挑战形成鲜明对比，在中继链中，由于每次升级都可能带来频繁更改，因此此类优化更为复杂。

应用级功能的灵活性与通证模型

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

JAM测试平台（JAM Toaster）：大规模试验与性能评估

测试环境的重要性

为确保JAM达到最初的预期，当前正在进行的努力之一是为JAM链建立一个全面的测试环境。与为了控制云计算成本而在不可靠硬件上运行的小规模测试网络不同，该计划需要大量投资。

JAM Toaster的意义

这就是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链的增强和兼容性

与Polkadot 1.0平行链的兼容性

JAM的设计优先考虑与现有Polkadot 1.0平行链的兼容性。

波卡验证器功能（PVF）的重新定向

虽然它保持了与Polkadot SDK的兼容性，但波卡验证器功能（PVF）进行了重新定向。它不再以WebAssembly为目标，而是将以PVM为目标。这一转变之所以得以顺利进行，是因为PVM是对RISC-V的微小修改，而RISC-V已被确立为LLVM的官方目标。因此，PVM可能会在JAM部署之前成为LLVM的官方目标。

JAM链引入的改进

除了作为平行链的宿主外，JAM还引入了重大改进。它有望简化基准测试工作，并减轻未来的基准测试需求。此外，JAM引入了协定的概念，即多实例、多分片的智能合约，用于管理和执行平行链间的特定交互协定。此外，完全支持XCMP至关重要，它能够消除通常由XCM实现的平行链之间信息传输的限制。

Agile Coretime的兼容性与灵活性

在Agile Coretime方面，JAM链与现有设置保持兼容。然而，它引入了针对Coretime的能力，即核心时间的目标对象不仅可以是平行链，还可以是任意的工作包集合。这种灵活性增强了JAM生态系统中资源分配的通用性和效率。

原文出自Polkadot Wiki，详情可査看：https://wiki.polkadot.network/docs/learn-jam-chain 这部分文章原文已经全部输出了，不再有第10个段落的内容。