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

fhEVM - це звичайний EVM з деякими попередніми компіляціями, які дозволяють обчислення на зашифрованих станах за допомогою нашої бібліотеки гомоморфного шифрування TFHE-rs. З погляду розробника тут немає криптографії: вони просто пишуть код Solidity, використовуючи надані нами типи даних (euint32, ebool і т. Д.). Однією з великих переваг fhEVM порівняно з іншими рішеннями щодо конфіденційності є те, що всі дані та обчислення відбуваються на ланцюжку. Це означає, що ви можете мати такий же рівень комбінаторності та доступності даних, як і у звичайних, текстових контрактах.

Ця властивість є ключовою для створення програмованої конфіденційності, оскільки весь логіка контролю доступу може бути визначена в самому контракті. Немає нічого, що потрібно жорстко закодувати в протокол, і нічого, що користувач повинен робити позапротокольно для відповідності. Додаток може забезпечити відповідність безпосередньо, всього лише кількома рядками коду Solidity!

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

Абстракція ідентичності через ланцюжок, конфіденційні DIDs

Децентралізований ідентифікатор (DID) - це унікальний цифровий ідентифікатор, який видано суб'єктом, таким як уряд, реєстратор, компанія або сам користувач. Цей DID може бути пов'язаний з криптографічним ключем, який підтверджує власність користувача DID, наприклад, гаманець EVM. Але він також може зберігати цілий ряд атрибутів, таких як вік користувача, національність, номер соціального забезпечення і т.д. Ці атрибути, з свого боку, можуть бути використані для доведення того, що ви задовольняєте певну умову (називається «атестація»), наприклад, бути повнолітнім або не бути громадянином Нарнії.

Більшість DIDs реалізовані клієнтською стороною і використовують докази з нульовим відкриттям для генерації атестацій. Хоча це прийнятно у багатьох випадках, це швидко ускладнюється, коли в операцію включені кілька користувачів, коли потрібно застосовувати складні правила до DID або коли потрібно зберігати загальний набір правил для всіх. Це в основному та сама компроміс, що й у застосунках розподілених та хмарних обчислень.

Однак наявність централізованого реєстру DID вирішить ці проблеми, оскільки ви можете просто попросити реєстр перевірити, чи всі відповідають вимогам. Це також спростить відстеження правил, оскільки вам потрібно буде впроваджувати їх лише в одному місці. Блокчейн був би ідеальною інфраструктурою для цього, оскільки він забезпечив би компонування між DID і додатками, які вимагають відповідності, а також компонування між самими правилами.

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

На щастя, у нас є рішення: гомоморфне шифрування, а точніше fhEVM! Завдяки можливості компонування в зашифрованому стані ми можемо розміщувати DID користувача безпосередньо в ланцюжку в зашифрованій формі, а сумісні програми перевіряють атрибути за допомогою простого виклику контракту. Можливість керувати ідентифікацією за допомогою смарт-контракту, який ми називаємо «Абстракція ідентичності», схожа на те, як можна керувати коштами за допомогою смарт-контракту з абстракцією облікового запису.

Цей посібник має 3 частини:

• Абстракція ідентифікації виконується за допомогою реєстраційного контракту, який відповідає за управління ідентифікаціями та свідоцтвами. Тут ми припускаємо, що DIDs є офіційними урядовими ID. Сам реєстр управляється центральною владою (наприклад, AFNIC), яка може створювати реєстраторів (наприклад, компанії з KYC, такі як Onfido, Jumio і т. д.), які, з свого боку, можуть створювати користувальницькі DIDs. Користувач потім переходить до свого реєстратора, щоб управляти та оновлювати свої DIDs.
• Регулювання визначається в контракті, який кодує набір правил для передачі токенів між особами на основі інформації, що міститься в їх DIDs. Фактично, воно забезпечує дотримання правил на рівні контракту, а не на рівні користувача.
• Дотримуйтеся конфіденційних переказів реалізовано в дотриманні контракту ERC20, який використовує контракт регулювання для забезпечення дотримання у переказах токенів, без змін до самого API ERC20. У цьому прикладі ми використовуємо конфіденційний контракт ERC20, де баланси та суми приховані, але він працюватиме так само добре з звичайним, текстовим токеном ERC20.

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

Договір реєстрації особистості

Контракт IdentityRegistry — це реєстр ідентифікаторів користувачів, які видаються реєстраторами та включають набір зашифрованих ідентифікаторів, таких як їх громадянство, вік, номер соціального страхування тощо. Ці ідентифікатори зберігаються як зашифровані 32-бітові значення (euint32).

Договір також вирішує дозволи, такі як:

