干货 | 理解以太坊的第2层扩展方案

原创 2018-03-19 Josh Stark 以太坊爱好者

宾夕法尼亚州的尼科尔森大桥建设照片(来源)。罗马人的工程原理正在被扩展到新用途上


对于以太坊来说,2018年是进行基础建设的一年。今年是早期采用测试网络极限的一年,今年将重新关注扩展以太坊的技术。


以太坊仍处于初级阶段。现在,它不具备安全性和可扩展性。任何密切关注该技术的人都能很好地理解这一点。但在过去的一年里,ICO驱动的炒作已经开始夸大目前的网络容量。以太坊和web3期望建设的——一个安全、易用、由一套共同的经济协议约束、可供数十亿人使用的分布式互联网,仍处于发展阶段,直到关键基础设施建成之后才能实现。


致力于构建此基础架构并扩大以太坊容量的项目通常称为扩容方案。它们有许多不同的形式,并且常常互相兼容或互补。


在这篇长文章中,我想深入探讨一种扩容方案:“链下”或“第二层”解决方案。


  • 首先,我们将概括地讨论以太坊(以及所有公共区块链)的扩展挑战。

  • 其次,我们将介绍解决扩容挑战的不同方法,分为“第1层”和“第2层”解决方案。

  • 第三,我们将深入研究第2层解决方案,并解释它们的工作原理——具体来说,我们将讨论状态通道,Plasma 和 Truebit


本文重点向读者提供关于第2层解决方案工作原理的全面、详细的概念性理解。我们不会深入研究代码或特定的实现方案,相反的,我们重点在于理解用于构建这些系统的经济机制以及所有第2层技术之间共同的常见见解。



一. 公有链的扩容挑战


首先,理解“扩容”不是一个单一的具体问题是很重要的。它指的是一系列必须克服的挑战,使得以太坊能对数十亿的全球用户有用。


最常讨论的扩容挑战是交易吞吐量。目前,以太坊每秒可以处理大约15笔交易,而Visa的处理速度大约为45,000 / tps。在过去的一年里,一些应用(比如 Cryptokitties,或者偶尔的 ICO)已经足够流行,来“减缓”网络速度并提高 gas 价格。


像以太坊这样的公有链的核心限制是,每一笔交易都要由网络中的 每一个节点 进行处理。在以太坊区块链上进行的每一项操作(付款,一个以太猫的诞生,新的ECR20合约的部署)都必须由网络中的每一个节点并行处理。区块链的设计就是这样的,这是使得公有链具有权威性的一部分。一个节点不需要依赖其他节点来告诉它区块链的当前状态是什么,它自己会搞清楚。


这给以太坊交易吞吐量带来了根本性的限制:它不能高于我们对单个节点所要求的交易吞吐量。


我们 可以 要求每一个节点做更多的工作。如果我们把区块大小扩大2倍(即区块 gas 值限制),这就意味着每一个节点的工作量是之前区块工作量的两倍。但是这是以去中心化为代价的:节点做的工作多了,意味着算力小的计算机(就像消费者设备)可能会退出网络,挖矿在算力大的节点上就变得更加中心化。

相反,我们需要一种方法,可以让区块链在不增加单个节点工作量的情况下做更多有用的事情。


从概念上讲,我们有两种方法可能解决这个问题:


Ⅰ. 如果每个节点不需要并行处理每个操作会怎么样?


第一个方法不符合我们的前提,如果我们可以构建一个区块链,那么每一个节点不需处理每一个操作会是什么样的?相反的,如果网络分为两部分,每个部分可以半独立运作,会是什么样的?


A部分可以处理一批交易,而B部分处理另一批交易。实际上这会使区块链交易吞吐量翻倍,因为交易限制变成了两个节点同时处理的交易总量。如果我们可以把区块链分成许多部分,那么我们就可以成倍的增加区块链的交易吞吐量。


这就是分片背后的智慧,分片,是 Vitalik 的以太坊研究小组以及其他团队研究的扩容方案。区块链被分成不同的部分,称为碎片,每个部分都可以独立处理交易。分片通常被称为第1层扩展方案,因为它是在以太坊本身的基本级协议中实现的。如果你想了解更多关于分片的知识,我推荐你看这个扩展问答和这篇博文。(编者按:中译本见文末超链接《以太坊上的分片》及《以太坊分片:overview and finality》)



