TechLife devBlog

Kwiecień 2017

IPFS - międzyplanetarny system plików

Internet 24 kwietnia 2017 19:16

Co niby może być ciekawego w systemie plików? Poza tym, że można zrobić z niego grę RPG to zazwyczaj niewiele. W tym przypadku może być jednak zupełnie inaczej. IPFS (InterPlanetary File System) to nowo powstający protokół, który w przyszłości może diametralnie zmienić sposób funkcjonowania sieci Internet a zastąpienie protokołu HTTP będzie tylko jedynym ze skutków ubocznych.

IPFS logo

Problemy dzisiejszej sieci

Nowych protokołów zazwyczaj nie tworzy się dla zachcianki ale w celu rozwiązania jakiś istotnych problemów. Jakie problemy więc próbuje rozwiązać IPFS?

  • CENTRALIZACJA - obecna sieć jest mocno scentralizowana a przez to bardzo podatna na wszelkie przypadki cenzurowania treści, odcinania dostępu do zasobów czy nawet odcinania całych krajów od internetu.
  • NIEEFEKTYWNOŚĆ HTTP - protokół HTTP zakłada pobieranie danego pliku z pojedynczej maszyny, nie mamy możliwości pobierania go równolegle z wielu (często bliższych nam) punktów jednocześnie tak jak w przypadku sieci p2p.
  • UTRATA HISTORYCZNYCH DANYCH - każdego dnia wiele wartościowych treści znika bezpowrotnie z internetu wraz ze stronami na których były zamieszczone a proces ich zabezpieczania i wersjonowania nie jest prosty i często wiąże się z tworzeniem kolejnych duplikatów co kosztuje sporo miejsca.
  • UZALEŻNIENIE APLIKACJI OD INTERNETU - większość współczesnych aplikacji jest uzależniona od dostępu do internetu a przez to nienadająca się do krajów trzeciego świata, nieodporna na katastrofy naturalne (podczas których duże obszary są odcinane od sieci) czy często przerywane połączenia.

Rozwiązania

Ok, skoro już wiemy z jakimi problemami chce zmierzyć się IPFS to teraz przyjrzyjmy się jakimi sposobami będzie starał się je pokonać.

1. TOPOLOGIA

topologie sieci

Obecnie wiele aplikacji działa w oparciu o scentralizowaną architekturę (A). Charakteryzuje się ona podziałem na role klient-serwer gdzie klientów mamy wielu natomiast serwer jest jeden (choć często składa się z wielu instancji). Łatwo możemy tu publikować informacje, ponieważ wysyłamy je w jedno miejsce, z którego następnie wszyscy klienci je odczytują. Problemem jest tu natomiast skalowanie aby sprostać ogromnej liczbie klientów dobijających się po aktualne informacje. Największą bolączką są pojedyncze punkty awarii (single point of failure), które w przypadku niewłaściwego funkcjonowania są w stanie unieruchomić przepływ informacji w całej sieci. Weźmy tu za przykład takie aplikacje jak Facebook czy Twitter. W przypadku awarii Load Balancerów, błędu w konfiguracji DNS-ów czy niedyspozycji bazy danych te aplikacje stają się całkowicie sparaliżowane.

Lepszym podejściem jest oczywiście architektura zdecentralizowana (B), która jest w stanie znieść unieruchomienie niektórych serwerów, ponieważ pomimo, że serwery w niej zlokalizowane komunikują się między sobą to nie są od siebie uzależnione. Przykładem mogą być tu serwery mailowe, serwery sieci komunikacji XMPP czy sieci społecznościowe takie jak Diaspora. Jeżeli przestanie działać jeden z podów Diaspory nie przeszkodzi to w komunikacji użytkownikom innych podów. Oczywiście nadal istnieją tu wąskie gardła takie jak serwery DNS czy serwery na których masz aktualnie konto.

Najbardziej odporną topologią jest sieć rozproszona (C), na którą to właśnie stawia IPFS. Taka architektura wiąże się jednak zupełnie innym podejściem do projektowania aplikacji, ponieważ każdy węzeł może się tu zachowywać jednocześnie jako klient i serwer oraz być połączony z dowolną liczbą innych węzłów. Co ciekawe właśnie tak wyobrażano sobie pierwotny kształt sieci Internet.

2. Identyfikacja i unikalność

Ponieważ głównym nośnikiem informacji w sieci IPFS są pliki, dlatego duży nacisk postawiono na ich właściwą reprezentację. Każdy plik w sieci IPFS ma swój unikalny identyfikator oparty na kryptograficznej funkcji skrótu (cryptographic hash), który generowany jest w oparciu o jego zawartość. Oznacza to, że niezależnie od nazwy jeżeli dwa pliki będą miały tą samą zawartość wtedy otrzymają również ten sam identyfikator. Przykład takiego identyfikatora:

/ipfs/QmVBEScm197eQiqgUpstf9baFAaEnhQCgzHKiXnkCoED2c

Po wprowadzeniu do pliku choćby minimalnych zmian jego identyfikator również ulegnie zmianie. Podobnie jest z folderami, hash folderu generowany jest na podstawie jego zawartości więc dorzucenie lub usunięcie pliku zmieni jego identyfikator. W ten sposób otrzymujemy sieć permanentnych plików, gdzie każda zmiana tworzy nową wersję pliku. Od razu rodzi się pytanie w jaki sposób znaleźć najnowszą wersję jakiegoś pliku?

Dla uproszenia załóżmy, że nasz znajomy prowadzi bloga w formie pojedynczego pliku blog.html. Znając identyfikator tego pliku jesteśmy w stanie bez problemu go pobrać. Wiemy jednak, że plik jest codziennie aktualizowany a skoro jest modyfikowany to jego kolejne wersje mają nowe nieznane nam identyfikatory. Jeżeli interesuje nas zawsze najnowsza wersja pliku to jak znaleźć najnowszy identyfikator?

Każdy węzeł sieci IPFS ma również swój unikalny identyfikator, którego możemy użyć posługując się IPNS czyli międzyplanetarnym systemem nazw (InterPlanetary Name Space). Każdy kto miał styczność z GIT-em na pewno kojarzy znacznik HEAD, który określa nam, która z wersji jest obecnie traktowana jako najnowsza.

[HEAD] ----- > trzecia wersja
               druga wersja
               pierwsza wersja

Podobnie w przypadku identyfikatora węzła może on wskazywać na konkretny identyfikator pliku czy folderu.

/ipns/hash-wezla  -->  /ipfs/hash-najnowszej-wersji-pliku-blog-html

Istnieje też opcja skorzystania z serwerów DNS i użycia domen jako wskaźnika na dany hash węzła czy pliku/folderu. Wtedy możliwe jest użycie nazwy typu:

/ipns/example.com

ale jak się domyślacie centralna sieć DNS nie bardzo wpasowuje się w filozofię sieci rozproszonej, dlatego to bardziej ciekawostka lub element przejściowy.

W ten właśnie sposób jesteśmy w stanie zapewnić dynamiczną treść w sieci niemodyfikowalnych plików.

3. Własny węzeł

Aby zacząć korzystać z sieci IPFS musimy uruchomić własny węzeł, który po wystartowaniu odszuka inne węzły znajdujące się w jego otoczeniu i pozwoli nam stać się częścią sieci. Obecnie istnieją dwie implementacje węzła:

  • go-ipfs - napisana w języku Go i najszybciej aktualizowana
  • js-ipfs - implementacja w JavaScripcie, która może być wykorzystana przez silnik Node.js lub przeglądarkę.

Ja obecnie używam implementacji w go, ponieważ ma bardzo przyjazny interfejs konsolowy a w dodatku odpowiednia paczka jest już w repozytorium Archlinuksa, więc jej instalacja sprowadza się do:

# pacman -S go-ipfs

Po instalacji należy zainicjować nasz węzeł, co wygeneruje startową konfigurację razem z unikalnymi kluczami, którymi będzie posługiwał się nasz węzeł.

$ ipfs init
initializing IPFS node at /home/trojkat/.ipfs
generating 2048-bit RSA keypair...done
peer identity: QmegHuTrDEN2j4SATDpE7U6nXW81hd1Ropph7EPkP4EXhS
to get started, enter:

ipfs cat /ipfs/QmegHuTrDEN2j4SATDpE7U6nXW81hd1Ropph7EPkP4EXhS/readme

Po wydaniu tego polecenia zobaczymy:

$ ipfs cat /ipfs/QmVLDAhCY3X9P2uRudKAryuQFPM5zqA3Yij1dY8FpGbL7T/readme
Hello and Welcome to IPFS!

██╗██████╗ ███████╗███████╗
██║██╔══██╗██╔════╝██╔════╝
██║██████╔╝█████╗  ███████╗
██║██╔═══╝ ██╔══╝  ╚════██║
██║██║     ██║     ███████║
╚═╝╚═╝     ╚═╝     ╚══════╝

If you're seeing this, you have successfully installed
IPFS and are now interfacing with the ipfs merkledag!

 -------------------------------------------------------
| Warning:                                              |
|   This is alpha software. Use at your own discretion! |
|   Much is missing or lacking polish. There are bugs.  |
|   Not yet secure. Read the security notes for more.   |
 -------------------------------------------------------

Check out some of the other files in this directory:

  ./about
  ./help
  ./quick-start     <-- usage examples
  ./readme          <-- this file
  ./security-notes

Oczywiście zachęcam do odwiedzenia strony quick-start, ale teraz zajmiemy się najważniejszym - uruchomieniem węzła:

