白皮书翻译：跨链双雄之一的分布式账本网络Cosmos

文白皮书来自Cosmos官方，原文地址：https://cosmos.network/resources/whitepaper

分布式账本网络

Jae [email protected]

Ethan [email protected]

讨论,join our community chat!

注意：如果您可以在GitHub上阅读此文档，那么我们仍在积极开发此文档。请定期查看更新！

1.介绍

开源生态系统、去中心化文件共享和公共加密货币的共同成功激发了人们的一种认识，即去中心化互联网协议可用于从根本上改善社会经济基础设施。我们已经看到了专门的区块链应用，如比特币[1]（加密货币）、大零币[2]（隐私加密货币）和以太坊[3]等通用智能合约平台，以及无数以太坊虚拟机（EVM）的去中心化应用，如Augur（预测市场）和TheDAO [4]（投资俱乐部）。

然而，到目前为止，这些区块链还存在许多缺陷，包括其总的能源效率低下、性能差或受限制以及治理机制不成熟。扩展比特币吞吐量的建议，如隔离见证[5]和BitcoinNG[6]，是纵向扩展解决方案，它们受单个物理机容量的限制，以确保完全可审核性。闪电网络[7]可以通过将一些事务完全脱离账本来帮助扩大比特币事务量，非常适合小额支付和隐私保护支付，但可能不适合更广泛的扩展需求。

理想的解决方案是允许多个平行链在保留安全性的同时进行互操作。使用工作量证明，这被证明是困难的，即使不是不可能的。例如，联合挖掘允许完成确保父链安全的工作，以便在子链上重用，但是仍然必须按顺序验证每个节点的事务，并且如果父链上的大多数哈希值功能没有主动联合挖矿子链，则联合挖矿的区块链易受攻击。另一方面，我们提供了对替代区块链网络架构的学术评论，并总结了其他建议及其在相关工作中的弊端。

在这里我们介绍Cosmos，一种解决所有这些问题的新型区块链网络架构。Cosmos是一个由许多独立区块链组成的网络，称为Zone。这些Zone由Tendermint BFT[8]驱动，它提供了一个高性能、一致、安全的PBFT式共识引擎，在这里，严格的分叉问责（fork-accountability）模式可以控制恶意参与者的行为。Tendermint BFT共识算法非常适合扩展公共权益证明区块链。

Cosmos的第一个Zone叫做Cosmos Hub。Cosmos Hub是一种具有简单的治理机制的多资产股权证明加密货币，从而促使网络能够适应和升级。此外，Cosmos Hub可以通过连接其他Zone来扩展。

Cosmos网络的Hub和Zone通过区块链间通信（IBC）协议（一种用于区块链的虚拟UDP或TCP）相互通信。代币可以安全快速地从一个Zone转移到另一个Zone，而无需在Zone之间交换流动性。相反，所有Zone间的代币传输都通过Cosmos Hub，Hub跟踪每个Zone持有的代币总数。将每个Zone与其他Zone的故障隔离开来。因为任何人都可以将一个新的Zone连接到Cosmos Hub，因此Zone允许未来与新的区块链创新兼容。

2.Tendermint

在这一节中，我们将描述Tendermint共识协议和用于构建应用的接口。相关详细信息，请参阅附录。

2.1验证器

在经典的拜占庭容错算法中，每个节点具有相同的权重。在Tendermint中，节点具有非负的投票权，具有正投票权的节点称为验证器。验证器通过广播加密签名或投票来参与共识协议，以就下一个区块达成协议。

验证程序的投票权在一开始就确定，或由区块链根据应用确定性地更改。例如，在Cosmos Hub等权益证明应用中，投票权可由作为抵押品的代币数量来确定。

注：像?和?这样的分数是指总投票权的比例，而不是验证器的总数，除非所有验证器的权重相等。>?表示“大于?”，大于等于?表示“至少?”。

2.2共识

Tendermint是一个部分同步的BFT共识协议，源于DLS共识算法[20]。Tendermint以其简单性、性能和分叉问责特性而闻名。协议需要一组固定的已知验证器，其中每个验证器由其公钥标识。验证器试图一次就一个区块达成共识，其中一个区块是事务列表。全面投票表决是否达成共识。每一轮都有一个提议区块的领导者或提议者。然后，验证器分阶段投票决定接受提议区块还是进入下一轮。从验证者的有序列表中确定投票的提议者，并与他们的投票权成正比。

这里将描述协议的全部细节。

Tendermint的安全性源于它通过超级多数（>?）投票和锁定机制使用最佳拜占庭容错。它们共同确保：

l ≥?投票权必须是拜占庭式的，否则超过两个值提交，会导致违反安全规定。

l 如果任何一组验证器成功地违反了安全性，甚至尝试这样做，都可以通过协议来识别。这包括对冲突区块的投票和广播不合理的投票。

在有强有力保证的同时，Tendermint还是提供了卓越的性能。在5大洲7个数据中心分布的64个节点的基准测试中，在商品云实例上，Tendermint 共识每秒可以处理数千个事务，提交延迟大约为1到2秒。值得注意的是，即使在恶劣的对抗条件下，在验证器崩溃或广播恶意制作投票的情况下，每秒仍能保持超过1000个事务的性能。详见下图。(官网图无法显示)。

2.3轻客户端

Tendermint的共识算法的一个主要优点是简化了轻客户端安全性，使其成为移动和物联网用例的理想候选。尽管比特币轻客户端必须同步块头的链并找到工作证明最多的块头，但是Tendermint轻客户端只需跟上验证器集的更改，然后验证最新区块中的>?预提交（PreCommits）即可确定最新状态。

简洁轻客户端证明也支持区块链间通信（inter-blockchain communication）。

2.4防止攻击

Tendermint有保护措施防止某些值得注意的攻击，如远程无风险双重支付和网络审查。这些在附录中将讨论得更充分。

2.5应用区块链接口（ABCI）

Tendermint共识算法在一个称为Tendermint Core的程序中实现。Tendermint BFT是一个与应用无关的“共识引擎”，可以将任何确定性的“黑盒”应用转变为一个分布式复制的区块链。Tendermint BFT通过应用区块链接口（ABCI）连接到区块链应用[17]。ABCI是定义复制引擎（区块链）和状态机（应用）之间边界的接口。通过使用socket协议，我们使在一个进程中运行的共识引擎能够管理在另一个进程中运行的应用状态。因此，ABCI允许区块链应用以任何语言编程，而不仅仅是共识引擎所用的编程语言。此外，ABCI使得可以很容易地交换出任何现有的区块链共识层。

我们用著名的加密货币比特币做了一个类比。比特币是一个加密货币区块链，每个节点都维护一个完全审计的未支出事务输出（UTXO）数据库。如果有人想在ABCI的基础上创建一个类似比特币的系统，Tendermint BFT将负责

l 节点间共享块和事务

l 建立规范/不变的交易顺序（区块链）

同时，ABCI应用将负责

l 维护UTXO数据库

l 验证交易的密码签名

l 阻止交易支出不存在的资金

l 允许客户查询UTXO数据库

Tendermint能够通过在应用流程和共识流程之间提供非常简单的API来分解区块链设计。

3.Cosmos概况

Cosmos是一个独立的并行区块链网络，每个区块链都由经典的BFT共识算法（如Tendermint 1）提供支持。

这个网络中的第一个区块链将是Cosmos Hub。Cosmos Hub通过一种新的区块链间通信协议连接到许多其他区块链（或Zone）。Cosmos Hub跟踪许多代币类型，并记录每个连接Zone中的代币总数。代币可以安全快速地从一个Zone转移到另一个Zone，而无需在Zone之间进行流动交换，因为所有Zone间的代币转移都要经过Cosmos Hub。

这种架构解决了区块链领域目前面临的许多问题，如应用互操作性、可扩展性和无缝升级性。例如，来自比特币、Go-以太坊、CryptoNote、ZCash或任何区块链系统的Zone可以以插件的形式连接Cosmos Hub。这些Zone允许Cosmos无限扩展以满足全局事务需求。Zone也非常适合分布式交易所，它也将得到支持。

Cosmos不仅仅是一个分布式账本，Cosmos Hub也不是一个封闭式花园或宇宙中心。我们正在设计一个开放的分布式分类网络协议，它可以根据密码学、健全经济学、共识理论、透明度和问责制等原则为未来的金融系统提供一个新的基础。

