VIT:Vitalik關于無狀態、維克爾樹和狀態休眠的即興技術

01

bluepintail 提問：

與進行中的升級 (1559、合并和分片) 相比，實現狀態休眠機制 (state expiry) 的復雜度怎么樣？

Vitalik 回答：

好問題！我會說從以太坊客戶端開發者的角度來說，它的復雜性介于 1559 和合并之間。它更大的難度在于基礎設施還沒建起來，以及要與狀態休眠機制長期配合的話需要重寫合約 (狀態休眠機制不會破壞任何現有的合約，可能除了一些非常病態的情況，但它確實使現有的合約隨著時間變得越來越低效，因此它們可能需要在 5-10年內重寫，以保持可運行)。

需要構建的一個主要基礎設施是提供舊狀態的見證數據 (witness)。如果有人有 1 年多沒訪問過的舊狀態，然后他們想發起一個事務訪問它的，如果不在它們手上，他們會需要從某處取出該舊狀態。有三種可能性：

中心化服務器 (etherchain、etherscan......) 采用一個標準化的 API，它會返回舊狀態的見證數據

用戶必須自己找到存檔節點，并對其進行 RPC 調用

去中心化又易于使用的方案是更難開發的：類似用門戶網絡 (Portal Network) 存儲這些證明

另一項需要實現的是升級所有以太坊基礎設施，以使用包含地址周期的新地址格式。

對于合約的主要挑戰是，如果你想構建一個長期保持可用的合約系統，那么你將需要以這樣的方式：對應新用戶的新數據不需要保存在舊地址周期。如果沒有做任何事，那么如果一個 ERC20 代幣在周期 0 被創建了，它現在應該是周期 10，然后發送一個 ERC20 代幣到一個還未擁有該特定 ERC20 代幣的地址，這將需要提供 8 個見證數據 (在時段20時，這會變成需要 18 個見證數據)。因此不是致命的，但會越來越煩人。為了避免這點，ERC20 代幣需要采用一種在更新的 (newer) 地址周期上有子合約的結構，把更新創建地址上的余額存儲在那些更新的地址周期上。我認為，現在是合約設計者開始認真考慮如何在“后狀態休眠機制” 的世界里設計他們的合約了。

02

dhskiskdferh 提問：

派盾：標記為Vitalik Buterin的地址轉移多種代幣或是整理錢包:金色財經報道，派盾PeckShield發布推文稱，標記為Vitalik Buterin的地址已轉移多種代幣（一些山寨幣）和1,541.59枚USDC，并將13萬枚USDC轉移到Coinbase，此舉或許是在整理錢包。[2022/12/21 21:58:13]

