Несколько месяцев назад криптокоманда a16z опубликовала Испытание Накамото, список наиболее важных проблем, которые необходимо решить в блокчейне. Особенно привлекло наше внимание четвертое: «Соответствие программной конфиденциальности», так как мы активно думаем об этом уже некоторое время. Сегодня мы предлагаем первое решение с использованием гомоморфного шифрования и нашего протокола конфиденциального смарт-контракта fhEVM (если вы не знакомы с fhEVM, вы можете прочитать наши статьи о конфиденциальности Токен ERC20ислепые аукционы).

fhEVM - это обычный EVM с некоторыми предварительными компиляциями, которые позволяют вычислять зашифрованные состояния с использованием нашей библиотеки гомоморфного шифрования TFHE-rs. С точки зрения разработчика здесь нет криптографии: они просто пишут код Solidity, используя предоставляемые нами типы данных (euint32, ebool и т. д.). Одним из больших преимуществ fhEVM по сравнению с другими решениями конфиденциальности является то, что все данные и вычисления происходят onchain. Это означает, что у вас может быть такой же уровень композиции и доступности данных, как у обычных контрактов с открытым текстом.

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

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

Абстракция личности через ончейн, конфиденциальные DID

Децентрализованный идентификатор (DID) — это уникальное цифровое удостоверение, которое выдается таким субъектом, как правительство, регистратор, компания или сам пользователь. Этот DID может быть привязан к криптографическому ключу, который доказывает, что пользователь владеет DID, например, к кошельку EVM. Но он также может хранить целый ряд атрибутов, таких как возраст пользователя, национальность, номер социального страхования и т. д. Эти атрибуты, в свою очередь, могут быть использованы для доказательства того, что вы соответствуете какому-либо условию (называемому «аттестацией»), например, быть старше 18 лет или не быть гражданином Нарнии.

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

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

Проблема: каждый увидел бы личность каждого!

К счастью, у нас есть решение: гомоморфное шифрование, а точнее fhEVM! Благодаря возможности иметь композицию на зашифрованном состоянии, мы можем размещать учетные записи пользователей напрямую на цепочке в зашифрованной форме и иметь признанные приложения, проверяющие атрибуты с помощью простого вызова контракта. Возможность управлять идентификацией через смарт-контракт, который мы называем «Абстракция идентичности», подобна тому, как можно управлять средствами через смарт-контракт с помощью Абстракции учетной записи.

Этот учебник состоит из 3 частей:

• Абстракция личности осуществляется с помощью контракта реестра, который отвечает за управление личностями и удостоверениями. Здесь мы предполагаем, что DIDs являются официальными идентификаторами государственных органов. Сам реестр управляется центральным органом (например, AFNIC), который может создавать регистраторов (например, компании по KYC, такие как Onfido, Jumio и т. д.), которые в свою очередь могут создавать пользовательские DIDs. Пользователь затем обращается к своему регистратору, чтобы управлять и обновлять свои DIDs.
• Регулирование определяется в контракте, который кодирует набор правил для передачи токенов между лицами на основе информации, содержащейся в их DID. Это в основном обеспечивает регулирование на уровне контракта, а не на уровне пользователя.
• Соблюдение конфиденциальных переводов реализовано в соответствующем контракте ERC20, который использует контракт регулирования для обеспечения соблюдения при токенных переводах, без каких-либо изменений в самом API ERC20. В этом примере мы используем конфиденциальный контракт ERC20, где балансы и суммы скрыты, но это бы работало так же хорошо с обычным, открытым токеном ERC20.

Архитектура нашего протокола конфиденциального DID Onchain

Контракт реестра идентификации

Контракт IdentityRegistry - это реестр DID пользователей, выданных регистраторами, включающий набор зашифрованных идентификаторов, таких как их национальность, возраст, номер социального страхования и т. д. Эти идентификаторы хранятся как зашифрованные 32-разрядные значения (euint32).

Контракт также обрабатывает разрешения, такие как:

• Обеспечение владельцу контракта (например, AFNIC) возможности добавлять, удалять или обновлять регистраторов.
• Позволяет регистраторам добавлять, удалять или обновлять созданные ими DID пользователей.
• Позволяя пользователям предоставлять смарт-контрактам доступ к конкретным атрибутам их DIDs. Важно отметить здесь, что пользователь несет ответственность за то, чтобы не предоставлять доступ к вредоносным контрактам, так же как он несет ответственность за то, чтобы вредоносные контракты не тратили их токены.

В качестве первого шага давайте реализуем логику создания и управления DID:

Теперь следующим шагом будет реализация логики идентификаторов и контроля доступа.

Идентификатор - это просто строка (например, «дата рождения») и зашифрованное 32-битное значение. Его можно создать или обновить только регистратору. Пользователь не может создавать свои собственные идентификаторы, так как мы хотим, чтобы они были подтверждены регистратором.

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

контракт IdentityRegistry - это EIP712WithModifier, Ownable

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

контракт IdentityRegistry является EIP712WithModifier, Ownable

Договор о регулировании

Следующим шагом будет создание нашего контракта о регулировании.

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

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

В этом примере мы реализуем некоторые основные правила:

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

Вместо того чтобы сбой транзакции, который может раскрыть чувствительную информацию, мы просто установим сумму перевода равной 0, если одно из условий не выполняется. Для этого используется гомоморфный тернарный оператор, называемый cmux: value = TFHE.cmux(encryptedCondition, valueIfTrue, valueIfFalse

Соответствующий конфиденциальный контракт ERC20

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

• Баланс пользователя и сумма перевода зашифрованы.
• Соответствие осуществляется при передаче вызовом контракта регулирования.
• Видимость определенных балансов может быть предоставлена адресам в белом списке (например, регуляторам)

Контракт регулирования вызывается с помощью простого вызова. Это подразумевает, что пользователи должны предоставить доступ к контракту ERC20 перед инициированием любого перевода; в противном случае перевод будет отменен.

Наконец, теперь мы можем создать наш контракт ERC20:

Аналогично тому, как пользователи предоставляют разрешения протоколам DeFi на использование своих токенов, им потребуется предоставить разрешение контракту на доступ к идентификаторам, необходимым для контракта о регулировании. Это делается с помощью вызова Identity.grantAccess(contractAddress, identifiers), которое может быть получено путем вызова метода просмотра ERC20.identifiers(). Этот список поступает непосредственно из контракта ERC20Rules для обновления свойств.

Соответствие и конфиденциальность могут сосуществовать!

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

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

Дополнительные ссылки

• ЗвездаХранилище Github fhEVM Zamaодобрить нашу работу.
• ОбзорДокументация fhEVM Zama.
• Получите поддержку на нашем коммуникационные каналы.
• Помогите развивать пространство FHE с помощью программы Zama Bounty: Создайте онлайн-игру на цепи, которая скрывает частные состояния, используя программное средство конфиденциальности fhEVM от Zama (15,000€ in prize).

Отказ от ответственности:

1. Эта статья перепечатана с [zama]。 Все авторские права принадлежат оригинальному автору [fhEVM]. Если есть возражения по поводу этого перепечатывания, пожалуйста, свяжитесь с Gate Learnкоманды, и они оперативно справятся с этим.
2. Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, являются исключительно мнением автора и не являются инвестиционным советом.
3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.