3.1TENDERMINT BFT

Cosmos Hub是Cosmos网络中的第一个公共区块链，由Tendermint BFT共识算法提供支持。Tendermint开源项目诞生于2014年，旨在解决比特币工作量证明共识算法的速度、可扩展性和环境问题。通过使用并改进麻省理工学院1988年【20】开发的经验证的BFT算法，Tendermint团队首次在概念上演示了一种权益证明的加密货币，它解决了第一代权益证明的加密货币（如NXT和BitShares1.0）所遇到的无利益关系问题。

如今，几乎所有的比特币移动钱包都使用可信服务器来提供交易验证。这是因为工作量证明需要等待许多确认，然后才能认为事务是不可逆转提交的。在CoinBase等服务上已经演示了双花攻击。

有别于其他区块链共识系统，Tendermint提供即时且可证明安全的移动客户端支付验证。由于Tendermint的设计宗旨是永远不使用分叉，移动钱包可以收到即时交易确认，这使得在智能手机上实现去信任、实用的支付成为现实。这对物联网应用也有重大影响。

Cosmos中的验证器具有与比特币矿工相似的角色，但它使用加密签名进行投票。验证器是负责提交区块的安全专用机器。非验证器可以将其权益代币（称为“atoms”）委托给任何验证器，以赚取一部分手续费和atom奖励，但如果委托验证器受到黑客攻击或违反协议，则它们将承担受到惩罚（大大降低）的风险。Tendermint BFT共识的经验证安全保证，以及利益相关者（验证人和委托人）的抵押品存款，为节点和轻型客户提供了可验证、可量化的安全保障。

3.2治理

分布式公共账本应该有一个宪法和一个治理体系。比特币依靠比特币基金会和挖矿来协调升级，但这是一个缓慢的过程。以太坊为解决TheDAO黑客攻击而进行的硬分叉为ETH和ETC等，主要是因为之前没有社会合约，也没有做出此类决定的机制。

Cosmos Hub上的验证者和授权者可以对自动更改系统预设参数（如区块链gas限制）、协调升级以及对Cosmos Hub治理政策的可读性章程修正案进行投票。章程允许利益相关者在盗窃和bug（TheDAO事件）等问题上团结一致，允许更快、更干净地解决问题。

每个Zone可以有自己的章程和治理机制。例如，Cosmos Hub可以有一个在Hub强制执行不变性的结构（没有回滚，除了Cosmos Hub节点实现的bug），而每个Zone可以设置自己的回滚策略。

通过在不同的策略Zone之间实现互操作性，Cosmos网络为用户提供了无许可实验的最终自由和潜力。

4.Hub与Zones

在这里，我们描述了一个新的去中心化和可扩展性模型。Cosmos是由Tendermint驱动的多个区块链组成的网络。虽然现有的提案旨在创建一个具有全局事务排序“单一区块链”，但COSMOS允许多个区块链在保持互操作性的同时并发运行。

在此基础上，Cosmos Hub管理许多称为“Zone”的独立区块链（有时被称为“分片”，参考被称为“分片”的数据库扩展技术）。来自发布在Hub上的Zone的最近块提交的恒定流允许Hub跟上每个Zone的状态。同样，每个Zone都与Hub的状态保持一致（但Zone之间不保持一致，除非通过Hub间接地保持一致）。然后，通过发布Merkle-证明作为信息发送和接收的证据，信息包从一个Zone传送到另一个Zone。这种机制称为区块链间通信（inter-blockchain communication），简称IBC。

任何Zone本身都可以是Hub以形成非循环图，但是为了清楚起见，我们将只描述只有一个Hub和多个非Hub的Zone的简单配置。

4.1HUB

Cosmos Hub是一个承载多资产分布式账本的区块链，其中的代币可以由单个用户持有，也可以由Zone自己持有。这些代币可以在一个称为“代币包”的特殊IBC包中从一个Zone移动到另一个Zone。Hub负责保持Zone内每个代币总量的全局不变性。IBC代币包事务必须由发送方、Hub和接收方区块链提交。

由于Cosmos Hub是整个系统的中心账本，因此Hub的安全性至关重要。虽然每个Zone可能是一个Tendermint区块链，其安全性可低至4个（如果不需要BFT共识，则更少），但Hub必须由一组全局去中心化的验证器保护，这些验证器能够承受最严重的攻击场景，如大陆网络分区或国家支持的攻击。

4.2Zones

Cosmos Zone是一个独立的区块链，它与Hub交换IBC消息。从Hub的角度来看，Zone是一个多资产动态成员多重签名账户，可以使用IBC数据包发送和接收令牌。与加密货币账户一样，Zone无法传输比其拥有更多的代币，但可以从拥有代币的其他人那里接收代币。可以将Zone指定为一个或多个代币类型的“源”，从而授予它扩大代币供应的权力。

Cosmos Hub的atom可以由连接到Hub的Zone的验证器进行质押。尽管对这些Zone的双花攻击将导致Tendermint的分叉责任削减atom，一个投票权>?的拜占庭Zone可能提交无效状态。Cosmos Hub不验证或执行在其他Zone上提交的事务，因此用户有责任将代币发送到他们信任的Zone。未来，Cosmos Hub的治理系统可能会通过考虑到Zone故障的Hub改进建议。例如，可以限制来自某些（或所有）Zone的出站代币传输，以便在检测到攻击时允许Zone的紧急电路断开（代币传输的临时停止）。

5.区块链间通信（IBC）

现在我们来看看Hub和Zone是如何相互通信的。例如，如果有三个区块链，“Zone1”、“Zone2”和“Hub”，我们希望“Zone1”生成一个通过“Hub”到达“Zone2”的数据包。要将数据包从一个区块链移动到另一个区块链，需要在接收链上提交证明。证据表明，发送链发布了所谓目的地的数据包。为了让接收链检查这个证明，它必须能够跟上发送方的区块头。该机制类似于侧链所使用的机制，侧链需要两个相互作用的链通过双向数据流证明彼此之间的数据流（事务）。

IBC协议可以自然地使用两种类型的事务来定义：IBCBlockCommitTx事务，它允许区块链向任何观察者证明其最新的区块哈希；IBCPacketTx事务，它允许区块链向任何观察者证明给定的包确实是由发送者的应用发布的，通过Merkle-证明到最近的区块哈希。

通过将IBC机制分为两个单独的事务，我们允许接收链的本地费用市场机制来确定哪些数据包被提交（即确认），同时在发送链上完全自由地允许允许多少个出站数据包 。

在上面的示例中，为了更新“Hub”上“Zone1”的区块哈希（或“Zone2”上“Hub”的区块哈希），IBCBlockCommitTx事务必须以“Zone1”的区块哈希（或以“Hub”的区块哈希）发布在“Hub”上。

有关两种IBC事务类型的更多信息，请参阅IBCBlockCommitTx和IBCPacketTx。

6.用例

6.1分布式交易所

正如比特币作为一种分布式、大规模复制的账本更安全一样，我们可以通过在区块链上运行比特币，使交易所不易受到外部和内部黑客的攻击。我们称之为分布式交易所。

当前，加密货币社区所称的去中心化交易所是基于所谓的“原子跨链”（AXC）交易。使用AXC交易，两个不同链上的两个用户可以进行两个在两个账本上一起提交的转移交易，或者根本不提交（即原子的）。例如，即使比特币和以太坊没有连接，两个用户也可以使用AXC交易用比特币交换以太币（或两个不同账本上的任意两个代币）。在AXC事务上运行交易的好处是，两个用户都不需要相互信任或交易匹配服务。缺点是双方都需要在线才能进行交易。

另一种去中心化交易所是在自己的区块链上运行的大规模复制分布式交易所。这类交易所的用户可以提交一个限价单并关闭计算机，交易可以在用户不在线的情况下执行。区块链代表交易员匹配并完成交易。

中心化交易所可以创建限价订单的深度订单簿，从而吸引更多的交易者。流动性在交易所产生了更多的流动性，因此在交易所业务中存在着强大的网络效应（或至少以赢家为主导的效应）。目前，加密货币交易所的领头羊是24小时交易量为2000万美元的Poloniex，其次是24小时交易量为500万美元的Bitfinex。鉴于如此强大的网络效应，基于AXC的去中心化交易所不太可能赢得中心化交易所的交易量。为了使去中心化交易所与中心化交易所竞争，它需要支持具有限价订单的深层订单。只有区块链上的分布式交易所才能提供这种服务。

