Все записи

9 мин чтения

Запустите собственный шлюз Label 309

Да — компания или разработчик может запустить собственный шлюз Label 309, пополнить его кошельки Cardano и хранилища и публиковать стандартные подтверждения существования, не используя CardanoWall в роли размещённого оператора. Вот что для этого нужно.

Да — вы можете запустить собственный шлюз. Шлюз Label 309 — это open-source-сервис, который рассчитывает стоимость, загружает данные, публикует, подтверждает и индексирует записи о подтверждении существования. Запустите свой — и ваша организация становится оператором: вы пополняете кошельки Cardano и хранилища, управляете учётными записями и API-ключами и публикуете стандартные записи, не завися от размещённого сервиса CardanoWall. Записи, которые вы закрепляете в блокчейне, ничем не отличаются от чужих, потому что формат определяет стандарт, а не оператор.

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

Когда стоит запускать собственный шлюз?

Запускайте собственный шлюз тогда, когда контроль над эксплуатацией важнее удобства.

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

Однако некоторым командам нужна другая модель:

  • строгие политики выбора подрядчиков и хранения данных в определённой юрисдикции;
  • регулируемые или подлежащие аудиту процессы;
  • публикация большого объёма записей;
  • внутренние архивы для комплаенса и системы юридических доказательств;
  • инфраструктура установления происхождения для ИИ и конвейеры подтверждений в CI/CD;
  • продукты, построенные поверх Label 309 под собственным брендом;
  • прямой контроль над ключами, учётными записями, пополнением и ценообразованием.

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

Что именно делает шлюз?

Шлюз владеет всем конвейером публикации и стоящим за ним состоянием денег, блокчейна и хранилища. Это один бинарный файл на Rust плюс PostgreSQL, и он отвечает за:

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

Это и есть механика надёжного сервиса публикации. За клиентом по-прежнему остаются пользовательские намерения и закрытые ключи; шлюз владеет блокчейном, хранилищем, ценообразованием и инфраструктурой учётных записей. Это разделение сделано намеренно — граница одна и та же, кто бы ни запускал шлюз: CardanoWall или вы.

Что нужно для самостоятельного хостинга?

Как минимум — эксплуатационное владение пятью вещами.

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

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

Пополнение хранилища. Если ваш шлюз принимает загрузку файлов или шифротекста, ему нужны бэкенд хранилища и средства для хранения байтов. В продакшене это Arweave через бандлер Turbo, оплачиваемый предоплаченными кредитами хранилища, которые вы пополняете с кошелька Arweave. Можно также развернуть инстанс только с хешами и вовсе без хранилища: тогда записи несут только хеш содержимого (и любые URI, размещённые во внешних системах), а сам инстанс не хранит ничего.

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

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

Самостоятельный хостинг — это настоящая инфраструктура. Относитесь к нему соответственно — и он будет надёжным; отнесётесь небрежно — и он станет обузой.

Меняет ли самостоятельный хостинг стандарт?

Нет. Самостоятельно размещённый шлюз публикует те же записи Label 309, что и любой другой оператор, и записи остаются стандартными.

Верификатору нужны только метаданные транзакции Cardano, при желании — байты содержимого, и публичный обозреватель блокчейна Cardano. Ему не нужно знать — и он не может определить, — пришла ли запись из размещённого шлюза CardanoWall, из шлюза вашей компании или с ноутбука разработчика. В этом и весь смысл отделения открытого стандарта от размещённого продукта: долговечный артефакт — это Label 309, а каждый шлюз — лишь его нижестоящая реализация.

Убирает ли самостоятельный хостинг все расходы?

Нет. Он убирает маржу размещённого оператора, но базовые расходы по-прежнему ваши.

Вы всё ещё платите за:

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

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

Кому не стоит хоститься самостоятельно?

Не хоститесь самостоятельно лишь ради того, чтобы не думать о цене.

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

Для большинства частных лиц и многих небольших команд размещённый CardanoWall — практичный путь.

Кому самостоятельный хостинг подходит?

