[翻译] 信息即媒介
区块链的另一种设计思路，从信息的角度看交易，也许会有不同的结果。
信息即媒介
本文翻译自：https://steemit.com/eos/@iang/the-message-is-the-medium
原文作者: iang
译者：区块链中文字幕组 荆凯(shuke0327)翻译时间：2017-10-22
预备信息
在这篇文章中介绍了我认为的几乎所有的 blockchain 设计中都存在的一个基础缺陷。简言之，这缺陷在于太过强调状态( state )作为（区块链的）"原子因素"，而我们也可以改用信息( message )来构建。 这一缺陷的影响很严重，但也很难理解，因为计算机科学的概念对于计算机科学世界以外的人来说，有些难以触及。
下文是非常不正式、不严格的描述，我尝试对非技术型的读者解释清楚信息和状态之间的区别。我尝试尽量简单的传达信息，但如果你仍然感到困惑，还有另外一种方式去理解，即，观察此处的空间 - 我们要创建它，从而信息会发送至媒介。这类比够烂的，让我们继续前进吧。
状态机是什么？
状态机是一个计算机科学发明的一个概念，用来描述具有可靠性、 确定性的机器。换句话说，它是一台软件"机器"，给定一组输入和存储，会始终产生相同的输出。
Figure 1 - The State Machine.png
设想一台自动售货机和其中的软件用于模拟硬件机器，以决定下一步做什么。换句话说，"如果我们处于状态 1，等待投币。如果硬币出现，进入状态 2。如果在状态 2中，等待按钮按下。 如果按下按钮，提供饮料，转到状态 1。” 在本质上，我们的机器包含处理算法的代码，记录位置的状态(存储)，读取输入信息（硬币，按钮）和将指令作为信息(饮料)输出的能力。
Figure 2 - a coke machine .png
我们也可以用小的状态机构造出大的状态机-数据库本质上就是一台庞大的状态机，由每个 SQL 表，每一行和每个单元格的小状态机组成。 协议也是一个小的状态机，由分布在协议两端的两个状态机组成。 Blockchain 是另一个巨大的状态机，由数以千计的"完整节点"状态机，以及大量叫做 SPV 客户端的附属节点组成。虽然状态机设计的本质很简单，但使用起来却既是一门艺术也是一门科学，因为对于如何将小的状态机组成大型状态机，我们并没有很好的见解。不过我们暂时先忽略这种复杂性。
选择
构建一个状态机，有两种基本方法。
注意，以下是非常具有个人色彩的观点，并非严格表述。我们忽略了上面提到的代码，只要假设在需要的地方它被引用到了。为了简单起见，我们也忽略掉输出信息。我们的目标是让你能够理解信息，而非为了讨好电脑geeks.
Figure 3 - timeline of transitions .png
通常我们对状态机的建模如上所示 -- 从状态一开始， 然后信息1 到达。 处理信息，会从状态1转变为状态2。在转变过程中，状态机发出信息，是否发送信息是可选的 - 取决于状态机在状态变化时的需要。
构建状态机时，我们的工作是编写代码来存储所有的状态，以及根据所有的已知信息来变更全部的状态。结果是，在做这件事的时候，有两种从根本上不同的方法去写状态机，选择哪种方法，会影响到我们的思考，我们的设计，最终影响到我们的能力(capabilities)。
第一种方式: 将其视作一台状态机。在这一观点中，我们存储状态1。 当信息到达时，状态机切换到状态2，我们存储新的状态。重复上述过程！将状态看作是上图中的蓝色的圆圈，你可以忽略掉世上所有其它不同的观点。
第二种方式: 将其视作一台信息的机器。在这一替代观点中，我们把信息记录下来。 我们仍然从状态1开始状态机。然后把所有输入的信息(上图中红色的标签)传入到机器中（并且将所有的新信息传出）。 我们存储信息，而不用为状态分神，因为我们可以随时计算出。
这些观点在理论上是大致等效的，要理解这一点关键在于知晓状态机是具有确定性的。一旦我们确立了机器的运行是精确无差错的，我们就可以知道，例如，状态1 叠加信息 M1 总是会得到 State2的结果（并输出信息M2）。
然后，如果我们有这台机器和一组给定的消息，我们总是可以运行机器，得到相同的状态。或者，如果我们记录了状态，我们总是可以按照状态的链条运行，重现状态机的动作，虽然我们没有必要知道这一过程是由什么信息导致的。如果你喜欢图（graphs），那么可以将（状态和信息的）这种区别看作是存储图的节点或者存储边界的区别。
我们可以选择思考事物的方式。并且根据我们的愿望和设想，我们有可能青睐一种方式或其他： 数据库被视作状态机，正如电灯的开关-它知道是否它是打开还是关闭，但不知道它是如何成为现在的状态的。而协议则更经常被认为是信息的机器；思考一下在邮件交流中的情形，最后一条消息不会告诉你所有的故事，需要花费时间去查看之前的所有信息，才能知道发生了什么事情。
photo.png
当前区块链的机制是什么？
这是就理论而言 — — 实践可能有所不同。你的网上银行账户表现得像一台状态机，会告知你账户的余额。但在银行内部，对复式记帐会计法的使用让它更像一台信息机。
区块链该如何做？
可能由于历史原因，或者可能因为这种方式对设计者而言更为典型，区块链被视作是一台状态机，而非信息机:
......区块链 的目标是表现一个正在被并行编辑的单一状态。 为了避免并行编辑中的冲突，它将状态表述为分类总账，即作用在初始状态上的一系列变化。 这些变化是区块链上的"块"，在比特币中，状态主要是未花费的输出的集合(这段强调是我加的）LM Goodman, “Tezos: A Self-Amending Crypto-Ledger Position Paper”, 2013
或者，在最近的一个旨在取代 Ethereum 的项目中的表述：
描述交易的语义学表述如何与我们对合约的描述相结合？从处理的层面看，交易是对消息在某个渠道已被"见证"的确认。消息本身是虚拟对象。某个代理发送信息，由另外的代理见证信息，信息打上时间戳记录在存储系统中-- 即为人们所知的”区块链“上，这一过程前后的状态，就是合约的前状态和后状态。信息的传递是原子操作。无论信息是否得到见证，只有对信息的成功见证才有资格作为可信的交易被记录到区块中。（原作者的重点强调以粗体显示，我的重点用斜体表示）匿名？，“RChain Architecture - Contract Design”, 2017 RChain Cooperative
请注意上述作者的观点，（他们认为）我们需要做的所有事情是将信息作为交易存储，然后回到区块链上，记录状态。
我们来看另一个例子，在下面图4中的比特币状态机器，我们可以在 UTXO 的模型之中可以很明显的见到这一关于状态的设计观点，UTXO模型将交易归类为未消费的交易输出("UTXO") 的集合。交易记录了包含了输入和输出的状态。与上面图 3比较，思考一下两张图中的存在于每条记录之中的蓝色框，不用考虑信息。通常每个 UTXO 交易表示为一个盒子模型，左边列出输入，右边列出输出，如图4：
Figure 4 - the UTXO or Unspent Transaction Outputs model .png
每笔交易的输入侧（左侧）是对之前的输出或"币"的引用列表，表示它们已经花费了，输出侧（右侧）是另外一个相匹配的新币列表，表示新币已经创建，可以用于未来消费。在上面图中，"交易 1"创建了 0.5BTC 作为输出，"交易 2"引用这个输出作为它的输入，花掉 0.5BTC .
比特币交易记录，同时记录了输入和输出，就像一个微型的资产负债表一样; 输入与输出相匹配。对视觉思考者来说，可以把每个交易记录视作乐高块，每个新的乐高块必须插到旧的块上，并且让更新的乐高块能够插到它上面。
UTXO 的脆弱性
在前面你已经看过了，但现在仍值得重复: 比特币的设计非同凡响，但是有一点，即比特币中所有的组块都以一种依赖性很强的方式彼此链接。 正如白皮书中所说：
“纯粹的点对点的电子现金实现版本，允许在线支付，无须经过金融机构，直接从一方发送到另一方"。中本聪，"比特币:-点对点电子现金系统，"2008年。
比特币的使命是成为金钱，钱也是安全模型的驱动力，借助给矿工支付的方式使矿工竞争挖矿，以完成交易的验证。内部依赖性这一强大的特性存在一个弱点 -- 用建筑学术语来讲叫做脆弱性（brittle）。我这样讲并不是指比特币会随时崩溃，而是，如果我们更改其中一个设计元素，就会威胁到整个架构的神圣性。
UTXO 也是如此。 如上所述，比特币的使命是成为货币。 每个（完全）节点需要有可用的比特币的所有记录，因此可以验证每笔传入的交易，并继续分发到备用区块中供挖矿计算。 相反，SPV 或远程客户端需要有简单的方法，只需要证明他们接收的那部分币，而不需要将整个区块链都拖下来。
这两项要求有冲突。在像比特币这样的大型区块链上，存在大量的记录， UTXO 的布局设计优雅，虽然有其它影响，但是能够以一种合理的效率满足两者的要求。它非常善于提供给客户端在某个时间点上所需要的交易证明。
交易委托账本
但如果要求变化了，UTXO 会发生什么？ 假设我们想进行交易。由于种种原因，最好的办法是把所有人集中，构建委托账本-包含竞价买单列表和一个卖单报价列表，然后运行拍卖清算过程，为所有的交易者找出最合适的价格。 当然，还有其他方法，但这才是经过时间检验，也是交易所在用的方法。
Figure 5 - the Blue Pill Trading Book of State .png
在 UTXO 状态机的撮合交易中，在买入侧有未知数量的买家出价竞争，在卖出侧，卖家的数量也是未知的。UTXO 设计不能轻易简化这种设计有两个原因: 1. 诸多未知的参与者相互竞争得到一个结果，这种互动难以规模化，因为总体布局需要运行时协商决定 - 输入，输出以及价格！ -在竞争的贸易者之间; 和 ２. 交易是信息敏感的 — 如果有方法可以退出谈判让谈判崩溃，交易者一旦确认了你的位置，就会这么做。这是个基本矛盾。
消息流可以轻松处理这个难题。如果区块链的中间人（在 PoW 设计中的矿工，或者 DPOS 机制之中的区块生产者），收到稳定的出价和要价信息，他只需要按顺序收集信息，将其传递给 "交易委托账本合约"，在合约内部构建委托账本，确定掉期价格，发送新的信息，确认合约的结果。
Figure 6 - the Red Pill Trading Book of Messages.png
消息会被记录，但状态 (例如，UTXO) 只是隐含其中，意味着它在计算机内部构造，然后（可以）被丢弃。只要区块链决定了严格的信息集合 -- 包括有哪些信息，以及信息的顺序 - 结果就是确定的，因为任何其他节点对每一组相同的输入消息运行同一合约，都会得到同样的输出信息。
两个额外的好处： 如果任何传入的交易在此区块中被丢弃，可以仅仅将它们推迟到下一个区块中就可以了。 因为输入的信息是独立于交易的，然而任何时候组成 UTXO状态的输入和输出更受限制，必须是所属的特定交易之中的依赖性集合的一部分。
第二, 这一结构更能够捕获到更多交易账簿的问题。就是说，如果你想与我交易，或者我与你交易，我们都需要将自己的投标作为信息发送。 困难的部分在合同内部完成，智能合约的作者在设计时候就已经覆盖了这一情况了。 与此相反的是，UTXO 的结构中，我们必须按照图片五的蓝色盒子那样，就所有的一切达成一致，签名，然后提交达成共识。 UTXO把困难的部分留给我们交易者，而把容易的部分 - 记录事实 - 交给区块链。
给你留个练习，你可以试试看在两种设计中如何处理交易费用。
轻微异议
不是只有一种方法 — — 状态模型的优点是捕获 bug 的更快。每一笔交易都需要完美的达成共识记录状态，而不只是让我们达成状态的信息。 交易要达成一致，捕获错误的能力可以被视作主要的优势，银行业正在寻求降低运行成本和业务风险的方式。但是即使这种选择也是有风险的- 当错误出现在区块链上时候，区块链会迅速的断裂和分叉。
当bug出现在信息模型下的区块链时，bug是隐性的，大多数情况下在各方之间就信息的意义产生分歧。受影响的人可以脱机处理；包括，我们可以开发出证明机制，可以在脱机状态或者链外观察所涉事项。
结论
就构建能力更强的区块链这一目的而言，信息模型出于诸多原因，比状态模型要更有优势。不是只有一种办法 - 状态模型在更快捕获异常方面具有优势。
一个完整的帖子会列出来所有利弊，但是暂时我们只列出了一个主要的优势。除了上面例子之中的灵活性之外，信息链可以得到好得多的表现。 例如，由@dantheman创建的Bitshares和Steem，都是构建在信息模型之上，可以每秒处理1000多次交易。就我所创建的Ricardo 系统而言，尽管非区块链，但是可以解释为何它如此容易，如此讨我喜欢：）
至少在理论上，这一路径承诺了更好的性能，你可以看到可能EOS也会按照这种方式来构造。实际上，正是出于对系统速度的要求，让 EOS 的设计者[@dantheman][3]和我能够发现（对不住了，Marshall McLuhan）：
信息即媒介
区块链中文字幕组
致力于前沿区块链知识和信息的传播，为中国融入全球区块链世界贡献一份力量。
如果您懂一些技术、懂一些英文，欢迎加入我们，加微信号:w1791520555。
本文译者简介
荆凯，程序员，坚信区块链将会改变潮水的方向。欢迎加微信: shuke0327，或者关注公众号: 增长之道
本文由币乎社区（bihu.com）内容支持计划赞助。
版权所有，转载需完整注明以上内容。