Tendermint提供了更快的事务提交的其他好处。通过在不牺牲共识的情况下优先考虑快速终结性，Cosmos中的Zone可以快速完成事务，包括交换订单事务以及IBC代币在其他Zone之间的传输。

考虑到当今加密货币交易所的现状，Cosmos的一个重要应用是分布式交易所（又称Cosmos-DEX）。事务吞吐量和提交延迟可以与中心化交易所媲美。交易者可以提交限价单，无需双方在线即可执行。有了Tendermint、Cosmos hub和IBC，交易者可以快速地将资金从交易所进出其他Zone。

6.2连接到其他加密货币

特权Zone可以充当其他加密货币的桥接代币的来源。桥接类似于Cosmos Hub和Zone之间的关系；两者都必须跟上另一个Hub的最新区块，以便验证代币已从一个移动到另一个的证据。Cosmos网络上的“bridge-zone”与Hub和其他加密货币保持同步。通过bridge-zone的间接访问使Hub的逻辑保持简单，并且与其他区块链共识策略无关（如比特币的工作量证明挖矿）。

6.2.1向Cosmos Hub发送代币

每个bridge-zone验证器都将运行一个Tendermint驱动的区块链，其中包含一个特殊的ABCI网桥应用，但也包含一个完整的“创世”区块链节点。

当在创世区块上挖掘新块时，bridge-zone验证器将通过签署和共享各自的创世区块链提示的本地视图来就提交的区块达成一致。当bridge-zone收到来源的付款（并且在以太坊或比特币等PoW链的情况下，已达成足够的确认）时，将在bridge-zone上创建一个具有该余额的对应账户。

在以太坊的情况下，bridge-zone可以共享与Cosmos Hub相同的验证器集。在以太坊方面（创世区块），网桥合约允许以太坊持有者通过将以太坊发送到以太坊上的网桥合约来将以太坊发送到bridge-zone。一旦网桥合约接收到以太坊，除非网桥合约从bridge-zone接收到适当的IBC包，否则以太坊不能被撤回。网桥合约跟踪bridge-zone的验证器集，该验证器集可能与Cosmos Hub的验证器集相同。

在比特币的情况下，这一概念是相似的，除了不是一个单一的网桥合约，每个UTXO将由一个阈值多签名P2SH 公共脚本控制。由于P2SH系统的限制，签名者不能与Cosmos Hub验证器集相同。

6.2.2从Cosmos Hub中提币

bridge-zone上的以太坊（“桥接以太坊”）可以通过Hub传输，然后通过将其发送到以太坊上的特定取款地址的事务来销毁。IBC数据包证明在bridge-zone上发生的事务可以发布到以太坊网桥合约，以允许以太坊被提取。

在比特币的情况下，受限的脚本系统使得很难镜像IBC代币传输机制。每个UTXO都有自己独立的发布脚本，因此当比特币托管签名者集合发生更改时，必须将每个UTXO迁移到新的UTXO。一种解决方案是根据需要压缩和解压缩UTXO集，以减少UTXO的总数。

6.2.3桥接Zone全面责任制

这种桥接合约的风险是一个流氓验证器集。≥?拜占庭投票权可以导致一个分叉，从以太坊的桥接合约中提取以太坊，同时将桥接以太坊保留在bridge-zone。更糟糕的是>?拜占庭的投票权可以通过偏离bridge-zone最初的桥接逻辑，直接从那些将其发送到桥接合约的人那里窃取以太坊。

通过设计完全负责的桥梁可以解决这些问题。例如，来自Hub和源站的所有IBC数据包可能需要由bridge-zone确认，以便可以通过Hub或源站的桥接合约有效地挑战和验证bridge-zone的所有状态转换。Hub和源站应允许bridge-zone验证器发布抵押品，并且应延迟将代币从桥牌合约中转移出去（并且抵押品的无担保期限足够长），以允许独立审核员提出任何挑战。作为Cosmos未来的实现建议，我们将开放该系统的规范设计和实现，以供Cosmos Hub的治理系统通过。

6.3以太坊扩展

解决可扩展问题是以太坊的一个开放性问题。目前，以太坊节点处理每一个事务，并存储所有状态。链接。

由于Tendermint可以比以太坊的工作量证明更快地提交块，因此由Tendermint 智能合约驱动并在桥接以太上运行的虚拟机Zone可以为以太坊区块链提供更高的性能。此外，虽然COSMOS Hub和IBC分组机制本身不允许任意的合约逻辑执行，但它可以用于协调在不同Zone上运行的以太坊合约之间的代币移动，从而通过分片为以代币为中心的以太坊扩展提供基础。

6.4多应用集成

Cosmos Zone运行任意的应用逻辑，该逻辑在Zone生命开始时定义，并可能随着时间的推移由治理进行更新。这样的灵活性允许COSMOS Zone充当与其他加密货币（如以太坊或比特币）的桥梁，并且还允许使用相同的代码库但具有不同的验证器集和初始分布的那些区块链衍生产品。这使得许多现有的加密服务框架，如以太坊、大零币、比特币、CryptoNote等，与Tendermint BFT一起使用，后者是一种在共同网络上的更高性能的共识引擎，为跨平台的互操作性打开了巨大的机会。此外，作为一个多资产区块链，一个事务可能包含多个输入和输出，其中每个输入可以是任何代币类型，从而使Cosmos能够直接充当去中心化交易的平台，尽管假设订单通过其他平台匹配的。或者，Zone可以作为分布式容错交易所（带有订单簿），这可以是对现有随着时间的推移而被黑客攻击的中心化加密货币交易所的严格改进。

Zone还可以用作企业和政府系统支持的区块链版本，其中传统上由一个组织或一组组织运行的特定服务的某些部分在某个Zone上作为ABCI应用运行，从而允许其继承公共Cosmos网络的安全性和互操作性，而不牺牲对底层服务的控制。因此，对于希望利用区块链技术但对将控制权完全放弃给分布式第三方的组织而言，Cosmos可能提供两全其美的选择。

6.5网络分区缓解

有人声称，像Tendermint这样的有利于抑制性的共识算法的一个主要问题是，任何导致没有投票权大于?的单个分区的网络分区（例如≥?脱机）都将完全停止共识。Cosmos体系结构可以通过使用带有Zone自治区的全局hub来帮助缓解这个问题，每个Zone的投票权都是基于一个公共地理区域来分配的。例如，一个通用的范例可能是，个别城市或地区在共享一个公共hub（如Cosmos hub）的同时经营自己的Zone，使市政活动能够在hub因临时网络分区而停止的情况下持续开展。注意，这允许在设计健壮的联邦容错系统时考虑实际的地理、政治和网络拓扑特征。

6.6联邦式名称解析系统

NameCoin是首批尝试通过调整比特币区块链来解决名称解析问题的区块链之一。不幸的是，这种方法有几个问题。

使用Namecoin，我们可以验证@satoshi是否在过去某个时间注册了某个特定的公钥，但是我们不知道该公钥是否最近更新过，除非我们下载了该名称上次更新后的所有块。这是由于比特币的UTXO事务Merkle化模型的局限性，该模型只将事务（但不可变的应用状态）Merkle化为块哈希。这使我们能够证明存在，但不能证明不存在以后对名称的更新。因此，如果不信任一个全节点，或者通过下载整个区块链而在带宽上产生重大成本，我们就无法确定名称的最新值。

即使一个Merkle化的搜索树是用NameCoin实现的，它对工作量证明的依赖性也会使轻量级客户端验证成为问题。轻客户端必须下载整个区块链中所有区块的区块头的完整副本（或者至少是自上次更新名称以来的所有区块头）。这意味着带宽需求与时间量成线性关系[21]。此外，工作量证明区块链上的名称更改需要等待额外的工作量证明确认块，这在比特币上可能需要一个小时。

对于Tendermint，我们只需要由验证器的法定人数（通过投票权）签署的最新块哈希，以及与名称相关联的当前值的Merkle证明。这使得对名称值进行简洁、快速和安全的轻型客户端验证成为可能。

