Изображения, модерация и чаевые: внутри социального dApp Kaspa

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

В этой статье разбирается архитектура: что попадает в цепочку, как работают изображения с адресацией по содержимому, трёхуровневая система модерации, как чаевые в KAS привязываются к постам и почему весь индекс можно восстановить исключительно из DAG.

Разделение on-chain / off-chain

Каждый пост Boards — это подписанная транзакция Kaspa. Полезная нагрузка транзакции содержит текст поста, ссылку на родительский пост (ID транзакции родительского поста для формирования тредов) и — при наличии изображения — SHA-256-хеш нормализованных байтов изображения. Этот хеш — единственные данные об изображении, которые попадают в цепочку.

Сами байты изображения никогда не включаются в транзакцию Kaspa. Они хранятся на инфраструктуре KaspaForge с ключом по их SHA-256-дайджесту. Браузер зрителя запрашивает изображение через API-эндпоинт, и сервер проверяет, можно ли отдавать этот хеш, прежде чем вернуть байты.

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

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

Изображения с адресацией по содержимому: дедупликация, блоклист и сборка мусора

Когда пользователь загружает изображение, сервер нормализует его (проверка формата, ограничение размера), вычисляет SHA-256 и проверяет блоклист до записи чего-либо на диск. Если этот хеш уже в блоклисте — то есть оператор навсегда запретил именно эти байты — загрузка отклоняется с кодом 403. Байты никогда не попадают в хранилище.

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

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

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

Трёхуровневая модерация: $0 за пост по архитектурному замыслу

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

Уровень 0 — локальный NSFW-классификатор при загрузке. Каждое загружаемое изображение проходит локальный инференс до возврата HTTP-ответа на загрузку. Классификатор — это чистая реализация на Rust модели MobileNetV2 от GantMan с пятью классами (категории: drawings, hentai, neutral, porn, sexy), работающая через крейт nsfw с движком tract — без зависимостей от C++, без загрузки внешних рантаймов при сборке. Веса модели хранятся как файл на диске; если файл отсутствует или повреждён, классификатор отключается и срабатывает оповещение при запуске.

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

let explicit = porn + hentai;
if explicit >= 0.70       => Blocked
else if explicit >= 0.35
     || sexy >= 0.80      => Gray
else                      => Clean

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

Важно: HTTP-ответ на загрузку всегда одинаковый — 200 с тем же SHA-256 — независимо от вердикта. Классификатор управляет *раздачей*, а не *загрузкой*. Изображение с вердиктом Blocked сохраняется, но никогда не раздаётся на безопасной доске; изображение с вердиктом Clean раздаётся немедленно. Это значит, что задержка классификатора никогда не блокирует путь загрузки — инференс выполняется в блокирующей задаче вне async-исполнителя, и ответ отправляется сразу после подтверждения сохранения.

Уровень 1 — жалобы зрителей. Каждый отрисованный пост содержит кнопку жалобы. Нажатие отправляет жалобу с ID транзакции поста. Сервер создаёт или обновляет запись жалобы, увеличивая счётчик и обновляя временную метку. При первой жалобе и каждой пятой после этого оператор получает уведомление в Telegram с прямой ссылкой на тред и кнопкой для открытия консоли администратора. Клиент сохраняет флаг reported в localStorage, чтобы кнопка отображалась как неактивная метка после использования — без повторных нажатий, незаметно раздувающих счётчик.

Уровень 2 — консоль оператора. API администратора предоставляет эндпоинты для скрытия постов, тредов или целых досок; жёсткого удаления байтов изображений (немедленное удаление с диска, а не просто блокировка раздачи); добавления или удаления записей из блоклиста; и обработки жалоб. Аутентификация переиспользует тот же токен-доступ, который защищает админ-маршруты Kaspa Escrow и Маркетплейса — Boards является третьим арендатором существующей системы авторизации, а не отдельным хранилищем учётных данных.

Шлюз раздачи имеет чёткий порядок приоритета:

1. Блоклист имеет наивысший приоритет. Хеш из блоклиста всегда возвращает 404 на любой доске. 2. Переопределение для NSFW-доски. Если доска допускает NSFW-контент, изображения раздаются независимо от вердикта — классификатор там носит рекомендательный характер. 3. Стандартный безопасный режим. Вердикт Blocked блокирует изображение; пост отображается только текстом. 4. Отсутствие вердикта по умолчанию = чисто. Это обеспечивает обратную совместимость для всех изображений, загруженных до появления классификатора — без скрытых сбоев при развёртывании.

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

Чаевые в KAS: стандартные транзакции, привязанные к постам

Чаевые в KAS на Boards — это стандартная транзакция Kaspa. Кошелёк отправителя создаёт транзакцию на адрес автора поста, а индексатор привязывает чаевые к конкретному посту по ссылке на транзакцию. Индексатор агрегирует чаевые по постам и отображает накопительную сумму рядом с тредом.

Поскольку чаевые — это обычные транзакции Kaspa, а не пользовательский токен или внутренняя бухгалтерия платформы, они наследуют те же свойства, что и любой перевод KAS: отправитель платит комиссию сети (в настоящее время 0,0001 KAS за используемый UTXO — политика кошелька/ноды, как описано в вики Kaspa), транзакция подтверждается через тот же консенсус GHOSTDAG, что и любой другой перевод, а получатель контролирует средства в собственном кошельке. KaspaForge никогда не хранит чаевые — KAS перемещается в цепочке от отправителя к получателю, как и любой платёж от пользователя к пользователю.

Индексация и восстанавливаемость

Индексатор Boards — это представление данных из цепочки, а не исходный источник истины. Каждый пост, ссылка на ответ и чаевые — это транзакция Kaspa. Если база данных KaspaForge была полностью утрачена, новый индексатор мог бы просканировать BlockDAG, найти все транзакции, связанные с Boards, по их опознавательным паттернам, и восстановить полный текстовый индекс, дерево тредов и суммы чаевых.

Это важное архитектурное свойство. База данных индексатора — это кэш, быстрая проекция неизменных данных цепочки с возможностью запросов. Байты размещённых изображений — единственный элемент, который нельзя восстановить из DAG (цепочка хранит только ссылку SHA-256, а не пиксели). Но текст, треды, подписи авторов и история чаевых полностью восстанавливаемы.

Компромисс — задержка. Сканирование всего DAG для восстановления индекса происходит не мгновенно — это занимает время, пропорциональное длине цепочки и плотности транзакций Boards. В обычном режиме индексатор обрабатывает новые транзакции почти в реальном времени по мере слияния блоков. Полное восстановление — это путь аварийного восстановления, а не рутинная операция.

Компромиссы и честные ограничения

NSFW-классификатор обнаруживает наготу, а не возраст. Вердикт Blocked — это утверждение о содержимом пикселей: сколько кожи, насколько откровенное изображение. Он не является и никогда не предназначался быть самостоятельным детектором CSAM. Реальная защита от нелегального контента — это цикл «жалоба → жёсткое удаление → блоклист»: человек просматривает помеченное изображение и может навсегда удалить его из индекса. Ссылка SHA-256 в цепочке и текст поста остаются постоянными — это честное ограничение хранения ссылок в неизменяемом реестре.

Ни одна LLM не проверяет изображения. Ранняя идея запускать языковую модель на каждом посте была отвергнута как экономически неоправданная для бесплатного сервиса. Уровень 0 — классификатор, уровень 1 — кнопка жалобы, а консоль оператора — место, где человек принимает окончательное решение.

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

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

Модерация действует в пределах индекса, а не на уровне всей сети. Жёстко удалённое изображение исчезает из индекса KaspaForge Boards. Те же байты, на которые ссылается тот же SHA-256 в другом индексаторе или в необработанных данных транзакций ноды, остаются доступными любому, кто может читать цепочку. Это тот же компромисс, с которым сталкивается любая система контента в цепочке: реестр нейтрален, а модерация — свойство наблюдателя, а не цепочки.