ETH2.0：它會是什麼？（二）

前言：對很多以太坊投資者來說，ETH2.0都是模糊不清的，甚至對於很多開發者來說，它也不夠清晰。那麼，作為未來的以太坊替代品，ETH2.0的發展路線圖包括哪些內容？有哪些值得我們關注的地方？本文有一個簡要的敘述。本文作者James Prestwich，來源於hackernoon，由“藍狐筆記”公眾號社群的“Sien”翻譯。

接《ETH2.0:它會是什麼？（一）》

階段4 —— 分片合約

然而，一個不可逾越的問題依然存在：ETH2.0合約。儘管它們跟以太坊合約會一樣強大，但註定是一個分片，且永遠無法與另外一個分片的合約直接交互。這是分片的直接後果。分片的目標是在分片之間分離狀態，而不要求直接瞭解其他分片信息。

它通過分離狀態和最小化各驗證者的負載來實現擴展。直接交互需要直接獲取信息。根據設計，分片沒有其他分片的直接信息。它只通過與beacon鏈的交聯來獲得其他分片的信息。因此，每當我們想要跨分片交互，我們必須等待beacon鏈。具體來說，這意味著如果SafeMath部署在分片A，在分片B的用戶要麼不得不等待以訪問它，要麼直接在分片B上部署新的SafeMath。

像SafeMath這樣的簡單基礎程序將被部署到每個分片——1024分片上的1024個SafeMaths——但像Maker或Compound這樣的市場呢？#DeFi對可組合金融的承諾變得有挑戰，因為要跨越分片邊界。在CDP的開放和DAI的收據之間的長時間延遲會導致不可接受的經濟損失。萬一市場發生變動，在用戶收到DAI之前CDP就被清算了呢？實踐中，這可能意味著用戶將在每個包含引人注目的智能合約的分片上擁有賬戶，並且完全丟失跨分片組合。只有Maker和0x都部署在同一個分片上時，它們才能進行交互，並且0x用戶也在該分片上有資產。

基本權衡：同步或擴展

ETH2.0設計者並沒確定跨分片通信系統具體什麼樣。通過閱讀很多提案，它貌似在即時反饋和可預測性之間有一個根本的權衡。分片的本質不會改變：無論如此，用戶必須等待跨分片通信。然而，我們可以在每個分片上緊密或鬆散地耦合交易的本地或遠程執行階段。

緊耦合使得等待先行。在完成分片通信之後，交易才執行操作。相比之下，我們可以通過現在執行部分操作以及後續再執行部分操作的方式實現松耦合交易。交易首先在本地分片上執行，然後在跨分片通信之後在遠程分片上執行。松耦合為用戶提供更好的樣貌。他們立即看到他們的交易在本地執行，同時也知道在未來的某個時刻將會遠程執行。不幸的是，他們要想知道松耦合交易的遠程階段結果就必須等待。緊耦合交易更具有可預測性。用戶更瞭解結果，因為遠程狀態在本地和遠程執行階段之間沒有發生切換。但是，緊耦合需要用戶在看到任何結果之前等待。

關於ETH2.0的通信模型的信息很少。我們知道除非犧牲幾乎所有擴展的好處，不然無法提供跨分片合約調用。如果你在這裡停止了閱讀，我不會指責你，因為階段4只有思維導圖和一些模糊的鏈接。

這種情況的一個非顯而易見的結果是，在階段4之前，ETH2.0將不會為複雜的智能合約系統提供重大的擴展好處。在此之前，如合約希望與其他合約交互則必須在一個分片內，且受制於該分片的速度和規模。

與ETH1.X相比，我們預計分片最多隻能獲得一個小的常數因子加速。這意味著，在階段4發佈之前，沒什麼理由遷移智能合約代碼或用戶，也就是可能在2020年中期之前，因為沒多大優勢。

與此同時，為了更好理解為工程師和DApp用戶做的權衡，我研究了一些提案的模型，在這裡也有一些簡短描述。我認為這些都不會被採用，但我相信它們對理解所涉及的權衡有幫助。再說一遍：下面說的一切都是預測。

基本模型：收據和證明

所有形式的跨鏈通信都利用了beacon鏈。因為beacon鏈提交所有分片的狀態，每個分片提交到beacon鏈的狀態，我們可以把它當作是分片鏈生態系統中的樞紐。一條鏈的信息轉入另外一條鏈，在某種意義上，必須通過beacon鏈進行。我們不想發送全部信息，因為這要求beacon鏈處理每個交易本身，會完全否定擴展的好處。