在Cosmos中，我们可以把这个概念进一步扩展。Cosmos中的每个名称注册Zone都可以有一个相关联的顶级域（TLD）名称，如“.com”或“.org”，每个名称注册Zone都可以有自己的管理和注册规则。

7.发行和激励

7.1ATOM代币

虽然Cosmos Hub是一个多资产分布式账本，但有一个特殊的原生代币称为atom。atom是Cosmos Hub唯一的代币。atom是持有者投票、验证或委托给其他验证者的许可证。像以太坊的以太币一样，atom也可以用来支付交易手续费以减少垃圾邮件。额外的通胀atom和区块交易手续费将奖励给委托给验证者的验证者和委托者。

BurnAtomTx事务可用于从储备池中恢复任意比例数量的代币。

7.1.1资金募集

创世区块上atom代币和验证器的初始分配将分配给Cosmos筹款者（75%）、主要捐赠者（5%）、Cosmos网络基金会（10%）和ALL IN BITS有限公司（10%）。从创世区块开始，每年将向绑定的验证者和委托者奖励atom总数的1/3。

更多细节见Cosmos 计划。

7.2验证器数量限制

与比特币或其他工作量证明区块链不同，由于通信复杂性的增加，Tendermint链随着验证器增加变得越来越慢。幸运的是，我们可以支持足够多的验证器，以创建一个具有非常快的事务确认时间的健壮的全球分布区块链，并且，随着带宽、存储和并行计算容量的增加，我们将来将能够支持更多的验证器。

在创世日，最大数量的验证器将被设置为100，并且这个数字将以13%的速率增长10年，最终达到300个验证器。

第0年: 100

第1年: 113

第2年: 127

第3年: 144

第4年: 163

第5年: 184

第6年: 208

第7年: 235

第8年: 265

第9年: 300

第10年: 300

...

7.3在创世日之后成为一个验证器

尚未成为验证器的Atom持有者可以通过签署和提交BondTx事务来成为验证器。作为抵押品提供的Atom数量必须为非零。任何人都可以在任何时候成为一个验证器，除非当前验证器集的大小大于允许的最大验证数。在这种情况下，只有当Atom数量大于最小验证器持有的有效Atom数量时，事务才有效，其中有效Atom包括委托Atom。当一个新的验证器以这样的方式替换现有的验证器时，现有的验证器变成非活动状态，所有的Atom和委托的Atom进入解除绑定状态。

7.4验证器惩罚

对于任何有意或无意偏离批准的协议的行为，必须对验证器处以一定的惩罚。一些证据是可以立即接受的，例如在同一高度和轮次的重复签名，或违反“预投票锁（prevote-the-lock）”（Tendermint共识协议的规则）。这些证据将导致验证器失去良好的信誉，其关联的Atom以及在储备池中按比例分配的代币（统称为“股份”）将被大幅削减。

有时，由于Zone网络中断、电源故障或其他原因，验证器将不可用。如果在过去的验证器超时窗口（ValidatorTimeoutWindow）块中的任何时候，验证器的提交投票未包含在区块链中超过验证器超时最大缺席时间（ValidatorTimeoutMaxAbsenttimes），则该验证器将变为非活动状态，并失去验证超时惩罚（ValidatorTimeoutPenalty）（默认1%）的股份。

一些“恶意”行为并不能在区块链上产生明显可识别的证据。在这些情况下，如果存在多数共识，验证器可以进行带外协调以强制这些恶意验证器超时。

在Cosmos Hub因≥?的投票权联盟脱机而停止的情况下，或在≥?投票权的审查员审查有恶意行为进入区块链的证据的情况下，hub必须通过硬分叉重组来恢复 -提案。（查阅“分叉和审查攻击”）。

7.5交易手续费

CosmosHub验证器可以接受任何代币类型或类型组合作为处理事务的费用。每个验证器可以主观地设置它想要的任何汇率，并选择它想要的任何事务，只要不超过区块gas限制。收取的手续费，减去下文规定的任何税款，将在每个验证器付款期（默认为1小时）按照其绑定的ATOM比例重新分配给权益持有人。

在收取的交易手续费中，储备税（默认为2%）将流向储备池，以增加储备池并提高Cosmos网络的安全性和价值。这些资金也可以根据治理系统作出的决定进行分配。

将其投票权委托给其他验证器的ATOM持有者向委托验证器支付佣金。佣金可以由每个验证器设定。

7.6激励黑客

Cosmos Hub的安全性是底层验证器的安全性和委托者选择委托的功能。为了鼓励发现和早期报告已发现的漏洞，Cosmos Hub鼓励黑客通过ReportHackTx事务发布成功的漏洞利用程序，其中说：“此验证器被黑客入侵，请向该地址发送赏金”。利用此漏洞后，验证器和委托者将变成无效的，每个ATOM的黑客惩罚比率（默认值为5%）将被削减，每个ATOM的黑客奖励比率（默认值为5%）将被奖励到黑客的悬赏地址。验证器必须使用其备份密钥来恢复剩余的ATOM。

为了防止滥用此功能来传输未授权ATOM，验证器和委托者在ReportHackTx之前和之后的已授权ATOM与未授权ATOM的部分将保持不变，并且黑客奖励将包括一些未授权ATOM（如果有的话）。

7.7治理规范

Cosmos Hub由一个分布式组织运营，该组织需要一个定义明确的治理机制，以便协调区块链的各种变化，例如系统的可变参数，以及软件升级和宪法修正。

所有验证者都有责任对所有提案进行投票。如果未能及时对提案进行投票，将导致验证器在一段时间内自动停用，该期间称为“缺席处罚期”（默认为1周）。

委托人自动继承委托验证器的投票权。此投票可能被手动覆盖。未绑定的ATOM没有投票权。

每个提议都需要存放一个MinimumProposalDeposit（最低保证金）代币，它可以是一个或多个代币（包括ATOM）的组合。对于每个提议，选民可以投票决定支付保证金。如果超过一半的选民选择接受该存款（例如，因为提案是垃圾邮件），除了被销毁的ATOM其他存币将进入储备池，。

对于每一项提案，选民可以选择下列方式投票：

l 同意

l 强烈同意

l 反对

l 强烈反对

l 弃权

提案通过（或失败）时，必须获得赞成票或强烈赞成票（或反对票或强烈反对票）的绝对多数，但1/3+的人可以“强制投票”投票否决多数决定。但是有1/3 +的成员可以通过“强制投票”来否决多数票。 当严格的否决权被否决时，每个人都将因失去价值相当于价值的费用的VetoPenaltyFeeBlocks（默认为1天的区块价值）（不受影响的税收除外）而受到惩罚，而否决多数票的当事方也将受到损失他的Atom的VetoPenaltyAtoms（默认为0.1%）惩罚。

7.8参数变更建议

这里定义的任何参数都可以随参数修改建议（ParameterChangeProposal）的传递而更改。

7.9悬赏提议

ATOM是通涨模式的，储备池资金随着赏金提议（BountyProposal）的通过而花费。

7.10文本建议

所有其他建议，如升级协议的建议，将通过通用文本建议（TextProposal）进行协调。

8.路线图

参见计划。

9.相关工作

在过去的几年里，在区块链共识和可扩展性方面有很多创新。本节简要概述了一些重要的因素。

9.1共识体系

9.1.1经典拜占庭容错

在恶意参与者面前达成共识是一个问题，可追溯到20世纪80年代初，当时莱斯利·兰波特（Leslie Lamport）创造了“拜占庭容错”一词，指偏离预期行为的任意过程行为，而“崩溃故障”则指一个过程简单地崩溃。早期的解决方案是为同步网络发现的，在同步网络中，消息延迟有一个上限，但实际应用仅限于高度受控的环境，如通过原子钟同步的飞机控制器和数据中心。直到90年代末，才引入了实用的拜占庭容错算法（PBFT）[11]，作为一种有效的部分同步共识算法，该算法能够容忍任意行为的1/3进程。PBFT成为标准算法，产生了许多变体，包括IBM最近创建的一个变体，作为其对超级账本贡献的一部分。

