【翻译|Ian】信息是一切中介

eoshenzhen (44)in #eos • 6 years ago

The Message is the Medium

信息就是中介

作者：Ian Grigg
翻译：Gavin
校对：Lochaiching

A Preliminary Message

初步信息

This post introduces what I think is a fundamental flaw in almost all blockchain designs. In brief, it is the emphasis on state as the ‘atomic element’, when we could also build using messages instead. The implications of this are quite severe, but also quite hard to understand because the computer science concepts are a bit inaccessible to the non-CS world.

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

What follows is a very informal, non-rigourous description to try and explain the difference between messaging and state to the non-technical audience. I’ve tried to get the simple message across but if you find yourself in a state of confusion, there is another way to understand it and that is to watch this space - we’re going to build it,so then the message will be put to the medium. Enough bad analogies, let’s forge on.

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

What’s a State Machine, anyway?

所以什么是状态机

A state machine is a computer science invention to capture the reliable, deterministic machine. In words, it is a software “machine” that given some set of inputs and memory, always delivers the same outputs.
ian消息媒介1.png

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

Think about a vending machine, and the software inside, which has to simulate the hardware machine so as to figure out what to do next. In words, “if we are in State 1, wait for coin. If a coin turns up, enter State 2. If in State 2, wait for button push. If a button push turns up, deliver drink, go to State 1.” In essence then, our machine consists of some code to handle that algorithm, some state (memory) to recall where we are, and an ability to read incoming messages (coins, buttons) and write outsome instructions as messages (drink!).

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

Figure 2 - a coke machine .png（编辑部：图挂了）

We can also construct bigger state machines out of smaller ones - a database is essentially an enormous state machine, made up many little machines for each SQL table, each row and each cell. A protocol is a small state machine made of two state machines - one for each end. A blockchain is another enormous state machine, made of thousands of “full node” state machines with lots of hangers-on called SPV clients. While the essence of the design of a state machine is pretty simple, using them is as much an art as a science because we don’t have a great view on how to compose small state machines into large state machines. But we’ll leave aside that complexity for now.

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

Choice

选择

It turns out that there are two fundamental approaches to building a state machine.

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

Note, what follows is a very stylised viewpoint, not a rigorous one. We ignore the code above, and just assume it is referenced wherever needed. We also ignore the output messages, for simplicity. Our goal is to get you to a state of understanding the message, not to impress CS geeks.
ian消息媒介3.png
请注意，以下是一个非常风格化的观点，而不是严谨的观点。我们忽略上面的代码，并假设它在需要的地方被引用。为简单起见，我们也忽略了输出消息。我们的目标是让普通人了解消息，而不是给CS极客们留下深刻印象。

We normally model the state machine as above - it starts out in State One, and then Message 1 arrives. The processing of this message causes a transition from State One to State Two. On transitioning to State 1, the machine sends out messages,although that is strictly optional - it depends on the machine’s needs at that transition.

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

Our job in building the state machine is to write the code to store and transition all states for all known messages. It turns out that, in doing this job, there are two fundamentally different ways in which to write the machine, and the choice of which colours our thinking, our design and eventually our capabilities.

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

First Way: Thinking of it as a machine of states. In this view, we store State One. Then, when the message arrives, the machine turns over to State Two, and we store that new state. Repeat! Think of the states as the Blue Circles above, and you can ignore any other view of the world.

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

Second Way: Thinking of it as a machine of messages. In this alternate view, we record the messages. We always start the machine at State One. Then we pump all of the incoming messages (Red Pills above) into the machine (and out pops any new messages). We store the messages, but don’t bother with the state, because we can calculate it any time.

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

These views are mostly equivalent in theory, and the trick to understanding this is that the machine is deterministic . Once we’ve established the machine as being exact and unforgiving in its actions, we know that for example M1 on State1 always results in State2 (and M2 out).

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

Then, if we have the machine, and we have the set of messages, we can always roll it again to get the states. OR , if we have recorded the states, we can always walk the chain of states to reproduce the action, although we don’t necessarily know what messages caused that journey. If you like your graphs, you could think of the distinction as storing the nodes OR storing the edges.

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