Ⅱ. 如果我们能够从以太坊现有的容量中挤出更多有用的业务会怎样?


第二种选择是从相反的方向考虑的:并不是增加以太坊区块链本身的容量,如果我们能用已有的容量做更多的事情会怎样?基层以太坊区块链的吞吐量是相同的,但实际上我们可以做更多对人们以及应用程序有用的操作,像交易、游戏里的状态更新或者简单的计算。


这就是状态通道,Plasma 和 Truebit 等“链下”技术背后的智慧。尽管它们每一个都解决了不同的问题,但它们都是通过链下操作而不是在以太坊区块链上运行的,同时仍然保证了足够的安全性和不可更改性。


它们也被称为第二层解决方案,因为它们构建在以太坊主链上。它们不要求对基层协议的更改,相反的,它们只是以以太坊智能合约的形式存在,与链下软件进行交互。




二. 第二层解决方案是加密经济解决方案


在深入理解特定的第2层解决方案之前,理解使其成为可能的基础见解非常重要。


公有链的基本能力在于加密经济共识。仔细调整激励机制,并且通过软件和加密技术来保护它们,我们可以创建可靠的、就系统内部状态达成一致的计算机网络。这是 Satoshi 白皮书的关键见解,该白皮书现在已应用于许多不同的公有链(包括比特币和以太坊)的设计中。


加密经济学给了我们一个确定性的 核心 ——我们知道,除非一些极端情况就像发生了51%的攻击,链上的操作(就像支付、或者智能合约)会像写定的那样执行。


第2层解决方案背后的智慧,是我们可以将这个核心内核的确定性作为 锚点——我们附加其他经济机制的一个固定点。第二层经济机制 可以向外扩展公有链的效用,让我们可以进行 链下 交互,如果有必要的话,仍然可以可靠地 引用 该核心内核。


这些构建在以太坊之上的层并不总是与链上操作具有相同的保证。但是它们仍然具有足够的 不可更改性 和 安全性,所以仍然是非常有用的。尤其是当不可更改性的要求有稍微的下降时,我们能以更快的速度或更低的开销来进行操作。


加密经济学并不是以 Satoshi 的白皮书开始和结束的——它是我们学习应用的一种技术。它不仅在核心协议的设计中,而且在扩展底层区块链功能的第二层系统的设计中。


Ⅰ. 状态通道


状态通道是一种技术,一种进行链下交易和其他状态更新的一种技术。然而,在一个状态通道内发生的事情仍然保持着非常高的安全性和不可更改性:如果出现任何问题,我们仍然可以选择回溯到链上交易中确定的“硬核”。


大多数的读者对支付通道 比较熟悉,支付通道已经存在了好几年了,并且最近通过闪电网络搭建在了比特币上。状态通道是更 通用 的支付通道,它们不仅可以用来进行支付,还可以用来在区块链上进行任意的状态更新,就像改变智能合约的内部状态。2015年,杰夫·科尔曼首次详细描述了状态通道。


解释状态通道如何运行的最佳方法就是看一个例子。记住,这是一个概念性解释,这意味着我们不会涉及具体实现的技术细节。


想象一下,Alice 和Bob 想玩一个井字游戏,赢家可以获得1eth。要做到这一点,最简单的方法就是在以太坊上创建一个智能合约,它可以实现井字游戏的规则,并跟踪每个玩家的操作。每次当一个玩家进行一次操作的时候,他们向智能合约发起一个交易。当其中一个玩家赢了的时候,就像规则里描述的那样,智能合约就给赢家支付1eth。


这是可行的,但是效率低下、速度慢。Alice和Bob正在让整个以太坊网络处理他们的游戏,这可能多于他们的需求。每次玩家想要进行操作的时候,他们都必须支付gas费用,而且他们必须等几个块开采后才能采取下一步行动。


相反的,我们可以设计一个系统,让Alice和Bob在 尽可能少地进行链上操作 的情况下来玩井字游戏。Alice和Bob将能在链下更新游戏的状态,同时仍然有充分的信心,如果有必要的话,他们可以恢复到以太坊主链的状态。我们把这种系统称为状态通道。