Tendermint共识优于PBFT的主要好处是Tendermint有一个改进和简化的底层结构，其中一些是采用区块链范式的结果。Tendermint区块必须按顺序提交，从而避免了与PBFT视图改变相关联的复杂性和通信开销。在Cosmos和许多加密货币中，当区块N本身尚未提交时，不需要允许i>=1的区块N+i提交。如果带宽是区块N没有提交到Cosmos Zone的原因，则对区块N+i使用带宽共享投票是无济于事的。如果网络分区或离线节点是区块N没有提交的原因，则N+i无论如何都不会提交。

此外，将事务批处理成块允许对应用状态进行定期的Merkle哈希，而不是像PBFT的检查点方案那样进行定期摘要。这可以为轻客户端提供更快的可验证事务提交和更快的区块链间通信。

Tendermint BFT还包括许多超出PBFT中指定范围的优化和功能。例如，由验证器提出的区块被分成若干部分，并进行Merkle化处理，然后以提高广播性能的方式闲聊（有关启发，参见LibSwift[19]）。而且，只要P2P网络是弱连通的，Tendermint BFT就不会对点对点连接做任何假设，并且可以正常工作。

9.1.2比特股权益证明

虽然BitShares1.0[12]不是第一个部署权益证明（PoS）的公司，但它为PoS区块链的研究和采用做出了巨大贡献，特别是那些在BitShares中被称为“委托”的PoS。在BitShares中，权益持有人选择“见证人”，负责订购和提交事务，以及“委托人”，负责协调软件更新和参数更改。BitShares2.0的目标是在理想的条件下实现高性能（100k tx/s，1s延迟），每个区块都由一个签名者签名，事务结束时间比区块间隔长很多。规范仍在开发中。权益持有人可以每天删除或替换行为不当的见证人，但是没有见证人或代表的大量抵押品，就像Tendermint PoS一样，在成功进行两次花钱攻击的情况下，它们会遭到削减。

9.1.3恒星币

在瑞波开创的方法的基础上，恒星币[13]改进了联邦拜占庭协议的模型，其中参与共识的过程不构成固定的和全局已知的集合。相反，每个进程节点管理一个或多个“quorum slices”，每个组成一组受信任的进程。恒星币中的“quorum”定义为一组节点，其中每个节点至少包含一个quorum slices，这样就可以达成一致。

恒星机制的安全性依赖于假设：任意两个仲裁的交集都是非空的，而一个节点的可用性要求其仲裁切片中的至少一个要完全由正确的节点组成，因此在使用之间需要权衡如果不对信任施加重要假设，则可能很难平衡大小的法定人数。最终，节点必须以某种方式选择足够的仲裁切片, 以具有足够的容错能力（或根本没有“完整的节点”，而本文中的大部分结果都取决于这些完整性），并且是确保这种配置的唯一提供策略是分层的，类似于边界网关协议（BGP），它由Internet上的顶级ISP用来建立全局路由表，并且被浏览器用来管理TLS证书。都因他们的不安全而臭名昭著。

本文所述的代币策略减轻了恒星论文中对基于Tendermint的权益证明系统的批评，其中发行了一种称为atom的新型代币，代表对费用和奖励的未来部分的主张。因此，基于Tendermint的权益证明的优点是相对简单，同时仍可提供足够且可证明的安全保证。

9.1.4BitcoinNG

BitcoinNG是对比特币的一种改进，它将允许纵向可扩展性的形式，例如增加块大小，而不会产生通常与这种变化相关的负面经济后果，例如对小矿商的巨大影响。通过将领导者选举与交易广播分开来实现这一改进：首先通过工作量证明在“微区块”中选举领导者，然后能够广播要提交的事务，直到找到新的微区块。这减少了赢得工作量证明竞赛所需的带宽需求，允许小矿商更公平地竞争，并允许最后一个矿工更定期地进行交易以找到微区块。

9.1.5Casper

Casper[16]是针对以太坊提出的一种权益证明共识算法。它的主要运作模式是“投注共识”。通过让验证者根据他们迄今为止所看到的其他赌注来迭代押注他们认为将在区块链中投入的区块，最终可以实现最终性。链接。这是Casper团队的活跃研究领域。挑战在于构建一个可以证明是进化稳定策略的投注机制。与Tendermint相比，Casper的主要好处可能是提供“共识之上的可用性”——共识不需要一个>?表决权的法定人数——也许以牺牲速度或实现复杂性为代价。

9.2横向扩展

9.2.1Interledger协议

Interledger协议[14]并不是一个严格意义上的可扩展性解决方案。它通过一个松耦合的双边关系网络，在不同的账本系统之间提供一个特别的互操作。与闪电网络一样，ILP的目的是促进支付，但它特别关注不同账本类型的支付，并扩展了原子交易机制，不仅包括哈希锁，还包括公证人的法定人数（称为原子传输协议）。后一种在账本间交易中实施原子性的机制类似于Tendermint的轻客户端SPV机制，因此有必要举例说明ILP和Cosmos/IBC之间的区别，如下所述。

1、ILP中的连接器的公证员不支持成员资格变更，不允许公证人之间的灵活加权。另一方面，IBC是专门为区块链设计的，在区块链中，验证器可以具有不同的权重，并且成员资格可以在区块链的过程中发生变化。

2.与闪电网络一样，ILP中的付款接收者必须在线才能向发送者发送确认。在IBC上的代币传输中，接收方区块链的验证器集负责提供确认，而不是接收用户。

3.最显著的区别是，ILP的连接器不负责或保持有关支付的权威状态，而在Cosmos中，Hub的验证器是IBC代币传输状态的授权以及每个Zone持有的代币数量的授权（但不是Zone内每个账户持有的代币数量）。这是允许从Zone到Zone的代币安全非对称传输的根本创新；在Cosmos中的模拟到ILP的连接器是一个持久且最大安全的区块链账本，即Cosmos Hub。

4.ILP中的账本间付款需要有外汇订单簿作为支持，因为没有从一个账本到另一个账本的不对称代币转移，只有价值或市场等价物的转移。

9.2.2侧链

侧链[15]是一种提议的机制，用于通过与比特币区块链“双向楔入”的替代区块链来扩展比特币网络。（双向楔入相当于桥接。在Cosmos中，我们称之为“桥接”，以区别于市场铆钉）。侧链允许比特币有效地从比特币区块链移动到侧链并返回，并允许在侧链上的新功能中进行实验。与Cosmos Hub一样，侧链和比特币互为轻客户端，使用SPV证明来确定何时应将代币转移到侧链并返回。当然，由于比特币使用工作量证明，以比特币为中心的侧链面临着工作量证明作为共识机制的诸多问题和风险。此外，这是一个比特币最大化解决方案，它不象Cosmos一样支持各种代币和Zone间网络拓扑。也就是说，双向楔入的核心机制原则上与Cosmos网络所采用的机制相同。

9.2.3以太坊可扩展性工作

以太坊目前正在研究一些不同的策略，以分片以太坊区块链的状态，以满足可扩展性需求。这些工作的目标是在共享状态空间中维护当前以太坊虚拟机提供的抽象层。目前正在进行多项研究工作。[18] [22]

9.2.4Cosmos与以太坊2.0 Mauve比较

Cosmos和以太坊2.0 Mauve[22]有不同的设计目标。

l Cosmos是关于代币的。Mauve是关于扩展通用计算的。

l Cosmos没有绑定到EVM，因此即使是不同的虚拟机也可以互操作。

l Cosmos允许Zone创建者确定谁验证Zone。

l 任何人都可以在Cosmos中建立一个新的Zone（除非治理层另有决定）。

l Hub隔离Zone故障，以便保留全局代币不变量。

9.3常规扩展

9.3.1闪电网络

闪电网络是一个提议的代币传输网络，在比特币区块链（和其他公共区块链）之上的一层运行，通过将共识账本之外的大多数事务转移到所谓的“支付渠道”中，可以提高许多数量级的事务吞吐量。这是通过链上加密货币脚本实现的，该脚本使各方能够签订双边有状态合约，其中状态可以通过共享数字签名进行更新，合约可以通过最终在区块链上发布证据来结束，该机制首先被跨链原子交换推广。通过与多方开放支付渠道，闪电网络的参与者可以成为路由他人支付的焦点，从而形成一个完全连接的支付渠道网络，代价是资金被捆绑在支付渠道上。

