在現有的可擴充套件性解決方案中，切分可能是支援水平可擴充套件性的最常用解決方案。切分的基本思想是將一個全域性系統狀態劃分為多個子狀態，並相對獨立地處理每個切分中的交易。透過分片技術的適當設計，系統的容量能夠隨著切分和處理器(節點)數量的增加而增加，換句話說，即線性規模。要應用分片，我們需要回答幾個關鍵問題：系統的全域性狀態是什麼?如何更改系統狀態?例如，在分散式鍵值（KV）儲存中（例如，BigTable、Cassandra），系統狀態是從任意位元組（鍵）到任意位元組（值）的對映，而更改系統狀態的操作是：建立、讀取、更新和刪除（CRUD）。

另一個例子是分散式只追加檔案系統（例如，Google檔案系統）。(GFS),Hadoop分散式檔案系統(HDFS)),如果系統狀態是一組目錄和檔案，並且操作是兩組：在目錄中建立、刪除和列表操作，以及開啟、追加、讀取和關閉檔案的操作。如何將系統狀態劃分為碎片，以便所有操作都能得到正確有效的處理？分割槽的方式對系統的效能是至關重要的，如果分割槽的設計不合適，那麼系統的效能會很差。要設計分割槽，我們需要考慮以下幾個關鍵方面：· 狀態到分割槽：系統狀態的哪些部分應該分割槽？為了簡化系統模型，我們應該只劃分系統狀態的部分:1)太大而不能在一個節點中;或者2)要求較高的每秒操作，而我們可能不會對系統狀態中大小小到足以在單機上執行且操作不頻繁的部分進行分割槽。例如，早期版本的GFS/HDFS只分割槽檔案中的資料，而不分割槽目錄，因為目錄的資料大小相對較小（與檔案中的資料相比），而且目錄操作也很少。· 確保操作（交易）語義：如何劃分系統狀態以滿足操作語義？一個關鍵的語義是原子性，如果一個操作以原子性的方式改變多個碎片中的狀態，這樣的操作需要在碎片之間進行適當的協調（例如，透過分散式鎖），這可能是昂貴的。因此，這種操作的效能很難從分片技術中獲益。——有時表現甚至更糟。為了避免這樣的問題，大多數現代的分片系統都支援在一個分片中進行原子批處理操作，並讓上層應用程式處理複雜的多分片原子性問題。· 平衡負載/大小：如何劃分系統狀態， a），所有碎片的負載在統計上均勻分佈；b），分割槽系統狀態的大小也統計均勻地分佈在所有碎片上。實現這些是線性標度的關鍵前提。只要在新增更多的碎片後負載/大小均勻分佈，我們就能夠透過新增更多節點來處理新的碎片來線性地增加系統容量。請注意，這些發行版與使用者操作模式高度相關，如果使用者操作模式隨時間變化很大，可能會導致負載不均勻（暫時或永久）。

· 重新切分：如何新增更多的碎片，以及新節點如何能夠為新碎片服務。新增更多的碎片後，新碎片將由舊碎片中的一些狀態組成，這些狀態將遷移到新節點。在重新格式化期間的遷移可能需要時間並暫停現有的服務。此外，我們還需要確保所支援的操作在重塑之前和之後的語義相同。在回答上述關於夸克鏈的問題之前，讓我們先介紹現有區塊鏈的系統模型和分片的難點。現有區塊鏈的系統狀態和交易我們考慮一個基於賬戶的區塊鏈模型，類似於以太坊，其中系統狀態基本上是一個從地址到賬戶資料的鍵值對映。地址有兩種型別：· 使用者地址；及· 智慧合約地址；

賬戶資料包括· 平衡；· 臨時措施；· 程式碼；· 儲存；其中使用者地址的程式碼和儲存為空。

CRUD操作的不同組合支援兩種型別的交易：1、兩個使用者地址之間的轉賬交易，主要是更新兩個地址的餘額和傳送方的暫存；2、只能合同交易，它可以· 更新發件人的名稱；· 更新多個使用者地址的餘額；· 透過呼叫和委託更新多個智慧契約的餘額和儲存；

· 建立多個使用者地址及其帳戶資料；· 建立多個智慧契約。區塊鏈分片中的挑戰與現有的可擴充套件性解決方案相比，區塊鏈切分帶來的挑戰是，區塊鏈的系統狀態與BigTable和Cassandra等分散式KV儲存完全相同；然而，壞訊息是，交易語義比簡單的CRUD操作複雜得多--智慧契約交易可能對系統狀態的任何鍵值對執行任何CRUD操作。如果將狀態劃分為不同的子狀態(碎片)，則要確保跨多個碎片的原子性將非常困難(大多數情況下是不可能的)。如何分割區塊鏈分類帳是區塊鏈分片的根本問題。此外，去中心化的世介面臨更多挑戰，因為我們需要建立適當的共識，以安全的方式處理所有碎片中的交易。新的切分共識開啟了新的攻擊可能性，因此如果沒有對執行緒模型的全面分析，切分可能很容易被破壞，因此整個網路很容易被破壞。除了分割槽和共識的挑戰之外，切分的另一個常見問題是切分之間的互操作性，即跨切分交易。底層的邏輯是可用性——使用者應該能夠訪問所有資源，包括智慧合約和跨所有分片的其他使用者帳戶。如何開發高效、安全的跨切分交易是一個關鍵問題。

在接下來的文章中，我們將討論夸克鏈在區塊鏈切分方面的解決方案。此外，我們將比較夸克鏈與現有的集中式系統，如谷歌的BigTable，並說明其與集中式系統的異同。