RChain中的成本核算（Cost Accounting）

RChain微博：RChain官方

该文稿来源于RCast第54期，讨论了RChain中的一个重要功能：成本核算（cost accounting）。每周Greg与RChain爱好者进行关于RChain技术的对话，以帮助社区更好了解Rholang语言、RSpace以及Casper等核心技术构件。

Greg: 我们本来打算讨论反射证明理论，该理论进展得十分顺利。但因为我们刚刚发布了Testnet-3，所以我想来谈谈它的主要功能，它对网络的意义以及它与整个开发过程之间的关系。

Isaac: 听上去不错。

Greg: 还记得我们谈论过Polkadot（以及其他一些网络），并试图进行分析和比较吗？

Isaac: 对。

Greg: 我们谈到了一项指导原则，那就是一切都与数据相关。如果你建立的网络可以很好地处理数据，那么你就可以专攻支付，反过来就要困难得多。如果你建立了一个针对支付进行了优化处理的网络，然后尝试扩展到数据，那么就会遇到很多支付网络中所不存在的问题。

Isaac: 很有道理。

Greg: 如果我们从那里开始做起，那么你要做的第一件事就是要先创建巨量存储。Ravi实际上已经开始做了。如果你考虑一下Rholang和RSpace，那么你会发现这是一个令人难以置信的NoSQL数据库。它对所有现有的NoSQL数据库都有帮助，由于它提供了三样东西。

第一：它可以存储连续（即代码）以及数据。如果你想要实现一些很棒的功能，这就能向前迈出一大步。它可以回溯到SQL中的存储过程。所有人都在说不要使用存储过程。然后，当他们优化存储时，他们最终还是会使用存储过程。它的进程更“干净”，这样就不会遇到存储过程为SQL数据库所带来的很多问题。此外，大多数NoSQL数据库都不具备SQL那样语义严格的查询语言。

这确实有问题，原因很多，我相信在生产中使用过此类存储的人都可以作证。在运行代码之前，你实际上并不知道代码将会执行怎样的操作。SQL数据库的查询语言具有非常清晰的语义。你知道自己的查询会做什么。原理和实践之间通常会有些差距。你在每一次构建真实系统时都必须要考虑到这一点。通常来说，人们都会从SQL清晰明确的定义中受益。这就是我们所提供的。

如果你能正确看待Rholang，你就会发现它是一种非常精美的查询语言。这是因为Rholang执行语义是直接映射到RSpace存储语义上的。两种语义处于同步状态，这就是按构造校正（correct by construction）的要点。我们从RSpace语义中提取Rholang语义，或反过来，从抽象Rholang语义中提取RSpace存储语义。因为它们是同构的，所以有各种优势，例如不会有代码注入攻击和其他类似情况产生。这就你能从这种精妙存储中所能获得的第二项好处。

最后，它可以提供并发执行。SQL也提供并发执行，但是程序员无法控制并发，因为他没有（除了锁定之外）直接可用的并发机制。我们不使用锁定规则，而是提供了Rho演算中的comm规则，因为基本交易机制和基本并发机制都是融合在一起的。

如果你仅仅将其视为存储，那么我们还有另一个优势。实际上，如果想要了解RChain发展过程，这就是我们所要做的第一步。我们构建了RSpace，Rholang和Rholang解释器。这是主要发布之一。它不是零节点，而是接近零。这样说能明白吗？

Isaac: 明白了。我从没将Rholang看作是一种查询语言，但是根据你的描述来看，这很有道理。你之前曾经说它是一种规范语言，我认为这是一个很酷的主意，但我从未想到过将它作为查询语言。

Greg: 只要模式匹配，这就是一种非常精美的查询语言。通过键值进入数据结构，它就是一种非常强大的查询语言。

这是发展的第一步，你可以将它基本上看作一个独立事件。你可以在计算机上运行Rholang和RSpace，你的客户也可以同时接触。他们可以将该存储用作独立实例来存储和检索数据。

下一步是要有此类存储的多个实例。我们的努力方向是要复制正确的容错存储。在两个实例之间放置一个comms层，该comms层使用的是art实施，其最上端的传输协议具有很多不错的功能。

本质上，这并不是什么高难度科学。就art而言，目前没有任何改进或推动，只是在传输层方面进行一些改进，然后加以实现并使其生效——而这也算不算是高难度，只是一种很好的分解和抽象方法。这就是Rholang和RSpace以及comms的本质，而这也再次对应于RChain开发中的特定发布。

