SBT или Verifiable Credentials: что выбрать для защиты данных

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

Verifiable Credentials решают ту же задачу иначе. Данные хранятся у пользователя вне блокчейна, эмитент подписывает утверждение криптографически, а проверяющая сторона валидирует подпись и статус документа. При корректной реализации VC позволяют раскрыть только нужное поле, не отправляя верификатору весь цифровой профиль. Поэтому вопрос «SBT или Verifiable Credentials для идентификации» нельзя сводить к сравнению двух форматов токенов. Это выбор между публичной ончейн-репутацией и приватной моделью суверенной идентичности.

Архитектурный конфликт: публичность реестра против приватности

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

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

VC строятся вокруг другой границы доверия:

• Issuer выпускает утверждение и подписывает его;
• Holder получает credential и хранит его у себя, например в цифровом кошельке;
• Verifier проверяет подпись, структуру и условия действительности документа.

Такая модель не требует, чтобы персональные данные были записаны в публичный блокчейн. В реестр при необходимости выносятся идентификаторы, ключи, статусы отзыва или служебные доказательства. Сам credential остается off-chain.

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

SBT оптимизирует публичную проверяемость. Verifiable Credentials — минимальное раскрытие данных. Пытаться получить оба свойства одним примитивом обычно означает принять лишний privacy overhead или лишнюю утечку.

Сравнение на уровне архитектуры выглядит так:

Таблица не означает, что любой SBT автоматически раскрывает паспортные данные, а любой VC автоматически приватен. Всё определяется тем, какие поля записаны, как формируется идентификатор, где публикуются метаданные и способен ли verifier связать credential с реальным человеком. Но базовые свойства протоколов задают направление риска.

Soulbound Tokens: концепция «цифровой души» и пределы модели

Концепция Soulbound Tokens была предложена Виталиком Бутериным, Гленом Вейлом и Пуджей Олхавер в мае 2022 года в работе Decentralized Society: Finding Web3's Soul. Идея состояла в том, чтобы использовать непередаваемые записи для формирования социальной репутации в Web3. В отличие от обычного NFT, SBT нельзя свободно продать или перевести на другой адрес. Он должен отражать не владение активом, а некоторый факт о его носителе.

На концептуальном уровне это полезное разделение. NFT отвечает на вопрос, какой адрес контролирует объект. SBT должен отвечать на вопрос, какие утверждения связаны с этим адресом. Например:

• участник состоит в DAO;
• адрес прошел определенный governance-процесс;
• кошелек получил credential от образовательного учреждения;
• адрес имеет историю участия в протоколе;
• пользователь выполнил условие для доступа к функции приложения.

Проблема начинается там, где адрес начинают считать устойчивым идентификатором человека. В реальности один пользователь может контролировать несколько кошельков, передать ключи другому лицу, потерять seed-фразу или использовать custodial-инфраструктуру. Сам по себе SBT не доказывает, что за адресом всё время стоял один и тот же субъект.

Есть и более жесткое ограничение: публичность. Авторы концепции отдельно признавали, что Soul-Based Tokens изначально публичны и потому не подходят для чувствительной информации, включая государственные удостоверения личности. Это не мелкая оговорка, которую можно закрыть красивым интерфейсом. Если credential записан в блокчейн, фронтенд не меняет модель угроз. Индексаторы, архивные ноды и аналитические сервисы всё равно могут извлечь запись.

Что происходит с SBT после публикации

Рассмотрим типичный жизненный цикл:

1. Эмитент вызывает функцию выпуска токена на адрес пользователя.

2. Транзакция попадает в мемпул, затем в блок.

3. Событие контракта индексируется внешними сервисами.

4. Любой наблюдатель связывает адрес с типом токена, временем выпуска и, возможно, URI метаданных.

5. Если адрес используется в других dApp, возникает корреляция между несколькими наборами данных.

