V神設計理念公佈，細數以太坊潛在的優缺點

此處此處此處

此處

原文的寫作時間不確定，但可將其視為一個原點，反思以太坊的設計理念以及以太坊在這幾年間的演化。既是反思其創新，也是反思其有欠考慮的地方。

原則

一級標題

• 原則

• 以太坊協議的設計遵循以下幾點原則：

• 三明治複雜模型（亦可譯為“複雜度分層模型” ）：我們認為以太坊的底層協議應盡可能的簡單，接口設計應易於理解（不論是面向開發者的高級編程語言接口，還是面向用戶的使用接口）。那些不可避免的複雜部分應放入中間層。中間層不作文核心共識的一部分，且對最終用戶不可見，它包含：高級語言編譯器、參數序列化和反序列化腳本、存儲數據結構模型、leveldb 存儲接口以及聯網協議等。當然，區分的界線不是絕對明確的，有時候需要酌情調整。

• 自由：不應限制用戶使用以太坊協議，也不應試圖優先支持或不支持某些以太坊合約或交易。這一點與“網絡中立” 概念背後的指導原則相似。比特幣交易協議就沒有遵循這一原則：比特幣交易協議並不鼓勵區塊鏈的“非常規用途（off-labal purpose）” （如，數據存儲，元協議）（校對注：off-labal 的原意為將藥物用在其經過批准的適應症之外的症狀上，例如使用止咳藥來治療頭痛。此處意譯為“非常規用途” ）；而且，有時候還有人用準-協議層的變更（例如將OP_RETURN 字段的長度限制在40 字節）來攻擊以“未經授權” 的方式使用區塊鏈的應用（校對注：此處是在諷刺比特幣的社區有審查比特幣區塊鏈用法的傾向）。因此，在以太坊，我們堅定支持僅使用交易手續費來達成大體激勵相容的辦法—— 用戶消耗整個網絡越多資源，需要付出的代價就越高，也即使其自己承擔成本（即庇古稅）。

• 不厭惡風險：如果風險的增加帶來了可觀的好處，我們願意承擔更高的風險（例如，通用的狀態轉換，出塊時間減低50 倍，共識效率，等等）。

一級標題

區塊鏈層協議

二級標題

二級標題

二級標題

1.每個被引用的輸入必須有效，且未被使用過；2.交易的簽名必須與每筆輸入的所有者簽名匹配；3.輸入的總值必須等於或大於輸出的總值。

圖片描述

圖片描述

圖片描述

- 比特幣所用的三式記賬法 -

• 但是，以太坊拋棄了UTXO 的方案，轉而使用更簡單的方法：採用狀態（state）的概念存儲一系列賬戶，每個賬戶都有自己的餘額，以及以太坊特有的數據（代碼和內部存儲器）。如果交易發起方的賬戶餘額足夠支付交易費用，則交易有效，那麼發起方賬戶會扣除相應金額，而接收賬戶則計入該金額。某些情況下，接收賬戶內有需要執行的代碼，則交易會觸發該代碼的執行，那麼賬戶的內部存儲器可能會發生變化，甚至可能會創建額外的消息發送給其他賬戶，從而導致新的交易發生。儘管以太坊沒有採用UTXO 的概念，但UTXO 也不乏有一些優點：

• 較高程度的隱私保護：如果用戶每次交易都使用一個新的地址，那麼賬戶之間的相互關聯就很困難。這樣做適用於對安全性要求高的貨幣系統，但不是對任何dapp 都合適。因為dapp 通常需要跟踪用戶複雜的綁定狀態，而dapp 的狀態並不能像貨幣系統中的狀態那樣簡單地劃分。

潛在的可擴展性：

• 理論上來說，UTXO 與某些類型的可擴展性方案（scalability paradigm）更契合，因為只需持幣者擁有能夠證明自己貨幣所有權的默克爾證明即可，即使所有的人（包括TA 本人）都遺忘了這一數據，真正受損也這個人，其他人不受影響。在以太坊賬戶系統中，如果所有人都丟失了某個賬戶對應的默克爾樹部分，那麼該賬戶將無法處理任何能夠影響它的消息，包括發送給它的消息，它也無法處理。不過，並非只有UTXO 能夠可擴展，也存在不依賴UTXO 就能擴展的方式（此處沒有擴展開來講，譯者註）。

• 賬戶的好處有以下幾點：

