以太坊正在為下一次硬分叉做準備·以太坊核心開發者第32次例會

以太坊正在為下一次硬分叉做準備。今天的以太坊核心開發者例會上，除了例行的對測試和客戶端的升級，他們還討論了推遲包含在 Constantinople中的 EIP（以太坊提升提議）。

以太坊核心開發者例會 #32 [01/26/18]

視頻

• 新的關於 PayGas 的以太坊提升提議將由 Vitalik 撰寫，以取代 EIP 86

• 在下一次核心開發者例會之前，EIP 96 需要更多的合作以獲得更規範的以太坊提升提議

• EIP 145 基本上是最終版了，它將從下一次硬分叉開始運行。

• EIP 169/170 將在下一次例會進行更充分的討論

• 在今後幾個星期，Parity 客戶端將支持運行 Casper 測試網路

• Harmony 客戶端已經運行了 Casper 支持

• Casper 測試網路正在調試這些客戶端

• Casper 測試網路獲得了「完全的成功」。圍繞防火牆有一些運行上的問題

• 在時間表以及哪些 EIP 將會包括在 Constantinople 上，將會有更多細節在下一次例會中確認

• 一個分片的最小完全特別版已經在 PyEVM 上運行

• 部署分片的第二階段和第四階段將會在一個月或之後完成

  測試

  Yoichi - 。關於用戶體驗的問題已經報告上去了。Tim 說 Yoichi 可以跟他要求任何關於用戶體驗的幫助。

• Swende - 關於 Hive 測試，一些重構已經完成了。希望能儘快重新啟動。

• Dimity - 在一個測試最優化過程中，他指出一部分測試已經在一次又一次分叉之後重複地測試，這是浪費時間；更好的方法是它應該被移除以最優化測試時間。客戶端也許不需要運行每一個變動，因為它只是從測試中移除一些已發送的數據。他計劃給所有這些指定特殊部分的分叉創建一個測試，因此當有人要創建一個測試的時候，它將指明這一測試將被運行在哪一次分叉上。

  分叉發布管理

  關於下一次硬分叉 Constantinople，哪些 EIP 會被考慮包含到其中？

  • EIP 86(記錄摘要 - 分片)( Vitalik ) - 會有一個新的操作碼叫做 Pay Gas。它有兩個功能：

  （1）支付 Gas。在功能上它將有一個 buit 以在交易結束後返還任何沒有被使用的 Gas 。

  （2）如果一筆交易在 PayGas 功能被調用之前被凍結了，該交易將會是無效的。但如果交易執行在 PayGas 操作碼已經被調用之後凍結了，那麼該交易是有效的。這樣做的目的是判定在 PayGas 操作碼之前的所有執行是否應該被考慮為基本驗證的一部分。所以，它將包括比如 nonce 這樣的東西；在一些情況下，它可能包含更多東西。如果在 PayGas 操作碼之後出現了任何東西，則都是完整執行的一部分，它所具有的礦工普遍工作的方式是每一個礦工都將有一些 Gas 門檻，也許是 100,000 Gas 或者別的。在任何時候，他們將保留一筆交易；他們將運行交易執行以用盡 Gas 數量。如果 PayGas 操作碼已經被調用了，該交易就不會被包括進來；但如果它沒有，它將是交易的終結。所以，這基本上是對預驗證（pre-verification）和錯誤交易執行的替代。

  另一個討論是關於使用協議內 nonce 的。在分片討論的環境里，團隊傾向於不使用它；但在另一種環境下，它會有更高的交易費用因為它將使交易在區塊鏈中出現不止一次。所以，在主鏈上，它也許會起作用，但它可以有一個獨立的協議驗證機制。

  好處：

  （a）抽象簽名 - 你可以使用任何你想要的簽名演算法。

  （b）重放保護抽象

  （c）它讓預驗證變得更加複雜

  可能的用例可以是眾籌。比如說，有一個 100,000 人想參與的眾籌，但其容量是前 20,000 人之後無人可以再加入。眾籌關閉的狀態將是所有 100,000 個交易都將發出但後面的 80,000 個會成為沒有操作碼的，也無需支付 Gas 費用。

  結論：關於 PayGas 的新的 EIP 將由 Vitalik 撰寫，以取代 EIP 86。

  • EIP 96 - 一開始，在將這一 EIP 包括進 Coinstantinople 上，Vitalik 沒有任何明確的意見。他認為，他對於現在的 Casper 來說是較不重要的。然而，Pawel 分享了他的想法：將一些功能從內部的 EVM（以太坊虛擬機）移到外部的合約，比如某些類型的預編譯（pre-complied）合約，是更正確的做法。它會讓遷移合約變得容易很多。Vitalik 後來同意將它包括進接下來的硬分叉。EWASM 團隊有同樣的感覺，Axic 添加。

  Piper - 我們正在準備在 PyEVM 中應用交易的概念。它正從分片部分迅速轉移到主鏈上。

  結論： EIP 96 將需要更多一點合作以獲得更正式的以太坊提升提議，直到下一次核心開發者例會。

  • EIP 145（在 EVM 中引入移位操作(Bitwise Shifting)） - Pawel 提醒道：EIP 已經準備好接受同行審議了。它也已經完成了 CPP 上的實現，但他們需要一些方式配置客戶端以包含這些性能。所以，它也可以運行在一些假的 Constantinople 分叉上，也可以在獨立的配置上運行。這是調試開始前我們列表上唯一的事項。歡迎更多的客戶端實現。Solidity 同樣支持它，由 Axic 添加。

  Karalabe 要求為 EIP 擴大測試案例，已覆蓋通用的用例，然後一個實現者便可檢查它看起來是否起作用了。

  結論：EIP 145 基本上是最終版了，並將進入硬分叉。

  • EIP 169/170（賬戶清零）- Vitalik 解釋，其中一人說如果賬戶的餘額下降到低於交易 Gas 價格的21000分之一，賬戶會消失。而其他人說，當你創建一個新帳戶的時候，初始的 nonce 必須是別的而不是0。

  結論：EIP 169/170需要在下一次例會中更充分的討論。

  Hudson - EIP 的時間安排對決定、實行和測試來說是很重要的；它有助於節省多少時間。

  客戶端升級

  Geth- Karalabe - Geth 最近的一個問題是，在你同步的哦時候，你使用了快速同步，使用了一些硬碟空間；在之後，它表現得像是一個全節點。從這一點繼續往前推，你的節點也像一個 Archive 一樣，最終，你的設備就變慢了。他們目前正在進行一個內存中的狀態裁剪，因此他們嘗試將垃圾只保存在內存里，然後在內存中清理它們，並且只是周期性地、或是在垃圾佔據硬碟達到相當數量才清理硬碟，也可能在別的時候。他們已經開始在主網上進行基準測試，這將減少80%的硬碟擴張。

