Миграция в WEB 3.0

Сегодня мы разберем с вами процесс написания децентрализованного сайта.

Домены ENS сейчас в основном используют для указывания на IPFS.

Имеется файл. Он публикуется в IPFS, и у него появляется хеш.

Этот хеш всегда одинаков, на этот хеш можно указать домен.

Домены ENS устроены таким образом, что пользователи в качестве записи у себя в домене указывают ссылку на ресурс в IPFS.

Необходимо понимать, что IPFS — это только статические файлы.

Серверные движки, WordPress, системы изменения новостного контента - это все не имеет отношения к IFPS.

Мы не можем применять для этих доменов традиционные движки.

Нет возможности дать куда-либо доступ, чтобы кто-то что-то редактировал, как это происходит при создании обычного сайта.

Обычно децентрализованные сайты генерируются и наполняются следующим образом:

• Либо верстается несколько статичных страниц, в виде простого текста в блокноте, а затем эти файлы публикуются в IPFS и на них указывается запись.
• Либо используются так называемые статичные сайто-генераторы. Пользователь пишет на своем локальном ПК несколько файлов, обычно в формате верстки Markdown. И затем из них генерируется сайт. В результате появляются несколько связанных друг с другом статичных файлов по типу HTML, которые загружаются на IPFS и на которые указывается запись.

Главный недостаток статичных сайтов в их техничности:

Вы не сможете передать доступ к редактированию для быстрого изменения текста.

Для простейших действий потребуются специальные знания.

Хочешь выделить текст курсивом, сделать его жирным, подчеркнуть?

Придется написать теги, соблюдать формат.

Такую же специфику, к примеру, имеет и GitBook: на нем нельзя редактировать статьи как в обычных редакторах.

Похожим образом готовились и переводы страниц для Tornado.Cash, возникало множество вопросов по верстке.

Имеющиеся утилиты, генераторы статичных сайтов - не слишком упрощают процесс редакции.

Предполагается что тот, кто редактирует такой сайт, достаточно подготовлен и технически ориентирован в языке разметки, знает, что такое утилиты для генерации и прочее.

В этом есть некоторый недостаток.

Давайте рассмотрим 2 существующих маршрута для запуска децентрализованного сайта на доменах IPFS и сравним достоинства и недостатки каждого пути.

Путь первый. Простой и доступный.

Использование сторонних сервисов.

Самый модный и популярный сейчас платный сервис - Fleek (Публикация либо $0 (до 3ГБ места и 50GB трафика), либо $40/мес криптовалютой).

Еще один сервис, предоставляющий возможность редактировать статьи и оформление - Forestry (Стоимость $0 usd - единичная учетная запись и $30/мес банковской картой для группового доступа).

Преимущества:

• У сервисов есть редактор, позволяющий публиковать текст без дополнительных утилит. Не требуется знание специального языка редактирования.
• Наличие готовых приятных минималистичных шаблонов. Не придется тратить время на разработку дизайна и оформления.

Но есть и недостатки. Все они связаны с потерей децентрализации.

1. Для оплаты сервиса вам потребуется не только крипта, но и банковская карта. Очевидно, что теряется конфиденциальность.
2. Учетные записи. Кому они будут принадлежать? Необходимо придумать, кому их доверить. Может возникнуть определенная ситуация, в которой пользователь, имеющий учетную запись, при желании, сможет заблокировать доступ всем остальным. И для того чтобы эту возможность ограничить, придется покупать более дорогой тариф, допускающий командный доступ к редактору.
3. Ко всему прочему, код сайта вынужден размещаться на публичном GitHub-репозитории. Что, с одной стороны, добавляет прозрачности, но вместе с тем приводит и к потере конфиденциальности. Любые ошибки и опечатки, которые будут сохранены между версиями, останутся в истории навсегда. И придется либо не разглашать репозиторий, либо писать без возможности допустить ошибку. Почему это важно? Утрируем: если кто-то случайно вставит в страницу редактора приватный ключ или другую чувствительную информацию, и затем сохранит ее, то это уедет в гитхаб. И останется в истории, поменять которую будет весьма проблематично.

