登录 注册
Cosmos & Tendermint> Cosmos白皮书(第8-10章)

8. 管理

Cosmos Hub通过分布式组织来运行,这类组织要求有一套完备的管理机制,从而协调区块链上的各类变动,比如系统变量参数,以及软件更新、规章更改等。

所有验证人对所有提案的投票负责。如果没能及时对提案做出投票,那么验证人就会在一段时间内自动失去活动权利,这段时间叫做缺席惩罚期(AbsenteeismPenaltyPeriod,默认为一周)。

委托人自动继承委托验证人的投票权。这一投票可能会被手动覆盖掉。而未绑定的Atom是没有投票权的。

每个提案都需要一定的保证金,即最低提案保证金(MinimumProposalDeposit )代币,这个可以是代币组合也可以是更多代币包括Atom。对每一个提案,投票人可能会投票来取走保证金呢。如果超过一半的投票人选择取走保证金(比如,由于提案是垃圾信息之类),那么保证金就会进去储备池,除非有任何Atom被燃烧。

对于每一个提案,投票人可能会投以下选项:

· 同意

· 强烈同意

· 反对

· 强烈反对

· 弃权

决定采纳(或不采纳)提案需要严格的多数投“同意”或“强烈同意”(或者“反对”及“强烈反对”),但是超过1/3的人投“强烈反对”或“强烈支持”的话就可以否决大多数人的决定。如果大多数人的票都被否决,那么每个人都会得到惩罚,即损失否决惩罚费用块那一部分钱( VetoPenaltyFeeBlocks,默认是一天的区块值 ,税费除外),而否决大多数决定的那一方也会受到额外的惩罚,即损失否决惩罚Atom(VetoPenaltyAtoms,默认为0.1%)。


8.1 参数改变提案

这里定义的任何参数都可以发生改变,主要在参数改变提案(ParameterChangeProposal)的接受范围内。

8.2 文本提案

所有其他提案,比如用来更新协议的提案,都会通过通用的文本提案(TextProposal)来协调。

8.3 路线图

详见计划


9. 相关工作

过去几年,关于区块链共识及可扩展性已经有过多次创新,这一部分将挑选一些重要的创新进行简短分析。

9.1 共识系统

经典拜占庭容错

二十世纪八十年代早期的共识机制中就已经出现了恶意参与者,当时Leslie Lamport杜撰了“拜占庭容错”这个词,用来指那些图谋不轨参与者做出的恣意妄为的行径,这个词和“死机故障”相对,死机故障就只是处理过程崩溃而已。早期针对同步网络也探索出了一些解决方案,其信息滞后有一个上限,尽管实际使用是在高度受控的环境下进行的(比如飞机控制器以及原子钟同步的数据中心)。直到九十年代后期,实用拜占庭容错(PBFT)才被引用,作为有效的、部分同步的共识算法,以容忍处理过程中⅓的恣意行为。PBFT成为标准算法,繁殖了各种衍生品,包括最近IBM用于超级账本中的。

和PBFT相比,Tendermint共识的主要好处在于其有一套经过改善且简化了的底层结构,其中有些是拥抱区块链范例的结果。Tendermint区块必须按顺序提交,这一点可以消除复杂性,节省与PBFT浏览变化相关的通信开支。在Cosmos和众多加密币中,如果区块N本身没有提交,那么就无需让区块N+i(i>=1)来提交。如果是带宽导致了区块N未提交到Cosmos空间,那么它就不会帮助使用带宽将选票共享给区块N+i。如果是网络分区或者线下节点导致的区块N未提交,那么N+i就无论如何也不会提交。

此外,区块内交易的批量处理可以对应用程序的状态进行默克尔哈希,而不是用PBFT检查机制进行周期消化。这可以实现轻客戸端更快的证明交易提交,以及更快的跨区块链通信。

Tendermint Core中有很多优化项和特点都超过了PBFT特定的性能。比如,验证人发起的区块被分割成部分,默克尔化然后散布开来,这种方式可以提高其广播性能(关于启发请查看LibSwift[19])。而且,Tendermint Core不会对点对点连接做任何假设,只要点对点网络仍有微小连接,那么它就能正常运行。


BitShare委托权益