• Дозволяє власнику контракту (наприклад, AFNIC) додавати, видаляти або оновлювати реєстраторів.
• Дозволяє реєстраторам додавати, видаляти або оновлювати створені ними користувальницькі DID.
• Дозволяючи користувачам надавати смарт-контрактам доступ до конкретних атрибутів їх DIDs. Важливо зазначити тут, що користувач відповідальний за те, щоб не надавати доступ до зловмисних контрактів, так само, як вони відповідальні за те, щоб не допускати витрат токенів зловмисними контрактами.

Як перший крок, давайте реалізуємо логіку створення та управління DID:

Тепер наступним кроком є реалізація логіки для ідентифікаторів та контролю доступу.

Ідентифікатор - це просто рядок (наприклад, "дата народження") та зашифроване 32-бітне значення. Його може створювати або оновлювати лише реєстратор. Користувач не може створювати власні ідентифікатори, оскільки ми хочемо, щоб їх сертифікував реєстратор.

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

контракт IdentityRegistry є EIP712WithModifier, Ownable

Тепер ми можемо завершити наш контракт реєстрації ідентичності, додавши необхідні методи доступу з деякими умовами та обробкою помилок.

контракт IdentityRegistry є EIP712WithModifier, Ownable

Договір про регулювання

Наступним кроком є створення нашого контракту про регулювання.

При впровадженні набору правил для переказів між двома особами важливо розуміти, що ці правила можуть змінюватися з часом. Наявність одного смарт-контракту, який визначає всю регуляцію для певного контексту, такого як переказ коштів, означає, що контракти ERC20 не повинні вести облік регулювання самостійно. Уряди можуть просто оновити цей контракт, і він автоматично пошириться на всі токени, які його реалізували.

На самому початку регуляторний контракт - це лише набір умов, які порівнюються з зашифрованими атрибутами ідентичності. Щоб уникнути зловживань, користувачі не надають безпосереднього доступу до регуляторного контракту, а надають доступ до контракту ERC20, який потім виконує делегований виклик до регуляторного контракту. Цей підхід забезпечує, що лише контракт ERC20, якому користувач довіряє, може отримати доступ до їхньої інформації. Пам'ятайте, що як відправник, так і отримувач повинні надати дозвіл на контракт ERC20, перш ніж може відбутися передача між ними.

У цьому прикладі ми реалізуємо деякі основні правила:

• Перекази в межах країни необмежені, але перекази в іншу країну обмежені 10 000 токенами.
• Користувач, внесений до чорного списку, не може переказувати або отримувати токени.
• Користувач не може передавати токени в країну з чорного списку.

Замість відмови в операції, що може розкрити чутливу інформацію, ми просто встановимо суму переказу на 0, якщо одна з умов не виконується. Це використовує гомоморфний тернарний оператор, який називається cmux: значення = TFHE.cmux(encryptedCondition, valueIfTrue, valueIfFalse

Дотримуючийся конфіденційний контракт ERC20

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

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

Договір регулювання викликається простим викликом. Це означає, що користувачі повинні надати доступ до контракту ERC20, перш ніж ініціювати будь-яку передачу; В іншому випадку переказ буде скасовано.

Нарешті, ми тепер можемо створити наш контракт ERC20:

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

Відповідність та конфіденційність можуть існувати поруч!

Сподіваюся, цей посібник показав вам, що відповідність - не складна річ для побудови, якщо є правильні інструменти. Хоча спочатку ми створили fhEVM для забезпечення конфіденційності в блокчейні, ми швидко зрозуміли, що цю технологію можна використовувати для управління ідентичністю та програмованої відповідності.

Запропонований дизайн тут is far from perfect, but we believe it can easily be improved and launched as a real world use case, so that Відповідність no longer has to be synonymous with surveillance!

Додаткові посилання

• Зірка Репозиторій Zama's fhEVM на Githubпідтримати нашу роботу.
• ОглядДокументація Zama's fhEVM.
• Отримайте підтримку нашоїкомунікаційні канали.
• Допоможіть розвивати простір FHE за допомогою програми нагород Zama: Створіть гру on-chain, яка приховує приватні стани, використовуючи програмовану конфіденційність fhEVM від Zama (15,000€ in prize).

Попередження:

1. Ця стаття була передрукована з [ zama]。 Усі авторські права належать оригінальному авторові [fhEVM]. Якщо є заперечення до цього перевидання, будь ласка, зв'яжіться з Ворота Навчаннякоманда, і вони вирішать це негайно.
2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, є виключно тими, хто їх написав, і не становлять жодних інвестиційних порад.
3. Переклади статей на інші мови виконуються командою Gate Learn. Якщо не зазначено, копіювання, поширення або плагіатування перекладених статей заборонено.