Geth v1.9.0 發布已一年半有餘。在這期間，我們確實發布過26 個版本（大約3 週一次），但是主要版本發布總是更特殊一些。我的心情很微妙：一方面，新功能上線令我興奮不已，另一方面，我又擔心會出現重大失誤。無論如何，以太坊正在發展，我們需要突破極限，跟上它的步伐。
言歸正傳，讓我們歡迎Geth v1.10.0 加入以太坊大家族。
風險提示
在詳細介紹最新版本之前，我們有必要強調一下：任何新功能的推出總伴隨著新的風險。為了滿足風險狀況不同的用戶和項目的需求，許多重要功能（暫時）可以單獨開啟或關閉。無論你想要閱讀這篇文章的所有內容，還是只閱讀你感興趣的部分，請不要略過文末的“兼容性” 一節。
接下來，就讓我們來看看Geth v1.10.0 究竟有哪些特性！
柏林硬分叉
首先要聲明一點。 Geth v1.10.0 尚不可用於柏林硬分叉，因為Solidity 團隊擔心EIP 2315 最後會出現變數。由於v1.10.0 是大版本，我們不想讓發佈時間太接近柏林分叉。我們很快就會發布v1.10.1，加入最終的EIP 及相關區塊編號的名單。
快照
我們一直在說快照加速（中文譯本），說了很久了，現在終於出現在新發布版本中，我們心中也五味雜陳。本文不會涉及太多細節（見上面的超鏈接），快照（snapshot）是基於以太坊狀態的加速數據結構，可大大加快讀取 賬戶和合約存儲項的速度。
具體來說，快照功能可以將訪問賬戶的成本從O(logN) 降低至O(1)。乍看之下，這可能不是很多，但是在實際情況下，假設主網上有1.4 億個賬戶，快照可以為每次賬戶讀取節省大約8 次數據庫查詢。這幾乎將磁盤查詢量減少了一個數量級，確保其成為與狀態大小無關的常量。
哇偶，這是不是說我們可以將gas limit 提高10 倍？很遺憾的是，不能。雖然快照確實能將讀取性能提高10 倍，但是EVM 執行還需要寫入 數據。數據寫入需要經過默克爾驗證。考慮到默克爾證明，磁盤寫入的成本必須是O(logN)。
既然如此，這又有什麼意義呢？ ！雖然加快賬戶和合約存儲的讀取速度並不足以提高gas limit，但它確實解決了一些棘手的問題：
DoS。在2016 年，以太坊遭受了有史以來最嚴重的DoS 攻擊（“上海” 攻擊），持續了大約2 至3 個月。這次攻擊通過以太坊狀態膨脹以及濫用各種gas 定價過低的操作碼來導致以太坊網絡癱瘓。經過無數次客戶端優化和硬分叉再定價之後，這次危機才得以平息。但是問題的根源依然存在：狀態訪問操作碼有著固定的EVM gas消耗量 O(1)，但是執行成本 O(logN) 是緩慢增加的。我們已經通過“橘子口哨”（Tangerine Whistle）、“伊斯坦布爾”（Istanbul）以及即將到來的“柏林”（Berlin）分叉狀態操作碼的gas 消耗量，讓EVM 成本（名義開銷）與運行時成本更加一致，但這些都只是權宜之計。快照可以將狀態讀取的執行成本降低至O(1)（使之與EVM 成本更加一致），從而長期解決基於狀態讀取的DoS 問題（請勿在他處引用這句話）。調用。檢查以太坊上智能合約的狀態需要一次微EVM 執行。一方面是運行字節碼，另一方面是從磁盤中讀取狀態插槽。如果你運行了一個只供自己使用的以太坊節點，當前的狀態訪問速度應該綽綽有餘。如果你運行一個供多名用戶使用的以太坊節點，快照所帶來的10 倍性能提升可以讓你以同樣的成本完成10 倍數量的查詢。同步。同步以太坊節點的方法主要有兩種。你可以下載區塊並執行區塊中的所有交易。或者，你可以下載區塊，驗證其PoW 證明，並下載與最新區塊相關的狀態。後者要快得多，但是需要通過其它節點獲取最新狀態的副本。在當前的Merkle-Patricia 狀態模型中，這些節點需要從磁盤上讀取 16TB 的數據，才能滿足節點同步需求。有了快照之後，這些節點只需從磁盤中讀取 96GB 的數據，就能讓新的節點加入網絡。欲知更多詳細信息，請閱讀快照同步 部分。
和其它功能一樣，快照也存在權衡取捨。雖然快照的諸多優點讓我們相信它值得推廣，但是需要付出一定的代價：
快照就是Merkle Patricia trie 的葉節點中已經包含的原始以太坊狀態的冗余副本。目前，快照在主網上額外需要大約 20 至25 GB 的磁盤成本。好在，快照有望讓我們進一步實現狀態存儲優化，並降低當前Merkle trie 的磁盤成本。由於目前還沒有人在網絡中構建快照，節點最初需要自行承擔迭代狀態trie 以及創建初始快照的開銷。根據你的節點的負載，這可能需要耗時一天至一周，但是（一切順利的話）每個節點在整個生命週期內只需完成一次。快照創建是在後台運行的，與其它節點操作同時執行。我們的計劃是，當全網節點都可獲得快照時，就不再要求節點迭代狀態trie 並創建初始快照。預知詳情，請閱讀快照同步 部分。
如果你對該快照功能有所顧慮，可以通過 --snapshot=false 在Geth 1.10.0 中禁用該功能，但是請注意，未來我們將強制啟用該功能，以保證網絡的基準健康度。
快照同步
如果你覺得我們的效率真差、一個快照功能做了這麼久，那是因為你還不了解快照同步！我們早在2017 年10 月就實現了一種新型同步算法的初始原型…… 那我們中間這三年干什麼去了？ ！在講述事情始末之前，我們先來了解一點歷史背景。
以太坊上線時，你可以選擇通過兩種不同的方式來同步網絡：完全同步 和快速同步（此處不考慮輕客戶端）。完全同步就是下載整條區塊鏈，並執行所有事務；快速同步需要信任較新的區塊，直接下載與之相關的狀態（然後就像完全同步一樣進行區塊執行）。雖然這兩種操作模式最終會產生相同的數據集，但是它們各自的權衡不同：
完全同步是信任最小化的，選擇執行從創世塊到鏈首塊之間的所有事務。雖然這可能是最安全的模式，但是以太坊主網目前有超過10.3 億筆事務，而且每天會新增125 萬筆。另外，這也意味著，完全同步的成本永遠都在增加。目前，一台性能優秀的計算機也需要8 到10 天才能處理完所有事務。快速同步選擇依靠PoW 的安全性。快速同步無需執行所有事務，而是認為如果某個區塊後面跟著64 個擁有有效PoW 的區塊，那麼對於作惡者來說，從這個區塊開始分叉的成本太高。因此，下載與HEAD-64相關的狀態不會有太大問題。快速同步信任較新區塊的狀態根，可以直接下載狀態trie。如此一來，該模式放低了對CPU 和磁盤IO 的需求，提高了對網絡帶寬和延遲的需求。具體來說，以太坊主網目前有大約6.75 億個狀態trie 節點。一台網絡連接良好的計算機需要8 至10 小時才能下載完成。
只要願意負擔高昂的成本，任何人都可以通過完全同步來驗證以太坊的完整歷史。但是，對於絕大多數人來說，快速同步就足夠了。這裡存在一個計算機科學悖論，即，一旦某個系統的使用量達到設計目標的50 倍，這個系統就會奔潰。此處的邏輯是，無論某個東西是如何運作的，只要給足壓力，就會出現意料之外的瓶頸。
在快速同步模式中，意料之外的瓶頸是由以太坊數據模型導致的 延遲。以太坊的狀態trie 是一個默克爾樹，其葉節點包含有用的數據，每個分支節點都是基於16 個子節點計算得到的哈希值。如果從默克爾樹的根節點開始同步（其哈希值包含在區塊頭內），下載所有數據的唯一方法就是逐個請求所有節點。有6.75 億個節點需要下載，即使每次都請求批量下載384 個節點的數據，最終也需要175 萬次往返。假設網絡中有10 個對等節點作為數據提供方，向這些節點請求數據的往返時間為50 毫秒，則快速同步需要等待 150 分鐘以上。但是，網絡延遲只是三個問題中的一個。
作為數據提供方的對等節點收到關於trie 節點的請求時，需要在磁盤中檢索它們。這裡，以太坊的Merkle trie 幫不上什麼忙。由於trie 節點是以哈希值作為鍵的，沒有什麼好的方法可以批量存儲/檢索這些trie 節點，需要逐個從數據庫中讀取。更糟糕的是，（Geth 使用的）LevelDB 將數據存儲在7 個層級（level）上，因此一次隨機讀取通常會觸及7 個文件。將這些數據全部相乘，一個批量下載384 個節點的網絡請求（每個請求需要7 次讀取）相當於2700 次磁盤讀取。速度最快的SATA SSD 能夠達到100.000 IOPS，也就是說，會額外增加37 毫秒的延遲。還是假設網絡中有10 個對等節點作為數據提供方，快速同步會額外增加108 分鐘的等待時間。但是，數據提供延遲是第二個問題。
請求那麼多trie 節點意味著，要上傳同樣多的哈希值給遠程節點。有6.75 億個節點要下載，就有6.75 億個哈希值要上傳，即，675 * 32 bytes = 21GB。假設全球範圍內的平均上傳速度是51Mbps（存疑）， 快速同步會額外增加56 分鐘的等待時間。平均下載速度是平均上傳速度的2 倍多，達到97 Mbps，快速同步會再額外增加63 分鐘。帶寬延遲是最後一個問題。
總之，快速同步模式下，僅等待數據就要花費6.3 小時之久，而且前提條件是：
你的網絡連接高於平均水平有足夠數量的對等節點提供數據你的對等節點只為你提供數據
快照同步旨在解決上述三個問題。核心思想非常簡單：快照同步並非逐個逐個下載trie節點，而是下載連續的狀態數據塊，並在本地重構Merkle trie：無需下載中間的Merkle trie 節點，即可批量獲取狀態數據，從而解決因網絡延時而導致的延遲問題。無需下載Merkle 節點，下行數據減少一半；無需單獨處理每單位數據，上行數據變得無關緊要，從而解決因帶寬而導致的延遲問題。無需請求按照隨機鍵值對排序的數據，對等節點僅執行幾次連續的磁盤讀取來作出響應，從而解決因磁盤IO 而導致的延遲問題（在對等節點已經以扁平的格式存儲數據的情況下）。
雖然我們的快照同步與Parity 的壓縮同步（Warp Sync）驚人地相似（也確實借鑒了後者的一些設計想法），但是相比後者有很大改進：
壓縮同步依賴於每3 萬個區塊創建的靜態快照。這意味著，作為數據提供方的節點需要每5 天左右重新生成快照，但是迭代整個狀態trie 實際上可能需要花費更多時間。也就是說，warp sync 不具備長期可持續性。快照同步則依賴於動態快照。無論多慢，動態快照只需生成一次，然後就會隨著區塊鏈的增長保持動態更新。壓縮同步的快照格式沒有採用Merkle trie 的結構，因此無法 單獨驗證每個壓縮數據塊。同步節點需要先下載整個20+ GB 數據集，才能對其進行驗證。因此，從理論上來說，壓縮同步模式對節點來說並不方便。相比之下，快照同步的快照格式是連續的默克爾樹葉節點，支持驗證任意大小的數據塊，因此可以立即發現不良數據。
現在，我們來對比一下快照同步和快速同步的具體數據。在區塊#11,177,000，通過3 個對等節點同步主網狀態（忽略區塊和收據，因為它們也一樣）得到的數據如下表所示：
時間上傳下載數據包磁盤讀取快速同步10 小時50 分鐘20.38GB43.8GB1607M15.68TB快照同步2 小時6 分鐘0.15GB20.44GB0.099M0.096TB-80.6%-99.26%-53.33%-99.993%-99.39%
請注意，Geth v1.10.0 已經上線快照同步功能，但是尚未啟用。原因是，快照同步要求節點必須創建快照加速結構，但是目前還沒有節點這麼做，因為快照加速結構功能也是Geth v1.10.0 推出的。你可以通過 --syncmode=snap 手動啟用快照同步，但是我們預期要等到柏林硬分叉過去幾週後才能找到合適的對等節點。等我們覺得有足夠多的對等節點採用快照同步功能時，我們將默認啟用該功能。
離線 “剪枝”（pruning）
過去幾年來，我們對Geth 取得的成就感到無比自豪。然而，任何人都會有羞於提及的短板。就Geth 而言，這塊短板就是狀態“剪枝” （state pruning）。那麼， “剪枝” 究竟是什麼意思？為什麼要這麼做？
處理一個新區塊時，節點會將網絡的當前狀態作為輸入數據，並根據區塊中的事務將其轉化成新的輸出數據。輸出狀態與輸入狀態幾乎相同，僅修改了幾千項。由於我們無法立即覆蓋舊的狀態（否則無法處理區塊重組），舊狀態和新狀態最終都會存儲在磁盤上。 （好吧，我們實際上比這裡說的要機靈點，只有遇上在接下來幾個區塊都不會刪除的新差異，我們才會將它們存儲在磁盤上，但是先讓我們暫且忽略這部分。）
如何逐個區塊將這些新的狀態數據發送至數據庫是一個問題。狀態數據會不斷累積。從理論上來說，我們可以“徑直刪除” 不存在重組風險的舊的狀態數據，但是結果證明，這是一個非常棘手的問題。因為以太坊中的狀態是以樹型數據結構存儲的（而且大多數區塊只會改變狀態的一小部分），所以這些（因網絡不斷出塊而形成的一棵又一棵）樹存儲的數據有很高的重合度。我們可以輕而易舉地判定舊的trie 的根節點是否穩定且可以刪除，但是要弄清楚舊狀態深處的某個節點是否依然被新的節點引用需要很高的成本。
多年來，我們已經實現了一系列“剪枝” 算法（記不清了，大概10 個吧）來刪除冗餘數據，但是這些解決方案全都因為數據量達到上限而失敗。因此，人們已經逐漸習慣Geth 的數據庫在快速同步之後本來很小，然後持續增長，直到你受不了並重新同步為止。這點確實很令人反感，因為重新下載只會浪費帶寬，並增加節點無意義的停機時間。
Geth v1.10.0 並不能徹底解決這一問題，但是它可以極大改善用戶體驗。如果你已啟用並完全生成快照，Geth 可以使用這些快照作為加速結構，較快決定哪些trie 節點應該保留，以及哪些trie 節點應該刪除。基於快照修剪trie 節點確實存在缺點，即，區塊鏈可能會在“剪枝” 期間停止增長。也就是說，你需要停止運行Geth，修剪其數據庫，然後重新啟動客戶端。
就執行時間而言， “剪枝” 需要幾個小時（這很大程度上取決於你的磁盤速度和垃圾累積量），其中三分之一的時間用來從快照中為較新的trie 節點生成索引，另外三分之一的時間用來刪除舊的trie 節點，最後三分之一的時間用來壓縮數據庫以釋放空間。完成修剪後，你的磁盤使用情況應該與完成一次新的同步後大致相同。如需對數據庫進行“剪枝” ，請運行geth snapshot prune-state。
請注意， “剪枝”是一個新功能，存在一定的風險。如果失敗，可能會導致不良數據塊。我們相信這個功能是可靠的，但是如果出現問題，就有可能對數據庫造成無法挽回的破壞。我們的建議是，（至少等到該功能經過充分測試後），在“剪枝” 之前先備份你的數據庫，在進入主網之前先嘗試測試網節點。
刪除事務索引
以太坊誕生已有6 年。在此期間，以太坊用戶已經發布超過10 億筆事務。這是很大的體量。
節點運營者想當然地認為，只要有了哈希值，就可以查詢過去任意一筆事務。說實說，這看似簡單，但是只要算一下，你就會知道有多繁雜。為便於搜索事務，我們（至少）需要將所有事務哈希映射到它們所在的區塊。即使我們通過一切權衡來盡可能減少存儲，我們也需要存儲區塊編號（4 字節/個）及其對應的哈希值（32 字節/個）。
每筆事務36 字節看似不多，但是乘以10 億筆事務之後得出的結果是，節點運營者需要存儲36 GB 的數據，才能說出事務0xdeadbeef位於區塊N。這是很龐大的數據量，而且需要查詢很多數據庫條目。如果你想查詢6 年前的事務，存儲36 GB 的數據並非難以接受。但是實際上，絕大多數用戶都不想。對於他們來說，額外的磁盤使用量和IO 開銷都是在浪費資源。請注意，事務索引並非共識的一部分，也非網絡協議的一部分。它們純粹是在本地創建的加速結構。
我們是否可以刪除節點存儲的一些無用數據？可以！ Geth v1.10.0 默認開啟刪除事務索引功能，並設置為235 萬個區塊（大約1 年）刪除一次。事務索引刪除機制將在後台運行，隨著新區塊不斷挖出，該機制將確保只有最近N個區塊內的事務能被索引到，之前區塊內的事務都會被刪除。如果有用戶想要訪問之前的事務，可以設置較高的
--txlookuplimit 值，並重啟Geth，然後原本不在查詢範圍內的事務將重新被索引（請注意，必須等到下一個區塊才會觸發）。
由於以太坊上大約1/3 的事務負載都發生在2020 年，這一整年的事務索引會在數據庫中佔據很大比重。刪除事務索引的目的並非打著節省存儲空間的旗號刪除現有功能，而是實現一種避免存儲空間隨區塊鏈歷史無限增長的運營模式。
如果你想要 禁用 刪除事務索引這一功能，可以在運行Geth 時設置--txlookuplimit=0。這樣一來，你的節點就會像之前那樣保留自創世塊以來每筆事務的映射，以便查詢。
原像丟棄
以太坊將所有數據都存儲在Merkle Patricia trie 中。葉節點中存儲的值都是原始數據（如，存儲插槽內容、賬戶內容），通往葉節點的路徑就是代表數據存儲位置的鍵。然而，這些鍵本身並非賬戶地址或存儲項地址，而是賬戶地址或存儲項地址的Keccak256哈希值。這有助於平衡狀態trie 的分支深度。使用哈希值作為鍵是可行的，因為以太坊用戶只會引用原地址，這些原地址可以隨時進行哈希計算。
然而，有一個用例是，有人在狀態trie 中存儲了一個哈希值，想要恢復其原像：調試。單步執行EVM 字節碼時，開發者可能想要查看智能合約中的所有變量。即使有了數據，在沒有原像的情況下，我們也很難將該數據與Solidity 變量對應起來。
最開始的時候，Geth 採取了一種不成熟的解決方案。我們將所有源自用戶調用（如，發送事務）而非EVM 調用（如，訪問插槽）的原像存儲在數據庫中。對於Remix 來說，這並不夠，因此我們擴展了我們的追踪API 調用，以便存儲所有SHA3（Keccak256）操作的原像。雖然該方案解決了Remix 的調試問題，但是非調試節點未使用的數據成了新的問題。
這些原像需要佔用的存儲空間並不大。如果你從創世塊開始進行完全同步（重新執行所有事務），你最終只需額外承擔5 GB 的負載量。但是，對於不需要使用這些數據的用戶來說，沒必要保留它們，否則只會增加LevelDB 壓縮的負擔。因此，Gethv1.10.0 默認禁用原像採集功能，但是沒有機制可以主動刪除已存儲的原像。
如果你正在使用你的Geth 實例調試事務，你可以通過 --cache.preimages 保留之前的設置。請注意，事後無法再生成原像。如果你在禁用原像採集功能的情況下運行Geth，卻又改變了主意，你需要重新導入區塊。
ETH/66 協議
eth/66協議是很小的改動，但是帶了很多好處。簡而言之，該協議為所有雙向數據包引入了請求與應答ID。這些ID 的目標是，降低響應與請求之間的配對難度，以便將響應傳遞給發出原始請求的子系統。
這些ID 不是必不可少的。實際上，在過去6 年中，沒有這些ID 我們也有其它變通的方法。可惜的是，如果多個子系統可以同時請求相同類型的數據（例如，同步區塊鏈的下載器、執行區塊公告的獲取器以及分叉挑戰都可以同時請求區塊頭），則所有需要向網絡發出請求的代碼都會變得過於復雜。此外，超時可能會導致延遲/意外交付或重新請求。在所有這些情況下，每當有區塊頭數據包到達時，每個子系統都會查看其數據，試圖弄清楚該數據是對自己還是其他人有用。非針對特定子系統的應答會導致其它地方出現故障，需要進行適當處理。綜上，這個方案雖然可行，但是會很麻煩。
就本文而言，eth/66協議的重要性並不在於它能解決某個特定問題，而在於它是在柏林分叉前引入的。由於所有節點都將在分叉時進行升級，這就意味著Geth 可以在分叉後開始棄用舊協議。只有等到所有舊協議棄用後，我們才能重寫Geth 的內部結構，以利用請求ID。按照我們的協議棄用計劃表，我們將很快棄用eth/64，並在今年夏末棄用eth65。
有些人可能會認為，這是Geth 在利用它的權重迫使其它客戶端執行協議更新。我們想要強調一點，柏林硬分叉引入的typed transaction 功能最初要求新的協議版本（譯者註：此處應指eth/66）。由於只有Geth 實現了完整的eth/xy協議，其它客戶端要求將該功能加入舊的協議版本（譯者註：此處應指eth/66 之前的此類協議，如eth/64），以免不得不將全部精力集中在聯網組件上。最終達成的協議是，Geth 將typed transaction 功能向後移植到之前協議的代碼中，為其他開發者爭取時間，但是作為交換條件，Geth 將在6 個月內淘汰舊版本，以免停滯不前。
ChainID 執行措施
回到2016 年，TheDAO 硬分叉發生之後，以太坊就引入了“鏈ID” 的概念。目的是讓用戶簽名的事務中帶上特殊標識符，來區分以太坊區塊鏈上的事務和以太坊經典區塊鏈上的事務（以及測試網上的事務）。使得一筆事務僅在一個網絡中被認定為有效，可以保證這些事務不會在當事人不知情時在另一個網絡上重複發生。
為了最小化這一轉變帶來的問題，新的/受（重放）保護的事務和舊的/不受保護的事務都被當成是有效的。 5 年以後的今天，以太坊區塊鏈上仍有約15% 的事務是沒有重放保護的。這並不意味著存在漏洞，除非你在不同的網絡上重用同一把私鑰。警告：千萬別這麼做 ！當然，也有意外發生，已知有一些基於以太坊協議的網絡因為重放問題而整體掉線。
因此，儘管我們不想當老大哥，我們還是決定嘗試推動用戶和工具都拋棄舊的、不受保護的簽名，並在一切地方都使用鏈ID。最簡單的辦法當然是在協議層讓缺乏重放保護的事務無效化，但這15% 的用戶就會陷入困境，並且病急亂投醫地去尋找修復程序。為了漸進地推動大家走向更安全的替代手段，而不是把桌子掀掉，Geth v1.10.0 在RPC 中會拒絕沒有重放保護的事務；但通過P2P 協議傳播的事務則保持現狀，不過，我們在未來也會逐漸推動拒絕措施。
如果你在使用由abigen 生成的代碼，我們已經在go-ethereum 代碼庫中加入了額外的簽名建構器，可以容易地創建鎖定了鏈ID 的事務。遺存的那個開箱即用的簽名器是在EIP155 實施之前編寫的，所以現在你要自己構築受保護的簽名。這很容易出錯，而且用戶會假設我們能在內部預測好鏈ID，所以我們決定引入直接的API。我們會在未來棄用並移除當前遺存的簽名器。
我們知道，仍在使用不帶重放保護簽名的用戶/工具不可能在一夜之間改變，所以Geth v1.10.0 支持回復到舊版本的行為，並通過--rpc.allow-unprotected-txs 來接收非EIP-155 的事務。請注意，這只是暫時的。最終我們會移除這個機制。
標籤棄用
在v1.9.x 家族發展的過程中，我們已經棄用了許多命令行標籤（CLI flag）。有一些是重新命名，以更恰當地遵循我們的命名規則；另一些則是因為一些功能已被丟棄（最著名的就是Whisper），所以遭到移除。在v1.9.x 的小更新中，我們都會保證舊的標籤仍然可用，只在使用舊標籤（而非推薦的新標籤）時打印警告信息。
Geth v1.10.0 終於找到機會可以完全移除舊命令行標籤了。如果你去年沒有更新到新版本的話，下面這個列表可以幫助修正自己所用的命令：
--rpc->--http，開啟HTTP-RPC 服務器--rpcaddr->--http.addr，HTTP-RPC 服務器監聽接口（listeninginterface）--rpcport->--http.port，HTTP-RPC 服務器監聽端口（listeningport）--rpccorsdomain->--http.corsdomain，接受請求的域--rpcvhosts->--http.vhosts，接受請求的虛擬主機名--rpcapi->--http.api，通過HTTP- RPC 接口提供的API--wsaddr->--ws.addr，WS-RPC 服務器監聽接口--wsport->--ws.port，WS-RPC 服務器監聽端口--wsorigins->--ws.origins，接受websockets 請求的Origins--wsapi->--ws.api，通過WS-RPC 接口提供的API--gpoblocks->--gpo.blocks，檢查相應區塊號區塊的gas price（Number of blocks to check for gas prices）--gpopercentile->--gpo.percentile，按近期事務的百分比提供gas 建議--graphql.addr->--graphql，在HTTP-RPC 服務器上開啟GraphQL--graphql.port-> --graphql，在HTTP-RPC 服務器上開啟GraphQL--pprofport->--pprof.port，分析器的HTTP 服務器監聽端口--pprofaddr->--pprof.addr，分析器的HTTP 服務器監聽接口-- memprofilerate->--pprof.memprofilerate，按給定比率開啟內存分析--blockprofilerate->--pprof.blockprofilerate，按給定比率開啟區塊分析--cpuprofile->--pprof.cpuprofile，向給定文件寫入CPU 分析
上面記錄的舊標籤中可能有一些在接下來幾個版本中仍然可用，但你不應該依賴它們。
因為大部分全節點都不會通過Geth 來使用USB 硬件錢包—— 而且在不同平台上，USB 的處理有點奇怪—— 許多節點運營者需要手動通過--nousb 來關閉USB 功能。為迎合大部分人的默認需求，Geth v1.10.0 會默認禁用USB 錢包支持，並取消--nousb 標籤。你仍然可以使用USB 錢包，只不過要手動使用--usb。
跟踪突然關閉
我們經常收到Geth 客戶端在啟動時候加載舊區塊時彈出bug 的報告。一般來說，這種現像是因為節點的運營者突然關閉Geth 客戶端（斷電、內存擠爆導致保護性關閉、關機超時時間過短，等等）。因為Geth 在內存中存儲著許多髒狀態（dirty state，即已被修改過的狀態），以避免向硬盤寫入幾個區塊後就會過時的狀態；突然關閉會導致這些數據來不及清洗（flushed ）。當啟動時發現丟失了近期的狀態，Geth 客戶端別無選擇，只能倒帶，回到它上一次完整完成了功能的區塊鏈點位上。
為了避免爭議節點運營者到底有沒有乾淨地關閉節點，也避免引入清洗功能（clean cycle）會掩蓋數據丟失的事實，Geth v1.10.0 會跟踪和報告節點宕機事件。我們希望這能幫助運營者在造成不可逆的數據丟失之前，先檢測到他們的錯誤配置或者問題所在。
WARN [03-03|06:36:38.734] Unclean shutdown detected booted=2021-02-03T06:47:28+0000 age=3w6d23h
兼容性
在臨近硬分叉時發布大更新，最起碼，算不上是最優策略吧。但是，每一次為Geth 客戶端軟件發布下一代的大更新，都比我們預計的時間多了兩個月。為了測試和緩解升級後軟件在生產環境中可能出現的問題，幾乎所有新功能都可以用命令行標籤來關閉。距我們計劃的硬分叉在主網激活的時間還剩下6 週，可以確保我們會擁有一個平滑的體驗。但不管怎麼說，我們想提前為所有可能出現的不便說一聲抱歉。
若想讓客戶端軟件回復成1.9.x版本對應的功能集合，可使用下列標籤：
--snapshot=false，禁用快照加速結構和快照同步功能--txlookuplimit=0，確保為主鏈上所有的交易建立索引（而不是僅為過去一年的交易建立索引）--cache.preimages，保持生成及保存賬戶的原象--rpc.allow-unprotected-txs，以允許非重放保護的簽名（non-replay-protected signatures）--usb，以重新啟用USB 錢包支持
注意，eth_protocolVersion API 調用已經刪除，因為沒有用處。如果你能充分說明為什麼需要這個功能，請聯繫我們。
結語
我們一向自豪於我們的大版本更新，這次也不例外。這次更新已經推遲了太久太久，但我們以穩定性為名，保證所有關鍵功能都盡我們所能做了測試。我們希望這個新版本號能打開一扇門，能為提高交易吞吐量、降低交易代價盡綿薄之力。
像往常一樣，我們軟件的：源代碼、git 標籤等，見GitHub 軟件版本發行頁適用於所有平台的、預構建的二進製文件，見下載頁Docker 鏡像，見ethereum/client-goUbuntu 安裝包，見Launchpad PPA repositoryOSX 安裝包，見Homebrew Tap repository
（完）
原文鏈接: https://blog.ethereum.org/2021/03/03/geth-v1-10-0/作者: Péter Szilágyi翻譯&校對: 閔敏& 阿劍
