The Message is the Medium

原文链接

最初的message设计

这篇文章讲一讲在区块链基础设施设计中，我认为存在的一些基本错误。简单的说，我们错误的把设计重心放到了状态修改的原子性上，而这里更好的替代方案是使用消息（而非状态）。错误的设计影响深远，并且对于非计算机行业的人群更加难以理解。

下面我们用一种通俗易懂的方式，针对非技术领域的朋友，解释消息和状态方案之间的区别。我会尽力简单地描述什么是消息， 在深入之前，你可以先把消息理解为我们发布出去的一篇博客文章，虽然这个比喻比较简陋。

什么是状态机？

状态机是一个软件装置，通过它，我们能在某一时刻得到一个确定的状态。换句话说，如果状态机初始状态一致，当我们输入同样的数据，那么状态机的输出结果肯定也是一样的。

我们可以把状态机比做一个自动贩卖机的系统软件，贩卖机的软件部分决定了硬件可以执行的行为。如下图，当贩卖机处在状态1下，它在等待用户投币。如果被投币，贩卖机进入状态2。在状态2下，贩卖机会等待用户点单。如果点单按钮被触发，则投递对应的饮料，最后回到初始状态1。本质上所有贩卖机都运行着同一套代码和内存数据， 这保证了我们可以通过算法准确获取到某一刻机器的实时状态。同时，它在感知到外部传入的消息后（如投币，按点单按钮），能够根据算法和当前状态产生确定的行为（如投递饮料）。

我们可以通过组合小的状态机，形成一个大的——数据库本质上就是一个大型状态机，数据库的表、表内的每一行、每行的每个属性，都可以看做为状态机。协议则是一对状态机，两头一边一个。区块链，则是另一个庞大的状态机，它由成千上万个“全节点”状态机组成，每个全节点还挂靠着成大量轻量客户端（SPV client）。本质上，状态机的设计很简单，但是如何将小的状态机组成一个大的，这是一门科学艺术（没有固定方法）。对这里的复杂性，我们不多作展开。

选型

创建一个状态机，一般有两种方式。

请注意，后面我以一种要求不太严格的、比较个人化的方法来描述。首先为了简洁，我们刻意省略了代码部分（IF语句）和输出部分（DRINK）。毕竟这篇文章的主要目的，是帮助并非geek的你，理解消息是什么。

我们设计的状态机通常如上图所示——从状态1开始，然后接收到消息1。对消息1的处理，使状态从1变成2。当它的状态由2变成初始状态1的过程中，会视情况发送消息出去。

实现一个状态机，主要是通过代码去控制保存交易状态，有消息过来，代码能控制已知状态间的转换。 实现它的过程中，最终我们发现本质上有两种构建方法。这两种选型的碰撞，极大丰富了我们的思考和设计，最终增强我们的技术能力。

方法一：创建一个状态机，先保存初始状态1。当消息到来，状态由变成2，然后保存状态2。一直不断重复！我们所有要考虑的，就是保存好上图两个蓝色圆圈所表示的状态，其他的任何信息都可以被忽略掉。

方法二：创建一个消息机，消息机启动时都在状态1。当输入数据（如上图的红色药丸，即消息）被灌入机器，我们将消息记录下来，然后输出新消息。这种场景下，我们保存了消息丢弃了状态，因为状态可以随时被计算出来。

实际上，因为机器的运行结果是可预测的，所以两种选型理论上很接近。这样的消息机一旦被创建，那么它的执行结果都可以可预期的，例如上图我们输入M1，一定会使消息机状态从State1转换为State2，最终输出M2。

接着，如果我们再拿一个一样的状态机，输入与刚才一样的消息，就可以得到一样的最终状态。再或者，如果记录所有状态，我们也能根据状态的前后变化，反推出它导致的执行动作，而导致状态变化的消息也不再重要。 大家都学习过几何，这其实就是一个“存储点”还是“存储边”的问题。

上面提供了区块链基础设计的两种思路。通过对我们的需求进行分析，可以决定选择其中的一个：
数据库是一个状态机，它就像一个开关——知道自己是开着还是关，但并不知道在这之前变化的过程。在与数据库通信时，协议就充当了消息机的角色。例如我们用email通信，拿到最后一个邮件并不能得知整个对话的经过，但是通过扫描两个人的来往消息，就能得知具体过程。

