The Message is the Medium
信息就是中介
作者：Ian Grigg
翻譯：Gavin
校對(duì)：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 ‘a(chǎn)tomic 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.
這篇文章介紹了我認(rèn)為幾乎所有區(qū)塊鏈設(shè)計(jì)中都存在的一個(gè)基本缺陷。簡(jiǎn)而言之，當(dāng)我們使用消息來(lái)構(gòu)建時(shí)，強(qiáng)調(diào)將state作為“核心元素”。這其中的影響是相當(dāng)巨大的，但也很難理解，因?yàn)橛?jì)算機(jī)科學(xué)的概念對(duì)not-CS世界來(lái)說(shuō)有點(diǎn)難以理解。
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.
接下里是一個(gè)非正式的、非嚴(yán)格的描述，試圖向一些非該專業(yè)領(lǐng)域的讀者解釋消息和state的區(qū)別。我試著以簡(jiǎn)單的方式來(lái)引導(dǎo)大家理解它，但是如果你發(fā)現(xiàn)自己還是處在一種混亂的狀態(tài)下，這有另一種理解它的方法那就是關(guān)注進(jìn)一步的進(jìn)展——我們要建立它，這樣信息就會(huì)被放到媒介上。有點(diǎn)糟糕的比喻，讓我們繼續(xù)吧。
What’s a State Machine, anyway?
所以什么是狀態(tài)機(jī)
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.
狀態(tài)機(jī)是一種計(jì)算機(jī)科學(xué)發(fā)明 ，用于捕獲可靠的、具有確定性信息的機(jī)器。 簡(jiǎn)而言之，它是一個(gè)軟件“機(jī)器”，它被給與一系列輸入和內(nèi)存，總是提供相同的輸出。
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!).
想想一臺(tái)自動(dòng)售貨機(jī)，以及內(nèi)部的軟件，它必須模擬外部硬件，以便確定下一步該做什么。 換句話說(shuō)，“如果我們處于狀態(tài)1，就是等待投入硬幣。 如果硬幣投進(jìn)來(lái)，就轉(zhuǎn)換到狀態(tài)2。如果處于狀態(tài)2，就是等待按鈕按下。 如果一個(gè)按鈕按下，提供飲料，轉(zhuǎn)到狀態(tài)1。”從本質(zhì)上說(shuō)，我們的機(jī)器包含一些代碼來(lái)處理該算法，一些state（內(nèi)存）來(lái)存儲(chǔ)我們的狀態(tài)，以及讀取傳入消息（ 硬幣，按鈕）和做出一些行為作為輸出消息（飲料！）的能力。
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.
我們還可以用較小的狀態(tài)機(jī)構(gòu)建更大的狀態(tài)機(jī) - 數(shù)據(jù)庫(kù)本質(zhì)上是一個(gè)巨大的狀態(tài)機(jī)，由每個(gè)SQL表的每行和每個(gè)單元作為多個(gè)小的狀態(tài)機(jī)構(gòu)成的。 協(xié)議是由兩臺(tái)狀態(tài)機(jī)組成的小型狀態(tài)機(jī) - 每端一臺(tái)。 區(qū)塊鏈?zhǔn)橇硪粋€(gè)巨大的狀態(tài)機(jī)，由數(shù)千個(gè)“全節(jié)點(diǎn)”狀態(tài)機(jī)組成，其中有許多掛機(jī)，稱為SPV客戶端。 雖然狀態(tài)機(jī)設(shè)計(jì)的本質(zhì)非常簡(jiǎn)單，但使用它們既是一門科學(xué)又是一門藝術(shù)，因?yàn)槲覀儗?duì)如何將小型狀態(tài)機(jī)組成大型狀態(tài)機(jī)沒(méi)有很深入的了解。 我們暫時(shí)不考慮這種復(fù)雜性。
Choice
選擇
It turns out that there are two fundamental approaches to building a state machine.
事實(shí)證明，構(gòu)建狀態(tài)機(jī)有兩種基本方法。
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.
請(qǐng)注意，以下是一個(gè)非常風(fēng)格化的觀點(diǎn)，而不是嚴(yán)謹(jǐn)?shù)挠^點(diǎn)。 我們忽略上面的代碼，并假設(shè)它在需要的地方被引用。 為簡(jiǎn)單起見(jiàn)，我們也忽略了輸出消息。我們的目標(biāo)是讓普通人了解消息，而不是給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.
我們通常以上述方式對(duì)狀態(tài)機(jī)進(jìn)行建模 - 它從狀態(tài)1開(kāi)始，然后到達(dá)消息1。處理此消息會(huì)導(dǎo)致從狀態(tài)1轉(zhuǎn)換到狀態(tài)2。 在轉(zhuǎn)換到狀態(tài)1時(shí)，機(jī)器發(fā)出消息，盡管這是非常嚴(yán)格并且可選的 – 但它還是取決于機(jī)器在該轉(zhuǎn)換時(shí)的需求。
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.
我們構(gòu)建狀態(tài)機(jī)的工作是編寫代碼來(lái)實(shí)現(xiàn)存儲(chǔ)和轉(zhuǎn)換所有已知信息的狀態(tài)。 事實(shí)證明，在完成這項(xiàng)工作時(shí)，有兩種根本不同的方式來(lái)編寫機(jī)器，以及選擇哪種取決于我們的思維、設(shè)計(jì)和能力。
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.
第一種方法：把它看作是一種狀態(tài)的機(jī)器。在這個(gè)視圖中，我們存儲(chǔ)狀態(tài)1。然后，當(dāng)消息到達(dá)時(shí)，機(jī)器轉(zhuǎn)到狀態(tài)2，然后存儲(chǔ)這個(gè)新?tīng)顟B(tài)。重復(fù)這個(gè)循環(huán)，把這些狀態(tài)想象成上面的藍(lán)色圓圈，你就可以忽略任何其他的世界角度。
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.
第二種方法：把它看作是信息的機(jī)器。在這個(gè)備用視圖中，我們記錄消息，并且總是在狀態(tài)1的時(shí)候啟動(dòng)機(jī)器。然后，我們將所有需要輸入的信息(上面的紅色藥丸)輸入到機(jī)器(并彈出任何新的信息)中。我們存儲(chǔ)信息，但不關(guān)心狀態(tài)，因?yàn)橛辛诵畔⒅笪覀兛梢噪S時(shí)計(jì)算出狀態(tài)的情況。
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).
這些觀點(diǎn)在理論上大多相同，理解這一點(diǎn)的關(guān)鍵是“機(jī)器是確定性的”。 一旦我們確定機(jī)器在其動(dòng)作中是精確且無(wú)情的，我們就知道例如狀態(tài)1上的M1總是導(dǎo)致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.
然后，如果我們有機(jī)器，并且我們有一組消息，就可以再次滾動(dòng)它以獲得狀態(tài)。或者，如果我們記錄了狀態(tài)，我們總是可以根據(jù)一系列狀態(tài)的轉(zhuǎn)換來(lái)重現(xiàn)action，盡管我們不一定知道哪些消息導(dǎo)致了這一狀態(tài)轉(zhuǎn)換。 如果你喜歡圖形學(xué)，你可以想一下以節(jié)點(diǎn)存儲(chǔ)和以邊存儲(chǔ)的區(qū)別。
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.
我們可以選擇如何思考問(wèn)題。 而且，根據(jù)我們的愿望和假設(shè)，可能會(huì)更喜歡這樣或那樣的方式：數(shù)據(jù)庫(kù)被視為狀態(tài)機(jī)器，就像燈開(kāi)關(guān)一樣 - 它知道它是打開(kāi)還是關(guān)閉，但不知道它是怎樣到了現(xiàn)在的位置。 而協(xié)議通常被認(rèn)為更像是消息機(jī)器; 考慮一個(gè)電子郵件交換，其中最后一條消息沒(méi)有告訴你所有的故事，如果它已經(jīng)持續(xù)了一段時(shí)間，你可能必須掃描線程中的所有之前的消息來(lái)弄清楚發(fā)生了什么。
photo.png（編輯部：圖又掛了）
Wheretofore the machinery of blockchain?
區(qū)塊鏈的機(jī)器在哪里
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.
這是理論上的 - 實(shí)踐可能會(huì)有所不同。 你的網(wǎng)上銀行帳戶被看做是一臺(tái)狀態(tài)機(jī)，并告知你余額。 但在銀行內(nèi)部，使用雙重輸入運(yùn)算使其更像是一種信息機(jī)器。
What should blockchain do?
區(qū)塊鏈應(yīng)該怎么做呢？
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:
由于可能是歷史性的原因，或者因?yàn)樵O(shè)計(jì)師以這種方式思考更典型，因此區(qū)塊鏈被視為狀態(tài)機(jī)器，而不是消息機(jī)器：
… 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:
或者，來(lái)自一個(gè)最近的Ethereum項(xiàng)目：
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 ”, 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.
請(qǐng)注意上面的作者如何建立將消息存儲(chǔ)為交易所需的一切，然后再回到區(qū)塊鏈狀態(tài)。
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:
如果我們?cè)倏匆幌聢D4中的比特幣狀態(tài)機(jī)的另一個(gè)例子，我們可以看到這個(gè)狀態(tài)視圖在UTXO模型中特別強(qiáng)調(diào)，它將交易分組為Unspent Transaction Outputs（“UTXO”）的集合。 交易是包含輸入和輸出的狀態(tài)記錄。 與上面的圖3相比，考慮每個(gè)記錄中的兩個(gè)藍(lán)色圓圈，但沒(méi)有消息。 通常，每個(gè)UTXO交易都表示為一個(gè)框，左側(cè)是輸入列，右側(cè)是輸出，圖4：
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.
在每個(gè)交易的輸入（左）側(cè)是先前交易的輸出或“硬幣”的引用列表，通過(guò)這樣的方式，確認(rèn)硬幣存在，然后花掉它，并且在輸出（右）側(cè)是另一個(gè)匹配的新硬幣列表，通過(guò)這種方式，確認(rèn)它們現(xiàn)在已經(jīng)被創(chuàng)造出來(lái)并在將來(lái)可以被消費(fèi)。 在上面，“交易1”創(chuàng)建0.5個(gè)BTC作為輸出，“交易2”通過(guò)引用它作為輸入來(lái)花費(fèi)0.5個(gè)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.
比特幣交易記錄，作為輸入和輸出的記錄，就像一個(gè)微型資產(chǎn)負(fù)債表; 輸入與輸出匹配。 對(duì)于具有視覺(jué)意識(shí)的人來(lái)說(shuō)，這些交易記錄中的每一個(gè)都像樂(lè)高方塊一樣，新的必須覆蓋舊的，并提供更新的以便在將來(lái)可以覆蓋掉它們。
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:
現(xiàn)在，它之前已經(jīng)被察覺(jué)到，但有必要復(fù)述一下：比特幣具有非凡的設(shè)計(jì)，但其中一個(gè)方面是所有組件都以非常依賴的方式彼此緊密相連。 正如它所說(shuō)：
“ 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 ” 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.
任務(wù)是貨幣，但貨幣也是安全模型的驅(qū)動(dòng)力，通過(guò)支付礦工競(jìng)爭(zhēng)驗(yàn)證。 內(nèi)部依賴的這個(gè)強(qiáng)大部分確實(shí)存在一個(gè)缺點(diǎn) - 在架構(gòu)方面它很脆弱。 通過(guò)這種方式，我并不是說(shuō)比特幣隨時(shí)都會(huì)崩潰，而是如果我們改變一個(gè)設(shè)計(jì)元素，它就會(huì)威脅整個(gè)構(gòu)造的神圣性。
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。 如上所述，比特幣的使命是為一種貨幣。每個(gè)（全）節(jié)點(diǎn)都需要擁有可用資金的每一條記錄，因此它可以驗(yàn)證每個(gè)傳入的交易，并繼續(xù)將交易分發(fā)到其適合的采集區(qū)塊中。 相比之下，SPV或遠(yuǎn)程客戶端需要有一種簡(jiǎn)單的方法來(lái)證明其輸入的幣的組成部分，以保證不會(huì)拖累整個(gè)鏈。
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.
這兩個(gè)請(qǐng)求是沖突的。 由于比特幣這樣的大型鏈中有很多記錄，因此UTXO布局是一種優(yōu)雅的設(shè)計(jì)，在其他影響的情況下以合理的效率滿足這些要求。 它非常擅長(zhǎng)提供客戶在某個(gè)時(shí)間點(diǎn)需要的證據(jù)。
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.
但是當(dāng)需求發(fā)生變化時(shí)，UTXO會(huì)發(fā)生什么？ 假設(shè)我們想做交易。 出于各種原因，最好的方法是將所有人聚集在一起，構(gòu)建一個(gè)訂單簿 – 要求購(gòu)買的出價(jià)列表與要出售的標(biāo)價(jià)列表 - 然后進(jìn)行拍賣結(jié)算流程以找到所有交易者的最佳價(jià)格。 當(dāng)然還有其他方式，但這既是經(jīng)過(guò)時(shí)間考驗(yàn)的方式，也是加強(qiáng)交流的方式。
圖5
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狀態(tài)機(jī)中聚集在一起時(shí)，我們是不知道想要競(jìng)標(biāo)買家的地位有多少，也不知道賣方的人數(shù)有多少。 UTXO設(shè)計(jì)過(guò)程中不能輕易地完成這種設(shè)想，原因有兩個(gè)：1，競(jìng)爭(zhēng)一個(gè)結(jié)果的許多未知因素的相互作用無(wú)法擴(kuò)展，因?yàn)檎麄€(gè)布局需要?jiǎng)討B(tài)協(xié)商 - 輸入、輸出和價(jià)格！ - 在競(jìng)爭(zhēng)交易者之間;
2，交易是信息敏感的 - 交易者一旦發(fā)現(xiàn)你坐上買家的地位就會(huì)想辦法退出談判并使你崩潰。 這是一個(gè)根本的矛盾！
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.
消息流可以輕松處理這個(gè)難題。 如果區(qū)塊鏈中間人（PoW設(shè)計(jì)中的礦工，或DPOS中的生產(chǎn)者）收到一系列穩(wěn)定的出價(jià)和報(bào)價(jià)信息，他只需按順序收集它們并將它們交給內(nèi)部構(gòu)建訂單薄的“書面合約”，然后決定交換價(jià)格，并發(fā)出新的確認(rèn)合約的消息結(jié)果。
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.
消息被記錄，但狀態(tài)（例如，UTXO）是隱含的，這意味著它由計(jì)算機(jī)內(nèi)部構(gòu)建，然后（可以）被丟棄。 只要區(qū)塊鏈決定了嚴(yán)格的消息集 - 消息和按什么順序 - 結(jié)果是確定性的，因?yàn)槊總€(gè)其他節(jié)點(diǎn)為每組相同的輸入消息運(yùn)行相同的合約，并且同意輸出消息。
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.
還有兩個(gè)優(yōu)點(diǎn)：如果在這個(gè)區(qū)塊中丟棄了任何傳入的交易，它們可以簡(jiǎn)單地被推遲到下一個(gè)區(qū)塊。 這是因?yàn)閭魅氲南o(wú)論什么時(shí)候進(jìn)行交易都是具有獨(dú)立意圖的，而構(gòu)成UTXO狀態(tài)的輸入和輸出更多地受制于它們的依賴集合的一部分，這些集合現(xiàn)在應(yīng)該在該交易中發(fā)生。
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.
其次。 這個(gè)結(jié)構(gòu)捕獲了交易賬戶的更多問(wèn)題。也就是說(shuō)，當(dāng)你想與我交易，或者我和你交易時(shí)，我們都將我們的買入/賣出作為信息寫入并發(fā)送給它。困難的部分是在合約里面完成的。 完整的合約作者在他的設(shè)計(jì)中已經(jīng)涵蓋了這一點(diǎn)。 相比之下，使用UTXO構(gòu)造，你和我必須在圖5中展示藍(lán)框，同意所有內(nèi)容，簽字然后提交以達(dá)成共識(shí)。 UTXO給交易員帶來(lái)了困難的部分，而將簡(jiǎn)單的部分 - 記錄事實(shí) - 留給了鏈。
As an exercise, you might like to examine how you would handle fees in both designs.
作為練習(xí)，你可能想要了解如何處理兩種設(shè)計(jì)中的費(fèi)用。
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.
它并非都是單向的 - 狀態(tài)模型具有更快地捕獲錯(cuò)誤的好處。每個(gè)交易必須在其記錄狀態(tài)下完全一致，而不僅僅是讓我們?cè)谀抢锏南ⅰ?這種快速捕獲錯(cuò)誤的能力可被視為交易對(duì)賬的主要優(yōu)勢(shì)，銀行業(yè)正在考慮降低成本和降低運(yùn)營(yíng)風(fēng)險(xiǎn)。
But even this could be a choice of risks - when a bug turns up in a blockchain, the chain quickly breaks and forks.
但即使這樣也可能是有風(fēng)險(xiǎn)的選擇 - 當(dāng)區(qū)塊鏈中出現(xiàn)bug的時(shí)候，鏈會(huì)迅速斷裂和分叉。
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.
當(dāng)節(jié)點(diǎn)沖突和哈希時(shí)，一切都停止了。 當(dāng)bug出現(xiàn)在消息模型鏈中時(shí)，該bug是隱含的，并且在很大程度上會(huì)在各方之間產(chǎn)生關(guān)于消息含義的爭(zhēng)議。 受影響的人可以將其變?yōu)槊摍C(jī)狀態(tài); 包括，我們可以緩存證據(jù)來(lái)離線觀看問(wèn)題，或者交換。
Conclusion
總結(jié)
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.
為了構(gòu)建功能廣泛的區(qū)塊鏈，消息傳遞模型有許多優(yōu)于狀態(tài)模型的原因。 這并不是一個(gè)單一的方式 - 狀態(tài)模型有更快地捕獲中斷的好處。
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 :-)
一個(gè)更全面的帖子會(huì)列出所有的優(yōu)點(diǎn)和缺點(diǎn)，但是現(xiàn)在，我們只會(huì)召集一個(gè)主要專業(yè)人士。 除了上述示例的靈活性之外，消息傳遞鏈可以達(dá)到更高的性能。 例如，@ danthemamn的Bitshares和Steem都是建立在這個(gè)模型上的，并且每秒顯示1000次交易。 和我的Ricardo系統(tǒng)一樣，雖然是非區(qū)塊鏈，但它解釋了為什么我這么喜歡:-)
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,
the message is the medium.
至少在理論上，這種方法可以提供更高的性能，你可以看到EOS也將以這種方式構(gòu)建的暗示！ 事實(shí)上，正是這些系統(tǒng)的速度需要導(dǎo)致設(shè)計(jì)師@dantheman和我自己發(fā)現(xiàn)，向Marshall McLuhan道歉：
信息是一切中介。
本文圖片來(lái)源于英文原文
版權(quán)聲明：
以下內(nèi)容來(lái)自微信公共帳號(hào)“EOS技術(shù)愛(ài)好者”，搜索“EOSTechLover”即可訂閱，翻譯Gavin，校對(duì)Lochaiching。轉(zhuǎn)載必須保留以上聲明。僅授權(quán)原文轉(zhuǎn)載。
本文原文鏈接為https://busy.org/@iang/the-message-is-the-medium
"EOS技術(shù)愛(ài)好者"全程由EOShenzhen運(yùn)營(yíng)，喜歡我們請(qǐng)為我們投票：（EOShenzhen的投票賬號(hào)：eoshenzhenio）！
了解更多關(guān)于EOShenzhen：
關(guān)于我們更多聯(lián)系：
Website：https://eoshenzhen.io
Steem：https://steemit.com/@eoshenzhen
Busy：https://busy.org/@eoshenzhen
Telegram：https://t.me/eoshenzhen
Twitter：https://twitter.com/eostechlover
簡(jiǎn)書：EOS技術(shù)愛(ài)好者
新浪微博：EOSTechLover
EOShenzhen的投票賬號(hào)：eoshenzhenio