首先,我们在以太坊主链上创建一个理解井字游戏的智能合约“法官”,并把 Alice 和 Bob 初始化为两个游戏玩家。这个智能合约包含 1eth 的价格。


然后,Alice 和 Bob 开始玩游戏。Alice 创建并签署了一个描述她第一次操作的交易,并将它发送给 Bob,Bob 也对交易签了名,并把签名版本发了回去,而且为自己保留一个副本。然后,Bob 创建并签署了一个描述他第一次操作的交易,并将它发送给 Alice,Alice 也对交易进行签名,再发回去,并为自己保留一个副本。每次,他们都更新游戏的当前状态。每一个交易包含一个声明,这意味着后面的交易总是能知道每一个操作发生的顺序。


到目前为止,没有任何事情发生在链上。Alice 和 Bob 只是在网上互相发送交易,没有任何东西传到区块链上。然而,所有的交易都能发送到法官合约上,换句话说,它们是有效的以太坊交易。你可以把这看作是两个人来回互相在写一系列区块链认证的支票。实际上没有钱存入银行或取出,但每人都有一堆他们可以随时存入的支票。


当 Alice 和 Bob 结束这个游戏时,也许是因为 Alice 赢了,他们可以向法官合约提交最终的的状态(例如一系列的交易)来关闭这个通道,这样只支付一笔交易的费用。法官合约确保这个最终状态是双方都签名的,等一段时间以确保没有人能合法的改变这个结果,然后就向 Alice 支付 1eth 的奖励。


为什么我们需要法官合约所等待的“挑战期”?


想象一下Bob没有把最终的真实状态发送给法官,而是发送之前的状态(一个之前他能赢 Alice 的状态)。法官只是一个传统的合约,它本身无法知晓这是否是最新的状态。


挑战期给了 Alice 一个向法官合约证明 Bob 关于游戏最终状态的谎言的机会。如果 Bob 发送的是更早的状态,那么 Alice 是保留过这个状态的副本的,她就可以把这个状态提交给法官合约。法官合约通过查看声明就能判断Alice发送的状态是最新的,并且拒绝 Bob 窃取胜利的企图。


功能和限制


状态通道在许多应用中都非常有用,它们在执行链上操作方面有严格的改进。然而,重要的是要记住,在决定一个应用程序是否适合通道化时,就已经做了特定的权衡:


  • 状态通道依赖于有效性。如果 Alice 在挑战期内丢失了网络连接(可能是Bob渴望赢得奖品,破坏了她家的网络连接),她可能无法在挑战期结束前做出回应。不过,Alice 可以让他人保留自己的状态副本,并支付一定费用,来保持她的有效性。

  • 当参与者将在很长一段时间内交换许多状态更新时,它们特别有用。这是因为在部署法官合约时创建的状态通道有一个初始成本,不过一旦部署完毕,在该通道内每个状态更新的成本就会非常低。

  • 状态通道最适用于具有一组确定的参与者的应用程序。这是因为法官合约必须始终知道作为通道的一部分的实体(即地址)。我们可以添加和删除成员,但每次都需要更改合约。

  • 状态通道拥有强大的隐私性,因为一切都在参与者之间的通道“内部”发生,而不是广播和记录在链上。只有最初和最后的交易必须公开。

  • 状态通道具有即时终结性,这意味着只要双方都签署了一个状态更新,这个状态就可以被认为是最终状态。双方对此都有很高的保证,如果有必要,他们可以“强制执行”将此状态放到链上。


在 L4 中,我们正在构建 Counterfactual 框架:一个在以太坊上的广义状态通道的框架。我们通用的模块化的实现,将允许开发人员即使本身不是状态通道专家的情况下,在其应用程序中使用状态通道。你可以在这里阅读关于这个项目的更多内容。我们将在2018年第一季度发布描述我们技术的论文。


