15 декабря в тестовой сети Эфириума Ropsten размещена альфа-версия платформы Swarm – службы распределенного хранения файлов. Основная цель Swarm – обеспечение децентрализованного и неограниченного хранилища публичных записей Эфириума, в частности, библиотек кода Dapps, их данных, а также данных блокчейна.

Согласно первоначальной дорожной карте создателей Эфириума, децентрализованная сеть будущего – Web 3.0 будет состоять из трех компонентов:

  • Децентрализованный виртуальный компьютер: Эфириум
  • Облачная децентрализованная система хранения информации: Swarm
  • Коммуникации в децентрализованной сети: Whisper

Начало публичного тестирования Swarm знаменует начало нового этапа развития сети. Структура Swarm предполагает глубокую интеграцию с сетью и блокчейном Эфириума на уровне мультипротокола devp2p, и будет отвечать за службу доменных имен (Эфириум предполагает присвоение публичным адресам доменных имен, подобно тому, как это принято в WWW), сервисные платежи и подтверждение доступности контента. Следует, однако отметить, что в альфа-версии PoC 0.2, развернутой на тестовой сети, система сервисных платежей пока отключена – она будет доступна, начиная с PoC 0.4: это означает, что любой пользователь сможет держать контент Swarm на своем компьютере и получать за это вознаграждение.

Среди других систем распределенного хранения Swarm выделяется двумя особенностями. Такие службы, как Bittorrent, Zeronet, IPFS, дают возможность регистрации и общего доступа к контенту, который пользователи держат на своих серверах, однако Swarm сам является провайдером и обеспечивает хостинг в качестве децентрализованного сервиса облачного хранения. На практике это означает возможность «загрузить и исчезнуть»: пользователь загружает контент в Swarm и может получить его обратно в любое время, и все это без обращений к жесткому диску. Swarm – это хранилище и служба доставки, после того, как он достигнет рабочей функциональности, диапазон использования будет расширен: от интерактивных веб-приложений реального времени, до гарантированного хранения редко используемого контента.

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

По мнению авторов Эфириума, блокчейн в сочетании с P2P технологиями дает возможность создания полностью децентрализованного интернета. Идея трех отдельных протоколов ( SHH для Whisper, BZZ для Swarm и ETH для блокчейна) была представлена в мае 2014 года Гэвином Вудом и Виталиком Бутериным, которые опубликовали свое видение экосистемы Эфириума, как интернет будущего – Web 3.0. Можно сказать, что смарт-контракты мотивирующих алгоритмов представляют собой коллективный разум, или разум улья Swarm (Swarm – рой).

Принципы работы Swarm

Swarm представляет собой сеть, сервис и протокол (набор правил). Сеть Swarm состоит из узлов, исполняющих протокол BZZ, который для коммуникации между узлами использует уровень devp2p/rlpx Эфириума. Протокол BZZ определяет способы взаимодействия. На базовом уровне Swarm – распределенное хранилище фрагментов данных с контент-адресами. Фрагменты данных – это произвольные блоки данных с фиксированным максимальным размером (сейчас 4 кб). Контент-адрес означает, что адрес любого фрагмента детерминированно вычисляется из его контента. Упрощенная схема адресации: фрагмент считается входом, и возвращает 32-байтный ключ в качестве выхода. Получаемый хэш необратим, стоек к коллизиям, а распределение равномерно (примерная схема биткойна, так же работает и PoW).

хэш фрагмента является адресом, по которому клиенты могут извлечь фрагмент (прообраз этого хэша). Необратимая и стойкая к коллизиям адресация обеспечивает и защиту целостности данных: независимо от контекста, если клиент знает адрес, он может по его хэшу определить, был ли фрагмент поврежден или изменен. Ресурсы (диск, память, полоса пропускания, CPU) узлов , из которых состоит Swarm служат для хранения фрагментов. Но как определяется, кто будет хранить фрагмент? Узлы имеют адреса (хэш адреса их аккаунта BZZ), которые хранятся там же, где и сами фрагменты.

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

Swarm использует набор соединений TCP/IP, в которых каждый узел имеет набор (квази-) перманентных пиров. Все коммуникации между узлами транслируются от узла к узлу, перемещаясь по активным соединениям между пирами. Узлы активно управляют соединениями пиров, чтобы поддерживать набор соединений, который обеспечит синхронизацию и извлечение контента с помощью маршрутизации, основанной на ключах. Таким образом, и хранение фрагментов, и запросы на выдачу контента всегда могут быть эффективно направлены с помощью соединений между пирами к узлам, находящимся ближе всего к адресам контента.