We have a choice about how we think about things. And, depending on our desires and assumptions, we are likely to prefer one way or the other: databases are seen as machines of state, as is a light switch - it knows whether it is on or off, but doesn’t know how it got to where it is now. Whereas protocols are typically thought of more as machines of messages; consider an email exchange in which the last message doesn’t tell you all the story, and if it’s been a while you might have to scan all the previous messages in thread to work out what’s happening.

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

photo.png（编辑部：图又挂了）

Wheretofore the machinery of blockchain?

区块链的机器在哪里

That’s in theory - practice can be different. Your online bank account is presented as a machine of state, with balance being told to you. But inside the bank, use of double entry accounting makes it more a machine of messages.

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

What should blockchain do?

区块链应该怎么做呢？

For reasons that might be historical, or maybe because it’s more typical for designers to think this way, blockchains are seen as machines of state, and not as machines of messages:

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

… The goal of a blockchain is to represent a single state being concurrently edited. In order to avoid conflicts between concurrent edits, it represents the state as a ledger, that is as a series of transformations applied to an initial state. These transformations are the “blocks” of the blockchain, and — in the case of Bitcoin — the state is mostly the set of unspent outputs.

(my emphasis) LM Goodman, “Tezos: A Self-Amending Crypto-Ledger Position Paper(https://tezos.com/static/papers/position_paper.pdf)”, 2013

Or, from a recent Ethereum replacement project:

或者，来自一个最近的Ethereum项目：

How do transaction semantics fit into our description of contracts? From the process level, a transaction is an acknowledgment that a message has been“witnessed” at a channel.
Messages themselves are virtual objects, but the pre-state and post-state of a contract , referring to the states before and after a message is sent by one agent and witnessed by another, are recorded and timestamped in storage , also known(in a moral sense) as the “blockchain”.
Message passing is an atomic operation. Either a message is witnessed, or it is not,and only the successful witnessing of a message qualifies as a verifiable transaction that can be included in a block.
(author’s emphasis in bold, my emphasis in italics ) anon?, “RChain Architecture - Contract Design(https://rchain-architecture.readthedocs.io/en/latest/contracts/contract-design.html) ”, 2017 RChain Cooperative

Note how the author above has established everything we need to store the message as transaction, and then fallen back to blockchain canon of state.

请注意上面的作者如何建立将消息存储为交易所需的一切，然后再回到区块链状态。

If we look at the Bitcoin state machine in Figure 4 below for another example, we can see this state view writ large in the UTXO model, which groups transactions as collections of Unspent Transaction Outputs (“UTXO”). The transaction is a record of state that includes the input, and the output. Comparing to Figure 3 above, think of both of the blue circles in each record, but none of the messages. Normally each UTXO transaction is represented as a box with a column of inputs on the left, and outputs on the right, Figure 4:

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

On the input (left) side of each transaction is a list of references to prior outputs or“coins”, by which presence they are then spent, and on the output (right) side is another matching list of new coins, by which presence they are now created and spendable in the future. Above, “Transaction 1” creates a 0.5BTC coin as an output, and “Transaction 2” spends the 0.5BTC coin by citing it as an input.

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

The Bitcoin transaction record, as a record of both inputs and outputs, is like a miniature balance sheet; the inputs match the outputs. For the visually minded,each of these transaction records is also like lego blocks in that new ones must plug onto old ones, and provide for newer ones to plug into them in the future.

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

The Brittleness of the UTXO

UTXO的脆弱性

Now, it has been observed before, but it is worth repeating: the Bitcoin design is of an extraordinary design, but one of its facets is that all of the components are strongly linked to each other in a very dependent way. As it says:

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

“ A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution. ”
Satoshi Nakamoto, “Bitcoin: A Peer-to-Peer Electronic Cash System(https://bitcoin.org/bitcoin.pdf) ” 2008.

The mission was the money, but the money is also the driver for the security model, by means of paying miners to compete to validate. This powerful facet of intra-dependency does have one weakness - it is brittle in architectural terms. By this, I do not mean that Bitcoin is about to fall apart at any moment, but rather, if we change one design element, it threatens the sanctity of the entire architecture.

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

And so it is with the UTXO. As mentioned, the mission of Bitcoin was a money. Every(full) node needs to have each record of the money available for it, so it can validate every incoming transaction, and proceed to distribute the transactions into its proposed block for mining. In contrast, SPV or remote clients need to have an easy way of proving just their component of incoming coins, without dragging in the whole chain.

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

These two requirements are in conflict. Because there are a lot of records in a big chain like Bitcoin, the UTXO layout is an elegant design that meets both those requirements with a reasonable efficiency given its other impacts. It is very good at providing the proof that a client needs at a point in time.

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

An Order Book

订单薄

But what happens to the UTXO when the requirements change? Let’s say we want to do trading. For various reasons, the best way to do this is to bring everyone together, construct an order book - a list of bids to buy versus a list of offers to sell - and then run an auction clearing process to find the best price for all traders. There are other ways of course, but this is both the time-tested way and the way imposed by exchanges.

Figure 5.

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

图5

ian消息媒介5.jpeg

In coming together in a UTXO state machine, an unknown number of people want to bid for positions on the buy side, as do an unknown number of people on the sell side. The UTXO design cannot easily facilitate this design for two reasons: 1. The interaction of many unknowns competing for one result does not scale because the entire layout needs to be negotiated on the fly - inputs, outputs and prices! – between the competing traders; and 2. trading is information sensitive - if there is a way to pull out of the negotiation and collapse it, traders will do that once they’ve spotted your position. This is a fundamental contradiction!

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

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

A messaging flow can handle this conundrum easily. If the blockchain intermediator (the miner in a PoW design, or the producer in DPOS) receives a steady series of messages for bids and offers, he simply collects them up in order and hands them to the “book contract” which internally constructs the book, decides on the swap price,and sends new messages out confirming the contract’s outcome.

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

Figure 6 - the Red Pill Trading Book of Messages.png（编辑部：图挂了again）

The messages are logged, but the state (e.g., UTXO) is implied , which means it is constructed by the computer internally, and then (can be) thrown away. As long as the blockchain has decided on the strict set of messages - both which messages and in what order - the result is deterministic because every other node runs the same contract for each set of the same input messages, and concurs on the output messages.

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

Two more advantages: if any incoming trades are dropped in this block they can simply be deferred to the next block. That’s because the incoming messages are independent intents to trade whenever, whereas the inputs and outputs making the UTXO state are more constrained to being parts of their dependent collection that should happen now, inside that very transaction.

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

Secondly. This construct captures much more of the problem of the trading book.That is, when you want to trade with me, or I with you, we both write our bid/offer as a message and send it in. The hard part is done inside the contract, and the smart contract author has covered that in her design. In contrast, with the UTXO construct, it is you and I that have to lay out the blue box in Figure 5, agree on everything, sign off and then submit it for consensus. UTXO leaves the hard part to us the traders, and the easy part - logging the fact - to the chain.

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

As an exercise, you might like to examine how you would handle fees in both designs.

作为练习，你可能想要了解如何处理两种设计中的费用。

Slight Demurral

小小异议

It’s not all one way - the state model has the benefit of trapping bugs more quickly.Every transaction has to be perfectly in agreement in its recorded state, not just the messages that got us there. This ability to trap errors quickly could be seen as a major advantage in reconciliation of trades, which the banking sector is looking at for cost and operational risk reduction.

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

But even this could be a choice of risks - when a bug turns up in a blockchain, the chain quickly breaks and forks.

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

Everything stops while nodes argue and hash. When a bug hits a message-model chain, the bug is implicit, and for the most part generates a dispute between parties over the meaning of the messages. Persons impacted can take it offline; including, we could develop the proofs to watch the issue offline, or exchain.

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

Conclusion

总结

The messaging model is for many reasons superior to the state model for the purpose of building broadly capable blockchains. It’s not all one way - the state model has the benefit of trapping breaks more quickly.

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

A fuller post would list all the pros and cons, but for now, we’ll just call out one major pro. Other than the ?exibility of the above example, messaging chains can reach much higher performance. For example, Bitshares and Steem by@danthemamn were all built on this model, and show 1000s of transactions per second. As was my Ricardo system, albeit non-blockchain, but it explains why it is so easy for me to like :-)

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

On paper at least, this approach promises much higher performance, and you can possible see a hint that EOS will be built this way too! Indeed, it was the need for speed in those systems that led designer @dantheman and myself to the discovery that, with apologies to Marshall McLuhan,