虽然闪电网络还可以很容易地跨越多个独立的区块链进行扩展，以允许通过交易所市场进行价值转移，但它不能用于将代币从一个区块链非对称地转移到另一个区块链。而Cosmos网络的主要优点是能够实现这样的直接代币传输。也就是说，出于节约成本和隐私的考虑，我们希望支付渠道和闪电网络与我们的代币传输机制一起被广泛采用。

9.3.2隔离见证

隔离见证是一种比特币改进建议链接，旨在提高每块事务吞吐量2倍或3倍，同时使新节点的区块同步速度更快。这一解决方案的优点在于，它在比特币当前协议的限制范围内如何工作，并允许软分叉升级（即具有较旧版本软件的客户端将在升级后继续运行）。Tendermint作为一种新的协议，没有设计限制，因此它具有不同的扩展优先级。最初，Tendermint使用基于加密签名的BFT循环算法，而不是挖矿，后者允许通过多个平行链进行横向扩展，而常规的、更频繁的区块提交也允许纵向扩展。

10.附录

10.1分叉责任

一个设计良好的共识协议应该在超过容量限制和共识失败的情况下提供一些保证。这在经济体系中尤其必要，因为拜占庭式的行为可以获得可观的经济回报。最重要的这种保障是一种分叉问责形式，即导致共识失败的过程（即导致协议客户端接受不同的价值——分叉）可以根据协议的规则，或可能的法律制度加以确定和惩罚。当法律体系不可靠或调用成本过高时，验证器可能会被迫缴纳保证金以便参与，当检测到恶意行为时，这些存币可能会被撤销或削减[10]。

注意，这与比特币不同，在比特币中，由于网络异步和查找部分哈希冲突的概率性，分叉是经常发生的。在许多情况下，由于异步性，恶意分叉与分叉无法区分，比特币无法可靠地实现分叉问责，除了矿工为挖掘孤立区块而支付的隐性机会成本。

10.2TENDERMINT共识

我们将投票阶段称为预投票和预提交。投票可以是针对某一特定区块也可以是空值。对于同一轮中的一个区块，我们称之为一个>?预投票的集合为Polka，对于同一轮中的一个块，我们称之为一个>?与提交的集合为提交。如果>?预提交在同一轮中为空值，则移到下一轮。

请注意，协议中的严格确定性会导致弱同步假设，因为必须检测并跳过错误的引导。因此，验证器在预先声明空值之前等待一定的时间超时假设，并且超时假设的值随着每一轮的增加而增加。在一轮的剩余时间里，进程是完全异步的，在这个过程中，只有当验证器从网络的>?处获得消息时，进程才会进行。在实践中，需要一个非常强大的对手无限期地挫败弱同步性假设（导致共识失败无法提交至区块），并且通过在每个验证器上使用超时假设的随机值可以使这样做变得更加困难。

另外一组约束或锁定规则确保网络最终在每个高度仅提交一个区块。可以识别任何恶意尝试导致在给定高度提交多个区块。首先，一个区块的预提交必须有正当理由，以Polka的形式。如果验证器已经在第R_1轮预提交了一个区块，我们说它们被锁定在该区块上，并且用于证明第R_ 2轮新预提交的R_Polka必须在R_1< R_Polka<= R_2的R_Polka中出现。其次，验证器必须提出和/或预先声明它们锁定的区块。总之，这些条件确保验证器在没有足够证据作为理由的情况下不会预提交，并且已经预提交的验证器不能为预提交其他内容提供证据。这确保了共识算法的安全性和活跃性。

协议的全部细节在这里描述。

10.3TENDERMINT轻客户端

在一个替代链（分叉）的存在下，意味着对所有块头的同步需要被消除。当然，由于削减需要某些人共享分叉的证据，所以轻客户端应该存储它所见的任何区块哈希提交。此外，轻客户端可以定期与验证程序集的更改保持同步，以避免远程攻击（但也可以使用其他解决方案）。

在以太坊类似，Tendermint使应用能够在每个块中嵌入全局Merkle根哈希，允许根据账户的平衡、存储在合约中的值或存在未使用的事务输出等容易验证的状态查询，这取决于应用的性质。

10.4防止远程攻击

假设广播网络和静态验证器集的集合具有足够的弹性，则可以检测到区块链中的任何分叉，并削减违规验证器的存币。V神（Vitalik Buterin）在2014年初首次提出这一创新，解决了其他权益证明的加密货币（见相关工作）的无利害关系问题。但是，由于验证程序集必须能够更改，在很长一段时间内，原始验证者可能会全部取消绑定，因此可以自由地从创世区块创建新链，因为它们不再锁定存币，因此不产生任何成本。这种攻击被称为远程攻击（LRA），与短程攻击不同，当前绑定的验证器会导致分叉，因此会受到惩罚（假设分叉负责的BFT算法如Tendermint共识）。远程攻击通常被认为是对权益证明的重大打击。

幸运的是，LRA可以通过以下方法减轻。首先，要使验证器解除绑定（从而收回其抵押品存币，并且不再赚取费用以参与共识），必须使该存币在称为“解除绑定期”的时间段内不可交易，该时间段可以是几周或几个月。其次，为了确保轻客户端的安全，它在第一次连接到网络时，必须针对可信源（最好是多个源）验证最近的区块哈希。这种情况有时被称为“弱主观性”。最后，为了保持安全，它必须与最新的验证器集同步，同步频率至少与解除绑定周期的长度相同。这确保了轻客户端在验证器的资金未绑定之前知道验证器集的更改，因此不再处于危险之中，这将允许它通过在绑定的高度创建新的区块（假设它控制足够多的早期私钥）来执行远程攻击来欺骗客户。

注意，以这种方式克服LRA需要对工作量证明的原始安全模型进行彻底检查。在工作量证明中，假设一个轻客户端可以在任何时候通过简单地处理每个区块头中的工作量证明，从受信任的创世区块同步到当前高度。然而，为了克服LRA，我们需要一个轻客户端以一定的规律性联机来跟踪验证器集中的更改，并且在它们第一次联机时，它们必须特别小心地将从网络中获得的内容与可信来源进行身份验证。当然，后一种要求类似于比特币，在比特币中，协议和软件也必须从可信来源获得。

上述防止LRA的方法非常适合于Tendermint驱动的区块链的验证器和全节点，因为这些节点将保持与网络的连接。该方法也适用于希望经常与网络同步的轻客户端。然而，对于不希望频繁访问互联网或区块链网络的轻客户端，还可以使用另一种解决方案来克服LRA。非验证器代币持有者可以将其代币作为抵押品过账，其未绑定期非常长（例如，比验证器的未绑定期长得多），并为轻客户端提供第二种方法来证明当前和过去区块哈希的有效性。虽然这些代币不算区块链共识的安全性，但它们可以为轻客户端提供强有力的保障。如果以太坊支持历史区块哈希查询，任何人都可以将其代币绑定到一个专门设计的智能合约中，并提供支付认证服务，有效地为轻客户端LRA安全创造了市场。

10.5克服分叉和审查攻击

根据区块提交的定义，任何≥?的投票权联盟都可以通过离线或不广播投票来停止区块链。这样的联盟还可以通过拒绝包含这些事务的区块来审查特定事务，尽管这将导致很大一部分区块提议被拒绝，这将减慢区块链的区块提交速率，降低其效用和价值。恶意联盟也可能会以涓涓细流的方式广播投票，以使区块链提交几乎停止，或参与这些攻击的任何组合。最后，它可以通过双重签名或违反锁定规则，导致区块链分叉。

如果一个全局活跃的对手也参与进来，它可能会以这样一种方式划分网络，使其看起来可能是错误的验证器子集导致了速度的减慢。这不仅仅是Tendermint的一个限制，而是对其网络可能由活动对手控制的所有共识协议的限制。

对于这些类型的攻击，验证器的一个子集应通过外部手段进行协调，以签署一个选择分叉（及其任何证据）的重组建议，以及验证器的初始子集及其签名。签署这样一个重组建议的验证者放弃他们在所有其他分叉上的抵押品。客户应核实重组建议上的签名，核实任何证据，并作出判断或提示最终用户作出决定。例如，手机钱包应用可能会向用户发出安全警告，而冰箱可可以通过投票权接受由+1/2原始验证者签名的任何重组建议。

