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