BitShares [12]不是第一个部署权益证明机制(PoS)的区块链,但是其对PoS区块链的研究与采纳做出了巨大的贡献,尤其是这些被认为是“受委托的” PoS。在BitShares中,股权持有者选择“见证”以及“委托”,其中“见证”负责下单并提交交易,而“委托”负责协调软件更新与参数变化。尽管BitShare在理想环境下的性能很高(100k tx/s,1秒的滞后),但是它也有可能受到恶意见证施加的重复使用攻击,这类攻击会导致区块链出现分叉而不用受到任何经济惩罚——它的惩罚来自于“没有任何权益”。BitShare试图通过允许交易查看近期区块哈希来环节这个问题。此外,权益相关者可以每天移除或替代行为不佳的见证,尽管这个对成功的重复使用攻击来说根本不算什么明确的惩罚。


Stellar

Stellar  [13]是在Ripple的解决方案上创建的,它精炼了联邦拜占庭协议模型,其中参与共识的进程不包括固定且举世闻名的组件。相反,每个处理节点管理一个或多个“仲裁集碎片”(每一个都组成一组可靠的进程)。Stellar中的“仲裁集”被定义为一组节点,其中每一节点包含(是一个超集合)至少一个仲裁集碎片,这样就可以达成协议。

机制的安全性依靠假设实现,即假设任意两个仲裁集的交集并非为空,而实现节点的可用性则需要至少一个仲裁集碎片来完整组成正确节点,这个在使用或大或小的仲裁集碎片间可能会产生一组权衡,因为要在不对信任施加重要假设的情况下来进行平衡是很困难的。最终,节点必须以某种办法来选择充足的仲裁集碎片,从而保证有足够多的容错(或任何“完整无损的节点”,大部分文章里得出的结果就依靠这个来决定)。此外,唯一用来确保这类配置的战略是等级制的,且和BGP协议相似(边界网关协议),可用于互联网高层ISP来创建全球路由表,或者是用在浏览器中管理TSL(传输层安全)证书,不过这两者都因其不安全性而臭名昭著。

Stellar文章中对基于Tendermint的权益证明系统的批判可以通过以下代币战略加以缓和,其中有一种新的代币叫做“atom”,可以通过发布这一代币来代表未来的费用及奖励。所以,Tendermint权益证明机制的好处就是其简易性,在相对简易的同时,提供足够多且可证明的安全保障。


BitcoinNG

BitcoinNG是针对比特币提出来的一种改善,或将允许垂直扩展形式,比如增加区块容量,并且不会带来负面经济影响(一般这类变动都会带来这类影响),比如越小的矿工受到的影响越大。这一改善可以通过将是首项选择从交易广播中分离来实现,即由“微区块”中的工作量证明先选择群首,之后可以对要提交的交易进行广播,直到新的微区块被发现。这个过程会减少赢得工作量证明比赛所必须的带宽需求,让小矿工可以更公平的参与竞争,然后让最后找到微区块的矿工来定期提交交易。


Casper

Casper [16]是针对以太坊提出的一个权益证明共识算法。其最初运行模式是“赌注共识”,理念就是让验证人反复对其认为会提交到区块链的区块下赌注(根据它之前打赌的经验来),最后得出结论。链接。这是Casper团队活跃中的研究领域,其挑战就是搭建一套进化稳定的打赌机制。和Tendermint相比,Casper主要的优势就在于提供了“优于一致性的实用性”——其共识无需超过⅔的仲裁选票——可能其代价就是速度慢以及实现复杂。

9.2 水平扩展

Interledger协议

Interledger协议[14]严格来说不算是可扩展解决方案。它通过一个松散耦合的双边关系网络,为不同账本系统提供了特别的互操作性。比如闪电网络,ILP的目的就是促进支付,不过是以不同账本类型的支付为主,并且延展了原子交易机制,将哈希锁以及公证人的仲裁集(也叫做原子传输协议)都包括进去。用于维持账本间交易原子数的后面这种机制和Tendermint的轻客戸端SPV机制相似,因此就可以对ILP和Cosmos/IBC之间的区别加以解释了,具体如下:

1. 在ILP中连接器的公证人不支持成员变动,并且不允许在公证人间进行灵活的权重。而IBC是专门为区块链设计的,其验证人可以有不同的权重,而且成员也可以根据区块链进程进行变动。

2.在闪电网络中,ILP付款接收人必须在线来发送确认函给发送者。而在IBC代币传输过程中,接收人区块链的验证组会负责提供确认,而非接收人。

3.两者最大的不同就是ILP的连接器不充当支付状态的权威方,而在Cosmos中,一个中心的验证人就是IBC代币传输状态以及每个空间所持代币总量(不是空间每个账户所持代币总量)的权威见证人。这是一个根本性创新,允许代币在空间里进行安全且非对称的传输,而在Cosmos中,充当ILP连接器的角色是一个持久且安全的区块链账本——Cosmos中心(Cosmos Hub)。

