InterPlanetary File System (IPFS)

InterPlanetary File System (IPFS)

avagy fájlrendszer a blokklánchoz

Sokan úgy gondolnak a blokkláncra, mint valamiféle általános elosztott tárolóra. Ez részben igaz is, hisz a blokklánc valóban egy masszívan redundáns, és következésképp igen biztonságos tároló, de korántsem általános célú. A jelenleg népszerű blokkláncok (Bitcoin, Ethereum, stb.) mérete úgy is sok Gigabyte-ra rúg, hogy többnyire csak pár byte-os tranzakciókat tartalmaznak. Képzeljük el, mekkora lenne akkor, ha mindenki blokkláncon tartaná a családi fotóalbumot. A probléma általános megoldása, hogy a nagy fájlokat a blokklánc helyett valamilyen ugyancsak decentralizált, de kevésbé redundáns tárolóra helyezzük, és a blokkláncon csak egy hivatkozást helyezünk el erre. Ilyen tároló megoldás az InterPlanetary File System, vagy IPFS.

Itt rögtön meg is jegyezném, hogy az IPFS-nek sok más alternatívája is létezik (például Ethereum esetén a többnyire magyarok által fejlesztett Swarm), mindazonáltal ezek közül talán az IPFS a legismertebb. Emellett a többi alternatív megoldás is az IPFS-hez hasonlóan működik, így ha az IPFS működését megértjük, ezen alternatív megoldások működését is érteni fogjuk.

Az IPFS más fájlrendszerekhez hasonlóan blokkokból épül fel. Minden blokk tartalmazhat valamilyen adatot, valamint egy link táblázatot, ami más blokkokra mutat. Minden linknek adható valamilyen név, valamint meg van adva hogy az általa mutatott blokk milyen méretű, mivel a blokkok mérete eltérő lehet. Igazából ennyire egyszerű az alapstruktúra, amiből a fájlrendszer felépül. Az egyes blokkokat a blokk tartalmából képzett hash-el érhetjük el. A rendszernek ez az apró, jelentéktelennek tűnő tulajdonsága rengeteg mágikus tulajdonsággal ruházza fel az IPFS-t.

Képzeljük el, hogy egy rövid szöveges fájlt tárolunk el IPFS-ben. Létrejön egy blokk, amihez tartozik egy hash. A fájlrendszeren belül akár milliónyi másolatot is készíthetünk a szövegfájlból, minden változat ugyanarra az adatcsomagra fog mutatni, nem jönnek létre felesleges másolatok. Hasonló megoldással tudnak helyet spórolni az ismert tárhely szolgáltatók is. Tegyük fel, hogy 10 ember előfizet 1Tb-os Dropbox tárhelyre. Itt tárolják a merevlemezük tartalmát, amiben lehetnek átfedések. Lehet például, hogy 2–3 embernél is megtalálható ugyanaz az mp3 fájl. Ez esetben egy ilyen hash alapú fájlrendszer az adott mp3-at csak egy példányban fogja leképezni, így a Dropbox a 10x1Tb-ot mindössze 5Tb-nyi helyen le tudja tárolni. Minél több a felhasználó, annál több lehet az átfedés, és annál többet lehet spórolni. De hasonló módon működik a GitHub is. A GitHub filozófiája, hogy ha szeretnénk beszállni egy projekt fejlesztésébe, másoljuk le a teljes projektet (forkoljuk a repository-t), végezzük el a módosításokat a saját változatunkon, majd jelezzük a projektnek, hogy fésülje vissza (merge) a fejlesztéseket a fő tárolóba. Létezhetnek hatalmas, több Gb méretű Git tárolók is, a másolás (fork) mégis pár pillanat alatt megtörténik. Ez is azért lehetséges, mert az egyes fájlok csak egy példányban vannak tárolva, így valójában csak egy referencia jön létre, nem másolódik semmi. Ezekhez hasonlóan működik az IPFS is, ahol egy blokk csak 1x képződik le. Persze a biztonság és a gyors elérés érdekében ezt az egy blokkot többen is tárolhatják, ahhoz hasonlóan, ahogyan a torrent protokoll is teszi. Ha valakinek kell valamilyen tartalom, miután megszerezte, ő is tárolja, így legközelebb már tőle is be lehet szerezni. Ennek a működésnek köszönhetően a blokkok “szétkenődnek” a rendszerben, így nagyobb biztonságban vannak (több gépen van róluk biztonsági másolat) és gyorsabban elérhetőek (több, közelebbi helyről beszerezhetőek).

