2. Обзор архитектуры¶

2.1. Предисловие¶

Swarm определяет 3 важных понятия:

chunk
Чанки — это части данных ограниченного размера (макс. 4 КБ), основная единица хранения и извлечения в Swarm. Сетевой уровень знает только о фрагментах и ​​не имеет понятия о файле или коллекции.
reference
Ссылка — это уникальный идентификатор файла, который позволяет клиентам получать и получать доступ к содержимому. Для незашифрованного содержимого ссылка на файл является криптографическим хешем данных и служит его адресом содержимого. Эта ссылка на хэш представляет собой 32-байтовый хэш, сериализованный с 64-битными шестнадцатеричными байтами. В случае зашифрованного файла ссылка имеет два компонента равной длины: первые 32 байта — это адрес содержимого зашифрованного ресурса, а вторые 32 байта — это ключ дешифрования, всего 64 байта, сериализованные как 128 шестнадцатеричных байтов.
manifest
Манифест — это структура данных, описывающая коллекции файлов; они определяют пути и соответствующие хэши контента, позволяющие извлекать контент на основе URL. Предполагается, что содержимое, на которое имеется ссылка в домене, является манифестом, и отображает запись содержимого, путь которой совпадает с путем в пути запроса. Манифесты также могут быть сопоставлены с деревом каталогов файловой системы, что позволяет загружать и скачивать каталоги. Наконец, манифесты также можно рассматривать как индексы, поэтому их можно использовать для реализации простого хранилища значений ключей или, альтернативно, индекса базы данных. Это предлагает функциональность виртуального хостинга , хранящую целые каталоги, веб-сайты web3 или примитивные структуры данных; аналогично web2.0, с удаленным централизованным хостингом.

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

  • без конфликтов (два разных блока данных никогда не будут отображаться на один и тот же идентификатор)
  • детерминированный (один и тот же контент всегда будет получать один и тот же идентификатор)
  • равномерно распределенный

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

Однако пользователи Интернета привыкли к изменяемым ресурсам, ища домены и ожидайте увидеть самую последнюю версию «сайта». Изменяемые ресурсы становятся возможными благодаря службе имен Ethereum (ENS) и фидам. ENS — это смарт-контракт на блокчейне Ethereum, который позволяет владельцам доменов регистрировать ссылку на контент для своего домена.. Используя ENS для разрешения доменных имен, схема URL-адресов обеспечивает извлечение контента на основе мнемонических (или фирменных) имен, во многом как DNS во всемирной паутине, но без серверов. Фиды — это автономное решение для передачи обновлений на ресурс, это предлагает более дешевые и быстрые обновления, чем ENS, однако обновления могут быть объединены в ENS любой третьей стороной, желающей заплатить за транзакцию.

Так же, как контент в Swarm адресуется с помощью 32-байтового хеш-кода, так каждый узел Swarm в сети связан с 32-байтовым хеш-адресом. Все узлы Swarm имеют свой собственный базовый адрес , который получается как (Keccak 256bit SHA3) хэш открытого ключа учетная запись Ethereum:

Примечание

Адрес узла Swarm = sha3 (открытый ключ учетной записи ethereum) — так называемая базовая учетная запись роя узла. Эти адреса узлов определяют местоположение в том же адресном пространстве, что и данные.

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

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

Жизнеспособность обоих шарниров зависит от предположения, что любой узел (загрузчик/запрашивающий) может « достичь » любого другого узла (хранителя ). Это предположение гарантируется специальной топологией сети (называемой kademlia ), которая гарантирует существование, а также максимальное количество переадресованных переходов, логарифмическое по размеру сети. /p>

Примечание

В Swarm нет такой вещи, как удаление/удаление. После того, как данные загружены, их невозможно отозвать.

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

2.2. Наложенная сеть¶

2.2.1. Логарифмическое расстояние¶

Метрика расстояния (MSB (x, y) ) двух байтовых последовательностей равной длины (x ) и (y ) является значением двоичного целочисленного преобразования. of (x XOR y ) (побитовое xor). Двоичное преобразование с прямым порядком байтов: сначала старший бит (= MSB).