4.ILP账本间支付需要由一份交易订单簿做支持,因为其不包括代币从一个账本到另一个账本的非对称传输,而只有价值或市场等值在传输。


侧链

侧链[15]是针对比特币网络扩展提出的一个机制,通过与比特币区块链“挂钩”的可替代区块链实现。侧链可以让比特币有效从区块链转移到侧链及后台,还可以在侧链上进行新功能测试。在Cosmos Hub中,侧链和比特币是彼此的轻客戸端,使用SPV(安全协议验证工具)证明来决定什么时候转移代币到侧链及后台。当然,因为比特币采用工作量证明机制,所以以比特币为中心的侧链也遇到很多工作量证明作为共识算法而带来的问题与风险。此外,这个是比特币多数派解决方案,它并不支持本地代币以及空间内网络拓扑学,而Cosmos可以。也就是说,这种双向挂钩的核心机制在原则上是和Cosmos网络运用的机制一样的。

以太坊在可扩展方面的努力

以太坊目前正在研究不同的方法来实现以太坊区块链状态的碎片化,从而解决可扩展问题。这些努力的目标就是在共享状态空间中维持当前以太坊虚拟机提供的抽象层。他们同时开展了多项研究。[18][22]

Cosmos vs 以太坊2.0 Mauve

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

· Cosmos专注代币。而Mauve是和扩展普通计算相关。

· Cosmos不一定是以太坊虚拟机,因此即使是不同的虚拟机也可以进行交互。

· Cosmos可以让空间创建者决定谁来验证空间。

· 任何人都可以在Cosmos开创新空间(除非管理有其他决定)。

· 中心会隔离空间故障,这样全球代币的不变性就得到了维护。

9.3 普通扩展

闪电网络

闪电网络是一种代币传输网络,在比特币区块链(及其他公共区块链)上一层运行,能够执行众多改善交易吞吐量的指令,通过将大多数交易从共式账本移出,转入所谓的“支付信道”内。这个举措通过链上的加密货币脚本或可实现,它可以让参与者进入双方有状态的合约,其中状态可以通过共享数字签名进行更新,并且最后将证据公布到区块链后可以关闭合约,这个机制最初是通过跨链原子掉期而普及的。通过开放多方支付信道,闪电网络的参与者可以成为他人支付的路由焦点,带领全面连接的支付信道网络,代价就是绑定在支付信道上的资本。也就是说,我们可以期待支付信道与闪电网络在我们的代币传输机制下投入广泛应用,一方面为了节省成本,另一方面也可以保证隐私。

      隔离见证

隔离见证是一项比特币改善提议( 连接),其目的是将每个区块的交易吞吐量提高2-3倍,并且同时保证区块快速同步新节点。这个方案的出色就在于它可以在比特币当前协议的限制下运行,并且允许进行软分叉更新(也就是其他旧版本的客户端软件在更新后可以继续运行)。Tendermint是一种新的协议,它没有设计限制,因此可以有不同的扩展选择。首先,Tendermint采用拜占庭容错循环制算法,这个是在加密签字而非挖矿的基础上进行,可以简单地通过多平行区块链进行水平扩展,而定期频繁的区块提交还可以进行垂直扩展。

10. 附录

10.1 分叉问责制

如果遇到超过容错能力以及共识出错的情况下,设计周到的共识协议应该要对此提供一定的保障。这个在经济系统中尤为必要,经济系统中的拜占庭行为可以获取大量资金奖励。而针对上述情况有一个最为重要的保证就是分叉问责制,这个形式下,导致共识出错的进程(也就是导致协议客户端开始接受不同值——即分叉出现)可以被识别出并根据协议规定进行生发,或者也有可能受到法律制裁。当法律系统变得不可靠或者调用代价过大,那么验证人可能要强制支付安全保证金来参与,而一旦检测到恶意行为,那么这些保证金就会被吊销或者减少。 [10]

注意这个和比特币有很大区别,由于网络同步及其发现哈希冲突的概率特性,比特币的分叉是定期出现的。在很多案例中,很难将恶意分叉与同步导致的分叉区分开来,所以比特币无法可靠地实施分叉问责制,除了让矿工为孤行区块挖矿支付隐形机会成本。

10.2 Tendermint共识

我们将投票阶段分为预投票及预提交阶段。一个选票可以用于特定区块或_Nil。我们把同一轮超过⅔的单个区块的预投票总和称为_Polka,把同一轮超过⅔的单个区块的预提交总和称为_Commit_。如果同一轮针对Nil的预提交超过⅔,那么它们就进入下一轮。

