Перевод

Это продолжение вольного перевода: https://medium.com/the-spartan-group/the-construction-of-the-soul-part-2-implementations-of-sbt-4afb34e09ec8. Первая часть по ссылке.

Введение

Это цикл статей из трёх частей, посвященных основам SBT, нашему видению SBT, её технической реализации и возможностям использования технологии ZK. В первой части обсуждалось, что такое SBT и его основные характеристики. В части 2 обсуждается базовая реализация и то, как мы можем добавить конфиденциальность с помощью SBT. Наконец, в части 3 мы обсудим, как можно использовать технологию ZK для повышения конфиденциальности SBT. Целью этого цикла статей является демистификация технических идей SBT и предоставление реализации для построения будущего Web3 с интеграцией социальной идентичности.

Аннотация

В первой статье цикла мы предложили видение, примеры использования и ключевые особенности SBT.

В целом, мы определили основные принципы проектирования для реализации SBT:

1. Невзаимозаменяемость;
2. Непередаваемость;
3. Проверка на совместимость;
4. Конфиденциальность;
5. Оффчейн хранение данных для SBT.

Во второй части серии статей мы рассмотрим реализацию SBT в соответствии с предложенными ранее рекомендациями по проектированию.

1. Идеи для реализации

В этом разделе мы обсудим реализацию SBT и ее компромиссы.

1.1 Сравнение с NFT

Поскольку NFT и SBT звучат очень похоже, каковы ключевые различия между этими структурами данных с точки зрения реализации?

В отличие от NFT, которые предназначены для торговли, SBT должны быть неразрывно связаны с “душой” и не подлежат передаче.

Данные NFT предназначены для публичного просмотра. Однако проекты SBT могут захотеть оставить свои данные конфиденциальными. Конфиденциальность может быть реализована различными методами.

Данные SBT должны быть легко читаемы другими проектами ончейн или оффчейн.

Руководствуясь следующими характеристиками, мы реализовали SBT в Solidity. Обсудим нашу реализацию в следующем разделе.

1.2 Базовый SBT

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

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

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

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

[Прим. Menaskop: в этом я с авторами категорически НЕ согласен: навязывать вновь отрицательную “репутацию” и/или оставлять удаление данных как возможность — это вновь не чистое Web 3.0 решение].

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

Данные могут храниться как ончейн, так и оффчейн. В нашей реализации мы предполагаем, что данные для SBT хранятся вне сети у провайдера, такого как IPFS. В нашей реализации URI вне-сетевого хранилища может быть связан с идентификацией в структуре данных “Struct Soul”.

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

Другие проекты-контрагенты должны иметь возможность легко получать данные из SBT.

Это полезно для контрагентов, которые хотят проверить атрибуты SBT пользователя. Другие проекты смогут проверять, есть ли у адреса “душа”, и проверять атрибуты, которые содержит эта “душа” именно.

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

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

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

Базовая реализация SBT подходит для проектов, которые хотят присвоить пользователям данные, не являющиеся конфиденциальными (персональными / частными) по своей природе. Например, проекты, которые хотят вознаграждать участников вайт-листов на основе их поддержки коллекции NFT, могут использовать эту SBT. В будущем проект может рассылать вознаграждения по этим адресам с помощью SBT.

В нашей предыдущей статье предложили, как SBT может быть потенциальным вариантом использования для распознавания NFT-локеров.

Например, когда NFT заблокирован в TimeLock.sol, хранитель может захотеть «показать», что он действительно владеет таким заблокированным NFT. Однако, с точки зрения разработчиков, было бы странно ссылаться на заблокированные NFT.

Поэтому SBT могут быть показателем того, как долго пользователи блокировали NFT, и они могут быть приняты в (условный) зал славы. При разблокировке NFT нужно будет «сжечь» непередаваемый обёрнутый токен.

Ссылка на предыдущую статью: https://medium.com/the-spartan-group/nft-vesting-with-time-locks-b7932b186a6e

Ссылка на контракт для SBT: https://github.com/SpartanLabsXyz/spartanlabs-contracts/blob/main/contracts/SoulBoundToken/BasicSBT.sol

Однако предложенный выше базовый вариант SBT не учитывает аспект конфиденциальности.

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