(Proximity (x, y) ) — это дискретное логарифмическое масштабирование расстояния MSB. Оно определяется как обратный ранг целой части логарифма расстояния по основанию 2. Он вычисляется путем подсчета количества общих ведущих нулей в (MSB) двоичном представлении (x XOR y ) (0 самый дальний, 255 ближайший, 256 сам) .

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

Он также обладает тем свойством, что любые два адреса, принадлежащие одному и тому же bin почти вдвое дальше друг от друга, чем от (x ).

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

2.2.2. Топология Kademlia¶

Swarm использует пакет ethereum devp2p rlpx в качестве транспортного уровня базовой сети. Этот необычный вариант допускает полустабильные одноранговые соединения (через TCP) с аутентифицированными, зашифрованными, синхронными потоками данных.

Мы говорим, что узел имеет возможность подключения к kademlia , если (1) он связан по крайней мере с одним узлом для каждого порядка близости до (но исключая) некоторого максимального значения (d ) (называемого глубиной насыщения ) и (2) это подключен ко всем узлам, чей порядок близости относительно узла больше или равен (d ).

Если каждая точка связного подграфа имеет кадемлию связности, то мы говорим, что подграф имеет топология кадмлиа . В графе с топологией kademlia (1) существует путь между любыми двумя точками, (2) его можно найти, используя только локальные решения на каждом шаге, и (3) гарантированно завершится не более, чем за глубину места назначения. плюс один.

Учитывая набор точек, равномерно распределенных в пространстве (например, результаты хеш-функции, примененной к данным Swarm), ячейки близости отображаются на серию подмножеств с мощностью на отрицательном экспоненциальная шкала, т.е.. , PO bin 0 имеет половину точек любой случайной выборки, PO bin 1 имеет одну четвертую, PO bin 2 одну восьмую и т. Д. Ожидаемое значение глубины насыщения в сети из (N ) узлов равно (log2 ( N) ). Последняя ячейка может просто объединить все ячейки глубже глубины и называется наиболее близкой ячейкой .

Узлы в сети Swarm идентифицируются хешем ethereum адрес базовой учетной записи Swarm. Это служит их оверлейным адресом, ячейки порядка приближения вычисляются на основе этих адресов. Пиры, подключенные к узлу, определяют другую, живую таблицу kademlia, где ребра графа представляют подключения devp2p rlpx.

узел в наборе имеет насыщенную таблицу kademlia подключенных одноранговых узлов, тогда граф «живого соединения» узлов имеет топологию kademlia. Свойства графа kademlia могут использоваться для маршрутизации сообщений между узлами в сети с использованием оверлейной адресации. В пересылка кадемлии сети, сообщение считается маршрутизируемым , если существует путь от узла отправителя к узлу назначения, через который сообщение может быть ретранслировано. В зрелой подсети с топологией kademlia каждое сообщение маршрутизируется. Большая часть узлов нестабильно подключена к сети; сохраняя несколько подключенных одноранговых узлов в своих ячейках PO, каждый узел может увеличить шансы, что он сможет пересылать сообщения в любой момент времени, даже если соответствующий одноранговый узел отключается.

2.2.3. Начальная загрузка и обнаружение¶

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

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

Поскольку узел уведомляется новых одноранговых адресов, он сохраняет их в таблице kademlia известных одноранговых узлов. Пока он прослушивает входящие соединения, он также активно пытается подключиться к узлам, чтобы достичь насыщения: он пытается подключиться к каждому известному узлу, который находится в PO граница N ближайших соседей называется глубиной ближайшего соседа и (2) пытается заполнить каждую ячейку до глубины ближайшего соседа здоровыми узлами. Чтобы удовлетворить (1) наиболее эффективно, он пытается подключиться к одноранговому узлу, который больше всего необходим в любой момент времени. Низкие (дальние) ячейки более важны для заполнения, чем высокие (ближние), поскольку они обрабатывают больший объем. Заполнение пустой корзины одним одноранговым узлом более важно, чем добавление нового однорангового узла в непустую корзину, поскольку раньше это приводит к насыщению кадемлии. Таким образом, протокол использует восходящую стратегию в первую очередь в глубину для выбора однорангового узла для подключения. Узлы, которые пытались подключиться, но не смогли подключиться, повторяются с экспоненциальным откатом (т. Е. Через временной интервал, который удваивается после каждой попытки). После определенного количества попыток такие узлы больше не рассматриваются.

