IPFS 去中心化資料結構（一）
本文翻譯自 IPFS 社群教程ProtoSchool 。ProtoSchool 是一個可以互動式學習 IPFS 程式設計的網站，涉及程式碼的部分大家可到該網站上直接執行測試！
去中心化的（Decentralized） Web 依賴於其獨特的資料結構以及連結策略。讓我們來一起學習一下雜湊（hashing）、內容定址（content addressing）、有向無環圖（DAG） 以及默克爾樹（Merkle Trees）！
LESSION 1 - 資料結構
在進入具體程式碼之前，讓我們先花點時間看看去中心化 Web 的概念。課程 1 暫時不會涉及程式碼，讓你可以可以更快熟悉一些關鍵術語和概念。
讓我們開始吧！
資料結構
無論你是否是程式設計師，你每天都被資料結構所包圍。列表、詞典和目錄都有助於我們組織資訊並考慮各種資料之間的關係。
在電腦科學中，資料結構是一種資料組織，管理和儲存格式，可以實現高效的訪問和修改。 更確切地說，資料結構是資料值的集合，描述它們之間的關係，以及可以應用於資料的功能或操作。
在程式設計中，資料結構無處不在。將資料組織成變數以便在程式中使用它們的方式涉及數十到數百萬個數據結構。如果你是開發人員，你可能熟悉常見的資料結構，如陣列、物件，圖等。
去中心化的資料結構
在去中心化的的 Web 上，我們是從對等節點（Peers）而不是某個中央節點訪問資料，所以我們需要專門的一些資料結構，來讓我們驗證和連結各種各樣的資料。
去中心化系統中的資料結構必須是可驗證的 。在單一系統上，你會比較信任你機器記憶體或磁碟上使用的資料結構。但在去中心化的系統中，對等節點的信任度較低，甚至可能為零。
此外，大型資料結構需要能夠在對等節點之間傳播並連結在一起 以便實現去中心化。與任何網頁可以連結到不同位置的另一個網頁的形式類似，去中心化的資料結構實現了可互連的資料網路。
LESSION 2 - 定址和中心化的 Web
在我們深入研究去中心化 Web 的共享工作方式之前，讓我們先花點時間來研究一下傳統方式是如何訪問資料的。
通過 URL 定址
URLs (統一資源定位符，Uniform Resource Locators) 是我們在中心化 Web 上分享資料的主要方式（這種方式我們都習慣）。URL 使我們能夠在網路上建立連結和連線資料，因此它們有助於實現有價值的目的。（沒有連結的話網路會非常糟糕！）但是， URL 基於儲存資料的位置 ，而不是基於儲存在那裡的資源內容。我們稱這種方式為位置定址 （location addressing），它會帶來一些問題。
大多數人都有使用 URL 的體驗，我們根據經驗對它做了一些假設。例如當我們看到https://www.puppies.com/beagle.jpg
時，我們可能會從檔名和副檔名猜測儲存在該位置的資料是小獵犬的照片（JPEG 格式）， 但是我們無法僅通過 URL 驗證這一點。很可能有一張藏在beagle.jpg
的吉娃娃的照片，甚至更糟糕的是它居然是一隻可愛的小貓！
通過域名、URL 描述了表示我們所請求資料的中央機構。即使網路是去中心化的，任何人都可以連線到其他任何人，但基於位置的引用要求了資料本身必須是中心化的，以便我們可以從中央機構獲取到。除了上面提到的檔名假設，我們也會對這些權威或域名做出假設。例如我們假設在puppies.com
上託管的檔案比在evilhacker.com
上託管的檔案更安全，但我們無法確定是否真的如此。
所有這些不確定性也反之亦然。如果我們看到一張可愛的小狗的照片並被告知它被儲存在網路上，但我們是無法猜出該圖片 URL 的。我們不能確定域名，不能確定由誰伺服，不能確定檔名。
中心化 Web 上的信任和效率
正如你所看到的，由於我們無法驗證 URL 上的特定內容 並且依賴於中心化機構（和人們的善良）來標記事物的真實情況，因此我們很容易被欺騙。
42000 人很可能儲存完全相同的可愛小獵犬的照片，它們使用了不同的域名和不同的檔名。讓我們面對現實吧，即使在我們自己的膝上型電腦上，大多數人都儲存了與download.pdf
相同的文件download(01).pdf
，或者使用v1
或2018-12-18
來命名相同的文件。Web 非常令人困惑，不同的 URL 上多次儲存了非常混亂的資料，而且沒有簡單的方法來判斷哪些資料項彼此相同。
肯定有更好的辦法！
下一節：IPFS 去中心化資料結構（二）