当≥1/3的投票权不诚实时，任何非同步的拜占庭容错算法都不能达成共识，然而分叉假设≥1/3的投票权已经出于不正当的理由通过双重签名或锁定更改来达成共识。因此，签署重组方案是一个协调问题，任何非同步协议（即自动地，并且不假设底层网络的可靠性）都无法解决这个问题。目前，我们将重组提议协调的问题留给了通过互联网媒体上的社会共识进行人为协调。验证器必须注意在签署重组提议之前确保没有剩余的网络分区，以避免签署两个冲突的重组提议的情况。

假设外部协调媒介和协议是健壮的，那么分叉比审查攻击更不受关注。

除了要求＞?拜占庭人投票权的分叉和审查制度外，＞?拜占庭人投票权的联盟还可能提交任意、无效的状态。这是任何（BFT）共识系统的特点。与使用易于验证的证据创建分叉的双重签名不同，检测无效状态的提交需要非验证对等方验证整个区块，这意味着它们保留状态的本地副本并执行每个事务，为自己独立计算状态根。一旦被发现，处理这种失败的唯一方法就是通过社会共识。例如，在比特币出现故障的情况下，无论是由于软件缺陷导致的分叉（如2013年3月），还是由于矿工拜占庭式行为导致的无效状态（如2015年7月），都是由企业、开发人员、矿工组成的关系密切的社区，和其他组织建立了一个社会共识，即参与者需要哪些手动操作来修复网络。此外，由于Tendermint区块链的验证者可能被认为是可识别的，因此，如果需要的话，无效状态的提交甚至可能受到法律或某些外部法律的惩罚。

10.6ABCI规范

ABCI由3种主要消息类型组成，它们从核心传递到应用。应用用相应的响应消息进行响应。

AppendTx消息是应用的工作马。区块链中的每个事务都会随此消息一起传递。应用需要根据当前状态、应用协议和事务的加密凭据验证通过AppendTx消息接收的每个事务。然后，经过验证的事务需要通过将值绑定到键值存储区或更新UTXO数据库来更新应用状态。

CheckTx消息类似于AppendTx，但它仅用于验证事务。Tendermint BFT的内存池首先使用CheckTx检查事务的有效性，并且只将有效事务转发给其对等方。应用可以检查事务中递增的nonce，如果nonce是旧的，则在CheckTx时返回错误。

Commit消息用于计算对当前应用状态的加密承诺，并将其放入下一个区块头中。这有一些方便的特性。更新该状态时的不一致现在将显示为区块链分叉，捕获一整类编程错误。这也简化了安全轻客户端的开发，因为Merkle哈希证明可以通过检查块哈希进行验证，并且块哈希由验证器的仲裁（通过投票权）签名。

附加的ABCI消息允许应用跟踪和更改验证器集，并允许应用接收区块信息，如高度和提交投票。

ABCI请求/响应是简单的Protobuf消息。检出架构文件。

10.6.1添加事务（AppendTx）

参数：

Data（[]字节）：请求事务字节

返回值：

Code（uint32）：响应代码

Data（[]字节）：结果字节，如果有的话

Log（字符串）：调试或错误消息

使用方法：

追加并运行事务。如果事务有效，则返回代码类型.OK

10.6.2检查事务（CheckTx）

参数：

数据（[]字节）：请求事务字节

返回值：

Code（uint32）：响应代码

Data（[]字节）：结果字节，如果有的话

Log（字符串）：调试或错误消息

使用方法：

验证事务。此消息不应改变状态。事务首先通过CheckTx运行，然后广播到内存池层的对等方。您可以将CheckTx设为半状态，并在提交或BeginBlock时清除状态，以允许在同一区块中存在依赖的事务序列。

10.6.3提交（Commit）

返回值：

Data（[]字节）：Merkle根哈希

Log（字符串）：调试或错误消息

使用方法：

返回应用状态的Merkle根哈希。

10.6.4查询（Query）

参数：

Data（[]字节）：查询请求字节

返回值：

代码（uint32）：响应代码

Data（[]字节）：查询响应字节

Log（字符串）：调试或错误消息

10.6.5刷新（Flush）

使用方法：

刷新响应队列。实现类型的应用。应用不需要实现此消息-它由项目处理。

10.6.6信息（Info）

返回值：

Data（[]字节）：信息字节

使用方法：

返回有关应用状态的信息。应用特性。

10.6.7设置选项（SetOption）

参数：

Key（字符串）：要设置的键值

Value（字符串）：要为键设置的值

返回值：

Log（字符串）：调试或错误消息

使用方法：

设置应用选项。例如Key=“mode”，Value=“mempool”表示mempool连接，或者Key=“mode”，Value=“consensus”表示consensus连接。其他选项是应用特性。

10.6.8初始化链（InitChain）

参数：

Validators（[]Validator）：初始创世验证器

使用方法：

创世时一次性调用。

10.6.9启动区块（BeginBlock）

参数：

Height（uint64）：开始的区块高度

使用方法：

表示新区块的开始。在任何AppendTxs之前调用。

10.6.10结束区块（EndBlock）

参数：

Height（uint64）：结束的块高度

返回值：

Validators（[]Validator）：更改了具有新投票权的验证器（删除0）

使用方法：

表示区块的结束。在所有事务之后每次提交之前调用

有关更多详细信息，请参阅ABCI库。

10.7IBC包传送确认

发送方可能希望接收链确认数据包的发送，这有几个原因。例如，如果预期目标链有故障，则发送方可能不知道其状态。或者，发送方可能希望对数据包施加超时（使用MaxHeight数据包字段），而任何目标链都可能遭受拒绝服务攻击，并且传入数据包的数量突然激增。

在这些情况下，发送方可以通过将初始分组状态设置为AckPending来要求传递确认。然后，接收链负责通过在应用Merkle哈希包含缩写的IBCPacket来确认交付。

首先，在“Hub”上发布了一个IBCBlockCommit和IBCPacketTx，证明了在“ZONE1”上存在一个IBCPacket。假设IBCPacketTx具有以下值：

§ FromChainID: “Zone1”

§ FromBlockHeight: 100 (比如说)

§ Packet: 一个IBCPacket:

§ Header: 一个IBCPacketHeader:

§ SrcChainID: “Zone1”

§ DstChainID: “Zone2”

§ Number: 200 (比如说)

§ Status:AckPending

§ Type: “coin”

§ MaxHeight: 350 (比如 “Hub”当前高度 300)

§ Payload: < “代币”有效载荷的字节>

接下来，在“ZONE2”上发布了一个IBCBlockCommit和IBCPacketTx，证明了在“Hub”上存在一个IBCPacket。假设IBCPacketTx具有以下值：

§ FromChainID: “Hub”

§ FromBlockHeight: 300

§ Packet: 一个IBCPacket:

§ Header: 一个IBCPacketHeader:

§ SrcChainID: “Zone1”

§ DstChainID: “Zone2”

§ Number: 200

§ Status:AckPending

§ Type: “coin”

§ MaxHeight: 350

§ Payload: <”代币”有效载荷的相同字节>

接下来，“Zone2”必须在其应用哈希中包含一个显示AckSent的新状态的缩写包。一个IBCBlockCommit和IBCPacketTx被发布在“Hub”上，这证明了在“ZONE2”上存在一个缩写的IBCPacket。假设IBCPacketTx具有以下值：

§ FromChainID: “Zone2”

§ FromBlockHeight: 400 (比如说)

§ Packet: anIBCPacket:

§ Header: anIBCPacketHeader:

§ SrcChainID: “Zone1”

§ DstChainID: “Zone2”

§ Number: 200

§ Status:AckSent

§ Type: “coin”

§ MaxHeight: 350

§ PayloadHash: <“代币“有效载荷的哈希字节等同值>

最后，“Hub”必须更新从AckPending 到AckReceived的数据包状态。这种新的最终状态的证据应该回到“Zone2”。假设IBCPacketTx具有以下值：

§ FromChainID: “Hub”

§ FromBlockHeight: 301

§ Packet: anIBCPacket:

§ Header: anIBCPacketHeader:

§ SrcChainID: “Zone1”

§ DstChainID: “Zone2”

§ Number: 200

§ Status:AckReceived

§ Type: “coin”

§ MaxHeight: 350