После подключения достаточного количества узлов ячейка становится насыщенной, и глубина насыщения ячейки может увеличиваться. Узлы продолжают сообщать о своем текущем насыщении. глубина их сверстникам, если она изменится. По мере увеличения глубины насыщения узлы будут получать уведомления о все меньшем и меньшем количестве новых сверстников (поскольку они уже знают свое окружение). Как только узел найдет всех своих ближайших соседей и заполнит все ячейки, новых одноранговых узлов не ожидается. По этой причине узел может завершить состояние насыщенного кадемлия, если он не получает новых пиров (в течение некоторого времени). Узлу не нужно знать количество узлов в сети. Фактически, через некоторое время после того, как узел перестанет получать новые одноранговые адреса, узел может эффективно оценить размер сети по глубине (глубина (n ) подразумевает (2 ^ n ) узлов)

Такую сеть можно легко использовать для системы обмена сообщениями в стиле пересылки. На этом основана PSS Swarm. Swarm также использует эту сеть для реализации своего решения для хранения.

2.3. Распределенный архив прообраза¶

Распределенные хеш-таблицы (DHT) используют оверлейную сеть для реализации хранилища ключей и значений, распределенного по узлам. Основная идея состоит в том, что пространство ключей отображается в адресное пространство оверлея, а информация об элементе в контейнере должна быть найдена с узлами, адрес которых находится в непосредственной близости от ключа. HT для децентрализованного адресного хранилища контента обычно связывают отпечатки пальцев контента с список узлов (сидеров), которые могут обслуживать этот контент. Однако ту же структуру можно использовать напрямую: это не информация о местонахождении контента, который хранится в узле, ближайшем к адресу (отпечатку пальца), а сам контент. Мы называем эту структуру распределенным архивом прообразов (DPA).

DPA придерживается мнения о том, какие узлы какой контент хранят, и это подразумевает еще несколько ограничений: (1) балансировка нагрузки содержимого между узлами требуется и достигается путем разделения содержимого на блоки равного размера ( chunking ); (2) должен существовать процесс, посредством которого блоки попадают туда, где они должны храниться ( синхронизация ); и (3) поскольку узлы не имеют права голоса в том, что они хранят, следует использовать меры правдоподобного отрицания .

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

Поскольку Swarm реализует DPA (для фрагментов по 4096 байт), ретрансляция запроса на извлечение на адрес фрагмента в качестве пункта назначения эквивалентна передаче запроса на узел хранилища. Переадресация kademlia может направлять такие запросы на извлечение по соседству с адресом блока. Чтобы доставка произошла, нам просто нужно предположить, что каждый узел, когда он пересылает запрос на извлечение, запоминает запрашивающих. Как только запрос достигает узла хранилища, может быть инициирована доставка контента и заключается в ретрансляции данных блока обратно запрашивающей стороне. (s).

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

2.3.1. Избыточность¶

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

Область полностью подключенного соседства определяет область ответственности . Узел хранилища отвечает за (хранение) фрагмента, если фрагмент попадает в зону ответственности узла. Предположим, что (1) стратегия пересылки, которая ретранслирует запросы по стабильным узлам и (2) стратегия хранения, при которой каждый узел в ближайшем окружении (из минимального количества R одноранговых узлов) хранит все куски в зоне ответственности. Пока эти предположения остаются в силе, каждый фрагмент можно получить, даже если узлы хранилища (R-1 ) одновременно отключаются. Что касается (2), нам все еще нужно предположить, что каждый узел в наборе ближайших соседей может хранить каждый фрагмент.

Дополнительные меры избыточности, например , будет реализовано в будущем.

2.3.2. Кэширование и очистка хранилища¶

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

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

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

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

2.3.3. Синхронизация¶

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

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

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

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