A hash-elés másik fontos következménye, hogy bármilyen módon változik a tartalom, megváltozik a hash. Ennek köszönhetően nem lehet a fájlokat titokban megváltoztatni, vagy meghamisítani, hiszen bármely változtatás új blokkot eredményez. Hogy ezt jobban értsük, nézzük meg, hogy néz ki egy könyvtárszerkezet IPFS-ben. Ha teljes fájlstruktúrát szeretnénk tárolni IPFS-ben, ahhoz előbb blokkokra kell bontanunk az állományokat. Minden állományt egy olyan blokk fog reprezentálni, ami a tartalmát leíró blokkokra mutat. Ebben az összefogó blokkban nem lesz adat, csupán a link listát használjuk. Egy ilyen összefogó blokk tehát egy fájlt reprezentál. A könyvtárak nagyon hasonlóan épülnek fel. A link táblázatban minden link név egy fájlnév, és az adott fájlra, vagy egy másik könyvtár blokkra mutat. Ennyi az egész. Ezzel az egyszerű struktúrával akármilyen bonyolult könyvtárszerkezet megvalósítható, és a struktúra bármely szintje a hash-el címezhető, ami tulajdonképpen úgy funkcionál, mint egy URL. Most képzeljük el, hogy az egyik fájlban valami megváltozik. Ez esetben a változást tartalmazó blokk másik hash-t kap, amit módosítani kell az összefogó blokkban is. Ettől viszont az összefogó blokk hash-e is megváltozik, amit módosítani kell a könyvtárbejegyzés blokkban, amitől annak a hash-e is megváltozik. Így gyűrűzik fel a változás a legfelső szintre. Tehát ha bármit változtatunk, úgy új hivatkozásra van szükség, új URL-t kell generálni. Ez a változtathatatlanság egyébként kísértetiesen hasonlít a blokklánc működésére, ahol ugyancsak nem változtatható a múlt, csak új blokkok hozzáadására van lehetőség.

Végezetül az ENVIENTA példáján szeretném bemutatni, miért is előnyösek a fenti tulajdonságok, és miért neveztem a címben az IPFS-t a blokklánc tárolójának. Az ENVIENTA Platform célja, hogy oda bárki feltölthesse nyílt forrású találmányát, amit aztán bárki módosíthat, új változatot hozhat létre belőle, illetve hozzájárulhat a találmány fejlesztéséhez (GitHub szerű kooperatív fejlesztés). Emellett a platform minden változatot időbélyegez a blokkláncon (Proof of Existence), amivel a feltaláló bizonyíthatja, hogy az adott terveket ő publikálta legelőszőr. Ez segíthet a viták eldöntésében, illetve akár elég lehet ahhoz is, hogy bíróságon megvétózzunk vele egy szabadalmi kérelmet (amit adott esetben pl. egy szabadalmi troll próbál beadni). Lássuk hogy segít ebben az IPFS. Ha a terveket IPFS-ben tároljuk, azzal rögtön megoldódik a biztonságos, decentralizált tárolás kérdése. Nincs szükség központi szerverre (vagy csak cache jelleggel), a blokkokat a felhasználók tárolhatják saját gépeiken, hasonlóan, mint a torrent protokoll esetén. A hash-el történő címzésnek köszönhetően automatikusan megoldott a gyors másolatkészítés (fork), valamint a verziókezelés. Ez mind adott az IPFS által, ráadásul decentralizált módon. Nem kell központi Git szerver, vagy bármilyen más megoldás. Mivel a hash-el történő címzés biztosítja a változtathatatlanságot, ezért az időbélyegzéshez elegendő annyit tennünk, hogy az Ethereum hálózatra írjuk az adott verzió hivatkozását. Ezzel egyben lesz egy verzió listánk is, ami alapján visszakereshetőek a tervek régebbi verziói. Mivel az adott hash-hez kötődő könyvtár struktúra változtathatatlan, ezért olyan, mint ha magukat a fájlokat tárolnánk a blokkláncon. Ezért hivatkoztam az IPFS-re úgy, mint a blokklánc fájlrendszerére.

A fentiekből látható, hogy az ENVIENTA platform fájl repository funkcióját minden külső eszköz nélkül gyakorlatilag az IPFS az előnyös tulajdonságainak köszönhetően önmagától megoldja. A hash alapú címzésnek köszönhetően ha valamit IPFS-ben tárolunk, és a hivatkozást a blokkláncra írjuk, az teljesen megfelel annak, mint ha a teljes fájlt a blokkláncra tárolnánk, azzal a különbséggel, hogy kisebb a redundancia (a blokkláncot minden node tárolja, az IPFS blokkokat csak pár). Az IPFS és a blokklánc segítségével létrehozható decentralizált torrent tracker, de pl. az Ethereum Name Service (ENS)-nek köszönhetően akár teljes decentralizált webet is építhetünk.

Akit mélyebben érdekel a téma, itt talál egy nagyon jó összefoglaló cikket az IPFS-ről angolul a ConsenSys-től: https://medium.com/@ConsenSys/an-introduction-to-ipfs-9bba4860abd0