乙太坊的設計理念詳解：探索乙太坊的發展歷程和設計理念！

叔塊（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 秒

7 代祖先以內的限制：這樣設計的目的是希望只保留少量區塊，而將更早之前的區塊清除。已經證明 7 代的可引用范圍就可以提供大部分所需的效果。

1 代后裔的限制：（例如，設 c = child 且 p = parent，則 c(c(p(p(p(head))))) 是無效的）：這也是出于簡潔性的設計目標，而且上述的模擬器顯示這不會帶來很大的中心化風險。（校對注：此句難解；一種可能的意思是：叔塊的后代不能作為叔塊，即只有主鏈的一代旁支能作為叔塊。）

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

獎金分配：7/8 的挖礦基礎獎勵分配給叔塊，1/32 分給侄塊，它們交易費用都是 0%。如果費用占多數，從中心化的角度看，這會使叔塊激勵機制無效；然而，這也是為什麼只要我們繼續使用 PoW，以太坊就會不斷發行以太幣的原因。

難度更新算法

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

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

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

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

簡單：算法的實現應相對簡單；

低內存：算法不應依賴于過多的歷史區塊，要盡可能少的使用 “內存變量”。假設有最新的十個區塊，將存儲在這十個區塊頭部的內存變量相加，這些區塊都可用于算法的計算；

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

我們當前的算法在低波動性和抗爆破性上并不理想。最近，我們計劃把時間戳參數改為與父區塊和祖父區塊比較，所以礦工只有在連續挖 2 個區塊時，才有動力去修改時間戳。另一個更強大的模擬公式： 

https://github.com/ethereum/economic-modeling/blob/master/diffadjust/blkdiff.py 

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 日），這一點還未改變，但它在未來有可能會改變。

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

如果交易不需要指定 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）。

如果值不是零，操作碼 CALL（以及 CALLCODE）會額外消耗 9000 gas。這是因為任何值傳輸都會引起歸檔節點的歷史存儲顯著增大。請注意，操作的 實際消耗 是 6700；但是此基礎上，我們強制增加了一個自動給予接收者的 gas 值，這個值最小 2300。這樣做是為了讓接受交易的錢包至少有足夠的 gas 來生成 log。

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

當前，因為缺乏礦工在實際中的行為的明確信息，所以我們將采取一個非常簡單公平的方法：投票系統，來設定單個區塊可消耗的 gas 總額。礦工有權將在最新區塊的 gas 上限基礎上變更 0.0975% (1/1024)，作為當前區塊的 gas 上限。所以最終的 gas 上限應該是礦工們設置的中間值。我們希望將來能夠采用軟分叉的方法來使用更加精確的算法。

虛擬機

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

EVM的設計目標如下：

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

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

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

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

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

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

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

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

A調用 B；

B 設置 B.S[0]=5，B.M[0]=9 ；

B 調用 C；

C 調用 B。

此時，如果B試圖讀取 B.S[0] ，它將得到B前面存入的數據，也就是 5；但如果 B 試圖讀取 B.M[0] ，它將得到 0，因為 B.M 是臨時存儲，讀取它的時候是虛擬機的一個新的實例。在一個內部調用（inner call）中，如果設置 B.M[0] = 13 和 B.S[0] = 17 ，然后內部調用和 C 的調用都終止、回到了 B 的外部調用（outer call），此時讀取 M，將會看到 B.M[0] = 9 （此值是在上一次同一 VM 執行實例中設置的）， B.S[0] = 17 。如果 B 的外部調用結束，然后 A 再次調用 B，將看到 B.M[0] = 0，B.S[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 ，+、- 和 * 在整數下不變。

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

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

ADDMOD, 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。

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

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

EXTCODESIZE, 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 虛擬機的編譯和執行。

LOG：LOG是事件的日志。

CALLCODE：該操作碼允許合約使用自己的存儲項，在單獨的棧空間和 memory 中調用其他合約的 “函數” 。這樣可以在區塊鏈上靈活實現標準庫代碼。

SELFDESTRUCT：允許合約刪除它自己，前提是它已經不需要存在了。SELFDESTRUCT 并非立即執行，而是在交易執行完之后執行。這是因為如果允許 SELFDESTRUCT 在執行之后回滾，將會極大地提高緩存的復雜度，不利于高效的 VM 實現。

PC：盡管理論上不需要 PC 操作碼，因為所有 PC 操作碼的實例都可以根據將 push 操作的索引加入實際程序計數器來代替實現，但使用 PC 可以創建獨立代碼的位置（可復制粘貼到其他合約的編譯函數，如果它們以不同索引結束，不會被打斷）。