在 Ethereum 和 Swarm 中，Sharding 和 Chunking 的區別
了解在乙太坊進一步發布的版本中，出於可擴展性目的，分片將被包括在內。在 swarm 中，“塊是有限大小（最大 4K）的數據片段，是 Swarm 中儲存和檢索的基本單位”
儘管在不同的上下文中，一個用於乙太坊狀態，另一個用於文件，但分塊和分片在概念上不一樣嗎？即，拆分文件
那麼分塊和分片之間是否存在細微差別？
http://swarm-guide.readthedocs.io/en/latest/architecture.html https://github.com/ethereum/wiki/wiki/Releases
在非常高的級別上，分塊是在文件級別，分片是在數據庫級別。
假設您有一個 20KB 的大文件，那麼您需要將其分成五塊。
分片是不是每個人都需要知道一切的概念。例如，假設您有一個相當於電話簿的數據庫。該數據庫由五台電腦維護。因此，您可以在所有五台電腦上複製該數據庫，但這意味著您擁有五次相同的資訊。相反，您可以拆分數據庫，以便不是每台電腦都需要保存所有資訊。所以電腦 A 儲存來自 AD 的名稱，電腦 B 儲存 DG 等。請注意，拆分不一定是互斥的，例如，您可以擁有一組 100 個最常查詢的名稱，並在所有五台電腦上複製這些名稱（或“碎片”）以獲得更好的查詢時間。
希望這會有所幫助。
為了擴展@wtk219 的答案，維護網路的安全性，例如在數據的可用性和有效性方面，還有其他設計考慮因素。
分片區塊鏈的基本設計可能是什麼樣的？
一個簡單的方法如下。為簡單起見，此設計僅跟踪數據塊；它不會嘗試處理狀態轉換函式。
存在稱為提議者的節點，它們接受分片上的 blob
k（取決於協議，提議者選擇哪個k或隨機分配一些k）並創建排序規則，因此它們也充當整理者，因此充當提議者和整理者的代理可以被稱為prolators。排序規則有一個 排序規則標頭，一條短消息，格式為“這是碎片上的 blobk排序規則，父排序規則是 0x7f1e74，blob 的 Merkle 根是 0x3f98ea”。每個分片的整理形成一條鏈，就像傳統區塊鏈中的塊一樣。還有一些公證人下載（以確保可用性）並驗證（通過執行數據以確保有效性）分片中的排序規則它們是隨機分配的，並且每個週期通過隨機信標鏈將它們洗牌到新的分片（使用一些可驗證的隨機函式，例如由 BLS 聚合簽名或 RANDAO 生成的塊雜湊，儘管後者已經過測試容易被操縱），並在排序規則中對數據的可用性進行投票（假設沒有 EVM，使用 EVM 他們也可能充當執行者並對數據的有效性進行投票）。
然後，委員會還可以檢查這些來自公證人的投票，並決定是否在主鏈中包含排序規則頭，從而建立與分片中排序規則的交叉連結。其他各方可能會質疑委員會、公證人、提議者、驗證者（使用 Casper Proof of Stake）等，例如通過互動式驗證遊戲或通過驗證有效性證明。
一條由所有人處理的“主鏈”仍然存在，但這條主鏈的作用僅限於儲存所有分片的排序規則頭。分片的“規範鏈”是分片
k上最長的有效排序規則k鏈，其所有標頭都在規範主鏈內。請注意，現在在這樣的系統中可以存在幾個“級別”的節點：
- 超全節點- 完全下載每個分片的每個排序規則，以及主鏈，完全驗證一切。
- 頂級節點——處理所有主鏈區塊，讓它們“輕客戶端”訪問所有分片。
- 單分片節點- 充當頂級節點，但也完全下載並驗證它更關心的某個特定分片上的每個排序規則。
- 輕節點——僅下載和驗證主鏈區塊的區塊頭；不處理任何排序規則頭或事務，除非它需要讀取某個特定分片狀態下的某些特定條目，在這種情況下，它將 Merkle 分支下載到該分片的最新排序規則頭，並從那裡下載 Merkle 證明狀態中的期望值。
有關截至 2018 年 8 月 13 日的最新規範，請參閱https://notes.ethereum.org/SCIg8AH5SA-O4C1G1LYZHQ#。