相反，不管什麼時候，分片A上的用戶或合約想與分片B的用戶或合約進行交互，我們讓分片A生成有該消息的“收據”。分片A提交其所有“收據”到區塊頭。beacon鏈等待分片A的完成，之後提交到分片A的區塊頭（包括對收據的承諾）。分片B必須等待beacon鏈完成最終性，然後提交到beacon區塊頭。一旦這些完成，新的交易就能提交到分片B，包括收據和證明。證明顯示該收據已經在包含在分片A中，A也包含在beacon中，該beacon也包含在B中。通過這樣的方式，在分片B上的合約可以相信從分片A發過來的消息。如果在分片B上的合約想發送回覆（可能是返回值或錯誤），我們反過來把過程重複一遍：分片B發出收據，最終回到分片A。

很容易理解為什麼這個過程需要耗費時間。四個通信步驟中的每一步都需要等待幾分鐘才能完成。不幸的是，我們無法完全避免等待。如果我們想確認遠程狀態，我們不得不等待每一步的最終結果。往返通信的最好情況是四個完成周期。也就是說，在三個週期之後，用戶獲得信心，因為用戶可以在分片A看到之前看到分片B的收據。用ETH2.0的6.4分鐘時間週期長度，用戶必須等待19分鐘才能看到結果，且需要等待26分鐘才能獲得鏈上的結果。

具體的收據：分片間的代幣轉移

ERC20代幣的多樣性讓如今的以太坊無處不在。然而，ETH2.0給代幣帶來一些邏輯問題。因為智能合約管理所有代幣餘額，並且智能合約只在單個分片上，在分片A上的代幣並不存在分片B上。不過，用一些聰明的跨分片通信，我們可以在幾個分片上部署相同代幣，允許在分片之間進行代幣轉移——有效地實現代幣合約之間的雙向錨定。

這個方案非常簡單：當部署我們代幣時（稱為Cool Cross-shard Token或CCT），我們將使用ERC20添加兩個小的附件功能：migrateSend和migrateReceive函數。我們將使用migrateSend燃燒代幣，併產生收據。收據將包含被燒掉代幣的數量以及接收的分片。我們將使用migrateReceive驗證收據，且鑄造相同數量的CCT。然後，我們將在每個分片上部署相同的代幣合約。

現在，我們可以有效地在一個分片上發起migrateSend請求燒燬，然後發起migrateReceive請求在另外一個分片上鑄造相同代幣，以此實現分片之間的代幣轉移。我們需要在每個分片上重新部署我們的代幣合約。但這似乎是值得的。轉移代幣，是單向的，至少需要兩個跨分片通信的完成時期。因此，在我們調用migrateSend之後，在我們的CCT在接收分片可用之前還需要花費大約10分鐘。

Yanking

收據是跨分片之間移動信息的一般方式。我們可以在收據上放置任何鏈上信息。這包括整個智能合約。通過在收據中包含合約代碼和存儲的方式，Yanking是一種跨分片轉移合約的提案。合約將從分片A中刪除，然後在收據抵達之後在分片B上重新部署。一旦在分片B部署，它可以直接與分片B的合約進行通信，並與分片B的狀態進行交互。它甚至能夠被拉回分片A。

這將允許任何智能合約跟其他智能合約進行通信（在跨分片等待時間之後）。不幸的是，因為收據包含整個合約和其所有存儲，它移動大的或流行的合約成本很高。並且，在收據轉移過程中，合約是完全不可使用的。它已經從分片A中抽出但還沒有抵達分片B。這意味著所有其他用戶在抵達分片B之前都被鎖定在該合約之外。即便這樣，只有已經在分片B上的用戶才能與之交互。因此，yanking最適合用戶少的小合約。它使緊耦合執行變得可能，但遠非一般解決方案。

分片配對

從這裡，我們轉向更多異國風情的解釋。收據設計的目的在於讓異步（松耦合）通信成為可能。但是，我們也可能需要同步通信。為此，我們必須更有創意。分片配對是一個簡單設計，可以讓我們緊耦合執行最小的事情。

分片配對是簡單的方案。在文中第三段描述中，我們在每個高度將分片洗牌成同步對。每次一個分片跟另一個分片配對，任一分片的用戶都可以跨越分片執行緊耦合狀態更新。這意味著，如果分片A和B在區塊高度7配對，所有分片A和B的驗證者必須知道分片A和B的所有狀態，且配對的分片必須同進退。

在這個模型中，如果你需要A和B之間進行跨鏈交易，你將要等待A和B的隨機配對。Vitalik描述了100個分片案例。有1024個分片，我們預計它花費512個區塊——大概1個小時時間——但由於配對是隨機但，它可能花費更長或更短的時間。正如Vitalik所說，當你想要與多個分片交互時，它的擴展性很差。

分片區

這是配對方案的更廣泛的版本。每個週期我們把分片分配進入一些“區域”，每個區域由多個分片組成。區域必須同步處理，這意味著一個區的所有分片一起更新他們的本地狀態。通過同步進行，區域在分片之間提供自由移動，並可與區域內任何合約直接交互。但，與區域外的任何分片進行通信沒有任何優勢。此外，由於區域要求驗證者瞭解區域內所有分片的狀態，因此，它們犧牲了分片中的很多擴展優勢。如果一個區域由16個分片組成，我們犧牲了大約15/16（94%）的擴展優勢，儘管贏得了只有15/1024（總網絡的1%）的緊耦合執行。

Encumbrances

跨分片（和跨鏈）通信的一個非顯而易見的特性是用戶比所涉及的鏈更快地獲得對消息的信任。從分片A發送5BETH到分片B，Alice知道它會在發送後立即到達。Bob看到發送則知道，BETH只要發送在分片A上完成，它會立即抵達分片B。然而，分片B和它的合約，必須等待幾分鐘，等待beacon鏈在分片A的完成上達成最終性。這意味著，複雜的樂觀錢包只要它們在分片A上花費，則可以在分片B上接收和發送資金。換言之，Bob將從Alice在分片B上的錢包獲得可執行的IOU，因為Bob非常相信Alice已經發送足夠的ETH來覆蓋它。

如果分片B上有足夠用戶希望觀察分片A，並接受標準化的IOU，那麼，分片A的ETH可能在發送後很快就可以在分片B上消費。然而，當應用於智能合約時，這個機制變得異常複雜，因為狀態永遠不可替換，對狀態的IOU幾乎是不可能的，因此它不適合一般的交互。

這意味著我們應該在松耦合中將encumbrances視為用戶體驗改進。它允許松耦合模擬緊耦合，以快速執行某些交易。

分離共識和狀態

其中一個更復雜和具有智力刺激的可能性是共識過程將從狀態更新過程中分離。如今，以太坊礦工和全節點僅在執行包含在區塊中的所有狀態更新之後才接受區塊。並不是非得要這樣。相反，他們可以先接受區塊，但稍後再更新狀態。在這種情況下，與其像以太坊那樣就係統狀態達成共識，不如就跨分片的交易總歷史（或者“總順序”）達成共識。

這樣做意味著每個分片能夠快速增加區塊，而無需瞭解其他任何分片的狀態，這就是分片如何產生擴展優勢。然而，在所有分片達成最終確定之前，還無法知道交易對分片狀態和整體網絡的影響。換句話說，狀態的最終確定延後於分片內容的最終確定。

從一個用戶的視角：我們會立即提交交易，且我們知道它們已被包括進去，但我們必須等待該交易結果的確定。隨著分片的最終確定，我們逐漸獲得更多狀態相關的信息，但無法完全肯定，直到所有分片都達成最終性。類似於encumbrances，用戶可能在某些情況下先於鏈確定交易結果，並採取行動。

結論和工程方向

ETH2.0是跟以太坊完全不同的系統。它們將並行多年，且有非常不同的功能。在不久的將來，預計會有一個從ETH到BETH的單向錨定。如果你運行交易所或託管服務，考慮一下，在它可進行鏈上轉賬之前，你如何能為用戶提供支持BETH託管交易和權益服務。

從長遠看，可以考慮你的智能合約如何適應分片，它們可能有，也可能沒有跨分片通信。最重要的是，密切關注研究和研發進程。ETH2.0是複雜且進化的系統。所有DApp工程師需要對ETH2.0計劃和進展有清晰理解。

------

風險警示：藍狐筆記所有文章都不構成投資推薦，

通往區塊鏈的新世界：關注“藍狐筆記”區塊鏈公眾號：lanhubiji

或加入藍狐筆記的知識星球：https://t.zsxq.com/iaQNnIq

閱讀更多 藍狐筆記 的文章

關鍵字: 工程師 分片 開發者