2.4. Уровень данных¶

Есть 4 разных уровня блоков данных, относящихся к Swarm:

  • message : p2p Сетевой уровень RLPx. Сообщения актуальны для проводных протоколов devp2p.
  • chunk : единица данных фиксированного размера в распределенном архиве прообразов.
  • файл : наименьший блок, связанный с mime-типом, целостность которого не гарантируется, если он не является полным. Это наименьшая семантическая единица для пользователя, в основном файл в файловой системе.
  • collection : отображение путей к файлам представлено манифест роя . Этот слой имеет отображение в дереве каталогов файловой системы. Учитывая тривиальные соглашения о маршрутизации, URL-адрес может быть сопоставлен с файлами стандартизированным способом, что позволяет манифестам имитировать карты сайтов/таблицы маршрутизации. В результате Swarm может действовать как веб-сервер, служба виртуального облачного хостинга.

Фактический уровень хранения Swarm состоит из двух основных компонентов: localstore и netstore . Локальное хранилище состоит из быстрого кеша в памяти ( хранилище памяти ) и постоянного дискового хранилища ( dbstore ). NetStore расширяет локальное хранилище до распределенное хранилище Swarm и реализует распределенный архив прообразов (DPA) .

2.4.1. Файлы¶

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

Компонент, который разбивает файлы на части в дереве Меркла, называется chunker . Наш chunker реализует алгоритм bzzhash , который представляет собой параллелизованный хэш дерева на основе произвольного хэша фрагмента . Когда чанкеру передается устройство чтения ввода-вывода (будь то файл или поток веб-камеры), он разбивает поток данных на фрагменты фиксированного размера, которые хешируются с использованием произвольного хэша фрагмента (в нашем случае хеша BMT, см. Ниже). Если используется шифрование, фрагмент шифруется перед хешированием. Ссылки на последовательные фрагменты данных объединяются и упаковываются в так называемый промежуточный фрагмент , который, в свою очередь, зашифровывается, хешируется и упаковывается в промежуточные фрагменты следующего уровня. Для незашифрованного содержимого и 32-байтового содержимого. chunkhash, размер блока 4K включает 128 ветвей в результирующем хеш-дереве Swarm. Если мы используем шифрование, ссылка составляет 64 байта, что позволяет иметь 64 ветви в хэш-дереве Swarm. Этот рекурсивный процесс построения хеш-дерева Swarm приведет к единственному корневому чанку, хэш чанка этого корневого чанка является хешем Swarm. файла. Ссылка на документ — это сам хэш Swarm, если загрузка не зашифрована, и хеш Swarm, объединенный с ключом дешифрования корневого блока, если загрузка зашифрована.

Когда FileStore передается ссылка для извлечения файла он вызывает Chunker, который возвращает вызывающему читателю доступный для поиска документ. Это ленивый читатель в том смысле, что он извлекает части базового документа только по мере их чтения (с некоторой буферизацией, аналогичной видеоплееру в браузере). Учитывая ссылку, FileStore берет хэш Swarm и с помощью NetStore извлекает корневой фрагмент документа. После его расшифровки, если это необходимо, обрабатываются ссылки на чанки на следующем уровне. Поскольку смещения данных можно легко сопоставить с путем к промежуточным фрагментам, произвольный доступ к документу эффективен и поддерживается на самом низком уровне. HTTP API предлагает запросы диапазона и может преобразовывать их в смещение и диапазон для API нижнего уровня, чтобы обеспечить защищенный случайный доступ к файлам с защитой целостности.

Swarm предоставляет API FileStore через схему URL-адресов непосредственно в HTTP локальный прокси-сервер (см. URL-схемы BZZ и Справочник по API). Этот API позволяет загружать файлы с помощью запроса POST, а также загружать файлы с помощью запроса GET. Поскольку на этом уровне файлы не связаны с mime-типом, для правильного отображения или обслуживания приложения к URL-адресу можно добавить параметр запроса content_type . Это установит правильный тип содержимого в HTTP-ответе.

2.4.2. Манифесты¶

