最初的message设计
这篇文章说一说，区块链基础设施的设计错误。简单的讲，我们错误的把设计重心放到了（分布式事务的）状态修改的原子性上，而这里更好的替代方案是使用消息来替换状态。错误的设计影响深远，并且对于非计算机行业的人群来讲更加难以理解。
后面我们用一种比较通俗和易懂的方式，为非技术领域的朋友，解释一下消息方案和状态方案之间的区别。我会竭尽所能地简单描述什么是message。 在深入之前，你可以把消息理解为我们发布出去的一篇文章，这个比喻比较简陋。
什么是状态机？
状态机是一个装置，我们在确定时刻可以获取到它的确定状态。换句话说，当状态机初始状态一致，当我们输入同样的数据，那么状态机的输出也肯定是一样的。
你可以把状态机当做一个自动贩卖机，自动贩卖机的系统规定了它可以执行的行为。如下图，当贩卖机在状态1下，它会等待用户投币。如果t它a被投币，则进入状态2。在状态2下，贩卖机等待用户点单。如果点单按钮被触发，则取出一个对应的饮料，同时回到状态1。实际上，所有贩卖机都运行着同一套代码和内存数据， 这保证了我们可以准确获取到此刻机器的状态。同时，它在感知到外部传入的消息后（如投币，按点单按钮），产生确定的行为（如投递饮料）。
我们可以将小的状态机组合成一个大的，而数据库本质上就是一个巨大的状态机，数据库的表、表内的每一行、每行的每个属性，都可以看做一个状态机。协议则是一对小的状态机，确定了相互通信的两点间的输入和输出。区块链则是另外一个非常庞大的状态机，它由成千上万个全节点状态机组成，然后每个全节点挂靠着成百上千的轻量客户端。虽然说状态机的设计本质很简单易懂，但是要将小的状态机如何组成多层次的大状态机，是一门科学的艺术。对这里的复杂性我们就不多做展开。
选型
一般来说，我们有两个基本方法来创建一个状态机。
第一个方法不是很严谨，首先为了简洁，我们省略了代码部分（IF语句）和输出部分（DRINK）。毕竟这篇文章的主要目的是，帮助非计算机行业的用户理解消息。
我们通常设计的状态机的模式如上图，当它接收到状态1的数据并处理后，状态会从1变成2。当状态机发送消息后（可有可无，视该交易的需要决定），状态会由2恢复到初始的1。
我们需要设计的状态机，可以通过代码来处理输入的所有消息，并且保存所有交易的状态。这样看来，我们要实现的状态机，实际上有两种不同的基础构建方法。两种不同的选型，会碰撞出新的设计思想，最终增强我们的业务能力。
方法一：创建一个状态机（只保存状态），先保存初始状态1，然后当消息到来，状态由变成2，然后保存状态2。一直不断重复！我们所有要考虑的就是保存好上图种的两个蓝色圆圈里的状态，其他的任何信息都可以被忽略掉。
方法二：创建一个消息机（只保存消息），而消息机启动时都在状态1，然后我们输入数据都将被保存下来，并且等待处理完后输出数据。这种场景下，我们保存了消息丢弃了状态，因为状态可以随时被计算出来。
因为机器的运行结果是可预测的，所以两种选型理论上很接近。
未完待续