# 第一章：介绍与动机
# 1.1 命名
如果你不知道的话，这是我将要做的几次演讲中的第一次，关于我大约三周前发表的一份文档——灰皮书。它描述了一个协议——Join-Accumulate Machine，简称 JAM——我希望能将 Polkadot 协议，特别是 Polkadot 中继链，过渡到这个协议上。这些讲座不是——每次讲座都不是一个完整的讲座。它是一个系列讲座的一部分，基本上意味着今天的讲座不会感觉特别完整。但当所有东西与其他八九个讲座——我将在接下来的五六周内进行——结合在一起时，你应该对这个协议有一个相当完整的了解。尽管如此，我将在时间允许的情况下，在最后尽量谈谈那些我不会深入讲解的内容，取决于我们实际上能有多少时间。因为是第一次讲座，我不太确定能讲多长时间或多少细节。好的，我认为这就是我想要覆盖的内容——用来介绍这是什么。我将逐点、逐段地讲解灰皮书，解释每一部分的含义，以及如果某些内容没有被明确说明会有什么影响。我非常乐意在整个过程中接受提问。如果你对某个特定部分有问题，可以举手。如果你愿意等到最后，也可以等到最后——在讲座结束时会有一个问答环节。除了论文之外，我确实有一些幻灯片——它们在这里。我不知道怎么全屏显示——我们可以就这样做。我想从——你知道吗，我应该从摘要开始。让我们回到摘要。
好的。嗯，这有多大？你能看到吗？太小了？好吧，可以。好的。灰皮书上面有我的名字，我写的。显然它不仅仅是我的工作。很多想法是我的，但要将这些想法提炼成可行的东西需要比我更多的人。但文字是我写的。好的。摘要——这是一份正式规范。它不是像 Polkadot 论文那样的愿景文件——那份论文没有太多细节。这是完全详细的，从这份文档中应该可以以一种与任何其他试图实现该协议的人基本兼容的方式来实现这个协议。所以在那个意义上，它应该是一份无歧义的规范。这与我大约 10 年前写的 Ethereum 黄皮书非常相似。JAM 有点像 Polkadot 和 Ethereum 的婚姻。它从两者中都取了一些元素。特别是它取了 Polkadot 的扩展机制，并将其融入更像 Ethereum 的范式——有点像里面有一些类似于智能合约的东西。JAM 协议围绕着一种二元论，我们将在本次讲座的最后讨论这个。但具体来说，名称是 in-core 和 on-chain 二元论——两种不同的方式进行安全的共识计算。
我们已经熟悉了 on-chain 的概念——在链上做计算。当比特币处理交易并计算哪些输出现在已花费、哪些未花费时，那就是 on-chain 计算。当 Ethereum 的智能合约被处理时，它们在链上被处理。我们不熟悉 in-core。In-core 计算本质上与 Ethereum 世界中的乐观 rollup 有些相似——它本质上是离链完成的计算，但其正确性通过博弈论机制保证——这些机制植根于链上。
JAM 是无许可的。这与原始 Polkadot 中继链形成对比——在那里需要赢得一个 slot 拍卖。我的意思是技术上任何人都可以参加 slot 拍卖，所以技术上 Polkadot 也是无许可的。但 JAM 是无许可的，意味着准入门槛低得多。所以你不仅不需要许可，而且你也不需要很多支持——财务上或社区方面——来将代码部署到 JAM 上。JAM 协议利用了 core time 这个底层概念——基本上是 Polkadot 对 block space 的等价物——但在一个特定的形式化下。具体来说，它是在我们所说的 Polkadot 的一个 core 中在某个特定时间段内你能做的事情。时间被量化为特定的区块——我一会儿也会简要讨论这个。本质上，这个 core time 是 web3 计算——或弹性、安全、无处不在的计算能力——的一个度量标准。它有点像 Ethereum 的 EVM gas。最后，JAM 被设计为兼容——或托管一个服务——使得 Polkadot 平行链可以迁移到那个在 JAM 上运行的服务中，而不会有任何重大中断。
好的，我希望这作为我对摘要的解释是相当清楚的。现在我要稍微谈谈命名，因为当我们说 Polkadot 时，我们可以指很多不同的东西。Polkadot 是一个网络、一个技术栈、一个经济体。它也是一个社区。因为我们对同一个术语有这种超载的使用，它不总是那么容易知道——可能会产生混淆。这就是为什么这个协议不叫"新 Polkadot 协议"，而是有自己的名字。这不是因为它是与 Polkadot 不同的东西或在战略上与 Polkadot 竞争的东西。而是因为我想清楚地说明我在描述的是什么。它之前——JAM 背后的想法之前由我在一个 RFC 中提出——几个月前——我想是去年秋天——叫做 Core JAM。现在它缩短成了 JAM。但它是同样的想法，只是经过了改革，并且围绕它有了很多额外的东西，使其成为一个连贯的协议，而不仅仅是一个关于如何改变现有 Polkadot 协议的想法。
# 1.2 驱动因素
驱动因素——为什么要费心做这个？大致来说，驱动因素是——首先是创建一个 web3 协议，这意味着弹性。其次是改进现有的 web3 协议——就是这其他四件事。通用性——它应该足以支持各种不同的应用，而不仅仅是少数几个或一个。性能——本质上以任何特定时间段内可以完成的计算量来衡量，但也可以以计算的成本或最低可能成本来衡量。我要调换另外两个的顺序。可访问性——本质上是实际使用这个系统有多容易——它是否到处可用。最后是连贯性。连贯性是一个有趣的——我将更深入地讨论连贯性——但连贯性本质上意味着——如果我在系统的一个部分，与系统其他部分互操作有多容易——它是否是同质化的容易程度——还是结构性地不同，取决于我想要与系统的哪个部分互操作。我一会儿会更深入地讨论这个。但这些基本上就是我确定的持续创新的驱动因素。连贯性在与我们目前 Polkadot 所拥有的东西进行比较时特别重要——事实上在与大多数其他正在采取的扩展方向进行比较时也是如此——在这个意义上我也包括 Ethereum 及其扩展方案。
# 1.3 规模-同步性对立下的扩展
我要稍微谈一下连贯性。这不是一个官方术语——它只是我想到的一个术语——虽然我从来无法在现有文献中找到任何符合我希望这个术语含义的东西，但后来有人告诉我——我一两周前遇到的——这个想法确实存在于文献中，但我又忘了它用的是什么术语。所以目前我就用这个术语。
这个术语的意思——规模-同步性对立——是说你在系统中有一个自然的权衡——在规模和其内部连贯性——或系统各部分之间的同步性之间。随着系统增长，它变得更不那么同步、更异步、更不连贯。这是一个基本的自然法则——你绕不过去。你可以管理它，但没有魔法粉尘可以撒上去让你完全摆脱它。幸运的是大多数时候这并不那么重要，因为我们可以设计我们的应用程序使我们的解决方案绕过这个限制。但我认为我们在各种努力领域中都看到了这个限制——计算机科学、物理学、生物学——到处——随着系统增长，它们变得不那么连贯、不那么同步——一个部分的变化需要更长时间才能影响到远处的部分。当你想想这其实是有道理的。论文中有一个关于这个对立原则的正式半形式化证明，但我认为如果你思考一下它也是自然而然的。
有趣的是，JAM 在区块链系统中为这个权衡提出了一个新的折中方案。我是说如果——我有一个白板——对——所以我们可以画规模-同步性图——我们可以扩展一个系统并让它同步——我们也可以说它是内部连贯的——基本上我假设存在某种反向的——像倒数——曲线——使得你只能拥有存在于曲线之下的系统。是的。你不能拥有一个既非常大又非常同步的东西——你被限制在曲线之下运行。我们可能看到一些系统规模大但同步性低，我们可能看到一些系统同步性高但只有很小的规模。例如，Ethereum 1 可能在这里——它非常同步——任何智能合约都可以立即调用部署在系统中的任何其他智能合约——状态在可访问性方面完全同构——无论你在哪个智能合约中，你对系统的所有状态都有完全访问权——没问题——但它只能扩展到这里——在一切变得太复杂之前。在这里我们可以说我们可以把东西分出去——我们可以有 10,000 个不同的区块链——每个都有自己的状态——小块的状态——但然后这可能允许规模无限增长——但它们不会是同步的——它们不会是连贯的。是的，我们当然可以用桥接把它们连接起来，但然后那些桥接变得不安全——有延迟——整体上系统失去了连贯性、失去了同步性。
如果你看看计算机架构、机器架构，你可以看到类似的事情发生——这不限于区块链。很明显的一个是——基本的数据处理——你可能有存在于 CPU 上的数据——在寄存器或一级缓存中——那是最大的同步性——但它不会增长。一级缓存非常小——寄存器数量不多。为了将系统扩展到那个之外，我们有二级缓存、三级缓存、RAM。但当我们上升到下一级和下一级时，同步性持续降低。一切都变得越来越异步。CPU 如果只有一件事要做，就只能等待——只能停顿等待它去读内存然后回来。如果我们像 80 年代和 90 年代那样超出内存，我们就去硬盘——我们去二级存储——我们有虚拟内存。当然如今我们甚至不把数据放在那里——我们把数据放在互联网另一边的另一台计算机上。如果你的 CPU 碰巧被阻塞在获取那个数据上，它将要睡很长时间。所以随着我们看到系统增长，同步性自然减少。我们必须处理它，但这并不意味着我们只能选择这里或这里。JAM 是——我不知道——大致来说——第一批说"让我们试着想象一个位于这里的系统——一个很好的甜蜜点——我们获得良好的规模但也获得良好的同步性"的区块链系统之一。