Пятый пункт особенно неприятен. Отдельная запись о прохождении курса может выглядеть безобидно. Но комбинация нескольких SBT способна построить устойчивый профиль: образование, место работы, участие в сообществах, финансовая активность, география и социальные связи. Здесь появляется не просто утечка отдельного поля, а deanonymization через пересечение графов.

Непередаваемость также не равна неизменяемой достоверности. Слабая реализация может разрешать эмитенту выпускать токены без достаточной проверки, а отзыв — оставлять неясным. Возможны ошибки в адресе, компрометация ключа Issuer, Sybil-атаки и намеренная выдача нескольких токенов одному человеку. Если протокол не описывает жизненный цикл записи, SBT становится постоянным маркером, но не надежным доказательством.

Где SBT действительно уместны

SBT имеют рациональные сценарии. Их не нужно списывать только потому, что они непригодны для паспорта или медицинской информации.

Они подходят, когда выполняются четыре условия:

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

Например, DAO может использовать SBT как публичный сигнал участия в governance. Web3-игра — как ончейн-отметку о достижении, если пользователь согласен сделать её видимой. Протокол доступа — как грубый фильтр для адресов, соответствующих некоторому условию. В таких сценариях SBT работают скорее как слой публичной репутации, а не как универсальный документ идентификации.

Но даже здесь стоит разделять атрибут и идентичность. Запись «адрес выполнил условие X» безопаснее, чем запись «конкретный человек имеет свойство Y». Чем ближе содержание SBT к реальной личности, тем хуже становится архитектурный профиль решения.

Verifiable Credentials: модель доверия вместо ончейн-паспорта

W3C Verifiable Credentials Data Model определяет стандартную схему взаимодействия между Issuer, Holder и Verifier. Первая публикация стандарта относится к 2019 году; модель получила дальнейшее развитие в версиях W3C VC Data Model 1.0 и 2.0.

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

Идентификатор может быть связан с DID в формате did:method:id. Сам DID не обязан содержать персональные данные. Он задает способ разрешения идентификатора и проверки связанных с ним ключей или сервисных endpoints. Реальная конфиденциальность зависит от выбранного DID method, кошелька, транспорта и политики хранения, но сама модель не требует публичной записи каждого атрибута.

Проверка VC математическая. Verifier проверяет:

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

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

Почему selective disclosure важнее самого факта подписи

Обычная цифровая подпись отвечает на вопрос: документ действительно подписал тот, кто указан как Issuer, или нет. Но если Holder отправляет verifier полный документ, криптографическая аутентичность не решает проблему избыточного раскрытия.

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

Selective disclosure меняет протокол предъявления. Верификатор получает только те поля или утверждения, которые нужны для конкретной операции. Остальные остаются у Holder. Это и есть практическая ценность SSI — self-sovereign identity: пользователь не просит централизованный сервис каждый раз подтвердить его статус, а предъявляет проверяемое доказательство с контролируемым объемом раскрытия.

В криптографической схеме BBS+ документ подписывается один раз, после чего его поля можно раскрывать выборочно без нарушения подписи эмитента. Здесь нет магии. Есть подпись над набором атрибутов и протокол доказательства того, что раскрытая часть происходит из корректно подписанного credential. Для verifier это означает: он проверяет доказательство, а не доверяет словам пользователя или скриншоту из личного кабинета.

BBS+, DID и revocation: где находится реальный overhead

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

Ключи и DID

Если Issuer потерял ключ или его скомпрометировали, доверие к новым credential становится проблемой. DID method должен описывать, как публикуются изменения ключей, как verifier получает актуальное состояние и что происходит при ротации. Само наличие строки did:method:id не гарантирует ни устойчивости, ни приватности.

Holder тоже становится объектом атаки. Компрометация кошелька может открыть набор credential, которые никогда не должны были утекать вместе. Поэтому защищать нужно не только блокчейн и смарт-контракт, но и recovery, key management, backup-политику и устройство, на котором выполняются cryptographic operations.

Отзыв и статус документа