你可以更詳細闡述一下智能合約實現將如徹底支持這點嗎？乍一看，我想知道如何把狀態 (像余額和補貼）轉移到一個新地址......我想是可以遷移狀態的，盡管我會覺得這是非常貴的交易。

關于如何在未來編寫合約以支持這點，請問你有什么洞見嗎？謝謝

以下是一個更完整的"后狀態休眠機制" ERC20 代幣的概述。

假設 ERC20 合約在周期 C 創建，而它當前處于周期 N。它的每個周期 C, C+1, C+2 .... N 都有子合約。一個地址周期是 A 的地址的代幣余額會被存儲在周期  max(C, A) 的子合約里。

這確保了即使 ERC20 合約失活了，如果你創建了一個新地址，你將不需要提供見證數據 (因為如果你的地址是在周期 N ，那么余額會被存儲在周期 N 的子合約里，這不需要見證數據才能編輯，因為 N 是最新的時段)。

只有以下兩種情況才需要見證數據：

讀取和編輯在最近兩個時段都未被訪問過的賬戶的余額

當賬戶和 ERC20 合約都失活后，第一次設置賬戶的余額

如果我們真的想，我們可以通過擴展協議來消除第二種情況，使在地址周期 P 的地址 X 可以發送由在地址周期  Q 上的地址 hash(X, P, Q) 所有的代幣；這會允許代幣持有者使用地址  hash(X, P, Q)  來接收代幣，這樣  X 就可以發送它們了 (如果 Q 是最近兩個時段之一，這就不需要見證數據了)。

另一個想法是只在可用的最近狀態周期里存儲代幣余額 (這樣只要發送者的狀態是最近的，就永遠不需要見證數據才能發送代幣給其他人)，且只有在必要時才會用 transfer 函數從歷史周期里取周期和匯總余額  (balance 函數也必須這樣做；這樣 balance 函數的使用就不得不減少，且在需要使用時也會節省很多)。

Vitalik：捐贈的50萬億枚SHIB不會獲得稅務沖銷:5月19日消息，Vitalik表示，其向印度新冠加密救援基金捐贈的超50萬億枚SHIB不會獲得稅務沖銷（稅務減免）。據悉，SHIB幣價波動劇烈，此前其捐贈款價值20億美元，目前縮水到8億美元左右。（彭博社）[2021/5/19 22:19:08]

以上內容的總結是：在為長期見證數據最小化做優化和簡化代碼間有一個光譜，我預計很多合約會更關注代碼簡化，并只使用最基本的長期見證數據最小化技巧。但我希望易于編碼的最佳實踐會隨著時間推移得到開發和發展。

03

Kike328 提問：

與某地址直接相關的狀態不能在每次與該地址本身有交互時都上傳嗎？我意思是，創建一些較短的周期，但每次與一個合約有交互時，就上傳該合約的所有狀態到該周期。我不是完全了解以太坊的狀態運作細節，所以可能我說的并不實際和有點愚蠢，但這會解決我們合約開發者對寫的合約不適用于未來的擔心。

與某地址直接相關的狀態不能在每次與該地址本身有交互時都上傳嗎？

不能，因為可能會有無限多這樣的狀態。M 個用戶* N 枚代幣=M*N 個潛在余額。

04

PurpleHamster 提問：

狀態休眠機制跟狀態租金方案一樣嗎？

狀態休眠機制和狀態租金解決的是相似的問題，兩個方案所屬分類的界限是有點模糊的。現在的 state expiry 方案與 2015-18 年間的狀態租金方案間的主要現實差異是：

狀態休眠機制沒有試圖對一個接收了給定狀態支付租金的某特定區塊做審計。相反，它更粗略，按年來計算。這能減少復雜性。

不存在“支付租金”這一操作；相反，你只需在正常交易發送過程中訪問它，就能延長它的活性時間。

如果你的狀態失活了，激活它是很簡單的；你只需提供一個見證數據

使狀態失活也不需要有什么操作，這也能減少復雜性

有一個“地址周期”機制使得在無須提供見證數據的情況下更容易創建新合約，同時避免復活沖突（這種情況是某狀態對象在某位置上失活了，有人發送了一個事務到這個位置以創建一個新的對象，這會與之前在這個位置上但“狀態不再可用”的值沖突。）

波場與WAVES達成戰略合作 將利用Gravity連接區塊鏈智能合約語言:據官方消息，波場已與WAVES達成戰略合作，Waves和TRON將一起利用Gravity來連接各自區塊鏈的智能合約語言，即Ride和Solidity。Gravity是一個無基礎代幣的預言機，具有跨鏈通信網絡。TRON和Waves正在通過Gravity建立一座橋梁，這將允許兩個生態系統為兩個用戶群提供更多的服務。波場和Waves的生態系統計劃將這一趨勢擴展到其他區塊鏈生態系統并以此為鏈間DeFi行業帶來革命性改變。波場 TRON 以推動互聯網去中心化為己任，致力于為去中心化互聯網搭建基礎設施。旗下的 TRON 協議是基于區塊鏈的去中心化應用操作系統協議之一，為協議上的去中心化應用運行提供高吞吐，高擴展，高可靠性的底層公鏈支持。波場 TRON 還通過創新的可插拔智能合約平臺為以太坊智能合約提供更好的兼容性。[2020/8/14]

05

robmacca 提問：

如果我擔心這些數據會丟失，是否有可能為我所有的錢包交易/值 (不是整個網絡) 創建見證數據？

Vitalik 回答:

如果你的數據在該狀態周期沒有被更新，你就必須每年上線一次，并創建一個見證數據，所以不是創建了見證數據以后什么都不用管了。我個人并不擔心數據丟失；有很多行動者在存儲歷史數據，只要它們中的一個是可用的，你就可以對其發出 RPC 請求并獲得見證數據。全部數據提供商 (我很確定數據提供商的數量超過 100) 都丟失了它們的數據這件事的概率比遇到 51% 要低得多。

06

CrustyRat  提問：

Mina 和它的實現對以太坊基金會和實現以太坊無狀態這一目標有什么啟示嗎？

我們的密碼學團隊與 Mina 團隊在很多場合聊過。我當然希望 Mina 先實現它的目標，因為它是一個更簡單的系統，且可以從頭開始，但整個狀態轉換函數完全使用 ZK-SNARK 加密也是以太坊的一個長期目標。盡管在我看來，這與無狀態是兩個不同的軌道。

07

BestLucarioFan 提問：

如果所有的存檔節點都關閉了，我們只剩下普通節點的話，失活的狀態會怎么樣？如果你自己不真的存儲失活狀態的話，是否不可能為失活狀態提供見證數據了？

聲音 | IOTA愛好者George：Vitalik對IOTA協議的理解并不正確:針對Vitalik評價IOTA Coordicide協議是Avalanche協議的升級克隆，IOTA愛好者George認為Vitalik有些輕浮和草率，并沒有認真研究IOTA的新研發成果。他表示：Avalanche協議和IOTA一樣是無礦工和第三者驗證者的新型加密協議，也稱為Leaderless協議。BCH是有礦工的，不是leaderless協議，所以IOTA和BCH絲毫沒有關系。IOTA Coordicide協議是第一個Leaderless的協議，所以說IOTA克隆Avalanche協議不現實。[2019/5/31]

還有，采用了狀態休眠機制后，你預計運行以太坊客戶端需要多少 GB？即使在很遠的未來，這會保持不變嗎？（不考慮 gas limit 提升的話）

最后，與 merkle-patricia trie 相比，解析維克爾樹 (verkle trie) 的速度會慢多少倍？

全部存檔節點都關閉這件事的可能性似乎是極小的。因為存檔節點有好幾百個，其中很多是由企業的高水平技術團隊運行的。作為一個額外的保護層，我預計門戶網絡或類似的系統會要求每個普通用戶存儲一小部分歷史狀態，并以這種方式進行去中心化備份。

采用了狀態休眠機制方案后，你預計運行要給以太坊客戶端需要多少 GB？即使在很遠的未來，這會保持不變嗎？（不考慮 gas limit 提升的話）

根據當前的 gas limit 水平，我預計 50 GB 就可以了，盡管如果 gas limit 提升的話這個數字會增加。

08

這很酷，如果只需要 50 GB的話，我想在我家的 PC 運行一個本地以太坊客戶端。

這里存儲量的減少是否會與輕客戶端的引入向疊加？

在實現了合并、無狀態和狀態休眠機制后，你會有下列客戶端選項可運行：

輕客戶端：存儲要求：50 kB。帶寬要求：最低每天 50 kB、每個區塊~1 kB。安全模型：同步委員會的誠實多數

無狀態客戶端：存儲要求：< 1 MB。帶寬要求：每個區塊~500 kB。安全模型：完全安全

行情 | Activity 指數EOS排名第一:據blocktivity.info數據顯示，Activity 指數排名第一的EOS 現報為 6,101,280 ，排名第二的STEEM 的 Activity 指數為 1,122,576 ，排名第三的BTS的 Activity 指數為 949,526 ，排名第四的ETH 的 Activity 指數為 574,337 ，排名第五的BTC 的 Activity 指數為 183,026 。Acitivity 指數為最近 24 小時內在區塊鏈上執行的操作數量。[2018/8/26]

普通全節點：存儲要求：~50 GB。帶寬要求：每個區塊~100 kB。安全模型：完全安全

存檔節點：存儲要求：~1-3 TB。帶寬要求：每個區塊~100 kB。安全模型：完全安全

09

UnrulySasquatch1 提問：

是打錯了嗎？為什么無狀態客戶端需要的帶寬是存檔節點的 5 倍？

全節點和存檔節點下載的是相同的數據，以與區塊鏈同步。無狀態節點需要下載更多數據，因為需要下載見證數據以驗證狀態 (普通節點不需要是因為它們僅自己保存和維護狀態)；這是擁有無狀態客戶端的折中。

10

AdvocatusDiabo  提問：

維克爾樹好像非常有前景。另一方面，Eli Ben-Sasson 說我們可以生成與今天所需見證數據大小相同的零知識證明 (https://twitter.com/EliBenSasson/status/1405414149925048323)。以及在數年后，可能會有一個新的改良數據結構。我的問題是我們可以把它抽象了嗎？是否有可能使底層數據結構不成為協議的一部分，而對于無狀態來說，是否可能在沒有一個數據結構的情況下也能請求到見證數據？我希望這個問題是有意義的。

從長遠來看，STARKs 肯定是更好的技術，但當前的證明生成還不夠快。使用對哈希了的二叉樹進行STARK 加密的見證數據的最壞情況會是每個分支 6000 次訪問 * 80 個哈希值 (假設最壞情況的深度)= 480000 個哈希值，一個更普遍情況的見證數據會是每個分支 1500 次訪問 * 25個哈希值=37500個哈希值。即使是后者也需要非常重型的超并行化機器 (ultra-parallelized machinary)，才能在一秒鐘內使用常規的哈希函數 (即 SHA256)生成一個證明。一旦優化了算法的哈希函數 (MiMC、Poseidon、Rescue 等系列) 被證明了是足夠安全的，那么STARKs 會變得更可行。至于維克爾樹，現在已經可以快速生成證明了。

11

Routine-Thing 提問：

對于礦工或驗證者來說，實現無狀態意味著什么？

這意味著你不需要大量的磁盤空間來做驗證者以驗證區塊。現在，要做區塊提議者還是需要有磁盤空間。也就是說，看起來越來越有可能區塊提議在將來會變成專業化的作業，驗證者不是一定要做區塊提議工作；詳見：https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725 （中文版）

12

asdafari 提問：

雖然該提議旨在解決中心化問題，這可能來自 PoS 系統里的 MEV，是保留 MEV 的長期方向嗎？如果是，原因是什么？它通過搶跑或尾追交易或三明治夾擊等從一般用戶手中提取價值，使區塊構建者/提議者獲益，我認為這是大多數人都認為是不可取的。我有時覺得我在 Uniswap 上的交易已經出現可疑的高滑點了，但這也可能只是我的多疑。

我真的看不出現在消除 MEV 是可能的。現在有非常多種重要類型的 MEV (例如，交易所的價格套利)，我看不到能把它們消除的方法。我認同應該最大限度地阻止三明治夾擊等類似的操作，盡管如此，我覺得更多的專業區塊提議者是解決方案的一部分 (例如，大多數 Uniswap 攻擊可以通過設置滑點=0 得到阻止，而要做到交易滑點為 0 且交易一致不會失敗或浪費 gas，在 Uniswap 上排序成功你交易費支付需要有額外條件，也就是需要專門的交易打包邏輯...)

13

TShougo 提問：

這可能是個新手問題。修剪 (pruning) 和無狀態有什么區別？修剪不是也為全節點減少狀態大小嗎？

修剪只意味著移除不再需要存儲的舊數據。大多數的以太坊節點已經都是修剪節點了，這幫助我們成功渡過出現過的 gas limit 提升。無狀態允許客戶端完全不需要存儲數據，狀態休眠機制允許最近沒有被訪問過的狀態數據也被修剪。

14

LightningShark 提問：

在使用像維克爾樹這樣的新概念時，你是如何管理風險的？你是否曾經擔心過使用這個方法會有風險？

維克爾樹依靠的是目前已經相當成熟的密碼學，即如果它出問題了，Monero 也運行不下去了。

15

Liberosist 提問：

你預計 rollup 會實現狀態休眠機制嗎？會有什么不同？還是說像 regenesis 這樣的方案在 rollup 里會更常見？

Regenesis 并不是狀態休眠機制的真正競爭者；Regenesis 是同時實現狀態休眠和歷史數據休眠 (這就是以太坊現在在走的路) 的概念的品牌名。我肯定期望 rollup 也會網這個方向走，只是因為接近主線 EVM 是符合它們的利益的。

16

temple22 提問：

對合同設計增加的復雜性可能會給開發人員帶來更高的準入門檻，你認為這可能是一個需要考慮的問題嗎？

盡管我理解狀態問題是必須要解決的。

這肯定會給開發人員增加一些復雜性，盡管目前的設計已經是多年思考與研究如何盡量減少這種情況的結果；這一直是阻止我們在 2018 年開啟這個計劃的主要原因。因此，我認為我們到了一個地步，是這個提議在給開發者增加復雜性與給客戶端或用戶大大減少復雜性之間取得一個合理平衡。其他以太坊功能 (例如賬戶抽象和更好的歷史訪問工具) 也會同時使開發者的工作更容易開展。

17

fipasi 提問：

狀態休眠機制對維持網絡運行是必須的嗎？

理論上，如果我們覺得構建區塊和運行一個普通節點需要更多存儲是沒問題的話，使用無狀態就可以維持它運行。但這個路徑有中心化風險。

18

lucadonnoh 提問：

對學習計算機科學的學生來說，有沒有什么學習承諾、默克爾樹、維克爾樹這些東西的好資源？

可以從閱讀我關于維克爾樹的文章開始：https://vitalik.ca/general/2021/06/18/verkle.html

19

lectorlector 提問：

有沒有可能用目前的以太坊默克爾樹生成一個維克爾樹結構，然后生成承諾和證明？這樣就可以維持當前以太坊默克爾樹的哈希函數了？

例如，生成一個維克爾樹證明，它是目前以太坊默克爾樹某個根上的一個葉子，還是說在把原來的哈希函數用在 KZG 承諾和維克爾樹上有某些限制，所以需要生成一個用一個不同哈希函數的、新的樹結構？(就像在 zkSNARK 中使用 Keccak256 就太貴了，人們因為 SNARK 線路大小限制而使用Mimc或Poseidon等'snark friendly'哈希函數)

我們需要使用新的承諾的新的樹結構，以生成維克爾樹證明；證明大小的增加與維克爾樹使用代數同態的承諾而不像 SHA256 那樣的黑箱哈希值密切相關。

20

saddit42 提問：

你會擔心實施無狀態會對現有的和未來潛在的應用造成太大的破壞？你認為是否有破壞性較小的可行路徑？

我不認為無狀態會破壞任何應用！狀態休眠機制確實會有 (看我上面的回答)，但即使如此，影響也不是那么糟糕 (現有的應用還會繼續運作，只是會隨著時間推移變得沒那么高效)，且應用會有很長的時間來適應。

21

UkoeHB  提問：

維克爾樹需要可信設置 (trusted setup) 嗎？如果需要，我很驚訝這點沒有在你的博客文章里提到，而盡在延伸閱讀里找到。

如果你使用 Kate 承諾的話，需要 (但是是小型的，因此制作一個就可以有數千個參與者是非常容易的)。如果你使用 bulletproof 類型的承諾，就不用。

原文鏈接：https://www.reddit.com/r/ethereum/comments/o9s15i/impromptu_technical_ama_on_statelessness_and/

Tags：VIT以太坊VITYTALGravityCoin以太坊價格最新消息GravityTALIS

火幣APP下載