Isaac: comms层与共识没有任何关系，它只发生在Casper领域。

Greg: 没错。共识都在Casper。现在，你已经有了两个连接的实例。如果他们互相跳过或者对源代码有分歧，则由程序员来处理。但这点非常好。紧接着就是下一步。

下一步是建立共识层。如果您希望所有这些实例在本质上都能互相协调，以便它们都同意所存储内容，那么就需要建一个共识层。这就是CBC Casper所提供的。对于不了解Casper细节的人来说，Casper的核心就是区块的合理性结构。每个区块都有来自先前块的对齐指针，因此你可以通过这种方法对模糊性和其他情况进行检测，从而确保安全。

同样的结构还可用于施加同步约束和公平约束，这就是Casper的与众不同之处，它可以按其执行方式来执行。Casper可以用来就任何事情达成共识，因为它实际上并不关心这项共识是什么。Casper在RChain中的作用是确保所有节点都对比赛的获胜者达成协议。只要实现这一点，就可以实现容错分布式计算机。

Isaac: 只要确保我们以一致的方式使用资源即可。

Greg: 完全正确。你最终会用到的是Rholang，RSpace，comms和CBC Casper，它们可以提供分布式容错数据存储。这在分布式系统世界中是很酷的。像SAP这样的公司发明出这些，并将其推向全世界，比如SAP HANA。但SAP HANA可不具备我们目前为止所列出的所有功能。

顺便说一句，有一个特定版本是包含了Casper所有内容的。我很希望自己能提供这个版本号，但我一下子背不出来。很多事项都可以并行完成：你可以边做comms层边用Rholang和RSpace，也可以独立执行一堆Casper。但最终，你必须将这些部分组装起来。如果查看RChain的发布时间表，你会发现它与我所描述的线性路径并不完全对应，但也已经很接近了。

回到我们的拒绝服务问题。为了防止拒绝服务，你要做的就是允许攻击者付费使用计算和存储。可以使用Rholang计算和RSpace存储。在执行计算步骤（通信事件）或进行存储步骤时，最终都要落实到价格上。现在，任何尝试使用DOS网络的人都必须为攻击支付费用。

顺便说一句，我所谈论的所有内容（除了并发语义和类似事项之外）都是行业标准。即使是Guardian的数据访问权或Google，所有这些数据点都会被代币化。每当他们出现在互联网上时，你都必须使用代币以获得访问权限。代币仅限于一定数量的请求。那是在诸如比特币之类的代币出现之前。人们一在网络上放置好东西后，便立即被DOS。

Isaac: 你的意思是那是为了防止DOS攻击，对吗？

Greg: 是的。这是我们长久以来都知晓的。正是这种洞察力，结合了将在线服务代币化的想法并将其与由区块链等等服务所提供的微交易结构相结合，帮助你向着创新又迈出了一步——因为你现在有了微交易架构。可以想象Amazon AWS工程师可能会用此架构来做一些事情；他们可能正在为自己没能这么做而懊悔不已呢——毕竟在过去的15年中，这个机会一直都存在着。

这就是Testnet-3：添加成本核算结构，使攻击者无法DOS网络。他们必须为攻击付出代价。这会直接影响网络的吞吐量。特别是，如果你不做成本核算方法就可以轻松合并发生comm事件的模块，因为大多数comm事件是完全分开的。在合并两个区块时，你只需要检查并查看它们没有提到相同的名称即可。

Isaac: “分开”的意思是他们不会争夺同一个资源，彼此完全无关。

Greg: 这有些微妙。如果遵循特定的规则，你甚至可以将具有相同名称的区块合并起来。Mike Stay已经将所有这些情况都分析过，并列出了这个巨大的电子表单中所有可能发生冲突以及可以安全合并块的情况。顺便一说，该分析直接出自Rholang结构，它在名称中的使用正好可以确定合并块方式。

Isaac: 你所说的是超越了简单的同名称之外的可合并性。

Greg: 是的，但比这更微妙一些。线性接收和发送可以更新值。什么时候才能安全地与其他项进行合并呢？诸如此类的问题。我们没有Mike的完整表单，也不具备对vault架构（RChain维护该账户架构以进行成本核算）的完整支持。但这个问题已经解决，所以我们可以分开了。

如果你只有一个账户而每个人都在往里存入，那有问题了。但是，如果每个验证者都有一个帐户，则可以在最大程度上减少冲突。你可以将通过这种方式收集数据的REV库进行分片。这基本上就是大钱包下的子钱包，大钱包拥有所收集的、作为客户成本会计应用的一部分的所有REV。这样说能明白吗？