У блокчейна есть неприятное, но понятное свойство: опубликованную историю трудно изменить. У VC можно выпустить новую версию и объявить старую недействительной, однако verifier должен уметь узнать актуальный статус. Это требует отдельного механизма revocation или suspension.

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

BBS+ и совместимость

BBS+ дает selective disclosure, но его поддержка не появляется бесплатно. Нужны совместимые библиотеки, аккуратная сериализация credential, единые правила каноникализации и проверка криптографических примитивов. Ошибка на уровне формата может разрушить совместимость, а ошибка в реализации — добавить уязвимость в доказательство.

Для команды dApp это означает дополнительный engineering overhead:

• нужно выбрать профиль VC и набор поддерживаемых proof formats;
• нужно описать политику доверенных Issuer;
• нужно реализовать проверку DID и ключей;
• нужно обрабатывать истекшие и отозванные credential;
• нужно ограничить корреляцию предъявлений;
• нужно провести аудит криптографических библиотек и границ доверия.

SBT тоже не являются бесплатными. Их стоимость просто находится в другом месте: gas, постоянное хранение, индексаторы, анализ графа адресов, защита от Sybil и корректная логика burn/revoke. Сравнивать только удобство выпуска токена некорректно. Нужно сравнивать полный протокол, включая ошибки, восстановление и последствия утечки.

Приватность VC — не свойство слова «credential». Она появляется только тогда, когда в протоколе реализованы selective disclosure, корректное управление ключами и отсутствие лишних журналов предъявления.

SBT против VC в Web3: четыре практических сценария

Образование и квалификация

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

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

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

Доступ к dApp

Здесь возможна гибридная архитектура. SBT может выступать публичным грубым фильтром: адрес имеет membership-токен и получает доступ к открытой функции. Если же доступ зависит от возраста, гражданства, корпоративной должности или другой чувствительной характеристики, нужен VC с selective disclosure.

Нельзя считать privacy-preserving решение безопасным только потому, что приложение не показывает атрибут в интерфейсе. Если контракт принимает адрес, который навсегда связан с credential, корреляция всё равно остается. В Web3 приватность должна учитываться на уровне транзакционного графа, а не только UI.

DAO и governance

Для DAO SBT удобны как репутационный маркер. Непередаваемый статус может отражать участие в голосованиях, вклад в разработку или прохождение внутреннего процесса. Но governance-архитектура должна отдельно решать проблему Sybil. Один SBT на адрес не означает один голос на человека.

VC могут помочь, если DAO хочет доказать уникальность участника или наличие определенного статуса без публикации исходных данных. В этом случае credential становится пропуском к governance-механизму, а не публичным досье. Цена — более сложный verifier и зависимость от качественной инфраструктуры Issuer.

Метавселенные и блокчейн-игры

Для игровых достижений SBT логичны: игроку может быть нужен постоянный, непередаваемый маркер прохождения контента. Но привязывать к игровому SBT реальные данные владельца не следует. Игровая репутация и юридическая идентичность — разные домены.

VC подходят для внешних атрибутов: подтверждения возраста, статуса участника турнира, права на закрытый контент или принадлежности к организованной команде. Критерий простой: если игре нужен факт о поведении внутри мира, SBT достаточно. Если ей нужен факт о реальном человеке, лучше использовать VC и раскрывать минимум.

Гибридная архитектура часто лучше бинарного выбора

В реальном Web3-продукте SBT и VC не обязаны конкурировать в одной точке. Они могут находиться на разных слоях:

• VC хранит подтверждение квалификации или статуса у пользователя;
• Holder предъявляет selective disclosure proof;
• verifier проверяет подпись Issuer;
• после успешной проверки приложение выпускает локальный или ончейн-SBT;
• SBT фиксирует уже не персональные данные, а факт допуска, участия или выполненного действия.

