聽V神講述,那些以太坊沒有走的路

摘要:本篇文章中V神介紹了一些分叉功能,其中很多都在核心開發者的圈子當中認真討論過。

原文標題:《The roads not taken》

原文作者:Vitalik Buterin

原文來源:Vitalik Buterin 官網

原文編譯:Kxp,律動BlockBeats

Ethereum 協議開發社區在Ethereum 的早期階段做出了很多決定,對項目的發展軌跡產生了重大影響。在有些情況下,Ethereum 開發者做出了理智的決定,解決了Bitcoin 遇到的一些問題。而在其它一些情況中,我們也在創造全新的東西,利用諸多選擇填補過往的空白。還有些時候,我們需要在復雜與簡易之間做出權衡,因為二者分別適用於不同的情景。

本篇文章我將介紹一些分叉功能,其中很多都在核心開發者的圈子當中認真討論過;但剩下沒有討論的功能此時此刻也應該被提上日程。同時,我們也期待看到一個不同的Ethereum,並從中學到新的東西。

我們是否應該採用一個簡易版的權益證明

Ethereum 很快將合併到的 Gasper 權益證明系統雖然複雜,但卻功能強大,具有以下特性:

強大的單區塊確認——一旦交易被納入區塊,通常在幾秒鐘內,該區塊就會被固化。除非有很大一部分節點誠信度低,或者存在極端的網絡延遲,否則它無法被逆轉。

經濟確定性——一旦區塊最終確定下來,在攻擊者沒有損失數百萬ETH 的情況下,它也不可逆轉。

可預測性高的回報——驗證者在每個週期(6.4 分鐘)都能獲得可靠獎勵,減少了對資金池的激勵。

支持較多數量驗證者——與其他大多數具有上述特性的鏈不同,Ethereum 信標鏈支持數十萬的驗證者(例如,Tendermint 提供比Ethereum 更快的確定性,但它只支持數百個驗證者)。

但製作一個具有這些特性的系統相當困難,需要進行多年的研究,經歷無數次的失敗,並花費大量的精力,而且最終結果也會非常複雜。

如果我們的研究人員不需要太考慮共識,並且有足夠多的精力的話,那麼也許rollup 在2016 年就已經被發明出來了。這就讓我們不禁反思:我們的權益證明真的應該有這麼高的標準嗎,因為即使是一個簡單弱化版本的權益證明就會比我們目前的工作證明要好得多。

很多人都存在一個誤解,認為權益證明本身就相當複雜,但實際上有很多權益證明算法幾乎和Nakamoto PoW 一樣簡單。 NXT 的權益證明在2013 年就出現了,是一個天然的候選方案;雖然它也有問題,但這些問題很容易被修補,而且我們本可以從2017 年,甚至從一開始就有一個運作良好的權益證明。 Gasper 之所以比這些算法更複雜,只是因為它嘗試完成的任務比它們多得多。但是,如果我們在一開始就加以謹慎,我們本可以先集中精力實現一些更可能完成的目標。

在我看來,從一開始就採用權益證明並不是一個正確的做法;PoW 有助於擴大最初的發行分佈,改善Ethereum 的可訪問性,並促進業餘愛好者社區的發展。但在2017 年,甚至2020 年,改用更簡單的權益證明卻可以更好的保護環境(以及因環境破壞而產生的反Crypto 思潮),同時也能讓研究人員更好地專注於擴展問題。我們最終還是需要耗費大量資源來製作一個更好的權益證明,從目前情況來看這會是一個必然結果。

分片的去複雜化

自2014 年開始研究Ethereum 分片以來,我們一直在著手解決去複雜化的問題。之前的複雜分片具有內置執行和跨分片交易功能,而之後我們簡化了協議,將更多的責任轉移到用戶身上(例如,在跨分片交易中,用戶必須在兩個分片上分別支付Gas 費)。然後,我們轉向了以rollup 為中心的路線圖,從協議的角度來看,分片只是數據的集合體。最後,通過danksharding,我們可以將分片收費市場合二為一。這樣一來,最終設計雖然看起來像是一個非分片鏈,但其背後進行的數據可用性採樣卻能使分片驗證成為現實。

