來源：ConsenSys
“擁有IPFS之後，你就可以開始用一種特定的方式來看待其他所有事物，然後你就會意識到你可以把它們全部替換掉。”
——IPFS創始人Juan Benet
01
簡單瞭解IPFS
本節將試圖為Christian Lundkvist博士以下的深入技術摘要提供高層次的見解。
IPFS最初是由Juan Benet所提出，目的是試圖建立一個能夠快速移動的版本化科學資料系統，版本控制可以讓您隨時間變化跟蹤軟體狀態（類似Git）。從那時起，IPFS就被認為是分散式、永久性Web。“IPFS是一個分散式檔案系統，旨在將所有計算裝置與同一檔案系統連線。在某些方面，類似於Web的原始地址，但實際上更類似於交換Git物件的單個bittorrent（位元流）群。IPFS未來可能會成為網際網路的一個新的主要子系統。如果構建成功，它將可以補充或替換HTTP，甚至能夠替代更多。這聽起來很瘋狂，確實很瘋狂。”
IPFS的核心是一個版本化的檔案系統，可以獲取檔案並對其進行管理，還可以將它們儲存在某個地址，然後隨著時間的推移跟蹤版本。IPFS還考慮了這些檔案如何在網路中移動，因此它也是一個分散式檔案系統。
IPFS對於資料和內容如何在網路上移動有著類似於bittorrent的規則。該檔案系統層提供了非常有趣的屬性，例如：
-完全分佈的網站
-沒有原始伺服器的網站
-可以完全在客戶端瀏覽器上執行的網站
-沒有任何可與之對話的伺服器網站
內容定址
IPFS不是透過儲存物件的伺服器來引用物件（圖片、文章、影片），而是透過檔案上的雜湊引用所有內容。這原理是，如果您要在瀏覽器中訪問特定頁面，則IPFS將詢問整個網路“是否有人擁有與該雜湊相對應的檔案？” IPFS上的一個節點可以返回該檔案，使您可以訪問它。
IPFS在HTTP層使用內容定址。這是一種慣例，我們將建立內容本身的某種表示形式，而不是建立一個按位置定位事物的識別符號。這意味著內容將決定地址。其機制是獲取一個檔案，然後以加密方式對其進行雜湊處理，這樣您就可以得到該檔案的非常小而安全的表示形式，從而確保了某個人不能僅僅拿出具有相同雜湊值的另一個檔案並將其用作地址。IPFS中檔案的地址通常以標識根物件的雜湊開始，然後是一個向下移動的路徑。您正在與一個特定的物件交談，而不是與伺服器對話，可檢視該物件內的路徑。
HTTP vs IPFS 查詢和檢索檔案
HTTP具有一個不錯的屬性，其中的識別符號是位置，因此很容易找到託管該檔案的計算機並與之對話。這很有用，通常效果很好，但在離線情況下或希望將整個網路上的負載降至最低的大型分散式方案中就無法使用了。
在IPFS中，步驟可分為兩部分：用內容定址識別檔案，去找到它——當您擁有雜湊值時，您會詢問所連線的網路“誰擁有此內容？（hash）”，然後連線到相應的節點並下載。結果是點對點覆蓋，可為您提供非常快速的路由。
要了解更多資訊，請觀看Alpha Video。
02
IPFS示例
技術檢查和IPFS（星際檔案系統）是經過測試的網際網路技術的綜合，例如DHTs，Git版本系統和Bittorrent。它建立了一個P2P群，可以交換IPFS物件。IPFS物件的總數形成了一個經過加密驗證的資料結構，稱為Merkle DAG，該資料結構可用於對許多其他資料結構進行建模。我們將在本文中介紹IPFS物件和Merkle DAG，並提供可以使用IPFS建模的結構示例。
IPFS物件
IPFS本質上是一個用於檢索和共享IPFS物件的P2P系統。IPFS物件是具有兩個欄位的資料結構：
資料——大小小於256 kb的非結構化二進位制資料的斑點。
連結——連結結構的陣列，這些是到其他IPFS物件的連結。
連結結構具有三個資料欄位：
名稱——連結的名稱。
雜湊——連結的IPFS物件的雜湊。
大小——連結的IPFS物件的累積大小，包括跟隨其連結的位置。
該尺寸領域主要用於最佳化P2P網路，這裡我們將基本忽略它，因為從概念上講，邏輯結構不需要它。
IPFS物件通常由其Base58編碼的雜湊引用。例如，讓我們使用IPFS命令列工具檢視帶有雜湊QmarHSr9aSNaPSR6G9KFPbuLV9aEqJfTk1y9B8pdwqK4Rq的IPFS物件（請在家嘗試）：
讀者可能會注意到，所有雜湊均以“ Qm”開頭。這是因為雜湊實際上是multihash，這意味著雜湊本身在multihash的前兩個位元組中指定了雜湊函式和雜湊長度。在上面的示例中，十六進位制的前兩個位元組為1220，其中12表示這是SHA256雜湊函式，而20表示雜湊的長度（以位元組為單位），即32個位元組。
資料和命名連結為IPFS物件集合提供了Merkle DAG的結構——DAG表示有向無環圖，Merkle表示這是一個經過加密認證的資料結構，使用加密雜湊來處理內容。這是留給讀者的一個練習來思考為什麼在這個圖表中不可能有迴圈。
為了視覺化圖形結構，我們將透過一個圖形來視覺化IPFS物件，該圖中包含節點中的資料，連結被定向到其他IPFS物件的圖邊，其中連結的名稱是圖邊上的一個標籤。上面的示例如下所示：
現在我們將舉例說明可以由IPFS物件表示的各種資料結構。
檔案系統
IPFS可以輕鬆表示由檔案和目錄組成的檔案系統。
小檔案
一個小檔案（<256 kB）由IPFS物件表示，資料是檔案內容（加上小頁首和頁尾），沒有連結，即連結陣列為空。請注意，檔名不是IPFS物件的一部分，因此兩個名稱不同且內容相同的檔案將具有相同的IPFS物件表示形式，因此具有相同的雜湊值。
我們可以使用命令ipfs向IPFS新增一個小檔案：
我們可以使用ipfs cat檢視上述IPFS物件的檔案內容：
使用ipfs物件檢視基礎結構可獲得收益：
我們將該檔案視覺化如下：
大檔案
大型檔案（> 256 kB）由小於256 kB的檔案塊的連結列表表示，並且只有最小資料指定此物件表示大檔案。指向檔案塊的連結的名稱為空字串。
目錄結構
目錄由指向代表檔案或其他目錄的IPFS物件的連結列表表示。連結的名稱是檔案和目錄的名稱。例如，考慮目錄test_dir的以下目錄結構：
檔案hello.txt和my_file.txt都包含字串Hello World！\ n。檔案testing.txt包含字串Testing 123 \ n。
當將此目錄結構表示為IPFS物件時，它看起來像這樣：
注意，對包含Hello World！\ n的檔案進行了自動重複資料刪除，\ n，該檔案中的資料僅儲存在IPFS中的一個邏輯位置（由其雜湊地址定址）。
IPFS命令列工具可以無縫地跟隨目錄連結名稱來遍歷檔案系統：
版本檔案系統
IPFS可以代表Git用於版本化檔案系統的資料結構。Git提交物件在Git Book中進行了描述。在撰寫本文時，尚未完全指定IPFS提交物件的結構，討論仍在進行中。
提交物件的主要屬性是它具有一個或多個連結，其名稱為parent0，parent1等，指向先前的提交，並且具有名稱物件的連結（在Git中稱為tree），該連結指向該物件引用的檔案系統結構。
我們以前面的檔案系統目錄結構以及兩次提交為例：第一次提交是原來的結構，並在第二次提交，我們已經更新了檔案my_file.txt，表示另一個世界，而不是原始的“Hello World!”。
這裡還要注意，我們具有自動重複資料刪除功能，因此第二個提交中的新物件只是主目錄，新目錄my_dir和更新後的檔案my_file.txt。
03
區塊鏈
這是IPFS最令人興奮的用例之一。區塊鏈具有自然的DAG結構，因為過去的區塊始終透過其後繼區塊的雜湊值進行連結。以太坊區塊鏈等更高階的區塊鏈也有一個關聯的狀態資料庫，該資料庫具有Merkle-Patricia樹結構，也可以使用IPFS物件進行模擬。
我們假設一個簡單的區塊鏈模型，其中每個塊包含以下資料：
交易物件列表；
到上一個塊的連結；
狀態樹/資料庫的雜湊。
然後可以在IPFS中按以下方式對該區塊鏈進行建模：
當將狀態資料庫放在IPFS上時，我們看到了重複資料刪除的好處——在兩個塊之間，只有已更改的狀態項需要顯式儲存。
這裡有趣的一點是，將資料儲存在區塊鏈上與將資料雜湊儲存在區塊鏈上之間的區別。在以太坊平臺上，您需要支付相當大的費用才能將資料儲存在關聯的狀態資料庫中，以最大程度地減少狀態資料庫的膨脹（區塊鏈膨脹）。因此，這是一種常見的設計模式，即較大的資料不儲存資料本身，而是儲存狀態資料庫中資料的IPFS雜湊。
如果在IPFS中已經表示了具有相關狀態資料庫的區塊鏈，那麼將雜湊儲存在區塊鏈上和將資料儲存在區塊鏈上的區別就變得有些模糊了，因為無論如何所有內容都儲存在IPFS中，並且只需要區塊的雜湊即可狀態資料庫的雜湊。在這種情況下，如果有人在區塊鏈中儲存了IPFS連結，我們可以無縫地跟隨該連結來訪問資料，就像資料儲存在區塊鏈本身中一樣。
但是，我們仍然可以區分鏈上和鏈下資料儲存。我們透過檢視礦工在建立新區塊時需要處理的內容來做到這一點。在當前的以太坊網路中，礦工需要處理將更新狀態資料庫的交易，為此，他們需要訪問完整狀態資料庫，以便能夠在更改後的任何地方對其進行更新。
因此，在以IPFS表示的區塊鏈狀態資料庫中，我們仍然需要將資料標記為“鏈上”或“鏈下”。對於礦工來說，“鏈上”資料對於本地挖礦是必不可少的，並且該資料將直接受到交易的影響。“鏈下”資料將必須由使用者更新，而礦工則無需接觸。