Командам, которые уже эксплуатируют серьёзную инфраструктуру и имеют конкретную причину держать конвейер у себя. Хорошие кандидаты:

  • компании, публикующие подтверждения большими объёмами;
  • команды комплаенса, закрепляющие свидетельства ежедневно или ежечасно — в идеале пакетом под одной записью;
  • команды ИИ, фиксирующие манифесты наборов данных и результатов;
  • команды DevSecOps, встраивающие подтверждения в конвейеры релизов;
  • юридические платформы, работающие с чувствительными доказательствами;
  • продукты, которым нужен Label 309 под собственным брендом;
  • организации, которые не могут пропускать чувствительные процессы через сторонний размещённый сервис.

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

Как продукт строится поверх шлюза?

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

Например:

  • продукт для комплаенса публикует ежедневные снимки контролей;
  • медиапродукт закрепляет хеши манифестов Content Credentials (C2PA);
  • юридический продукт запечатывает доказательства для конкретных получателей;
  • инструмент для разработчиков публикует подтверждения релизов;
  • ИИ-продукт проставляет метки времени для пакетов сгенерированных результатов.

Продукт никогда не переписывает заново отправку транзакций в Cardano или учёт хранилища — он обращается к шлюзу. Именно так устроен CardanoWall: веб-приложение и воркер — это обёртка вокруг тех же публичных плоскостей шлюза, которыми пользуется сторонний интегратор, без приватной двери. Если хотите глубже разобрать паттерны интеграции, см. как строить на шлюзе Label 309.

Как клиенты подключаются к шлюзу?

Через HTTP API шлюза, разделённый на две плоскости.

Веб-приложение, десктоп-приложение, CLI, интеграция через SDK или бэкенд-сервис используют токены учётных записей или API-ключи, чтобы вызывать плоскость данных: расчёт стоимости, загрузку, публикацию, чтение баланса, чтение записей. Действия оператора — создание учётных записей, зачисление балансов, установка маржи, выпуск учётных данных — идут через управляющую плоскость и всегда только с доверенного бэкенда.

Обычное разделение:

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

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

Что операторы должны защищать?

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

Ключи и учётные данные. Шлюз подписывает единым зашифрованным набором ключей — ключи Cardano, хранилища и вебхуков в одном файле под одной парольной фразой. Создайте его офлайн, держите офлайн-резервную копию и файла, и парольной фразы, и охраняйте корневой секрет оператора как пароль продакшен-базы данных. Пути для экспорта ключей или вывода средств нет: потеряете набор ключей — и средства на его адресах останутся заблокированными навсегда.

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

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

Минимум привилегий. Браузер никогда не должен получать учётные данные оператора. Задача CI никогда не должна получать больше прав, чем ей нужно. Ограничивайте токены счетов узко и держите их короткоживущими.

Как работает проверка против самостоятельно размещённого шлюза?

Ровно так же, как против любого шлюза: проверка вообще не доверяет шлюзу.

Верификатор проверяет транзакцию Cardano, метаданные Label 309, хеши, опциональные подписи, любые доказательства Merkle и запечатанные данные по стандартным правилам — без сервера издателя в цепочке. Шлюз помогает вам публиковать и индексировать; он не может сделать недействительное подтверждение действительным.

Особенно это важно для внутренних систем. Компания, запускающая собственный шлюз, всё равно должна проверять свои записи независимо. «Наш шлюз сказал, что опубликовал» — это не подтверждение. Подтверждение — это запись в блокчейне и независимая проверка. Выполнить такую проверку можно open-source-инструментом командной строки cardanowall или проверить запись вручную — ни тому, ни другому не нужен запущенный шлюз.

Как это связано с CardanoWall?

CardanoWall — это размещённый, отполированный продукт и эталонный оператор стандарта. Самостоятельный хостинг — путь к независимости. Одно другому не противоречит.

Пользователь может начать на CardanoWall, позже перейти на самостоятельно размещённый шлюз или использовать оба для разных процессов. Разработчик может построить продукт на модели шлюза. Компания может оставить размещённый CardanoWall для простых команд, а для регулируемой автоматизации запустить собственный шлюз. Общий слой под всем этим — Label 309: открытый, нейтральный к поставщикам и одинаковый в блокчейне, кто бы ни публиковал.

Коротко

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

Размещённый CardanoWall — это удобство. Самостоятельный хостинг — это контроль. Записи-подтверждения остаются стандартными в любом случае.

Что почитать дальше

gatewayself-hostingdevelopers