DOI :: [UK], [IPFS], [DNS] | Введення в IPFS,

Введення в IPFS

cubly.ru

12 хв

17 листопада 2021 р

Переглянути оригінал

З'ясуємо, що таке IPFS.

IPFS (InterPlanetary File System) – це розподілена система для зберігання та доступу до файлів, вебсайтів, додатків та даних.

IPFS – це пірингова мережа зберігання даних. Контент доступний через однорангові вузли, розташовані в будь-якій точці світу, які можуть передавати інформацію, зберігати її або робити те й інше. Принцип роботи IPFS схожий з роботою BitTorrent-клієнтів, IPFS теж використовує розподілені хеш-таблиці ( DHT ) і здатний за секунди знайти учасників мережі, які можуть поділитися файлами, що запитуються. Щоб зрозуміти, які це дає переваги, варто зрозуміти різницю в тому, як ми серфімо звичний нам інтернет і як це відрізняється від підходу IPFS.

Коли ми користуємося браузером, для доступу до контенту ми використовуємо URL ( Uniform Resource Locator ), який говорить, де ми можемо знайти той чи інший контент. Приклад такої адресиhttps://mysite.com/my_perfect_book.pdf

Що ми можемо зрозуміти з цієї адреси? Файл називається my_perfect_book.pdf, знаходиться на сайті mysite.com, IP-адреса якого ми можемо дізнатися за допомогою DNS . Нам невідомо нічого про вміст контенту, поки ми не завантажимо його, більше того, вміст може змінюватися з часом, так ми можемо завантажити зовсім не те, що очікували . Також є ризик того, що матеріали будуть піддані цензурі (можливо, навіть помилково ), або сайт просто припинить своє існування.

У IPFS, на відміну класичного вебу, використовуються адреси такого виду: QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco, звані Content Identifier (скорочено CID ). На відміну від традиційних URL , які вказують на те, де файл розташований, адреси IPFS створюються на основі вмісту контенту (якщо точніше обчислюється криптографічний хеш ). Це дає нам дві переваги:

1. Ми завжди можемо перевірити, що завантажені нами дані не були підмінені будь-ким, просто порахувавши для нього хеш-функцію. Якщо хоч один байт файлу відрізняється, хеші просто не збігатимуться, і IPFS відкине такий файл.

2. Так як адреса вказує не "звідки", а "які" отримати дані, їх стає набагато складніше піддати цензурі. Файли можуть знаходитися відразу в кількох сховищах, в кеші користувачів IPFS, тому навіть якщо повністю заблокувати весь зовнішній інтернет, дані можна буде отримати, якщо вони залишилися в сховищі хоча б у одного бенкету.

Як влаштований IPFS? ⌗

Для розуміння IPFS необхідно розібрати 3 фундаментальні принципи:

1. Унікальна ідентифікація ресурсу за допомогою контентної адресації

2. Зв'язування контенту за допомогою спрямованих ациклічних графіків (DAGs)

3. Виявлення контенту за допомогою розподілених хеш-таблиць (DHTs)

Контентна адресація в IPFS ⌗

Даний пункт ми вже частково розібрали вище, для кожного образу даних створюється Content Identifier ( CID ) – хеш-сума, яка унікально адресує ці дані. Насправді, крім хеш-суми, CID містить версію (зараз їх існує дві, CID версії 0 починаються на Qm, CID версії 1 влаштовані дещо складніше і містять префікс способу кодування CID і формат вмісту , щоб програми знали, як інтерпретувати контент) . На офіційному сайті є зручна сторінка , яка показує, як інтерпретувати CID.

Що таке Merkle DAG та як це використовується в IPFS? ⌗

Бинарное хеш-дерево

Дерево Меркла (або Дерево Хешей) - це повне двійкове дерево, листя якого містить хеші блоків даних, а внутрішні вершини містять хеші від складання значень у їхніх дочірніх вершинах. У IPFS замість хешей використовуються Content Identifier.

Така структура дозволяє IPFS пов'язувати складні структури, наприклад цілу папку файлів або git-репозиторій. Великі файли в IPFS розбиваються на чанки (розмір яких залежить від типу контенту), відповідно, при завантаженні великого файлу в IPFS також буде побудовано дерево хешів, що має свій CID і вказує на CID кожного чанка. Існує спеціальний інструмент , що наочно показує такі дерева.

