理解以太坊的Layer 2扩容解决方案：状态通道（State Channels）、Plasma 和 Truebit
对于以太坊来说，2018年是专注底层架构之年。今年很多早期参与者会测试网络极限，并且重新关注以太坊的扩容技术。 以太坊仍然处于起步阶段。直到现在，它仍然没有那么安全或者可扩展。对于任何密切关注以太坊技术的人来说，这都是很好理解的。但在过去一年，ICO推动的炒作已经过分夸大了目前的网络能力。以太坊和web3的美好愿景—— 一个安全，易于使用的去中心化网络，由一系列通用的经济协议来约束，并且被数十亿人来使用——这个承诺希望在即，但是只有在关键的底层架构完成的前提下才能实现。 那些正在致力于构建以太坊的底层架构以及扩展其性能的项目通常被称为扩容解决方案。这些方案有很多种形式，并且常常彼此兼容或互补。 在这篇长文中，我想深入探讨某一类扩容解决方案：“链下（off-chain）”或者说“layer 2”解决方案 首先，我们来总体讨论下以太坊（以及所有公链）的扩容挑战。 其次，我们会介绍解决扩容挑战的不同方法，并且会区分“layer 1”和“layer 2”解决方案。 第三，我们会深入研究layer 2解决方案并且解释它是如何工作的——具体来说，我们会讨论状态通道，Plasma和Truebit。 本文的重点是让读者能够对于layer 2解决方案工作原理有一个完整和详细的概念性理解。但是我们不会深入研究代码或特定的实施方案。反之，我们会专注于理解用来构建这些系统的经济机制，还有一些在所有layer 2扩容技术中得以共享的共识。 1. 公链的扩容挑战 首先，重要的是理解“扩容”并不是一个单一的、特定的问题。它指的是一系列以太坊必须要解决的挑战，从而以太坊才能被全球数十亿人使用。 最常讨论的扩容挑战是交易吞吐量问题。目前，以太坊每秒可以处理大约15笔交易，而相比而言Visa的处理能力大约为45,000/tps。在过去一年，一些应用例如以太猫，或者偶发的ICO，都足够火爆，能让以太坊网络“降速”并且会提高交易费用（gas）。 像以太坊这种公链的关键限制在于，每一笔交易都需要被网络中的每一个节点处理。以太坊区块链上的每个操作，一笔交易，以太猫的诞生，部署新的 ERC20 合约，每一个发生在以太坊区块链上的操作都必须由网络中的每个节点并行处理。这是设计理念决定的，它是保证公链权威性的一部分。节点们不用依赖其他节点来告诉它们，区块链的当前状态是什么，它们自己就能搞清楚。 这就从根本上给以太坊网络的交易吞吐量造成了限制：它不能高于我们对单个节点所要求的交易吞吐量。 我们可以让每个节点去承担更多工作。如果我们将区块的大小加倍（也就是区块的gas值限制），也就意味着每个节点处理每个区块的工作量大致是之前的两倍。但是这就带来了影响去中心化的代价问题：节点需要做更多工作意味着低性能的计算机（例如消费级设备）可能会退出以太坊网络，如果算力集中在高性能节点运营者手中，挖矿就变得非常中心化。 所以，我们需要找到让区块链能够在不提高单个节点工作量的情况下，负担更多有用工作的方法。 从概念上来说，有两种方法可以解决这个问题： Ⅰ. 如果每个节点不必并行处理每一项操作会怎么样？ 第一种方法和我们预设的前提不同，如果我们构建一个区块链，其中每个节点不需要都去处理每个操作会怎么样？如果网络被分成两部分，它们还可以半独立的进行操作，又会怎么样？ A部分可以处理一批交易，同时B部分可以处理另一批交易。这样就可以有效地使区块链的交易吞吐量翻倍，因为我们的限制现在能够被两个部分同时处理。如果我们将区块链分为很多不同的部分，那么我们就可以把区块链的吞吐量提高很多倍。 这就是“分片”技术背后的见解，“分片”是由Vitalik的以太坊研究团队和其他社群提出的扩容解决方案。区块链被分成很多部分，它们被称为“分片”，每个分片都可以独立地处理交易。分片通常被称为是“layer 1”扩容解决方案，因为这是在以太坊底层协议上实现的。如果您想了解有关分片的更多内容，我建议您阅读extensive FAQ和这篇博文。 II. 如果在以太坊现有处理交易能力之外去进行更多有效操作会怎么样？ 第二种选择是从反方向进行考虑的：并不是提高以太坊区块链本身的能力，如果我们可以利用已有的能力做更多的事情，会怎么样呢？底层以太坊区块链的吞吐量是相同的，但是实际上我们可以做更多对于人们和应用程序有用的操作，例如交易，游戏中的状态更新，或是简单的计算。 这就是类似状态通道，Plasma和Truebit等“链下”技术背后的见解。当然，这些技术都在解决不同的问题，但它们都是通过“链下”操作，而不是在以太坊区块链上进行操作，同时仍然保证了足够的安全性和不可更改性。 这些也被称为“layer 2”解决方案，因为它们是构建在太坊主链“之上”的。他们不需要更改底层协议，他们只是以基于以太坊的智能合约的形式存在，与链下的软件进行交互。 2.layer 2扩容解决方案是加密经济解决方案 在深入了解具体的layer 2扩容解决方案前，了解使得他们可行的底层概念是非常重要的。 支撑公有链最基础的动力源泉就是加密经济共识。通过仔细协调激励机制以及通过软件和加密算法对激励进行保障，我们就可以创建对于系统内部状态达成共识的可靠计算机网络。这就是中本聪白皮书中的关键见解，并且这种见解现在也被应用在许多不同公链的设计中，包括比特币和以太坊。 加密经济共识给予我们一个确定性的核心——除非有极端事件例如51%×××发生，否则我们都知道链上操作——例如支付或者智能合约，会像写定的那样执行。 在layer 2解决方案背后的见解，就是我们可以把核心内核的确定性作为锚定——我们附加其他经济机制的一个固定点。 第二层的经济机制可以向外扩展公链的效用，让我们能够进行链下交互，如果有需要的话，仍然可以可靠地转回到核心内核上。 这些构建在以太坊底层“之上”区块链层，并不总是与链上操作具有相同的保障。但是它们仍然有足够的不可更改性和安全性，所以仍然是非常有用的。尤其是当不可更改性的要求略微下降时，我们能以更快的速度或更低的开销来进行操作。 加密经济并不是随着中本聪的白皮书而开始和结束，它只是一种我们正在学着应用的技术。加密经济不仅体现在对于核心协议的设计，还体现在对于第二层系统的设计，其扩展了底层区块链的功能性。 I. 状态通道（State channels） 状态通道（State Channel）是一种用于执行交易和其他状态更新的“链下（off-chain）”技术。但是，一个状态通道“内”发生的事务仍保持了很高的安全性和不可更改性。如果出现任何问题，我们仍然可以选择回溯到链上交易中确定的“稳定内核”。 大部分读者会对支付通道（payment channel）比较熟悉，这一概念已存在多年了，并且最近通过闪电网络（lightning network）部署在了比特币上。状态通道是支付通道泛化出来的形式，它们不仅可用于支付，还可用于在区块链上进行任意的“状态更新”，就像在智能合约内部进行更改一样。 2015 年，Jeff Coleman 第一次详细介绍了状态通道。 解释状态通道的运作方式的最佳方法就是来看一个样例。请记住这是一个概念性的解释，也就是说我们不会涉及具体实现的技术细节。 现在设想Alice和Bob想玩一场井字游戏，胜者可以获得一个eth。为了实现这一目标，最简单的方法就是在以太坊上创建一个智能合约，它可以实现井字游戏规则并跟踪每个玩家的动作。每次玩家想要移动时，他们都会向合约发送一个交易。当一名玩家获胜时，根据规则描述，合约会付给胜者一个eth。 这样做是可行的，但是效率低下并且速度很慢。Alice和Bob正在让整个以太坊网络处理他们的游戏过程，这对于他们的需求来说有点过于夸张。玩家每想要移动一步都需要支付gas费用，并且还要在进行下一步移动之前等待区块打包。 但是，我们可以设计一个新的系统，它能使Alice和Bob在玩井字游戏时产生尽可能少的链上操作。 Alice和Bob能够以链下的方式更新游戏状态，同时又很确定计算结果在需要时仍能将其恢复到以太坊主链上验证。我们把这个系统称之为“状态通道”。 首先，我们在以太坊主链上创建一个能够理解井字游戏规则的智能合约“Judge”，同时它也能够确认Alice和Bob是我们游戏中的两位玩家。该合约持有一个eth的奖励。 然后，Alice和Bob开始玩游戏。Alice创建并签署一个交易，它描述了她游戏的第一步，然后将其发送给Bob，Bob也对交易签了名，再将签名后的版本发回并为自己保留一份副本。然后Bob也创建并签署一个描述他游戏中第一步的交易，并发送给Alice，她也会对交易签名，再将其发回，并保留一份副本。每一次，他们都会这样互相更新游戏的当前状态。每一笔交易都包含一个“随机数”，这样就使我们可以直接知道游戏中移动的顺序。 到目前为止，还没有发生任何链上的操作。Alice和Bob只是通过互联网向彼此发送交易，还没有任何东西传达到区块链上。但是，所有交易都可以发送给 Judge 合约，换句话说，它们是有效的以太坊交易。你可以把这看作两人彼此来回填写了一系列经过区块链认证的支票。实际上，并没有钱从银行中存入或取出，但是每人都有一堆可以随时存入的支票。 当Alice和Bob结束游戏时（可能是因为Alice赢了），他们可以通过向 Judge 合约提交最终状态（比如，交易列表）来关闭该通道，这样就只需要付一次交易费用。Judge合约会确定双方都对这个“最终状态”签名，并等待一段时间来确保没人会对结果提出合理质疑，然后向Alice支付一个eth的奖励。 为什么我们需要设置让 Judge 合约等待一下的”质疑时间“？ 想象Bob并没有给 Judge 合约发送真实的最终状态，而是发送一份之前他赢了Alice的状态。但是 Judge 仅仅是一份合约，它本身无法知晓这是否是最新的状态。 而质疑时间给了Alice一个机会向 Judge 合约证明Bob对游戏最终状态撒了谎。如果有更近期的状态，她就会有一份已签名交易的副本，并且可以将其提供给 Judge合约。Judge 合约可以通过检查随机数来判断Alice的版本是否是最新的，然后驳回Bob窃取胜利的企图。 特性和限制 状态通道在许多应用中都很有用，它们对于在链上执行操作进行了严密的改进。但重要的是要注意，在决定应用程序是否适合被通道化时，需要做出一些特定的权衡： 状态通道依赖于有效性 如果Alice在质疑时间内掉线了（可能是Bob渴望赢得奖品，破坏了她家的网络连接），她可能无法在质疑时间结束前做出回应。但是，Alice可以付费给其他人，让其保存一份她的状态副本，并作为她的权益代表，以保持系统的有效性。 当参与者将在长时间内交换大量状态更新时，状态通道非常有用 这是因为部署 Judge 合约时创建一个通道会产生初始成本。但是一旦部署完成，该通道内每一个状态更新的成本都会非常低。 状态通道最适于有一组确定参与者的应用程序 这是因为 Judge 合约必须始终知晓所有参与到给定通道的实体（比如，地址）。当然我们可以增加或删除用户，但是每次都需要更改合约。 状态通道有很强的隐私性 因为一切都参与者之间的通道“内”发生，而不是公开广播并记录在链上。只有开头和结尾的交易必须公开。 状态通道具有即时终结性 这意味着只要双方都签署了一个状态更新，这个状态就可以被认为是最终状态。双方都有明确保证，如果有必要，他们可以将状态“强制执行”到链上。 我们 L4 团队正致力于创建 Counterfactual框架：一个能在以太坊上推广普及使用状态通道的框架。我们的总体目标是使开发者可以在他们的应用程序中以模块化的方式使用状态通道，而不需要成为状态通道的专家。你可以在这里了解更多该项目的信息。我们将在 2018 年的第一季度发布技术细节文件。 另一个值得注意的针对以太坊的状态通道项目是 Raiden，该项目目前正致力于构建一个支付通道网络，使用了和闪电网络类似的范式。这意味着你不必与想要交易的特定人员开通状态通道。你可以与一个连接到更大型通道网络的实体架设一个单独的通道，这样你就能够向连接到同一网络的任何人支付而无需额外费用。 除了 Counterfactual 和 Raiden，在以太坊上还有几个用于特定于应用程序的状态通道。例如，Funfair 就为他们的去中心化×××构建了他们称之为“Fate channels”的状态通道，SpankChain 为成人产业演员构建了一套单向支付通道（他们还为其 ICO 使用了状态通道），还有 Horizon Games 也在他们的第一款基于以太坊的游戏中使用了状态通道。 II. Plasma 2017 年 8 月 11 日，Vitalik Buterin 和 Joseph Poon 发表了一篇题为《Plasma：自主智能合约》（ Plasma: Autonomous Smart Contracts）的论文。这份论文介绍了一种新技术，它能使以太坊每秒可以处理的交易远比现在更多。 就像状态通道一样，Plasma 是一种管理链下交易的技术，同时依靠底层的以太坊区块链来实现其安全性。但是 Plasma 采用了一种新思路，它是通过创建依附于以太坊“主”区块链的“子”区块链。这些子链又可以相应地产生它们自己的子链，子链的子链又可以产生子链，如此递进下去。 其结果就是，我们可以在子链级别上执行许多复杂的操作，在与以太坊主链保持最低限度交互的情况下，运行拥有数千名用户的整个应用程序。Plasma 子链可以更快地操作，承担的交易费用更低，因为子链上的操作无需在整个以太坊区块链上进行重复。 plasma.io/plasma.pdf 为了弄清楚 Plasma 的运行原理，我们来看一个如何使用它的样例。 让我们试想你正在创建一个基于以太坊的集换式卡牌游戏。这些卡牌是一些基于 ERC 721 不可替代的token（比如 Cryptokitties），但是拥有一些特定的特征和属性，可以让玩家相互对战——就像炉石传说或者万智牌一样。这种复杂操作在链上执行的成本很高，所以你决定在你的应用程序中使用 Plasma 作为替代方案。 首先，我们在以太坊主链上创建一系列的智能合约，它们可作为 Plasma 子链的“根节点”。Plasma 根节点包含了子链的基本“状态交易规则”（诸如“交易无法消费已消费过的资产”），也记录了子链状态的哈希值，并建立一种允许用户在以太坊主链和子链间转移资产的“桥接”服务。 然后，创建我们的子链。子链可以拥有自己的共识算法，在这个例子中，我们假设它使用了 PoA(Proof of Authority)，POA是一种依赖于可信区块生产者（比如，验证者）的简单共识机制。在“工作量证明”系统中，区块生产者与 POW 系统中的矿工类似，它们是接收交易，形成区块并收取交易费用的节点。为了让样例简单点，假设你（也就是创建游戏的公司）是创建区块的唯一实体，即你的公司运行着几个节点，这些节点就是子链的区块生产者。 一旦子链创建并激活，区块生产者会定期的向根节点合约进行提交。这意味着他们实际上在说“我提交的 X 是子链中当前最新的区块”。这些提交被当做子链中事务的证明，链上记录在 Plasma 根节点里。 现在子链已经准备好了，我们可以创建集换式卡牌游戏的基本组件。这些卡片是基于 ERC721，在以太坊主链上初始化，然后由 Plasma 根节点转移到子链上。这里引入了一个关键点：Plasma 可以扩展我们与基于区块链的数字资产的交互，但是这些资产应当首先创建在以太坊主链上。然后，我们将实际的游戏应用程序以智能合约的方式部署到子链上，这样子链就包含了游戏所有的逻辑和规则。 当用户想要玩我们的游戏时，他们只需要和子链交互。他们可以持有资产（ERC721 卡牌），可以为了以太币购买并交换它们，可以与其他用户对战，还有其他任何游戏中允许的行为，而这些行为都不需要与主链直接交互。因为只有很少的节点（比如，区块生产者）才需要处理交易，所以交易费会很低，操作也能更快。 但是这种模式安全吗？ 通过把更多操作从主链迁移到子链上，很明显我们可以执行更多的操作了。但是这样安全吗？发生在子链上的交易是否具备权威性？毕竟，我们方才描述的系统只有一个中心实体控制着子链的区块生产。这样不是中心化吗？这样公司不是随时都能窃取你的资产或者拿走你收集的卡牌吗？ 简而言之，即使是在子链中单个实体完全控制所有区块生产的情况下，Plasma 也为你提供了一个基本保证，即你始终都可以将你的资金和资产退回到主链上。如果一个区块生产者开始恶意行事，最坏的情况也仅仅是强迫你离开这个子链。 让我们了解一下区块生产者能恶意行为的几种方式，同时了解 Plasma 会如何处理这些情况。 首先，想象一个区块生产者试图通过说谎欺骗你，他们可以通过创建一个伪造的新区块，声称你的资金被他们控制了。由于他们是唯一的区块生产者，所以他们可以自由引入一个并不遵循我们区块链规则的新区块。就像其他区块一样，他们也得将这个区块存在的证据提交给 Plasma 根节点合约。 如上所述，用户有能将他们的资产随时退回到主链上的最终保障。在这个情景下，用户（或者更确切来说是代表他们权益的应用程序）会侦测到这种盗窃的企图，并在区块生产者尝试和使用他们“偷到”的资产之前把自己的资产撤回到主链上。 Plasma 还创建了一种机制，防止欺诈时不能退回到主链上。Plasma 包含了一种机制，任何人（包括你）都可以向根节点合约发布欺诈证明（fraud proof），试图证明区块生产者作弊。这个欺诈证明会包含之前区块的信息，并且允许我们证明，根据子链中的交易状态规则，这个错误的区块并不能正确接上之前的状态。如果欺诈被证实，那么子链就会“回滚”到前一个区块。更妙的是，我们还构建了一种体系：任何签出错误区块的区块生产者会被处罚，他们会因此丢失链上的保证金。 plasma.io/plasma.pdf 但是提交欺诈证明需要访问底层数据，即需要用之前的实际区块历史来证明欺诈。如果区块生产者为了防止Alice向根节点合约提交欺诈证明，而并没有共享之前区块的信息的话，那怎么办？ 在这种情况下，Alice的解决方案就是收回资产并脱离子链。本质上说，爱丽丝向根节点合约提交了一份“欺诈证明”。在一段延迟期内，任何人都可以质疑该证明（比如，展示后面的合法区块证明实际上她消费了这些资产）。之后，Alice的资产将会被移回到以太坊主链上。 plasma.io/plasma.pdf 最后，区块生产者可以审查子链中的用户。如果区块生成者愿意，他们可以直接不在其区块中包含特定交易，从而有效阻止用户在子链上执行的任何操作。如上所述，解决方案仅仅是把我们所有的资产退回到以太坊主链上就可以了。 但是，资产退回本身也会带来风险。其中一个问题就是如果所有使用这一子链的用户同时都要退回资产会怎么样。在这种大量提现的情况下，以太坊主链可能没有足够的容量来处理每个人在质疑期内的交易，也就意味着用户可能会丢失资金。尽管有许多可能的技术能够防止这种情况发生，例如，通过延长质疑时间的方式来响应资产退回的需求。 值得注意的是，并不是所有的块生产者都必定被一个实体所控制——这只是我们案例中的极端个例。我们可以创建子链，把区块生产者分布在许多不同实体间，即像公有链一样真正地去中心化。在这种情况下，区块生产者如上述方式进行干预的风险更小，而用户不得不将资产转移回以太坊主链的风险也更小。 现在我们已经介绍了状态通道和 Plasma，以下几点对比值得注意。 它们之间一个不同之处在于，当状态通道中所有参与方都一致同意退回资产时，状态通道可以立即执行退回。如果Alice和Bob同意关闭通道并撤回他们的资金。只要他们都认同最终状态，他们就可以立即从状态通道取得他们的资产。这在 Plasma 上是不可能的，如上所述，用户在取出资产的过程中必须经历一个质疑时间。 与 Plasma 相比，状态通道每笔交易的平均交易费更便宜，而且速度更快。这意味着我们应该可以在 Plasma 子链上构建状态通道。例如，一个应用程序中两个用户在进行一系列的小型交易。在子链级别构建状态通道应该会比直接在子链上执行每个交易更加便宜和迅速。 最后，需要注意的是这些只是部分描述，我们还遗漏了许多细节。Plasma 本身还处于非常早期的阶段。如果你有兴趣了解 更多关于 Plasma 的现状，可以查看 Vitalik 最近的一个关于 “最小化可行性Plasma（Minimal Viable plasma）” 的提议（即精简的 plasma 实施方案）。一个台湾的团队正在进行这项工作，可以在这个代码库中查看。OmiseGo 正在研究他们的去中心化交易的实施，他们在这里发布了进度最近更新信息。 III. Truebit Truebit 是一种帮助以太坊在链下进行繁重或复杂计算的技术。这使得它与状态通道和Plasma不同，它们对于提高以太坊区块链的总交易吞吐量更有用。正如我们在开篇部分所讨论的那样，扩容是一个多方面的挑战，需要的不仅仅是更高的交易吞吐量。Truebit不会让我们完成更多的交易，但它能让基于以太坊的应用程序去处理更复杂的事务，并且仍能被主链验证。 这就让我们能够对以太坊应用程序做一些有用的操作，这些操作的计算成本太高，无法在链上执行。例如，验证来自其他区块链的简单支付验证（SPV）证明，这个证明可以让以太坊智能合约“检查”交易是否在另一个链上已经发生（如比特币或狗狗币）。 让我们看一个例子。试想你有一些代价很高的计算（比如 SPV 证明）需要作为以太坊应用程序的一部分来执行。你不能单纯的把它当做以太坊主链上智能合约的一部分，因为SPV证明的计算成本是非常昂贵的。请记住，因为每个节点都要并行处理这种操作，所以在以太坊上直接进行任何计算都是非常昂贵的，。以太坊的区块有最大费用（gas值）限制，从而为该区块中所有交易能执行的计算总量设置了上限。但是SPV证明的计算成本实在太大，即使它是区块中唯一的交易，它需要的gas值也是单个区块gas值上限的许多倍。 相反，链下你可以只需要向人支付很少的费用来完成计算。去完成计算并由你付费的这个人被称作解算者（solver）。 首先，解算者支付智能合约中的保证金。然后，你给解算者一份他们需要计算内容的描述，它们运行计算，并返回结果。如果结果是正确的（大多在一秒钟内），他们的保证金将被退回。如果事实证明，解算者并没有正确地执行计算——比如他们欺诈或犯了错误——他们就会失去他们的保证金。 但是我们如何判断结果是正确的还是错误的？Truebit使用一种叫做“验证游戏”（verification game）的经济机制。从本质上讲，我们为其他被称为挑战者的参与方创造了激励，来检查解算者的工作。如果挑战者能够通过验证游戏证明解算者提交了错误结果，那么他们会获得奖励，而解算者则会失去保证金。 因为验证游戏是在链上执行的，所以它不能直接地计算结果（这会破坏整个系统的设计初衷——如果我们可以在链上进行计算，我们就不需要Truebit）。相反，我们强迫解算者和挑战者确定他们意见不一致的具体操作。实际上，我们将双方逼入一个死角——找到导致他们对结果意见不一的具体代码行。 一旦确定了具体的操作，实际上它就足够小到可以由以太坊主链执行了。然后，我们通过以太坊的智能合约执行该操作，该合约一劳永逸地解决了哪一方说了真话，哪些又是谎言或错误。 如果您想了解更多有关Truebit的信息，你可以阅读这篇论文，或者阅读Simon de la Rouviere的博客文章。 结论 layer 2解决方案都有一个共同见解：一旦我们有了公链提供的有确定性的核心，我们就可以把它作为加密经济系统的锚定，然后扩展区块链应用的可用性。 现在我们已经研究了一些示例，我们可以更具体地了解layer 2解决方案如何应用这种见解。layer 2解决方案所使用的经济机制往往是互动游戏：它们通过为各参与方创造激励来相互竞争或彼此“检查”工作。区块链应用程序可以假设某个给定的声明可能是真的，因为我们已经为另一方创造了强烈的激励来提供证明其错误的信息。 在状态通道方案中，就是通过给各方机会互相“反驳”，来确定通道的最终状态。在Plasma方案中，就是如何管理欺诈证据和提现的方法。在Truebit方案中，我们通过激励挑战者来证明解算者是错误的，以确保解算者给出真实结果。 这些系统将有助于解决将以太坊扩展到庞大的全球用户群所涉及的一些挑战。有些系统，像状态通道和Plasma，将会增加平台的交易吞吐量。而其他的系统，像Truebit，可以将更困难的计算作为智能合约的一部分，从而开创新的使用案例。 这三个示例仅代表了加密经济扩容解决方案设计可能性的一小部分。我们甚至没有涉及像Cosmos或Polkadot这样的“跨链协议”所做的工作（尽管这些协议到底是“layer 2”解决方案还是其他东西，这已经完全是另一篇文章的主题）。我们还应该期望发明新的、意想不到的layer 2系统，这些系统可以改进现有模型，或者在速度，不可更改性和开销成本之间提供新的权衡。 比任何特定的layer 2解决方案更重要的是，底层技术的进一步发展以及使其首先成为可能的机制：加密经济的设计。 这些layer 2扩容方案有力证明了像以太坊这样的可编程区块链的长期价值。建立基于layer 2解决方案的经济机制，只有在可编程区块链上才有可能：因为你需要用脚本语言编写执行交互式游戏的程序。由于像比特币这样的区块链只提供了有限的脚本功能，这对于它们来说很困难（或者有些情况下，比如 Plasma，这是完全不可能实现的）。 以太坊允许我们创建layer 2解决方案，以便在速度，不可更改性和成本开销之间找到新的权衡点。这可以让底层区块链更能够适用于更多种类的应用程序，因为面对不同威胁模型的不同类型应用程序会对不同的权衡模式有天生的偏向。对于需要保障乃至国家性范围内的高价值交易时，我们可以使用主链。对于更偏重交易速度的数字资产交易，我们可以使用 Plasma。layer 2方案让我们能够在不影响底层区块链的前提下取得权衡，并保持去中心化和不可更改性。 而且，很难事先预测给定的扩展方案需要哪些脚本功能。当设计以太坊的时候，Plasma和 Truebit还尚未发明。但是因为以太坊是完全可编程的，实际上它能够实现我们能发明的任何经济机制。 区块链技术的价值是建立在加密经济共识的确定性内核，而诸如以太坊这样的可编程区块链才是能够充分利用这种价值的唯一途径。 感谢Vitalik Buterin，Jon Choi，Matt Condon，Chris Dixon，Hudson Jameson，Denis Nazarov和Jesse Walden对本文早期草稿的评论。 转载自：https://www.cnblogs.com/chongdongshequ/p/9700759.html
github: https://github.com/hukkinj1/cosmospy cosmospy Version 5.0.1 Tools for Cosmos wallet management and offline transaction signing Installing Installing from PyPI repository (https://pypi.org/project/cosmospy): pip install cosmospy Usage Generating a wallet from cosmospy import generate_wallet wallet = generate_wallet() The value assigned to wallet will be a dictionary just like: { "seed": "arch skill acquire abuse frown reject front second album pizza hill slogan guess random wonder benefit industry custom green ill moral daring glow elevator", "derivation_path": "m/44'/118'/0'/0/0", "private_key": b"\xbb\xec^\xf6\xdcg\xe6\xb5\x89\xed\x8cG\x05\x03\xdf0:\xc9\x8b \x85\x8a\x14\x12\xd7\xa6a\x01\xcd\xf8\x88\x93", "public_key": b"\x03h\x1d\xae\xa7\x9eO\x8e\xc5\xff\xa3sAw\xe6\xdd\xc9\xb8b\x06\x0eo\xc5a%z\xe3\xff\x1e\xd2\x8e5\xe7", "address": "cosmos1uuhna3psjqfxnw4msrfzsr0g08yuyfxeht0qfh", } Converter functions Mnemonic seed to private key from cosmospy import seed_to_privkey seed = "teach there dream chase fatigue abandon lava super senior artefact close upgrade" privkey = seed_to_privkey(seed, path="m/44'/118'/0'/0/0") Private key to public key from cosmospy import privkey_to_pubkey privkey = bytes.fromhex("6dcd05d7ac71e09d3cf7da666709ebd59362486ff9e99db0e8bc663570515afa") pubkey = privkey_to_pubkey(privkey) Public key to address from cosmospy import pubkey_to_address pubkey = bytes.fromhex("03e8005aad74da5a053602f86e3151d4f3214937863a11299c960c28d3609c4775") addr = pubkey_to_address(pubkey) Private key to address from cosmospy import privkey_to_address privkey = bytes.fromhex("6dcd05d7ac71e09d3cf7da666709ebd59362486ff9e99db0e8bc663570515afa") addr = privkey_to_address(privkey) Signing transactions from cosmospy import Transaction tx = Transaction( privkey=bytes.fromhex("26d167d549a4b2b66f766b0d3f2bdbe1cd92708818c338ff453abde316a2bd59"), account_num=11335, sequence=0, fee=1000, gas=70000, memo="", chain_id="cosmoshub-3", sync_mode="sync", ) tx.add_transfer(recipient="cosmos103l758ps7403sd9c0y8j6hrfw4xyl70j4mmwkf", amount=387000) tx.add_transfer(recipient="cosmos1lzumfk6xvwf9k9rk72mqtztv867xyem393um48", amount=123) pushable_tx = tx.get_pushable() One or more token transfers can be added to a transaction by calling the add_transfer method. When the transaction is fully prepared, calling get_pushable will return a signed transaction in the form of a JSON string. This can be used as request body when calling the POST /txs endpoint of the Cosmos REST API.
科普 | Cosmos 区块链的工作原理，Part-1：比较 Cosmos 与比特币、以太坊
编者注：本文对 Cosmos 网络中区块链和比特币、以太坊进行了巨细靡遗的比较。作者先从区块链系统的栈层出发，分析了比特币、以太坊在不同栈层上的技术要点，最后回归到 Cosmos 网络中的区块链，概念解释尤为清晰，是不可多得的解释文。 鉴于文章实在太长，我们在文首附上了目录。 目录 Cosmos 是什么？ 区块链结构简介 比特币栈层结构 以太坊栈层结构 基于比特币与以太坊构建应用程序 Cosmos 区块链结构 Cosmos 共识层 Cosmos 网络层 Cosmos 应用层 结论 密码学货币产业从未停下脚步。 一切都始于2010年比特币的问世。比特币刚问世时，所有人都认为它是数字货币的圣杯。曾经被认为不可能的事情现在变成了现实：第一个点对点（peer-to-peer，P2P）支付网络出现了。 即便在今天，对事物的信任仍然是最难以琢磨并且最珍贵的资产。比特币通过创建第一个“免信任型”系统，绕过了这一问题。但这仅仅是一个开始。 从那之后，比特币就成为了催生更广泛密码学创新的催化剂，这些创新也导致了一系列新型去中心化系统与金融基础设施的出现：以太坊（Ethereum）、闪电网络（Lighting Network）、EOS、Tezos、Maker…… 这个名单还在不断延长。 但是有一个项目与众不同：Cosmos。 在区块链领域，Cosmos 是一个“新生儿”。虽然它的理念已经出现有一段时间了，但其开发团队一直在背后慢慢地开发以确保 Cosmos 设计及实现的正确性。这也使得 Cosmos 最近才公开推出。 因此，有很多人看过 Cosmos 项目之后却不理解它也就不足为奇了。简单浏览 Cosmos 相关资料并不会让他们能够直观地了解 Cosmos，反而会让他们有更多疑问： 什么是 Cosmos？ Cosmos 的工作原理是什么？ 与比特币、以太坊相比 Cosmos 有什么不同？ Cosmos 的特点是什么？ 我已经知道 Cosmos 团队快两年了。老实说，当我第一次听说他们在做什么的时候，我和其他人一样对它的概念一无所知。 但当我更深入地了解 Cosmos 之后，我开始非常欣赏它。我这么说不仅是为了引人注目，是真正地发自内心。 我对 Cosmos 非常着迷，所以我们决定将 TruStory 应用构建为一个 Cosmos 区块链应用。（插播：我将在之后的文章中更详细地阐述我们为什么会做出这个决定） 尽管如此，关于 Cosmos 仍然有很多困惑。所以我决定专门为此写一篇文章。我想让读者对 Cosmos 是什么以及它在区块链世界中的定位有一个更深层次的理解。 你准备好开始了么？理清思绪，带上你的思考帽，系好安全带。我们要开车啦！ Cosmos 是什么？ Cosmos 是这样定义自己的： “一个由多条独立平行区块链组成的去中心化网络，每条平行区块链均采用 BFT 共识算法（例如：Tendermint 共识）。” 哇，好拗口啊！让我们把这个定义拆分成几个容易理解的部分。 独立平行区块链的去中心化网络 我在这里假设读者已经对区块链非常了解了！不过，我还是快速回顾一下： 简单来说，区块链是一个分布在许多计算机上的数据库，每台计算机上的数据库都保持相同的状态。换句话说，每台计算机上的数据库所包含的数据都完全相同。这些计算机共同组成了所谓的“区块链网络”。 比特币和以太坊都是区块链，而 Cosmos 是由许多这样并行运行的区块链组成的区块链网络。 如果你不能完全理解刚才说的，那么在进一步了解 Cosmos 工作原理之前，你最好再多读一些关于区块链的基础知识。（编者注：中译本见文末超链接《区块链是什么鬼》） “每条区块链都采用 BFT 共识算法” BFT 是 “Byzantine Fault-Tolerant（拜占庭容错）”的缩写。一条拜占庭容错的区块链能够在网络中部分节点宕机 以及/或者 作恶（即所谓“拜占庭式节点”）的情况下，保证网络依旧具备“安全性”与“活性”等性质。安全性与活性能够确保区块链网络中每个节点维护相同的状态。 插播：如果你想要更深入地了解什么是安全性（Safety）与活性（Liveness），请阅读我的这篇有关分布式共识的文章。（编者注：中译本见文末超链接《分布式共识的工作原理，Part-2》） 因此，一种 “BFT 共识算法” 乃是定义了计算机间通信与协调、使得区块链具有拜占庭容错能力的算法。Cosmos 网络中的所有区块链都采用某种 BFT 共识算法。 比特币和以太坊的共识算法不是典型的 BFT 算法。所以它们不符合 Cosmos 网络中区块链的定义。（值得注意的是，虽然它们不是拜占庭容错的，但仍然可以让比特币和以太坊等区块链加入 Cosmos 网络，仅仅需要一些额外的步骤。如果你觉得费解，不用担心——我们将稍后对此进行更深入的研究。） 插播：如果你还是不清楚什么是 BFT，我在这篇文章中写得蛮清楚了。（编者注：中译本见文末超链接《分布式共识的工作原理，Part-3》） “Tendermint 共识算法” Tendermint 是由 Cosmos 开发者提出并构建的一种 BFT 共识算法。Cosmos 网络中的区块链可以使用 Tendermint 共识或任何其他 BFT 共识算法。稍后我们将在本文了解更多关于 Tendermint 的内容。 简单来说，Cosmos 网络是一个由多条并行运行的独立拜占庭容错区块链组成的生态系统。这些区块链是 独立运行的，并且能够与其他区块链进行 互操作。 现在你可能会想，“为什么区块链之间要进行互操作呢？” 好问题！我们很快就会讲到。但首先我们要回顾一下区块链的结构。 区块链结构简介 在深入研究 Cosmos 生态系统中区块链是如何工作和互操作的之前，让我们先回顾一下区块链结构的基础知识。 正如我们前面所讨论的，区块链是一个多机复制数据库，并且在每台计算机上维护相同的数据。这种类型的分布式系统也被称为“复制状态机”。 复制状态机是一种多机复制的确定性状态机，但因为网络中每台计算机都维护着相同的状态，因此在功能上看起来就像一台单机。 听起来很熟悉，对吧？回顾上文区块链的定义，这里的定义仅仅是将“数据库”替换为“状态机”、“数据”替换为“状态”，相信你能明白我的意思。 “确定性” 可以简单地理解为，给定一个确定的输入，状态机将始终产生相同的输出。在区块链系统中，“确定性”意味着如果你从一个给定状态开始执行相同的事务序列，你总是会得到相同的最终状态。 复制状态机从某个状态启动。每笔有效事务都将导致系统状态转变到下一个状态（这与数据库中条目更新相同：如果你更新某个条目，数据库将迁移到包含该更新后数据条目的新状态）。 复制状态机在概念上有三个栈层： 1）应用层 应用层负责定义状态变迁，并在事务发生后更新状态机状态。 2）网络层 网络层负责将在某一个状态机上执行的事务传播到网络中其他所有状态机上。 3）共识层 共识层由算法组成，负责确保在事务执行后每一台状态机都存储相同的状态（即，某一状态机无法伪造不存在的事务）。 3a）抗女巫攻击层 试图在去中心化公网运行的复制状态机还需要第四层（“抗女巫攻击层”），确保任何一台状态机都不能破坏网络。如果没有这一层，状态机可以通过创建许多假身份来篡改状态，从而获得与其投入不成比例的影响或收益（即，发起女巫攻击）。 总之，应用层负责定义状态与管理状态迁移。网络与共识层负责保持每台机器上状态一致（即，确保网络中每个数据库数据一致）。抗女巫攻击层（显然）负责避免女巫攻击。 现在，让我们看看在比特币区块链和以太坊区块链中是如何定义与实现这些栈层的。 比特币栈层结构 1）应用层 比特币的主要应用是 P2P 交易。比特币使用 Script（一种堆栈式非图灵完备的语言）来定义与执行交易。当发送方通过交易发送比特币时，发送方将使用脚本来编码指定谁才能掌控这笔资金。Script 包含一组操作码或者说命令，发送方可以使用这些操作码来指定要花费一笔比特币所需满足的条件。 2）网络层 当发送方向接收方发送比特币时，该转账交易必须被广播到网络中，才能使矿工将其打包进区块中。比特币使用一种“Gossip 协议”来确保每个节点都会将其接收的所有新区块或交易发送至邻居节点（peer）。Gossip 协议是确保消息在全部节点间传播的 P2P 协议。比特币网络中所有节点都会将其新接收的有效交易立即发送给其邻居节点，从而使得待打包交易能够在几秒钟内通过点对点网络传播到大多数节点。 3）共识层 在交易被转播到网络中后，还需要将其添加到区块链中才能完成转账（即让网络中的计算机都来执行这个事务）。验证交易并将其打包到区块中的过程称为“中本聪共识（Nakamoto Consensus）”。中本聪共识的运行原理可以在其他论坛或文章找到。如果你想深入了解，这篇文章是一个很好的入门文章。 3a）抗女巫攻击层 中本聪共识依赖于“工作量证明（Proof-of-Work）”来防止女巫攻击。基本上，产生一个新区块所需的算力使得比特币共识协议自身能够抵抗女巫攻击。由于矿工需要大量的算力来产生下一个区块，使得他们无法在不增加大量算力（与资金）投入的情况下“伪造”多个身份。 以太坊栈层结构 1）应用层 与比特币不同，以太坊的设计初衷是构建一个能够运行去中心化应用的平台。以太坊包含一种高级语言（即，Solidity），使得开发者能够通过编写智能合约定义去中心化应用的具体功能。EVM（以太坊虚拟机，Ethereum Virtual Machine）是以太坊应用层的核心。EVM 使用 EVM 编译器将智能合约代码编译成字节码，用户可以通过交易的形式，将该字节码上传到区块链之后，EVM 就可以执行这些字节码，从而改变去中心化应用的状态（即，更新以太坊节点存储的该智能合约相关状态）。由于以太坊网络中所有节点均运行 EVM，这也保证所有节点的状态一致。 2）网络层 与比特币相似，以太坊也使用 Gossip 协议，使得节点能够与其邻居节点通信。 3）共识层 为了达成共识，以太坊使用了与中本聪共识相似的“Ethash”，但 Ethash 与中本聪共识有一些关键区别。如果你需要了解以太坊共识算法的工作原理，请阅读我之前的一篇文章。（编者注：中译本见文末超链接《以太坊的工作原理》) 3a）抗女巫攻击层 与比特币一样，Ethash 依赖于工作量证明（目前为止，译者注：未来以太坊 2.0 将切换到 PoS 共识机制）来抵御女巫攻击。 基于比特币与以太坊构建应用程序 我希望以上内容让你对区块链结构有了一定了解。当我们讨论 “比特币” 或 “以太坊”时，这些名字指的是相关的所有栈层。因为比特币和以太坊是由这些栈层组成的整体。 你无法将以太坊智能合约与其底层 Ethhash 共识层分开，也因此单独讨论这两个主题都没有意义。比特币也是如此，不使用中本聪共识与工作量证明你就无法进行比特币交易。 另一方面，Cosmos 采用了一种稍微不同的模式：它将应用层与共识层和网络层分开。 因为 Cosmos 的目标是建立一个区块链网络，所以这样设计是有意义的。在这个区块链网络中，每条区块链是独立的，并且有它自己的需要和要求（即，它自己的应用）。在这种情况下，想要提出一种一刀切的、适合所有区块链的应用层，是行不通的。让我们用几个例子来研究一下原因。 比特币局限性的一个例子 假设我们准备构建一个货币应用程序。在这种情况下，像 Bitcoin Scrypt 这种简单的基于堆栈的脚本语言是最佳选择。比特币脚本语言不仅可以很好地实现从一个地址到另一个地址的价值转移，并且非常简单、不是图灵完备的。 因此，它不太容易受到各种类型安全漏洞的影响，而这些安全漏洞可能会严重影响图灵完备的编程语言。这正是我们在处理货币与价值存储时想要的。但是这种简单也有其局限性。 使用 Scrypt 做任何更复杂的事情（例如：去中心化预测市场）都非常困难。比特币脚本语言不仅受其可执行代码复杂性限制，对于开发者来说也十分不友好。更糟糕的是，比特币区块链交易的处理速度很慢（大约每秒 7 笔交易）。因此，直接在比特币区块链上构建需要高交易吞吐量的应用是不现实的。 以太坊局限性的一个例子 与比特币相反，以太坊的 EVM 与智能合约语言（Solidity）是为了支持更灵活的应用程序而设计的。Solidity 是一种图灵完备的编程语言，因此理论上它可以执行任意算法复杂度的代码。 在实际应用中，由于 Solidity 易出错并易受到安全攻击，所以使用 Solidity 开发任意复杂度的程序是相当困难的。这种特性与处理价值转移的应用程序背道而驰，在后者这个场景种，安全性是最重要的。 此外，智能合约也非常难以升级，从而使得迭代开发非常困难。合约一旦部署上链，你所能做的就只有祈祷它能够平稳运行！与比特币一样，以太坊交易处理速率也非常低（大约每秒能够处理 15 笔交易），因此在以太坊区块链上构建需要高交易吞吐量的应用也是不现实的。 Cosmos 的提出就是为了满足这种实际业务需要，尽管它为此做了一些较大的牺牲。接下来我们将深入研究具体的细节。但在那之前，我们还必须理解 Cosmos 中区块链的三个栈层是什么样的。 Cosmos 区块链结构 首先，我们将从共识层开始了解 Cosmos，以便更好地理解在 Cosmos 上开发应用程序与使用比特币或以太坊有何不同。 Cosmos 共识层 Cosmos 网络中区块链使用 Tendermint 共识算法。Tendermint 是一个 2014 年诞生的开源项目，“旨在解决比特币工作量证明（Proof-of-Work, PoW）共识算法的速度、可扩展性与环境问题”。 Tendermint 共识算法是一个 “无视应用层（application-agnostic）的共识引擎”。从本质上讲，这意味着任何区块链都可以使用 Tendermint 共识算法，它是拜占庭容错的，并且使用 PoS 算法来抵御女巫攻击。 又是一大堆术语！我们好好说道说道。 Tendermint 共识是如何运作的？ 回顾一下，共识算法的存在是为了保证事务执行后，状态机中保存的状态一致；而 Tendermint 共识算法定义了一种“能让所有节点对下个区块达成共识”的规则。 让我们看看相关因素及规则是如何运作的吧！ 验证者 负责达成状态一致的节点称为“验证者”。任何愿意协助整个网络达成共识的参与节点都能成为验证者；作为回报，验证者会获得交易手续费和区块奖励。Tendermint 整合这些验证者的投票结果，确定下一个区块的正确状态。 通过质押对抗女巫攻击 每个验证者的票都有自己的投票权重，投票权重通常是在创世块产生时确定，或是在开始运行后根据应用层开发者所设计的某些逻辑来决定。一般来说，由验证者锁在系统中的代币量（作为质押品）决定投票权重的大小，这种质押物也被称为“保证金”。 Consensus 共识 按照规则，验证者要按轮次（round）对每一个区块达成共识。每一轮都包含三个基本步骤：提议阶段（Propose）、预投票阶段（Prevote）、预提交阶段（Precommit），以及两个后续步骤：提交阶段（Commit）、新高度阶段（NewHeight）。从抽象角度来看，验证者按照以下协议规则共同决定下一高度要使用什么区块： 首先是提议阶段，由指定的验证者提出一个区块——每一轮中的提议者都是从有序的列表中按照投票权重的比例，确定性地选择出来的。 接着进入预投票阶段——每一位验证者广播他们各自的预投票。 当该轮次中某一区块收到超过 2/3 的预投票，我们就称其为 “polka”。一旦出现 “polka”，就进入下一个阶段。 进入预提交阶段，由每一个验证者广播他们的预提交的投票。 如果某一特定区块收到超过 2/3 的预投票，就进入提交阶段，这个阶段会将区块加入区块链，并增加区块高度。每当有新的区块加入区块链，所在区块链的区块高度就 +1。 如果失败，则要么返回预投票阶段，要么回到预提交阶段。 要注意的是，在任何高度上，都有可能需要一轮以上的投票才能提交一个区块。因为可能出现以下情况： 被指定的“提议者”在应该提出区块时掉线 提议者所提出的区块违反一些预先定义的规则 Tendermint 依靠超时机制确保区块链出块不会遇到延宕。如果在超时前，提议区块没有收到超过 2/3 的预投票，则由新的提议者再次进行提出区块流程。 协议细节详见此处。 总的来说，Tendermint 选择了与比特币的中本聪共识、以太坊 Ethash 不同的路线， 让我们做一些重点对比： 确定性与概率性 与中本聪共识和 Ethash 这类概率性共识不同， Tendermint 是确定共识——这意味着 Tendermint 每个区块都是最终确定的，而不像比特币的区块只是处于“很可能”被确定的状态。 我们回顾一下中本聪共识，区块总是处于“未确定”状态——只有确定某个区块在“最长链”上，才能有把握认为该块正在被最终确定，这也是为什么比特币交易需要等“6个区块确认”。 而在 Tendermint 中，验证者成功投票及提交后，区块就立即被确认了。 固定验证者 vs. 可变验证者 中本聪共识及 Ethash 允许矿工随时选择加入或退出，并不需要其他矿工提前知晓。相反地，Tendermint 共识要求维护一个事先知晓且固定的验证者集合，验证者身份是靠他们的公钥来辨认的。 领导 vs. 无领导 中本聪共识及 Ethash 没有指定领导者来提议下一个区块（i.e. 任何矿工都有可能挖到下一个区块）。另一方面，Tendermint 选择领导者，或称为提议者，负责提出下一个区块。 明确的 vs. 模糊的超时机制 中本聪共识和 Ethash 没有使用超时机制来确保矿工一定能出块，而 Tendermint 有明确的超时机制保证区块链的出块过程不会遭遇延宕。 100 个验证者 vs. 1000 个验证者
Cosmos 和 Polkadot 都是关注区块链互操作性的项目，关于二者之间的差别已经有过很多讨论。如果你还不熟悉这两个项目，Linda Xie 发过一串推特介绍过这两个项目，可以作为很好的入门材料。 虽然已经有很多帖子分析过这两个项目的区别了，但是我认为其中大部分都存在一定的偏向性或者不够详细。通过这篇帖子，我会从架构权衡到哲学等方面更深入地探讨这两个项目。 为什么要构建一条新的区块链？ 为什么一些项目要选择从头开始构建一条专门承载应用程序的区块链，而不是以智能合约的形式在现有的区块链上编写应用程序呢？主要有以下两点原因。 首先，现有的智能合约平台不一定能满足应用程序所需的灵活性和可定制性。举例来说，如果你想搭建的应用程序需要自定义的哈希函数，那么把它编写到以太坊上会消耗很多 gas ，因为这个函数每调用一次都需要在以太坊虚拟机内执行一次。一种解决方案是提议将这个函数作为预编译合约添加至以太坊协议内。但是，除非这个函数也广泛应用于其它应用程序，否则这项提议大概率是不会通过的。从头开始编写一条新的区块链，你就可以自由灵活地设计区块链的核心逻辑，以此满足你的应用程序的需求。 其次是自治问题。在智能合约平台上构建的应用程序必须接受平台的治理并遵守其规则，从区块时间和 gas 定价之类影响用户体验的规则，到回滚之类改变状态的决策等等。 但相应的，具有自治能力的链失去了与其它应用程序进行无缝通信的能力，因为应用程序都是搭建在使用不同状态机的区块链上。Cosmos 和 Polkadot 都致力于解决这个问题——Cosmos 采用的是 Hub-and-Zone（中心-分区） 模型，Polkadot 则采用的是Relay Chain/Parachain（中继链/平行链）模型。 读者需要对这两个项目有一定的了解，本文侧重于梳理二者的不同点。 1.局部安全 vs 全局安全 Cosmos 和 Polkadot 采用的安全模型差别极大。简单来说，Polkadot 的工作流程如下： Polkadot 的网络架构 平行链是 Polkadot 网络中的区块链。这些链有自己的状态机、自己的规则和自己的区块生产者，即核验人（collators）。每条平行链本质上都是一个独立的状态机，而且可以使用任何类型的特殊功能、共识算法、交易手续费结构等等。在 Polkadot 网络中，所有平行链都有同一条母链，叫做中继链，里面包含了由所有平行链组成的 “全局状态”。中继链拥有自己的共识算法，叫做 GRANDPA 共识（祖父共识），可以迅速将平行链上的区块确定下来。通过这个模型，Polkadot 的平行链实现了 “安全性共享”——如果中继链上有 1000 名验证者，具有极高的安全性，凡是连接到这条中继链的平行链都会受益。这样一来，平行链即能拥有自己的状态机并自定义规则，又能与成百上千条平行链一起共享母链的安全性。 这种模型的罩门在于由中继链上的验证者来验证平行链上的状态改变。例如，验证者可能会出于某种原因一直拒绝某条链上的核验人提议的区块，而且这条中继链上的区块永远无法被添加进全局状态。为了尽量避免这种情况，Polkadot 对验证者进行混洗，让他们随机验证平行链，降低同一位验证者始终验证同一条平行链的概率。Polkadot 还另设有一类被称为 Fishermen （渔夫）的验证者，他们会不断查验验证者是否存在恶意行为。 Cosmos 采用了完全不同的网络架构。 Cosmos的网络架构 在 Cosmos 网络中，每条链都是独立运行的，并设有自己的安全机制，而非像 Polkadot 那样采用 局部/全局 的安全性模型。每条链都有自己的共识机制，而且由单独的验证者来负责保护这条链的安全性。Cosmos 网络使用中心-分区模型来实现互操作性，每个分区（独立的链）都可以通过中心（同样是一条独立的链）向其它分区 “发送代币”。这个协议被称为 IBC （跨链通信），是链与链之间通过发送消息实现代币转账的协议。IBC 协议尚在开发之中，最开始先支持代币转账，最终会支持各类消息的跨链传递。 相比于 Polkadot 的架构而言，Cosmos 的架构最大的不同之处在于，每个分区的状态仅由各自的验证者保护。一个分区想要获得很强的安全性，就需要建立自己的验证者集，这对于小型应用程序来说会比较困难。不过，对于那些想要获得更多控制权的应用程序来说，这是个很大的亮点。例如，币安最开始就是用自己的节点来充当币安链的验证者，来促进去中心化交易所的持续运行。这样一来，币安在测试币安链并增加新功能的时候就有了充分的控制权。我觉得币安不太可能放弃决定哪些交易可以上链的权力，但若要在以太坊或 Polkadot 平台上开发，就不能不放弃这样的权力。正因如此，我认为 Telegram、Facebook 和 Kakao 这类公司会选择构建自己的区块链并掌握其控制权，未来也不太可能与别的链通信。 2. 治理和参与 Polkadot 和 Cosmos 之间的第二个主要差别在于治理和参与。在 Polkadot 网络中，只有一条中继链和一些与这条中继链共享验证者的平行链。根据目前的估算，平行链的数量上限为 100 条，不过未来有可能减少或增加。Polkadot 网络通过拍卖机制来竞拍平行链的使用权——出价最高的人需要在 PoS 系统中锁定一定数量的 DOT （Polkadot 上的原生货币），才可以在一定时间段内拥有所拍得平行链的使用权。这意味着要想使用 Polkadot 上的平行链，需要购买并锁定大量 DOT ，直到不想再使用这条平行链为止。 Cosmos 网络没有设置固定的参与规则——任何人都可以创建中心或分区。中心就是具有自治能力的区块链，专门用来连接其它区块链。这里有两个例子，一个是 Cosmos Hub，最近已由 Tendermint 团队上线；另一个是 Iris Hub，旨在连接主要运行于中国或其它亚洲国家的区块链 。这种中心-分区模型提高了跨链通信的效率，因为分区链只需要连接到中心，无需连接到其他每条链上。 中心-分区模型可以更高效地连接多条链 由于参与规则不同，这两个网络在治理流程上也存在差异。在 Polkadot 网络中，治理决策取决于投票者所质押的 DOT 数量。关于链上投票会有一套正式机制，不过尚未最终确定下来，点击此处可了解最新进展。除了采取以质押量决定投票权重的机制之外，Polkadot 还组建了一个委员会来代表不活跃的权益持有者。委员会最开始由 6 人组成，每两周增加 1 人，直到满 24 人为止。每位委员会成员均通过赞成投票的方式选出。治理流程的具体细节尚未敲定，也就是说有很多方法可以改变中继链的参数，如出块时间、区块奖励等，以及平行链的参与规则。例如，Polkadot 的治理流程可以改变平行链使用权的竞拍机制或所需的 DOT 数量。有一种常见的误解是 DOT 持有者可以通过投票随意弃用某条平行链。实际上，DOT 持有者只能改变参与流程。也就是说一旦竞拍下了某条平行链，在整个租期之内都享有这条链的使用权。 另一方面，Cosmos 网络不存在单一的 “治理”流程。每个中心和分区都有自己的治理流程，因此没有一套应用于整个系统内所有链的核心规则。我们所说的“Cosmos 治理”指的都是 Cosmos Hub 的治理，即由 Tendermint 团队上线的那条链。Cosmos Hub 的规则是，任何人都可以发送一个文本提议，由 ATOM 持有者进行投票表决，ATOM 的质押量决定了投票权重。想知道提议长什么样子，这里有个例子。如果你想深入了解治理流程的话，可以阅读一下 Chorus One 发布的这篇帖子，是了解 Cosmos Hub 治理机制的入门材料。 3.跨链通信 Polkadot 和 Cosmos 之间的另一个差别是跨链通信协议及其设计目标。Polkadot 旨在实现平行链之间任意的消息传递。也就是说，平行链 A 可以调用平行链 B 中的智能合约，实现与平行链 B 之间的代币转账或是其他类型的通信。Cosmos 则聚焦于跨链资产转移，其协议较为简单。目前，这两种通信协议仍待完善细则，而且尚未构建完成。可以查看 IBC（跨链通信）和 ICMP （平行链之间的跨链通信）这两种协议的细则。 跨链通信所面临的最大挑战不是如何将一条链上的数据在另一条链上表示出来，而是如何处理链分叉和链重组这样的情况。这是 Cosmos 和 Polkadot 在构架设计上最大的差异。 为了确保跨链通信的安全性，Polkadot 采用了两种不同的机制。首先是安全性共享机制，降低了信息交换的难度。 共享安全性的另一个好处是所有平行链都位于同一个安全层级，因此每条链可以彼此信任。为便于理解，我们以以太坊（安全性较高）和 Verge（安全性较低）的交互操作为例。若想在 Verge 链上表示以太坊，我们可以锁定一些以太坊，然后在 Verge 链上生成 ETH-XVG 代币。然而，由于 Verge 链的安全性较低，攻击者可能会向 Verge 链发动 51% 攻击，并向以太坊区块链发送双花交易，就可以取回比实际拥有数量更多的以太币。因此，在互相发送消息的时候，安全性较高的链很难信任安全性较低的链。如果是在安全层级各不相同的链之间互传消息，情况就会变得更加复杂。 从理论上来说，共享安全性是一种保障跨链通信的良好方式。前提是，这种协议要确保能够经常对验证者进行混洗，再随机分配到各条平行链上。这就会造成经典的 “数据可用性问题”，即每次验证者被分配到新的平行链上，就需要下载新链的状态。这是目前区块链领域最大的难题之一，Polkadot 能否解决尚未可知。 其次，Polkadot 引入了 Fisherman（渔夫）的概念，也就是 Polkadot 网络上的 “赏金猎人”，专门监视平行链上的恶意行为。从某种意义上来说，这是抵御恶意行为的“第二道防线”。如果某条平行链的验证者将一个无效块上链，Fisherman 发现后可以向中继链提交证明，将包括所有平行链在内的整个 Polkadot 网络的状态进行回滚。在跨链通信期间，最令我们担心的莫过于一条链在重组，另一条链却运行如常。Polkadot 就避免了这个问题，一旦发现无效块上链，整个网络都会回滚。 Cosmos 采用了完全不同的跨链通信方式。因为每条链上都有自己的验证者，所以很有可能会出现分区中的验证者串谋的情况。也就是说，如果有两个分区需要通信，A 分区需要必须信任 Cosmos Hub（通信枢纽）以及 B 分区中的验证者。从理论上来说，A 分区的人在决定向 B 分区发送信息之前，需要调查一下 B 分区的验证者。不过我觉得实际情况没那么糟糕。 Polychain Labs 或 Zaki Manian 的 iqlusion 等知名验证者节点可能会验证多条链，逐渐建立起良好的声誉。也就是说，当 A 分区的人看到 B 分区是由 Polychain Labs 和 iqlusion 验证的，可能会因此决定信任 B 分区。 然而，即使一条链得到了人们的信任，也有可能被怀有恶意的攻击者控制，出现各种问题。有一段对话中提到了一个很好的例子： 代币分散于不同分区的 Cosmos 网络 假设上图中的小红点代表一种名为 ETM 的代币，即 Ethermint 分区的原生代币。A、B、C 三个分区的用户想要使用 ETM 来运行各自分区内的一些应用程序，而且他们都信任 Ethermint 分区，因此通过跨链通信在各自的分区内接受了一些 ETM 。现在假设 Ethermint 分区的验证者串谋发动双花攻击，任意转移 ETM 代币。这也会对剩余网络造成影响，因为 ETM 代币也存在于其他分区中。不过受波及的只有 Ethermint 或其他分区中的 ETM 代币持有者。Ethermint 分区中的恶意验证者只能毁掉自己的分区，破坏不了其他分区。这就是 Cosmos 架构的目标——确保恶意行为无法影响整个网络。 Polkadot 则不同。如果中继链（全局状态）上发生了无效状态更新，又没被 Fisherman 发现的话，Polkadot 网络中的每条平行链都会受到影响。平行链不能被看作是完全不同的东西，毕竟它们都共享同一个全局状态。 4.共识算法 Polkadot 中继链采用的是 GRANDPA 共识算法。这个算法能让中继链迅速确定来自所有平行链的区块，并且容纳大量验证者（1000 名以上）。简单来说，这是因为并非所有验证者都需要对每一个区块进行投票——他们可以只需为自己认为有效的某个区块投票，相当于这个区块之前的所有区块也都得到了认可。通过这种方式，GRANDPA 算法可以找出一组得票数最多的区块，并将这组区块确定了下来。该算法仍处于开发之中，尚不知实际会如何执行。 平行链可以采用不同的共识算法达成局部共识。Polkadot 提供一个软件开发工具包（Substrate），其中包括 GRANDPA、Rhododendron 和 Aurand 三种开箱即用的共识算法。今后可能会有更多算法被加入 Substrate ，皆可应用于 Polkadot 网络。 在 Cosmos 网络中，每条链可以选用的共识算法有很多，只要是符合 ABCI 规范的共识算法即可。 ABCI 规范旨在实现跨链通信的标准化。目前只有 Tendermint 算法符合这个规范，还有另一些团队也在努力开发符合该规范的其他共识算法。从更抽象的层面上来看，Tendermint 算法的原理是让每位验证者都能互相通信，共同决定一个区块能否上链，这样就能实现单一区块层面上的确定性。该算法的速度很快，而且通过了 200 名验证者的压力测试，在 Game of Stakes（权益争夺赛）中的出块时间为 6 秒。Cosmos 团队也提供了一个软件开发工具包，里面包含了开箱即用的 Tendermint 算法。这篇文章很好地介绍了共识算法，以及 Tendermint 算法的功能。 Tendermint 算法最大的缺点是验证者之间的通信成本高很高。也就是说，虽然验证者人数在 200 左右的时候，算法的运行速度很快，一旦人数涨到了 2000 ，速度就会慢得多。另一方面需要权衡的是异步环境中的安全性。也就是说，在出现网络分区之时，不会出现两个不同的交易历史最终合并成一个（而另一个交易历史被抛弃）的情况，而是整个网络都将停止运行。这点非常重要，一旦一笔交易得到了“最终确认”，即使是在最差的网络环境下也不会被撤销。 我的个人观点是，基于共识算法来比较这两个项目没什么长远意义。这两个项目的构架未来都将接受不同的共识算法。如今的绝大多数应用不管使用的是 Tendermint 算法还是 Polkadot 的某个共识算法都可以良好运行。 5.Substrate vs Cosmos SDK Polkadot 和 Cosmos 都提供软件开发工具包，分别叫作 Substrate 和 Cosmos SDK 。二者的目的都是为了便于开发者搭建自己的区块链，其中包括各种开箱即用的模块，例如治理模块（投票系统）、质押模块和认证模块等。这两个工具包最主要的区别在于，Cosmos SDK 仅支持 Go 语言，而 Substrate 支持任何可编译为 WASM (Web Assembly) 的语言，给予了开发者更多灵活性。 这两个工具包都是构建区块链的全新框架，未来几年还将新增更多功能。关于这两个工具包的深度剖析以及使用这两个工具包开发应用程序的详细体验需要另外写一篇文章了。如果你感兴趣的话，请在推特上给我 @juliankoh 留言。 结论 虽然这篇文章篇幅很长，写的也很详细，但是依然有所疏漏。Cosmos 和 Polkadot 之间的不同点很难把握，可能还有很多细节我没有捕捉到。要全方位了解这两个项目绝非易事，毕竟项目文件随时都可能改动。这两个项目尚在起步阶段，未来一年将得到极大的发展——我在上文中提到的几个点可能很快就不成立了。总而言之，我认为 Polkadot 相比 Cosmos 主要有以下几个优势： 应用程序开发者不需要自己维护安全性 共享安全性模型下的跨链通信更容易解决数据可用性问题 Substrate（在 WASM、更多共识算法和开箱即用模块方面）表现出很大的野心 相比跨平行链的合约调用更侧重于不限类型的信息传递（这一用例目前尚不明确） 1.0 版本的开发者似乎多一些 反过来，Cosmos 相比 Polkadot 主要有以下几个优势： Cosmos 已经上线了，Polkadot 还没上线 Polkadot 的平行链参与流程限制性更强，而且成本更高 更能满足特定项目（如币安）对自定义的需求 平行链上验证者的恶意行为会波及整个网络。在 Cosmos 网络中，恶意行为只能破坏个别分区和资产 已经有很多项目在使用 Cosmos SDK 了 重点关注如何降低资产转移的难度。目前已经有经过验证的用例。 感谢每一位不厌其烦为我答疑解惑的朋友，尤其是来自 Cosmos 团队的 Zaki Manian 和 Gautier Marin ，以及来自 Polkadot 团队的 Alistair Stewart 。NEAR Protocol (Alex Skidanov) 发布的 Whiteboard Series 系列视频很棒，对我理解这两个项目给予了很大帮助。Linda Xie 整理出来的关于 Polkadot 和 Cosmos 的链接帮助我缩小了文章的范围，让这篇文章更具有可读性。特别感谢 Cheryl Yeoh 在我撰写本文的过程中为我提供的灵感和思路，并且对本文进行了审校。 转载自：https://ethfans.org/posts/5-differences-between-cosmos-polkadot
跨链加密货币资产转移是开发团队在 Cosmos 中实现的核心功能。在 Cosmos 生态中，加密资产可以通过 IBC 协议进行转移。IBC 协议是一种能够促进互操作能力的跨链通信协议（Inter-Blockchain Communication Protocol）。值得一提的是，IBC 协议只有在转出和转入区块链都具有最终性时才能使用。 但是，比特币和以太坊都不具有最终性保证；他们都是概率最终性。[注：不久的将来 Casper the Friendly Finality Gadget (FFG) 实现后，以太坊会具有最终性。（编者注：中译本见文末超链接）] 概率最终性意味着，随着某个区块后面的链的长度的增加，这条链也就更不容易被重新组织，也就更能让我们相信这个区块是“最终的”。但是因为概率最终性不能完全防止区块链的重新组织，所以通过 IBC 协议安全地跨链转移资产是不可行的。这就提出了一个问题：Cosmos 分区（Zone）是如何与已经存在的不具有最终性的区块链进行互操作的。 挂钩分区（Peg Zone） 挂钩分区是 Cosmos 的解决方案。一个挂钩分区是一条基于账户模式的区块链，它将 Cosmos 中的分区与像 Bitcoin、Ethereum 这样的外部的区块链连接起来。它扮演了一个适配器分区的角色；或者是像在 Casper 演讲中说的那样，它是一个“最终性工具”。通过设定一个“最终性阈值”，当区块链中新增一定数量的区块后认为区块链具有了伪最终性（Pseudo-finality）。一般来说，这种“连接”分区设计可以被认为是一种两路挂钩（2WP）。 像 Tendermint Core这样的共识引擎提供了实时最终性。如果想更好的了解它是如何工作的，请阅读关于 Tendermint 共识的更多内容 连接以太坊 以太坊挂钩分区将是 Cosmos 中第一批实现的这种分区之一。它与 Ethermint 非常不同，后者剥离了 PoW 挖矿，然后在 Tendermint 共识机制和新的网络协议栈之上实现 EVM。而以太坊挂钩分区会使得 ERC20 代币和以太币能够在原生的以太坊和 Cosmos 网络中通过 IBC 连接的所有分区间转移。 挂钩分区的细则还在开发中，你可以关注它的 Github 代码库： Peggy 。 Peggy 在 Cosmos 中，因为我们可以使用 IBC 协议转移任何加密资产，所以容易进行互操作。然而，在 Cosmos 和以太坊之间转移加密货币在技术上是十分复杂的，这是因为 IBC 数据包不能以太坊中被高效地解码。这又是因为 EVM 没有设计成与 IBC 兼容。这些问题只有 Peggy 才能解决。 Peggy 有一个曲折的开端。第一个尝试把 Cosmos 和以太坊连接起来的是一个叫 ETGate 的黑客马拉松项目，但后来证实 ETGate 需要大量消耗 Gas。ETGate 是由 Joon 设计的，他是第二届 HackAtom 的大奖获得者。他也加入了 Cosmos 开发 Peggy。 ETGate 最初尝试直接将 Cosmos 枢纽（Hub）和以太坊连接起来的。它尝试在 EVM 内部编译出兼容性。就像这样： [ 以太坊 ] <- ETGate -> [ Cosmos 枢纽 ] 当面对 Tendermint 和以太坊使用不同的构件的问题时，这种设计是非常不实用的。Tendermint 中使用的每一个基础构件都与以太坊中的基础构件不兼容。事实证明，尝试在 EVM 中客服兼容性问题、构建可互操作区块的成本非常昂贵。 以下是构建可互操作区块的模块分析： 序列化格式： Tendermint 的序列化对象的编码方法是 go-wire。以太坊用的是 RLP (Recursive Length Prefix)。 签名方案： Tendermint 使用的是 ed25519，而以太坊用的是 secp256k1。 数据结构： Tendermint 把键值对存在 IAVL+ 树中，而以太坊把它们存在 Patricia 树中。 ETGate 的设计消耗大量计算资源，因为它在 EVM 中解码 IBC 数据包。IBC 数据包中的内容是 Tendermint 头、交易、IAVL+ 树证明和 ed25519 签名。 在意识到我们可以通过把解析转换机制放在 EVM 之外，即定制的区块链中完成，此方式将节省大量 Gas，Peggy 的设计思路就变得清晰了。 Peggy 的 5 个组成部分 以太坊智能合约：将会有一组以太坊智能合约扮演资产保管人的角色，它们能够保管以太坊中的代币和 Cosmos 中的代币。 见证人（Witness）：见证人组件能够证明以太坊中发生的事件。100 个区块（也就是最终性门槛）产生之后，见证人会在不具有最终性的区块链上实现伪最终性。它运行一个完全验证的以太坊节点，以便通过将 WitnessTX 提交到挂钩分区中来证明以太坊中的状态更改。我们在这里使用一个共享的安全模型，让一组 Cosmos 枢纽验证人同时作为挂钩分区的见证人。 挂钩分区：挂钩分区是建立在 Tendermint 上的，用于连接不同类型区块链。它允许用户执行或者查询交易。这就是 Cosmos 如何与以太坊进行通信的。 签名者：签名者使用以太坊能够解析的 secp256k1 签名方案对信息进行签名，以便智能合约能够高效地验证签名。签名组件通过 SignTx 消息生成一个 secp256k1 签名并将其发布到挂钩分区中，以便在管道中的智能合约中转发事务进行验证。 中继器： 中继器组件批量转发交易信息。这些交易由签名者模块进行签名后被转发到以太坊智能合约中。 总结 现实世界中的例子：把 Cosmos 中的代币转到以太坊中 例如，你想取出一些 Cosmos 的 Photon 代币并且把他们变成等值的以太币。该怎样利用 Peggy 完成的呢？为简单起见，我们会略去低层次的技术细节，只描述主要的流程。 首先从 Cosmos 枢纽中开始。你先通过 IBC 协议把一些 Photon 转移到挂钩分区中。挂钩分区接收到传来的 IBC 数据包：一个包含发送 Photon 代币的消息。签名者监视着这个挂钩分区并且对这些 IBC 交易进行签名，高效的把这些签名转换为以太坊能解析的 secp256k1 格式的私钥。这样一来，你的交易就在挂钩分区上完成了签名。 关注这个挂钩分区的中继器等到他们看到超过 2/3 的签名者这个交易进行了签名，然后将你签署的交易批量处理为通过 IBC 发送的所有其他交易的清单。然后他们把附有签名的列表转发到以太坊智能合约运行的 EVM 上。 以太坊智能合约接下来检查交易列表是否有效。针对 Photon 智能合约会生成它的 ERC20 版本。智能合约产生 ERC20 Photon 之后，它将 ERC20 Photon 发送到你在以太坊主网中的地址上。 此时，你可以方便地通过例如 0x protocol 或是 OmiseGO 这样的 ERC20 去中心化交易所（DEX）把 ERC20 Photons 转换成ETH。 最后 我们正在进行 Peggy 的早期设计。相关以太坊智能合约已经编写完成并且正在进行测试。在许多方面上，Peggy 甚至比 Cosmos 枢纽更加复杂。为了使其能正确的运行，Peggy 将需要进行数次迭代。大家可以期待 Peggy 在今年下半年上线，也就是在 Cosmos 主网上线后。对于以太坊项目而言，很多问题都亟待解决：可扩展性解决方案的需求，吞吐量的增加以及降低运行成本。以上问题都十分重要。因此，Peggy 的部署是重中之重，在开发其余生态系统项目的同时，Cosmos / Tendermint 团队已经将其大部分资源用于 Peggy 的开发。 正在进行的工作 以太坊智能合约一旦部署之后就无法修改，因此非常难以更新。在智能合约更新管理方面还缺乏组织结构。Peggy 的发展路线图迫使我们应对这种不确定性，但这是我们希望能够产生具体解决方案的一个研究领域。 转载自：https://ethfans.org/posts/the-internet-of-blockchains-how-cosmos-does-interoperability-starting-with-the-ethereum-peg-zone
权益证明的漫漫长路 权益证明的定义可以查看理解权益证明。 1982年，拜占庭将军问题首次被Lamport，Shostak和Pease提出。Cosmos的Ethan Buchman这样描述它：”这是一个在可妥协的通信网络中实现分布式协议的问题，也就是在不可靠的环境中建立一个可靠的系统的问题“。从1982年到1999年，都没有人能够创造一个可以解决拜占庭将军问题系统。长久以来，拜占庭将军问题与计算都是无关的，因为在那个时候，互联网演进出基于云的中央中心化计算模式，所需要解决的只是容错问题。 所以，故障容错算法得到普及，例如1998年发明的Paxos算法和2013年发明的Raft算法被广泛的应用。而1999年发明的实用拜占庭容错（PBFT）却没有被学术界之外采用。直到2008年，中本聪将网络规模级别的分布式拜占庭容错(BFT)算法设计到区块链方案中，才使拜占庭容错得到推广。当这种原型出现之后，系统研究界的人都开始围绕将学术界“奇物”应用到真实世界而去构思各种想法。 在2011年，BitcoinTalk论坛对一个叫做权益证明(PoS)的概念组织了一场讨论。最初的PoS协议例如点点币，实现结果的并不理想。第一个真正提出将BFT研究应用到PoS公有区块链环境中是Jae Kwon，他在2014年创造了Tendermint。 在当时，PoS研究做出了很大的假设：假设系统中的一系列对等节点都是静态的，并且在长时间内都是稳定的。在区块链环境中完全是不现实的。 Jae Kwon的重大突破是使Tendermint能够使用区块，哈希链接，动态验证器集合和循环的领导者选举来将BFT研究适应复制状态机（区块链）的领域。 在Tendermint环境中，出现了大量的共识算法（Honeybadger, Ouroboros, Tezos, Casper），它们都包含了BTF研究的元素以及在区块链上其他模块观察的元素。 为权益证明做的所有研究都指向一个重要问题：在不耗尽物质稀缺资源的情况下，我们可以达到工作量证明（PoW）的安全级别吗？这个问题可以转化为：PoS的投票权以链上货币计价而不是计算力计价。区块链的POS共识问题比可扩展性更被广泛讨论，运行PoW挖矿的高开销成本以及环境外部性方面存在的问题都刺激了大量资源涌入PoS安全研究。 本文主要探讨了在加密货币中使用了权益证明的三个主要PoS协议的特性：由Vlad Zamfir带领研究的Casper the Friendly Ghost(CTFG)和由Vitalik Buterin带领研究Casper the Friendly Finality Gadget(CFFG)以及Jae Kwon带领研究的Tendermint。 权益证明的陷阱 无利害关系 起初，有多种不同的说法来描述权益证明的一般陷阱，无利害关系就在这时被提出。Jae Kwon 2014年5月以“错误选择谬论”的不幸名字第一次提到这个问题。在2014年7月Vitalik把比特币开发者所描述的确切定义的问题普及推广为“无利害关系”。问题呈现出此情况：验证者通过在给定高度为多个有冲突的区块投票可以有效的破坏安全性而不用付出任何代价。 简单的PoS实现对于这些攻击而言是非常脆弱的。灾难性的是，因为没有任何的激励来鼓励大家永远集中在一个独一的链上，并且每次激励都要同时在相互冲突的链条上进行重复签名，所以为了获得更多的区块奖励，在经济上最优的策略就变成了尽可能的在多个分杈上进行投票。下面这张图就展示了： 在简单的PoS设计中竞争链上的期待投票数高于单一链上期待的投票数 在工作量证明中，对于在多个链上进行挖矿的矿工“惩罚”是他们必须分开他们的计算力（非常稀缺的资源）。在现代非简并的PoS设计中，这种成本必须嵌入到协议里面以此模仿物理PoW挖矿的限制。 Vitalik Buterin在2014年1月引入的“slasher”概念或协议内惩罚可以减轻这个攻击。Jae Kwon在同一年进一步推算了此方法，这是实现Tendermint共识协议的第一个迭代进展。苛刻以及允许这种惩罚的条件，对于所有的非简并BFT协议都是有帮助的，甚至在本文中出现的三种共识都采用了。 远程攻击 远程攻击来源于用户不得不撤回保证金的权利。这就产生了一个基本问题，因为这意味着攻击者可以从任意长度的距离建立一个分杈而不用担心被削减。一旦保证金被解除绑定，激励不从某个高度区块前进行长距离投票就被取消了。换句话说，当超过2/3的验证者解除了绑定，那么他们就可以恶意的创造包含之前验证者集的第二条链，这可能导致任意的交易。 对于权益证明协议这是相当致命的，因为安全模型必然是“主观”的。当参与网络要求大量的社会信息，那么这个安全模型就会被称为是“主观的”。一个新节点加入网络之后，对于当前网络的状态可能会得出不同的结论，因为他们的决策是基于主观信息的，即社会声誉。在相反面，工作量证明的安全模型必然是“客观的”，因为当前网络状态总是工作量最多的那个状态，新节点对于网络状态的结论总是相同的，因为他们的决策是基于客观信息。 PoS的远程攻击在弱主观性模型下进行了纠正，这要求接入到网络中的后续新节点： 当前必须是被绑定的。只相信当前有保证金的验证节点 解除绑定保证金必须要经过一个"解冻"期。解除绑定之后，代币需要数周到数月的“解冻”时间，用以实现“同步性”前提（即延迟的消息） 禁止在N个块之前恢复，其中N是保证金的长度。 这个规则使任何长程分杈无效。 可选择的将验证者集存放在PoW的链上 Casper（s）和Tendermint采用一种简单的锁定机制（“Tendermint”中俗称“冻结”）来锁定股权一段时间（几周到几个月后“解冻”），以防止任何恶意联合验证者 违反安全。在CFFG算法中，一个分杈选择规则永远只能修改最终块之后的块阻止了远程攻击。通过使用时间戳，在CFFG中的长距离分叉试图修改比最终块还要更早的块的时候会被协议直接忽略掉。 卡特尔形式 第三，最后的障碍是面临任意价值的任何经济形式都将面对一个真正的寡头垄断问题，就算本土加密货币也不例外。 “加密货币令人难以置信的集中，挖矿算力也是一样。寡头垄断竞争是很多现实市场的常态。少数相对富有的验证者之间的协调比多数相对贫穷验证者之间的协调要容易的多。在我们这种情况下，卡特尔形式是完全被预料到的。” ——Vlad Zamfir，Casper的历史第4章节 Tendermint依靠额外协议管理方法来与寡头垄断验证者进行对抗。虽然在审查制度方面没有任何协议措施，但依靠带外社会信息解决卡特尔形成，其中的基本原理是：用户最终将不可避免地注意到卡特尔的形成，社会上也会对此到处八卦，然后放弃或者投票重新组织受到攻击的区块链。 到目前为止，Vlad的Casper协议是唯一一个明确使用共识内审查激励来打击卡特尔形式一种模式。 概述 有很多不同的方式来实现权益证明的算法，但是权益证明设计的两个主要原理是基于链的PoS和基于拜占庭容错(BFT)的PoS。Tendermint是基于拜占庭容错的PoS设计，CTFG是基于链的PoS设计，而CFFG则混合了两者。 计算机科学中的CAP理论返回在分布式数据系统中提供超过2/3担保的不可能性：可用性、一致性、分区容错。基于链的PoS算法倾向于选择可用性高的而不选择一致性高的，因为可用性高意味着所有的交易都能被处理，不过要以牺牲整个网络中一致性状态复制为代价。基于BFT的却相反，会倾向于选择高一致性。 基于BFT的权益证明 拜占庭容错共识算法源于30多年的丰富研究。Tendermint（2014）是Castro和Liskov在1999年引入的实用拜占庭容错(PBFT)算法的第一个PoS的改编版。基于BFT的PoS协议伪随机的安排一个验证者在多轮投票的过程中提出一个区块。但是，提交和最终化区块取决于大多数——所有验证者中2/3的验证者在提交的区块中签名。在区块最终化之前可能需要进行几轮(译者注：这种多轮投票和现实世界的波尔卡舞蹈类似， 这也是polkadot 名字的由来)签名。BFT系统只能容错1/3的失败，其中失败包括故障或是恶意的攻击。 Tendermint核心 Tendermint主要包含两个主要的技术：区块链共识引擎和通用的应用接口。共识引擎被称为Tendermint核心模块，确保相同的交易在每个机器中都按照相同的顺序被记录下来。应用接口被称为应用区块链接口(ABCI)，让交易可以被任何编程语言编写的程序处理。 在核心模块中，Tendermint基于循环投票机制进行工作，这也是共识协议的原理。一个回合被分成3个处理步骤：验证者提出一个块、发送提交意图、签名后提交一个新区块。这种机制为原子广播提供了一个安全的状态复制机，增加了一个责任层——安全故障可以完全归结于Tendermint。 Tendermint共识算法从验证者集开始。验证者们都维护了一份区块链的全拷贝，并且可以用公钥来识别验证者的身份。在每个新的块高度他们轮流的提出一个区块。每轮投票都只有一个验证者可以提出块，并且要用验证者相应的私钥对此进行签名，这样的话如果有错误发生就可以找到为此负责的验证者。然后剩下的验证者就需要对每个提议都进行投票，投票都需要用自己的私钥进行签名。这些组成一个回合。不过可能因为网络的异步需要好几个回合才能提交一个新块。 验证者提交块的时候由于几种原因可能会失败：当前的提议可能下线了，或者网络可能遇到了延迟。Tendermint允许验证者可以被跳过（就是轮到一个验证者出块的时候但是此验证者没出块）。验证者在移到下一轮投票之前等待一小段时间来接收提议者（此轮出块的验证者）提出的整个区块。这种对超时的依赖让Tendermint成为一个弱同步协议，而不是一个异步协议。不过，剩下的协议是异步的，并且验证者只有在接收到了超过2/3的验证者集消息时才会进行处理事物。正是因为这样，所以Tendermint需要大多数的验证者可以100%正常运行，如果1/3或更多的验证者离线或脱机，网路就会停止运行了。 假设少于1/3的验证者是拜占庭，Tendermint保证安全永远不会被破坏——也就是，验证者（2/3以上）永远不会在同一个高度提交冲突的区块。因此，基于Temdermint的区块链永远不会分叉。 目前为止，Tendermint的设计决策确实是把安全性和不可改变性地位放在了灵活性之上。在现实世界上有相当高的可能性是，系统真的会停止运行，参与者将会需要在协议外组织在某种软件上更新后重启系统。 在数字加密货币社区中只有少数人理解 Casper以及为什么它很有价值的时候，Tendermint就为Casper研究奠定了基础。这个洞察力就是：如果一个链的本身是高度容错的，那么你就可以依赖链来对于谁来生产区块做出一个好的决定，但是如果链的本身就是不可靠的，那么你就陷入了鸡和鸡蛋的问题中去了，这也是之前所有其他共识算法的灭顶之灾。 这个设计决策被认为不如可用性优先的协议例如以太坊和比特币。比特币中的权衡是：如果它的网络被分裂了，比特币在各种攻击的情况下就失去了它的安全保证。这其实就是一个不可修改理论，也就是你的置信区间是100%的时候，那么你跟随的就是一条正确的链，你会使用这条链来选择谁来生产下个区块，但是一旦你转移到一条不安全的链上之后，并没有一条明确的路径让你回到正确的链上。 Tendermint的明确属性 可证明的活跃性 安全阈值：1/3的验证者 公有/私有链相容 即时的最终确定性：1-3秒，取决于验证者数量 一致性优先 在弱同步性网络的共识安全 基于链的权益证明 基于链的权益证明模仿了工作量证明共识算法，在此权益证明中协议让伪随机选择出来的验证者产生一个新块，新块是哈希连接（包含上个块的哈希值）到前一个最长链的父区块上。基于链的PoS非常依赖同步的网络，通常优先考虑可用性而非一致性。Casper(s)对于倾向于活跃性而非安全性环境而言，它就是Tendermint核心思想的一个改编。 CFFG CTFG是一个明确的PoS构造，但是CFFG是一个覆盖在已存在的以太坊PoW提议机制上的PoS——融合了PoW和PoS两者，由Vitalik Buterin带领实现。 比特币和以太坊的PoW共识协议都不会做“最终”决定，并且区块可能会潜在的被重新组织到一些过去区块高度。当区块没有机会再被修改的时候才能称为“最终确定”的。因为工作量证明没有提供这样的修改保证，所以它被认为是共识不安全的。相反，当我们持续加长链的时候区块的最终确定性概率也越来越高。为了为以太坊区块链增加想要的最终确定性和51%的攻击阻力，CFFG实现的逻辑就完美的提供了这种效果。 CFFG将通过多个步骤推出，以保守的方式将以太坊的PoW安全模式逐渐过渡到PoS安全模式。Casper的第一个迭代将会是实现这里讨论的混合PoW/PoS协议，Casper的最后一个迭代很有可能吸取CFFG和CTFG的教训，朝着一个完整的PoS协议发展。 CFFG是基于链的PoS和基于BFT的PoS的之间的混合体，因为它吸取了两者的思想。它的模块化覆盖设计让现在的PoW链的更新变得更加容易，因为它对于将系统升级到完全不同的共识模式而言是一种更保守的方法。 Casper的应用逻辑存在于智能合约的内部。要想在Casper中成为验证者，必须要有ETH并且要将ETH存储到Casper智能合约中作为杠杆的权益。在Casper第一次迭代中区块提议的机制会被保留：它依然使用Nakamoto PoW共识，矿工可以创建区块。不过为了最终化区块，Casper的PoS覆盖掌握控制权，并且拥有自己的验证者在PoW矿工之后进行投票。 Casper的PoS共识最重要的一个部分就是检查点(checkpoints)。Casper在50区块增量的时候评估最终确定性就称之为检查点，每50个块片段就称之为周期(epoch)。通过验证者在每个周期发送投票消息时触发这个处理过程。 在一个周期前最终化检查点需要2个周期才能完成，也就是需要两轮投票。例如，当超过2/3的验证者（也就是大多数）给一个检查点c投票了，那么就说这个检查点已经被"审判"了。下一个周期，当大多数人给检查点c投票了，会发生两件事情：c变成了被审判的并且c已经最终化了。c这个周期也就代表着最后一个最终化的周期(LFE)。 回顾一下，一个区块最终化需要两个条件： 大多数(超过2/3)验证者在周期1的时候给区块1进行了投票，因此审判了区块1 大多数(超过2/3)验证者在周期2的时候给区块2进行了投票，区块2是区块1的子区块，因此在周期2的时候最终化了区块1 在理想执行中，一个区块的最终化是按照下面的步骤的： 区块1的2/3投票→审判区块1→2/3投票区块2→最终化区块1 其中区块2是区块1的子区块 当一个检查点被最终化之后验证者就会得到报酬。不过，如果有两个最终化的检查点在相同高度上分杈时，那么就破坏了安全性，这个时候就达到了消减的条件，最少1/3的保证金将会被消减掉。当安全性被破坏的时候可以将错误归因的证据当作交易广播给PoW的矿工。然后PoW就将这个证据交易组成一个区块来进行挖矿，提交了这个证据的验证者会得到查找者的费用。当此事发生的时候，签署了在冲突区块的有罪验证者将会在两条链上被消减掉。 现在如果一个矿工进行蛮力攻击，那么会发生什么？现在Casper的最终化区块链可以防止PoW的攻击者，就算是51%或者更多的计算力重写最新检查点之外的历史也会被阻止。因此，Casper协议提供了安全。不像CTFG，因为CFFG就是不同提议机制上的一层覆盖，Casper不能确保活跃性，因为活跃性是取决于提议机制的。 验证者是被激励着集合在权威链上的，因为如果他们持续在不同的链上进行投票将会受到惩罚。Slasher 2.0的形成让验证者不仅仅会为双重投票而受罚也要为在不正确的链上进行投票而受到惩罚。不过这也造成了一个“泄气”的窘境，因为验证者担心如果出现一个分杈而自己不确定到底哪个才是权威的，然后投错票之后被消减所以选择退出投票。 CFFG的明确属性 最终化：超过20分钟最终化。每隔50块（一个周期）就最终化一次区块，防止PoW挖矿暴利攻击 共识安全性 可证明的活跃性 优先可用性 CTFG CTFG是Vlad Zamfir的正确构造(CBC)共识协议专用于对抗寡头垄断的真实世界的环境。CTFG是工作量证明中GHOS或GHOST协议的PoS改编版，用于其分杈选择规则。CTFG背后的指导设计原则是基于加密经济学的，使用旨在实现评估安全的正规方法。与前面详细说明的CFFG混合协议不同，CTFG是纯粹的权益证明的概念。 “Casper刚刚开始的时候只是简单的‘友好的幽灵’，它对于PoS而言是GHOST的改编，完善的激励让卡特尔‘友善地’变成‘非卡特尔’的验证者。” ——Vlad Zamfir，Casper的历史第5章 与工作量证明类似，CTFG会为一致性和可用性进行权衡。特别，在区块没有被最终化的时候，随着在链中的深度越深的它们就会越安全。CTFG与CFFG有一点相似，链头部的处理总是比区块最终化的处理要快很多。 Casper的PoS提议机制与Tendermint提议机制最大的区别是相比较伪随机选择领导者，前者的验证者可以基于自己见到的块提出块。 Casper提供的一个独特功能是参数化安全阈值。与比特币中使用6个确认来确定一个经济最终状态类似，CTFG中的“评估安全”提供了一个验证者可以有一个与其他验证者不同的安全阈值功能。Casper的设计目标是在网络维持PoS低开销的时候能够允许验证者选择自己的容错阈值。 Casper对Tendermint的核心优势在于网络随时可以容纳一定数量的验证者。因为Tendermint中的区块在创建的时候需要最终化，所以区块的确认时间应该短一点。为了达到短区块时间，Tendermint PoS能够容纳的验证者数量就需要有个限制。由于CTFG和CFFG到在区块创建的时候都不需要安全性，所以以太坊网络相对于cosmos容纳100个验证者来说，可以容纳验证者的数量会更加的多一点。 CTFG的明确属性 可用性。Casper的节点在它们达成共识之前可以块分杈 异步安全性 生存。Casper的决策可以在部分同步中存活，但是不能在异步中存活 卡特尔阻力。Casper的整个前提是建立在抵制寡头垄断攻击者基础之上，因此不会有任何勾结的验证者可以超越协议 安全性。取决于每个验证者的评估安全阈值 未来的工作 公链在产品上运行是一个比较新生的技术。在这个范例中到目前为止显示出不会腐败的唯一安全模型就是工作量证明。权益证明的设计空间还非常的大，而且工程学上权衡的理解也远远不够，因为权益证明是一个研究前沿也没有足够的数据。不用多说，要达到一个最佳的PoS共识算法，我们还有很多未来工作需要完成。 Tendermint的一个改进可能是新的提出机制，或者将Tendermint的多轮投票过程压缩成一轮投票。 第二个未来工作的领域可能是利用更高级的加密技术让区块头的签名更小一点。因为我们是通过Cosmos来建立一个“区块链的互联网”，所以将轻客户端证明从一条链上移到另一条链上就是我们的核心工作。从这个观点来看的话，使用更加高级的密码学将区块头的大小减少三十倍或者更多是非常有利的。目前，100验证者，Tendermint的区块头接近4KB，它们都是验证者的签名。我们可以使用高级的加密技术让100个签名从3.2KB减少到64字节。 还有一些优化p2p层的方法，这样我们就可以显著减少点对点需要最终化块的流量。在未来的工作中，不仅仅是压缩区块头中的数据量，还会减少发送到对端的数据量。这样的话，在Cosmos网络初始100个验证者的阈值之上，Tendermint还可以增加更大的验证者集。 转载自：https://ethfans.org/posts/consensus-compare-casper-vs-tendermint
Ethermint 是一个在 Tendermint 上的 Ethereum 优化的产物。将 Ethermint 和 Cosmos Hub 同时发布是为了双方能够促进对方发展：在保证智能合约可编写和执行，同时利用Tendermint引擎提高效率。 Ethermint的主要特性： Web3兼容 高吞吐 横向扩展性强 交易确定性 Cosmos简介 因为以太坊使用的是工作量证明的安全模型，Go Ethereum (Geth)性能很差，也不能提供交易确定性。 使用 Ethermint 不但可以通过 web3 RPC 来部署智能合约，而且操作的速度提升了20倍左右。这得益于区块大小的增长。Geth 的处理速度在 12.5TPS( 每秒交易，transactions per second)。Ethermint 的处理速度在200 TPS，这得益于 Tendermint PoS的确认速度。 Ethermint 相关文档：http://ethermint.readthedocs.io/en/develop/ Ethermint 代码库GitHub：http://github.com/tendermint/ethermint 架构：Hub&Spoke 图解：Cosmos Hub 和 Spoke 架构，每一个空间（Zone）都可以代表一个不同的区块链，也可以是同一条链的多个复制本以实现横向扩展性（Horizontal Scalability） Tendermint 的核心与应用区块链交互界面（ABCI） Tendermint 主要由以下两部分组成：区块链共识引擎和上层应用接口。共识引擎称为：Tendermint Core, 它用来保证系统每个节点内交易的顺序是一致的。上层应用接口称为 Application Blockchain Interface (ABCI), 保证交易能被应用处理，不受编程语言的限制。 Tendermint 也可以被用于保证任意应用的状态一致性。它可以作为一个即插即用的共识组件来替代已有的共识引擎。所以，开发人员可以将任意版本的Ethereal代码(Rust,Go,或Haskell)，把它当作一个ABCI运行在Tendermint共识引擎之上。这就诞生了一个新的Ethereum 。 另一个例子是 Cosmos network，运用 ABCI&Tendermint Core 实现应用和共识过程的分离。 当我们建立好不同的 zones, 可以使用相应的 Inter-blockchain Communication (IBC)协议进行沟通，实现跨链交互。 主要特性 Web3完全兼容 Ethermint 完全兼容 Ethereum 的 web3 接口和 RPC 调用方法。对于一个已经开发好Ethereum 上的钱包软件的开发者，他很容易将钱包转移到 Ethermint 上运行：只要该改变服务的URL。 开发工具 Truffle 简化了部署智能合约的流程，开发者不需要控制和 Ethereum 节点的交互。若将 Ethereum 节点替换为 Ethermint 节点, 那么你就可以将合约部署在Cosmos上。 这样就实现了合约的交互，花费的时间不超过10秒钟。 吞吐量达到更高的数量级 Tendermint 的 PoS 共识引擎无疑能将大大提高Ethermint 的运行速度，这也是它毫无疑问的优势。建立在容许更高吞吐量的共识引擎之上的效果是使得执行智能合约的成本更低。因为 Tendermint 可以处理速度比 Ethereum 虚拟机（EVM）高20倍，这意味着不会再因为网络缓慢的交易导致费用上涨。 因此，在 Ethermint 中执行一个合约可节省20到50倍的交易费用。 不设限的水平扩展 Ethereum 目前的主要问题之一是可扩展性。 Ethereum 处理速度在12.5 TPS，这就是网络到达瓶颈的地方。 Ethermint 的上限在200 TPS。 但是，假设 Cosmos 上线，网络可达到200 TPS 的上限。 由于模块化的 hub 和 zone 的设计，我们可以轻松地添加第二个 Ethermint zone。也就是说，我们可获得了400 TPS的吞吐量。 再加上两个Ethermint zone，我们得到800 TPS。 这种水平可扩展性的方法是 cosmos 所独有的，它可无限扩展。 实时交易确定性 Bitcoin 和 Ethereum 的 PoW 的共识算法都不会做出“最终”决定，而且在51％的攻击下，理论上过去的块可以被重写。 当没有机会修改过去的块时，块被认为是有“确定性”的。 由于 Nakamoto 协议一致没有提供这样的保证，实际上的共识并不被认为是安全的。 在Ethereum目前的PoW建设中，由于块永远不会“最终化”，您必须等待6个确认，然后才能“确定”您的交易已经进入块状。 通常情况下，Bitcoin 的6次确认大约需要60分钟，而Ethereum 需要2分钟。 在 Ethermint 中，您可以获得 Tendermint 的交易最终确定性，平均在1秒钟内确定块。 Ethermint 的实现 由于Tendermint的共识机制的作用，我们可以即时保证交易的最终性。 在Tendermint中，协商一致的节点首先在对块的内容达成共识之前首先进行多轮投票提案流程。 当这些节点的绝对多数决定一个块时，它们通过状态转换逻辑运行它。 在Ethereum中，共识的过程是相反的，矿工们将交易包含在一个块中，运行状态更新，然后做“计算”来尝试挖掘块。 转载自：https://ethfans.org/posts/a-beginners-guide-to-ethermint
安装go环境 下载并安装go https://golang.org/dl/ wget https://dl.google.com/go/go1.12.7.linux-amd64.tar.gz // 下载 tar -C $HOME -xzf go$VERSION.$OS-$ARCH.tar.gz // 解压到home/go 配置环境变量 mkdir -p $HOME/go/bin echo "export GOPATH=$HOME/go" >> ~/.bash_profile echo "export GOBIN=$GOPATH/bin" >> ~/.bash_profile echo "export PATH=$PATH:$GOBIN" >> ~/.bash_profile source ~/.bash_profile 安装cosmos 先解决墙内问题 一键解决 go get golang.org/x 包失败 https://shockerli.net/post/go-get-golang-org-x-solution/ export GO111MODULE=on export GOPROXY=https://goproxy.io // Go version >= 1.11 下载代码并编译 mkdir -p $GOPATH/src/github.com/cosmos cd $GOPATH/src/github.com/cosmos git clone https://github.com/cosmos/cosmos-sdk cd cosmos-sdk && git checkout v0.35.0 make tools install 那将安装gaiad和gaiacli二进制文件。验证一切正常： gaiad version --long gaiacli version --long 安装jq sudo apt-get install jq 开始配置 设置新节点 gaiad init <your_custom_moniker> // 注意Monikers只能包含ASCII字符。使用Unicode字符将使您的节点无法访问。 您可以moniker稍后在~/.gaiad/config/config.toml文件中进行编辑： # A custom human readable name for this node moniker = "<your_custom_moniker>" 您可以编辑该~/.gaiad/config/gaiad.toml文件以启用反垃圾邮件机制并拒绝低于最低汽油价格的传入交易： # This is a TOML config file. # For more information, see https://github.com/toml-lang/toml ##### main base config options ##### # The minimum gas prices a validator is willing to accept for processing a # transaction. A transaction's fees must meet the minimum of any denomination # specified in this config (e.g. 10uatom). minimum-gas-prices = "" 您的完整节点已初始化！ 创建Genesis文件并启动网络 # You can run all of these commands from your home directory cd $HOME # Initialize the genesis.json file that will help you to bootstrap the network gaiad init --chain-id=testing testing # Create a key to hold your validator account gaiacli keys add validator # Add that key into the genesis.app_state.accounts array in the genesis file # NOTE: this command lets you set the number of coins. Make sure this account has some coins # with the genesis.app_state.staking.params.bond_denom denom, the default is staking gaiad add-genesis-account $(gaiacli keys show validator -a) 1000000000stake,1000000000validatortoken # Generate the transaction that creates your validator gaiad gentx --name validator # Add the generated bonding transaction to the genesis file gaiad collect-gentxs # Now its safe to start `gaiad` gaiad start 此设置将所有数据gaiad放入~/.gaiad。您可以检查您创建的创世纪文件~/.gaiad/config/genesis.json。使用此配置gaiacli也可以使用并且具有令牌帐户（包括放样和自定义）。 参考 https://www.jianshu.com/p/38736bdc08d8 https://cosmos.network/docs/cosmos-hub/installation.html#install-gaia https://github.com/cosmos/cosmos-sdk/issues/4634
导读 2017年以来，区块链项目出现了井喷式地上升，然而在喜人增长态势的背后，人们也注意到大部分项目都缺乏与其它区块链项目互连互通的能力而成为孤立的网络体系。 因此，跨链技术也逐渐进入了大家的视野，本文将为大家解读一个跨链项目Cosmos，看看它是如何做到让不同区块链的价值网络实现互通的。通过对该项目的解读，让大家对跨链项目有个初步的了解。 同时受限于篇幅，我们会分为上下两篇，上篇让大家了解了Cosmos的核心技术Tendermint，详情可见上篇：深度剖析区块链跨链技术Cosmos(上篇)。此篇将为大家着重介绍Cosmos。 跨链技术背景 随着区块链技术的火热，越来越多的企业和开发人员加入到区块链的浪潮中，市面上也出现了许多不同类型的链，应用在金融、健康医疗、供应链、资产管理和溯源等领域。然而大部分链上应用（加密货币或者智能合约）都无法跨越当前链的边界，不能与其他链协同合作实现价值的流通从而限制了区块链的发挥空间。如何能让不同类型的链协同合作实现价值的流通成了探索的方向，这也是跨链技术的起因。跨链技术是打开链与链之间互通的钥匙，能很好地解决价值孤岛的问题，建立价值网络的桥梁。 目前主流的跨链技术包括： 公证人机制（Notary schemes） 侧链/中继（Side chains/relays） 哈希锁定（Hash-locking） 分布式私钥控制（Distributed private key control） 而本文所要介绍的主角Cosmos就是中继技术的一个典型案例，接下来将逐步为大家揭开Cosmos的面纱。 Cosmos概述 Cosmos是Tendermint团队推出的一个支持跨链交互的异构网络，它最终的目标是创建一个区块链互联网，允许大量自主且易开发的区块链互相扩展和交互。基于Tendermint开发，采用的Tendermint共识算法，是一个类似实用拜占庭容错共识引擎，具有高性能、一致性、具备拜占庭容错等特点。关于Tendermint的详细介绍可以参考本文上篇：深度剖析区块链跨链技术Cosmos(上篇)。 Cosmos网络由许多独立的并行区块链组成，网络中第一个区块链是Cosmos Hub，其他的并行链称为Zone，通过跨链协议（IBC）与Hub进行跨链操作。 目前Cosmos Hub已经经过了多个版本的迭代，MVP版本也趋于完成，同时测试网络也在前不久更新到gaia-7001，但主网的上线时间团队还未给出，所以对Cosmos感兴趣的朋友还需要一些耐心。 Cosmos架构 从Github上可以看出Cosmos主要的代码是cosmos-sdk，它包含Cosmos Hub的程序代码，同时也是一个区块链开发框架，为其他区块链开发者提供一些通用的功能模块，比如：共识，P2P网络，IBC，账户，治理，认证等。大致框架如下： 不难看出cosmos-sdk其实就是一个ABCI应用。主要有： baseapp：定义了一个基本ABCI应用的模版，与Tendermint通信。开发者也可以根据自己的需求重写。 应用程序：包括gaia、basecoin、democoin。其中gaia就是hub主程序，basecoin以及democoin是提供的两个示例应用。 plugins：cosmos-sdk的基本单元，每个plugin都是baseapp的功能扩展，包含各自的消息和交易处理逻辑。目前SDK已经集成了一些重要的 staking：POS相关的实现，包括：绑定，解绑，通货膨胀，费用等操作。 ibc：跨链协议IBC的实现，也是Cosmos支持跨链的主要插件。 governance：治理相关的实现，如提议、投票等。 auth：定义了一个标准的多资产账户结构（BaseAccount），开发者可以直接嵌入自己的账户体系中。 bank：定义资产的转移。 因此基于cosmos-sdk框架，利用其插件功能，可以非常快速的开发出属于自己应用的区块链，同时也可以很方便的加入Cosmos生态网络，支持不同链之间的互操作，在插件的设计上和EOS也有异曲同工之妙。 那么如何使用这些插件功能呢？可以参考cosmos-sdk提供的示例应用，以basecoin为例，只需要几步： 创建自己的ABCI应用，可以嵌入baseapp，也可以重载baseapp。 定义自己的账户体系，可以嵌入BaseAccount。 选择所需要的插件，注册到消息路由。 Cosmos跨链 Tendermint团队在15年就开始考虑跨链技术，跨链也是Cosmos网络最重要的一个特性。一般来说，实现跨链需要做到： 共识算法需要具备及时最终性，也就是说在出块之后，需要能够快速确认为不可逆（固定不变）。 交易确认需要高效独立的证明方法，目前的做法都是基于Merkle证明。 基于cosmos-sdk的区块链使用了Tendermint共识算法就非常容易能够做到。除此之外，Cosmos的区块链间通信协议（IBC）将不同区块链连接起来，达到价值转移的目的。 IBC协议 IBC协议是针对Cosmos网络设计的，依赖其及时最终性的特点，用于Hub与Zone之间消息传递。IBC协议中设计了两个消息： IBCBlockCommitTx：发送方所在区块链的最新的区块信息。 IBCPacketTx：跨链交易本身的信息，及其在发送方链中被打包的区块信息。 但有了消息的传递，接收链如何校验信任消息呢？ 在IBC协议设计里，两个链建立连接之前需要进行彼此注册，有两个作用： 保存对方链验证者集合以及Merkle证明的算法，这样接收链才能确保消息的正确性和来源的可靠性。 为对方链创建两个可靠队列，一个队列存放所有发送对方链的消息（outgoing），一个队列存放来自对方链的消息（incoming）。 我们以chain1中用户User A转100mycoin 给test-hub用户User B为例看看IBC整个的工作流程如下（基于目前IBC实现代码）： 整个工作流程可以分为三个阶段： User A向chain1提交跨链交易，chain1执行该交易，并将交易存入outgoing队列。 relayer从chain1中对应test-hub的outgoing消息队列取出跨链交易，提交到test-hub。 test-hub执行交易，放入incoming消息队列。 大家可以看到，整个流程比较简单，而且涉及的消息只有IBCPacket。目前Cosmos跨链实现并没有全部完成，只是完成了一个简单的交易处理流程。 PegZone 基于cosmos-sdk开发的区块链能够轻松满足实时最终性，然而现存的Bitcoin和Ethereum这类使用POW共识的区块链并不具备此特点，只能属于概率最终性，无法防止区块链的回滚。对于这类链，团队采用PegZone方案来解决。 PegZone本身其实是一条代理链，实时跟踪原始链的状态，通过设定一个安全阀值，等待原始链区块增长数达到安全阀值时就认为原始链的状态达到了伪实时最终性（回滚概率小），这点和轻客户端钱包验证是相同的原理，例如比特币安全阀值通常设置为6，以太坊安全阀值可以设置为20或者100。而PegZone本身具备实时最终性，就可以通过IBC与Hub相连，从而实现跨链。 接下来还是用例子来说明下，以Ethereum为例来看，有兴趣的朋友可参考Github上的cosmos/Peggy项目。示意图如下： 上图我们可以看出PegZone可以分为5个部分： Smart Contract：资产托管的角色，保管以太坊中的代币和Cosmos中的代币。主要提供了lock、unlock、mint、burn四个方法。 Witness：是一个以太坊全节点，监听以太坊合约的event，并等待100个区块产生后，封装WitnessTx提交到PegZone中来证明在以太坊内状态更改。 PegZone：PegZone是基于Tendermint的区块链，负责维护用户的账户信息，允许用户之间资产的转移，并提供交易查询。 Signer：使用secp256k1对交易进行签名，以便签名能够高效的被智能合约验证，对应于智能合约的校验者公钥集合。 Relayer： 中继器负责交易转发。将所有Signer签名后的SignTx转发到smart contract中。 现状 跨链是Cosmos的重要特性，但在从目前的代码实现上感觉有些遗憾： IBC协议目前只完成了基本消息的传递功能，并没有安全校验、注册机制以及一些异常的处理。 PegZone机制处于暂停状态，机制设计上团队也称处于实验性质。 对于没有基于cosmos-sdk开发，但符合实时最终性的链无法使用IBC，无法做到异构链的兼容。它们可能使用不同的： 签名算法 序列化方法 Merkle证明的方式 总结 通过上下两篇文章，从架构，核心技术——Tendermint、跨链、源码以及现状等方面对Cosmos进行了详细介绍。整体来讲，Cosmos更偏向于一个区块链开发框架，让开发者可以只需要专注于自身业务而不需要考虑区块链底层技术实现，所以在架构设计上采用了灵巧的插件设计，开发者可以按需使用。 Cosmos跨链协议部分从代码上看，完成度还不太高，有些遗憾。并且设计上跨链交易都需要通过Cosmos Hub，这样会过于依赖Hub，对Hub本身的承载压力是个考验，目前其他的一些跨链实现方案也都需要依赖自身的一条链，都会存在这个问题。笔者觉得跨链未来会发展成标准化协议，就像TCP之于互联网，而不是依赖某条具体链，通过定义标准化的模块，通过路由将跨链交易转到目标链，目标链完成对原始链的校验后，确认交易合法性，并执行交易。设想示意图如下： 转载自：https://mp.weixin.qq.com/s?__biz=MzUyMjg0MzIxMA==&mid=2247483744&idx=1&sn=02baaff744429c37626dc89aed14988f&chksm=f9c4e445ceb36d53578bd8c22af2ea14023be0b787a4d980702ed0246a02a1229296e0fe53c1&scene=0