以太坊:以太坊 Phase 2 進展（2019-12）_ETH

編者按：本文來自以太坊愛好者，作者：WillVillanueva，翻譯&校對:阿劍&曾汨，Odaily星球日報經授權轉載。以太坊2.0Phase2的工作在不斷推進。本文所講的是截至當前的最新進展。Phase2的大部分工作都是以太坊基金會的Ewasm團隊和Quilt團隊合作完成。本文不同部分所講的內容往往指向不同領域，交集甚少，因此，就請挑自己喜歡的部分閱讀吧。在閱讀本文之前，我非常推薦大家通過下列材料先了解一下Phase2以及執行環境提議的背景知識：通往Eth2Phase2以及Phase2測試網之路以太坊2.0Phase1&2開發者體驗EthHub深入解讀Ethereum2.0Phase2環游Eth2Phase2Ewasm2.0：Eth2.0中的狀態執行影響Phase2的協議層變更

VitalikButerin自今年4月以來已經寫出了不少提案以及準提案。在這些觀念上不斷迭代之后，當前的方向應該說非常確定了。最先提出以太坊2.0執行環境的初始提案已經在社區中探討多時了。Vitalik的2號提案精煉了1號提案以及Eth2作為無狀態協議的新理念。當前Phase2的設計沒有大幅偏離2號提案的思想。從歷史上來看，引入信標鏈負載均衡的概念之后，提案的一部分確實有所改變。這種負載均衡的思想提議將一條分片鏈理解為一個純粹的計算進程，那么EE就可以在預先指定的分片鏈上動態運行。本質上，這種理念是通過在信標鏈上定義的負載均衡合約，將計算負載平衡到不同的分片鏈上。值得強調的是，這一設計理念非常有趣，可以通過相互協作的中繼者實現多種不同模式的跨分片同步交易。它值得我們投入更多精力去研究，如果可靠的話，我們可以在未來把這一工具加到分片鏈上。最后，Vitalik在Devcon5期間公開了一份提案來簡化Phase0以及Phase1。這份提案沒有改變Phase2的根本方向，只是嘗試改善圍繞Phase2的開發者體驗。在Devcon5上，有不少朋友都投訴Eth2沒有跨分片的產品可組合性。在新提案下，跨分片通信可以在一個區塊內完成。而在以前的提案中，跨分片通信要等待交聯數據得到確認才能完成。結果就是，即使你的資金分散在不同的分片中，也可以很容易地把它們都匯集到一個分片中。該提議也恢復了ETH的神圣性，因為在這個“操作系統”中，分片、執行環境、驗證者賬戶、區塊生產者之間都可以自由傳輸ETH，只需一個區塊的時延即可完成。它也會生成一個更簡單的手續費市場，消除大家對舊的手續費市場提案的中心化擔憂。執行環境提案

Cyber Capital創始人：建議以太坊通過Roll-ups或執行分片回到Layer 1擴展:金色財經報道，Cyber Capital創始人Justin Bons在社交媒體上稱，以太坊正面臨著一個嚴重的困境，激勵機制的大規模錯位是造成深度腐敗的原因。在Layer 2向這個生態系統傾注資金的推動下，蓋過了Layer 1的資金。幾百萬和幾百億之間的差異是ETH放棄Layer 1擴容的原因，這是很自然的，我們應該期待任何系統性的規模。

問題是，在這種情況下，它導致ETH走錯了路，這就是為什么它是一個反常的激勵措施，開發者、影響者和領導者在短期內通過遵循Layer 2敘事賺取更多收入，雖然Layer 2通過支持限制Layer 1容量的敘述來賺取更多，但支持通過Layer 2專門擴展這在以太坊網絡的長期成功與Layer 2的短期利潤之間造成了明顯的利益沖突。

我建議以太坊通過Roll-ups或執行分片回到Layer 1擴展，我還應該提到ZKEVM，它仍然受到ETH開發者的關注，并且可以擴展到Layer 1。然而，它的發展太過遙遠，目前還不被認為是可行的。我們需要的是鏈上治理，將資金從區塊獎勵引導到去中心化的金庫。這將創建一個Layer 1傾向的資金來源，能夠與對立的利益競爭，這種方法已經被XTZ、DASH和DCR等老牌公鏈所檢驗。[2023/5/28 9:46:27]

我們已經在搭建執行環境的原型和早期實現上取得了重大進展。首先，我們需要驗證一種執行環境是否能在無狀態模式下運作。這種執行環境所要求的證明/見證的數據量會太大嗎？使用證據來執行狀態轉換的時間會太長嗎？為了回答這些問題，我們做了很多種執行環境、用它們來研究這些問題，不過，首先我們需要一個搭建原型的引擎：Scout。Scout

Scout是一款以太坊2.0Phase2執行過程原型搭建引擎，它開發了一個對EwasmAPI的封裝器，所以開發者可以用它搭建出執行環境的原型并開展基準測試。而且它還有assemblyscript和C++端口。與Eth1相關的諸EE

為了支持Eth1能切換到Eth2中，我們要把Eth1的狀態轉換規則做成Eth2中的一個執行環境。這一切換的主要挑戰在于，將Eth1轉換成無狀態模型，然后將EVM和交易/賬戶模式轉成一個執行環境。下面要談到的EE都是Eth1EE的前身。最近有一個工作組成立，專門圍繞Eth1EE大力開發。他們匯總出了一份初始工作計劃，并且很友善地在ethresearch論壇介紹自己。無狀態默克爾帕特里夏樹token主要資料：Github、SinaMahmoodi在Devcon5上的演講無狀態tokenEE的第一個原型旨在模仿Eth1.0的架構。它使用parity的代碼庫來實現Eth1狀態樹以及RLP編碼規則。它也納入了一個基本的中繼者實現，讓中繼者為一組交易生成多種證明。基準測試：70筆交易以及5000個賬戶/葉子節點用時：5秒證據大小：235kb執行執行和證據大小仍需要重大改進，但進展也從這些早期結果中展現了出來。其中一個問題涉及到將Parity的rust庫編譯成wasm代碼，結果出現了很多memcopy操作以及其它效率低下的操作。總的來說，把rust編譯到webassembly已經被證明會遇到很多困難。此外，簽名驗證一項用去了4秒。TurboToken主要資料：Turboproof概覽、TurboproofRustGithub、TurboTokenGithub、GuillaumeBallet的Devcon5演講、SinaMahmoodi的Devcon5演講TurboToken模型用到的turboproofs技術一開始是AlexeyAkhunov為實現Eth1無狀態輕客戶端所做的研究，它能夠高效地生成、合并及序列化Eth1數據樹的multiproof，也支持單次操作高效更新數據樹。CaseyDetrio和Sina用assemblyscript和rust語言開發出了一個初始的單分支原型，以驗證turboproof的效率是否夠高。在單分支原型上初步得出了令人滿意的結果后，Casey用assembly腳本實現了一個簡單、最基本可用的turboprooftokenEE。SinaMahmoodi復制了這一實現，然后將Guillaume的turboproof完整rust代碼庫和生成器移植到了typescript中。基準測試：70筆交易以及5000個賬戶/葉子節點用時：140毫秒證據大小：50kb執行時間和證據大小相比起SMPT原型都有了很大的提升。此外，在整個基準測試中，簽名驗證花去了105毫秒。來自CaseyDetrio的基準測試證明還可借助進一步的優化將簽名驗證的時間削減1/3。當然，5000遠遠小于Eth1數據樹上的實際賬戶數量，Sina正在拓寬基準測試，以測試turboproof在實際負載下的表現。EVM解釋器EE主要資料：Github、Devcon5演講我們需要在一個執行引擎中開發出一個EVM解釋器，好支持Eth1EE。Hugo做了一個原型，而且圍繞一個addandmul256合約做了測試。未來還需要引入更多合約和基準測試來改進這個原型。總結上述所有的實驗性工作都是為了做出Eth1執行環境的一種實現。我們已經開始制作構造原型了，但還是有很多性能問題需要審議。如上文所述，近期有一個工作組開始一門心思開發Eth1EE并打造Eth1無狀態模式。以Eth2為中心的諸EE

以太坊未確認交易為178,912筆:金色財經消息，據OKLink數據顯示，以太坊未確認交易178,912筆，當前全網算力為661.67TH/s，全網難度為8.86P，當前持幣地址為62,673,172個，同比增加115,186個，24h鏈上交易量為1,449,553ETH，當前平均出塊時間為13s。[2021/9/13 23:22:23]

這一部分要向大家介紹那些不完全是為實現Eth1->Eth2遷徙而開發的EE。Eth2要使用一種新的基于賬戶的執行環境，不同于Eth1的賬戶和交易模型，因為Eth1所用的交易、賬戶和累加器模型都不是最優的。此外，諸如optimisticrollups、ZKrollups之類的模型也要研究。Eth2EE的設計空間是完全開放的，而下列就是早期的想法和原型。CMerkleToken主要資料：Github、Devcon5PresentationPaulDworzanski對無狀態Merkletoken的C語言實現，他使用了二叉默克爾樹。數據樹的驗證和更新都用到了最優內存分布，而且安排了獨特的multiproof格式。該模型的驗證、更新數據樹操作都是一次完成的），而且很有可能可以用在Eth1的十六叉數據樹上。但是，尚不清楚數據樹更新算法能不能用在Eth1的數據樹上）。基準測試：證明中涉及到了222個賬戶中的40個用時：20毫秒證據大小：25kb當前，測試用到的這個實現已經是最高效率的了。基準測試中沒有包括驗簽的部分，但我們估計只需多花30毫秒即可。而且還有很多進一步優化的方案，比如通過緩存哈希和證據來減低運算時間和大小。適應性哈希長度方案也可以進一步降低證據的大小。最后，更好的哈希函數實現就能帶來更短的運算時間。ZKRollup主要資料：GeneralZKRollupOverview、Devcon5演講、EEstark驗證者示例、WASMproof驗證者、websnarksZKrollups是一種Layer-2擴展方案，因為不會用到復雜的退出挑戰機制和鎖定機制，所以能夠避免現有的Layer-2方案常見的用戶體驗問題。與這里列出的其它token轉移方案相比，ZKRollup大幅降級了對數據可用性的要求。這里列出的實現使用了websnark——一個用wasm實現的生成器，可用于snark驗證或其它配對函數。為了開發該EE，Jared改編websnark、開發了一個驗證Groth16證據的獨立wasm庫。這個EE還是個早期原型，還得繼續開發。ShardEther(Sheth)主要資料：Github、MattGarnett的Devcon5演講、InternalQuilt演講、SSZ概覽Sheth是Eth2合約EE的一個先驅。Sheth基于Eth2中用到的簡單序列化編碼規范，它用到了稀疏默克爾樹方案、借用turboproof的操作碼但使用了不同的形式來管理讀取、寫入和更新需求。DiederikLoerakker的設計思路是，通過存儲一個offset的列表來決定如何遍歷整棵數據樹。稀疏默克爾樹證明的長處在于，你可以在編譯時靜態地定義你正在引用的數據的總體索引。它也極大地簡化了更新狀態所需的邏輯，因為數據樹永不刪除或者插入節點；不過，為此也付出了一些犧牲。Sheth還包括了一個命令行客戶端，可以作為中繼者或者狀態提供者。基準測試：50個賬戶以及50筆交易證據大小：517kb當前的實現產生的證明大小實在是太大了，而且也比我們期望的要慢。證據可以通過移除補位的0或者消除0哈希值的數量而大幅減小；運算速度則可以通過引入host函數來管理256比特的操作還有必要的代碼優化來提升。DiederikLoerakker已經提交了一個issue，論述了如何提交這個設計的效率。總的來說，使用稀疏默克爾樹就會比較依賴哈希計算，而這個效果已經從初始的基準測試表現出來了。SimpleUmbrella—Eth2智能合約EE主要材料：EthResearch論壇中的提案、executecodehostfunctionPR該Eth2EE是一個無狀態的智能合約執行環境，運行合約的方式與Eth1執行環境相似，但合約是wasm形式的。此外，它未來有可能會轉用累加器，而不是使用eth1所用的十六叉默克爾樹。稀疏默克爾樹看起來不錯，不過也還需要進一步的基準測試來作出可靠的決策。MattGarnett匯總了一個Eth2EEspawnruntimes以及在子合約中分享調用者/被調用者數據的早期規范。因為近期的一些爭議，我們開發了一個host函數的原型，可用于在Eht2EE中spawn或者運行子合約。一個新的代碼庫已經開放，很快我們就能運行基本的智能合約了。Ewasm——解釋器、編譯器以及計算量度量

以太坊開發平臺Tenderly完成1530萬美元A輪融資:以太坊開發平臺Tenderly完成1530萬美元A輪融資，Accel領投，Point Nine Capital、Version One等參投，所籌資金將進一步用于開發產品并制定以太坊生態系統內的新開發標準。據悉，Tenderly此前完成330萬美元種子輪融資，Point Nine Capital領投，Version One等參投。Tenderly旨在建立新一代的以太坊開發者平臺，為開發者提供智能合約實時監控、合約部署測試環境等服務。（versionone）[2021/7/30 1:24:11]