Любые отношения, зафиксированные ончейн, сразу же становятся видны всем в мире, а не только их участникам. Сопоставляя данные SBT, враждебно настроенные субъекты могут получить возможность деанонимизировать реальные личности пользователей из их SBT.

Например, если доказательство человечности (proof-of-humanity) получит более широкое распространение, конфиденциальность станет ещё более важной, поскольку альтернатива заключается в том, что всё, что мы делаем, будет связано ончейн напрямую с личностью.

2. SBT с приватным хранением данных 

В своей научной статье Виталик Бутерин предложил несколько возможных вариантов реализации SBT с сохранением конфиденциальности, причём это возможно как при хранении данных ончейн, так и оффчейн.

В этом разделе обсудим возможные варианты реализации приватного хранения данных SBT.

Храните элемент по адресу, который является хэшем (i) индекса, (ii) адреса получателя и (iii) секрета, принадлежащего получателю.

Можете раскрыть свой секрет интерфейсу, который затем будет искать все предметы, принадлежащие вам, но никто не будет знать, какие предметы принадлежат вам, пока не раскроете свой секрет.

Секрет, предоставленный пользователем, позволил бы платформе найти все данные, связанные с SBT пользователя.

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

Почему это работает?

Адреса Ethereum генерируются на основе хэша Keccak-256 и представляются в виде шестнадцатеричных чисел. Для генерации адреса используются последние 20 байт хэша Keccak-256.

Поскольку одна шестнадцатеричная цифра равна 4 битам, мы возьмем последние 40 цифр хэша Keccak 256 в качестве нашего адреса. Мы можем развернуть наш элемент по этому адресу.

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

Поэтому при развёртывании следует предоставлять только хэш, но не секрет.

Например, Боб хочет оформить SBT с помощью dApp для кредитования.

Кредитная платформа сначала проводит KYC для Боба.

Адрес развёртывания генерируется с использованием идентификатора клиента Боба, его ончейн-адреса и «Peanut» — секрета, который он придумал.

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

Затем SBT, содержащая KYC-данные Боба, развертывается на цепочке по адресу развертывания.

Никто, кроме людей, знающих секрет Боба, не может сканировать KYC-данные Боба.

Когда проект хочет просмотреть KYC-данные Боба, Бобу достаточно предоставить свой секрет «Peanut», и он сможет получить все KYC-данные Боба.

Преимущества:

• Этот метод позволяет легко взаимодействовать с протоколами, поскольку всё, что нам нужно, это секрет, индекс и адрес для получения элемента.

Недостатки:

• Однако развёртывание элемента по определённому адресу является хлопотным и газоёмким.

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

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

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

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

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

Пример реализации в Python с SHA256:

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

Как можем соединить данные оффчейн с хэш-ссылкой внутри чейна?

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

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

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

Проектам придётся позаботиться о защите передачи секретов и предотвращении таких распространенных атак, как атака воспроизведения, атака «человек посередине», атака повторного воспроизведения и многие другие распространённые атаки.

Как только безопасность третьей стороны, которая занимается получением SBT, будет нарушена, секрет человека станет публичным.

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

Кроме того, единственным способом доказать, что пользователь обладает определенным атрибутом, является раскрытие секрета. Однако для того, чтобы создать псевдонимную совместимость SBT, когда различные протоколы могут получать данные из SBT, пользователь должен раскрывать минимально необходимое количество данных.

Если проект требует только проверки атрибута, пользователь не должен раскрывать весь секрет. Пользователи должны ограничивать раскрытие своих секретов как можно меньшим количеством проектов.

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

3. Заключение

В этой статье рассмотрели реализацию SBT на основе рекомендаций по проектированию, которые были представлены в первой части цикла. Мы реализовали базовую SBT, а также SBT с частным хранением оффчейн и ончейн.

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

Использование технологии ZK может помочь нам уменьшить количество секретов пользователей, чтобы их данные SBT оставались действительно частными. Это подводит нас к третьей части серии эссе, в которой опишем SBT с реализацией zk-SNARK, где секреты пользователей могут оставаться скрытыми, предотвращая их от различных атак.

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

На этом всё и

До!

#sbt #soulbound_token #web_3.0