加入 PolkaWorld 社区，共建 Web 3.0！
sub0 reset 活动在昨天圆满结束！最令人期待的 Gavin Wood 的演讲在最后一天进行，他在现场分享了 Polkadot 发展出 JAM 的最初想法，出以及 JAM 当前的进展，此外还重磅推出未来 JAM 的路线图！该演讲内容较长，PolkaWorld 将分为两部分发布！
本文为第一部分，主要内容包含建设 Polkadot 多年来的驱动因素，Gavin 认为的 Web3 应该具备什么样的准则，以及 JAM 在这些准则上的实现程度！
Gavin 每次的演讲内容都极具观点，本次也不例外！继续阅读，查看 PolkaWorld 的整理版本！
很高兴看到这么多人能够参加 sub0 活动。不知道大家目前感觉如何，这是 sub0 的第三天了！前两天有一些模块化和教育相关的内容，还不错吧？我其实不太清楚大家的水平，所以这次的分享内容比较混合，从最基础的部分开始，一直到我们现在具体在做的事情。
驱动因素与 Web3 准则
那我们现在就从最基础的开始：为什么我们要费心去做这些？
大约十年半前，互联网领域出现了一种新概念，这是为应对斯诺登事件后的网络发展而提出的，这个概念后来被称为 Web3。随着时间的推移，这一概念逐渐发展成了一系列的原则或准则，其中最核心的就是“韧性”。
“韧性”指的是一种网络的持久性和可靠性，例如比特币网络自成立以来一直在持续运行，从未被“破坏”或“关闭”过。这种稳定性也可以理解为“不可阻挡性”，即网络运行不会轻易被外界因素所干扰。不过，我更倾向于用“韧性”这个词，因为它的含义更中性，不一定意味着网络运行一定会受到人为的阻止。此外，理解哪些原则是 Web3 特有的也很重要，比如“韧性”大概是最具 Web3 特性的准则。
除了“韧性”之外，我认为还有另外一些准则也符合 Web3 的特性，但这些准则相较于“韧性”更具争议性。接下来提到的两个准则是“通用性”和“性能”。
“通用性”指的是这个网络或平台在不同任务或应用场景中的适用范围。例如，比特币的设计比较有限，它在编程功能（或称脚本功能）上存在很多限制，因此并不是一个非常通用的解决方案。而以太坊则在这方面拓展了更多的可能性，它可以支持更多种类的应用和任务。在保留“韧性”的同时，通用性这一准则的发展也对 Web3 带来了重要的推动作用！
不过性能，尤其是性能和一致性方面，进展有点停滞。我在后面会多讲讲性能和一致性，因为这正是 JAM 进入到这个框架中的原因。
然后是可访问性，这里涉及很多因素。可访问性包括开发者可访问性，比如 API 是什么样的？系统能提供哪些保证？也包括对普通用户的可访问性，比如人们实际使用这个系统有多容易？是否需要先进入一个中心化的网站去购买代币？他们是否需要先理解某些概念或术语才能使用？是否有国家或司法区域的限制？关于可访问性的问题很多，而我相信其中许多问题是可以通过技术解决的，尽管可能不是全部。
我认为可访问性和一致性在 Web 2.0 中都存在一定的缺陷。虽然有人会认为 Web 2.0 的系统，即使在不同服务器上运行，也可以保持一致性。同样，Web 2.0 确实非常具有可访问性，像 Facebook 上有 40 亿用户。但是，Web 2.0 中很容易关闭某些服务，比如由于司法管辖边界的原因，特定人群就无法访问某些服务。所以，我认为这方面确实存在两种不同的观点。
不过，Web3 的设计和目标是尽量实现这五个特性 —— 韧性、通用性、性能、一致性和可访问性，以便更好地支持去中心化、无需信任和高效的网络。
JAM 如何融入 Web3？
那么，JAM 是如何融入 Web3 概念的呢？简单来说，JAM 就是一个无需信任的超级计算机。线索就在它的名字里，它就是一个机器，其中的 “J” 和 “A” 代表了机器的工作方式，但本质上它就是一个机器。
它是一个虚拟机，是一个运行计算机代码的机器。我们通常称这种东西为计算机。它是超级计算机，因为它拥有大量的核心、高性能和丰富的存储功能。并且它是无需信任的，因为你不需要信任任何人就可以使用它。这个无需信任的超级计算设施构成了 Web3 云的基础。如果你愿意，可以把它看作一个 Web3 云。
那么，什么是云呢？
基本上，云就是可以运行服务的地方。由于它是无需信任的，所以没有传统意义上的服务器。这里的“服务器”是从人类角度来理解的，所以不会有专门的人员来服务你的需求。我们没有这种意义上的服务器，没有像 AWS 或 Google Cloud 这样的公司提供你所需的服务。
而作为一个无需信任的超级计算机，它结合了我们在计算机中看到的两个关键功能。
首先是数据存储和数据托管。在我们的案例中，预计可以托管 1.6 PB 的数据，并且每秒能够从数据存储中获取约 2/3 GB 的数据。
其次是计算功能，虽然计算能力比较难衡量，但大致相当于 341 个 AMD Threadripper 处理器速度的四分之一到二分之一。如果按照以太坊的标准来衡量 JAM 的计算能力，虽然 EVM 的 Gas 数量不容易精确计算，但可以粗略估算为 JAM 每秒的计算能力相当于每秒消耗约一万亿 Gas。
JAM 如何融入更广泛的生态？
接下来我们来看它如何融入更广泛的生态。
以太坊和 Polkadot 1.0 的根本问题
以太坊 L1，毕竟已经有 10 年历史了。现在看起来可能不那么先进了，但还是值得提一下。它的使用成本很高，性能也比较低。十年前它的确非常出色，但像很多曾经领先的计算机一样，十年后它在性能上已经不太能和其他新方案相比了。
我们可以看看以太坊的路线图，即计划拥有许多独立的区块链，称为 L2 区块链，这些 L2 将至少由以太坊 L1 主网络来托管或保护。但是，这些 L2 是由各个不同的组织、个人，甚至可能是公司来运行的，所以如果你想使用不止一个 L2，会有一种零散的感觉。因为它们以不同的方式工作，提供的保证和 API 不尽相同，甚至功能集也可能不同。虽然这可以被看作是一种优势，体现了市场的多样性和灵活性，但如果你想构建一个更加一致的（统一的）解决方案，这种多样性可能就是一种劣势。
更重要的是，L2 模型（和许多其他 L2 模型一样）导致了状态的持久分割。如果把这些视为一个整体系统，那么每个 L2 实际上都是一个子系统，其数据访问是与其他 L2 持续分隔的。这种数据分割也是分片（sharding）理念的一部分。而在这一方面，Polkadot 做出了重要突破，接下来会详细讨论这个进展。
PolkaWorld 注：“状态的持久分割”指的是在一个系统中，各个子系统或分片的状态（即数据和信息）是相对独立的，彼此之间不能直接共享或访问。换句话说，这些子系统的状态是彼此隔离的，这种隔离是持久的和长期存在的。
在区块链和去中心化系统中，这种状态持久分割通常见于分片（sharding）或分层网络模型中。以以太坊 L2 为例，每个 L2 都有自己的状态和数据，它们之间不能直接访问或共享数据。即使在同一主链（如以太坊 L1）上托管，L2 之间也没有一个通用的、持续的状态共享机制。这样做的好处是可以提高系统的扩展性和性能，但缺点是增加了不同 L2 之间的数据交互复杂性。
因此，当我们提到“状态的持久分割”时，实际上是在说各个 L2（或分片）之间的数据和状态是分隔的，且这种隔离长期存在，不会像在一个单一系统中那样可以随意访问。
Polkadot 在以太坊之前的很多年就实现了将一个大型系统分割成多个分片、独立部分，并且持续保持它们之间的隔离。但这种做法带来了我称之为高度不一致性的问题。同时，以太坊也正逐渐尝试通过零知识加密技术来提升计算和数据可用性的扩展性，但这个方法可能还需要几年时间才能真正可行，且目前（甚至未来几年）会导致高度中心化，成本也极为高昂。
那么，Polkadot 的情况如何呢？
这里我说的 Polkadot 是指现阶段的 Polkadot 1.0，而不是它未来的发展。Polkadot 尤其是在其平行链模型中，同样存在这种持续的状态分割。作为一个平行链托管平台，或者说区块链托管解决方案，Polkadot 由于平行链各自拥有独立的状态，因此它们相互之间的数据转移比较困难。
此外，Polkadot 1.0 的版本还存在较高的准入门槛，因为通常有两年的租约和较为有限的插槽数量。不过，这一问题在 Polkadot 2.0 的新版本（具有灵活的核心时间）中得到了极大改善，显著降低了使用 Polkadot 作为区块链托管系统的门槛，但持续的状态分割仍然是一个劣势。
当前的解决方案
为了解决状态持久分割的问题，一种替代方案是使用“桥接链”，即在完全独立的区块链之间建立桥梁，通常通过轻客户端桥接来实现。这种桥接依赖于彼此验证者的正常运行来保证安全性。然而，这种方式通常是不安全的，因为它会带来“因果污染”的风险，这指的是，在一个不安全的链上触发某个事件，从而对另一条更安全的链产生连锁反应或负面影响。如果你想把这种方式用在一个整体的系统上，试图构建一个一致性的系统，最终会导致因果污染，进而破坏整个系统的安全性，因为你可以通过选择一个薄弱环节来攻击系统！
而且系统仍然存在这种持续的状态分割，对吧？最终，一条链上可以直接访问的数据，对另一条链来说几乎是完全不可访问的，尽管可以通过一些特殊且通常成本高昂的预言机机制来获取数据。
除了桥接链，我们还可以尝试增强服务器性能，比如加强验证节点的性能，让它们彼此靠得更近，为它们提供超高速的互联，从而把验证者网络打造成一个看起来更像集中托管的服务。这种方式将会是同步的，这对开发者来说很有帮助。
如果提升验证节点性能，确保其互联速度快，并且不太在意旧数据的可访问性，或者不在意引入新验证者（因为新验证者需要同步所有数据），那么可以达到相当不错的效果。但最终，还是会遇到硬件和带宽的瓶颈 —— 即对验证者的硬件要求、验证者之间的连接速度等要求越来越高。通常，这种方式会较少去中心化，因为网络的多样性减少，导致系统的弹性下降，且容易走向中心化，因为同步难度增加使得新验证者难以进入这个“圈子”，而且通常需要极好的连接速度来保持同步。
那么 JAM 如何解决系统规模和一致性之间的矛盾？
JAM 是一个多核计算模型，它具有大部分一致的共享状态。这意味着虽然 JAM 的状态不是完全同步的，但它也不像分片那样将数据持续隔离，而是实现了大多数部分的一致共享存储。这种设计让 JAM 能够在保持去中心化的同时，允许数据和计算在系统中更自由地流动。
由于 JAM 是多核的，它可以在系统内部执行大量计算。尽管异步编程比同步编程更复杂，但 JAM 依然保持了很高的韧性。其关键在于“几乎一致”的共享状态，这是 JAM 为在韧性和高性能之间找到平衡而做的优化。
因此，回到 Web3 的原则，JAM 并没有单独追求某一个特性，而是兼顾了韧性、通用性和可访问性。对于这些特性，JAM 提供了一个非常不错的解决方案，既能满足高性能需求，也能保持系统的去中心化和可靠性。
所以在 Web3 领域，许多技术难题已经有了部分解决方案，JAM 正在尝试利用这些解决方法来提升系统的性能。然而，要同时解决性能和一致性的问题非常困难，因为系统规模和一致性之间存在着一种根本的矛盾关系。也就是说，随着系统规模的增大，要保持一致性会变得越来越困难，这是不可避免的限制。
这种系统规模和一致性之间的矛盾关系在许多领域中都存在。例如，在生物学中，一个单细胞不可能扩展到像人体那么大，否则它无法正常工作。因为细胞内部的营养密度会出现极大的差异，营养物质的传输方式也无法支持如此大的规模。因此，单细胞只能在特定的小规模下有效运作。如果需要更大规模的结构，就必须发展成多细胞生物，而不是无限扩大单个细胞的体积。类似地，动物也不会将它们的小规模生物结构直接无限放大。例如，从冷血动物到温血动物的转变就是为了适应更大的体型规模，并在这种规模下保持一定程度的一致性。这种变化是为了在更大的系统中优化一致性。
在物理学中也能看到这种现象。光速实际上定义了规模和一致性之间的权衡。随着事物之间的距离增加，它们在因果关系上也变得更加疏远。它们对彼此产生影响所需的时间更长。比如在量子领域，我们可以观察到即时效应，光速在其中并不起作用。然而，一旦进入经典物理领域，就必须遵循光速的限制 —— 这正如我所说的，系统随着规模增大所获得的一致性或失去的一致性。
我们在电流传输速度上也能看到类似现象。当系统运行速度极快且非常复杂时，跨越大量的硅片会成为一个问题，因此我们需要优化硅片上路径的长度和距离差，否则即便在微小的空间中，我们也会失去一致性。
在 CPU 设计中也会遇到类似的问题。当有多个 CPU 核心时，不同的核心在同一时刻可能会读取到不同的内存内容，这就是所谓的一致性问题。随着系统规模的增大和 CPU 核心数量的增加，各个核心对内存的“视角”可能会出现差异，因此需要管理这种一致性下降的问题。为了解决不一致性，一个最直接的方法是进行“分割”。也就是说，不再让所有 CPU 核心共享同一块内存，而是给每个 CPU 核心分配各自独立的内存。如果多个核心需要协作，那么它们可以通过网络发送消息来相互通信。这样可以有效管理一致性问题。
类似地，与其拥有一个体积加倍的变形虫，不如直接有两个变形虫；与其拥有一个体积加倍的细菌，不如直接有两个细菌。在数据库中，我们可以有不同的数据库，或者稍微聪明些，设置一个数据库但分成不同的分片，对吧？通常，这种方法是通过将系统划分成独立的子系统来实现持续的分割。但如果我们这样做，尤其是简单地进行分割，就会削弱系统的整体组合性，降低系统内部协调和对齐的能力，这种划分方式可能会剥夺系统某些原有的功能。
不过，还有更复杂的方法来管理不一致性。例如，多细胞生物可以共享 DNA，并通过复杂的信号系统（如激素、神经元等）来协调。这就是管理分割导致的不一致性的一种方法。大型生物可能会进化出血管系统和温血机制，以便更有效地传输营养，并保持整个生物体内较为一致的环境条件。
在 CPU 设计中，可能会为每个核心配备独立的内存（如缓存），同时使用一些巧妙的同步原语和数据管理方法，以确保需要时可以看到一致的内存状态。这正是现代多核 CPU 的工作方式，因此它们看起来具有一致性，即使在异步性、延迟或停滞方面付出了一定代价。
而这正是 JAM 所做的尝试 —— 采取这种细致的方式来管理不一致性，使系统在大多数情况下保持一致性。
我们不可能让系统实现完全的一致性，至少现在不行，可能永远也不行。因为如果你观察其他大型系统的例子，它们都不是完全一致或完全同步的。现实世界中不存在这种完全一致的系统。当你希望系统扩展时，必须吸收一些不一致性。关键在于，能否在保持旧有用例正常工作的前提下有效管理这些不一致性。
那么，JAM 是如何微调这种不一致性的呢？它基本上借鉴了现代多核、多 CPU 机器设计的一些概念。
JAM 拥有类似于共享存储的内存，但在任何时刻，每个核心（在 JAM 中类似于 CPU 核心）可能对存储有略微不同的视角。这些视角最终会统一，特定存储点一旦统一，系统就可以继续处理需要用到该存储的工作。在这一点上，它与 CPU 类似。还有一个完全一致的元素概念，类似于同步且具有原子性特性的数据库。
如果将 JAM 类比为一台普通计算机，可以将其视为一个拥有 341 核 CPU 的系统，总内存带宽约为 682 MB/s，总内存容量约为 1.6 PB。并且，它还具备一个数据库子系统，具有完全一致、完全同步和原子特性，这使它每秒可以处理约 2.5 MB 的数据和 100 万次操作，并拥有大约相当于单核 CPU 水平的脚本处理能力。
所以关键是，各核心可以访问公共存储。这里所谓的公共存储，并不是完全固定、可知、全局一致的状态——因为它并非绝对同步。但它具有一种“公共存储”概念，最终会转化为一个可知的状态。就像一种“叠加态”，如果在某一刻测量，状态可能不完全确定，但你知道它很快会变为可知状态。
该存储是以 4K 页为单位进行寻址的，这对于运行虚拟机非常方便。使用该存储时，这些 4K 页可以通过两种方式寻址：一种是长期地址格式，即加密承诺；另一种是短期寻址机制，即导出引用。导出引用基本上是指向放置该数据的工作负载的引用。
如果你不知道数据的具体内容，只知道某个工作负载生成了这些数据，那么你可以在一定时间内通过该工作负载的引用来访问它。关键在于，某些存储元素会与特定的 CPU 核心存在关联性。这有点类似于 CPU 核心的 L1 或 L2 缓存，使得访问该数据更快，减少该核心在需要访问数据时停滞的可能性。
因此，如果你要对某个特定数据或一系列中间结果进行大量操作，只要它在同一个核心上，处理不会中断。如果将数据移到不同的核心，则需要后台工作将数据传输过去，以便其他核心继续处理。这与 CPU 中的处理类似：一个进程通常会在单个核心上执行，因为该核心的缓存已经加载了该进程所需的数据。
关注 PolkaWorld 公众号，我们将继续发布第二部分！第二部分详细介绍了 JAM 包含哪些服务，以及 JAM 接下来的路线图！
也可以查看原视频：https://www.youtube.com/watch?v=UxcmPC-yY0A&t=455s
PolkaWorld Telegram 群：
https://t.me/+z7BUktDraU1mNWE1
PolkaWorld Youtube 频道：
https://www.youtube.com/c/PolkaWorld
PolkaWorld Twitter：
@polkaworld_org
更多内容
JAM 让 Polkadot 实现真正的 Web3 网络，这是许多项目承诺但未实现的！
关注 PolkaWorld
发现 Web 3.0 时代新机遇
点个 “在看” 再走吧！
