这篇文章介绍了我认为几乎所有区块链设计中都存在的一个基本缺陷。简而言之，当我们使用消息来构建时，强调将state作为“核心元素”。这其中的影响是相当巨大的，但也很难理解，因为计算机科学的概念对not-CS世界来说有点难以理解。

    接下里是一个非正式的、非严格的描述，试图向一些非该专业领域的读者解释消息和state的区别。我试着以简单的方式来引导大家理解它，但是如果你发现自己还是处在一种混乱的状态下，这有另一种理解它的方法那就是关注进一步的进展——我们要建立它，这样信息就会被放到媒介上。有点糟糕的比喻，让我们继续吧。

    所以什么是状态机

    状态机是一种计算机科学发明(https://busy.org/exit?url=https% ... inite-state_machine)，用于捕获可靠的、具有确定性信息的机器。简而言之，它是一个软件“机器”，它被给与一系列输入和内存，总是提供相同的输出。

    想想一台自动售货机，以及内部的软件，它必须模拟外部硬件，以便确定下一步该做什么。换句话说，“如果我们处于状态1，就是等待投入硬币。如果硬币投进来，就转换到状态2。如果处于状态2，就是等待按钮按下。如果一个按钮按下，提供饮料，转到状态1。”从本质上说，我们的机器包含一些代码来处理该算法，一些state（内存）来存储我们的状态，以及读取传入消息（硬币，按钮）和做出一些行为作为输出消息（饮料！）的能力。

    我们还可以用较小的状态机构建更大的状态机-数据库本质上是一个巨大的状态机，由每个SQL表的每行和每个单元作为多个小的状态机构成的。协议是由两台状态机组成的小型状态机-每端一台。区块链是另一个巨大的状态机，由数千个“全节点”状态机组成，其中有许多挂机，称为SPV客户端。虽然状态机设计的本质非常简单，但使用它们既是一门科学又是一门艺术，因为我们对如何将小型状态机组成大型状态机没有很深入的了解。我们暂时不考虑这种复杂性。

      事实证明，构建状态机有两种基本方法。

    请注意，以下是一个非常风格化的观点，而不是严谨的观点。我们忽略上面的代码，并假设它在需要的地方被引用。为简单起见，我们也忽略了输出消息。我们的目标是让普通人了解消息，而不是给CS极客们留下深刻印象。

    我们通常以上述方式对状态机进行建模-它从状态1开始，然后到达消息1。处理此消息会导致从状态1转换到状态2。在转换到状态1时，机器发出消息，尽管这是非常严格并且可选的–但它还是取决于机器在该转换时的需求。

    我们构建状态机的工作是编写代码来实现存储和转换所有已知信息的状态。事实证明，在完成这项工作时，有两种根本不同的方式来编写机器，以及选择哪种取决于我们的思维、设计和能力。

    第一种方法：把它看作是一种状态的机器。在这个视图中，我们存储状态1。然后，当消息到达时，机器转到状态2，然后存储这个新状态。重复这个循环，把这些状态想象成上面的蓝色圆圈，你就可以忽略任何其他的世界角度。

    第二种方法：把它看作是信息的机器。在这个备用视图中，我们记录消息，并且总是在状态1的时候启动机器。然后，我们将所有需要输入的信息(上面的红色药丸)输入到机器(并弹出任何新的信息)中。我们存储信息，但不关心状态，因为有了信息之后我们可以随时计算出状态的情况。

    这些观点在理论上大多相同，理解这一点的关键是“机器是确定性的”。一旦我们确定机器在其动作中是精确且无情的，我们就知道例如状态1上的M1总是导致State2（和M2输出）。

    然后，如果我们有机器，并且我们有一组消息，就可以再次滚动它以获得状态。或者，如果我们记录了状态，我们总是可以根据一系列状态的转换来重现action，尽管我们不一定知道哪些消息导致了这一状态转换。如果你喜欢图形学，你可以想一下以节点存储和以边存储的区别。

    我们可以选择如何思考问题。而且，根据我们的愿望和假设，可能会更喜欢这样或那样的方式：数据库被视为状态机器，就像灯开关一样-它知道它是打开还是关闭，但不知道它是怎样到了现在的位置。而协议通常被认为更像是消息机器;考虑一个电子邮件交换，其中最后一条消息没有告诉你所有的故事，如果它已经持续了一段时间，你可能必须扫描线程中的所有之前的消息来弄清楚发生了什么。

    这是理论上的-实践可能会有所不同。你的网上银行帐户被看做是一台状态机，并告知你余额。但在银行内部，使用双重输入运算使其更像是一种信息机器。

    由于可能是历史性的原因，或者因为设计师以这种方式思考更典型，因此区块链被视为状态机器，而不是消息机器：

    如果我们再看一下图4中的比特币状态机的另一个例子，我们可以看到这个状态视图在UTXO模型中特别强调，它将交易分组为UnspentTransactionOutputs（“UTXO”）的集合。交易是包含输入和输出的状态记录。与上面的图3相比，考虑每个记录中的两个蓝色圆圈，但没有消息。通常，每个UTXO交易都表示为一个框，左侧是输入列，右侧是输出，图4：

    在每个交易的输入（左）侧是先前交易的输出或“硬币”的引用列表，通过这样的方式，确认硬币存在，然后花掉它，并且在输出（右）侧是另一个匹配的新硬币列表，通过这种方式，确认它们现在已经被创造出来并在将来可以被消费。在上面，“交易1”创建0.5个BTC作为输出，“交易2”通过引用它作为输入来花费0.5个BTC。

    比特币交易记录，作为输入和输出的记录，就像一个微型资产负债表;输入与输出匹配。对于具有视觉意识的人来说，这些交易记录中的每一个都像乐高方块一样，新的必须覆盖旧的，并提供更新的以便在将来可以覆盖掉它们。

    TheBrittlenessoftheUTXO

    UTXO的脆弱性

    现在，它之前已经被察觉到，但有必要复述一下：比特币具有非凡的设计，但其中一个方面是所有组件都以非常依赖的方式彼此紧密相连。正如它所说：

    任务是货币，但货币也是安全模型的驱动力，通过支付矿工竞争验证。内部依赖的这个强大部分确实存在一个缺点-在架构方面它很脆弱。通过这种方式，我并不是说比特币随时都会崩溃，而是如果我们改变一个设计元素，它就会威胁整个构造的神圣性。

    这就是UTXO。如上所述，比特币的使命是为一种货币。每个（全）节点都需要拥有可用资金的每一条记录，因此它可以验证每个传入的交易，并继续将交易分发到其适合的采集区块中。相比之下，SPV或远程客户端需要有一种简单的方法来证明其输入的币的组成部分，以保证不会拖累整个链。


    这两个请求是冲突的。由于比特币这样的大型链中有很多记录，因此UTXO布局是一种优雅的设计，在其他影响的情况下以合理的效率满足这些要求。它非常擅长提供客户在某个时间点需要的证据。

    AnOrderBook

    订单薄

    Figure5.

    但是当需求发生变化时，UTXO会发生什么？假设我们想做交易。出于各种原因，最好的方法是将所有人聚集在一起，构建一个订单簿–要求购买的出价列表与要出售的标价列表-然后进行拍卖结算流程以找到所有交易者的最佳价格。当然还有其他方式，但这既是经过时间考验的方式，也是加强交流的方式。



    在UTXO状态机中聚集在一起时，我们是不知道想要竞标买家的地位有多少，也不知道卖方的人数有多少。UTXO设计过程中不能轻易地完成这种设想，原因有两个：1，竞争一个结果的许多未知因素的相互作用无法扩展，因为整个布局需要动态协商-输入、输出和价格！-在竞争交易者之间;

    2，交易是信息敏感的-交易者一旦发现你坐上买家的地位就会想办法退出谈判并使你崩溃。这是一个根本的矛盾！

    消息流可以轻松处理这个难题。如果区块链中间人（PoW设计中的矿工，或DPOS中的生产者）收到一系列稳定的出价和报价信息，他只需按顺序收集它们并将它们交给内部构建订单薄的“书面合约”，然后决定交换价格，并发出新的确认合约的消息结果。

      消息被记录，但状态（例如，UTXO）是隐含的，这意味着它由计算机内部构建，然后（可以）被丢弃。只要区块链决定了严格的消息集-消息和按什么顺序-结果是确定性的，因为每个其他节点为每组相同的输入消息运行相同的合约，并且同意输出消息。


    还有两个优点：如果在这个区块中丢弃了任何传入的交易，它们可以简单地被推迟到下一个区块。这是因为传入的消息无论什么时候进行交易都是具有独立意图的，而构成UTXO状态的输入和输出更多地受制于它们的依赖集合的一部分，这些集合现在应该在该交易中发生。


    其次。这个结构捕获了交易账户的更多问题。也就是说，当你想与我交易，或者我和你交易时，我们都将我们的买入/卖出作为信息写入并发送给它。困难的部分是在合约里面完成的。完整的合约作者在他的设计中已经涵盖了这一点。相比之下，使用UTXO构造，你和我必须在图5中展示蓝框，同意所有内容，签字然后提交以达成共识。UTXO给交易员带来了困难的部分，而将简单的部分-记录事实-留给了链。

    它并非都是单向的-状态模型具有更快地捕获错误的好处。每个交易必须在其记录状态下完全一致，而不仅仅是让我们在那里的消息。这种快速捕获错误的能力可被视为交易对账的主要优势，银行业正在考虑降低成本和降低运营风险。

    但即使这样也可能是有风险的选择-当区块链中出现bug的时候，链会迅速断裂和分叉。

    当节点冲突和哈希时，一切都停止了。当bug出现在消息模型链中时，该bug是隐含的，并且在很大程度上会在各方之间产生关于消息含义的争议。受影响的人可以将其变为脱机状态;包括，我们可以缓存证据来离线观看问题，或者交换。

     总结
    为了构建功能广泛的区块链，消息传递模型有许多优于状态模型的原因。这并不是一个单一的方式-状态模型有更快地捕获中断的好处。

    一个更全面的帖子会列出所有的优点和缺点，但是现在，我们只会召集一个主要专业人士。除了上述示例的灵活性之外，消息传递链可以达到更高的性能。例如，@danthemamn的Bitshares和Steem都是建立在这个模型上的，并且每秒显示1000次交易。和我的Ricardo系统一样，虽然是非区块链，但它解释了为什么我这么喜欢:-)

    至少在理论上，这种方法可以提供更高的性能，你可以看到EOS也将以这种方式构建的暗示！事实上，正是这些系统的速度需要导致设计师@dantheman和我自己发现，向MarshallMcLuhan道歉：

    信息是一切中介。