本文翻译自Nutzipper的文章： 'Why block merge matters and how RChain is solving the scalability problem.'
链接：https://rholang.github.io/blog/2021/02/13/rchain-merge/
本文旨在解释RChain如何实现水平扩展性，主要讲解RChain平台的一个关键技术：块合并。RChain实现了水平可扩展性，即：增加更多的节点，将会使区块链更快。这是其它区块链无法实现的。
区块链本质上就是一台计算机，由众多相互复制的节点组成。区块链有两个基本功能：利用加密学算法证明状态的变迁，利用经济学手段对企图进行欺骗的行为进行惩罚。本文涉及第一个基本功能：状态变迁。
早期的区块链实现了公共账本功能。公共账本记录了大家的帐户余额。但仅有账户余额不好玩，所以更复杂的模型不断推出，比如比特币的UTXO等等。
以太坊开发的EVM模型是图灵完备的状态机，可以跑智能合约，而不只是记录账户余额的改变。矿工或者节点验证者负责记录状态的变迁、记录账户余额，打包交易和运行智能合约。在POS区块链上，一旦状态发生变迁，需要其它验证节点的验证确认，达摩克利斯之剑将惩罚作恶的节点。这是几乎所有区块链的基本原理。
但是如果矿工对同一个状态进行两个不同的变迁，会怎样？
POW区块链采用最长链原则解决这个问题，状态的变化按顺序存储，最终最长链胜出。此过程中虽然有孤块的产生，但是矿工做无用功本身也是协议不可或缺的组成部分。
POS区块链中，矿工质押代币越多，出块的概率就越大，也将因此获得更高的出块奖励。
区块链的基本假设是状态的变迁是一个接着一个串行发生的，所以状态的验证也是一个接着一个。所以在寻求扩展性方案时，会考虑并行链或者链下完成密集计算的方案。
为什么不使用图，超图，或者超图的超图？将所有状态变迁囊括，将孤块完全消灭？
问题在于，矿工在产生新状态时，是基于多个原有状态，我们可以称之为多个基础状态。其中一些已经被验证过是正确的。如果你不是一条链，而是DAG, 你将有多个可能的基础状态。
假设四个验证节点分别提出四个块：
- tx1: Alice买了一个玩具火车
- tx2: Bob买了一张电影票
- tx3: Carol买了Alice要买的那个玩具火车
- tx4: Dave将他的资金转账到一个有漏洞的Defi合约
矿工A看到了这四个交易，试着产生一个新的状态变迁：需要将这四个状态变迁打包到最终确认状态中，最终确认状态将交给其它节点进行验证。矿工A如何确认这四个状态变迁不存在双花情况？（事实上tx1和tx3就构成了双花）
当然，有人企图利用智能合约监测比较特殊的情况，比如使用严格的模型监测token的转移，以保证token的转移相互之间没有干涉。但是这是不可扩展的方案，会很快达到上限。这是一个错误的倾向，因为没人能够保证这个方法是安全的。
RChain的解决方案，归功于基于Rho演算的程序语言，直接提供冲突检测。矿工A能够简单地发现哪个状态改变不能相互结合，并且剔除它们。所以直接将tx3标记为冲突并从即将打包的最终确认状态中剔除。Carol可以检查链上的状态，看到她的交易被拒绝。需要提醒一下，这个冲突解决方案不是在区块一级实现的，而是在用户部署环节实现。
更深一步理解，需要看一下RChain如何处理虚拟机的状态。在Rholang语言中，所有的计算都是以通过特定信道“发送”和“接受”进行的，归类于进程演算的编程语言。简单讲，所有的存储包括两类：数据和continuation。continuation是指一旦触发条件满足后将会执行的一段程序。
如果数据或continuation能够匹配，就会发生comm event, 在Rholang里是一个基本的计算事件。所有数据和continuation都存储在RSpace里，需要提及一下：基于这种存储模型，RChain能够提供事务处理能力。
RSpace里有一个基本限制：在任何时间点上，都不应该有comm event，因为当状态变迁发生时，会触发comm event，所有的continuation被调用，直至comm event被消除，所以comm events不会存储到RSpace中。
这就是为什么冲突检测的逻辑简化成了检测RSpace中是否有潜在的comm event，如果没有冲突，tx可以被存入RSpace，而无需执行任何代码。
这个冲突解决方案是内置于计算模型的层面，应用于所有代码。并且其正确性是经过数学证明的。
有了这些基础知识，我们来讲解：这又是如何带来可扩展性的？通常意义上讲区块链增加更多节点将不可避免地降低处理能力，去中心化是需要成本的，不是免费的。
这是个合理的现象，路由的额外支出和数据复制的额外支出会增加，如果允许矿工并发改变状态，需要有方法验证和组合这些状态变迁。
我们需要两个组件：有效的验证和有效状态合并。后者包括冲突检测和状态变迁合并。
RChain伟大之处在于，所有的状态验证可并发进行。RSpace是一个只读结构，当矿工A接受到由矿工B、C和D产生的若干区块时，所有的状态变化都在并行验证，即使它们中包含冲突。
极端情况下，100个区块的验证时间和一个区块的是一样的。但是这涉及到代码的优化，合适的工程实现及可用的资源。我们仍在持续优化的过程中。
冲突检测可以在不同的效率等级执行，在冲突的个数和性能之间寻求平衡。最有效率的方式是无需分析信道里的内容，而只检测是否同一个信道被不同极性的状态变迁使用。一个可能是放入信道的是数据，另一个可能是continuation。
一般情况下，冲突不会存在，因为信道是使用unforgeable name。这又是RChain的一大特性，能够基于此实现OCAP安全模型。
对于多数用例来说，这种冲突检测都是足够的。冲突检测简化成两个集合的交集，想要深层次了解的人可以加入discord来探讨。
最后一部分是状态合并，这步操作要求数据必须是在最终确认块之前的很狭窄的时间范围内，需要通过缓存实现，但是即使没有缓存，也可以进行合并，因为其本质只是对数据库的读和写。
总结，本文简要解释了什么是块合并，以及其与可扩展性的关系。链接里有相关数据：https://gist.github.com/nzpr/2465db5210c817324ab7ab4f01e23f38
期待的结果是可以证明线性可扩展性。合并时间是节点数量和区块数量线性函数。
从数据结果可以看到20个区块的状态合并所用时间是两倍于10个区块的合并时间。这让我们对实现线性可扩展性充满了遐想。
