以太坊分片詳解

本次以太坊分片技術的分享,主要是基於V神在臺北作的一場關於分片的分享會。

若有指正,請聯繫微信:wuqiong_blockchain算法

爲了提升可擴展性,以太坊提出了兩個解決方案。一個是創建分層結構(Layer 2),把沒必要要的交易從最底層的主鏈分離到附屬結構上,比特幣的閃電網也是這個思路。另外一個即是分片技術(Sharding),着眼於改進主鏈自己的協議來提升它的性能。安全

分片技術概覽

在如今的以太坊中,每個節點都要處理全網的交易。這就使全網的性能極大地受制於單點的能力。而分片之因此可以處理更多的交易,是由於每一筆交易只由不一樣分片中這一小部分的節點看到和處理。這樣,全網中不一樣交易即可以由不一樣的分片中的節點在同一時間點上平行處理。這樣就大大提升了交易的處理效率。在這個模型當中,主鏈(Main chain)依舊不斷造成。同時,不一樣的分片(Shard chain)中也會造成屬於本分片的鏈,甚至,分片中還能夠二次分裂出新的分片鏈。每隔不固定的時間,分片會將當前的分片鏈上最新區塊的的Markel Root/collation header 同步到主鏈上。在最新公佈的算法中,每次只能同時分裂出最多100個分片。微信

V神所構想的分片技術有六個階段。當前所實現還只是第一階段。第一個也是最簡單的分片技術,就是把系統切分紅獨立的數據片。只是作了網絡的分片和交易的分片,並無真正實現狀態的分片。網絡

ETH分片理念設想

分片技術詳解

要了解一下有關分片技術的細節,首先咱們先來了解分片中幾個關鍵的角色。函數

Proposer

Proposer是交易池的維護者。負責爲proposal(collationheader)作準備而收集交易,並負責廣播collation body。任何人均可以成爲proposer。性能

Collator

Collator是由爲隨機函數選出的合法collator,其身份的合法性只在指定時間段和指定分片內有效。它的主要做用就是collates the
proposal以創建collation。Collator從全部分片的collator pool中選出。spa

Executor

Executor執行狀態交易函數。其實proposer也應該是executor,都是擁有獲取交易所花費gas和選擇高手續費的交易等能力的身份。code

Blobs & Chunks

blobs and chunks

collator區塊結構開發

collator區塊結構

下面給出一張圖,從宏觀上來解釋交易的執行流程:rem

宏觀流程

下圖,再從細節上解釋交易的流程,同時引入一個很是重要的額概念:

SMC(Sharding Manager Contract)

細節流程

SMC中包含隨機個collator pool,這些collator pool又分別來自於不一樣的分片中的當前時間段中最新的collator。

分片技術的安全性

以太坊主鏈每一個時間段新生成的區塊,都會將在此時間點以前的五個區塊打包在內。這也被成爲「LookAhead」。每一個validator都會藉由LookAhead來確認在將來他們將負責驗證的是哪一個分片。也就是驗證者是先得知會被劃分到哪一個分片的。在指定時間段內,每一個區塊的驗證者都會面臨新一輪的隨機選擇(共5個區塊,共五個validator)。當到達主鏈出塊時間,全部validator都會將已校驗的交易發送到交易池中。檢驗發起者須要向交驗者支付激勵。交驗者下載潛在的分片提案。驗證者驗證數據的有效性,並挑選當前分片中最新區塊,而後將collation header提交給主鏈。由礦工負責挖礦生成新的主鏈的區塊。

那分片技術是否可以預防攻擊呢?假如遭遇攻擊,惡意節點驗證錯誤的信息並提交主鏈挖礦。那麼錯誤的區塊就會在分片鏈中記錄下來。是否這樣的攻擊就已成定局了呢?

答案是否是的。

由於個區塊的交驗者都會面臨一次隨機重選。惡意節點不會每次都拿到打包權。那麼,當正直節點在惡意節點以後被選中,在驗證數據有效性時,就會察覺到有不可信信息,那麼他就會追溯到腐壞解區塊分片頭的上幾個區塊,將正確信息提交到主鏈並在此分片鏈上分叉。這次做惡也就失敗。

此處留一個問題,供你們思考:

若是該分片內的全部節點合謀做惡呢?
那麼是否還有可能發現並糾正錯誤信息?

(雖然咱們知道每一個申請做爲validator的人都會提交對應的質押,
惡意者自身利益與全網利益有互相關係的特色,
但仍假設做惡收益大於做惡懲罰呢?。。。)

簡介系統角色和模型

系統中主要有兩種角色。

一種是常規Executor,包括Executors和proposors。他們負責:
  • 旁觀指定的分片
  • 狀態變動
  • 均可能得到相應的交易手續費收益
一種是輕客戶,負責:
  • 驗證最新頭部
  • 旁觀指定分片

系統中主要有兩種狀態模式:

一種是有狀態

一種是無狀態

分片中的客戶端組件

分片客戶端組件

分片開發規劃

  • basic Sharding without EVM
  • EVM狀態轉換函數
  • 輕客戶端狀態協議
  • 跨分片交易
  • 與主鏈安全的緊耦合
  • 超二次分片
相關文章
相關標籤/搜索