Isaac: 是的，我想我明白了。你说的是一种攻击，而这种攻击与将所有帐户用户分开的解决方案相关？

Greg: 不，我只是说我们没有这样做。因为这个原因，目前我们无法合并区块。必须要有一个单一的上层网络，先把它放进去，然后才能做其他事情，这就说回到合并区块了。而这将大大提高网络吞吐量。

Isaac: 吞吐量会增大是因为你不想仅对一个帐户进行更改。而现在你有几个不同的帐户，而且在大多数情况下它们彼此之间并没有任何关系。

Greg: 正是如此。你之所以能够获得额外的吞吐量，是因为你有一些大家都同意的区块，但两个不同的验证器是以不同速度运行的，它们都可以在该区块的顶部构建新区块，然后提交。之后，第三个验证器将同时获得这两个区块，并说：“与其序列化，不如将它们合并。”

只要保持主动合并的成本相对较低，就不会有问题——如果逻辑开始膨胀，那么问题就来了；此时最好对它们进行排序化。只要逻辑不超出比例，合并就会带来更高的吞吐量，而这会是一个很大的成功。随之而来的是成本后会计，这个我们已经说过了。我们正试着完成这些事情，然后就可以开始硬化了。

作为硬化工作的一部分，我们将采用RCat应用程序，并使用它来驱动整个网络。我们已经从RCat剥离了播放器客户端。这带来了显著的优势，那就是我们现在可以把它变成一个非常简单的客户端，只需敲击RCat请求资产即可。

RCat并不知道另一端是如何使用这些资产的。这使我们能够严格地处理RCat客户端网络。我们可以有一大堆资产，并使用对数据资产的请求来加载网络，这就又回到了我开头想要说的地方。

RSong和RCat的重点是演示：“如果数据为王，那么这就是一个处理数据的网络。”我们尽可能清晰地演示了这一点。现在，我们将回到该假设，并说明：“我们正在针对数据进行优化”，这可以使付款变得很容易，但我们要解决更棘手的问题。使用RCat进行此演示，尤其是作为难题的强化部分，将大有助益。

Isaac: 我的理解是，RCat就像RChain希望作为平台提供支持的一个样板资产管理DApp。强化的目的是为了确保我们拥有的所有功能都能够为我们希望RCat所能做到一切提供支持。

Greg: 完全正确。RCat是一个源自于RSong的资产管理系统。至于你存储了哪一类资产，这是完全不可知的。

我希望能做一个使用RCat的简单小应用程序。InkMe的想法是用户可以上传头像（自己的照片），然后就能做一个动作。他们所能做的就是给其他用户着色。他们只需用颜色标记用户的个人资料——调出色轮或蜡笔，选择一种颜色，然后说“现在我觉得你是蓝色的”或“现在我觉得你是红色的”。你不用说出那些颜色所代表的意义，那就是人们当下的感受。这也意味着用户可以调出自己的个人资料，并查看自己是如何被社区中其他人着色的。可能每个人都将他们染成红色。他们认为，关于红色及其与社区的互动方式已有共识。他们可以开始发现颜色的含义。

他们也可能被染成彩虹色，这取决于它们的交互方式。这不是一个输赢的游戏，而更像是发现颜色在社区中所代表的含义。这样的一个客户端非常简单，数据资产只有图片加上颜色标签，所以可以相对简单地完成。它提供的是一种测试网络的方法，同时也可能为人们带来很多乐趣。

Isaac: 你有什么想用Testnet-3做的事吗？

Greg: 是的，可能就在之后。一旦用Testnet-3解决了一些问题，我们就会将其标记为公开测试版，这将是强化工作的一部分。我们也许可以在这个标记网络上建立InkMe应用程序。

我很清楚，并不是每一个人都能了解开发过程以及设计基本原理。我只是想把它放置在那里，并且解释一下为什么会发展成这样。很多人不明白，为什么我们会在特定时间宣布完成了特定的目标。那是因为他们没有这种以数据为中心的视角。而这是我们一直在追求的。归根结底，这是因为我们认为人们应该对自己的数据负责，所以我们发自内心地想要支持这一运动。

Isaac: 这对我了解大局来说有很大的帮助。任何人都可以查看RNode所发布的各个版本中所有内容的一切细节，并查看进度和逻辑线。将所有这些小片段拼凑在一起一观全局，这是很困难的事情，但你在此为我们描述了这个大局。