• 節省大量空間：如果一個賬戶有5 個UTXO，則從UTXO 模式轉成賬戶模式，所需空間會從300 字節降到30 字節。具體計算如下：300 = (20+32+8）* 5 （20 是地址字節數，32 是TX 的id 字節數，8 是面額佔用的字節數）; 30 = 20 + 8 + 2 （ 20 是地址字節數，8 是賬戶餘額值字節數，2 是nonce 2 字節數）；但實際節約並沒有這麼大，因為賬戶需要被存儲在帕特里夏樹中。另外以太坊中交易也比比特幣中的更小（以太坊中100 字節，比特幣中200-250 字節），因為每次交易只需要生成一次引用，一次簽名，以及一個輸出。

• 可互換性更強：UTXO 結構並沒有區塊鏈層的概念，所以不管是在技術還是法律上，通過建立一個紅名單/黑名單，並依據的這些“有效輸出” 的來源區分它們並不是很實際。

簡單：以太坊編碼更簡單、更易於理解，尤其是在涉及到復雜腳本時。儘管任何去中心化應用都可以用UTXO 方式來（勉強）實現，但這種方式實質上是賦予腳本限制給定的UTXO 所能輸出的UTXO 的種類及其使用條件（比如需要包含默克爾樹證明來幫助腳本所對應的應用更改狀態根）的能力。因此，UTXO 實現方式比以太坊使用賬戶的方式要復雜的多。

輕客戶端：輕客戶端可以隨時通過沿指定方向掃描狀態樹來訪問與賬戶相關的所有數據。在UTXO 範式中，每筆交易需要用到的引用都不同，這對於長時間運行並使用了上文提到的UTXO 根狀態傳播機制的dapp 應用來說，無疑是繁重的。

我們認為，賬戶的好處大大超過了其他方式，尤其是對於我們想要支持的、可包含任意狀態和代碼的dapp 應用而言。另外，本著“沒有特點就是最大的特點” 的指導原則，我們認為如果用戶真的關心私密性，則可以通過合約中的簽名數據包協議來建立一個加密“混幣器（mixer and coinjoin）”混淆支付路徑。

校對注：這就是以太坊日後面臨的“狀態爆炸” 問題的技術原因：所有狀態數據必須完整保存，無法合理地刪除賬戶。作為一種區塊鏈協議，以太坊的節點不僅要對事務（交易）的順序達成共識，還要對全局狀態達成共識（表現形式就是區塊頭裡需要包括狀態根。因此，若要刪除狀態，也需要全網的共識，否則會陷入分裂。

這篇文章這篇文章。

這篇文章

這篇文章

• 默克爾帕特里夏樹（MPT）

• 默克爾帕特里夏樹（Merkle Patricia tree/trie），由Alan Reiner 提出設想，並在瑞波協議中得到實現，是以太坊的主要數據結構，用於存儲所有賬戶狀態，以及每個區塊中的交易和收據數據。 MPT 是默克爾樹和帕特里夏樹的結合，結合這兩種樹創建的結構具有以下屬性：

任一組鍵-值對所對應的根哈希值都是唯一的，想要謊稱某個鍵值對存在於某棵樹上是一定會被識破的（除非攻擊者擁有約2^128 的算力）。

增、刪、改一個鍵值對的時間複雜度是對數級別。

• MPT為我們提供了一個高效、易更新、且代表整個狀態樹的“指紋” 。關於MPT更詳細描述：https://github.com/ethereum/wiki/wiki/Patricia-Tree。

• MPT的具體設計決策如下：

• 有兩類節點：KV 節點和離散節點。 KV節點的存在提高了效率，因為如果在特定區域樹是稀疏的，KV節點可作為一個“捷徑” 來壓縮樹的高度（閱讀MPT 的詳述可了解更多細節）。

• 離散節點是十六進制，不是二進制：這樣讓查找更有效率，我們現在認識到這種選擇並不理想，因為十六進制樹的查找效率在二進制中可以通過批次存儲節點來模擬。但是，MPT 樹結構的實現是非常容易出錯的，最終至少會造成狀態根不匹配，所以我們決定擱置變更，等到1.1 版本再說。

• 空值（empty value）與非成員（non-membership）之間沒有區別：這樣做是為了簡化邏輯，以太坊中未啟用的賬戶的值（餘額）默認為0，空字符串也用0 表示。然而，需要強調的是，這樣做犧牲了一些通用性，因而也不是最優的。

終節點（terminating）和非終節點的區別：技術上，標識一個節點“是否是終節點” 是沒必要的，因為以太坊中所有的樹都被用於存儲固定長度（即鍵的長度）的數據，但為了增加通用性，我們還是會添加這個標識，以期望以太坊的MPT 的實現方式能夠被其他密碼學貨幣原樣採納。

在“安全樹”（狀態樹和賬戶存儲樹）中採用SHA3(k) 作為鍵：使用SHA3(k)，想要通過生成許多的賬戶（賬戶最多可讓狀態樹高達64 層！）並重複調用SLOAD 和SSTORE 操作碼來DoS 攻擊的難度會大大提高。注意，這也讓枚舉樹變得更困難；如果要使你的客戶端具備枚舉的功能，最簡單的方法就是維護一個映射sha3(k) -> k 的數據庫。

校對注：這裡的意思是，如果使用k 作為默克爾樹存儲數據的鍵，其分佈可能很稀疏，而攻擊者可以容易地規劃出需要很深的樹路徑來存儲的賬戶，並對這些賬戶重複調用狀態訪問操作，以此造成網絡中的節點超負荷運行，但是，哈希函數的結果是隨機分佈的，以sha3(k) 作為鍵可以使鍵的分佈較為均勻，樹高也會較矮）。

RLP

這種特性也是有得有失，這一方面意味著DoS 攻擊會變得更困難，另一方面，也使得一個區塊中的交易的狀態樹訪問路徑，很少有重合的，因此每次搜索都是複雜度最差的情形。

此外，這也使得MPT 不宜實現“無狀態性”（區塊自身攜帶驗證所需的數據、驗證者無需具有全局狀態），因為狀態訪問的路徑不重合，證據的空間效率也是最差情形。當然，也可以說，默克爾樹證據的空間效率本身也不夠高

RLP（recursive length prefix）：遞歸長度前綴。

RLP 編碼是以太坊中主要的序列化格式，它的使用無處不在：區塊、交易、賬戶狀態以及網絡協議消息。詳見RLP 正式描述： https://github.com/ethereum/wiki/wiki/RLP

RLP 旨在成為高度簡化的序列化格式，它唯一的目的是存儲嵌套的字節數組3。不同於protobuf、BSON 等現有的解決方案，RLP並不定義任何指定的數據類型，如Boolean（布爾值）、float（浮點數）、double 或者integer（整數）。它僅僅是以嵌套數組的形式存儲結構體，由協議來確定數組的含義。 RLP 也沒有顯式支持map 集合，半官方的建議是採用[[k1, v1], [k2, v2], ...] 的嵌套數組來表示鍵值對集合，k1,k2 ... 按照字符串的標準排序。

與RLP 具有相同功能的方案是protobuf 或BSON，它們是一直被使用的算法。然而，以太坊中，我們更偏向於使用RLP，因為：（1）它易於實現；（2）絕對保證字節的一致性。

許多語言的鍵值對集合沒有明確的排序，並且浮點格式有很多特殊情況，這可能造成相同數據卻產生不同編碼和不同哈希值。通過內部開發協議，我們能確保它是帶著這些目標設計的（這是一般原則，也適用於代碼的其他部分，如虛擬機）。 BitTorrent 使用的編碼方式bencode 也許可以替代RLP。不過它採用的是十進制的編碼方式，與採用二進制的RLP 相比，稍微遜色了點。

壓縮算法

網絡協議和數據庫都採用了一個自定義的壓縮算法來存儲數據。該算法可描述為：對0 使用行程編碼4 並同時保留其他值（除了一些特殊情況如sha3(' ') ），舉例如下：

壓縮算法存在之前，以太坊協議的許多地方都有一些特殊情況，例如，sha3 經常被重定義使得sha3(' ')=' '，這樣不需要在賬戶中存儲代碼，可以節省64 字節。然而，最近所有這些使得以太坊數據結構變得臃腫的特殊情況都被刪除了，取而代之的是將數據保存函數添加到區塊鏈協議之外的層，也就是將其放入網絡協議以及將其插入用戶數據庫實現。這樣增加了模塊化能力，簡化了共識層，使得對壓縮算法的持續更新部署起來相對簡單（例如：可通過網絡協議的版本號來區別、部署）。

樹（trie）的使用

• 提醒：理解這部分的知識需要讀者了解布隆過濾器5 的原理。簡介可見：http://en.wikipedia.org/wiki/Bloom_filter

• 以太坊區塊鏈中每個區塊頭都包含指向三個樹的指針：狀態樹、交易樹、收據樹。

• 狀態樹代表處理完該區塊後的整個狀態；

收據樹代表每筆交易相應的收據。

• 其中：

• 交易的收據是一個RLP 編碼的數據結構：

• 其中：

• medstate：交易處理後，狀態樹的根；

• logbloom：交易中所有logs 的address 和topics 組成的布隆過濾器。

註釋：

註釋：

• 註釋：

• 註釋：

• UTXO：unspent transaction outputs，字面理解是：未花費的交易輸出，也即未被任何交易引用為輸入的交易輸出。它是比特幣協議中用於存儲價值（所有權）信息的數據結構。 —— 校對注

  var cats : String[] = ["Cat","Beansprout", "Pumpkin", "Max"];
  var dogs : String[] = ["Dog","Oly","Sib"];
  var pets : String = [cats, dogs];
  

  Nonce，Number used once 或Number once 的縮寫，在密碼學中Nonce 是一個只被使用一次的任意或非重複的隨機數值，在加密技術中的初始向量和加密哈希函數都發揮著重要作用，在各類驗證協議的通信應用中確保驗證信息不被重複使用以對抗重放攻擊（Replay Attack）。 —— 譯者註

• 行程編碼（run-length-encoding）：一種統計編碼。主要技術是檢測重複的比特或字符序列，並用它們的出現次數取而代之。 （百度百科）—— 譯者註

• 一級標題

一級標題

一級標題

叔塊（uncle blocks）獎勵

GHOST 協議是一項不起的創新，由Yonatan Sompolinsky 和Aviv Zohar 在2013 年10 月首次提出的。它是解決快速出塊伴生問題的第一個認真嘗試。

GHOST 的用意是解決這樣一個難題：更短的出塊時間（因此確認速度會更快）會導致有更多區塊“過時” 因而安全性會下降—— 因為區塊在網絡中傳播需要一定時間，如果礦工A 挖到一個區塊並向全網廣播，在廣播的路上，B 也挖出了區塊，那麼B 的區塊是過時的，且B 的本次挖礦對網絡的安全沒有貢獻。

此外，還有一個中心化問題：如果A 是一個礦池，有30% 的算力，B 有10% 的算力。 A有70% 的時間產生過時的區塊（因為另外的30% 時間會產生最新區塊，可認為TA “立即” 得到了最新塊的數據而無需等待區塊傳播），而B 有90% 的時間產生過時區塊。如果區塊的產出時間間隔很短，那麼過時率就會變高，則A 憑藉其更大的算力使挖礦效率也更高。所以，區塊生成過快，容易導致網絡算力大的礦池在事實上壟斷挖礦過程。

根據Sompolinsky 和Zohar的描述，GHOST 解決了在計算哪個鍊是最長的鏈的過程中，因產生過時區塊而造成的網絡安全性下降的問題。也就是說，不僅是父區塊和更早的區塊，同時過時的旁支區塊（在以太坊中，我們稱之為“叔塊”）也被添加到計算哪個塊具有最大的總工作量證明中去。

• 為了解決第二個問題：中心化問題，我們採用了另一種策略：對過時區塊也提供區塊獎勵：挖到過時區塊的獎勵是該區塊基礎獎勵的7/8；而包含過時區塊的侄子區塊將收到1/32 的基礎獎勵作為賞金。但是，交易費不會獎勵給叔塊和侄塊。

• 在以太坊中，過時區塊只能被其兄弟區塊的7 代以內的直系後代區塊包含為叔塊。之所以這樣限制是因為，首先，GHOST 協議若不限製過時區塊的代際距離，將會花費大量開銷在計算過時區塊的有效性上；其次，無限制的過時區塊激勵政策會讓礦工失去在主鏈上挖礦的熱情；最後，計算表明，過時區塊獎勵政策限制在7 層內提供了大部分所需的效果，而且不會帶來負面效應。

度量中心化風險的一個模擬器可見此處：https://github.com/ethereum/economic-modeling/blob/master/ghost.py

一個更高層次的討論可見此處：https://blog.ethereum.org/2014/07/11/toward-a-12-second-block-time/

• 校對注：此處的“包含” 在技術上的形式是：侄塊在區塊頭中引用叔塊的區塊哈希值，然後把叔塊的區塊頭包含在區塊體內。

• 區塊時間算法的設計決策包括:

• 區塊時間12s：選擇12 秒是因為這已經是長於網絡延遲的最短時間間隔了。在2013 年的一份關於測量比特幣網絡延遲的論文中，確定了12.6 秒是新產生的區塊傳播到95% 節點的時間；然而，該論文還指出傳播時間與區塊大小成比例，因此在更快的貨幣中，我們可以期待傳播時間大大減少。傳播間隔時間是恆定的，約為2 秒。然而，為了安全起見，在我們的分析中，我們假定區塊的傳播需要12 秒

• 叔塊必須是有效的：叔塊必須是有效的header，而不是有效的區塊。這樣做也是為了簡化，將區塊鏈模型保持為線性數據結構（而不會變成DAG）。不過，要求叔塊是有效的區塊也是有效的方法。

• 一級標題

一級標題

一級標題

難度更新算法

• 目前以太坊通過以下規則進行難度更新：

• 難度更新規則的設計目標如下：

• 快速更新：區塊間的時間應該隨著hash 算力的增減而快速調整；

• 低波動性：如果挖礦算力恆定，那麼難度不應劇烈波動；

• 不可爆破：算法不應讓礦工有過多篡改時間戳或者礦池反复添加或刪除算力的激勵

一級標題

一級標題

一級標題

Gas 和費用

• 比特幣中所有交易大體相同，因此它們的網絡成本用單一一種單位來模擬。以太坊中的交易要更複雜，所以交易費用需要考慮到賬戶的許多方面，包括網絡帶寬費用、存儲費用和計算費用。尤其重要的是，以太坊編程語言是圖靈完備的，所以交易會使用任意數量的寬帶、存儲和計算成本；而最終會使用多少數量是無法可靠預測的（因為所謂的“圖靈停機問題” ）（校對注：即不存在一個可靠的辦法，能夠斷言任意可在圖靈機上執行的程序會不會在有限步內終止）。防止有人使用無限循環來實施拒絕服務式攻擊是我們的一個關鍵目標。

• 以太坊交易費用的基本機制如下：

• 每筆交易必須指明自身願意消耗的gas 數量（即指定startgas 的值），以及願意為每單元gas 支付的費用（即gasprice ），在交易執行開始時，startgas * gasprice 價值的以太幣會從發送者賬戶中扣除；（校對注：此處的startgas 就是我們現在慣用的gaslimit 。）

• 交易執行期間的所有操作，包括讀寫數據庫、發送消息以及每一步的計算都會消耗一定數量的gas；

• 如果交易執行完畢，消耗的gas 值小於指定的限制值，則交易執行正常，並將剩餘的gas 值賦予變量gas_rem ; 在交易完成後，發送者會收到返回的gas_rem * gasprice 價值的以太幣，而給礦工的獎勵是（startgas - gas_rem）* gasprice 價值的以太幣；如果交易執行中，gas消耗殆盡，則所有的執行恢復原樣，但交易仍然有效，只是交易的唯一結果是將startgas * gasprice 價值的以太幣支付給礦工，其他不變；》）

當一個合約發送消息給另一個合約，可以對這個消息引起的子執行設置一個gas 限制。如果子執行耗盡了gas，則子執行恢復原樣，但gas 仍然消耗。 （校對注：截至本文校對之時（2021 年7 月9 日），這一點還未改變，但它在未來有可能會改變。見《

• 值得考慮刪除的EVM 功能

• 上述提到的幾點都是必須滿足的，例如：

• 如果交易不需要指定gas 限制，那麼惡意用戶就會發送一個有數十億步循環的交易。沒有人能夠處理這樣的交易，因為處理這樣的交易花的時間可能很長很長；但是誰也無法預先告知網絡上的礦工，這就會導致拒絕服務的漏洞產生。

• 一種替代嚴格gas 計數的方法是時間限制，但它不可能有用，因為它們太主觀了（某些計算機比別人的更快，即使大家的計算機都一樣也仍然有可能出現差池）。

• startgas * gasprice 的整個值，在開始時就應該設置好，這樣不至於在交易執行中造成該賬戶“破產”、無力繼續支付gas 費用。一邊執行一邊檢查餘額也不行，因為賬戶可以把餘額放到別的地方。

• 如果在gas 不夠的情況下，交易執行不會完全復原（回滾），合約就必須採用強有力的安全措施來防止合約發生變化。

如果子限制不存在，則惡意賬戶可以對其他合約實施拒絕服務攻擊。攻擊者可以先與受害合約達成一致意見，然後在計算過程開始時插入一個無限循環，那麼發送消息給受害合約或者受害合約的任何補救嘗試，都會使整個交易死鎖。 （校對注：此句亦難解。）

• 要求交易發送者而不是合約來支付gas，這樣大大增加了開發人員的可操作性。以太坊早期的版本是由合約來支付gas的，這導致了一個相當嚴重的問題：每個合約必須實現“門衛” 代碼，確保每個傳入的消息為合約提供了足夠的以太幣供其消耗。

• gas 消耗計算有以下特點：

• 對於任何交易，都將收取21000 gas 的基本費用。這些費用可用於支付運行橢圓曲線算法所需的費用（該算法旨在從簽名中恢復發送者的地址）以及存儲交易所花費的硬盤和帶寬空間。

• 交易可以包括無限量的“數據” 。虛擬機中的某些操作碼，可以讓收到這樣交易的合約訪問這些數據。數據的“固定消耗量” 規則是：每個零字節4 gas，非零字節68 gas。這個公式的產生是因為用戶向合約發送的交易中，大部分的交易數據由一系列的32 字節的參數組成，其中多數參數具有許多前導零字節。該結構看起來似乎效率不高，但由於壓縮算法的存在，實際上還是很有效率的。我們希望此結構能夠代替其他更複雜的機制：這些機制根據預期字節數嚴格包裝參數，從而導致編譯階段複雜性大增。這是三明治複雜模型的一個例外，但由於成本效益比，這也是合理的模型。用於設置賬戶存儲項的操作碼SSTORE 的消耗是：1）將零值改為非零值時，消耗20000 gas；2）將零值變成零值，或非零值變非零值，消耗5000 gas；3）將非零值變成零值，消耗5000 gas；此外，交易執行成功（即未耗盡gas 交易就執行完了）後會退回15000 gas。退款金額上限是交易消耗gas 總額的50%。這給了人們小小激勵去清除存儲項。我們注意到，正因為缺乏這樣的激勵，許多合約的存儲空間沒有被有效使用，從而導致了存儲數據的快速膨脹。這一設計既能提供“為存儲項持續收取租金” 模式的大部分好處，又不會失去合約一旦確立就可以永久存在的保證。延遲退款機制是必要的，因為可以阻止拒絕服務攻擊：攻擊者可以發送一筆含有少量gas 的交易，循環清除大量的存儲項，直到用光gas，這樣消耗了大量的驗證算力，但實際並沒有真正清除存儲，也不需要付出很多gas。 50% 的上限的是為了確保打包交易的礦工依然能夠確定執行交易的計算時間的上限。（校對注：首先，SSTORE 等狀態訪問操作碼的gas 消耗量已經隨著以太坊的硬分叉而多次更改。截至2021 年7 月，最新的數值可見《柏林昇級內容概覽》。）

• 》；在可預見的未來，這個操作碼的數值還會繼續變化；其次，這裡的gas refund 機制，事後證明並沒有啟動緩解狀態數據的膨脹問題，反而惡化了該問題，因為人們可以在gas price較低時寫入大量垃圾數據，在gas price 較高時清除這些數據來獲得gas，這就是“GasToken” 的原理。當前已確定，在“倫敦” 分叉中會改變gas refund 機制，見《

• 以太坊“倫敦” 升級預覽

• 合約提供的消息數據是沒有成本的。因為在消息調用期間不需要實質複製任何數據，調用數據（call data）可以簡單地視為指向父合約memory 的指針，該指針在子進程執行時不會改變。

• Memory 是一個可以無限擴展的數組，然而，每擴展32 字節的memory 就會消耗1 gas 的成本，不足32 字節以32 字節計。 （校對注：memory 一般譯為內存，但在以太坊的語境下，它是EVM 由於存儲數據的三種類型之一，因此都不譯，以示其特殊性。）某些操作碼的計算時間極度依賴參數，gas 開銷計算是動態變化的。例如，EXP 的的開銷是指數級別的（10 gas + 10 gas/字節，即，x^0 = 1 gas、x^1 … x^255 = 2 gas、x^256 … x^65535 = 3 gas ，等等）。複製操作碼（如：CALLDATACOPY, CODECOPY, EXTCODECOPY）的開銷是1 gas + 1 gas/32 字節（四捨五入；LOG 操作碼的規則也類似）。 Memory 擴展的開銷不包含在這裡。如若包含，會變成一個平方攻擊向量（50000 次的CALLDATACOPY，每次消耗50000 gas，則其計算量應是50000^2，但如果不使用動態收費規則，就只需付出~50000 gas）。》）

Gas 機制的另一個重要部分是gas 價格本身體現出的經濟學原理。比特幣中，默認的方法是採取純粹自願的收費方式，礦工扮演守門人的角色並且動態設置收費的最小值。以太坊中允許交易發送者設置任意數目的gas。這種方式在比特幣社區非常受歡迎，因為它是“市場經濟” 的體現：允許礦工和交易者之間依據供需關係來決定價格。然而，這種方式的問題是，交易處理並不遵循市場原則。儘管可以將交易處理看作是礦工向發送者提供的服務（這聽起來很直觀），但實際上礦工所處理的每個交易都必須由網絡中的每個節點處理，所以交易處理的大部分成本都由第三方機構承擔，而不是決定是否處理它的礦工。因此，“公地悲劇” 問題很有可能發生。

一級標題

一級標題

一級標題

虛擬機

• 以太坊虛擬機是執行交易代碼的引擎，也是以太坊與其他系統的核心區別。請注意，虛擬機應該同“合約與消息模型” 分開考慮。例如，SIGNEXTEND 操作碼是虛擬機的一個功能，但實際上“某個合約可以調用其他合約並指定子調用的gas 限定值” 是“合約與消息模型” 的一部分。

• EVM的設計目標如下：

• 簡單：操作碼盡可能的少並且低級；數據類型盡可能少；虛擬機的結構盡可能少；

• 結果明確：在VM 規範中，沒有任何可能產生歧義的空間，結果應該是完全確定的。此外，計算步驟應該是精確的，以便可以測量gas 的消耗量；

• 節約空間：EVM 組件應盡可能緊湊；

• 為預期用途而特化：在VM 上構建的應用應能處理20 字節的地址，以及32 位的自定義加密值，擁有用於自定義加密的模數運算、讀取區塊和交易數據與狀態交互等能力；

簡單安全：為了讓VM 不被利用，應該能夠容易地讓建立一套gas 消耗成本模型的操作；

• 優化友好：應該易於優化，以便即時編譯（JIT）和VM 的加速版本能夠構建出來。

• 同時EVM 也有如下特殊設計：

• 臨時/永久存儲的區別：我們先來看看什麼是臨時存儲和永久存儲。臨時存儲：存在於VM 的每個實例中，並在VM 執行結束後消失。永久存儲：存在於區塊鏈狀態層。假設執行下面的樹（S 代表永久存儲，M 代表臨時存儲）：

• A調用B；

• B 設置BS[0]=5，BM[0]=9 ；

  B 調用C；

• C 調用B。

• 此時，如果B試圖讀取BS[0] ，它將得到B前面存入的數據，也就是5；但如果B 試圖讀取BM[0] ，它將得到0，因為BM 是臨時存儲，讀取它的時候是虛擬機的一個新的實例。在一個內部調用（inner call）中，如果設置BM[0] = 13 和BS[0] = 17 ，然後內部調用和C 的調用都終止、回到了B 的外部調用（outer call），此時讀取M，將會看到BM[0] = 9 （此值是在上一次同一VM 執行實例中設置的）， BS[0] = 17 。如果B 的外部調用結束，然後A 再次調用B，將看到BM[0] = 0，BS[0] = 17 。這個區別的目的是：1.每個執行實例都分配有內存空間，不會因為循環調用而減損，這讓安全編程更加容易。 2.提供一個能夠快速操作的內存形式：因為需要修改樹，所以存儲更新必然很慢。

  棧/memory 模式：早期，計算狀態（除了指向下一個指令的程序計數器）有三種：棧（stack，一個32 字節標準的LIFO 棧），內存（memory，可無限延長的臨時字節數組），存儲項（storage，永久存儲）。在臨時存儲端，棧和內存的替代方案是memory-only 範式，或者是寄存器和內存的混合體（兩者區別不大，寄存器本質上也是一種內存）。在這種情況下，每個指令都有三個參數，例如： ADD R1 R2 R3: M[R1] = M[R2] + M[R3] 。選擇棧範式的原因很明顯，它使代碼縮小了4 倍。

  單詞大小32 字節：在大多數結構中，如比特幣，單詞大小是4 或8 字節。 4 或8 字節對存儲地址和加密計算來說局限性太大了。而不對大小作限制又很難建立相應安全的gas 模型。 32 字節是一個理想大小，因為它足夠存儲下許多密碼算法所需要的大數值以及地址，又不會因為太大而導致效率低下。

  我們有自己的虛擬機：我們的虛擬機使用java、Lisp 和Lua 等語言開發。我們認為開發一款專業的虛擬機是值得的，因為：1）我們的VM 規範比其他許多虛擬機簡單的多，因為其他虛擬機為複雜性付出的代價更小，也就是說它們更容易變得複雜；然而，在我們的方案中每額外增加一點複雜性，都會給集約化發展帶來障礙，並帶來潛在的安全缺陷，比如共識錯誤，這就讓我們的複雜性成本很高；2 ）我們的VM 更加專業化，如支持32 字節；3）我們不會有復雜的外部依賴，複雜的外部依賴會導致我們安裝失敗；4）完善的審查機制，可以具體到特殊的安全需求；即使使用外部VM，也無法節省太多工作量。

  使用了可變、可擴展的memory 大小：固定memory 的大小是不必要的限制，太小或太大都不合適。如果內存大小是固定的，每次訪問內存都需要檢查訪問是否超出邊界，顯然這樣的效率並不高。

  1024 調用深度限制：許多編程語言在內存還沒有溢出時，就因為調用深度太深而崩潰了。所以僅使用區塊gas 上限一種限制是不夠的。
  

無類型：只是為了簡潔。不過，DIV、SDIV、MOD、SMOD 會使用有符號（signed）或無符號的操作碼（事實證明，對於操作碼ADD 和MUL，有符號和無符號是對等的）；轉換成定點運算在所有情況下都很簡單，例如，在32 位長度下，a * b -> (a * b) / 2^32, a / b -> a * 2^32 / b ，+、- 和* 在整數下不變。

• ADDMOD,校對注：在原譯本中還有如下一段，但其對應段落在當前版本的原文中已經刪除了： 棧大小沒有限制：沒什麼特別理由！許多情況下，該設計不是絕對必要的；因為，gas 的開銷和區塊gas 上限總是會充當每種資源消耗的上限。

• 這個VM 中某些操作碼的功能和用意很容易理解，但也有一些不太好理解，以下是一些特殊的原因：

• MULMOD：大多數情況下， mulmod(a, b, c) = a * b % c ，但在橢圓曲線算法中，使用的是32 字節模數運算，直接執行a * b % c 實際上是在執行((a * b) % 2^256) % c ，會得到完全不同的結果。在32 字節的空間中執行32 字節數值的a * b % c 計算的共識非常困難且繁瑣。

• SIGNEXTEND：SIGNEXTEND操作碼的作用是為了方便從大的有符號整數到小的有符號整數的類型轉換。小的有符號整數是很有用的，因為未來的即時編譯虛擬機也許有能力檢測主要處理32 字節整數又長時間運行的代碼塊，小的有符號整數能加快處理。

• SHA3：在以太坊代碼中，SHA3 作為安全的、高強度的、不定長數據哈希映射方法，應用非常廣泛。通常，在使用存儲器時，需要使用Hash 函數來防止惡意衝突，在驗證默克爾樹和類似的以太坊數據結構時也需要使用到Hash 函數。重要的是，與SHA3 的相似的哈希函數，如SHA256、ECRECVOR、RIPEM160，不是以操作碼的形式包含在裡面，而是以偽合約的形式。這樣做的目的是將它們放在一個單獨的類別中，如果當我們以後提出適當的“原生插件” 系統時，可以添加更多這樣的合約，而不需要擴展操作碼。

• ORIGIN：ORIGIN 操作碼由交易的發送者提供，主要的作用是允許合約退回支付的gas。

• EXTCODESIZE,COINBASE:COINBASE 的主要作用是：1）允許子貨幣對網絡安全作出貢獻；2）使礦工能夠作為一個去中心化的經濟體，來設置基於子共識的應用，如Schellingcoin。

• PREVHASH：PREVHASH 可用作一個半安全的隨機來源。此外，允許合約求值（evalute）上一個區塊的默克爾樹狀態證明，而不需要高度複雜的“以太坊輕客戶端” 遞歸結構。

• EXTCODECOPY：主要的作用是讓合約依據模板檢查其他合約的代碼，甚至是在與其他合約交互前，模擬它們。見：https://lesswrong.com/lw/aq9/decision_theories_a_less_wrong_primer/

• JUMPDEST：當跳轉（jump）目的地限制在幾個索引時（尤其是，動態目的跳轉的計算複雜度是O(log(有效挑戰目的數量))，而靜態跳轉總是恆定的）， JIT 虛擬機實現起來更簡單。於是，我們需要：1）對有效變量跳轉目的地做限制；2）激勵使用靜態而不是動態跳轉。為了達到這兩個目標，我們定下了以下規則：1）緊接著push 後的跳轉可以跳到任何地方，而不僅是另一個jump；2）其他的jump 只能跳轉到JUMPDEST。對跳轉的限制是必須的，這樣就可通過查看代碼中的前一個操作來確定當前是一個靜態跳轉還是動態跳轉。缺乏對靜態跳轉的需求是激勵使用它們的原因。禁止跳轉進入push 數據也會加快JIT 虛擬機的編譯和執行。

• 原文鏈接:

• 原文鏈接:

（完）

原文鏈接:

https://eth.wiki/en/fundamentals/design-rationale

（完）

原文鏈接: