原文作者：Beam
原文作者：Beam
圖片描述
圖片描述
一級標題
一級標題
一級標題
一、關於“分片”
簡單來說，考慮不可能三角的製約，從以太坊作為坐標係原點（0,0）出發，按照“縱向” 和“橫向” 兩種思路，我們將當前的區塊鏈的擴展性方法分為兩大類：
縱向擴容（Vertical Scaling）：通過提高系統現有硬件的性能來實現。建立一個去中心化網絡，而網絡中的每個節點都具有超級計算能力，即每個節點都需要“更好”的硬件— — 這種方式簡單有效，可以達成吞吐量的初步改進，尤其適用於高頻交易、遊戲以及其他對延遲比較敏感的應用場景。然而這種擴容方式會限製網絡的去中心化水平，因為運行驗證節點或全節點的成本變高了。維持去中心化水平受限於計算硬件性能的大致增長速度（這就是所謂的“摩爾定律”：芯片上的晶體管數量每兩年會翻一倍，計算成本則會減半）。
橫向擴容（Horizontal Scaling）：橫向擴容一般有幾種思路。一種是在區塊鏈的語境下，將某一生態中的交易計算量分散到多個獨立的區塊鏈上，每條鏈都擁有自己的區塊生產者和執行能力，這種方式可以充分定制化每條鏈的執行層，比如節點硬件要求、隱私功能、gas 費用、虛擬機以及許可設置等。另一種橫向擴容方案是模塊化區塊鏈，將區塊鏈的基礎架構劃分成執行層、數據可用性層（DA）以及共識層。最主流的區塊鏈模塊化機制就是rollup。還有一種是將一條區塊鏈分成很多片，並行執行。每個分片可以看成一個區塊鏈，也就是說許多區塊鏈可以並行執行。另外，通常還會有一條主鏈，其唯一的任務就是保持所有分片同步。
需要指出的是，以上的擴容思路都不是孤立存在的，每一種解決方案都是在不可能三角中找到一個權衡點，配合系統中經濟力量創造的激勵機制設計，達到宏觀和微觀層面的有效平衡。
為了討論“分片”，我們需要從頭開始梳理。
依然假設這樣一種情景，Walmart 購物結賬，為了提高結賬效率，降低客戶等待時間，我們從單一的結賬通道，擴展到10 個結賬窗口，為了避免賬本錯誤，這個時候我們需要製定統一的規則：
第一，如果我們有10 個收銀員，該如何分配他們去哪個窗口工作？
第二，如果我們有1000 個客戶排隊等待，該如何決定每一個客戶去哪個窗口結賬？
第三，這10 個窗口對應的10 個單獨賬本，該如何進行匯總？
第四，為了避免發生賬目不匹配的情況，該如何防止收銀員出現錯誤？
這幾個問題其實對應了分片中的幾個關鍵問題，分別是：
該如何確定全網的節點/ 驗證者屬於哪個分片？即：如何進行網絡分片（NetworkSharding）；
二級標題
二級標題
二級標題
01 網絡分片（Network Sharding）
圖片描述
圖片描述
圖片描述
圖片描述
圖片描述
二級標題
二級標題
02 交易分片（Transaction Sharding）
02 交易分片（Transaction Sharding）
圖片描述
圖片描述
圖片描述
二級標題
二級標題
二級標題
03 狀態分片（State Sharding）
狀態分片指的是，在區塊鏈資料是如何分配在不同分片中儲存的。
依舊沿用我們Walmart 排隊的例子，每個窗口都有一筆賬，他們的賬本是如何記錄的？如果：客戶來排哪個隊，就記哪個賬，比如A 客戶去了A 窗口，那第二天該客戶去了別的結賬窗口比如B 窗口，而B 窗口並沒有該客戶的過往賬戶信息（比如涉及到了儲值卡等結賬方式），該怎麼辦？向A 窗口調用該客戶的賬戶信息？
狀態分片是分片最大的難題，比上述的網絡分片和交易分片更棘手。因為在分片機制下，交易會根據地址分配在不同的分片處理，也就是說，狀態只會儲存在其地址所在的分片中，此時要面臨的一個問題是，交易不會只在一個分片中進行，時常會涉及到跨分片（Cross-Sharding）。
考慮一種轉賬情形，A 賬戶轉賬10U 給B 賬戶，而A 的地址分配在分片1，交易的紀錄也會儲存在分片1。 B 的地址分配在分片2，交易的紀錄就會儲存在分片2。
一但A 要轉賬給B，就會形成跨分片交易，分片2 就會向分片1 調用過去的交易紀錄，確認交易的有效性，如果A 頻繁地打幣給B，分片2 就必須不斷跟分片1 互動，交易的處理效率便會因此降低。但是，如果不下載和驗證特定分片的整個歷史，參與者則不一定能確定他們之間交互的狀態是某些有效塊序列的結果，且這樣的塊序列確實是分片中的規範鏈。
因此，相比於無分片的單一鏈，分片系統面臨的新挑戰是用戶無法直接完全驗證任何給定鏈的有效性和可用性，因為數據太多。必須為用戶提供最大限度的去信任和實用的間接方法來驗證哪條鍊是完全可用且有效，以便於他們可確定哪條鍊是規範鏈。在實踐中，區塊鏈開發者可以使用如下技術解決驗證中的一些問題：如委員會、SNARKs/STARKs、漁夫機制、以及欺詐和數據可用性證明等。
一級標題
一級標題
一級標題
二、分片的探索與嘗試
我們回顧一下以上有關於分片的討論時，提到的一些關鍵性問題：
二級標題
二級標題
二級標題
01 計算分片
Zilliqa 是最早嘗試分⽚的智能合約平台之⼀，是分片技術的一種很有益也很有效的嘗試。
其成立於2017 年，由與新加坡國立大學相關的專門研究人員和學者組成的團隊推動，主要目標是解決可擴展性問題，專為計算密集型任務而構建。 Zilliqa 網絡能夠通過稱為計算分片的並行化過程，在其網絡上處理高吞吐量的交易。在分片式區塊鍊網絡上，計算交易的任務分佈在網絡的各個分片上。
從分片過程來說，Zilliqa 將其分為兩部分。首先，選擇目錄服務（DS）委員會節點，然後啟動分片過程並將節點分配給每個分片。一旦在分片中驗證了交易，便可以通過整個網絡對其進行驗證，並進入一個全局狀態，該狀態將所有分片中的交易組合到Zilliqa 區塊鏈上的單個可驗證真相來源。
簡單來說，對於區塊鏈中的節點具有的三個主要功能：
- 處理交易
二級標題
二級標題
二級標題
02 靜態狀態分片
更為通用的分片方法是將帳戶的地址空間劃分為多個稱為分片的固定大小區域，並將網絡中的節點分配給不同的分片。這稱為狀態分片。 Near、Elrond 和Harmony 等平台正在採用這種方法。儘管以太坊最初計劃實施狀態分片，但新方法僅對數據進行分片以增加可訪問性。
2.1 以太坊的數據分片構想
在以太坊環境中，分片將通過分擔處理整個網絡上匯總所需的大量數據的負擔，與Layer2 協同工作。這將繼續減少網絡擁塞並增加每秒交易量。
應該指出的是，隨著更有效的擴展路徑的開發，以太坊的分片計劃也在不斷發展。以太坊對於未來分片構想其中一個方案版本是基於“數據可用性” 的分片，“Danksharding” 是一種新的分片方法，它不使用分片“Chain” 的概念，而是使用分片“ Blob ”來分割數據，同時使用“數據可用性抽樣” 來確認所有數據是否可用。
2.2 Harmony
而另一種方案版本涉及到在方案一的基礎上，為每個分片添加額外的功能，使每一個分片更像今天的以太坊主網，允許分片存儲和執行代碼並處理交易，因為每個分片都將包含其獨特的智能合約和賬戶餘額集，跨分片通信將允許分片之間的交易。然而這種方案還在社區辯論中，因為方案一的數據可用性加上Layer2 的協同，已經可以為以太坊提供足夠的可拓展性，因此社區還在評估版本二的經濟成本與收益價值。
Harmony 是一個基於PoS 的分片網絡，採用了一種更為標準的分片方法，這種方法的想法是擁有多個稱為分片的小型區塊鏈，每個分片負責狀態的一部分，以及一個協調它們的區塊鏈，在Harmony 中稱為信標鏈。我們按照之前的討論，先看看Harmony 是如何從下到上解決網絡分片、交易分片和狀態分片的問題。
網絡分片：Harmony 將驗證者網絡分為不同分片，每個分片都包含一組不同的驗證器，它們彼此緊密相連，在它們之間運行共識。
交易分片：Harmony 的交易由單個分片處理和處理。這使得分片能夠同時處理交易，提高了區塊鏈的總交易容量。對於交易，用戶只需在簽名交易中指定shard_id字段，表示交易所屬的分片。
狀態分片：在Harmony 中，每個分片的驗證者都需要存儲1/N 的全局狀態，因為他們維護自己的區塊鍊和狀態數據庫（N= 分片數）。這減輕了驗證者對數據可用性的擔憂。此外，交叉分片進一步提高了分片之間的狀態一致性。
Harmony 主網支持多個分片中的數千個節點，在幾秒鐘內生成具有即時確定性的塊。通過質押機制的安排減少了中心化，同時支持質押委託、獎勵複合和雙簽削減。採用了EPoS (Effective Proof-of-Stake) 的有效抵押機制和安全的隨機分片技術(Random Sharding)，靠協議的規定把大戶抵押的代幣打散成許多細小的部分，並隨機分配到多個分片裡，這樣任何人就無法把他抵押的代幣集中到單一分片內，從而無法攻擊單一分片。
而關於跨分片，在跨分片交易和信標鏈同步的情況下，來自不同分片的驗證者通過全球連接的網絡跨分片發送消息。根據Harmony 官方文檔，採用了「Kademlia 跨片路由技術」，來控制跨片間通信的網絡開銷，並且利用「糾刪碼」對區塊廣播過程進行優化，使廣播者的網絡壓力更小，避免發送者的網絡瓶頸問題，從而實現高效的橫向分片擴展。已經裝備自己成為第一個完成跨分片消息傳遞的分片區塊鏈。借助有效的跨分片消息傳遞協議和全網狀設計，分片之間將能夠進行無縫通信，隨著團隊積極朝著這個目標努力，用戶和開發人員可以期待今年晚些時候在Harmony上的跨分片消息傳遞協議。
2.3 Elrond
對於Harmony 上的構建者和開發者來說，這是一個重大突破，因為他們可以通過整理特性和使用駐留在不同分片上的數據來構建。此外，分片間數據的一致性也很重要。這兩種追求將決定這種無限可擴展性的可持續性。
Elrond 是一個高吞吐量的公共區塊鏈，旨在提供安全性、效率、可擴展性和互操作性。使Elrond 與眾不同的兩個最重要的特性是自適應狀態分片和安全的權益證明共識機制。
對於交易、數據和網絡，Elrond 採用所有級別的自適應狀態分片。動態自適應分片機制將執行分片合併和分片拆分，同時考慮可用驗證節點的數量和網絡使用情況。由於跨分片的定期節點改組，對惡意攻擊保持高彈性。每個epoch，每個分片中最多1/3 的節點被重新洗牌到其他分片，以防止串通。在隨機性方面，使用BLS 簽名保護隨機源，這使其無偏見和不可預測。
而對於分片狀態架構上的智能合約採用跨分片執行過程處理，分片負載均衡。跨分片平衡智能合約允許Elrond 並行運行多個智能合約。
同時，對於跨分片，Elrond 採用他們稱為元鏈（Meta Chain）的設計，可以做到在幾秒鐘內快速確定跨分片交易（Finality）。通過研究其技術白皮書，我們簡化其過程如下：假定Elrond 網絡僅有兩個分片和元鏈。假設用戶從他的錢包中生成一筆交易，該錢包的地址位於分片0，並希望將EGLD 發送給另一個錢包地址位於分片1的用戶，則需要下圖所示的步驟來處理跨分片交易。
塊的結構由包含有關塊的信息（塊隨機數、輪次、提議者、驗證者時間戳等）的塊頭表示，以及包含內部實際交易的每個分片的小塊（miniblock）列表。在我們的例子中，對於分片0 中的一個塊，通常會有3 個小塊（miniblock）：
miniblock 0：包含分片0 的分片內交易
miniblock 1：包含與分片0 中的發送者和分片1 中的目的地的跨分片交易
miniblock 2：包含跨分片交易，發件人在分片1，目的地在分片0。這些交易已經在發件人分片1 中處理，將在當前分片處理後完成。
一個塊中具有相同發送者和接收者的小塊的數量沒有限制。這意味著具有相同發送者和接收者的多個小塊（miniblock）可以出現在同一個塊中。在這個過程中，跨分片執行的原子處理單元是一個小塊（miniblock）：要么立即處理小塊（miniblock）的所有事務，要么不處理，小塊（miniblock）的執行將在下一輪重試。
圖片描述
圖片描述
圖片描述
2.4 Near
圖片描述
圖片描述
圖片描述
圖6 Near 放棄了信標鏈的做法，採用了Nightshade 的設計
Nightshade 將系統建模為單個區塊鏈，其中每個塊在邏輯上包含所有分片的所有事務，並更改所有分片的整體狀態。在物理上，沒有參與者下載完整狀態或完整邏輯塊。相反，網絡的每個參與者只維護與他們驗證交易的分片相對應的狀態，並且塊（Block）中所有交易的列表被分成物理塊（Chunk），每個分片一個塊。
在理想條件下，每個塊每個塊的每個分片恰好包含一個塊，這大致對應於具有分片鏈的模型，其中分片鏈以與信標鏈相同的速度生成塊。然而，由於網絡延遲，一些塊可能會丟失，因此實際上每個塊的每個分片都包含一個或零個塊。
正文
圖片描述
一級標題
正文
正文
正文
正文
二級標題
二級標題
二級標題
二級標題
二級標題
二級標題
3.2 Shardeum 與線性擴展
要解釋什麼叫線性擴展，我們需要想像下面一種情形：
Near 主⽹ 1 個100 個節點的分⽚。預計將來會添加更多分⽚。 Harmony 有4 個分片，每個分片250 個節點，主網共1000 個節點。所有的合約在同一個分片。 Elrond 有3 個分片與1 個元鏈，每個分片800 個節點，主網共3200 個節點。
如果在Harmony 中添加100 個節點，不足一個分片中需要的250 個節點，Harmony 該如何處理這部分節點？是否可以考慮將這共1100 個節點分成11 個分片，每片100 個節點？
聽起來更美好，但是由於某些分片的靜態特性，許多額外的節點需要加入網絡才能創建新的分片。假如，我們要向上述網絡中加入一些節點，如果只增加1 個單獨的節點，是無法提高整個區塊的表現的，至少要為目前“最小分片大小” 數量的節點（在Near 中即為100 個節點） — — 因為目前的分片都是靜態分片，不支持線性擴展，還沒有生產網絡實際能做到靜態分片的拆分和合併。
圖片描述
圖片描述
一級標題
一級標題
一級標題
正文
一級標題
Reference
1.https://blog.chain.link/blockchain-scalability-approaches-zh/
2.https://www.odaily.news/post/5147856
3.https://docs.near.org/concepts/basics/transactions/overview
4.https://medium.com/nearprotocol/the-authoritative-guide-to-blockchain-sharding-part-1-1b53ed31e060
5.https://medium.com/nearprotocol/unsolved-problems-in-blockchain-sharding-2327d6517f43
6.https://medium.com/nearprotocol/why-doesnt-near-just-replicate-ethereum-serenity-design-3e2cfa2f960c
7.https://ethereum.org/en/upgrades/sharding/#what-is-sharding
8.https://blog.ethereum.org/2020/03/27/sharding-consensus
9.https://www.web3.university/article/ethereum-sharding-an-introduction-to-blockchain-sharding
10.https://medium.com/harmony-one/enabling-cross-shard-communication-at-harmony-22f26483d0d1
11.https://en.elrondwiki.com/article/multi-shard-the-answers-to-certain-questions
12.https://docs.elrond.com/technology/cross-shard-transactions/
13.https://near.org/papers/nightshade/
14.https://shardus.com/whitepaper.pdf
正文
正文
推特｜@JSquare_co
