Plasma是一系列协议，允许个人轻松部署高吞吐量，安全的区块链。即使“Plasma”完全恶意行事，以太坊主链上的智能合约也可以确保用户的资金安全。这消除了对像侧链那样的可靠挂钩机制的需要。Plasma是非监管的，允许在不牺牲安全性的情况下确定可扩展性的优先级。

我们设想了许多Plasma的未来，让用户可以自由选择交易地点。因此，在发布我们的Plasma实施的同时，我们创建了PlasmaRegistry.vy。注册表允许新链通过列出其IP / DNS地址，自定义“名称”字符串及其合同地址来加入网络。注册管理机构合同会验证可信部署，因此用户可以放心，注册管理机构上的任何合同都可以安全存入 。

这篇文章主要说明Plasma目前的协议、进展和来自研究界的最新发展。

Plasma具有以下属性：

• Plasma Cash中的“固定面额”问题。
• 区块大小是随交易数量而变化，而不是存款数量。
• 轻客户端证明，其以区块大小的对数进行缩放和区块线性存储，使得运算符成为系统唯一的（计算）瓶颈。
• 退出过程，允许出口仅指定最近的事务，而不是事务及其父事务。
• 链间原子交换，为分散交换协议奠定了基础。
• 无限存款容量。

• 用Javascript编写的命令行Plasma 操作符。
• 用Javascript编写的Plasma 客户端实现并带有命令行钱包。
• 支持使用Vyper编写的ETH和ERC20令牌的智能合约。
• 集成的JSON RPC，允许客户端下载和验证轻客户端证明和交易。
• Plasma 操作员块浏览器。
• 模拟客户端群，生成要加载测试的事务。
• Plasma “注册”合同，列出了一组经过验证的安全合同和运营商IP地址供用户探索。

我们的Github根据MIT许可提供我们的所有实施：

plasma操作员：启动自己的plasma并部署到testnet。

plasma-core：核心plasma客户端功能 - 兼顾逻辑。

plasma-node：用于实现CLI的plasma-core的Node.js包装器

plasma-js-lib：用于构建集成plasma事务的Web应用程序的JS帮助程序。

plasma合约：PlasmaChain.vy和PlasmaRegistry.vy Vyper合约。

plasma-explorer：由运营商托管的块浏览器。

plasma-utils：用于建立plasma规格的共享实用程序。

plasma：上述组件的集成测试。

以下是plasma-core实现的架构：

plasma操作员实现的架构：

1、一般定义和数据结构

本节将介绍协议组件的术语。这些数据结构由plasma utils的库序列化进行编码和解码。在模式中可以找到每个结构的所有数据结构的精确字节/字节二进制表示。

代币ID分配

任何plasma 资产的基本单位表示为硬币，与标准的plasma cash一样，这些硬币是不可替代的，我们将代币的索引称为coinID，16字节。它们按照每个资产（ERC 20 / ETH）的存款顺序分配。值得注意的是，链中的所有资产共享相同的ID空间，即使它们是不同的ERC20或ETH。这意味着跨所有资产类（我们称之为tokenType或token）的事务共享同一个树，从而提供最大压缩。

我们通过让前4个字节引用硬币的tokenType来实现这一点，接下来的12个代表该特定tokenType的所有可能硬币。

例如：第0个tokenType始终为ETH，因此第一个ETH存款将给予存款人硬币0x00000000000000000000000000000000的支出权利。

每次存款收到的总硬币精确地（存放的令牌数量）/（最小标记面额）很多。

例如：假设tokenType 1为DAI，硬币面额为0.1 DAI，第一个存款人发送0.5 DAI。这意味着它的tokenType == 1，因此第一个存款人将从0x00000001000000000000000000000000收到coinID，包括硬币0x00000001000000000000000000000004。

面额

实际上，面额将远远低于0.1。它不直接在合同中存储面额，而是为每种标记类型存储一个小数集映射，表示存放的ERC20（或ETH的WEI）数量与收到的等离子币数量之间的小数点移位。这些计算可以在智能合约中的Depositerc20、Depositeth和FinalizeExit函数中找到。

//注意：对于此版本，decimalOfsets被硬编码为0，因为我们在客户端/操作员代码中缺乏支持。

2、硬币的交易范围内

转移

事务由指定的块编号和Transfer对象数组组成，它们描述了每个事务范围的详细信息。 来自plasma-utils中的模式（长度，以字节为单位）：

我们可以看到，事务中的每个Transfer都指定了tokenType，start，end，sender和recipient。

类型化和非类型化界限

上面要注意的一点是，起始值和结束值不是像coinid那样的16个字节，而是12个字节。在上述有关存款的章节中，这应该是有意义的。为了获得传输描述的实际coinID，我们将令牌字段的4个字节连接到start和end的左边。我们通常将12字节版本称为transfer的untypedStart和untypedEnd，其中连接版本称为typedStart和typedEnd。这些值也由序列化器公开。

另一个注意事项：在任何转移中，相应的coinID定义为包含start和end exclusive。也就是说，传输的确切coinID是[typedStart，typedEnd]。例如，前100个ETH硬币可以使用Transfer传输，其中transfer.token = 0，transfer.start = 0，transfer.end = 100.第二个100将具有transfer.start = 100和transfer.end = 200 。

多重和转移/交易原子性

事务模式由一个4字节的块编号组成（事务只有在特定的等离子块中包含时才有效）和一个Transfer对象数组。这意味着事务可以描述多个传输，这些传输要么全部原子执行，要么不依赖于整个事务的包含和有效性。这将成为后续版本中分散交换和碎片整理的基础。

序列化

如上所示，plasma-utils实现了用于数据结构的自定义序列化库。 JSON RPC和智能合约都使用由序列化程序编码的字节数组。

编码非常简单，每个值的串联，固定为模式定义的字节数。

对于涉及可变大小数组的编码，例如包含一个或多个传输的事务对象，单个字节数先于单个字节。 可以在此处找到序列化库的测试。

目前，我们有以下对象的模式：

• Transfer
• UnsignedTransaction
• Signature
• SignedTransaction
• TransferProof
• TransactionProof

海纳学院的内容将围绕：区块链技术，产品社群，经济模型等全方位的知识体系输出。欢迎联系作者微信：csschan1120