觀點：Eth2作為數據可用性引擎
編者按：本文來自以太坊愛好者（ID：ethfans）編者按：本文來自
以太坊愛好者（ID：ethfans）
以太坊愛好者（ID：ethfans）
編者按：本文來自
以太坊愛好者（ID：ethfans）
以太坊愛好者（ID：ethfans）
編者按：本文來自
以太坊愛好者（ID：ethfans）
以太坊愛好者（ID：ethfans）
，作者：Casey Detrio，翻譯&校對：閔敏& 阿劍，Odaily經授權轉載。
編者註：這篇文章的原標題為“Phase One and Done: eth2 as a data availability engine”，在發表當時（2019 年4 月），作者意在為Eth2.0 提出一種替代Phase 2 的路線圖，也就是，如果僅用分片來保證數據可得性，這樣的系統是否有用，還需要增加哪些部分來使之變得有用。令人驚訝的是，在一年半以前，作者就已經認識到，對zk-rollup 這樣的系統來說，底層必須保障的是“狀態轉換的執行和數據可得性必須是原子化地綁定在一起的”，因此底層必須具備執行能力，哪怕是非常簡單的無狀態執行；而且，（作者也通過層層推理指出）為保證用戶體驗，還缺少的主要部分是數據怎麼上分片的手續費支付協議（這兩點認識，即使放到今天，也仍然稱得上是前沿，甚至是超前）。手續費協議在Phase 2 的規範中，目前也仍然是缺失的。
順帶說一句，本文作者是Casey Detrio，他是Ewasm 團隊的一員，之前也為Phase 2 提供過很多想法；他也認為，應該以“保證Eth1 的合約到了Eth2 能夠如常執行” 為核心來設計Eth2 . 0。他是被低估的一個開發者。
目前，限制Eth1 吞吐量的瓶頸是狀態增長。因此，如果我們想要擴展以太坊，從邏輯上來說，1000 個具有獨立狀態的分片能夠將吞吐量提高1000 倍。
但是，從Eth1.x 的路線來看，Eth1.x 想要對兩類資源的成本進行重大調整：存儲（storage）和交易數據（tx data）。目前，存儲的定價過低，而交易數據的定價過高。這會激勵dApp 開發者在編寫合約時更多使用存儲而非交易數據，從而導致存儲成為吞吐量的瓶頸。針對這一問題提出的解決方案是增加存儲的定價，並減少交易數據的定價。經過這些成本調整，開發者將受到激勵更多地使用交易數據，而非存儲（即，他們會編寫更多無狀態合約而非狀態合約）。因此，在不久的將來（如果Eth1.x 的路線圖獲得廣泛採用），我們預期Eth1 的吞吐量會受到交易數據的限制，而非存儲的限制。
如果我們假設吞吐量受到交易數據的限制，那麼為了擴展以太坊，Serenity 上的分片不需要有狀態。如果吞吐量受到來自無狀態合約的交易數據的限制，那麼1000 個無狀態分片就會將吞吐量提高1000 倍。
這聽起來不錯，但是需要通過分片來實現，按計劃要等到Phase 2。與此同時，我們可以將Phase 1 作為數據可得性引擎。數據可得性引擎一詞似乎逐漸流行起來。我們來思考一下它是如何運作的。
以zk-rollup 為例，zk-rollup 受到數據可得性的限制。 Eth1 上的zk-rollup 合約能否有效地將Eth2 作為橋接式可用性保障提供方？如果在執行（即，驗證SNARK 證明並更新狀態根）過程中無法同時保障數據可得性，你就會得到一個類似plasma 的zk-rollback 系統。這個系統雖然能夠大幅提高TPS，但是會引入複雜的權衡關係，需要處理像plasma 那樣的運營者挑戰和退出機制。在可用性挑戰中，任何人都可以提供數據來證明可用性，因此目前還不清楚將數據放入橋接的Eth2 分片中能不能讓事情變得更簡單。
現在有了另一個版本的zk-rollup，即，500 TPS 的zk-rollup，一切都變得簡單多了。不再需要指定的運營者，任何人隨時都能充當中繼者，並生成SNARK 證明來更新狀態。事實上，數據可得性保障始終伴隨著狀態更新，也就是說不需要處理像plasma 那樣的運營者挑戰和退出機制。但是這需要執行和數據可得性保障都發生在同一筆交易中，而遺憾的是我們無法使用橋接式可用性引擎做到這點。換言之，橋接對於zk-rollback 這樣的欺詐證明系統來說足夠了，但是對zk-rollup 這樣的有效性證明系統來說還不夠。結論是，為了將Layer 2 上的有效性證明簡單化，Layer 1 上的可用性引擎需要具備的一項重要功能是，能保證數據可得性與狀態轉換的執行是原子化地一起發生的。
或許我們不應該對這一認識感到驚訝。如果單靠數據可得性（沒有執行）就有用的話，就不會有人說Phase 1 啟動只是為了確保一堆非零blob（二進制大型對象）的可用性，也就不會有人抱怨必須要等Eth2 進入下一階段才能真正發揮作用了（除了PoS 之外）。我們正在努力將Phase 1 作為數據可得性引擎，但是它依然無法執行任何操作，因此令人感到失望。 （哇，我們可以構建Mastercoin 2.0 了！）
那麼，為什麼Phase 1 會與執行相衝突？好吧，假設是有狀態執行，則每個分片都要維護一些本地狀態。如果驗證者需要維護很多本地狀態，那麼驗證者混洗就會復雜得多。反之，如果沒有執行，就不用擔心本地狀態。驗證者混洗就會簡單得多，我們就可以專注於使用數據blob 構建分片，然後更快地啟動分片。
但是，我們先不假設執行是有狀態的。如果我們嘗試使用非常簡單的無狀態虛擬機來執行操作會怎麼樣？
假設信標鏈狀態中有3 個新的驗證者字段：code、stateRoot和deployedShardId。這裡還有一個函數process_deploy（就在process_transfer 下方）。一旦代碼部署完成，驗證者必須保證賬戶餘額不低於某個閾值【至少鎖定1 ETH。如果代碼中沒有自毀程序（SELFDESTRUCT），那麼這部分ETH 就等同於銷毀了，代碼也會永久部署】。
現在，我們假設全局狀態中已經有了一些帶有代碼的賬戶。