§ PayloadHash: <“代币“有效载荷的哈希字节等同值>

同时，“Zone1”可以乐观地假设“代币”包的成功交付，除非“Hub”上证明了相反的证据。在上面的例子中，如果块350的“Hub”没有从“Zone2”接收AckSent状态，它将自动将状态设置为超时。超时的证据可以在“Zone1”上发布，并且任何代币可以返回。

10.8Merkle树与证明规范

Tendermint/共识生态系统支持两种Merkle树：简单树和IAVL+树。

10.8.1简单树

简单树是元素静态列表的Merkle树。如果物品的数量不是2的幂，一些叶子会处于不同的水平。简单树试图使树的两边保持相同的高度，但左边的高度可能更大。此Merkle树用于Merkle化区块的事务和应用状态根的顶级元素。

包含7个元素的简单树

10.8.2IAVL+树

IAVL+数据结构的目的是为应用状态下的键值对提供持久存储，以便能够有效地计算确定性Merkle根哈希。该树使用AVL算法的一个变体进行平衡，所有操作都是O（log（n））。

在AVL树中，任何节点的两个子树的高度最多相差一个。每当更新时违反此条件时，将通过创建指向旧树的未修改节点的O（log（n））个新节点来重新平衡树。在原始的AVL算法中，内部节点也可以保存键值对。AVL+算法（注意加号）修改了AVL算法，使其保持叶节点上的所有值，同时只使用分支节点存储密钥。这简化了算法，同时保持了Merkle哈希追踪短。

AVL+树类似于以太坊的Patricia尝试。有折衷办法。在插入IAVL+树之前不需要哈希键，因此这在键空间中提供了更快的有序迭代，这可能有利于某些应用。逻辑实现起来更简单，只需要两种类型的节点——内部节点和叶节点。Merkle证明平均更短，是一个平衡二叉树。另一方面，IAVL+树的Merkle根取决于更新的顺序。

我们将支持其他有效的Merkle树，例如以太坊的Patricia 尝试，当二进制变量可用时。

10.8.3事务类型

在规范实现中，事务通过ABCI接口流式传输到Cosmos hub应用。

Cosmos Hub将接受许多主要事务类型，包括SendTx、BondTx、UnbondTx、ReportHackTx、SlashTx、BurnAtomTx、ProposalCreateTx和proposalbotetx，这些类型都是相当自解释的，并将在本文的未来版本中记录。这里我们记录了IBC的两种主要事务类型：IBCBlockCommitTx和IBCPacketTx。

IBCBlockCommitTx

IBCBlockCommitTx事务由以下部分组成：

§ ChainID (string):区块链的ID

§ BlockHash ([]byte):区块哈希字节，包含应用哈希的Merkle根

§ BlockPartsHeader (PartSetHeader): 区块部分设置头字节，仅用于验证投票签名

§ BlockHeight (int): 提交的高度

§ BlockRound (int): 提交的轮次

§ Commit ([]Vote): 包含区块提交的>? Tendermint预提交投票数

§ ValidatorsHash ([]byte): 新验证器集合的Merkle树根哈希

§ ValidatorsHashProof (SimpleProof): 证明ValidatorsHash不符合BlockHash的简单树Merkle证明

§ AppHash ([]byte): 应用状态的IAVL树 Merkle 树根哈希

§ AppHashProof (SimpleProof): 一个简单树Merkle证明，证明AppHash与BlockHash相反

IBCPacketTx

IBCPacket由以下部分组成：

§ Header (IBCPacketHeader): 包头

§ Payload ([]byte): 数据包载荷的字节数。可选的

§ PayloadHash ([]byte): 数据包字节的哈希值。可选的

必须存在Payload或PayloadHash之一。IBCPacket的哈希是头和负载这两个项的简单Merkle根。没有完整负载的IBCPacket称为缩写包。

IBCPacketHeader由以下部件组成：

§ SrcChainID (string): 源区块链 ID

§ DstChainID (string): 目标区块链ID

§ Number (int): 所有数据包的唯一编号

§ Status (enum): 可以是AckPending、AckSent、AckReceived、NoAck或Timeout之一

§ Type (string): 这些类型依赖于应用。Cosmos保留“代币”包类型

§ MaxHeight (int): 如果此高度没有NoAckWanted或AckReceived状态，则状态变为超时。可选的

IBCPacketTx事务由以下部分组成：

§ FromChainID (string): 提供此数据包的区块链的ID；不一定是源

§ FromBlockHeight (int): 在源链的区块哈希中包含（Merkle-ized）以下数据包的区块链高度

§ Packet (IBCPacket): 一种数据包，其状态可以是akpending、AckSent、AckReceived、NoAck或Timeout

§ PacketProof (IAVLProof): 一个IAVL树-Merkle证明，用于在给定高度证明包的哈希值与源链的AppHash值之间的关系

{图X}描述了通过“Hub”将数据包从“Zone1”发送到“Zone2”的序列。首先，IBCPacketTx向“Hub”证明包包含在“Zone1”的应用状态中。然后，另一个IBCPacketTx向“Zone2”证明包包含在“Hub”的应用状态中。在此过程中，IBCPacket字段是相同的：SrcChainID始终为“Zone1”，DstChainID始终为“Zone2”。

PacketProof必须具有正确的Merkle证明路径，如下所示：

IBC/<srcchanid>/<dstchanid>/<Number>

当“Zone1”想通过“Hub”向“Zone2”发送数据包时，无论数据包是在“Zone1”、“Hub”还是“Zone2”上聚合的，它们的数据都是相同的。唯一可变字段是跟踪分发的状态。

11.致谢

我们感谢我们的朋友和同行在构思、审查和支持我们与Tendermint和Cosmos的合作方面提供的帮助。

SkuChain的Zaki Manian在格式和措辞方面提供了很多帮助，特别是在ABCI部分

Adhea和Dustin Byington的Jehan Tremback帮助进行初始迭代

Honey Badger的安德鲁·米勒（Andrew Miller）就共识提供反馈

·Greg Slepak就共识和措辞提供反馈

还要感谢比尔·格雷姆和韩升华的各种贡献。

你的名字和组织在这里是因为你的贡献

12.引文

§ 1Bitcoin:https://bitcoin.org/bitcoin.pdf

§ 2ZeroCash:http://zerocash-project.org/paper

§ 3Ethereum:https://github.com/ethereum/wiki/wiki/White-Paper

§ 4TheDAO:https://download.slock.it/public/DAO/WhitePaper.pdf

§ 5Segregated Witness:https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki

§ 6BitcoinNG:https://arxiv.org/pdf/1510.02037v2.pdf

§ 7Lightning Network:https://lightning.network/lightning-network-paper-DRAFT-0.5.pdf

§ 8Tendermint:https://github.com/tendermint/tendermint/wiki

§ 9FLP Impossibility:https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf

§ 10Slasher:https://blog.ethereum.org/2014/01/15/slasher-a-punitive-proof-of-stake-algorithm/

§ 11PBFT:http://pmg.csail.mit.edu/papers/osdi99.pdf

§ 12BitShares:https://bitshares.org/technology/delegated-proof-of-stake-consensus/

§ 13Stellar:https://www.stellar.org/papers/stellar-consensus-protocol.pdf

§ 14Interledger:https://interledger.org/rfcs/0001-interledger-architecture/

§ 15Sidechains:https://blockstream.com/sidechains.pdf

§ 16Casper:https://blog.ethereum.org/2015/08/01/introducing-casper-friendly-ghost/

§ 17ABCI:https://github.com/tendermint/abci

§ 18Ethereum Sharding:https://github.com/ethereum/EIPs/issues/53

§ 19LibSwift:http://www.ds.ewi.tudelft.nl/fileadmin/pds/papers/PerformanceAnalysisOfLibswift.pdf

§ 20DLS:http://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf

§ 21Thin Client Security:https://en.bitcoin.it/wiki/Thin_Client_Security

§ 22Ethereum 2.0 Mauve Paper:http://vitalik.ca/files/mauve_paper.html

未排序链接

https://www.docdroid.net/ec7xGzs/314477721-ethereum-platform-review-opportunities-and-challenges-for-private-and-consortium-blockchains.pdf.html

相关链接

【译文】什么是跨链双雄之一的Cosmos？

—-

编译者/作者：灰狼

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。