Världens alla it-system, för att inte tala om deras användare, skapar redan idag enorma mängder data som måste lagras någonstans. I det flesta fall är detta ”någonstans” lika med enorma datacenter, ofta tillhörande stora molntjänster. För att ta del av dessa data använder vi fortfarande den klassiska klient-server-modellen, och oftast över protokollet http(s). Även om mycket hänt på framförallt serversidan i och med utvecklingen av molntjänster och det så kallade Webben 2.0 är vi fortfarande till stora delar kvar i en centraliserad klient-server-modell – skillnaden är att filservern numer ägs av ”någon annan". Frågan är om detta är hållbart i framtiden?
Många hävdar att den mängd data vi hittills samlat i våra datacenter, och som förstås fortsätter att öka, inte kommer i närheten av de mängder som kommer behövas för att backa upp de visioner som målas upp. Ett exempel på vad som väntar runt hörnet är den AR-drivna (augmented reality) spegelvärld av digitala tvillingar av alla reella objekt och miljöer som inte bara kommer att förstärka vår egen perception genom AR-glasögon, utan utgör den enda perception autonoma robotar, som självkörande fordon, har att förhålla sig till. Det vi är på god väg att utveckla är en digital tvillingvärld av den reella världen, en digital karta i skala 1:1. Hur många bytes blir det? Kommer den centraliserade klient-server-modellen över http att stå pall?
Webben 3.0 – den distribuerade webben
Svaret på dessa frågor är förmodligen nej. Det kommer antagligen inte att hålla. Det som behövs är att vi decentraliserar webben; det som av vissa kallas Webben 3.0, och IPFS är den decentraliserade webbens lagringsprotokoll par preferens. Men vad är det då?
Interplanetary File System, IPFS, är ett globalt distribuerat block-filsystem som bygger på ett protokoll och ett peer-to-peer-nätverk av lagringsnoder där användarna lagrar filer som sedan kan nås med hjälp av nätverks-adresser som genereras utifrån innehållet i filerna. Ambitionen är att knyta samman alla datorer (i vid bemärkelse) i samma system av filer som fungerar på ungefär samma sätt som fildelning via Bittorrent och samma typ av versionshantering som i Git och Github.
Den som tittat på blockkedjor har sannolikt även stött på IPFS som begrepp, och det är ingen slump, men det är viktigt att poängtera att dessa tekniker inte har ett dugg med varandra att göra som modeller sett. IPFS bygger inte på blockkedjemodellen överhuvudtaget, annat än att de delar peer-to-peer-filosofin i hur nätverksnoderna hänger ihop och delar information.
Använder fyra etablerade tekniker
Adresserna till innehållet fungerar så att innehållet i sig, eller rättare sagt en hash av innehållet, utgör adressen eller pekaren till innehållet. Jämför med http där en url utgör adressen till innehållet – i IPFS är innehållet adressen. En typisk IPFS-adress kan se ut så här:
QmRU1jJ1kNd9fTzjFwM4X9YtA2wfXN1W2eFK7mgTMJ8xgK
Den minnesgode kommer kanske att tänka på distribuerade hashtabeller, och det är inte en slump. En distribuerad hashtabell (DHT) är en datastruktur som ger en sökfunktion för lagrade värden. Lagrade värden motsvaras av en unik nyckel i ett nyckel/värde-par. Givet en nyckel returnerar DHT:n motsvarande lagrade värde. D:et i DHT säger förstås att systemet är distribuerat över två eller fler noder.
Inom IPFS används DTH:ns sökfunktion för att hitta de noder som lagrar de data som efterfrågas inom nätverket. Givet nyckeln (innehållet som eftersöks) returnerar DHT:n värdet (adressen till de noder som lagrar det eftersökta innehållet).
Den andra tekniken som IPFS bygger på är Bittorrent. Det fina med Bittorrent är, som de flesta känner till, att den delar upp stora filer (eller alla filer) i mindre bitar som sedan sprids över många (eller alla) noder. På detta sätt ansträngs inte en nod jättemycket om många vill åt ett visst innehåll (klient-server), utan alla noder ansträngs pyttelite (peer-to-peer). I grundläget delas data upp i 256 kilobyte stora partitioner och varje partition hashas med SHA-256. Utbytesprotokollet i IPFS är inspirerat av, men inte exakt samma, som Bittorrent och kallas BitSwap.
Den tredje inspirationskällan till IPFS är versionshanteringsystemet Git. Git bidrar med ett distribuerat revisionskontrollsystem som håller reda på förändringar i innehåll som delas av flera parter. Git är känt, och enormt populärt, inte minst genom webbversionen Github. Gits sätt att adressera innehållet motsvaras av nyckel/värde-paret i DHT:er för att hitta vilka noder som lagrar ett visst innehåll, men utöver detta delar Git upp datafilerna i små segment, och för att organisera lagringssystemet länkar Git alla segment i en så kallad Merkle Directed Acyclic Graph (DAG).
Det Git alltså gör är att hålla reda på var innehållet finns, även om innehållet ändras (adressen till innehållet baseras ju på innehållet). Om utvecklare som använder Git uppdaterar koden de arbetar med, borde ju även adressen till innehållet i filsystemet förändras, men det håller Git reda på.
Den fjärde och sista tekniken IPFS bygger på kallas Self-Certified File System (SFS). SFS är ett distribuerat filsystem vars främsta egenskap är att det separerar den nyckelhantering som ger säker tillgång till data, från de faktiska data som delas över internet. Till skillnad från andra distribuerade filsystem kräver SFS inte ett system för nyckelhantering för att mappa filnamn till kryptonycklar, utan filnamnen innehåller i sig publika nycklar vilket gör filnamnen till självcertifierande sökvägar, och användaren kan verifiera noden från vilken data hämtas.
Protokollstack och komponenter
Utöver att IPFS är ett distribuerat filsystem är det även ett protokoll med en protokollstack. Sett ovanifrån applikationslagret och ned till nätverksnivån ser protokollstacken ut som följer:
- Nodidentiteter. IPFS-noder måste generera en identitet innan de kan kommunicera med andra noder. Genom PKI genererar noden först ett nyckelpar (privat och publik nyckel). Därefter skapar noden sin identitet genom att hasha den publika nyckeln upprepade gånger.
- Objekt. IPFS använder en egen datastruktur för att lagra datafiler. Innan filerna lagras, partitioneras de och varje partition hashas. Partitionerna länkas sinsemellan för att systemet ska kunna hämta hela filen. Länkarna upprätthålls med hjälp av en Merkle DAG.
- Filer. Med inspiration från Git använder IPFS ett versionssystem ovanpå systemets Merkle DAG.
- Namnsystem. IPFS använder ett namnsystem som de kallar InterPlanetary Naming System (IPNS). IPNS bygger på SFS.
- Utbyte. När data lokaliseras använder IPFS Bitswap som protokoll för att utbyta data.
- Routing. IPFS använder DTH, som beskrivet ovan, för att hålla reda på vilka noder som håller vilka data.
- Nätverk. IPFS-protokollet låter noder ansluta till varandra oavsett den underliggande typen av nätverk – typiskt tcp/ip, men IPFS behöver inte ens ip för att fungera, utan fungerar i princip ovanpå vilket annat nätverk som helst. Detta beror på att IPFS tillämpar ett egen adressering med en egen adressrymd.
Denna protokollstack bakas sedan ihop till tre IPFS-komponenter:
- IPNS är komponenten som låter användarna peka sina länkar mot den senaste versionen av datat som lagras på IPFS. Det ger användarna ungefär samma användarupplevelse som med http, det vill säga användarna kan använda samma länk även om datat uppdateras.
- IPLD är ett dataformat för merkle-länkade objekt. Dess huvudsakliga uppgift är att upprätthålla hash-länkade datastrukturer och propagera dessa runt nätverket.
- Libp2p är en modulär nätverksstack för peer-to-peer-nätverk som sätter upp uppkopplingar mellan nätverksnoder och söker upp och levererar data när det efterfrågas. Det representerar utbytes-, routing- och nätverkslagren i IPFS protokollstack.
Nackdelar med IPFS
IPFS är bandbreddskrävande, vilket främst beror på att data i DHT:n ständigt uppdateras och cirkuleras. Så fort data, till exempel ett levande delat dokument, uppdateras, måste DHT:n uppdateras för att alla som vill ta del av dokumentet ska få tillgång till den senaste versionen. Bandbreddsproblemet är en livlig diskussion inom utvecklingsgruppen på Github, och flera förbättringar har gjorts, men analyser visar att även en nod som varken tar emot eller skickar innehållsdata, och normalt är uppkopplad mot ungefär 500–1000 andra noder, ändå tar emot cirka tio gigabyte data, och skickar cirka sju gigabyte data per dygn.
IPFS-systemet som sådant kan inte garantera att efterfrågat data finns att tillgå när det efterfrågas. Det grundläggande problemet är att de som upprätthåller noder saknar incitament att lagra data åt andra. Även om det är sällsynt kan data bli onåbart om den eller de noder som lagrar data tas bort eller inte kan nås vid tillfället.