RSK【 Unitrie 提案】的的优点

RSK 诞生于 2015 年，当时作为一种以太坊兼容比特币侧链。回到 2016 年，RSK 侧链当时仍然处在开发阶段，改进并简化其设计，更换了一个关键以太坊组件：账户 trie，在以太坊黄皮书中也称作 world state。world-state trie 是以太坊式区块链中的主数据库，其支持数据结构称作 Secure Modified Patricia Trie。RSK设计了一种替代状态数据结构，该结构后来演变为现在所谓的 Unitrie，那么有什么优点呢，请看下文。

①缩短会员资格证明

通过采用二进制 trie 代替 radix-16 trie，可尽最大可能缩短 RSK trie 中账户的会员资格证明，同时，验证其会员资格证明需要的时间也接近最优水平。这样可实现分散化轻量节点、在移动电话上运行、消耗更少的带宽以及更低的功率。在下面的示例图中，radix-16 rie 需要 30 个指针（实心圆）和 3 个节点（圆圈）来证明存在目标节点（蓝色圈）。radix-2 trie 仅需要 8 个指针和 8 个节点。传输节点时不需要传输父参考，因为可动态计算其参考，因此，二进制 trie 证明需要的空间是 radix-16 trie 的 26%，radix-16 与 radix-2 trie 会员资格证明的比较：

②通过压缩账户节点减小状态大小

Unitrie 中的账户既不需要存储“存储”trie 根散列摘要，也不需要存储代码散列摘要，这意味着从状态中几乎移除了 60% 的账户数据。例如，存储 1 个 RBTC 的账户使用约 38 个字节，而以太坊中使用 104 个字节。下图显示移除不必要的字段节省的大致空间，通过移除不必要的字段压缩账户节点：

③通过嵌入小节点减小状态大小

对于大小小于 ~44 个字节（准确值待定）的子节点，Unitrie 提供将其直接嵌入父节点的功能。此功能在 RSKIP107 中说明。 由于大部分账户最终的节点大小范围均为 31 至 41 字节，这意味着大部分账户将嵌入父节点中。这样可降低账户间接费用达 62%。通过节点嵌入以及缩短账户记录实现的账户大小减小达 81%，这样不仅可减少完整节点的同步时间和资源需求，而且还可降低 DoS 攻击风险（通过创建账户刷屏状态）。下面的示例图显示以太坊 trie 中有两个子节点的节点如何转换为 Unitrie 中嵌入子节点的单个节点，将两个小节点嵌入其父节点：

④通过压缩存储单元密钥减小状态大小并降低 Gas 费用

RSKIP108 介绍存储密钥具有一长串零前缀时可以怎样压缩存储单元。具有单字节地址以及存储单个字节的单元最多可压缩至之前未压缩大小的 10%，因为其尺寸小，也可实现节点嵌入。为了激励用户使用压缩存储，RSKIP109 更新了合约存储写入操作的成本。例如，在地址 0x00 存储 0x01 会使用低至 5460 gas 单位，而以太坊中为 20K。下图说明以太坊和 Unitrie 中存储单元地址 0x01 使用的不同密钥，密钥存储压缩示例：

⑤配合并行事务处理时具有更好的可扩展性

RSKIP04 建议采用并行事务处理以减少块处理时间。通过减少块处理时间，可以更快地传播块并改进共识。这也意味着可以将更多的事务纳入块中而不延迟块传播。通常，相对于较小的挖矿池，较高的块传播延迟有利于最大的的挖矿池，然而，如果事务可以拆分为合约状态访问不重叠的集合，则区块链只能从并行事务处理中获益。如果所有事务均调用某个单个令牌合约，则该合约强制事务序列化并成为瓶颈。其中一个解决方案（如 RSKIP59中所规定）是，在设计合约时使合约存储单元移入子合约，从而创建父子关系。然后，将不同用户的令牌余额存储于不同的合约中。该解决方案仍然需要重新设计和重新实施合约以强制特定设计模式的用户启用可扩展性。但 Unitrie 有可能解决该问题，并且没有使用新模式的相关障碍。Unitrie 启用同时访问存储单元简化检测，而非仅检测同时访问完整合约。这意味着只要两个合约不写入同一存储单元（或一个合约读取另一个合约写入的存储单元），则两个合约可同时执行。例如，ERC20 合约通常仅修改与源账户和目标账户相关的单元，因此，这些合约会通过单元级检测获取立即并行处理的能力。虽然没有 Unitrie 也可以实现同样的功能，但 Unitrie 可大大简化写入冲突检测算法。以下图为例来介绍处理事务的两个线程。第一个线程修改合约 C 的某个单元（通过紫色箭头指示），它不受线程 2 的影响。而线程 2 修改同一合约的另外两个单元，它不影响线程 1 修改的单元，两个执行线程修改同一合约存储：

⑥与存储租金组合时更加公平

