本文爲 Casey Detrio 於 6 月 1 日發表的長推特，談及 Eth1.0 的遷移問題以及一個他認爲非常天才的想法：用橋接器讓 Eth1.0 上的合約來協調分片鏈，讓後者的吞吐量可以爲前者所用。Eth1.0 的遷移問題實際上是所有以太坊社區成員都關心的問題，而周全的解決方案顯然還需進一步討論。

原文標題：《範式轉變：Eth2.0 的分片鏈如何能服務於 Eth1.0 上的合約？》
作者：Casey Detrio
翻譯：阿劍

Casey Detrio：

昨天我跟 @josephch 聊了很長時間，他問了一個重大但又可怕的問題：隨着大家的注意力都轉向 Eth2.0 的發佈，從長遠來看，Eth1.0 鏈以及鏈上的所有合約及其用戶，要如何適應 Eth2.0 （Serenity）的路線圖呢？

我們曾經害怕這個問題，因爲給不出一個好的答案。但這一次，我們問了一個新的問題、用了一種新的敘事方式，因此我從中得到的更多是啓發，而非恐懼。因爲其中實際上包含着一種思考模式的轉變，一開始它只會逐漸地發生，（我希望）未來它會集體性地同時爆發。

我所受到的啓發是：與其問 Eth1.0 的合約要如何遷移到 Eth2.0 的分片上（破），不如問 Eth2.0 的分片要如何服務於 Eth1.0 上的合約（立）！

儘管他也知道這是一個棘手的問題，我覺得 Joseph 一定從中得到了啓發，因爲他也意識到了這種轉變。這種朝向全新理解的角度轉變始於一項圍繞着 Eth2 的創新：Eth1 到 Eth2 的「可用性橋接器」。

橋接器這種想法已經被提出有幾個月之久了，但當時並沒有被當成重要的創新（至少我是沒看出來）。追溯歷史，我們可以看出爲什麼它被低估了。這故事要從 2018 年 6 月那場轉折開始說起。

在 2018 年 6 月的路線轉折中，人們放棄了在主網上部署 PoS，而是選擇發佈 Eth2.0 （PoS + Sharding）作爲一條獨立的新鏈（信標鏈 + 分片鏈），讓我們暈頭轉向。被推到了一個新的宇宙中，我們就要圍繞着 Eth2.0 來調整自己，我們的願景也變得完全以 Eth2.0 爲中心。

在 2018 年的路線轉折中，人們提出了分階段的 Eth2.0 構想；自那以後，可用性橋接器就成了最重要的一件事，雖然這一念想完全不引人注目。我們可以從 Eth2.0 階段性構想的一個有趣側面證明這一點。

這個有趣的一面就是，在 Phase1 中分片鏈是完全沒有用途的，因爲驗證者爲分片鏈打包的區塊（即數據塊）裏面除了 0 字節什麼也沒有。要啓動 100 條滿是 0 字節的分片鏈顯然很蠢。

這裏的問題在於，要想可靠地把用戶的交易（非 0 字節的數據）打包到分片鏈區塊中，我們先得確定 Phase 2 工作的基本原理。而這是我們還沒能確定的。

而可用性橋接器的天才之處在於，它使用 Eth1.0 的合約給分片區塊提議者支付、要求後者在數據塊中納入有用的非零數據。

我要說的是，如果我們盯着 Phase2 作爲最終目標，我們是看不見 eth2-phase1 橋接器對 Eth1.0 鏈的重要性的：在等待 Phase2 發行的時候，這個橋接器看起來就是某種裝裝樣子的哨子。

而我正在意識到，這種橋接器是一種全新的想法，有可能產生出新路線圖和傳統願景的統一體：Eth2.0 = Eth1.0 + PoS + 分片鏈。

這種統一體不再把 Eth2.0/ 分片 當成一個獨立的新系統、也不再給 Eth1.0 的 dApp 安排一場迫在眉睫、顛沛流離、挫人士氣的大遷徙；橋接器可以讓我們把分片鏈當成 Eth1.0 的延伸，分片鏈會建立在 Eth1.0 生態系統的勢能之上，並帶着這種勢能繼續前行。

也許我們可以拓寬橋接器，變成一個 8 車道超級通道，將 Eth1.0 鏈 與百萬噸級的可用性和執行引擎連接起來，獲得 1000 條乃至 10000 條分片鏈的並行吞吐量。

Eth1.0 鏈可以成爲「帝國首都」/ 最熱門的分片鏈，其中的合約可以發起即時的同步調用（調用部署在其它「城市」裏的合約）（當然也要付出更高的費用）。

那些不是嚴格與 dApp 間交互相關的 dApp 功能可以並行處理，可以遷移到「分片上」而非鏈下（即在分片上執行，而不是在主鏈上執行）。