Якщо раптом ми вирішимо змінити частину файлу та опублікувати нову версію в IPFS, хеш листя, що відповідає за змінені блоки даних, зміниться, внаслідок чого зміняться хеші їхніх батьківських елементів, аж до кореневого. Однак хеш того листя, контент блоків яких не змінився, залишиться тим самим, відповідно, новий і старий файл, хоч і матимуть різні CID, але посилатимуться на одні й ті самі CID збігаються блоків даних. Таким чином досягається дедуплікація контенту.

Виявлення контенту за допомогою DHT ⌗

Хеш-таблиця - це звичайна таблиця з двома полями: ключ і значення. Розподілена хеш-таблиця - це таблиця, яка розділена між усіма бенкетами в розподіленій мережі. Щоб знайти контент, необхідно запитати про нього серед своїх бенкетів.

Після того, як IPFS дізнається, де знаходиться контент (а якщо бути точніше, у яких бенкетів зберігаються блоки даних, з яких складається завантажуваний контент), IPFS використовує DHT ще раз, щоб дізнатися, де ці бенкети знаходяться на даний момент (процедура маршрутизації) .

Тепер ми знаємо, які бенкети мають потрібний нам контент і як з цими бенкетами зв'язатися. Потім IPFS зв'язується з цими бенкетами, відправляє їм список бажань (CID блоків, які ми хочемо отримати), а бенкети відправляють ці блоки. Після отримання блоків даних IPFS генерує CID на основі отриманих даних, щоб звірити його з CID, який ми запросили. Таким чином можна перевірити, що дані не були ніким підмінені.

А де зберігаються дані? ⌗

Дані, що публікуються в IPFS, зберігаються на нодах — учасниках мережі. Якщо ви створювали свої торрент-роздачі, ви знаєте, що спочатку файли є тільки у вас, ви публікуєте їх та роздаєте іншим учасникам. Якщо ви не встигнете нікому віддати свою копію файлів і вимкніть свій комп'ютер, ніхто не зможе завантажити ваші дані, тому потрібно дочекатися, поки хоча б кілька людей їх скачають і почнуть роздавати, перш ніж самому йти з роздачі.

Список закріплених файлів на локальній ноді

В IPFS все відбувається схожим чином. Як тільки ви публікуєте будь-який контент на локальній ноді, він "закріплюється" ( pinning ), IPFS буде зберігати його вічно на вашому пристрої, доки ви не відкріпите його ( unpin ). Коли хтось запитає контент, який є у вас, він автоматично збереже його копію до свого локального кешу. Однак, слід мати на увазі, що даний кеш не перманентний, отже, з часом той бенкет перестане роздавати цю інформацію, якщо до неї ніхто довго не звертався. При цьому ніхто не забороняє іншому бенкету також "закріпити" завантажені від вас файли, тоді він продовжить роздавати їх разом з вами.

Користувачі IPFS закріплюють собі ту інформацію, яку вважають цінною для себе, тому інформація, яка ніким не закріплена (а значить, нікому не представляє цінності), згодом видаляється для економії місця.

Зрозуміло, що тримати опубліковану інформацію на своєму особистому пристрої і постійно роздавати її — не завжди зручно, для вирішення цієї проблеми на допомогу приходять Pinning Services , по суті, це можна вважати хмарним сховищем, куди можна завантажити свої дані, щоб вони завжди були доступні в IPFS.

Інтеграція з всесвітнім павутинням ⌗

Для інтеграції з існуючим вебом існує дві технології, які використовуються спільно: IPFS Gateway і DNSLink

Шлюз IPFS

Шлюз IPFS — це сервер, який дозволяє отримати доступ до файлів у мережі IPFS з браузерів, які безпосередньо не підтримують доступ до IPFS. Шлюз можна підняти у себе локально, або користуватися громадським, наприклад https://ipfs.io . Слід зазначити, що при використанні шлюзу ви не зможете перевіряти CID завантажених файлів на клієнтському пристрої, тому ви повинні довіряти шлюзу або не користуватися ним зовсім.

DNSLink⌗

DNSLink використовує TXT-записи DNS для того, щоб закріпити CID за певним доменом. Наприклад, ми можемо дізнатися, що домен ipfs.io вказує на CID Qmf6DcRku4QUBjkToCSj3dMkhipUgg1NURYSMUFNsj1jsF:

$ dig +noall +answer TXT \_dnslink.ipfs.io
\_dnslink.ipfs.io. 30 IN TXT "dnslink=/ipns/website.ipfs.io"

$ dig +noall +answer TXT \_dnslink.website.ipfs.io
\_dnslink.website.ipfs.io. 30 IN TXT "dnslink=/ipfs/Qmf6DcRku4QUBjkToCSj3dMkhipUgg1NURYSMUFNsj1jsF"

Як видно з прикладу вище, TXT-запис _dnslink.ipfs.ioвказував на адресу /ipns/website.ipfs.io, а website.ipfs.ioв свою чергу, вказує на конкретний IPFS CID.

Тут варто ще згадати IPNS (InterPlanetary Name System) . IPNS дозволяє створювати довгі адреси виду k5..., які посилаються на конкретний CID і можуть бути оновлені вами. Таким чином, при завантаженні нової версії файлу у вас не буде необхідності розсилати всім новий CID, користувачі відразу дізнаються його, звертаючись до даних по IPNS. DNSLink є альтернативою IPNS, використовуючи доменні імена замість довгих хешей. DNSLink працює швидше і легко запам'ятовується, однак потрібно розуміти, що DNS-сервера можуть бути блоковані, або їх відповідь може бути підмінена, якщо ви не використовуєте DoH або DoT .

Як користуватися ⌗

Можна поставити собі консольну утиліту ipfs-cli або десктопний клієнт , який включає IPFS-ноду і файловий менеджер, а також розширення для браузера , яке дозволить відкривати IPFS-посилання у своєму браузері, використовуючи локальну ноду.

У цій статті як приклад ми створимо односторінковий сайт-резюме, опублікуємо його в IPFS, використовуючи один із pinning-сервісів, і налаштуємо DNS, щоб при відкритті нашого сайту зі звичайного браузера користувачі могли його побачити.

Створення односторінкового сайту-резюме ⌗

Нам потрібно підготувати статичну версію сайту, простий набір сторінок. На цьому етапі довго зупинятися не будемо, на цій сторінці можна знайти покрокову інструкцію щодо створення такого сайту за допомогою генератора Hugo ( а ось тут можна знайти інструкцію російською мовою ).

bash Создаём заготовку статичного сайта

# Устанавливаем Hugo

snap install hugo

# Создаем основу вебсайта

hugo new site my-website
cd my-website

# Устанавливаем тему

# Список существующих тем: <https://themes.gohugo.io/>

git init
git submodule add <https://github.com/gurusabarish/hugo-profile.git> themes/hugo-profile

# Включаем тему

rm config.toml
cp ./themes/hugo-profile/website/v3.yaml ./config.yaml
sed -i 's/\\.\\/\\.\\./hugo-profile/g' ./config.yaml

# Редактируем созданную конфигурацию под себя

vim ./config.yaml

# Запускаем сервер для просмотра получившегося сайта

hugo serve

Переходимо за посиланням http://localhost:1313 і бачимо сайт, що вийшов:

Односторінковий сайт на типовому шаблоні hugo-profile від Guru Sabarish

Тепер ми можемо ввести команду hugo і наш сайт скомпілюється в папку public. Вміст цієї папки ми будемо публікувати в IPFS.

Публікація файлів у IPFS ⌗

Щоб нам не доводилося тримати свій комп'ютер постійно увімкненим, скористаємося одним із Pinning сервісів . Я вибрав Pinata , він надає 1ГБ безкоштовного сховища і не вимагає прив'язування банківської картки.

Після реєстрації та завантаження папки public на сайт, ми отримуємо CID, за яким ми можемо переглянути наш вміст:

Жовтим виділено Content Identifier завантаженої папки

Натиснувши на значок ока ліворуч, ми можемо переглянути наш сайт у браузері (як можна помітити, я вибрав інший шаблон для свого сайту):

Цей сайт, завантажений в IPFS та відкритий через IPFS Gateway

Також ми можемо відкрити програму IPFS Desktop і переглянути вміст папки з сайтом, ввівши CID у поле у ​​верхній частині інтерфейсу. Папка може завантажитись не відразу, слід почекати, поки IPFS знайде бенкетів, у яких вона є.

Вміст нашої папки із сайтом, завантаженим у мережу IPFS