В общем, это самый простой путь, с возможностью корректировать статьи, делать заголовки, удобно форматировать текст в визуальном редакторе. Использование сторонних сервисов позволяет предоставить доступ нескольким пользователям для работы над сайтом. И если вы готовы смириться с некоторой потерей децентрализации и необходимостью ежемесячно оплачивать сервисы, то на выходе вы получаете работающий в IPFS вебсайт, на который можно указывать домен ENS.

Путь второй. Тернистый, но идеологически верный.

Написание сайта вручную, без использования сторонних сервисов. Нет зависимости от оплаты, репозитория. Полный контроль и конфиденциальность. Создание сайта на IPFS выглядит в оригинальном виде именно так.

Недостатки связаны со спецификой работы.

• Нет возможности для работы команды. Писать и публиковать может только пользователь, владеющий приватным ключом, одиночно. Это увеличивает сроки разработки, но и гарантирует вам абсолютный контроль.
• Специальные знания. Для редактирования необходимо знать язык верстки. Все нюансы оформления текста прописываются вручную в блокноте, текстовом редакторе, проставляются необходимые теги. Нет привычного визуального сервиса для работы над сайтом. Верстка происходит в строго определенном формате.

Написание сайта без использования стороннего сервиса позволяет вам быть спокойным относительно ваших данных, вы свободны от оплат и возможного негативного влияния других пользователей. Да, необходимо владеть языком верстки, соблюдать множество нюансов для корректной работы сайта. Обычно, этим путем идут небольшие частные проекты, в которых нет частых обновлений и публикаций.

Резюмируем.

Оба сценария создания сайта допустимы и имеют свои преимущества.

В принципе, ничто не мешает попробовать использовать сторонний сервис, это удобно и облегчает работу. Конечно, присутствует вероятность столкновения с критикой сообщества из-за потери децентрализации. Но информацию об использовании сторонних сервисов можно и не раскрывать, если вы не ставите перед собой цель поделиться процессом создания ресурса.

Отдельно необходимо отметить, что вне зависимости от выбранного пути написания сайта, не предусмотрена возможность подписок и оповещений о выходе нового контента. Пользователи сами должны обновлять страницу.

Не имея бэкенда, сайт не сможет сам инициировать оповещение в фоне, не может принять запрос о подписке, для таких операций ему понадобится сторонний non-web3.0 сервис, выглядящий для читателя, как встройка на javascript с кнопкой "подписаться" и формой для почты. И только при условии, что такой сервис способен распознать структуру сайта и определять появление в нем новых статей.

И если нет клиента IPFS и клиента ENS, то необходимо пользоваться ссылками .link. Это еще один момент снижающий децентрализацию.

Оплата газа, стоимость и количество транзакций.

Важный момент:

Да, ее стоимость может быть выше, чем простая отправка эфира, необходимо смотреть стэк вызова NFT, их контрактов, объектов в контракте. Создание этой указывающей записи будет стоить в районе 40$ за транзакцию.

В панели ENS у домена необходимо указать постоянную ссылку в системе IFPS. Она указывается единожды и под ней будут публиковаться файлы, связанные с сайтом.

Для любых обновлений сайта, изменения контента = не потребуются новые дополнительные эфирные транзакции.

В дальнейшем потребность менять эту ссылку [то есть создавать новые эфирные транзакции] может возникнуть только в случае компрометации какой-либо информации или при необходимости отнять право публикации. Другими словами, такое случается редко.

Рассмотрим на примере.

Tornado.Cash опубликовал свою страницу с которой они рекомендуют работать.

У сайта Tornado.Cash нет никакого бэк-энда.

Сайт статичный, в нем нет разделов, нет какой-либо динамически генерируемой информации из серверной базы данных.

Это просто лицевая страница, которая все операции проводит только через браузер пользователя, обращаясь исключительно к ноде эфира, работая с транзакциями.

Статичная страница с кодом, который в браузере обращается к эфиру через посредника, публичную общеизвестную сервер-ноду эфира, и просто позволяет с ней обмениваться транзакциями.

Она просто опрашивает через браузер смотрящего, связанные транзакции, которые необходимы для работы и позволяет через нее публиковать, создавать транзакции.