Geth v1.8.0將不會為 GoEthereum 提速，但它將在實際上防止它變慢。有了這一點，用戶就不需要頻繁地重新同步，只需要 1/5 的時間。他們同樣已經為實現完整的垃圾收集做了獨立的 pull request（譯者註：GitHub 上的一種代碼改進行為） 或是概念證明（POC）實驗。接下來的工作是190，他希望擁有完整的垃圾收集實現。

團隊會等待完整的發布。

• Parity- Afri - Parity 1.9 發布了。這是迄今最快的客戶端。下周的重點是輕節點開發。他們同樣將開始實現 Casper 測試網路報告。

• Harmony- Mkalinin - 我們已經實現了 Casper Ware 節點最純粹的版本。這一節點可以與其他客戶端在混合共識網路中同步。

• CPP Ethereum- Pawel - 我們已經結合了 EWASM，所以，可以為虛擬機智能合約運行 EWASM 了。

• Ethereum JS- Casey - Ethereum JS 沒有重要的升級，只是保持維護。

• PyEVM- Piper - 重新命名，並將 PyEthereum 客戶端命名為Trinity。從命令行交互界面的共識實現開始，盡他們所能地快速工作。正在開發分片，其他的融合也在繼續。

• TurboGeth- Alexey - 在它很有希望穩定下來之後，開發著最後的最優版本。同步更快了，而他們正在嘗試檢驗它是否能像一個客戶端那樣工作。

  研究進展

  Casper 和 分片- Vitalik - Casper FFG - Casper FFG 的測試版已經運行幾個星期了。它運行得不是太好，因為它一直在重新連接，並且，對另一個節點來說，也沒有好到可以完全獨立維護。所以最終，在一些防火牆上，它需要主動的維護。他們已經準備好幫助 Casper 測試網上的其它客戶端。在這裡可以跟蹤分片進展的狀態。

  分片 - 許多工作已經起步。我們準備在 PyEVM 上實現分片。我們正在為 THIG 的一些改變做開發，比如賬戶通道，寫入 PyEVM 的賬戶抽象。話了很多時間開發一棵新的二進位樹。實際上，下一步是獲得無狀態客戶端的邏輯。正在嘗試讓全節點功能在測試網路上工作。

  黃皮書

  黃皮書已經被置於自由創造共享文化協議（Creative Commons Free Culture License） CC-BY-SA 之下。它最近由 Nick Savers 加以維護，並獲得了來自世界各地的許多人的貢獻。

  PS. 這篇文檔在 2018年1月27日 更新。

  科普 ERC 和 EIP 代表什麼呢? :

  http://ethfans.org/posts/what-do-erc-and-eip-stand-for

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！