星期六 , 4月 20 2024
首页 / 区块之心 / 技术指南 | Plasma Cash区块结构的规范

技术指南 | Plasma Cash区块结构的规范

Plasma Cash推出的最重要的改进之一是“light proofs”。Plasma 结构要求用户下载整个Plasma 链,以确保他们的资金安全。使用Plasma Cash,他们只需下载与自己资金相关的Merkle树枝。

这是通过引入一个新的事务有效性条件来实现的:特定CoinID的事务只在Merkle树的CoinIdth叶中有效。因此,只下载该分支就足够确信该硬币不存在有效的交易。这个方案的问题在于,交易是“卡”在这个面额上的:如果你想交易多个硬币,你需要多个交易。

如果我们将基于范围的事务放入常规Merkle树的分支中,则light proofs就变得不安全。这是因为有一个分支并不能保证其他分支不相交:

第4和第6叶都描述了范围内的交易(3,4)。有一个分支并不保证另一个分支不存在。

使用常规Merkle树,保证没有其他分支相交的唯一方法是将它们全部下载并检查。但那已经不再是light proofs!

我们的Plasma实现的核心是一个新的块结构,以及一个伴随的新事务有效性条件,它允许我们为基于范围的事务获得light proofs。块结构称为Merkle sum树,其中每个散列旁边是和值。

新的有效性条件使用特定分支的和值来计算开始和结束范围。这种计算是经过精心设计的,因此两个分支的计算范围不可能重叠。转移只有在其自身范围在该范围内时才有效,因此这将使我们返回我们的轻客户!

本节将详细说明sum tree的规范、范围计算的内容以及如何实际构造满足范围的sum tree。

我们已经编写了Plasma-Merkle sum tree的两个实现方法:一个是在操作员的数据库中完成,另一个是在内存中用于在Plasma实用程序中测试。

 

sum tree 节点规范

Merkle sum树中的每个节点都是48个字节,如下所示:

[32 byte hash][16 byte sum]

总和的16字节长度与coinID相同并不是巧合!

我们有两个辅助属性,.hash和.sum,这两个属性将引出这两个部分。

例如,对于somenode = 0x1b2e79791f28c27ed669f257397e1deb3e522cf1f27024c161b619d276a25315ffffffffffffffffffffffffffffffffff

我们有node.hash == 0x1b2e79791f28c27ed669f257397e1deb3e522cf1f27024c161b619d276a25315和node.sum == 0xffffffffffffffffffffffffffffffffff。

 

父级计算

在一个规则的merkle树中,我们构造一个哈希节点的二叉树,直到一个根节点。指定和树格式是一个简单的问题,即定义父(左,右)计算函数,该函数接受两个兄弟作为参数。

例如,常规Merkle sum树具有:parent = function(left,right){return Sha3(left.concat(right))}其中Sha3是哈希函数,concat将这两个值附加在一起。

若要创建merkle sum tree,父函数还必须连接其子函数的加法运算结果。sum值:

注意parent.hash对每个sibling.sum和hashes是一种承诺:我们对两者的完整96个字节进行哈希处理。

 

计算分支的范围

我们使用Merkle sum tree的原因是因为它允许我们计算分支描述的特定范围,并且100%确信不存在其他有效的重叠分支。

我们通过在分支上加上左和右和来计算这个范围。在每个父级计算中,将两者初始化为0。如果包含证明指定了右侧的同级,则取right sum+=right.sum;如果将left sum+=left.sum添加到左侧,则取left sum+=left.sum。

然后,分支描述的范围是[leftsum,root.sum-rightsum]。请参见以下示例:

在本例中,分支6的有效范围是[21+3,36–5)==[24,31]。注意31–24=7,这是叶6的总和值!同样,分支5的有效范围是[21,36-(7+5))==[21,24)。注意它的结束和分支6的开始是一样的!

你会发现构造一个Merkle sum tree是不可能的,它有两个不同的分支覆盖相同的范围。在树的某个层面,总和必须被打破!尝试通过制作另一个与范围(4.5,6)相交的分支来“欺骗”叶子5或6。仅填写灰色框中的?

 

你会发现,在树的某个层次上,这是不可能的:

这就是我们获得轻客户的方式。我们将分支范围称为implicitStart和implicitEnd,因为它们是从包含证明中“隐式地”计算的。我们在plasma-utils中通过calculateRootAndBounds()实现了一个分支检查器,用于测试和客户端证明检查:

在Vyper中使用智能合约

请注意,键入的范围是开始和结束,即完整的16个字节。

在常规Merkle树中,我们通过散列“叶子”构建底层节点:

给定一个带有单个transfera的txa,和值应该是什么?事实证明,不仅仅是transfera.end-transfera.start。原因是,如果传输不接触,它会破坏分支的范围。我们需要“填充”sum值来解释这个间隙,否则root.sum将太小。

有趣的是,这是一个非确定性的选择,因为您可以将节点填充到间隙的右侧或左侧。 我们选择了以下“左对齐”方案来将叶子解析为块:

我们将最底层的.sum值称为该分支的parsedSum,而TransferProof模式包含一个.parsedSum值,用于重建底部节点。

 

分支有效性和隐含NoTx

因此,由智能合约检查的分支的有效性条件如下:implicitStart <= transfer.typedStart <transfer.typedEnd <= implicitEnd。注意,在“Plasma CashFlow”中的和树的原始设计中,一些叶子被填充了一个特殊的“notx”事务,以表示范围没有被处理。使用这种格式,不进行交易的钱币仅为[implicitstart,transfer.typedstart]和[transfer.typednd,implicitend]范围内的钱币。智能合约保证这些范围内的硬币不能用于任何挑战或对退出的反应。

 

原子性多发(Atomic Multisends)

通常(为了支持交易费用和交换)交易要求多次转移要么发生或要么不发生,结果是每个.transfer需要包含一次有效的事务 – 每个.transfer都有一个与特定transfer.typedStart和.typedEnd相关的有效总和。但是,对于这些包含中的每一个,它仍然是完整的UnsignedTransaction的哈希 – 而不是被解析到底部的单个Transfer.hash。

关于 冯先生失眠中

冯先生失眠中
卷而怀之

检查

区块链,只是金融发展的延续吗?

区块链诞生于 2008 年的那 …

发表评论

邮箱地址不会被公开。 必填项已用*标注