Открыть сервис
Главная → Блог → IPFS Gateway

IPFS Gateway

IPFS Gateway — это серверное программное обеспечение или сервис, предоставляющий доступ к содержимому, хранящемуся в распределённой файловой системе IPFS (InterPlanetary File System), через стандартные протоколы HTTP и HTTPS. IPFS Gateway выступает в роли моста между традиционной архитектурой «клиент-сервер» Всемирной паутины и децентрализованной одноранговой сетью IPFS, позволяя пользователям загружать файлы, веб-страницы и другие данные из IPFS без необходимости устанавливать специализированное клиентское ПО или запускать полный узел сети.

История и предпосылки создания

Протокол IPFS был разработан Хуаном Бенетом и впервые описан в 2014 году. Основная идея заключалась в создании глобальной, версионируемой файловой системы, адресуемой по содержимому (content-addressed), а не по местоположению (location-addressed), как в классическом HTTP. Однако для массового внедрения требовалась совместимость с существующей инфраструктурой Интернета, где доминирует HTTP. IPFS Gateway был предложен как решение этой проблемы, позволяя браузерам и другим HTTP-клиентам взаимодействовать с IPFS-сетью.

Первые публичные реализации шлюзов появились в 2015–2016 годах, в том числе официальный шлюз от Protocol Labs — ipfs.io. Развитие технологии шлюзов шло параллельно с эволюцией самого протокола IPFS, включая внедрение поддержки IPNS (InterPlanetary Name System) и DNSLink для разрешения изменяемых имён.

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

IPFS Gateway функционирует как посредник. Когда пользователь отправляет HTTP-запрос на шлюз, содержащий идентификатор контента (CID — Content Identifier), шлюз выполняет следующие шаги:

  1. Приём запроса: Шлюз получает HTTP-запрос, например, https://gateway.ipfs.io/ipfs/QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco/wiki/`.
  2. Поиск контента: Шлюз использует свой собственный IPFS-узел (или подключается к другим узлам сети) для поиска узлов, хранящих запрошенные блоки данных, соответствующие указанному CID.
  3. Загрузка и кэширование: Шлюз загружает необходимые блоки данных из сети IPFS. Загруженные данные часто кэшируются на диске шлюза для ускорения последующих запросов к тому же контенту.
  4. Формирование HTTP-ответа: Шлюз собирает блоки в исходный файл или веб-страницу и отправляет их клиенту в виде стандартного HTTP-ответа с соответствующими MIME-типами и заголовками.

Ключевая особенность — шлюз не хранит контент постоянно (за исключением кэша). Он извлекает его из сети по запросу, что делает шлюзы «лёгкими» точками входа.

Типы IPFS-шлюзов

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

Публичные шлюзы

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

  • ipfs.io (официальный шлюз Protocol Labs)
  • dweb.link
  • cf-ipfs.com (шлюз Cloudflare)
  • gateway.pinata.cloud

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

Приватные (локальные) шлюзы

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

Преимущества: полный контроль над данными, отсутствие цензуры, высокая скорость при доступе к локально закреплённому контенту, возможность работы в офлайн-режиме. Недостатки: требует установки и настройки программного обеспечения (например, go-ipfs или kubo), потребляет ресурсы системы (диск, память, сеть).

Шлюзы с аутентификацией

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

Функциональные возможности

IPFS Gateway поддерживает несколько режимов работы, определяющих формат URL и способ разрешения контента.

Path Gateway (путь)

Классический режим, при котором CID или имя IPNS указывается в пути URL. Пример: https://gateway.ipfs.io/ipfs/<CID>/path/to/file https://gateway.ipfs.io/ipns/<name>/path/to/file

Этот режим наиболее распространён и прост для понимания. Шлюз интерпретирует первую часть пути после /ipfs/ или /ipns/ как идентификатор корневого объекта.

Subdomain Gateway (поддомен)