另一个以太坊上值得注意的状态通道项目是雷电网络,它目前专注于建立一个支付通道网络,模式与闪电网络相似。这意味着你不必与每个想要与之交易的特定人员都开通一个状态通道,你可以打开一个连接着更大的状态通道网络的通道,如此你可以向任何连接在这个状态通道网络上的人付款,并且不需与额外的费用。


除了 Counterfactual 框架和雷电网络,在以太坊还有几个用于特定于应用程序的状态通道。例如,Funfair 为其分布式博弈平台建立了状态通道(他们称之为“博弈通道”),Spankchain 已经为成人参与者建立了单向支付通道(他们还为其ICO使用了状态通道),而且 Horizon Games 在他们的第一个以太坊为基础的游戏中也在使用状态通道。


Ⅱ. Plasma


2017年8月11日,Vitalik Buterin 和 Joseph Poon 发表了一篇名为《Plasma:自主智能合约》的文章。这篇论文介绍了一种新技术,可以使得以太坊每秒交易数比目前可达到的更多。


就像状态通道,Plasma 是一种链下交易的技术,同事它依靠以太坊底层来实现它的安全性。不过 Plasma 是从一个新的方向实现了状态通道,它允许创建附加在以太坊主链上的子链。这些子链反过来可以产生他们自己的子链,他们的子链也可以产生他们子链,等等。


其结果就是,我们可以在子链级别执行许多复杂的操作,运行拥有数千名用户的整个应用程序,并且只需与以太坊主链进行尽可能少的交互。Plasma 子链可以更快地操作,且交易费用更低,因为它的操作不需要在整个以太坊区块链存留副本。


plasma.io/plasma.pdf


为了理解Plasma如何运行的,我们来看一个如何使用它的例子。


让我们假设你正在以太坊创建一个交易卡游戏。这些卡片将是 ERC 721 不可替代的 token(如 Cryptokitties ),但这些卡片具有某些的定的特征和属性可让用户互相对战。例如“炉石传说”或“万智牌”。 这种复杂的操作在链上执行起来是很昂贵的,所以你决定使用Plasma来代替应用程序。


首先,我们在以太坊主链上创建了一套智能合约,作为Plasma 子链的“根”。Plasma 根包含了子链的基本“状态交易规则”(诸如“交易不能花费已经花费的资产”),记录了子链状态的哈希值,并且作为一种“桥梁” 让用户在以太坊主链和子链之间转移资产。


然后,我们创建子链。子链可以拥有它们自己的共识算法,在这个例子中,假设它使用 POA,POA 是一种简单的、依赖于可信块生产者(即验证者)的共识机制。区块生产者与 POW 系统中的矿工类似,它们是接收交易、形成区块并收取交易费的节点。让我们保持例子的简单性,假设你(创建游戏的公司)是唯一一个创建区块的实体,即你的公司运行着几个节点,这些节点被当做子链的块生产者。


子链一旦创建并激活,块生产者将定期向根合同做出声明。这意味着他们实际上在说“我声明子链中最新的一块是X”。这些声明被记录在Plasma根中的链上,作为子链发生计算的证据。


现在子链已经准备好了,我们可以创建交易卡游戏的基本组件。卡片本身是 ERC721 中、最初在以太坊主链上创建的,然后通过 Plasma 根移动到子链上。这引出了一个关键点:Plasma 允许我们扩展基于区块链的数字资产的互动,但这些资产需要首先在以太坊主链上创建。然后,我们在子链上部署包含所有游戏逻辑和规则的实际游戏应用的智能合约。


当用户想玩我们的游戏时,他们 只与子链交互 。他们可以持有资产(ERC721卡)与以太币进行兑换,和其他用户(无论我们的游戏允许他们做什么)玩游戏,而无需直接与主链交互。因为只有非常少的节点(即块生产者)必须处理交易,所以交易费会很低并且操作会很快。


但是这样安全吗?


通过把更多操作从主链移到子链上,很明显我们可以进行更多操作。但这样有多安全?发生在子链上的交易实际上是否真的是最终的?毕竟,我们刚刚描述了一个系统,其中只有一个实体控制着我们子链的块的生产。这不是中心化吗?公司会不会窃取你的资金,或者只要它想就能随时拿走你的收集卡片(资产)吗?