И единственный способ вести многостраничные сайты в виде статичных файлов, это использовать утилиты для статичных сайт-генераторов, которые на компьютере у пользователя раскладываются в файлы и затем каждый раз публиковать их в IPFS.

Публикуя новые версии сайта, нет необходимости менять запись в ENS.

Потому мы и подчеркиваем, что потребуется всего одна транзакция. Она просто указывает на ссылку в IPFS, а контент страницы может изменяться многократно.

Может показаться странным, что контент в IPFS способен претерпевать изменения, раз в самом начале мы упоминали, что все файлы имеют хеш и обращаются по ним. Эти хеши неизменны, по этому принципу устроены NFT.

На самом деле, все NFT тоже размещают всю информацию в IPFS, полагаясь на то что ссылка в IPFS на какой-то объект в NFT будет неизменной.

И эта ссылка опирается исключительно на содержимое файла, таким образом гарантируя его неизменность.

В IPFS есть механизм IPNS, позволяющий при неизменной IPFS ссылке обновлять файлы внутри.

Поэтому вам не придется унизительно оповещать всех после каждого обновления: "Ребята, я там букву в тексте поменял, у меня теперь совсем новая ссылка, ходите по ней, а старую забудьте"..

Но для того, чтобы это работало, необходимо, чтобы кто-то держал определенный приватный ключ у себя на компьютере. Приватный ключ определит доступность по этой ссылке.

Если этот ключ будет скомпрометирован, или если его потребуется заменить, то, в этом случае, нужно будет пойти в ENS панель и создать новую транзакцию, чтобы домен ENS указывал уже на новую ссылку IPFS.

Где хранятся файлы в IPFS?

Отдельная небольшая ремарка о том, как в этом IPFS хранятся файлы, кто их хранит и где.

По рассказу звучит так, будто это некоторое облако, которое просто есть и работает.

IPFS, в некотором смысле, похож на торренты.

Когда пользователь что-то публикует в IPFS, то в исходном виде только компьютер этого пользователя раздает загруженные ресурсы.

Если кто-то зайдет по этой ссылке, то содержимое этого IPFS ресурса изначально раздается от того, кто их загрузил и объявил все эти ресурсы, то есть с компьютера загрузившего.

И для того, чтобы иметь возможность загружать файлы, кто-то, у кого есть их копия, постоянно должен быть онлайн.

Если пользователь уже посмотрел эти файлы, то их копии будут оставаться доступными до тех пор, пока эти файлы кто-то открывает, пока к ним продолжается обращение. Они будут кэшироваться на других нодах очень долго пока происходит посещение.

Но очевидно, что быть хостингом своего сайта и держать свой личный ПК для раздачи этих файлов постоянно включенным не желательно.

И здесь существуют различные варианты.

Первый вариант особенно часто практикуют NFT проекты.

• Очень маленький виртуальный сервер берется в аренду. На него ставятся клиенты IPFS, он же и выступает нодой. Сервер потребляет совершенно немного ресурсов, не требует какой-то особой тяжелой цепи блоков.
• За пару долларов в месяц вы получаете ноду и можете публиковать IPFS ресурс через неё, таким образом файлы всегда есть на этом сервере, они не исчезают из IPFS, и раздаются вне зависимости от других участников.

Второй вариант это внешние готовые сервисы, интегрированные с IPFS.

В этих сервисах работа с IPFS происходит через их собственные ноды IPFS, которые всегда онлайн.

Получается, кроме возможности удобного редактирования сайта, мы получаем и размещение файлов на сторонних нодах.

Повторимся, весь IPFS заточен на хешах файлов и полагается на то, что файлы неизменны, что достигается за счёт системы адресов в IPFS.

Поэтому нет проблемы в том, что кто-то держит это на своих других нодах. Никто не сможет подменить, изменить или поменять эти файлы.

А для того, чтобы домен всегда указывал на одну запись, и чтобы не приходилось после каждого изменения на сайте обновлять домен в ENS и указывать на другой хеш файла,

В IPFS есть возможность объявлять одну фиксированную ссылку, и загружать под ней все изменения файлов, подписывая это ключом.

Материал подготовлен командой Telegram-канала:

@Ghost_In_The_Block

Отдельная благодарность? Mode, Fantom, Bunny.