Режим, при котором CID или имя IPNS выносится в поддомен. Пример: https://<CID>.ipfs.gateway.ipfs.io/path/to/file https://<name>.ipns.gateway.ipfs.io/path/to/file

Этот подход решает проблемы с относительными ссылками и безопасностью (изоляция контента разных CID в разных источниках браузера — origin). Он рекомендуется для доступа к веб-сайтам, размещённым в IPFS.

DNSLink Gateway

Позволяет использовать доменные имена, управляемые через DNS, для доступа к контенту в IPFS. Владелец домена добавляет TXT-запись вида dnslink=/ipfs/<CID> или dnslink=/ipns/<name>. Шлюз, получив запрос на домен, проверяет DNS-запись и перенаправляет запрос к соответствующему CID. Пример: https://en.wikipedia-on-ipfs.org/` — этот сайт использует DNSLink для указания на актуальный CID википедии.

Применение

IPFS Gateway используется в различных сценариях, где требуется децентрализованное хранение с доступом через HTTP.

Децентрализованные веб-сайты (dWeb)

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

Хранение и распространение файлов

IPFS Gateway позволяет скачивать файлы (изображения, видео, архивы) из IPFS через обычную ссылку. Это удобно для распространения больших объёмов данных, например, дистрибутивов ПО, научных наборов данных, медиа-контента.

Интеграция с блокчейн-приложениями (dApps)

Многие децентрализованные приложения (dApps) на базе Ethereum, Solana и других блокчейнов хранят свои интерфейсы (HTML, CSS, JS) и метаданные NFT в IPFS. Шлюзы используются для загрузки этих интерфейсов в браузере пользователя.

Кэширование и CDN

Публичные шлюзы, такие как Cloudflare IPFS Gateway, выполняют функцию кэширующего слоя, ускоряя доступ к популярному контенту. Они также могут предоставлять географически распределённый доступ (CDN).

Критика и ограничения

Несмотря на полезность, IPFS Gateway имеет ряд недостатков.

  • Централизация: Публичные шлюзы являются центральными точками отказа и цензуры. Оператор шлюза может блокировать доступ к определённому контенту или прекратить работу сервиса.
  • Производительность: Первый запрос к контенту, которого нет в кэше шлюза, может быть медленным, так как шлюзу необходимо найти и загрузить блоки из сети IPFS.
  • Нагрузка на сеть: Использование публичных шлюзов создаёт дополнительную нагрузку на сеть IPFS, так как шлюзы выступают в роли «тяжёлых» клиентов.
  • Безопасность и конфиденциальность: Публичные шлюзы могут логировать запросы пользователей, что создаёт риски для приватности. Контент, доступный через шлюз, может быть проверен оператором на вредоносность, но также может быть подвержен атакам типа «отравление кэша».
  • Зависимость от DNS: Для работы DNSLink и некоторых других функций требуется доступ к традиционной DNS-инфраструктуре, что частично нивелирует децентрализацию.

Альтернативы и развитие

Существуют альтернативные подходы к доступу к IPFS, не требующие HTTP-шлюзов:

  • IPFS Companion: Браузерное расширение, которое перенаправляет запросы к IPFS-контенту на локальный узел.
  • Brave Browser: Встроенная поддержка IPFS (протокол ipfs://).
  • IPFS Desktop: Приложение, объединяющее IPFS-узел, шлюз и интерфейс управления.

Развитие технологии направлено на улучшение производительности (например, Bitswap — протокол обмена блоками), повышение безопасности (верификация контента на стороне клиента) и децентрализацию доступа (например, протокол Filecoin для экономического стимулирования хранения).

Источники

  1. Benet, J. (2014). IPFS - Content Addressed, Versioned, P2P File System. (Draft 3).
  2. Protocol Labs. (2020). IPFS Gateway Specification. GitHub.
  3. Cloudflare. (2021). Introducing the Cloudflare IPFS Gateway.
  4. Wikipedia. (2024). InterPlanetary File System.

BFOmetr — база данных и аналитика по компаниям России.

На главную BFOmetr →

Похожие материалы