這部分內容涵蓋了Ewasm團隊在過去幾年中的大量工作。在Devcon5期間，Ewasm團隊給出了一個清楚的、數據翔實的Ewasm相關工作現狀和進展說明。如果這部分內容勾起了你的興趣，我非常推薦你看看完整的視頻。下面我會給出一個簡單的總結。此外，Maksym也為Ewasm團隊在WasmintheBlockchain大會上的分享內容做了一份非常全面的概覽。編譯器

如果我們想讓Eth2能盡快發布，那么繼續編譯器路線可能會有更高的風險。其中一個困難或者說難以弄清楚的事項是管理JITbombs。單操作的編譯器也許也可以避免JITbombs，但現在大家都比較擔心當前的單操作編譯器實現的穩定性和安全性。在未來將編譯器作為Eth2的一部分也許不無道理，但如果我們想盡快啟動，解釋器可能是個更安全的選擇。解釋器

CaseyDetrio以及AlexBeregszaszi的Devcon5演講給出了對解釋器性能的非常全面的分析。更有意思的是，優化后的解釋器以及精心編寫的代碼被證明可以實現接近原生編譯器的性能。在一次測試中，Casey將一個wasm解釋器和用于256位數學操作的host函數相結合，評估了多種配對函數和哈希函數的性能。結果令人印象深刻，性能很接近原生且優化后的編譯器。在他的一系列基準測試中，他還發現最快的解釋器是wabt。計算量度量

PaulDworzanski在他的Devcon5演講中深入探討了這個領域。為了度量計算量，use_gas調用會在wasm合約部署及驗證之時注入wasm字節碼。注入及驗證的復雜性無疑會影響合約部署的費用。當前的基準測試顯示，注入計算量度量組件后，wasm代碼運行的速度會變慢1.04～2.4倍。對注入流程及注冊器assembly的更優模式基準測試將指明進一步優化的方向。在Lighthouse客戶端或者Phase2模擬中的Phase1和2原型

以太坊二層擴容方案StarkEx 3.0主網上線 包含L1 Vaults和SHARP功能:以太坊二層擴容方案StarkEx 3.0主網正式上線，包含L1 Vaults和SHARP兩大新功能。通過L1 Vaults，StarkEx用戶可與以太坊地址特別是智能合約地址進行資產交互， L1 Vaults允許通過智能合約將資金存入任何以太坊地址、發布限價單交易并提取資金；SHARP（SHARed Prover）則從數個StarkEx驅動的應用中收集交易，然后將它們打包成一個證明，從而提高了每筆交易的Gas使用率并實現了更快的交易確認速度。[2021/7/28 1:20:00]

我們希望模擬Phase1和2的客戶端最終是如何構建的，以及如何支持開發實現的團隊。我們也希望使用這些工作來模擬及測試EE在實際環境中跨多個分片運行時的情形。在Devcon5期間，我做了一場關于我們所構建的模擬程序的演講。我們在Lighthouse客戶端中開發/加入了一個非常簡單的Phase1原型并在該客戶端中加入了phase2Ewasmruntime。我們與Sheth交互，而且能夠在Lighthouse中模擬基本的EE或者代幣轉移。因為Lighthouse客戶端還在踴躍開發中，我們意識到維護Lighthouse客戶端的一個分支并在上面開發很可能會比我們一開始設想的要難。所以，我們決定吸取初始原型的養分，在Scout里面開發一個抽象的存根版本。我們將繼續模擬信標鏈和分片鏈的運行，不過我們可以大幅簡化其中的邏輯，因為我們的重心在執行環境的研究以及跨分片基準測試上。這部分工作正由Quilt團隊的兩位新成員管理著。中繼者、狀態提供者以及手續費市場

JohnAdler針對這一主題寫了一份非常全面的概覽。他的文章也講述了Eth2提案的有趣演化歷程。總結一下，Vitalik最新的分片簡化提案消除了一開始我們在中繼者模型中遇到的許多問題。不過，關于狀態提供者如何向區塊生產者發送交易，以及區塊生產者如何將交易包合并到一個合適的multiproof中，仍有不少問題懸而未決。其中一種建議是部署一個帶有證明合并腳本的新執行環境。接下來，圍繞著狀態提供者的激勵機制也要確定下來。Zsolt在第一次輕客戶端小分隊視頻會議中分享了他對激勵機制的研究。Eth1EE工作組也正在評估一個狀態提供者網絡，他們拿BeamSync上先前的工作作為模型。最終，中繼者或者狀態提供者將繼承web3.js或者ethers.js所連接的RPC端點。為這些跨多個EE的操作提出一系列標準是至關重要的。跨分片交易