简而言之,即使在单个实体控制子链上所有块生产的 情况 下,Plasma 也为你提供了一个基本保证,即你始终可以将金和资产退回到主链上。如果一个块生产者开始恶意行事,可能发生的最糟糕的事情就是他们迫使你离开子链。


让我们了解一下块生产者能恶意行为的几种情况,并了解Plasma如何处理这些情况。


首先,想象一下一个块生产者对你进行欺诈——通过创建一个你的资金立即被他们控制的假的新块。他们是唯一的块生产者,所以他们可以随心所欲的创建不符合我们区块链规则的新块。就像其他区块一样,他们必须向根合约广播一个包含此区块证据的声明。


就像上面提到那样,用户总是有一个最终的保证:他们可以把资产退回到主链上。在这种情况下,用户(或者更确切地说一个代表他们的应用程序)能够检测到盗窃的企图,并且在区块生产者尝试并使用他们偷到的资产之前把自己的资产退回到主链上。


Plasma 还创建了一种机制,防止欺诈时不能退回到主链上。Plasma 包含了一个机制,任何人(包括你在内)都可以向根合约发布欺诈证明,尝试表明该块的生产者有欺诈行为。这个欺诈证明会包含前一个块的信息,并且允许我们证明根据子链规则,当前块(错误块)不是根据前一个块的状态正确产生的。如果这个欺诈被证实,那么子链就会回滚到前一个区块的状态。更好的是,我们构建了一个处罚系统:任何对错误块签名的块生产者都会丢失他们在链上的保证金。


plasma.io/plasma.pdf


但是提交一个欺诈证明要求你能获取底层数据——即:用于证明欺诈的区块的实际历史。如果块生产者为了阻止 Alice 向根合约提交欺诈证明,没有把之前的块的信息进行共享怎么办?


在这种情况下,Alice的解决方案是把她的资金退回到主链上,并离开这个子链。本质上,其实是Alice向根合同提交了“证明资金”。在任何人都能向她的证明发出挑战的延迟期后(例如,证明她在之后一个合法的区块里花掉了这些资金),Alice的资金就回到了以太坊主链上。


plasma.io/plasma.pdf


最后,块生产者可以审查子链的用户。如果他们想,块生产者可以不把某些交易包含到块中,从而有效地阻止了一个用户在子链上的任何操作。如上所述,此种情况下,对于用户来讲,解决方案仅仅是把资产退回到以太坊主链上就可以了。


但是,资金退回本身就有风险。有一个问题是,如果子链上所有的人都同时退回资金会发生什么。在大量资产退回的情况下,以太坊主链在挑战期内可能没有足够的容量来处理每个人的交易,这意味着用户可能会丢失资金。尽管有许多能阻止这种情况发生的技术,例如,通过延长挑战期的方式来适应资金退回的需求。


值得注意的是,并不是所有的块生产者都要被一个实体所控制——这只是一个的极端的例子。我们可以创建子链,并把块生产者分布在不同的实体中,即,类似公有链那样,以一种分布式的方式进行管理。在这种情况下,块生产者以上述方式进行干预的风险较小,因此用户不得不把资产转移到主链上的风险也小。


现在我们已经介绍了状态通道和 Plasma,以下几点对比值得注意。


有一点不同就是当状态通道的各方都同意退出时,状态通道可以立即执行资金回退。如果Alice和Bob都同意关闭通道并退回资金,只要他们对最终状态达成一致,他们可以立即从状态通道中得到他们的资产。这在plasma中是不可能的,就像上面说的,用户必须经历一个有挑战期的资金退回过程。


状态通道平均每个交易的交易费要比Plasma便宜,而且状态通道速度更快。这就意味着我们可能在Plasma上构建状态通道。例如,在有两个用户进行一系列小交易交互的应用程序上,构建状态通道。在子链级别构建状态通道比直接在子链上处理交易更快更便宜。


最后值得注意的是,这些只是部分描述,我们还遗漏了许多细节。Plasma 本身就处于非常早的阶段。如果你想了解更多关于 Plasma 的现状,可以看 Vitalik 最近关于 Plasma 最小实现版的提议(即精简 Plasma 实现方案)。这里有台湾团队正在实现的Plasma,你可以在这个代码库中找到。OmiseGo 正在实施他们的分布式交互进行——他们进度的更新在这里。


