IPFS: Trustless gateway и CAR-ответ

Обычный шлюз может выдать готовый файл, а trustless-маршрут предоставляет данные, которые клиент проверяет самостоятельно относительно известного CID. В уроке разберём смысл такого ответа и узнаем, почему слово trustless не означает отсутствие любых предпосылок доверия.

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

Получение проверяемых блоков

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

ожидаемый корень + путь
           ↓
шлюз выдаёт блоки и структуру
           ↓
клиент проверяет CID каждого блока
           ↓
клиент проверяет связи и восстанавливает файл

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

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

Доверенный начальный идентификатор

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

Для библиотеки есть дополнительное обязательство SHA-256 точных байтов release.json в CourseCatalog. После восстановления файла сравниваем его с записью известной сети и адреса. Это связывает полученное содержание с издателем, а не только с произвольным CID.

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

Согласование формата

HTTP-запрос использует предусмотренное согласование типа ответа. Клиент сообщает поддерживаемый формат и интерпретирует полученный тип. Нельзя получить обычный HTML, прочитать заголовок с CID и объявить, что весь DAG проверен.

Спецификация описывает параметры и media types. Полный запрос для будущего клиента строится по его поддержке и известной форме цели. Здесь не приводится «универсальный» заголовок для всех файлов, потому что одиночный блок, путь UnixFS и полный DAG имеют разные задачи.

Если ответ не соответствует ожидаемому формату, состояние становится отказом обработки. Шлюз может вернуть ошибку или иной поддерживаемый путь, но автоматическое доверенное исполнение HTML вместо блока недопустимо. Формат ответа — часть границы данных.

Полнота и избыточность

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

Неполный CAR может содержать правильный корень, но не один из дочерних блоков. Клиент обнаруживает отсутствие при обходе и сообщает, что восстановление не завершено. Сам заголовок с корнем не является достаточным основанием считать объект готовым.

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

Потоковая обработка

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

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

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

Правильные блоки из неправильного дерева

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

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

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

После восстановления release.json библиотека по-прежнему сверяет SHA-256 точных файловых байтов с CourseCatalog. Эта дополнительная связь отвечает за объявление редакции. Затем проверяются схема и политика отображения. Таким образом, trustless-маршрут не заканчивается красивой отметкой «CAR прочитан»: он связывает каждый необходимый этап с известной целью и показывает только тот успех, который действительно следует из подготовленной процедуры. В текущей работе эти случаи описаны как ожидаемые, без исполнения парсера.

От проверки к отображению

После восстановления манифеста проверяется файловый SHA-256, схема и допустимые пути. Затем читаются конкретные материалы. Если они содержат активный HTML, применяются правила origin и изоляции прошлого урока. Криптографически правильный блок не получает повышенных полномочий автоматически.

Для учебного читателя можно отображать проверенный текст как содержимое внутри контролируемого интерфейса, а активные примеры — отдельным ограниченным маршрутом. Это решение продукта, которое нужно описать рядом с данными выпуска.

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

Официальные правила доступны в Trustless Gateway Specification и CARv1. После урока слово trustless означает конкретную клиентскую проверку содержания при известном корне. Оно не обещает доступность, авторство, безопасность активного кода или отсутствие всех внешних зависимостей.

Оглавление серии