以太坊设计的其中一个结果是，它启用 gas 套利，用户可通过该功能预购和占有存储单元而不存储任何有用数据，只是在晚些时候清空这些单元以便重新获得最初用于购买这些单元的部分 gas，然后将该 gas 出售给第三方。另一个非计划结果是，以太坊需要高额预付款以便使用新的存储单元，因为此付款主要用于密钥/值对的永久性存储和活性保证。

存储租金可同时缓解这两个问题。讨论最多且广为接受的存储租金形式需要用户与合约交互，以便支付与上述合约不活动的时间成比例的费用，该费用也与不活动时间期间合约使用的存储空间成比例。RSKIP61 建议采用合约租金，以防止原始 EVM 设计的部分不受欢迎结果影响平台公平。虽然这样可提供大致的公平性，但是它只是一个粗略框架，并且在极端情况下效果不佳。许多人拥有的合约存储数百万条密钥/值对但很少使用的情况将导致长时间不活动周期后第一个调用的用户产生巨大存储租金负担。Unitrie 可简化单个存储单元跟踪最后访问时间的任务，从而细化存储租金，允许合约仅支付调用执行涉及的单元的租金。这种简化（在 RSKIP113 中详述）源自平等对待所有节点，因此，账户、代码和存储单元可在被访问时收取租金。

⑦通过简化状态垃圾收集提高完整性

状态垃圾收集指清除正常情况下因已覆盖而绝不会再次被引用的旧状态数据。在区块链重大重组等异常情况下，可通过从预先计算的状态检查点重新执行旧块来重新计算此数据。但是，以太坊中的垃圾收集非常重要，因为它必须应用到许多单独的数据库（或 trie），每个活动合约一个。采用 Unitrie 意味着垃圾收集应用到单个数据库，从而降低有可能在垃圾收集过程中更改数据库而使其处于不连贯状态的线程中断风险。

⑧状态同步更快、更简单

许多应用都需要在特定块高度查询区块链的状态，包括轻量级钱包和区块链桥等。Unitrie 采用二进制结构，使用空间最少，检索和证明该状态下数据会员资格的性能最高。它还可降低传输状态信息所涉及网络命令的复杂性。

然而，最为重要的是，Untrie 可启用快速并行下载状态信息以执行“快速同步”或“曲线同步”。 如果所有信息均存储在单个 trie 中，则节点可更高效地检索状态信息。由于 Unitrie 存储位于每个子节点的子树使用的字节个数，因此，Unitrie 数据结构支持尺寸范围查询。此功能可用于同级请求特定大小的 trie“包”，从任何字节偏移开始均可。因此，请求可以负载平衡良好的方式并行。例如，某个节点可以收集来自 10 个节点的状态信息，并依次请求字节范围 0K 至 100K、100K 至 200K 等，以此类推。这样可允许创建同步模式时兼具快速同步（立即验证返回的数据）和曲线同步（同时从多个源检索大数据块）两者的优点。下图为示例 Unitrie 显示节点子树大小的情况。trie 可被拆分为三个块，各包含几乎等量的数据，每个块均可被不同的同级请求。即使请求者不知道每个块的内容和限制，请求者也可提前了解块的大小。收到块时可高效、分别验证每个块。部分内部节点包括于一个以上的块中，以便启用验证。而 Unitrie 的另一个巨大优势在于，通过存储 trie 节点大小，网络节点可以显示状态同步完成百分比，并预估完成同步的剩余时间。

⑨较小的区块链通过自动代码消除重复

通过将存储单元和代码组合至单个内容寻址数据库中，包含相同密钥/值的节点在该数据库中仅存储一次。这样可提供自动数据去重复功能，对于合约代码，该功能可减少区块链大小，并且不需要单独的去重复机制，也不需要使用数据压缩技术。trie 中的代码节点将始终包含相同的前缀 (0x80)；因此，相同的代码意味着相同的节点散列和相同的存储。

⑩EXTCODESIZE 执行更快

每个 Unitrie 节点均包含一个字段，缓存该节点中所存储数据的大小。在以太坊 trie 中，查询节点数据大小时强制从数据库提取该数据。Unitrie 可通常查询此新字段响应大小查询，例如 EXTCODESIZE 运算码生成的查询，无需从硬盘提取该代码。EXTCODESIZE 运算码过去在某些以太坊实施中一直用于执行 DoS 攻击，而 Unitrie 对这种攻击提供免疫力。

总结

RSK 在 2016 年提出的 Unitrie 可显著改进 RSK 等基于账户的区块链中的状态存储，提供明显更好的完整节点性能。Unitrie 通过降低完整节点资源要求改进分散化效果，通过启用更好的并行事务执行提高事务产量，通过缓存有效负载大小并减小账户尺寸防止 DoS 攻击，通过启用更好的存储租金提高公平性，并通过压缩状态减少同步时间。RSK深知执行网络升级以采用 Unitrie 具有挑战性，RSK依然接受挑战，RSK愿意付出巨大努力（时间和金钱）以减少整个节点的资源消耗，RSK创造【 Unitrie 提案】 以便个人可以在标准笔记本电

—-

编译者/作者：老韭菜一代

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。