В сочетании с мотивационной системой Swarm, собственный рациональный интерес узла диктует оппортунистическое поведение кэширования: узел кэширует все транслируемые фрагменты локально, так чтобы он смог обслужить их, как только придет запрос. Вследствие этого поведения, популярный контент избыточно копируется в сети, уменьшая задержки при выдаче – авторы называют этот процесс «автомасштабирование сети». Более того, такая стратегия кэширования защищает оригинальных хранителей контента от потенциальных DoS атак. Swarm мотивирует узлы кэшировать весь контент, который проходит через них, до тех пор, пока остается свободное пространство. Установлено, что кэширование фрагментов со средней частотой использования всегда является оптимальной стратегией, даже если ради этого приходится удалять старые фрагменты.

Лучшим предсказателем спроса на фрагмент является частота запросов на него в прошлом. Поэтому, рациональное поведение требует удаления фрагментов, которые давно не запрашивались. Так, контент, который теряет актуальность, или никогда не запрашивался, будет перемещен в корзину и удален, если он не защищен «страховкой». Это приводит к тому, что узлы полностью задействуют свои ресурсы для эффективного обслуживания пользователей. Такое органичное автомасштабирование делает Swarm максимально эластичным облаком.

Документы и хэш в Swarm

Следующий вопрос: откуда берутся фрагменты?

Фрагментатор Swarm находится на уровне API. Фрагментатор получает любой исходник, например, текстовый или видеофайл, и делит его на фрагменты фиксированного размера. Это фрагменты данных, их другое название – листовые фрагменты (leaf chunks). Они хэшируются и синхронизируются с пирами. Затем хэши фрагментов данных сами упаковываются во фрагменты (промежуточные фрагменты) и процесс повторяется. Сейчас в один фрагмент входят 128 хэшей. 

В результате, данные оказываются представлены деревом Меркла, а корневой хэш дерева служит адресом, по которому пользователь извлекает загруженный файл. При получении файла, пользователь берет корневой хэш и получает его прообраз, и если он оказывается промежуточным фрагментом, то он интерпретируется как последовательность хэшей – адресов фрагментов на низшем уровне. Так процесс достигает уровня данных и выдается оригинальный контент. Дерево Меркла фрагментов обеспечивает защиту целостности содержимого даже на «тяжелых» видеофайлах.

Манифесты и URL

На вершине дерева Меркла фрагментов Swarm размещает ключевой третий слой контента: файлы манифестов – json массивы записей. Такая запись определяет путь, тип контента и хэш, указывающий на контент. Манифесты позволяют создавать виртуальные сайты, хостинг которых обеспечивает Swarm, и он же обеспечивает адресацию этих сайтов, основанную на URL. Записи манифеста могут указывать на другие манифесты, так что они могут быть рекурсивно встроены один в другой, а это позволяет кодировать манифест в виде сжатого дерева (compact trie), эффективно масштабируя огромные массивы данных (например, Википедия или Youtube). Манифест также можно представить как карту сайта, или таблицу маршрутизатора, которая сопоставляет строки URL и контент. Поскольку каждый шаг процедуры представляет собой структуру Меркла или адрес контента, манифест обеспечивают защиту целостности данных для всего сайта.

Манифесты можно читать с помощью протокольной схемы bzzr url. Пример – приложение Swarm Explorer, аналогичный стандартному браузеру сети.

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

Если же нужно постоянно обновлять содержимое сайта, то необходимо использовать изменяемые адреса, основанные на службе имен. Здесь встречаются блокчейн, Сервис Имен Эфириума и доменные имена. Более продвинутый (и сложный) способ отслеживать изменения, это использование контроля версии, например git, или mango – git, использующий Swarm или IPFS в фоновом режиме.

Сервис Имен Эфириума

Чтобы вносить изменения или обновлять данные, нужна система доменных имен. Для сервиса доменных имен необходим блокчейн и соответствующий механизм. Для преобразования доменных имен в хэши Swarm использует Ethereum Name Service (ENS). Для приобретения доменов и управления ими используются специальные инструменты. Здесь важнейшим звеном является ENS, поскольку это мост между блокчейном и Swarm.

Дорожная карта Swarm

Вслед за Swarm 0.2, опубликованным 15 декабря, последует более амбициозная версия 0.3 с полностью переписанным сетевым уровнем и новым протоколом синхронизации. Будут добавлены каналы приватно коммуникации и дополнительное маскирование файлов. В расширенные спецификации манифестов будет включена поддержка заголовков http и метаданные.

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