注意,协议中严格的决定论会招致较弱的同步假设,因为默认的首项必须被扣除且略过。因此,验证人在对Nil进行预投票前会等候一段时间(即_TimeoutPropose_ ,超时提议),而_TimeoutPropose_ 的值会随着每一轮的进行而增加。每一轮剩下的进程是完全同步的,在过程中只有验证人收到超过⅔的网络投票才会进入下一步。在实践中,这么做将需要超级强大的对手无限阻挠较弱的同步假设(导致共识无法提交区块),而且通过使用每个验证人的_TimeoutPropose_ 随机值还可加大其难度。

另一套约束,或者锁定规则会确保最终在每个高度只提交一个区块,任何试图提交超过一个区块到指定高度的恶意行为都会被识别出来。首先,每个区块的预提交必须正当,并且以Polka的形式提交。如果验证人已经在_R_1_轮预提交了一个区块,那么我们就认为它们被锁定在了这个区块,然后用于验证_R_2_轮新预提交动作的Polka必须进入R_polka轮,其中 R_1 < R_polka <= R_2。第二,验证人必须提出并且/或者预投票它们被锁定的区块。这两步合起来,就可以确保验证人不会在没有充足证据证明正当性的前提下进行预提交,并且保证已经完成预提交的验证人不能再为其他东西的预提交贡献证明。这样不但可以保证安全,还能保证共识算法的活跃。

关于这一协议的全部细节参考 这里

10.3 Tendermint轻客戸端

本来需要同步所有区块头,现在在Tendermint-PoS里取消了这一需求,因为我们有替代链(分叉),也就是说可以削减超过⅓的绑定权益。当然,削减也是需要有人共享分叉证据的,所以轻客戸端就要存储任何它见证的区块哈希提交。此外,轻客戸端可以定期同步验证组的变动,以避免出现 远距离攻击(除了其他可能实现的解决方案)。

秉着和以太坊类似的想法,Tendermint能够让应用程序在每个区块中嵌入全球梅克尔根哈希,可以进行简单且可验证的状态查询,比如查询账户余额、合约存放价值,或者未使用交易输入的存在等,具体由应用程序的特性决定。

10.4 预防远距离攻击

假设有一套充足的可复原的广播网络集合以及一组静态验证组,那么任何区块链分叉都可以被检测到,而且发起攻击的验证人提交的保证金会被扣除。这一创新是由Vitalik Buterin于2014年首次提出的,可以解决其他权益证明加密货币"没有任何权益"的问题(详见 相关工作部分。)但是,由于验证组必须要可以更改,所以可能在很长一段时内最初的验证人可能会解除绑定,因此就可以自由从创世区块中创建新链,并且不需要任何费用,因为他们不再有锁定的保证金。这类攻击被称为远距离攻击(LRA),和短距离攻击相反,短距离攻击是当前处于绑定中的验证人导致的分叉,并且会因此受到惩罚(假设有类似Tendermint共识这样的分叉问责制拜占庭容错算法)。长距离攻击经常被认为是对权益证明机制的重要打击。

所幸的是,LRA可以通过以下方法得以缓解。第一,针对解绑(来恢复抵押的保证金并且不再挣取参与共识的费用)的验证人,保证金在一定时间内必须是不可转移的,可以称作"解绑期",可能长达数周或数月。第二,针对轻客戸端的安全,其首次连接到网络必须根据可信源验证最近的一个或者最好是多个区块哈希。这种情况有时也被称作"薄弱主观性"。最后,为了保证安全,必须频繁同步最新验证组(每次间隔时间和解绑期一样)。这一点可以保证轻客戸端在验证人解绑资金(从而没有任何权益)前知道验证组的变化情况,否则解绑的验证人就会通过实施远距离攻击来欺骗客户端,在其绑定的高度创建新区块起始返回点(假设它可以控制足够多的早期私钥)。

注意,用这种方式解决LRA问题需要对工作量证明模型原始的安全问题进行彻底检查。在PoW中,轻客戸端被认为可以在任何时候从可靠的创世区块同步到当前高度,这个过程可以简单的在每个区块头上处理工作量证明来完成。但是,为了解决LRA,我们需要轻客戸端上线定期追踪验证组的变动,并且其首次上线必须尤其要注意根据可靠源来验证其从网络收集的情报。当然,后面这个要求和比特币的类似,在比特币中,协议和软件也必须从可靠源获得。

上述预防LRA的方法正好适合Tendermint驱动下的区块链验证人及全部节点,因为这些节点的任务就是保持连接到网络。这个方法也适合那些想要经常进行网络同步的轻客戸端。但是,对不希望频繁接入互联网或区块链网络的轻客戸端来说,还有另一种方法可以用来解决LRA问题。非验证人的代币持有者额可以在很长的解绑期内(比如比验证人的解绑期久)发布代币作为抵押品,并且为轻客戸端提供第二级解决方案来证实当前及过去区块哈希的有效性。就算这些节点没有计入区块链共识的安全性时,他们还是可以为轻客戸端提供强大的保障。如果历史区块哈希查询在以太坊中得到过支持,那么任何人都可以用特定的智能合约来绑定他们的代币,并且提供付费证明服务,从而有效地针对轻客戸端LRA安全问题开发出一个市场。

10.5 克服分叉及审查攻击

由于区块提交的定义如此,所以任何超过⅓的投票联合都可以通过下线或者不广播选票来中止区块链运行。这样的联合也可以通过拒绝包含这类交易的区块来检查特定交易,尽管这或将导致大多数区块提案被拒绝,从而减缓区块提交速率,降低实用性及价值。恶意联合或许会陆陆续续地广播选票,以阻挠区块链的区块提交,将其逼停,或者就是参与到这些攻击的组合攻击中。最后,它会通过双重签名或者违反锁定规则来造成区块链分叉。

如果一个全球活跃的对手参与进来,那么就会使网络分割,导致验证组子集出现拉低速率。这不单单是Tendermint面临的限制,也是所有共识协议(其网络可能由活跃对手控制)的限制。

对这几类攻击,验证人子集应该在外部进行协调,签署重组提议来选择分叉(及牵扯到的任何证据)以及验证人的初始子集。签署这份重组提议的验证人会放弃他们在其他分叉上的所有抵押品。客户端要验证重组提议上的签名,验证任何证据并且做出判断或者给端用户提示来做决定。比如,一个手机钱包APP可能会提示用户安全警告,而电冰箱可能会接受签署超过½的初始验证人提出的重组提议。

任何非同步的拜占庭容错算反都不能进入共识,如果超过⅓的投票不诚实的话,而且出现分叉就说明已经有超过⅓的投票权因为无正当理由的双重签名或改锁而失信。因此,签署重组提议是一个协调性问题,无法通过任何非同步协议(即自动的,不对底层网络可靠性做假设的)来解决。目前,我们认为重组提议的协调问题,可以通过互联网媒体的社会共识来实现人为协调。验证人必须确保在签订重组提议前不会出现网络分割,以此来避免有两个相冲突的重组提议被强叔的情况出现。

加入外部条件媒介以及协议足够稳健的话,那么分叉的问题就没有检查攻击问题来的严重。

分叉和检查需要有超过⅓的拜占庭投票权,此外超过⅔的投票权联合可能会恣意提交无效状态。这个是任何拜占庭容错共识系统的特点。和双重签名不同,双重签名会利用简单的可验证的证据来创建分叉,而要检测无效状态的提交则需要非验证对等节点来验证整个区块,也就是说它们会保留一份本地状态副本,执行每笔交易,然后独立计算状态根。一旦检测出来,处理这类故障的唯一方法就是社会共识。比如,如果比特币出现问题,那么无论是软件漏洞造成的分叉,还是矿工拜占庭行为提交的无效状态(正如2015年7月),连接紧密的商户、开发者、矿工以及其他组织组成的社区按照所需分工来参与修复网络。此外,因为Tendermint区块链的验证人或可进行身份认证,所以如果有这个想法,那么无效状态的提交也可能会受到法律或其他外部法律体系的惩罚。

10.6 TMSP具体说明

TMSP(Tendermint Socket协议)由三个主要信息类型组成,这三类信息从核心传递到应用程序上,然后应用程序用相关回复信息做出应答。

AppendTx 信息是应用程序的主力。区块链上的每笔交易都通过这个信息来传递。应用程序需要借助AppendTx信息在当前状态、应用程序协议以及交易加密证书中进行验证,验证每笔接收的交易。验证过的交易之后需要更新应用状态——通过绑定一个值到关键价值存储库中,或者更新UTXO数据库。

CheckTx 信息和AppendTx信息类似,但是只针对交易验证。Tendermint Core的内存池会先用CheckTx检查交易有效性,并且只会将有效的交易分程传递给对等节点。应用程序可能会检查交易中的递增新鲜值,如果新鲜值过期就会借助CheckTx返回一个错误。

Commit信息是用来计算当前应用状态上的加密提交项的——之后会存入下一区块头。这包含一些方便的特性。状态更新的矛盾性将以区块链分叉的形式出现,从而捕捉整个阶段的程序错误。这也简化了安全轻客戸端的开发,因为梅克尔哈希证明可以通过检查区块哈希来加以验证,而区块哈希是通过验证人仲裁集加以签署的(通过投票权)。

额外的TMSP信息允许应用程序追踪改变验证组,并让应用程序接收高度、提交的选票之类的区块信息。

TMSP的要求/回应是简单的Protobuf信息。请参考这里的 模式文件

AppendTx(附加交易)

  • 命令行参数 :

            Data ([]byte): 所需交易的字节

  • 返回 :

            Code (uint32): 回复代码

            Data ([]byte): 结果字节,如果有的话

            Log (string): 调试或出错信息

  • 使用 : 附加并运行一笔交易。如果交易有效,那返回CodeType.OK

CheckTx(检查交易)

  • 命令行参数 :

  •     Data ([]byte): 所需交易的字节

  • 返回 :

  •     Code (uint32): 回复代码

        Data ([]byte): 结果字节,如果有的话

        Log (string): 调试或出错信息

  • 使用 :

验证一笔交易。这个信息不应该改变状态。交易在广播给内存池层对等节点前,首先通过CheckTx运行。你可以发起半状态化CheckTx,并在Commit or BeginBlock上清算状态,以允许执行同一区块中相关的交易序列。

Commit(提交)

  • 返回 :

  •     Data ([]byte): 梅克尔根哈希

        Log (string): 调试或出错信息

  • 使用 : 返回应用程序状态梅克尔根哈希。

Query(查询)

  • 命令行参数 :

  •     Data ([]byte): 查询需要的字节

  • 返回 :

  •     Code (uint32): 回复代码

        Data ([]byte): 查询回复字节

        Log (string): 调试或出错信息

Flush(划掉)

  • 使用 :

划掉回复队列。使用types.Application的应用程序无需实施这条信息——这个由项目进行处理。

Info(信息)

  • 返回 :

  •     Data ([]byte): 信息的字节

  • 使用 :

          返回关于应用程序状态的信息。Application specific.

SetOption(设置选项)

  • 命令行参数 :

  •     Key (string): 设置密钥

        Value (string): 密钥设置的值

  • 返回 :

  •     Log (string): 调试或出错信息

  • 使用 : 设置应用选项。比如,针对内存池的连接可以将密钥设置为"mode"(模式),价值为"mempool"(内存池)。或者针对共识连接,将密钥设置为"mode",价值设置为"consensus"(共识)。其他选项根据可具体应用进行专门设置。

InitChain(初始链)

  • 命令行参数 :

  •      Validators ([]Validator): 初始创世验证人

  • 使用 : 在创世块生成后进行调用

BeginBlock(起始块)

  • 命令行参数 :

  •     Height (uint64): 区块刚开始的高度

  • 使用 : 为新区块的开始提供信号。在任何附加交易(AppendTxs)前进行调用。

EndBlock(结束区块)

  • 命令行参数 :

  •     Height (uint64): 结束时的区块高度

  • 返回 :

  •     Validators ([]Validator): 具有新选票的变动后的验证人(归零就去除)

  • 使用 : 为区块结束提供信号。在每次提交前所有交易后调用。

更多细节请参考 TMSP知识库

10.7 IBC包交付确认

发送人可能会需要接收链提供包交付确认,这个原因有很多。比如,发送人可能不了解目的链的状态,如果有问题的话也不得而知。或者,发送者可能会想要向包强加一次超时(借助MaxHeight 即最大值包域),而目的链可能会遇到拒绝服务攻击,比如接受包数量突然暴增。

在这些案例中,发送人可以通过在AckPending上设置初始包状态来要求提供交付确认。接着就由接收链通过在应用程序的梅克尔哈希中包括一个缩写的IBCPacket 来确认交付。

Figure of Zone1, Zone2, and Hub IBC with acknowledgement

首先,IBCBlockCommit 以及IBCPacketTx 是公布在"Hub"(中心)上用来证明"Zone1"(空间1)上的IBCPacket的存在的。假如IBCPacketTx 的值如下:

  • FromChainID: “Zone1”

  • FromBlockHeight: 100 (假如)

  • Packet: an IBCPacket:

  •     SrcChainID: “Zone1”

        DstChainID: “Zone2”

        Number: 200 (假如)

        Status: AckPending

        Type: “coin”

        MaxHeight: 350 (假如"Hub"目前的高度是300)

        Header: an IBCPacketHeader:

        Payload: <The bytes of a “coin” payload>(一个"代币"的有效负荷字节)

第二步,IBCBlockCommit 和IBCPacketTx 被公布到"Zone2"(空间2)来证明IBCPacket 存在于"Hub"上。假如IBCPacketTx 的值如下:

  • FromChainID: “Hub”

  • FromBlockHeight: 300

  • Packet: an IBCPacket:

  •     SrcChainID: “Zone1”

        DstChainID: “Zone2”

        Number: 200

        Status: AckPending

        Type: “coin”

        MaxHeight: 350

        Header: an IBCPacketHeader:

        Payload: <The same bytes of a “coin” payload>(一个"代币"相同的有效负荷字节)

接下来,"Zone2"必须将缩写的包放入其应用程序哈希中来显示AckSent的最新状态。

IBCBlockCommitand 和IBCPacketTx 会公布到"Hub"上来证明缩写的IBCPacket 存在于"Zone2"上。假如IBCPacketTx 的值如下:

  • FromChainID: “Zone2”

  • FromBlockHeight: 400 (say)

  • Packet: an IBCPacket:

  •     SrcChainID: “Zone1”

        DstChainID: “Zone2”

        Number: 200

        Status: AckSent

        Type: “coin”

        MaxHeight: 350

        Header: an IBCPacketHeader:

        PayloadHash: <The hash bytes of the same “coin” payload>(相同"代币"有效负荷的哈希字节)

最后,“Hub"必须更新从AckPending 到AckReceived的包的状态。这个最新状态的证据要回到"Zone2”。假如IBCPacketTx 的值如下:

  • FromChainID: “Hub”

  • FromBlockHeight: 301

  • Packet: an IBCPacket:

  •     SrcChainID: “Zone1”

        DstChainID: “Zone2”

        Number: 200

        Status: AckReceived

        Type: “coin”

        MaxHeight: 350

        Header: an IBCPacketHeader:

        PayloadHash: <The hash bytes of the same “coin” payload>(相同"代币"有效负荷的哈希字节)

同时,"Zone1"可能会积极地假设"代币"包的交付是成功的,除非"Hub"上有证据给出相反的证明。在上述例子中,如果"Hub"没有从"Zone2"接收到区块350的AckSent 状态,那么它就会自动将这个设置到Timeout(超时)。这个超时证据可以贴回到"Zone1"上,然后就可以返回任意代币。

Figure of Zone1, Zone2, and Hub IBC with acknowledgement and timeout

10.8 梅克尔树及梅克尔证明说明

Tendermint/Cosmos生态支持的梅克尔树有两种:简单的和IAVL+的。

简易版梅克尔树

简易版梅克尔树针对的元素的静态列表。如果项的数目不是2的次方,那么有些树叶就会在不同的层。简易树试图让树的两侧在同一高度,但是左边可能会稍大一点。这种梅克尔树就是用于一个区块交易的梅克尔化的,而顶层元素就是应用状态根。

                *
               / \
             /     \
           /         \
         /             \
        *               *
       / \             / \
      /   \           /   \
     /     \         /     \
    *       *       *       h6
   / \     / \     / \
  h0  h1  h2  h3  h4  h5

  A SimpleTree with 7 elements

IAVL+梅克尔树

IAVL+数据结构的目的是永久储存应用状态中的密钥-值,这样具有决定功能的梅克尔根哈希就可以有效进行运算了。这个树的平衡通过 AVL算法的一个变量来达到,所有运行都是O(log(n))。

在AVL树中,任意节点两个子树的高度至少有一处不同。无论什么时候出现更新来打破这种情况,这个树都会通过创造O(log(n))新节点(指向旧树上未修改的节点)来再次达到平衡。在初始AVL算法中,内部节点也可以维持密钥-值。AVL+算法(注意这里有个"+"号)对AVL算法进行了修改,来维持所有树叶节点上的值,同时还只需采用分支-节点来存储密钥。这一点在简化算法的同时,还能维持较短的梅克尔哈希轨迹。

AVL+树类似于以太坊的 Patricia tries(帕氏树)。其中也有一定的折中。密钥不需要在嵌入到IAVL+树前生成哈希,而这个就为密钥空间里提供了较快的命令迭代,或许为很多应用程序都带去了好处。逻辑实现很简单,只需要两种节点——内部节点和树叶节点。作为一个平衡的二进制树,梅克尔证明算是短的。而另一方面,IAVL+树有取决于命令的更新。

我们将支持额外有效的梅克尔树,比如以太坊的帕氏树,同时实现二进制变量的可用性。

10.9交易类型

在标准实现中,交易通过TMSP界面流入Cosmos Hub的应用程序。

Cosmos Hub将接受几类主要交易,包括SendTx,BondTx,UnbondTx,ReportHackTx,SlashTx,BurnAtomTx,ProposalCreateTx,以及ProposalVoteTx(即发送交易、绑定交易、解绑交易、攻击报告交易、削减交易、Atom燃烧交易,创建提议交易),这些都不需要加以寿命,会在之后文章更新中进行归档。这里我们主要列举两个主要的IBC交易类型:IBCBlockCommitTx 以及IBCPacketTx(即IBC区块提交交易以及IBC包交易)

IBCBlockCommitTx(IBC区块提交交易)

IBCBlockCommitTx 交易主要由这些组成:

  • ChainID (string): 区块链ID

  • BlockHash ([]byte): 区块哈希字节,就是梅克尔根(包括应用程序哈希)

  • BlockPartsHeader (PartSetHeader): 区块部分设置的头字节,只用于验证投票签名

  • BlockHeight (int): 提交高度

  • BlockRound (int): 提交回合

  • Commit ([]Vote): 超过⅔的Tendermint预提交投票,以组成区块提交项

  • ValidatorsHash ([]byte): 新验证组的梅克尔树根哈希

  • ValidatorsHashProof (SimpleProof): 简易版梅克尔树证明,在区块哈希中证明验证人哈希

  • AppHash ([]byte): IAVL树,应用程序状态的梅克尔树根哈希

  • AppHashProof (SimpleProof): 简易版梅克尔树证明,在区块哈希中验证应用程序哈希

IBCPacketTx(IBC包交易)

IBCPacket 由下列项组成:

  • Header (IBCPacketHeader): 包头

  • Payload ([]byte): 包有效负荷字节。可选择。

  • PayloadHash ([]byte): 包字节哈希。可选择。

有效负荷或有效负荷哈希必须存在一个。IBCPacket 的哈希就是两个项的简易版梅克尔根,即头和有效负荷。没有完整有效负荷的IBCPacket 被称作缩写版包。

IBCPacketHeader由下列项组成:

  • SrcChainID (string): 源区块链ID

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

  • Number (int): 所有包特定数量

  • Status (enum): 可以是AckPending,AckSent,AckReceived,NoAck,或Timeout任意一个

  • Type (string): 种类根据应用程序决定。Cosmos保留"coin"(币)包种类。

  • MaxHeight (int): 如果状态不是这个高度给出的NoAckWanted 或者AckReceived ,那么状态就算超时。可选择。

IBCPacketTx 交易有下列项组成:

  • FromChainID (string): 区块链ID,用于提供这个包,不是必要的来源

  • FromBlockHeight (int): 区块链高度,其中接下来的包会包含在源链的区块哈希中

  • Packet (IBCPacket): 数据包,其状态可以是AckPending,AckSent,AckReceived,NoAck,或Timeout任意一个

  • PacketProof (IAVLProof): IAVL树梅克尔证明,用于一定高度的源链中的应用哈希中验证包的哈希

通过"Hub",从"Zone1"发送到"Zone2"的包的序列会用{Figure X}函数进行描述。首先一次IBCPacketTx会向"Hub"证明包是包含在"Zone1"的应用程序状态中。然后,另一次IBCPacketTx 会向"Zone2"证明包包含在"Hub"的应用程序状态中。在这个过程中,IBCPacketTx 的域是一样的:SrcChainID永远是"Zone1"而DstChainID 永远是"Zone2"。

PacketProof 必须有正确的梅克尔证明路径,如下:

IBC/<SrcChainID>/<DstChainID>/<Number>

当"Zone1"想要向"Zone2"通过"Hub"发送证明,那么IBCPacket 的数据是相同的,无论这个包是在"Zone1"、 "Hub"还是"Zone2"上梅克尔化的。唯一可变的域只有追踪交付的Status (状态),如下所示。

鸣谢

感谢朋友及同行在概念成型与检查方面提供的帮助,以及对我们同Tendermint及Cosmos工作的支持。

关于我们

“因特链” 致力于打造国内最具前瞻性的区块链和跨链技术社区目前主要讨论的公有链项目有Cosmos、Polkadot、EOS、IPFS、Dfinity、Plasma、0xproject、KyberNetwork等。

公司

 联系我们

 浙江-杭州

 lipeng@chainx.org

【浙ICP备17025508号-1】