$ ipfs daemon
Initializing daemon...
Adjusting current ulimit to 2048...
Successfully raised file descriptor limit to 2048.
Swarm listening on /ip4/10.3.217.65/tcp/24800
Swarm listening on /ip4/127.0.0.1/tcp/4001
Swarm listening on /ip4/192.168.1.103/tcp/4001
Swarm listening on /ip6/::1/tcp/4001
API server listening on /ip4/127.0.0.1/tcp/5001
Gateway (readonly) server listening on /ip4/127.0.0.1/tcp/8080
Daemon is ready

Lub z wykorzystaniem systemd:

$ systemctl --user start ipfs.service

Węzeł posiada własny webowy interfejs, który możecie znaleźć odwiedzając adres http://localhost:5001/webui

IPFS webui

Można znaleźć tam również zakładkę z ciekawą wizualizacją wszystkich węzłów, które wykrył nasz węzeł.

IPFS webui: połączenia

Działający węzeł pozwala nam już operować na rozproszonej sieci IPFS. Przetestujmy:

$ ipfs get /ipfs/QmcniBv7UQ4gGPQQW2BwbD4ZZHzN3o3tPuNLZCbBchd1zh -o movie.mp4

Gratulacje, właśnie staliście się użytkownikami sieci rozproszonej! Teraz możecie również zacząć udostępniać własne pliki:

$ ipfs add example.jpg
added QmbFMke1KXqnYyBBWxB74N4c5SBnJMVAiMNRcGu6x1AwQH example.jpg

O wiele, wiele więcej

Jeżeli dotrwałeś aż do tego zdania to znaczy, że prawdopodobnie temat Cię zainteresował i jesteś gotów na więcej. Wszystko co tu przedstawiłem to zaledwie liźnięcie obszernego tematu jakim jest IPFS. Za jego opracowaniem stoją ludzie z Protocol Labs i to do nich najlepiej zwrócić się po szczegółowe informacje. Ich twarzą na konferencjach a zarazem głównym pomysłodawcą protokołu jest Juan Benet dlatego nikt lepiej niż on nie opowie o tym projekcie (po angielsku).

A tu krótkie demo działania:

Garść linków:

Podsumowanie

x) Niezwykle rzadko zdarzało się w historii ludzkości, żeby jakiś nowy wynalazek nie był związany z którąś ze znanych już technologii czy teoriami, które rozważano już od wielu lat. Nasza obecna kultura remiksu przerabiająca dobrze znane idee i rozwiązania sprawdza się doskonale i ma na koncie wiele znakomitych technologii i wynalazków. Dlatego kiedy usłyszałem o składnikach, jakich użyto to przyrządzenia IPFS-a od razu pomyślałem, że ktoś dokładnie odrobił zadanie domowe. Wystarczy wspomnieć o drzewach skrótów używanych przez Git-a czy Bitcoina dodać to tego BitTorrenta, z którego wyjmujemy czułe punkty jakimi są trackery i pomnożyć to przez ulepszone rozproszone tablice mieszające. Brzmi ciekawe jeszcze przed implementacją.

y) Jak każda rodząca się technologia również IPFS musi przejść swój okres niemowlęcy, odkryć ślepe uliczki i znaleźć rozwiązania problemów, które dopiero pojawią się na horyzoncie. Jednak patrząc na obecne technologie takie jak bezstanowy protokół HTTP też można by powiedzieć, że nie nadają się do użytku. Ale przecież nie logujemy się do naszego ulubionego serwisu po każdym odświeżeniu strony, ponieważ tam gdzie jest problem wkrótce pojawia się też rozwiązanie - ciastka z identyfikatorem sesji. Również IPFS ma przed sobą wiele pytań, na które nikt nie znalazł jeszcze wystarczająco dobrej odpowiedzi, ale jak na razie nawet samo śledzenie procesu projektowania jest dla mnie niezwykle ciekawe. Zwłaszcza gdy mamy okazję dołożyć swoją choćby małą cegiełkę. W końcu ludzie do dzisiaj odwiedzają stronę z pierwszym commitem Linusa.

z) Coraz częściej słyszy się zarówno w Polsce jak i w innych krajach o mniej lub bardziej udanych próbach kontroli internetu. Wymówek zawsze jest wiele: walka z pedofilią, terroryzmem czy Fake News™. Ostatecznie jednak wszystko sprowadza się do tego samego: ściślejszej kontroli obywateli, zamykaniu niewygodnych portali czy odcinaniu niewygodnych osób/grup od ich wpływu na społeczeństwo. W takim świetle bardzo ciekawe rysuje się scenariusz, w którym kilku gości z klawiaturami przekonfigurowuje tak strukturę sieci, że przestaje ona być możliwa do kontroli, niezależnie od tego jak wysoko siedzi osoba, której się to nie podoba.