行情 | 以太坊網絡持續擁堵:根據公開數據顯示，目前以太坊的網絡平均未確認交易筆數為68904筆，近日以太坊網絡擁堵持續，情況較為嚴重。[2018/7/25]

異步跨分片交易

Vitalik的最新Phase0&1提案對于跨分片交易和可組合性來說都是好消息。在新提案中，一次跨分片調用只需1個時隙的時延就能完成，而在過去的提案中，一次調用要等待12~18分鐘的時延才能確定下來。因此，在分片間轉移你的狀態會變得很快。此前，我們想用optimisticroots來加快調用速度，但發現這些方案都非常復雜。從一個dApp開發者的角度來看，跨分片調用只需遵循多線程編程中的異步范式和方法。在編寫智能合約時，HLL和DSL需要提供必要的工具將跨分片行為抽象成異步范式。整個模式很有可能就像下面這樣：簡單的異步調用消息驅動型方法兩階段確認鎖——讀/寫如何在EE或者在合約的底層中支持這些模式還需要進一步的研究。上文提到的模擬應該能為我們對這些模型的實驗提供基礎，不過，我們真的要說，這是一個重要的研究領域，如果人們愿意參與進來，我們會非常高興。像在此貼中描述的那樣，在更底層規定進程前和進程后的行為分別，可能會為在合約內暫停執行及后續繼續執行提供一個合理的框架。同步跨分片交易

之前，Vitalik發表了一篇論述狀態方案的帖子。這些方案實質就是鏈上Layer-2模式，而分片僅作為數據可用性層。這些模型其實都是現在所謂的optimisticrollups的前身。將多分片用作一個optimisticrollup方案的數據可用性層使同步跨分片交易成為可能。我們可能在不遠的將來根據這個概念開發出一款原型。此外，如果信標鏈引入負載均衡機制，我們可以通過相互合作的中繼市場實現同步跨分片交易。請看上文“影響Phase2的協議層變更”部分了解更多細節。我們真的需要跨分片調用嗎？

另一種值得進一步研究的觀點是，Eth2的主體應該要向狀態通道、optimisticrollups以及zkrollups傾斜。在這種思路下，Eth2本身就是一個數據可用性層，而跨分片調用只有在橋接這些方案或者在退出挑戰/錯誤性證明過程中才會用到。Rollups仍要在Eth1或者Eth2執行環境的邊界內定義好，不過，只有需要提交錯誤性證明的時候，才需要在鏈上執行計算。Phase2工具鏈

為推進我們的研究，我們提議了一套開發者需要用到的工具鏈。正如上文“Lighthouse中的Phase1和Phase2原型”章節中說的那樣，我們正在積極開發一套模擬來測試及運行跨分片的執行環境。不過，為使智能合約運行模式最優化，我們還得添加很多編排工具。這個帖子對這些工具做了更深入的說明。Phase1&2模擬類似于Truffle這樣的測試工具，用于在一個EE中運行wasm合約插入Phase1客戶端的運行時環境可靠的muilti-proof后端中繼者、狀態提供者工具，用于與web3.js交互Vitalik對Phase2的其他貢獻

Vitalik最近還在其它帖子中討論了與Phase2相關的主題，但我在上文中沒有直接引用，特此指出：Eth1->Eth2遷移實現跨分片交易通過加入儲存價值的EE來消除執行環境風險形式化并提升Eth2應對無效分片區塊確定性的方法在信標鏈上保存的合約跨分片DeFi可組合性行動起來！

如果你有興趣幫助我們，請聯系我們并參與進來。請加入這個telegram頻道來獲取新知或提問。我們已經有了進步，但仍有很多工作做。最后，我們將開始每月一次的視頻會議。第一次會議計劃在美國東部時間的12月3號，周二，上午10點舉行。結論

在Phase2上我們已經取得了很多進展，但毫無疑問需要做更多工作。這些早期的數據顯出前景不錯，而近期的大力投入也是非常有用的。我們需要圍繞跨分片搭建原型并加以測試，我們也要開始構思如何在Eth2EE里面開發合約。無狀態系統的累加器方案需要更多關注，因為它將讓當前的EE原型性能更高、更適應生產環境。我們還需要為EE開發打造更好的工具。最后，不能漏掉，我們還需要中繼者、狀態提供者的經濟激勵機制。感謝DannyRyan和JosephC。

Tags：ETHPHAETH2以太坊bodhiethereumPhantasiaCRETH2價格以太坊最新價格行情美元

USDT