Ⅲ.Truebit


Truebit 是链下一种帮助以太坊进行繁重、复杂计算的技术。这使得它与状态通道和Plasma不同,它们对于提高以太坊区块链的总交易吞吐量更有用。正如我们在开篇部分所讨论的那样,扩容是一个多方面的挑战,它不仅仅要提高交易吞吐量。Truebit 不会提高交易吞吐量,但它能让基于以太坊的应用程序仍然以在主链上验证的方式,做更复杂的事情。


这将使我们能够对以太坊应用程序有用的、计算成本高、无法在链上进行的操作。 例如,验证来自其他区块链的简单支付验证(SPV)证明,这个证明可以让以太坊智能合约“检查”交易是否在另一个链上已经发生(如比特币或狗狗币)。


让我们看一个例子。想象一下你有一些代价昂贵的计算(就像 SPV 证明)需要作为应用程序的组成部分。你不能仅仅把它当做以太坊主链智能合约的一部分,因为SPV证明的计算代价是非常昂贵的。记住,在以太坊上直接进行任何计算都是非常昂贵的,因为每个节点都要并行处理这种操作。以太坊的区块有一个 最大 gas 值限制,从而为该区块中所有交易能执行的计算总量设置了上限。一个 SPV 证明的计算代价是非常大的,即使它是区块里唯一的交易,它需要的 gas 值也是单个区块 gas 值限制的许多倍。


相反,你向别人支付一小笔费用,把计算放到链外。收你钱的人就被称为求解者。


首先,求解者支付智能合约中的保证金。然后,你给求解者描述一下他们需要执行的计算。他们进行计算,并返回结果。如果结果是正确的(大多都在一秒钟内),他们的保证金就能返回。如果事实证明求解者没有正确执行计算——即他们有欺诈操作或犯了错误,那么他们就失去保证金。


但是,我们如何判断返回结果是正确还是错误呢?Truebit 使用一种称为“验证游戏”的经济机制。从本质上讲,我们为被称作挑战者的其他团体创造了激励,让他们来检查求解者的工作。如果挑战者能够通过验证游戏证明求解者提交了错误的结果,那么挑战者将得到奖励,而求解者则丢失了他们的保证金。


由于验证游戏是链上执行的,因此它不能仅仅计算结果(这会破坏系统的整个目的,如果我们把计算在链上质询,则不需要Truebit)。相反,我们强迫求解者和挑战者来验证他们没有达成一致的具体操作。实际上,我们把双方逼到一个死角——找到他们不同意结果的实际代码行。


Truebit的简化概念图


一旦一个特定的操作经过了验证,那么它就小到足以在以太坊主链上执行了。然后我们以太坊上的智能合约执行这个操作,这个智能合约能够一劳永逸的解决哪一方在说真话,哪一方在说假话或者或者犯了错误。


如果你想了解更多关于Truebit的东西,你可以阅读这篇文章,或者Simon de la Rouviere的博客。(编者注:中译本见文末超链接《一个可扩展的去中心化计算的代码执行法庭》)



三. 结论


第2层的解决方案都有一个共同的见解:一旦我们拥有公有链提供的确定性核心内核,我们就可以将其用作扩展区块链应用程序可用性的加密经济系统的锚点。


现在我们已经研究了一些示例,我们可以更具体地了解第2层解决方案是如何应用此见解的。第2层解决方案使用的经济机制往往是互动游戏:它们通过为不同团体创建激励,来相互竞争或“检查”彼此的工作。区块链应用程序可以假定某给定的声明可能是真实的,因为我们已经为另一方创建了强激励,来证明你提供给它的是错误的信息。


在状态通道中,这就是我们如何确认通道最终状态的方法——通过给各团体一个“反驳”对方的机会。在 Plasma 中,这就是我们如何管理欺诈证明和资金退回的方法。在Truebit 中,这就是我们如何确保求解者说出真相的方法——通过激励验证者证明求解者的错误。