区块链的底层模型究竟选哪一种？

我们要说的是理论上的，而实际很可能不一样。比如，你的银行账号看起来就像一个状态机，里面存储着可以随时查看的余额。但是在银行内部，因为他们统计时采用复试记账，这看起来更像一个消息机。

区块链现在应该怎么做？

有可能是历史的原因，或者是因为惯性思维，区块链更多的被当做是一个状态机，而非一个消息机：

......区块链的主要功能，是维护一个可以被并行修改的状态。为了解决并发读写冲突，区块链把状态记做账本（LEDGER），账本中包含了一系列对初始状态的更改。区块链把这些更改记录到一个区块（BLOCK）当中。在比特币的例子中，区块链保存的状态通常指未被花费的余额（UTXO）。
——LM Goodman, "Tezos: 一个自动修复的加密账本立场文件"，2013

再或者，我们来看最近的一个以太坊替代项目：

如何让交易语义和合约更好的融合在一起？
在消息处理的角度上看，交易是指在某条链上，它已经被见证过并且通告（给所有节点）。
消息只是一个被传输的虚拟的数据结构，但当它被发起方传递给合约后，将导致合约前后状态发生实际变化。而这个过程被另外的节点见证，最终将被打上时间戳，记录到存储器（区块链）中。
消息的传递是一个原子操作。不管一个消息是否被见证，只有被成功见证过的消息才会被记录到一个区块当中。
——anon？，“RChain架构-合约的设计”，2017 RChain Cooperative

我们留意到，上述作者创造了一个完整的、以存储交易消息为基础的区块链，却最终落地变回了典型的状态型区块链。

另外一个例子，如下图，我们看一看比特币的UTXO状态机模型（UTXO是用户未花费余额的状态集合）。在UTXO模型下，交易是一条对状态的记录，里面包含了一组输入和一组输出。对比上面的图3，我们只关注两个蓝色圈中表示的状态（忽略红色的消息）。通常每一笔交易就像下面的蓝色方框，从左边有一组状态输入，右边有一组新状态输出。

方框左侧输入的，是其他交易的输出。输入后，就代表他们被花掉了，并且从右侧输出一组相应的可用余额，输出的余额可以在未来被交易。上图中，TRANSACTION 1输出了0.5个比特币，TRANSACTION 2消费了刚才输出的0.5个比特币。

比特币的一个交易记录，记录了若干输入和输出，就好比一个小型的资产平衡表，输入的余额必须等于输出的余额。 交易记录就好比乐高积木，新的交易记录必须对接到旧的交易记录中，并且开放给更新的交易记录对接。

UTXO的脆弱性

我们很早就知道，但是这里我还是要重提一下：比特币的设计精妙非凡，但是从另一面看，它的很多组件相互的关联性太强了。如下所说：

“一个纯粹的P2P版本的电子现金，能够允许点到点的在线支付，这个过程绕过了传统的金融机构。”
中本聪，“比特币白皮书：一个点对点的电子现金系统”，2008

（变成流通）货币是比特币的目标，同时，货币也是维护它安全性的驱动力（通过奖励竞争挖矿的获胜者）。货币和安全性之间的强依赖，导致了比特币在架构上存在脆弱性。这里并不是说比特币会因此而崩溃，我们想说明的是，如果我们更改比特币系统中的某个设计，这可能导致（比特币） 的架构不再像之前那样经得起推敲。

同样的问题存在于UTXO。我们刚提到，比特币的目的是想成为流通货币。对于全节点来讲，它需要记录下当前时刻的每一笔可用余额，这样才能保证它独立验证所有交易，并且打包出块以获得奖励。相反的，对于SPV轻量节点或者其他远程轻量客户端，则只需要提供一个简单的方法证明有他能花这笔钱，完全无需将整个链（中交易输出的UTXO状态集合）记录到本地。

上述两个需求通常是矛盾的（在一个节点上，同时满足货币的流通性和安全性）。对于比特币这样拥有海量交易记录的链来说，UTXO的设计非常精巧，在一定取舍下满足了两个需求，同时保证了性能。当客户需要证明自己有一笔未花费余额（UTXO）的时候，它的优点就体现出来了。

