來自 Cosmos Hub 的經驗如果你觀察過 Cosmos Hub 是如何從 1.0 版本升級到 2.0 版本，再升級到 3.0 版本的，你就會知道 Cosmos Hub 的升級本質上是透過用一個新的創世塊重啟區塊鏈來實現的。要升級的時候，節點運營者需要關閉節點，然後生成 Cosmos Hub 狀態的快照，然後將這一快照打包進新的創世塊，建立一條新的區塊鏈。現在，凡是想要加入 Cosmos Hub 的人，都需要獲取 CosmosHub-3 的創世塊，下載 CosmosHub-3 的所有區塊並進行重放（不再需要下載 CosmosHub-1 或 CosmosHub-2 的區塊了）。我們可以 “重啟” ETH 1.0 嗎？我們來設想一下同樣的方法能不能應用到以太坊上。以太坊區塊鏈非常龐大（150-160 Gb），狀態也很大（40-100 Gb，具體取決於你儲存狀態的方式）。“重啟” 以太坊區塊鏈的一個明顯優點是，新加入的節點需要下載 40Gb 的創世狀態，而非一條 150 Gb 的區塊鏈。然而，下載 40 Gb 的創世狀態也不是很好的體驗。將以太坊的狀態儲存在鏈下，只有默克爾根雜湊是鏈上可見的

假定我們可以將這 40 Gb 儲存在 “鏈下”，只將根雜湊打包進創世塊，這樣我們就能從空狀態開始了。但是，我們如何讓交易訪問這些隱式的狀態？請記住，儘管這 40 Gb 的狀態是隱式的，而且如何獲取這些狀態屬於實現細節，你可以執行所有 1000 萬個區塊來計算這些狀態，或者透過快速同步、warp 同步來下載其快照，或者從其他人的外部磁碟複製過來再進行驗證。雖然狀態是隱式的，但是我們假設區塊提議者（通常是礦池）可以訪問這部分隱式資料，而且能夠處理所有交易。只不過我們要放棄一個假設：所有其他驗證節點都可以訪問隱式狀態，來驗證區塊中的交易是有效的，且區塊頭中的狀態根雜湊符合區塊的執行結果（譯者注：在當前的以太坊協議中，因為所有狀態都是顯式的，所以這個假設是合理的）。這不是無狀態以太坊嗎？如果你瞭解無狀態以太坊（Stateless Ethereum），你可能會意識到，這正是我們目前努力的方向 —— 保留 “區塊提議者可以訪問隱式狀態” 的假設，去除 “所有驗證節點都可以訪問隱式狀態” 的假設。我們建議的解決方案是，讓區塊提議者將額外的證明新增到區塊中。我們將該證明稱為 “區塊見證（block witness）”。區塊中的證明 vs 交易中的證明第一次瞭解這個方案的人會認為額外的證明實際上是由交易傳送者提供的，是交易有效負載的一部分，我們不得不出來解釋說並非如此，證明是由區塊提議者提供的。但是，我們後來發現，交易也必須包含額外的證明。換言之，交易傳送方需要證明傳送方地址有足夠的 ETH 來支付 gas 費，以及其他所有由這個賬戶發起的 nonce 值較小的交易。此外，交易傳送方還需證明傳送方賬戶的 nonce 值，以便節點弄清楚 nonce 值之間是否存在缺口，以免有人藉機傳送一系列不可行的交易來進行 DDOS 攻擊。我們還可以進行更加嚴格的檢查，不過對於絕大多數抗 DDOS 攻擊的方案來說， ETH 餘額和傳送方賬戶 nonce 值是必要資訊（或許還不夠充分）。

交易中的證明存在的缺點假設我們想讓交易傳送者將每一個相關狀態的證明都新增進交易。這樣做的好處在於，將簡化我們為見證收取額外 gas 費所需的工作量。這樣做的主要缺點在於，這通常需要透過動態狀態訪問（DSA，與靜態狀態訪問（SSA）相對）實現。如果一個交易涉及的智慧合約特別複雜，比方說，有大量對其他合約的巢狀呼叫，可能很難預先計算出交易將涉及的狀態項。攻擊者甚至可以利用 DSA 來給使用者 “下套”，即，搶跑其交易（傳送內容一樣但 Gas 費更高的交易，以搶在前面被打包）讓使用者的交易因為證明不充分而失敗。ReGenesis 提供的緩解措施雖然 DSA 的隱患很難徹底解決，但是可以儘可能降低其風險，讓使用者不會感到不便，也不會永遠限於無法實現預期狀態轉換的境地。該緩解措施需要引入額外的規則，即，任何隨交易提供的證明（已經根據狀態根進行過驗證，但這並不足以保證交易能成功）都會成為隱式狀態的一部分。因此，隨著使用者反覆嘗試執行交易，隱式狀態會不斷增長，最終交易成功。那些嘗試給使用者 “下套” 的攻擊者必須找到更復雜的方法，把使用者的狀態訪問重定向到已有的隱式狀態之外，最終以失敗告終。隨著隱式狀態從無（剛重啟時）到有不斷增長，包含越來越多的主動訪問狀態，交易需要提供的證明將會減少。過了一段時間，大多數交易甚至不需要附帶任何證明，除了那些涉及到很久之前的狀態的交易。我們可以定期執行 ReGenesis

我稱之為 “重啟” reGenesis ，可以定期執行，以便減輕非挖礦節點的負擔。ReGenesis 也代表了一個不那麼激進的無狀態以太坊版本。反覆執行 ReGenesis 將簡化以太坊客戶端實現的架構，幾乎可以免去對較高階快照同步演算法的需求。如果我們每隔 100 萬個區塊（大約 6 個月）執行一次 ReGenesis，可以將狀態快照和區塊鏈檔案放到 BitTorrent、Swarm 和 IPFS 上公開。目前我們無法做到這點（隨產生隨存），因為狀態每隔 15 秒而非 6 個月轉換一次。如果客戶端實現可以重放 6 個月的區塊，我們就不需要非常複雜的快照演算法。因此，以太坊實現的複雜性會降低。ReGenesis 的缺點我還沒有對此進行深入探索，不過我已經看到的三個缺點有：使用者可能需要訪問完整的隱式狀態來建立交易。實際上，我認為這是公平的妥協。（由於 DSA）使用者可能需要反覆執行交易，直到最後實現預期狀態轉換。

一些（利用區塊鏈資料來實現資料可用性的）rollup 技術可能會受到影響