IPFS（行星際檔案系統）是用於基於區塊鏈的內容的去中心化儲存解決方案。IPFS使用P2P（對等）網路模型進行檔案共享，該模型分散並分佈在許多計算機或節點上。檔案被分解為不同的部分，並儲存在節點網路中，這些節點透過雜湊跟蹤檔案。當要查詢某個檔案時，將根據其雜湊值重新建立原始檔案。
使用分散式雜湊表（DHT）儲存和檢索檔案系統是IPFS的核心創新。它類似於BitTorrent協議，但是它們指向共享檔案的方式不同。IPFS是將檔案作為鍵值對儲存在區塊鏈上。資料分為256 KB的塊，並散佈在節點或計算機的網路中。它被有效地協調以實現節點之間的有效訪問和查詢。BitTorrent不使用區塊鏈，而是依賴Torrent來指向檔案。可以有不同的Torrent指向同一個檔案，但在IPFS中，你只需要一個指向檔案的雜湊ID。
檔案釋出到IPFS的方式與將檔案釋出到雲中的方式不同。IPFS上的所有資料均透過其雜湊ID進行定址。當某人請求該資料時，他們是直接透過其雜湊ID而不是實際檔案本身來請求該資料。因此IPFS為檔案的實際位置提供了一個抽象，因此實際的物理位置對應用程式無關緊要。這種抽象為應用程式開發人員消除了複雜性。
節點在網路上承載檔案。IPFS區塊鏈上的Filecoin等數字資產激勵他們這麼做。激勵節點在其計算機或伺服器上提供用於託管檔案的儲存空間。些檔案被賦予一個雜湊ID，然後可以透過網路分發。其他節點也可以託管同一檔案，從而允許製作多個副本。想要該檔案的使用者將根據離他們位置最近的節點的雜湊值來訪問它。
託管檔案的所有節點都將引用根雜湊，該根雜湊是檔案的雜湊ID。每當發出檔案請求時，使用者就會使用基於其根雜湊值儲存該檔案的最近節點的雜湊值來下載檔案。IPFS上沒有重複項，因為雜湊在上載時將始終引用該檔案或檔案的一部分。
檔案放入IPFS區塊鏈後，它將保持可用，直到透過取消檔案繫結並執行垃圾收集例程將其刪除。檔案本身可以具有透過其雜湊指向的不同節點。只要存在指向該檔案的雜湊，不同的節點也可以託管該檔案。IPFS可以更新為指向不同的雜湊值，但是隻要原始節點的雜湊值現在或將來的任何時候都可以訪問該資料，則至少有一個節點仍在託管該資料。
儲存定址方案
IPFS與典型的基於雲的基於Internet的儲存系統的區別在於它是基於內容的（內容定址）而不是基於位置的（位置定址）。位置定址儲存系統的一個示例是HTTP協議。當儲存系統基於位置時，它是指使用DNS伺服器透過其主機名來標識伺服器。這透過對映到使用者友好名稱的邏輯定址方案（例如IP地址）跟蹤主機。如果主機更改其名稱或地址，則還必須在名稱服務表中對其進行修改。
基於內容的定址儲存屬於從網路獲取資料的內容。這需要確定檔案物理位置的內容識別符號。在這種情況下，資料是根據其加密雜湊而不是邏輯地址來訪問的，就像檔案的數字指紋一樣。網路將始終基於該雜湊返回相同的內容，而不管檔案的上傳者，上傳時間和上傳時間。
在速度和可靠性方面，IPFS可以比HTTP表現得更好。內容定址儲存系統可以從離使用者最近的各種伺服器（例如IPFS網路上的對等或節點）提供檔案，而不是依賴伺服器位置來獲取檔案。換句話說，使用者只需搜尋一個檔案，而無需搜尋引擎引用位置，即伺服器名稱或地址。相反他們將透過檔案的雜湊值引用它，並且可以從網路上最近的可用節點中獲取該檔案。
安裝IPFS
有兩個節點選項可用於IPF的公共安裝。
1. PFS Desktop — 直接在計算機（膝上型電腦或桌上型電腦）託管和共享檔案。可以安裝IPFS配套應用程式，以允許使用Web瀏覽器訪問本地節點。
2. IPFS Cluster — 為了大規模託管和共享檔案，該群集支援跨IPFS節點群協調和協調Pinets。這允許透過分散式節點構建大規模的大型檔案儲存系統。
安裝IPFS Desktop後，配置節點首先要初始化儲存庫。以下是您從Windows Powershell或Mac/Linux終端外殼鍵入的命令。
ipfs init
> initializing ipfs node at /Users/<username>/.go-ipfs
> generating 2048-bit RSA keypair...done
> peer identity: Qmcpo2iLBikrdf1d6QU6vXuNb6P7hwrbNPW9kLAH8eG67z
> to get started, enter:
>
> ipfs cat /ipfs/QmYwAPJzv5CZsnA625s3Xf2nemtYgPpHdWEz79ojWnPbdG/readme
首次使用IPFS時執行此初始化。下一步是執行IPFS守護程序，以將節點加入網路。
ipfs daemon
> Initializing daemon...
> API server listening on /ip4/127.0.0.1/tcp/5001
> Gateway server listening on /ip4/127.0.0.1/tcp/8080
這將在本地計算機127.0.0.1上初始化並執行守護程序。它會啟動一個偵聽TCP埠5001的API伺服器和一個偵聽TCP埠8080的閘道器伺服器。現在您應該能夠透過發出swarm命令看到網路上的其他IPFS節點。它應該如下所示：
ipfs swarm peers
> /ip4/104.131.131.82/tcp/4001/p2p/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ
> /ip4/104.236.151.122/tcp/4001/p2p/QmSoLju6m7xTh3DuokvT3886QRYqxAzb1kShaanJgW36yx
> /ip4/134.121.64.93/tcp/1035/p2p/QmWHyrPWQnsz1wxHR219ooJDYTvxJPyZuDUPSDpdsAovN5
> /ip4/178.62.8.190/tcp/4002/p2p/QmdXzZ25cyzSF99csCQmmPZ1NTbWTe8qtKFaZKpZQPdTFB
如IPFS文件中所述，pees採用以下格式：
<transport address>/p2p/<hash-of-public-key>
這是在網路上獲取檔案的示例命令：
ipfs cat /ipfs/QmW2WQi7j6c7UgJTarActp7tDNikE4B2qXtFCfLPdsgaTQ/cat.jpg > cat.jpg
open cat.jpg
這將從指定的對等方獲取一個名為'cat.jpg“然後在本地開啟。
IPFS的Javascript
以下是使用Runkit NPM和Infura閘道器（對公眾免費）將資料寫入IPFS網路的測試程式碼。
const IPFS = require('ipfs-mini' 1.1.5 );
const ipfs = new IPFS({host: 'ipfs.infura.io', port: 5001, protocol: 'https'});
const data = "Writing a test message on the network";
ipfs.add(data, (err, hash) => {
if(err){
return console.log(err);
}
console.log('https://ipfs.infura.io/ipfs/'+hash);
})
在這段程式碼中，我使用require函式在Node.JS上請求“ ipfs-mini”包。然後我配置對Infura IPFS閘道器“ ipfs.infura.io”的訪問。然後我將資料指定為字串“Writing a test message on the network”。我建立一個條件以在出現問題時返回錯誤，否則我想要雜湊值，然後控制檯記錄閘道器的URL和雜湊值。
結果將返回唯一的雜湊：QmQhadgstSRUv7aYnN25kwRBWtxP1gB9Kowdeim32uf8Td
我現在可以輸入URL連結：https://ipfs.infura.io/ipfs/QmQhadgstSRUv7aYnN25kwRBWtxP1gB9Kowdeim32uf8Td
這將顯示我剛剛放入Infura閘道器的資料。資料不是永續性的，幾天或幾周不活動後將被刪除。對於永久資料儲存，需要在內部或在雲上使用專用伺服器。
IPFS的優點
1. 分散化-檔案儲存在節點網路中，由雜湊引用。透過Filecoin激勵節點託管檔案。
2. 容錯-如果一個節點發生故障，只要有託管該檔案的節點，該檔案仍然可用。沒有單點故障。
3. 可擴充套件性—託管檔案的節點越多，網路上的使用者就可以變得越快和可用。
4. 持久儲存-IPFS的重點是資料儲存：只要可以訪問與原始資料相對應的物件以及任何新版本，就可以檢索整個檔案歷史記錄。假設資料塊儲存在整個網路的本地並且可以無限期地快取，這意味著IPFS物件可以永久儲存而無需修改。
5. 抵制審查—內容上載到IPFS後，任何中央機構都無法刪除它，因為它分佈在整個網路中。僅從一個節點刪除它不會完全刪除該檔案。這意味著在其他節點上仍有可用的副本。
IPFS的缺點
· 對使用者不友好
在IPFS網路上建立檔案索引的方式不是非常使用者友好。例如要透過其雜湊ID訪問檔案，需要輸入：ipfs.io/ipns/QmeQe5FTgMs8PNspzTQ3LRz1iMhdq9K34TQnsCP2jqt8wV
開發人員可以使用連結共享檔案，但是這可能變得乏味且耗時。IPFS使用IPNS（星際名稱系統）來查詢檔案。IPNS將嘗試使名稱解析更加使用者友好，就像Internet上的DNS一樣。
有一個GUI和基於web的擴充套件IPFS配套應用程式，使用者可以使用它來更方便地訪問。然而由於學習曲線更加陡峭，它仍然不像普通的智慧手機應用程式那樣使用者友好或簡單易用。它不像點選網頁上的按鈕那麼簡單。使用者必須知道IPFS是如何工作的才能使用它。
· 資料隱私和合規性
在使用IPFS的公共共享儲存系統上放置客戶資料（如KYC等個人識別資訊（PII））不是最好的用例。首先它違反了儲存合規性規則，該規則規定KYC資料不能也不應在公共雲或共享儲存空間上公開，並且應包括IPFS。在公共雲上，對組織管理資料的控制更少。金融機構的嚴格要求是將資料和資料備份儲存在受監管的而非公共儲存系統上。這裡的另一個問題是，由於它位於公共網路上，因此任何節點都可以託管KYC資料。這進一步違反了嚴格規定誰可以在何處儲存資料的法律。
第二個問題是，所有節點必須符合金融系統的規則和規定，這意味著它們必須具有備份，強大的安全性，容錯性等。在公共網路上，這些節點是隨機的，不能讓它們遵守規則，因為它們不必信任您的系統。他們還可以將KYC資料提供給網路上的其他使用者，即使行為被加密，惡意參與者也可以訪問。他們可以自己解密，這為他們提供了一條途徑。
· 資料不一致
在IPFS上，節點維護網路上資料的長期備份的動機也很小。節點可以選擇清除快取的資料以節省空間，這意味著從理論上講，如果沒有剩餘的節點託管資料，檔案最終會隨著時間的流逝而“消失”。在當前的採用水平上，這不是一個大問題，但從長遠來看，備份大量資料需要強大的經濟動力。
這裡的問題是，如果公司使用公共IPFS網路進行檔案儲存，則節點可以隨時選擇不將來託管檔案。如果所有節點都決定執行此操作，則除非IPFS託管在專用網路上，否則無法將檔案保留在網路上。根據IPFS協議，如果您新增到IPFS網路的檔案沒有被很多人訪問，它將消失。您的資料需要在網路上更加流行才能使其永久存在。如果您不希望資料從IPFS網路中消失，則必須將資料固定在節點上。固定可確保透過網路至少您的節點擁有該資料。
由於IPFS是分散式的，因此所有託管節點都將擁有您上載的檔案的副本。通常如果檔案不活躍或不經常使用，則將其刪除。這可能是一個非常有爭議的問題，因為有時檔案已被歸檔並且不經常使用，有時還需要立即刪除。當已經儲存在IPFS上的資料發生更改時，其雜湊也必須更改。如果有新版本，則必須上載，但不會覆蓋舊版本。這會影響到檔案的現有連結，因此原始檔案保持不變，但是現在您需要為新檔案建立一個新連結。
更新KYC資料時，這可能是一個挑戰。這些文件過期後，必須上載新版本以替換舊版本。IPFS提供了版本控制，但是一旦將其放在公共網路上就會變得棘手，因為可以從不同的節點存在許多版本。舊版本不會自動更新。舊的必須存檔或銷燬。IPFS不能以與AWS或Azure相同的方式存檔檔案。
IPFS確實有一個版本控制系統。這是IPFS的Merkle-DAG結構的一個特性，它允許您構建分散式版本控制系統（VCS）。最受歡迎的示例是Github，它使開發人員可以輕鬆地同時在專案上進行協作。Github上的檔案使用Merkle DAG進行儲存和版本控制。它允許使用者獨立地複製和編輯一個檔案的多個版本，儲存這些版本，以及以後與原始檔案合併編輯。但是根據許多開發人員的觀點，從理論上講，這幾乎是可行的，但還沒有一種經過充分測試和驗證的有效的技術（在撰寫本文時）。如果我們要實施它，那將需要更多的時間和開發成本，從長遠來看可能是好的。