An Order Book

如果上述两种需求发生变化，UTXO还好用么？例如我们想做一个交易所。综合很多因素后，我们发现最好的实现方式是把所有信息聚集起来，将买卖双方的报价组成一张清单，然后通过一个竞拍程序， 根据大家的报价找到一个最优方案进行撮单。当然也有其他方案可选，不过这已经是被众多交易所实践过，并且经受了时间考验的最优方法。

试想当在UTXO状态机下，有一批未知数量的买家和卖家。这里有两个需求因素制约着UTXO，让其难以发挥优势：1.不同交易员需要根据买入量、卖出量、价格随时动态撮合多方需求，达成多方满意的订单结果；2.撮合交易对消息非常敏感，当交易员得知新底价后，如果有办法他一定会撤销和撕毁之前的报价。这两个需求基本上是矛盾的。

基于消息流的设计可以轻易解决这个难题。如果链上的撮合者（在POW场景中指矿工，DPOS场景中指出块者）有稳定的买入和卖出订单消息流，它只需要简单地将接收到的订单全部放入一个“撮合合约”中，然后撮合价格匹配的订单达成交易，然后以消息的形式输出合约的执行结果。

这个过程中，消息都被日志记录下来，但是状态（例如UTXO）则是隐式的，这意味着状态只存在于机器内部的，无需（永久）保存下来。只要链上确定了消息的约束集（如消息如何输入、如何排序执行），那么同样的合约，部署在任意节点上，当我们输入同样的消息，合约执行结果一定也是一样的。

（消息机）还有两个优势：第一，当前块未确认的交易会自动延迟到下一个区块中进行确认。因为每一个传入的交易消息都是与时间无关的独立的一笔交易。而对于UTXO，每一次交易的输入和输出都会影响UTXO集合的状态，所以每笔交易都强依赖于当前时间点的UTXO状态集（每次均需重新判断）。

第二个优势，这种设计能反馈更多的（撮合交易订单的）问题。例如，当你和我想达成一笔交易，我们只需要把买入和卖出消息发送到交易合约中。这里，最复杂的一部分（撮合交易）被合约解决了，而合约的作者在设计的时候已经解决了这个问题。相反的，我们来看UTXO合约，如果你和我想按照figure5中蓝色方框内的内容达成交易，UTXO将最复杂的一部分（撮合交易）交给了交易的用户，而最简单的一部分（把记录消息到日志里）则放到了区块链上去解决。

更多的，你还可以对比在两种设计下，交易费处理上的不同。

（消息机模型的）一些疑虑

并不是说消息机就很完美，状态机的优势是跟踪定位bug更快。状态机下每一笔交易都必须对当前状态达成共识，而消息机只确认消息达成共识。对于撮合交易来讲，能够快速捕获到（状态不一致的）问题是一个很大的优势。这对于致力于削减成本和运营风险的金融部门来说，非常重要。

但是即使有这个优点，当区块链发生bug时，往往还是会产生硬分叉。

节点间的不一致，整条链都会陷入瘫痪。

当消息机模型的区块链发生bug时，由于bug都是隐式的，最多导致不同的节点对于相同消息的产生不一样的处理。受到bug影响的人可以把这条消息隔离开，然后将消息放到线下进行跟踪和重放，进一步观察bug是如何发生的。

结论

要组建一个广为人用、且可靠的区块链，消息机模型在很多方面都优异于状态机模型。但并不绝对，因为状态机在跟踪异常上更快。

虽然我们可以写一篇更全面的分析贴，列举两种模型间更多的优缺点，但本文只重点讲比较重要的几条。基于消息链模型除了有以上灵活的特性外，还能获得更高的运行效率。例如@danthemann设计的bitshare和steemit都建立在消息机模型上，两个系统均能达到1000以上的TPS。我自己研发的Ricardo系统也类似，即使它不是区块链项目，但却解释了为何我如此偏爱消息机。

理论上，消息机模型确实能提供一个更高性能的解决方案。同时，可能大家已经隐约知道，EOS项目就是基于消息模型构建！实际上，正是因为对（区块链链上数据处理）速度的需求，驱动着设计师@danthemann和我发现并且认识到（鉴谅我引用Marshall McLuhan的至理名言）：

the message is the medium.