Запам'ятаємо наш CID, він стане нам у нагоді пізніше, коли ми будемо налаштовувати свій домен: QmZkSWaUY1dTeCNokmBdV9rS2SgRBGvTzbA2Xk49EPc6FE.

Настройка DNS, часть 1⌗

Останнім етапом буде асоціація нашого доменного імені з Content Identifier (пам'ятаєте, ми говорили про DNSLink ?). Вважатимемо, що у вас вже є власне доменне ім'я та доступ до налаштування його DNS-записів.

У моєму розпорядженні є доменне ім'я cubly.ru , DNS-записи якого керуються через Cloudflare. Щоб сайт був доступний за нашим доменом імені користувачам IPFS, нам необхідно створити TXT-запис з ім'ям _dnslink.<доменное_имя>та значенням dnslink=/ipfs/<ваш_CID>.

TXT-запис, що вказує на CID моєї папки

Після цього наш сайт став доступний для користувачів IPFS крім адреси /ipfs/QmZk.. через більш лаконічну адресу /ipns/cubly.ru ( подивитися через IPFS Gateway ).

Якщо ми встановимо плагін IPFS Companion та спробуємо відкрити сайт cubly.ru у браузері, плагін автоматично визначить, що сайт доступний в IPFS (знайшовши створений нами TXT-запис) та переадресує на наш локальний Gateway: http://cubly.ru.ipns. localhost:8080 . Наш локальний IPFS Gateway переконається, що всі завантажені браузером файли справжні, підрахувавши їх хеш суми.

TXT-запис, що вказує на CID моєї папки

Як видно на скріншоті, у плагіні є опція "Import to Files on My Node". Ми можемо натиснути на неї, щоб імпортувати вміст сайту на нашу IPFS-ноду і роздавати вміст сайту вже зі свого комп'ютера, щоб сайт відкривався швидше у користувачів, які знаходяться у вашому місті, доки IPFS Desktop запущено. Якщо ви закриєте його, то сайт все одно залишиться доступним, адже він є на Pinata і в інших нод, які встигли закешувати його, просто вашим сусідам доведеться почекати, поки їх IPFS нода знайде інші бенкети.

Настройка DNS, часть 2⌗

Ми налаштували запис DNSLink, і сайт став доступний за зручним ім'ям для користувачів IPFS, але що робити з користувачами, які ще не користуються Web 3.0?

Все до банальності просто: ми налаштуємо запис CNAME, який перенаправить всіх звичайних користувачів на публічний IPFS Gateway. Так як я користуюся Cloudflare, буде логічно скористатися власним IPFS Gateway: cloudflare-ipfs.com. Почитати про нього можна в блозі Cloudflare .

Нам досить просто додати CNAME-запис на наш домен і перевірити, що сайт відкривається з будь-якого пристрою:

Додавання запису CNAME на домен cubly.ru

Майте на увазі, що за стандартом, CNAME-запис неможливо застосувати на кореневий домен, Cloudflare автоматично підставляє IP-адресу cloudflare-ipfs.com у наш запис. Якщо ваш DNS-провайдер не вміє робити це автоматично, можна створити запис A, що вказує на IP cloudflare-ipfs.com:

$ nslookup cloudflare-ipfs.com

Non-authoritative answer:
Name: cloudflare-ipfs.com
Address: 104.17.64.14
Name: cloudflare-ipfs.com
Address: 104.17.96.13
Name: cloudflare-ipfs.com
Address: 2606:4700::6811:400e
Name: cloudflare-ipfs.com
Address: 2606:4700::6811:600d

Створюємо A-запис, який вказує на IP Cloudflare IPFS Gateway

Тепер сайт повинен стати доступним для всіх користувачів, у тому числі тих, хто не користується IPFS. Як видно зі скріншота нижче, IPFS Companion вимкнено, а сайт продовжує відкриватися.

Розміщений в IPFS сайт доступний всім користувачам

Итог⌗

В результаті ми з вами познайомилися з IPFS та принципом її роботи, а також опублікували свій сайт у спільній мережі, забезпечивши доступ до нього користувачам IPFS та Web. Переглядаючи сайт, користувачі IPFS зберігатимуть його ресурси у своєму кеші, збільшуючи його доступність, швидкість його завантаження та роблячи його більш розподіленим.

У IPFS маса застосувань, кілька з них:

Приєднуйтесь до становлення розподіленого Інтернету ✌️

Просмотры: