Plasma Core的证明结构和检查

与传统的区块链系统不同，完整的Plasma节点不存储每一个交易，它们只需要存储与其拥有的资产相关的信息。这意味着发送者必须向接收者证明发送者实际上拥有给定的范围。一个完整的证明包含了足够的信息来保证，如果以太坊链本身不分叉，那么令牌可以在主链上赎回。

必须根据操作员提交给主链上智能合约的块哈希检查包含根。通过追踪证明方案中验证的保管链，从代币的初始存款到目前为止，保证了赎回能力。

Plasma Core采用了一种相对简单的方法来验证传入的事务证明。本节介绍该方法。

证明格式（Proof Format）

历史证明包括一组存款记录和相应交易的长清单以及相应的TransctionProofs。

plasma-utils暴露一个静态checkTransactionProof(transaction，transactionProof，root)方法，Plasma-core通过调用ProofService来使用它。

交易证明（Transaction Proof）

TransactionProof对象包含检查给定Transaction的有效性的所有必要信息。也就是说，它只是一个TransferProof对象的数组。根据上面关于原子多重的一节，当且仅当所有的TransferProofs都有效时，给定的TransactionProof才有效。

转移证明（Transfer Proof）

TransferProofs包含在正确的块编号中恢复包含与事务中给定Transfer相对应的有效分支所需的所有必要信息。这构成：

1. Merkle sum tree的实际节点，代表分支的完整`inclusionProof`

2. 用于计算分支跟踪的二进制路径的叶的索引

3. 上面的sum树规范中描述的已解析的bottom.sum

4. 特定发件人的签名

就像plasma-utils架构一样：

请注意，inclusionProof是一个可变长度数组，其大小取决于树的深度。

证明步骤（Proof steps）

从存款开始，验证过程的核心是将每个证明元素应用于当前“已验证”状态。如果任何证明元素没有导致有效的状态转换，我们必须拒绝证明。

应用每个证明元素的过程是公开的; 我们只是根据合同的监管规则要求在每个区块应用交易。

快照对象（Snapshot object）

我们跟踪历史拥有范围的方式称为快照。

快照代表了区块中范围的经过验证的所有者：

存款记录（Deposit records）

每个收到的范围必须来自相应的存款。

存款记录由其令牌、开始、结束、存款人和块号组成。

对于每个存款记录，验证者必须仔细检查以太坊以确认所声称的存款确实发生，并且在此期间没有发生退出。

验证快照数组将初始化为这些存储，每个snapshot.owner都是存储者。

接下来，我们应用所有给定的事务证明，相应地更新已验证的快照。对于每个事务和相应的TransactionProof，验证程序执行以下步骤：

1. 验证给定的证明元素是否有效。如果没有，提示错误

2. 对于交易中的每次转移，请执行以下操作：

a.“拆分”在transfer.typedstart、transfer.typend、implicitstart和implicitend上更新的任何快照。

b.增加所有结果验证快照的.block编号，这些快照的block编号等于transaction.block number-1;

c.对于在transfer.start和transfer.end之间的每个拆分快照：

i.验证snapshot.owner==transfer.from。如果没有，抛出一个错误。

ii.设置snapshot.owner=transfer.sender。

TransactionProof必须应用于递增的BlockNumber中。

一旦该操作被递归地应用于所有交易证明，客户可以通过搜索已验证快照中的所有元素(块号等于当前Plasma块，所有者等于其地址)来检查自己现在拥有的新硬币。

交易证明有效性（TransactionProof Validity）

上述步骤1中的交易有效性检查等同于检查智能合约的有效性条件。基于上面的和树规范的基本有效性检查如下：

1.检查事务编码是否格式正确。

2.对于每次转移和相应的转移证明：

a.检查签名是否解析为其transfer.sender地址

b.验证inclusionproof的根是否等于该Plasma块的根哈希，以及leafindex定义的二进制路径。

c.计算分支的implicitstart和implicitend，并验证implicitstart<=transfer.start