Такая схема отделяет чувствительный credential от публичной репутации. Но она не устраняет все риски. Если SBT выпускается на адрес, который можно связать с личностью, он всё равно создает наблюдаемый след. Кроме того, ончейн-запись о прохождении проверки может раскрыть сам факт взаимодействия с определенным сервисом.

Поэтому гибрид проектируют с ограничением метаданных. В контракт не следует помещать имя, email, номер документа, полную квалификацию или URI, ведущий к открытой персональной карточке. Лучше фиксировать минимальный результат проверки, а иногда — вообще не писать его в сеть, если приложение может использовать off-chain authorization.

Минимальная матрица выбора

При проектировании dApp полезно разделить требования по типу:

• Нужна публичная репутация адреса — можно рассматривать SBT.
• Нужно подтвердить атрибут реального пользователя — предпочтительнее VC.
• Нельзя раскрывать исходные данные verifier — нужен selective disclosure.
• Запись должна быть видна всем и не передаваться — SBT соответствует семантике.
• Данные могут устаревать, отзывать или исправляться — VC обычно удобнее.
• Нужна совместимость между несколькими организациями — ориентиром служит W3C VC Data Model.
• Система должна работать без публичного следа предъявления — необходимо отдельно проектировать транспорт, revocation и журналирование.
• Нужно связать credential с одним человеком — одного SBT недостаточно; потребуется механизм уникальности и защита от Sybil.

Что проверять в технической реализации

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

1. Состав данных. Какие атрибуты реально попадают в chain, события контракта, IPFS-метаданные, логи RPC и аналитические индексы? Скрытое в UI поле не является приватным.

2. Модель субъекта. Credential выдается человеку, организации, адресу или ключу? Если субъектом является адрес, описано ли восстановление после потери ключа и изменение контролирующего устройства?

3. Жизненный цикл. Как выпускается, обновляется, отзывается и уничтожается запись? Для SBT должна быть прозрачна логика burn и revoke. Для VC — механизм проверки статуса и поведение при компрометации Issuer.

4. Криптография доказательств. Если заявлена поддержка BBS+, нужно проверить конкретную реализацию, библиотеку, формат сериализации и тесты совместимости. Само упоминание zk-SNARKs или selective disclosure ничего не доказывает.

5. Корреляция. Используется ли один DID или адрес во всех сервисах? Повторное предъявление одного и того же идентификатора может свести на нет приватность даже при корректной подписи.

6. Доверие к Issuer. Кто имеет право выпускать credential? Как verifier получает список доверенных эмитентов? Что происходит, если организация закрылась, сменила ключи или выпустила ошибочный документ?

7. Поведение verifier. Не отправляет ли кошелек лишние атрибуты? Не пишет ли приложение каждый запрос в централизованный лог? Не связываются ли IP, DID, timestamp и тип credential в единую таблицу наблюдения?

8. Газ и операционная нагрузка. Массовая выдача SBT создает транзакционный overhead и требует контроля nonce, ретраев и индексации. VC переносят нагрузку в криптографическую обработку, хранение, синхронизацию статусов и поддержку кошельков.

Без этого анализа сравнение превращается в выбор между двумя маркетинговыми ярлыками. В одном случае продают «душу» на блокчейне, в другом — «суверенную идентичность» без описания revocation и recovery. Для production-системы обе формулировки бесполезны.

Итоговый вердикт

Для защиты персональных данных, документов об образовании, квалификаций, возрастных и корпоративных атрибутов выбирайте Verifiable Credentials. Их off-chain-модель, роли Issuer–Holder–Verifier и selective disclosure лучше соответствуют требованиям приватности. При использовании BBS+ можно раскрывать отдельные поля подписанного документа, не публикуя исходный credential в блокчейне.

SBT выбирайте для публичной ончейн-репутации, где открытость записи является частью продукта, а связывание токена с адресом не создает неприемлемого риска. Это подходящий примитив для membership, достижений и некоторых governance-сценариев. Это не безопасная оболочка для паспортных данных и не замена суверенной идентичности.

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