这些系统将有助于我们标注将以太坊扩展到庞大全球用户群中所涉及的挑战。 一些像状态通道和 Plasma 等将增加平台的交易吞吐量。像 Truebit 这样的其他方案将可以在智能合约中进行更加 困难 的计算,从而开创新的使用案例。


这三个例子仅代表加密经济解决方案可能设计空间的一小部分。我们甚至没有说像 Cosmos 或 Polkadot 这样的“跨链协议”所做的工作(尽管他们还有一些其他内容都是“第2层”解决方案,但这些另一篇文章的主题)。我们还应该期望发明新的、不可思议的第2层系统,以改进现有模型,或在速度、不可更改性和开销之间提供新的权衡。


比任何特定第二层解决方案更重要的是,进一步发展底层的技术和机制,如果可能的话,要把加密经济设计这种底层技术放到第一位。


对于像以太坊这样的可编程区块链的长期价值而言,这些第2层扩展方案是一个有力的论据。只有在区块链可编程时,构建第2层解决方案的经济机制才是可能的:你需要使用脚本语言来编写执行交互式游戏的程序。这对比特币等区块链来说要困难得多(或者在某些情况下,比如 Plasma 是不可能的),因为它只提供有限的脚本功能。


以太坊允许我们构建第2层解决方案,以便在速度、不可更改性和开销之间找到新的权衡点。这使得底层区块链更适用于多种类的应用程序,因为具有不同威胁模型的不同类型的应用程序,对于不同的权衡有自然的偏好。对于我们希望保护的民族的、国家的高价值交易,我们使用主链。对于速度更重要的数字资产交易,我们可以使用Plasma。第2层可以让我们在保持去中心化的特性、不可更改的特性和不影响底层区块链的情况下做出这些权衡。


而且,事先很难预测给定的扩展方案需要哪些脚本功能。设计Ethereum时,Plasma 和 Truebit 尚未发明。但是因为以太坊是完全可编程的,它实际上能够实现我们发明的任何经济机制。


充分利用区块链技术的价值的唯一方法,是通过可编程区块链(如以太坊)来实现这一加密经济公式创建的 核心确定性。


感谢 Vitalik Buterin,Jon Choi,Matt Condon,Chris Dixon,Hudson Jameson,Denis Nazarov 和 Jesse Walden 对本文早期草稿的评论。




原文链接: https://medium.com/l4-media/making-sense-of-ethereums-layer-2-scaling-solutions-state-channels-plasma-and-truebit-22cb40dcc2f4
作者: Josh Stark
翻译&校对: 刘艳安 & Elisa


本文由作者授权 EthFans 翻译及再出版。

那以后中心化公链都要被淘汰,以太坊上创建链,就跟现在发个ico一样简单,几分钟就能创建一条链