Swarm manifest — это структура, которая определяет отображение между произвольными путями и файлами для обработки коллекций. Он также содержит метаданные, связанные с коллекцией и ее объектами (файлами). Самое главное, что запись в манифесте указывает тип файлов мультимедиа mime, чтобы браузеры знали, как с ними обращаться. Вы можете представить манифест как (1) таблицу маршрутизации, (2) индекс или (3) дерево каталогов, которые позволяют Swarm реализовывать (1) веб-сайты, (2) базы данных и (3) каталоги файловой системы. .Manifests предоставляют основной механизм, позволяющий использовать адресацию на основе URL-адресов в Swarm. Доменная часть URL-адреса отображается на манифест, в котором ищется часть пути URL-адреса для получения записи файла для обслуживания.

Манифесты в настоящее время представлены в виде сжатого trie () с отдельными узлами trie, сериализованными как json. Структура json имеет минимальный массив записей манифеста с путем и ссылкой (хэш-адрес Swarm). Часть пути используется для сопоставления пути URL, ссылка может указывать на встроенный манифест, если путь является общим префиксом более чем одного пути в коллекции.Когда вы получаете файл по URL-адресу, Swarm преобразует домен в ссылку в корневой манифест, который рекурсивно просматривается для нахождения подходящего пути.

Высокоуровневый API для манифестов предоставляет функциональные возможности для загрузки и скачивания отдельных документов в виде файлов, коллекций (манифестов) в виде каталогов. Он также предоставляет интерфейс для добавления документов в коллекцию по пути, удаления документа из коллекции. Обратите внимание, что удаление здесь означает только то, что создается новый манифест, в котором отсутствует рассматриваемый путь. В Swarm нет другого понятия удаления. Swarm предоставляет API-интерфейс манифеста через URL-схему bzz , см.

Этот HTTP-прокси API подробно описан в разделе «Справочник по API».

Примечание

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

2.5. Компоненты¶

Далее мы опишем компоненты более подробно.

2.5.1. Swarm Hash¶

Swarm Hash (a.k.a. bzzhash ) — это хеш, разработанный для эффективного хранения и извлечения в хранилище с адресной адресацией, как локальном, так и сетевом. Хотя он используется в Swarm, в нем нет ничего специфичного для Swarm, и авторы рекомендуют его как заменяющую замену последовательно-итеративным хеш-функциям (например, SHA3) всякий раз, когда они используются для ссылки на чувствительный к целостности контент, поскольку он составляет улучшение производительности и удобства использования без ущерба для безопасности.

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

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

Хеши блоков данных определяются как хэши конкатенации 64-битной длины (в порядке LSB-first) содержимого и самого содержимого. Из-за включения длины она устойчива, даже если базовая хеш-функция чанка не является.

Промежуточные чанки состоят из хэшей конкатенации 64-битной длины (в LSB-first order) содержимого, включенного в этот блок, за которым следуют ссылки на его дочерние элементы (ссылка — это либо хэш блока, либо хеш блока плюс ключ дешифрования для зашифрованного содержимого).

Чтобы различать Во-вторых, нужно сравнить длину фрагмента с 64-битным числом, с которого начинается каждый фрагмент. Если фрагмент ровно на 8 байтов длиннее этого числа, это фрагмент данных. Если он короче, это промежуточный фрагмент. В противном случае это недопустимый чанк Swarm Hash.

Для хеширования чанка мы используем алгоритм хеширования на основе двоичного дерева Меркла по 32-байтовым сегментам данных чанка с использованием базовой хеш-функции. . Наш выбор для этого базового хеша — это хеш Keccak 256 SHA3, используемый во всем Эфириуме. Для защиты целостности метаданные 8-байтового диапазона хешируются вместе с корнем BMT, в результате чего получается хеш BMT. BMT-хэш идеален для компактных доказательств включения.

2.5.2. Chunker¶

Chunker — это интерфейс к компоненту, который отвечает за дизассемблирование и сборку больших данных. Точнее, Splitter дизассемблирует , в то время как Joiner собирает документы заново.

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

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

Оцените статью
techsly.ru
Добавить комментарий