我猜想，其他開發者和研究者也正在產生類似的想法、在迭代 eth1-eth2 橋接器。我迫不及待想看看他們的提議。

Vitalik：

這 … 感覺不太 make sense。理由如下：

無論怎麼說，我們需要從 PoW 遷移到 PoS，而信標鏈會是 PoS 中心鏈。所以，如果「Eth1.0」要變成每個人都跟蹤的一箇中心，它得變成信標鏈上的一個狀態根和一個數據空間。所以無論怎麼說我們都不得不付出這個遷移成本。

然後，我們還有 @realLedgerwatch 在打造 Eth1.0 無狀態客戶端上的工作。爲了防止運行信標鏈節點的門檻太高，eth1.0 的驗證工作必須基於無狀態客戶端。當前我們有的是一個執行環境，除了某些原因，每個信標鏈節點都必須驗證數據。對於安全性來說這不是必需的，我們可以降格成由一個委員會（和感興趣的節點）來驗證數據。

目前我們已經爲將 Eth1.0 引擎轉變爲一個執行環境的每一步都做了辯護。也許它會是人們首要使用的一個執行環境。如果有需要，我也可以通過加入基本的跨分片支持來讓它變得更突出。

因此，我們可以合理地說，eth1.0 系統整個要從一條鏈轉變爲一個執行環境。如果計劃得當，這一操作可以無縫完成，不會破壞應用。因此，對 dApp 來說遷移成本也可以下降到零。

好吧，我收回「不太 make sense」的說法。實際上這並不是「A vs B」的辯論，把 Eth1.0 當執行環境的模型是兩大方法的綜合（eth2 圍繞 eth1 vs eth2 取代 eth1），綜合之後我們可以同時獲得雙方的優勢。具體來說，就是：

  • 接近於 0 的遷移成本
  • 在 eth1 上開發 dApp 變成了一個長期可靠的策略，因爲 eth2 完全體出現之後，他們就可以開始使用其它分片鏈
  • 不會在長期中導致共識複雜性翻倍
  • 快速離開 PoW
  • 更低的設計成本，因爲我們可以把我們首要關注的第一個執行環境放在 eth1.0 無狀態客戶端中
  • 同時，感興趣的團隊可以專注於用更好的設計打造相互競爭的執行環境，也許最終大多數活動都可以遷移到更好的執行環境中
  • 以及，最重要的是，eth1.0 以及上面的合約「看起來」就像 eth2.0 系統中的一等公民（譯者注：在軟件設計上指的是第一級的操作對象），而非二等公民。

Casey Detrio：

當你說「『這』不太 make sense」的時候，我不太清楚你的「這」指的是什麼。當然，問題本身「eth2.0 的分片鏈可以給現有的 eth1.0 合約帶來什麼幫助」當然是有意義的。我的意思是，這就是可用性橋接器本身試圖回答的問題，不是嗎？

所以，也許你的意思是迭代可用性橋接器的提議沒什麼意義？你似乎是在主張：把 eth1.0 鏈變成一個分片（或者一個執行環境）是一種更好的方法。有些 eth2.0 研究員懷疑這是不是真的可行，我還算樂觀的了。

另，你的第（4） 條指出「除了某些原因，每個信標鏈節點都必須驗證數據」，我不太清楚你在講什麼。我做了一個模糊而開發的建議：迭代可用性橋接器的理念。我沒有提議每個信標鏈節點都要驗證數據（不管這到底是什麼意思）。

不管怎麼說，你得承認，這裏面是一種敘事上的轉變。舊的故事是：「我們可能永遠都無法把 eth1.0 整合到 eth2.0 中。還是開始準備遷移所有合約吧，而且需要完全 重寫 / 重新設計 跨合約通信服務」。

而新的故事是：「我們可以在 Phase2 發佈之前給 eth1.0 做一個可用性橋接器。Phase2 發佈之後，一條可行的路是將 eth1.0 轉變爲 eth2.0 中的分片鏈 / 執行環境。」最終的遷移作爲一種遙遠的可能性一直都是擺在檯面上的，但它不再是主流敘事了。

我認爲可用性橋接器（及其迭代）是另一條可以結出碩果的路徑（而且與 eth1.0 的遷移並不互斥）。橋接器 1.0 及其迭代版本是否有用，或者是否不得不做出重大犧牲，是我想要討論的問題。

再說清楚一些，我所謂的「可用性橋接器」指的是 @VitalikButerin 提出過的「在 eth1.0 輕客戶端中實現 eth2.0」，而非我曾經寫過的「開發到 Phase1 就結束」，後者講到了可用性橋接器，但並沒有迭代它，而且就其自身而言只是一個 eth2.0 的提案。

來源鏈接：twitter.com