### 回答1: Spark Streaming 和 Flink 都是流处理框架,但在一些方面有所不同。 1. 数据处理模型 Spark Streaming 基于批处理模型,将流数据分成一批批进行处理。而 Flink 则是基于流处理模型,可以实时处理数据流。 2. 窗口处理 Spark Streaming 的窗口处理是基于时间的,即将一段时间内的数据作为一个窗口进行处理。而 Flink 的窗口处理可以基于时间和数据量,可以更加灵活地进行窗口处理。 3. 状态管理 Spark Streaming 的状态管理是基于 RDD 的,需要将状态存储在内存中。而 Flink 的状态管理是基于内存和磁盘的,可以更加灵活地管理状态。 4. 容错性 Flink 的容错性比 Spark Streaming 更加强大,可以在节点故障时快速恢复,而 Spark Streaming 则需要重新计算整个批次的数据。 总的来说,Flink 在流处理方面更加强大和灵活,而 Spark Streaming 则更适合批处理和数据仓库等场景。 ### 回答2: Spark Streaming 和 Flink 都是流处理框架,它们都支持低延迟的流处理和高吞吐量的批处理。但是,它们在处理数据流的方式和性能上有许多不同之处。下面是它们的详细比较: 1. 处理模型 Spark Streaming 采用离散化流处理模型(DPM),将长周期的数据流划分为离散化的小批量,每个批次的数据被存储在 RDD 中进行处理,因此 Spark Streaming 具有较好的容错性和可靠性。而 Flink 采用连续流处理模型(CPM),能够在其流处理过程中进行事件时间处理和状态管理,因此 Flink 更适合处理需要精确时间戳和状态管理的应用场景。 2. 数据延迟 Spark Streaming 在处理数据流时会有一定的延迟,主要是由于对数据进行缓存和离散化处理的原因。而 Flink 的数据延迟比 Spark Streaming 更低,因为 Flink 的数据处理和计算过程是实时进行的,不需要缓存和离散化处理。 3. 机器资源和负载均衡 Spark Streaming 采用了 Spark 的机器资源调度和负载均衡机制,它们之间具有相同的容错和资源管理特性。而 Flink 使用 Yarn 和 Mesos 等分布式计算框架进行机器资源调度和负载均衡,因此 Flink 在大规模集群上的性能表现更好。 4. 数据窗口处理 Spark Streaming 提供了滑动、翻转和窗口操作等灵活的数据窗口处理功能,可以使用户更好地控制数据处理的逻辑。而 Flink 也提供了滚动窗口和滑动窗口处理功能,但相对于 Spark Streaming 更加灵活,可以在事件时间和处理时间上进行窗口处理,并且支持增量聚合和全量聚合两种方式。 5. 集成生态系统 Spark Streaming 作为 Apache Spark 的一部分,可以充分利用 Spark 的分布式计算和批处理生态系统,并且支持许多不同类型的数据源,包括Kafka、Flume和HDFS等。而 Flink 提供了完整的流处理生态系统,包括流SQL查询、流机器学习和流图形处理等功能,能够灵活地适应不同的业务场景。 总之,Spark Streaming 和 Flink 都是出色的流处理框架,在不同的场景下都能够发挥出很好的性能。选择哪种框架取决于实际需求和业务场景。 ### 回答3: Spark Streaming和Flink都是流处理引擎,但它们的设计和实现方式有所不同。在下面的对比中,我们将比较这两种流处理引擎的主要特点和差异。 1. 处理模型 Spark Streaming采用离散流处理模型,即将数据按时间间隔分割成一批一批数据进行处理。这种方式可以使得Spark Streaming具有高吞吐量和低延迟,但也会导致数据处理的粒度比较粗,难以应对大量实时事件的高吞吐量。 相比之下,Flink采用连续流处理模型,即数据的处理是连续的、实时的。与Spark Streaming不同,Flink的流处理引擎能够应对各种不同的实时场景。Flink的实时流处理能力更强,因此在某些特定的场景下,它的性能可能比Spark Streaming更好。 2. 窗口计算 Spark Streaming内置了许多的窗口计算支持,如滑动窗口、滚动窗口,但支持的窗口计算的灵活性较低,只适合于一些简单的窗口计算。而Flink的窗口计算支持非常灵活,可以支持任意窗口大小或滑动跨度。 3. 数据库支持 在处理大数据时,存储和读取数据是非常重要的。Spark Streaming通常使用HDFS作为其数据存储底的系统。而Flink支持许多不同的数据存储形式,包括HDFS,以及许多其他开源和商业的数据存储,如Kafka、Cassandra和Elasticsearch等。 4. 处理性能 Spark Streaming的性能比Flink慢一些,尤其是在特定的情况下,例如在处理高吞吐量的数据时,在某些情况下可能受制于分批处理的架构。Flink通过其流处理模型和不同的调度器和优化器来支持更高效的实时数据处理。 5. 生态系统 Spark有着庞大的生态系统,具有成熟的ML库、图处理库、SQL框架等等。而Flink的生态系统相对较小,但它正在不断地发展壮大。 6. 规模性 Spark Streaming适用于规模小且不太复杂的项目。而Flink可扩展性更好,适用于更大、更复杂的项目。Flink也可以处理无限制的数据流。 综上所述,Spark Streaming和Flink都是流处理引擎,它们有各自的优缺点。在选择使用哪一个流处理引擎时,需要根据实际业务场景和需求进行选择。如果你的业务场景较为复杂,需要处理海量数据并且需要比较灵活的窗口计算支持,那么Flink可能是更好的选择;如果你只需要简单的流处理和一些通用的窗口计算,Spark Streaming是更为简单的选择。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值