但如果我們選擇了一條與之相反的路徑呢?實際上Ethereum 的研究人員曾花大量時間探索了一個更複雜的分片系統:分片將成為鏈,在分叉選擇規則中子鏈依賴於主鏈,跨分片消息會被協議路由,驗證者會在分片之間輪換,甚至應用程序也會在分片之間自動完成負載平衡。

這種方法的問題在於:這類形式的分片基本還只是一些想法和數學模型,而Danksharding 則是一個完整且可供實施的規範。因此,鑑於Ethereum 的種種限制因素,在我看來,分片的簡化和去歧義化絕對是正確之舉。儘管如此,我們還是應該投入更多精力開展研究,因為它可以幫我們確定有前景的研究方向。一般來說,即使是非常複雜的想法也其簡易的版本,且依然能為我們帶來很多幫助,同時還很有可能在未來幾年內左右Ethereum 的協議發展方向(甚至是Layer2 協議)。

我們應增加還是減少EVM 中的功能

除了安全審計功能之外,EVM 的規範在2014 年中之前就可以推出。不過,在之後的幾個月裡,我們一直在積極探索對去中心化應用區塊鏈有用的新功能,具體如下:

1. 我們之前想增加一個POST 操作碼,但後來還是決定放棄了。 POST 操作碼會進行異步調用,而該調用在交易完成後才會執行。

2. 我們之前還想添加一個ALARM 操作碼,但後來也放棄了。 ALARM 的功能類似於POST,只是它能在在未來的某個區塊中執行異步調用,讓合約能提前規劃操作。

3. 我們添加了日誌,它可以讓合約輸出不涉及狀態,但可以被DApp 接口和錢包讀取的記錄。不過,我們也考慮過讓ETH 轉賬發出日誌,但還是放棄了,因為我們覺得「反正人們很快就會轉到智能合約錢包」。

4. 我們考慮過擴大SSTORE 以支持字節數組,但後來由於擔心其複雜性過高和安全性不足而選擇了放棄。

5. 我們增加了預編譯合約,它們可以用比EVM 更低的Gas 費,用原生方式執行特定的Crypto 操作。

6. 在發布後的幾個月裡,我們反复考慮了狀態租用問題,但囿於它的複雜程度我們並未把它包括在內。如今,人們正在積極探索更好的狀態過期方案,儘管無狀態驗證和提議者/構建者分離比它重要的多。

今天來看,我們基本上都做出了正確的決定,我們也確實不需要增加POST 操作碼,也很難保證ALARM 操作碼的安全性(如果每個人在1 到99999 個區塊中都設置了一個ALARM,那麼在第100000 個區塊中執行大量代碼,會發生什麼?那個區塊會不會花幾個小時來處理這些代碼?一些預定的操作會被推到後面的區塊嗎?如果這種情況發生了,那麼ALARM 還能保留什麼安全保證呢?)字節數組SSTORE 的安全性也很難實現,而且會擴大最壞情況下的見證規模。

狀態租用問題更具挑戰性:如果我們從第一天起就真正實現了某種狀態租用,那麼我們就會有任何能夠圍繞持續狀態的規範化假設進行演化的智能合約生態系統。 Ethereum 會變得更難構建,雖然它可能會更具擴展性和可持續性。同時,我們當時的狀態過期計劃確實比我們現在的要差得多。有時候,好的想法就是要花上幾年的時間才能達成,並無捷徑可言。

LOG 的替代路徑

LOG 可以用兩種不同的方式來完成:

1. 我們可以讓ETH 轉賬自動發出一個LOG。這將為交易所和許多其他用戶節省大量的時間,並減少和軟件錯誤的發生。人們將更加依賴LOG,同時智能合約錢包也會得到更大規模的使用。

2. 我們完全可以不用LOG 操作碼,而把它變成一個ERC:會有一個配置submitLog 函數的標準合約,它可以使用Ethereum 存款合約技術來計算該區塊中所有日誌的Merkle 根。無論是EIP-2929 還是區塊上的存儲(相當於TSTORE,但在之後會被清空)都將降低它的成本。

我們曾認真考慮過第一種方式,但最後還是沒有採用,主要原因還是它的簡易性不足:使用LOG 操作碼直接生成日誌會更為便捷。我們還做了錯誤的估計,認為大多數用戶會迅速遷移到智能合約錢包,並使用操作碼來記錄轉賬。

我們之前沒有好好考慮過第二種方法,但現在回想起來,它其實也很不錯。它的主要缺點在於,它缺乏一個快速掃描日誌的Bloom 過濾器機制。但事實證明,Bloom 過濾器機制速度太慢,對DApp 並不友好,所以現在越來越多的人開始使用 TheGraph 來進行查詢。

總的來說,採用任何一個方法都會使情況變得更好。將LOG 保留在協議之外會使事情變得更簡單,但如果它在協議之內,它自動記錄所有ETH 轉移的功能也非常實用。

時至今日,我會贊成取消EVM 中的LOG 操作碼。

如果EVM 完全與眾不同呢

EVM 可以選擇兩條截然不同的路徑:

1. 讓EVM 成為一種更高級的語言,有內置的變量、if 語句、循環等結構。

2. 讓EVM 成為某些現有虛擬機(LLVM、WASM 等)的副本。

我們從未好好考慮過第一條路徑,而它的優勢在於,它可以簡化編譯器,並允許更多的開發者直接在EVM 中編碼。同時,它還可以使ZK-EVM 的結構更加簡單。不過,這條路徑的弱點是,它會使EVM 代碼在結構上更加複雜:它不再是一排簡單的操作碼列表,而是一個更複雜的數據結構,必須以某種特定方式進行存儲。也就是說,我們錯過了一個兩全其美的機會:在保持EVM 基本結構不變的同時,對其做出一些改變可以給我們帶來很多好處,包括禁用動態跳轉、增加一些旨在支持子程序的操作碼(另見:EIP-2315)、只允許在32 字節的詞彙邊界上訪問存儲器,等等。

第二條路徑好壞參半,支持的人認為它可以讓程序從現有語言(C、Rust 等)編譯到EVM 中,而反對的人則認為,鑑於Ethereum 特殊的限制因素,它實際上不會提供任何好處:

1. 現有的高級語言編譯器往往不關心總的代碼大小,而區塊鏈代碼必須大量優化以減少每一個字節的代碼大小。

2. 我們需要實現虛擬機的多項功能,並嚴格要求兩個功能不能以不同方式處理相同的代碼,但這也會給在不是我們寫的代碼上進行安全審計和驗證造成困難。

3. 如果虛擬機規範發生變化,Ethereum 將不得不一直隨著它進行更新,否則將很難同步。

因此,儘管當初一些細節得到改善可能會產出更好的結果,但和現在情況不同的是,EVM 在以前可能還是從來沒有過一個可行的路徑。

ETH 供應是否應該以不同的方式進行分配

我們可以從下面這張來自 Etherscan 的圖表看到目前ETH 的供應量:

今天大約一半的ETH 是在公開的Ethereum 銷售中售出的,任何人都可以向一個標準化的Bitcoin 地址發送BTC,而最初的ETH 供應分佈是由一個開源腳本計算得出的,該腳本通過掃描Bitcoin 區塊鏈上的交易獲得地址。其餘的ETH 基本都是靠挖礦得到的,其中標有「其他」的1200 萬ETH,是「預挖礦」的部分——即在Ethereum 基金會和約100 個Ethereum 協議的早期貢獻者之間分配的部分。

人們對該過程提出了兩點批評意見:

1. 預挖礦,以及Ethereum 基金會收到銷售資金的事實,並不是可信的中立。一些收件人地址是在閉環中人工挑選出來的,而且我們必須相信Ethereum 基金不會通過貸款將銷售中收到的資金重新放到銷售環節當中來為自己提供更多的ETH。

2. 預挖礦過度地獎勵了早期的貢獻者,這讓後來的貢獻者只能分得較少的獎勵。 75% 的預挖礦用於獎勵貢獻者在啟動前的工作,而啟動後,Ethereum 基金會只剩下300 萬ETH。在之後的半年時間內,由於財務上的需要,該數字又下降到約100 萬ETH。

在某種程度上,這些問題是相互關聯的:人們為了最大限度地減少中心化,縮小了預挖礦的規模,而這也會讓它更快耗盡。

Zcash 採取了另一種不同的方法:協議中一組硬編碼的接收地址將收到恆定的20% 區塊獎勵,並這一名單每4 年就會重新協商一次(到目前為止已經做了一次調整)。雖然這種方法具有更高的可持續性,但也會因為中心化而受到更多的批評(Zcash 社區似乎比Ethereum 社區更願意接受技術專家的領導)。

我們可以採用如今在一些defi 項目中流行的「DAO from day 1」作為替代路線,草案提議如下:

1. 我們同意在2 年內,拿出每個區塊2 個ETH 的獎勵放入開發基金當中。

2. 任何在Ethereum 銷售中購買ETH 的人都可以指定投票給他們青睞的發展基金,以進行ETH 分配(例如:「每個區塊1ETH 給Ethereum 基金會,0.4ETH 給Consensys 研究團隊,0.2ETH 給Vlad Zamfir 等等」)

3. 得到投票的接受者從開發基金中獲得的份額將等於每個人投票的中位數,並將按按比例進行計算,從而保證其總數等於每個區塊2 個ETH(設置中位數是為了防止自我交易:為自己投票毫無用處,除非你讓其他購買者中至少有一半人為你投票)。

這一銷售可以由法律實體運作完成,該實體承諾將銷售期間收到的Bitcoin 按照與ETH 開發基金相同的比例進行分配(或銷毀,如果我們想讓Bitcoin 玩家高興的話)。這可能會導致Ethereum 基金會和其他團體在不破壞可信中立性的情況下得到大量的資金,加快生態系統去中心化的進程。當然,這一做法的缺點在於,投幣投票真的很糟糕,但務實地說,2014 年仍然是一個較早和理想化的階段,投幣投票最嚴重的缺點在銷售結束很久以後才會開始顯現。

這也許會是一個更好的想法,並樹立一個更好的先例。儘管從現實的角度來看,即使開發基金是完全可信中立的,今天那些對Ethereum 礦工感到不滿的人,很可能會將矛頭轉向DAO 分叉。

啟發

總的來說,有時我覺得Ethereum 最大的挑戰在於保持兩個願景之間的平衡——一個重視安全性和簡潔性,純粹簡單的區塊鏈,以及一個用於構建先進應用程序的高性能平台。上面的諸多例子只是這個問題的一個方面:我們是減少功能數量從而更類似Bitcoin,還是創造更多功能以方便開發者?我們應該擔心讓開發資金更加可信中立會使其更像Bitcoin,還是應該先關心如何確保開發者得到足夠的獎勵,從而讓Ethereum 變得更好?

在我個人看來,我們可以同時實現這兩個願景——一個規格逐漸縮小的基礎層,以及一個以Layer2 協議為中心,功能強大的開發者友好型高級應用生態系統。即便如此,要達到這樣一個理想的狀態還是需要很長的時間。所以說,我們只有一步步地考慮如何制定路線圖,才能取得一定的成果。

雖然我們現在已經無法改變很多事情,但也並不是全部,而且我們依然可以著手提高功能性和簡易性。不過,在這個過程中我們有時也會遇到一些困難:為了提高分片上Layer2 的可擴展性,我們需要先增加一些複雜性以實現分片。但即便如此,複雜性的降低也是可能的,Ethereum 的歷史已經證明了這一點:

1.EIP-150 使得調用堆棧深度限制不再適用,從而減少了合約開發者對於安全性的擔憂。

2.EIP-161 讓「空賬戶」不再與字段為零的賬戶區分開。

3.EIP-3529 刪除了部分退款機制,使得Gas Token 不再可行。

有了Verkle 樹等還在醞釀中的想法以後,我們甚至可以進一步降低複雜性。但如何在未來更好地平衡這兩種願景,是我們應該開始好好思考的問題。

Total
0
Shares
Related Posts