原文：《Конфіденційність блокчейну та відповідність нормативним вимогам: на шляху до практичної рівноваги》
Спікери: Віталік Бутерін, Джейкоб Іллум, Маттіас Надлер, Фабіан Шар і Амін Сулеймані
Компіляція: How Odaily Planet Daily Husband
Сьогодні V God та інші є співавторами дослідницької роботи про протоколи конфіденційності під назвою «Конфіденційність блокчейну та відповідність нормативним вимогам: на шляху до практичної рівноваги» (Blockchain Privacy and Regulatory Compliance: Towards a Practical Equilibrium).
У статті описується новий протокол підвищення конфіденційності на основі смарт-контрактів — пул конфіденційності, обговорюються його переваги та недоліки, а також показано, як він балансує між чесними та нечесними користувачами. Протокол розроблено для використання доказів із нульовим знанням для перевірки легітимності коштів користувачів без розкриття їх повної історії транзакцій, збалансовуючи конфіденційність і нормативні вимоги, відфільтровуючи кошти, пов’язані зі злочинною діяльністю.
Odaily Planet Daily тепер компілює суть статті таким чином.
Вступ
Публічні блокчейни є прозорими за дизайном. Основна ідея полягає в тому, що будь-хто може вибрати перевірку транзакцій, не покладаючись на централізовану третю сторону; завдяки зменшенню залежностей це забезпечує нейтральну основу для різноманітних програм, включаючи, але не обмежуючись, фінанси та самосуверенну ідентифікацію.
Однак, з точки зору конфіденційності, публічні набори даних володіють кожною транзакцією, що містить кожну адресу блокчейну. Щоразу, коли хтось передає актив на іншу адресу або взаємодіє зі смарт-контрактом, ця транзакція завжди буде видимою в блокчейні. Це явно не відповідає вимогам конфіденційності.
Наприклад: Аліса оплачує вечерю в ресторані за допомогою блокчейн-гаманця. Тепер одержувач знає адресу Аліси та може аналізувати всю минулу та майбутню діяльність за цією адресою. Так само Аліса тепер знає адресу гаманця ресторану та може використовувати цю інформацію, щоб отримати адреси гаманця інших гостей або переглянути дохід ресторану. Або третя сторона (наприклад, соціальні мережі), яка знає адресу ресторану та гаманця Аліси, може легко визначити фактичну адресу проживання Аліси та вивчити її минулі та майбутні операції.
**Поширення протоколів, що покращують конфіденційність, має вирішити вищевказані проблеми. Це дозволяє користувачам вносити кошти в протокол, використовуючи одну адресу, і знімати кошти з протоколу пізніше, використовуючи іншу адресу. Усі депозити та зняття коштів все ще видно в блокчейні, але відповідність між конкретними переказами та переказами більше не є публічною. **
Одним із найвідоміших протоколів для підвищення конфіденційності є Tornado Cash. Він успішно вирішує вищезазначені проблеми, дозволяючи користувачам зберегти певну конфіденційність. Однак, крім законних користувачів, які намагаються захистити свої дані, Tornado Cash також використовують різні зловмисники. Дані про депозит показують, що хакерська група переказувала кошти через цей протокол. Є докази того, що цей протокол для підвищення конфіденційності також використовується північнокорейськими хакерськими групами, що в кінцевому підсумку призвело до того, що адреси смарт-контрактів протоколу потрапили до списку спеціально визначених громадян і заблокованих осіб, який веде Управління з контролю за іноземними активами США (OFAC). (часто називають списком SDN) ).
**Основною проблемою Tornado Cash є стирання межі між законними та злочинними користувачами. **Таким чином, Tornado Cash надає функцію відповідності, яка дозволяє користувачам створювати підтвердження того, з якого депозиту надійшло дане зняття. Незважаючи на те, що цей механізм дозволяє людям доводити свою невинуватість, це відбувається за рахунок необхідності довіряти централізованому посереднику та створення інформаційної асиметрії. Зрештою, механізм майже не використовувався користувачами.
У цьому документі обговорюється розширення цього підходу, який дозволяє користувачам публічно засвідчувати інформацію про те, з яких депозитів могли походити їх зняття, не втрачаючи конфіденційності. **Пули конфіденційності пропонують загальну концепцію: Дозволити підтвердження членства («Я підтверджую, що мої зняття було здійснено з одного з цих депозитів») або докази виключення («Я підтверджую, що мої зняття коштів не походили з жодного з цих депозитів») ) . **У цій статті обговорюється ця пропозиція та пояснюється, як її можна використовувати для досягнення балансу між чесними та нечесними користувачами.
Зауважте, що пули конфіденційності надають додаткові параметри, розширюючи набір дій користувача. Вони все одно можуть надати більш детальну сертифікацію конкретним контрагентам, якщо це необхідно. Проте в деяких випадках може бути достатньо підтвердження членства або виключення. Крім того, можливість публічного оприлюднення цих сертифікатів пропонує ряд переваг порівняно з двостороннім розкриттям інформації.
2. Технічна підготовка
У цьому розділі ми надаємо короткий технічний огляд і обговорюємо технічну конструкцію та загальні принципи протоколів, таких як пули конфіденційності.
1. Конфіденційність блокчейну до ZK-SNARK
Історично прихильники блокчейну стверджували, що хоча всі транзакції прозорі, блокчейни можуть зберігати конфіденційність, оскільки вони забезпечують анонімність.
З появою сучасних інструментів кластеризації та аналізу цей захист конфіденційності став недостатнім. Щоб покращити конфіденційність загальнодоступних блокчейнів, були представлені більш потужні технології, такі як Token Join і Monero. Однак ці технології все ще несуть ризик витоку даних. **
Потім з’явилися технології загального призначення з нульовим знанням, такі як Zcash і Tornado Cash, які можуть зробити набір анонімності кожної транзакції рівним усьому набору всіх попередніх транзакцій. Цю техніку часто називають ZK-SNARK.
2、 ZK-SNARK
ZK-SNARK — це техніка, яка дозволяє перевіряльнику доводити певне математичне твердження щодо загальнодоступних і приватних даних, задовольняючи при цьому дві ключові властивості: нульовий рівень знань і простоту. **
● З нульовим знанням: не розкриває жодної інформації про особисті дані, крім підтвердження того, що зазначені особисті дані відповідають заяві.
● Стислість: Докази короткі та їх можна швидко перевірити, навіть якщо підтверджені твердження вимагають трудомістких обчислень.
ZK-SNARK отримали широку увагу з боку блокчейн-спільноти через їх значення для масштабованості, наприклад ZK-rollups. Для програм конфіденційності простота не особливо важлива, але необхідне знання.
«Заявку» доказу ZK-SNARKs можна розглядати як тип програми під назвою «схема», яка обчислює результат функції f(x, w) із загальнодоступними та приватними вхідними даними, а потім доводить, що для даного загальнодоступний вхід x , існує приватний вхід w такий, що f(x, w) оцінюється як True.
3. Застосування ZK-SNARK в таких системах, як Zcash і Tornado Cash
Існують деякі незначні відмінності між різними версіями Zcash і системами, натхненними нею (наприклад, Tornado Cash). Однак основна логіка, на яку вони спираються, дуже схожа. У цьому розділі описано просту версію, яка приблизно відповідає тому, як працюють ці протоколи.
Токени складаються з секретів, які зберігаються їх власниками. З s можна отримати два значення:
● Public Token ID L = хеш (s + 1)
● НуліфікаторU = хеш (s + 2)
Серед них хеш відноситься до хеш-функції пароля, наприклад SHA 256. Якщо задано s, можна обчислити ідентифікатор маркера та обнулювач. Однак, враховуючи набір обнулювачів і загальнодоступний ідентифікатор маркера, псевдовипадкова поведінка хеш-функції гарантує, що ви не зможете визначити, який зероайзер пов’язаний з яким ідентифікатором маркера, якщо не знаєте секрети, які згенерували обидва.
Блокчейн відстежує всі ідентифікатори токенів, які були «створені», і всі нуліфікатори, які були «витрачені». Обидва набори постійно зростають (якщо протокол не хоче примусово витрачати токени).
Колекція ідентифікаторів токенів зберігається в структурі даних, яка називається деревом Merkle: якщо дерево містить N елементів, кожен суміжний елемент хешується (результатом є ⌈ N/2 ⌉ хешів), кожен сусідній хеш знову хешується (результатом є ⌈ N/4 ⌉ хешів) і так далі, доки всі дані не будуть зафіксовані в одному «кореневому хеші».
Враховуючи конкретне значення в дереві та кореневий хеш, можна надати гілку Merkle: «сестринське значення», яке хешує разом на кожному кроці шляху від цього значення до кореня. Ця гілка Merkle є корисною, оскільки це невеликий (log 2(N) хешів) фрагмент даних, який можна використовувати для підтвердження того, що будь-яке конкретне значення насправді є в дереві. На малюнку нижче показано приклад дерева Merkle висотою 4.
Коли користувачі надсилають монети іншим, вони надають наступне:
● Zerizer U, який ви хочете витратити
● Ідентифікатор маркера L' нового маркера, який потрібно створити (одержувача просять надати це)
● ЗК-СНАРК.
ZK-SNARK містить такі приватні входи:
● секрети користувача
● Гілка Merkle у дереві ідентифікаторів маркерів, яка доводить, що маркер з ідентифікатором маркера L = hash(s + 1) дійсно був створений у певний момент у минулому
Він також містить такі загальнодоступні дані:
● U, обнулювач витрачених жетонів
● R, кореневий хеш, проти якого спрямовані докази Меркла
ZK-SNARK підтверджує дві властивості:
● U = хеш (s + 2)
● Відділення Merkle дійсні
Окрім ZK-SNARK, протокол перевіряє наступне:
● R — поточний або історичний кореневий хеш дерева ідентифікаторів маркерів
● U немає в наборі витрачених нуліфікаторів
Якщо транзакція дійсна, вона додає U до набору використаних обнулювачів і L' до списку ідентифікаторів токенів. Показ U запобігає подвійній витраті одного жетона. Однак іншу інформацію розголошувати не будуть. **Зовнішній світ може лише бачити, коли транзакції були надіслані; у них немає способу отримати шаблон того, хто відправив або отримав ці транзакції, і немає способу розрізнити уніфіковане джерело токенів. **
З наведеної вище моделі є два винятки: депозити та зняття коштів. У депозитах ідентифікатори токенів можна створювати без анулювання певного попереднього токена. Депозити не є анонімними з точки зору конфіденційності, оскільки зв’язок між заданим L і зовнішньою подією, яка дозволяє додавати L (у Tornado Cash, внесення ETH у систему; у Zcash, новий майнінг ZEC), є відкритим.
Іншими словами, **депозити прив’язані до минулої історії транзакцій. **Під час зняття коштів зеройзер використовуватиметься без додавання нового ідентифікатора токена. Це може відключити зняття з відповідних депозитів і опосередковано з минулою історією транзакцій. Однак зняття коштів можна пов’язати з будь-якими майбутніми транзакціями, які відбудуться після події зняття.
У першій версії Tornado Cash немає концепції внутрішніх переказів, вона дозволяє лише депозити та зняття коштів. Пізніші версії, все ще експериментальні, також дозволяли внутрішні перекази та монети різного номіналу, включаючи підтримку операцій «розділення» та «злиття». У наступних розділах ми обговоримо, як розширити базову систему переказу монет із збереженням конфіденційності та пули конфіденційності до довільних номіналів.
4. ZK-SNARK у пулі конфіденційності
**Основна ідея пулу конфіденційності полягає в тому, що користувач не тільки доводить, що зняття пов’язано з попереднім депозитом за допомогою підтвердження з нульовим знанням, але також доводить, що він належить до більш жорсткого набору асоціацій. **Пов’язана колекція може бути підмножиною всіх депозитів, зроблених раніше, або колекцією, що містить лише власні депозити користувача, або чимось середнім. Користувачі вказують набір, надаючи корінь Merkle пов’язаного набору як загальнодоступний вхід.
Як показано на малюнку нижче, для простоти ми безпосередньо не доводимо, що пов’язаний набір справді є підмножиною депозитів, зроблених раніше; замість цього ми лише вимагаємо, щоб користувач використовував той самий ідентифікатор монети, що й кінцевий вузол, щоб доведіть дві гілки Меркла через нульове знання:
● Введіть гілку Merkle кореня R загального набору ідентифікаторів монет
● Введіть гілку Merkle наданого кореневого RA набору асоціацій
Намір цього полягає в тому, щоб десь розмістити повний набір асоціацій (може бути в ланцюжку). Основна концепція така: замість того, щоб вимагати від користувачів точно вказувати, з якого саме депозиту вони зняли кошти, або, навпаки, не надавати жодної інформації, окрім підтвердження відсутності подвійних витрат, ми дозволяємо користувачам надавати набір варіантів, які можуть бути джерелом коштів, і ця колекція може бути такою широкою чи вузькою, як вони хочуть.
Ми підтримуємо екосистему, яка полегшує користувачам визначення набору асоціацій відповідно до їхніх уподобань. Далі в цій статті буде описано лише інфраструктуру, засновану на цьому простому базовому механізмі, і його наслідки.
3. Практичні міркування та випадки використання
Проаналізуйте, як протоколи підвищення конфіденційності використовуються на практиці з точки зору програми.
1. Варіанти використання асоціативних колекцій
Щоб проілюструвати цінність цієї програми в середовищі правоохоронних органів, ось приклад:
Припустимо, у нас є п'ять користувачів: Аліса, Боб, Карл, Девід, Єва. Перші чотири користувачі є чесними, законослухняними, але усвідомлюють конфіденційність, а Єва — злодійка. Оскільки громадськість знає, що Єва є злодієм через інформацію про те, що монети за адресою, позначеною «Єва», викрадені. На практиці це трапляється досить часто: у загальнодоступних блокчейнах кошти, згенеровані використанням уразливостей у протоколах DeFi, відстежуються для виявлення незаконних коштів, що надходять у Tornado Cash.
Коли кожен із п’яти користувачів робить виведення, вони можуть вибрати, який пов’язаний набір вказати. Їхній набір зв’язків має включати їхні власні депозити, але вони вільні вибирати, яку з інших адрес включити. Перші чотири користувачі були мотивовані, з одного боку, бажанням максимально захистити свою конфіденційність. Це спонукає їх прагнути розширити коло своїх асоціацій. З іншого боку, вони хочуть зменшити ймовірність того, що торговці чи біржі вважатимуть їхні монети підозрілими. Є простий спосіб зробити це: вони не включають Єву у свою пов’язану колекцію. Тому для чотирьох з них вибір очевидний: нехай їхній набір асоціацій буде {Аліса, Боб, Карл, Девід}.
Звичайно, Єва також хоче максимізувати свій набір асоціацій. Але вона не може виключити свої власні депозити, тому вона змушена мати пов’язаний набір, що дорівнює набору всіх п’яти депозитів. Відповідний вибір учасників показано на малюнку нижче.
Хоча сама Єва не надала жодної інформації, завдяки простому процесу виключення ми можемо зробити чіткий висновок: п’ятий крок відступу може вийти лише від Єви.
2. Побудова асоційованих колекцій
У попередньому розділі показано один із можливих способів використання пов’язаних колекцій у протоколі, подібному до пулу конфіденційності, і те, як чесних учасників можна відокремити від поганих. Зауважте, що система не залежить від альтруїзму Аліси, Боба, Карла та Девіда; вони мають чіткі стимули, щоб виправдати своє розлучення. Розглянемо тепер більш детально побудову асоціативної колекції. Загалом існує дві основні стратегії створення асоціативних колекцій. Вони описані нижче та візуалізовані на малюнку нижче.
● **Включення (або членство): **Визначає певний набір депозитів, які ми маємо переконливі докази, щоб вважати їх низькими ризиками, і створює пов’язаний набір, який включає лише ці депозити.
● Виключити: Визначте певний набір депозитів, які ми маємо переконливі докази, щоб вважати їх високим ризиком, і створіть набір асоціацій, який включає всі депозити, окрім цих депозитів.
На практиці користувачі не вибирають депозити вручну для включення їх до пов’язаної колекції. Замість цього користувачі підписатимуться на посередників, яких ми називаємо Постачальники колекцій асоціацій (ASP), які створюють колекції асоціацій із певними властивостями. **У деяких випадках ASP можна створювати повністю в ланцюжку, не потребуючи втручання людини (або ШІ). В інших випадках ASP генеруватимуть пов’язану колекцію незалежно та публікуватимуть пов’язану колекцію в ланцюжку або деінде.
Ми наполегливо рекомендуємо публікувати принаймні корінь Merkle набору асоціацій у ланцюжку; це позбавляє зловмисних ASP можливості виконувати певні типи атак на користувачів (наприклад, надаючи різним користувачам різні набори асоціацій у спробі деанонімізувати їх). Уся колекція має бути доступною через API або в ідеалі через недорогу децентралізовану систему зберігання, таку як IPFS.
Можливість завантажувати весь пов’язаний набір є важливою, оскільки вона дозволяє користувачам генерувати докази членства локально, не розкриваючи жодної додаткової інформації для ASP, навіть не про депозити, що відповідають їхнім зняттям.
Ось як ASP можуть бути структуровані на практиці:
● **Відкладене додавання для виключення зловмисників: **Будь-який депозит автоматично додається до пов’язаної колекції через фіксований проміжок часу (наприклад, 7 днів), але якщо система виявляє, що депозит пов’язаний із відомою поганою поведінкою (наприклад, великий -масштабна крадіжка або адреса в опублікованому урядом списку санкцій), депозит ніколи не буде додано. На практиці цього можна досягти за допомогою колекцій, які курує спільнота, або існуючих постачальників послуг скринінгу транзакцій, які вже виконали роботу з ідентифікації та відстеження депозитів, пов’язаних із поганою поведінкою.
● Щомісячна плата за одну особу: для того, щоб приєднатися до пов’язаного збору, вартість депозиту має бути нижчою за певний фіксований максимум, і вкладник повинен без жодних відомостей довести, що він володіє певним маркером ідентифікації (наприклад, за підтримки уряду національні ідентифікаційні системи або легкі механізми, такі як перевірка облікового запису в соціальних мережах). Змішано з додатковим параметром, який представляє механізм скасування поточного місяця, щоб гарантувати, що кожна особа може надсилати депозити до пов’язаної колекції лише раз на місяць. Розробка намагається реалізувати дух багатьох загальних правил боротьби з відмиванням грошей, згідно з якими невеликі платежі нижче певного порогу забезпечують вищий рівень конфіденційності. Зауважте, що це можна реалізувати повністю як смарт-контракт, який не вимагає ручного контролю для підтримки поточної роботи.
● Щомісячна плата для довіреного члена спільноти: Подібна до місячної плати для однієї особи, але більш обмежена: користувачі повинні довести, що вони є членами спільноти, якій дуже довіряють. Довірливі учасники спільноти погоджуються надавати конфіденційність один одному.
● **Оцінка в режимі реального часу на основі штучного інтелекту: **Система AI ASP може надати оцінку ризику для кожного депозиту в режимі реального часу, і система виведе відповідний набір, що містить депозити з оцінкою ризику нижче певного порогу. Потенційно ASP може виводити кілька наборів, що відповідають численним пороговим значенням оцінки ризику.
4. Подальший технічний опис
У цьому розділі ми аналізуємо, як пропозиція підтримує довільні найменування, і обговорюємо спеціальні випадки, такі як повторна сертифікація, двосторонні прямі докази та послідовні докази.
1. Підтримуйте будь-яку конфесію
Наведена вище спрощена система захисту конфіденційності монет підтримує лише перекази монет того самого номіналу. Zcash підтримує довільні номінали за допомогою моделі UTXO. Кожна транзакція може мати кілька входів (потрібно опублікувати обнулювач кожного входу) і кілька виходів (потрібно опублікувати ідентифікатор маркера кожного виходу). Кожен створений ідентифікатор токена має супроводжуватися криптографічним номіналом. На додаток до підтвердження дійсності зеройзера, кожна транзакція повинна супроводжуватися додатковим доказом того, що сума номіналів створених монет не перевищує суму номіналів витрачених монет. Малюнок нижче ілюструє цей додатковий доказ.
Цю конструкцію можна розширити для підтримки депозитів і зняття, розглядаючи депозити як (незашифровані) входи, а зняття як (незашифровані) виходи. Крім того, дизайн можна обмежити для спрощення аналізу. Наприклад, можна дозволити лише часткове зняття, дозволяючи транзакції мати один зашифрований вхід і два виходи: незашифрований вихід, що представляє зняття, і зашифрований вихід «зміна», що представляє залишкові кошти, які можна використовувати для майбутніх зняття.
Природне запитання полягає в тому, як розширити цей дизайн для підтримки пулів конфіденційності. Вставити його без змін у пул конфіденційності не є ідеальним, оскільки графік транзакцій не узгоджується з тим, що ми інтуїтивно очікуємо: якщо користувач вносить 10 токенів, а потім витрачає 1 + 2 + 3 + 4 у чотирьох послідовних жетонах зняття, ми хочемо розглядати всі чотири зняття як джерело початкового депозиту в 10 токенів. Але фактичний результат такий, як показано нижче: джерелом першого зняття є депозит 10 токенів, а потім джерелом другого зняття є результат зміни 9 токенів, створений першим зняттям, і так далі за аналогією. На практиці це створює проблеми, оскільки ASP вимагає перевірити проміжний депозит і додати його до пов’язаної колекції.
Для того, щоб усі чотири зняття коштів у цьому прикладі мали початковий депозит у 10 монет як джерело, нам потрібно вирішити дві проблеми:
● Переконайтеся, що кожне часткове зняття не пов’язане публічно з іншими зняттями
● Дозвольте кожному частковому зняттю включати депозит як член пов’язаної колекції
Якщо ми підтримуємо лише часткове зняття коштів, а не більш складні транзакції MIMO, і гарантуємо, що кожне зняття має певний відповідний «початковий депозит», існує кілька способів зробити це безпосередньо. Природним і масштабованим підходом є поширення обіцянки певної інформації через транзакції. Наприклад, ми могли б вимагати, щоб транзакції містили хеш зобов’язання (coinID+hash®) з додаванням деякого випадкового значення r, щоб забезпечити засліплення, і вимагали, щоб ZK-SNARK доводили, що зобов’язання в транзакції є таким самим, як і її батьківська транзакція. Якщо материнська транзакція сама по собі є зняттям коштів, зобов’язання збігається з ідентифікатором монети початкового депозиту, а якщо материнська транзакція є депозитом, зобов’язання збігається з ідентифікатором монети початкового депозиту. Таким чином, кожна транзакція в ланцюжку повинна містити зобов’язання щодо оригінального ідентифікатора депозитної монети та вимагати підтвердження того, що це значення є у пов’язаному наборі, наданому транзакцією.
Щоб покращити конфіденційність проти атак агрегації балансу, ми також можемо підтримувати злиття монет. Наприклад, якщо у мене залишилося кілька монет, я можу об’єднати їх із своїм наступним депозитом. Щоб врахувати це, ми можемо вимагати, щоб транзакції прив’язувалися до набору ідентифікаторів монет, а також вимагали, щоб транзакції з кількома вхідними даними прив’язувались до об’єднання їхніх батьківських транзакцій. Відкликання міститиме доказ того, що всі закріплені ідентифікатори монет є у пов’язаному наборі.
2. Особливі обставини
● Повторна сертифікація: користувачам потрібна інформація про секретний депозит, щоб зняти депозити, подібно до протоколів пулу конфіденційності. Та сама секретна інформація також використовується для створення доказів приналежності до набору асоціацій. Збереження секретної інформації дозволяє користувачам створювати нові докази для різних наборів або оновлювати пов’язані набори. Це дає користувачам більшу гнучкість, але також може створювати додаткові ризики.
● Пряма двостороння сертифікація: У деяких випадках користувачам може знадобитися розкрити іншій стороні точне джерело зняття коштів. Користувачі можуть створити пов’язану колекцію, що містить лише їхні депозити, і створити докази проти цієї колекції. Ці докази зазвичай є винятками та сприяють лише частковій конфіденційності, коли вони надаються двом сторонам. Однак обмін доказами вимагає встановлення сильних припущень довіри.
● Доказ послідовності: У економіці швидких транзакцій із використанням системи, як-от пул конфіденційності, протокол потрібно змінити, щоб адаптуватися до цього середовища. Окрім типів транзакцій депозиту та зняття коштів, протокол також має підтримувати внутрішні операції надсилання для підвищення ефективності. Крім того, передаючи філії та ключі Merkle, користувачі можуть поширювати інформацію, пов’язану з історією транзакцій, щоб одержувачі могли перевірити походження коштів. Це гарантує, що кожен користувач має мінімум інформації, необхідної для впевненості в отриманих коштах.
На практиці токен може мати кілька «походжень». Наприклад, Боб є власником кав’ярні, і він отримує 5 жетонів від Аліси, 4 жетони від Ешлі, 7 жетонів від Енн, і в кінці дня йому потрібно заплатити Карлу 15 жетонів, щоб заплатити за обід. Натомість Девід, можливо, отримав 15 жетонів від Карла, 25 жетонів від Кріса, і хоче внести 30 жетонів Еммі (обмін). У цих більш складних випадках ми дотримуємося того самого принципу: історію, яка була додана до пов’язаної колекції досить давно, можна ігнорувати, тоді як нову історію потрібно передавати.
П'ять, детальніше
Система, подібна до пулу конфіденційності, може дозволити користувачам отримати більший захист конфіденційності своїх даних про фінансові операції, зберігаючи при цьому можливість довести відокремленість від відомої незаконної діяльності. Ми очікуємо, що чесні користувачі будуть заохочені брати участь у таких схемах завдяки поєднанню двох факторів:
● Бажання приватності
● Бажання не викликати підозри
1. Соціальний консенсус і набори асоціацій
Якщо існує повний консенсус щодо того, хороші чи погані кошти, система вироблятиме просту розділову рівновагу. Усі користувачі, які володіють «хорошими» активами, мають сильний стимул і здатність довести, що вони належать до «тільки хорошого» пов’язаного набору. З іншого боку, погані актори не зможуть надати таких доказів. Вони все ще можуть вносити «погані» кошти в пул, але це їм не на користь. Кожен може легко визначити, що кошти були зняті з протоколу з підвищеною конфіденційністю, і побачити, що зняття посилається на пов’язану колекцію, яка містить депозити із сумнівних джерел. Більше того, «погані» гроші не псують «хороші». При знятті коштів із законних депозитів їх власники можуть просто виключити всі відомі «погані» депозити зі своєї пов’язаної колекції.
Там, де існує глобальний консенсус і де висновки про те, чи вважається фінансування «хорошим» чи «поганим», залежать від соціальної точки зору чи юрисдикції, набір асоціацій може значно відрізнятися. Припустімо, що існують дві юрисдикції з різними наборами правил. Організації в юрисдикціях A і B можуть використовувати ту саму угоду про покращення конфіденційності та видавати сертифікати, які відповідають вимогам їхніх відповідних юрисдикцій. Обидва можуть легко запровадити конфіденційність у своїх власних пов’язаних колекціях і виключити вилучення коштів, які не відповідають вимогам відповідних юрисдикцій. Якщо потрібно, підтвердження членства може бути видано для перетину двох пов’язаних наборів, тим самим достовірно доводячи, що депозити, які відповідають їх зняттю, відповідають вимогам обох юрисдикцій.
Тому пропозиція є дуже гнучкою, і її слід розглядати як нейтральну інфраструктуру. З одного боку, це бореться з цензурою. Це дозволяє будь-кому приєднатися до пов’язаної колекції за власним вибором і зберегти конфіденційність у власній спільноті. З іншого боку, сторонні особи можуть вимагати докази проти певного набору асоціацій, які відповідають їхнім нормативним вимогам. Таким чином, навіть якщо існує спільнота зловмисників у протоколі, що підвищує конфіденційність, вони не зможуть приховати підозріле походження депозитів, доки інформація точно відображається в побудові пов’язаного набору.
2. Властивості асоційованих колекцій
Щоб функціонувати, асоціативні колекції повинні мати певні властивості. Збір має бути точним, щоб користувачі могли бути впевненими, що вони безпечно використовують свої вилучені кошти. Крім того, властивості кожного набору повинні бути стабільними, тобто менш імовірно змінюватися з часом. Це зменшує потребу у повторній перевірці зняття з нових колекцій. Нарешті, щоб досягти суттєвого захисту конфіденційності, набір асоціацій має бути достатньо великим і містити різні типи депозитів. Однак ці властивості суперечать одна одній. Загалом, великі та різноманітні колекції можуть мати кращі властивості конфіденційності, але можуть бути менш точними та стабільними, тоді як менші колекції легше підтримувати, але вони забезпечують меншу конфіденційність.
3. Практичні міркування та змагання
Регульовані організації, які приймають криптоактиви, повинні переконатися, що закони та правила, яким вони підпадають, дозволяють приймати такі кошти. Сьогодні багато з цих організацій покладаються на так звані інструменти скринінгу транзакцій: програмне забезпечення або служби, які аналізують блокчейн, щоб виявити потенційно підозрілу активність, посилання на нелегітимні адреси або інші невідповідні транзакції. Інструменти перевірки часто виражають ризик, пов’язаний з кожною угодою, через оцінку ризику. Цей рейтинг базується на призначенні переказних коштів та історії їх транзакцій. Протоколи, що покращують конфіденційність, можуть створювати проблеми в цьому відношенні. Вони усувають видимий зв’язок між депозитами та зняттям. Таким чином, за наявності протоколів, що підвищують конфіденційність, оцінка ризику повинна брати до уваги атестацію та призначати оцінку на основі набору асоціацій.
Інструменти та послуги для перевірки транзакцій в основному надають професійні компанії, які мають досвід аналізу блокчейну та суміжних юридичних галузей. В ідеалі ці фірми (і будь-хто інший) мали б доступ до всіх сертифікатів членства та відповідних пов’язаних колекцій, щоб надавати точні показники ризику для всіх транзакцій. Тому ми рекомендуємо зберігати всі докази в блокчейні або інших загальнодоступних сховищах доказів. Єдиним винятком є докази членства розміром один, надані певному контрагенту. Зі зрозумілих причин ці докази не повинні бути загальнодоступними.
Зберігання доказів безпосередньо в ланцюжку додає додаткових транзакційних витрат, але зменшує зусилля з координації, робить конкуренцію більш справедливою та пом’якшує квазімонопольні ризики, які можуть створювати постачальники інструментів перевірки через знання непублічних доказів.
Загальні параметри конфіденційного пулу дуже гнучкі. Створюючи певну колекцію асоціацій, протокол можна адаптувати до різних випадків використання. Ось два приклади цих спеціальних колекцій асоціацій:
● **Альянси комерційних банків можуть створити пов’язану колекцію, що містить лише депозити їхніх клієнтів. **Це гарантує, що підтвердження будь-якого зняття коштів, створених для колекції, пройшло процедури «Знай свого клієнта» (KYC) і протидії відмиванню грошей (AML) в одному з банків-учасників, але не розкриває, яке зняття коштів належить якому клієнту.
● **У випадках, коли від фінансових посередників вимагається чітко задокументувати джерело коштів, вони можуть вимагати від користувачів надати доказ проти пов’язаного набору, який містить лише депозити користувачів. **Після цього підтвердження буде обміняно на двосторонній основі з посередником, що дозволить їм відстежувати кошти так, ніби користувач ніколи не використовував пул конфіденційності. Хоча це вимагає від користувачів довіри посереднику в тому, що він не розкриє докази, в ідеалі це дає змогу користувачам дотримуватися правил без необхідності розголошувати інформацію громадськості.
4. Вибір дизайну та альтернативи
Дуже гнучке налаштування на основі зборів асоціацій, перевірки zk і добровільного розкриття інформації. Хоча це корисно для забезпечення того, що пропозиція може бути адаптована до різних юрисдикцій, слід проявляти велику обережність щодо вибору конкретного дизайну. Зокрема, є два потенційні коригування, проти яких ми виступаємо. Ми вважаємо, що вони мають проблеми з вимогами довіри та можуть створити квазімонополістичні ринкові структури. Нижче ми коротко описуємо та обговорюємо ці альтернативи:
● Централізований доступ: Правоохоронні органи, постачальники оцінки крипторизику або подібні суб’єкти можуть отримати доступ до перегляду зв’язків між транзакціями користувачів, зберігаючи конфіденційність від інших.
● **Білий список для всієї системи: **Системи конфіденційності можуть накладати обмеження на типи користувачів, які можуть вносити монети в їхні пули, вимагаючи від них надати додаткові докази або вимагаючи, щоб депозити очікували певний період часу, протягом якого централізована оцінка ризиків система може відхиляти депозити.
Ці два методи подібні тим, що вони надають привілеї певним об’єктам. Це породжує складні питання управління: хто має доступ до цієї інформації? Хто має повноваження керувати дозволами? Приватна компанія не здається гарним варіантом, оскільки будь-які привілеї, швидше за все, створять олігополістичну структуру ринку, де кілька компаній матимуть доступ до даних, які надаватимуть ці послуги, тоді як інші не зможуть конкурувати.
Подібним чином існує багато питань управління та політичних питань, з якими потрібно зіткнутися при наданні повноважень державним установам, особливо в міжнародному середовищі. Навіть якщо інституція на 100% заслуговує на довіру, не зловживає своєю владою для реалізації політичних завдань і не залежить від інших суб’єктів, які могли б змусити її зловживати своєю владою, така ситуація є симптомом стану спокою. Організації, члени, країни та політичні структури всередині організацій змінюються з часом. Може існувати зовнішній тиск, і існування цих привілеїв може створити додаткові стимули для порушення та отримання впливу на системи управління організації.
Крім того, атаки всередині або за межами організації або помилки від імені централізованої організації можуть мати далекосяжні наслідки. Ми вважаємо, що слід запобігати створенню таких централізованих точок відмови.
Зважаючи на це, ми розуміємо, що різні розміри транзакцій і обставини можуть вимагати різних комбінацій сертифікацій. Наприклад, для великих транзакцій багато користувачів можуть надати основні докази виключення в мережі та надати своїм контрагентам більш детальну інформацію про джерело коштів.
5. Напрямок поглиблених досліджень
Хоча це дослідження містить огляд того, як протоколи підвищення конфіденційності на основі zkSNARK можна використовувати в регульованих умовах, є кілька аспектів, які заслуговують на подальше вивчення.
По-перше, потрібно усвідомити, що конфіденційність, отримана за допомогою цих протоколів, залежить від багатьох факторів. Зловмисники можуть пов’язати зняття з конкретними депозитами на основі недостатньо великого набору зв’язків, поганого вибору кореня та помилки користувача.
Крім того, вибір, зроблений іншими користувачами, може негативно вплинути на вашу конфіденційність. У крайніх випадках усі інші учасники пулу опублікували б підтвердження членства в розмірі один, виявляючи прямий зв’язок між їхніми депозитами та зняттям коштів. Очевидно, це неявно виявило б зв’язок між єдиними транзакціями депозиту та зняття коштів. У більш тонкому прикладі обмеження з різних доказів членства можуть бути використані для отримання інформації та потенційного співвіднесення депозитів і зняття з високою ймовірністю. Після поєднання цієї підтвердженої інформації з метаданими транзакцій конфіденційність протоколу може бути скомпрометована.
Нарешті, зловмисний ASP може скомпілювати запропонований набір асоціацій таким чином, щоб він міг максимізувати вилучення інформації або підвищити сприйняту анонімність шляхом додавання депозитів, де відомі відповідні зняття. Усі ці питання вимагають подальших досліджень для оцінки наданих властивостей конфіденційності. Подібним чином було б цікаво продовжити дослідження властивостей розділення рівноваг, моделюючи, як хороші та погані гравці поводяться за певних припущень і як публічне доказування першого впливає на конфіденційність другого.
Юридичні експерти можуть додатково дослідити конкретні вимоги щодо розкриття інформації. Схема, запропонована в цій статті, є гнучкою, а висновки юридичних експертів можуть допомогти адаптувати угоду та екосистему, побудовану навколо неї, щоб забезпечити відповідність у різних правових юрисдикціях.
6. Висновок
У багатьох випадках конфіденційність і відповідність вважаються такими, що суперечать одне одному. Ця стаття припускає, що це не обов’язково так, якщо протоколи підвищення конфіденційності дозволяють користувачам доводити певні атрибути джерела їхніх коштів. Наприклад, припустімо, що користувачі можуть довести, що їхні кошти не пов’язані з депозитами відомого незаконного походження, або що кошти є частиною певної колекції депозитів, не розкриваючи жодної додаткової інформації.
Така установка може створити роздільну рівновагу, в якій чесні користувачі сильно стимулюються доводити, що вони належать до деякого сумісного набору асоціацій, і зберігати конфіденційність у цьому наборі. Натомість для нечесних користувачів вони не можуть надати таких доказів. Це дозволяє чесним користувачам відмежуватися від депозитів третіх сторін, з якими вони не погоджуються, або заборонити їм використовувати свої кошти в сумісному середовищі. Ми вважаємо, що пропозиція є дуже гнучкою та може бути скоригована відповідно до потенційних різноманітних нормативних вимог.
Цей документ слід розглядати як внесок у потенційне майбутнє співіснування фінансової конфіденційності та регулювання. Ми хочемо сприяти обговоренню та спрямовувати розмову в більш позитивне, конструктивне русло. Щоб розширити та змінити цю пропозицію, знадобиться співпраця між фахівцями-практиками, науковцями з різних дисциплін, політиками та регуляторами; кінцевою метою є створення інфраструктури для підвищення конфіденційності, яку можна використовувати в регульованому середовищі.
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Остання стаття Бутеріна: як протокол пулу конфіденційності захищає конфіденційність користувачів і відповідає вимогам відповідності?
原文：《Конфіденційність блокчейну та відповідність нормативним вимогам: на шляху до практичної рівноваги》
Спікери: Віталік Бутерін, Джейкоб Іллум, Маттіас Надлер, Фабіан Шар і Амін Сулеймані
Компіляція: How Odaily Planet Daily Husband
Сьогодні V God та інші є співавторами дослідницької роботи про протоколи конфіденційності під назвою «Конфіденційність блокчейну та відповідність нормативним вимогам: на шляху до практичної рівноваги» (Blockchain Privacy and Regulatory Compliance: Towards a Practical Equilibrium).
У статті описується новий протокол підвищення конфіденційності на основі смарт-контрактів — пул конфіденційності, обговорюються його переваги та недоліки, а також показано, як він балансує між чесними та нечесними користувачами. Протокол розроблено для використання доказів із нульовим знанням для перевірки легітимності коштів користувачів без розкриття їх повної історії транзакцій, збалансовуючи конфіденційність і нормативні вимоги, відфільтровуючи кошти, пов’язані зі злочинною діяльністю.
Odaily Planet Daily тепер компілює суть статті таким чином.
Вступ
Публічні блокчейни є прозорими за дизайном. Основна ідея полягає в тому, що будь-хто може вибрати перевірку транзакцій, не покладаючись на централізовану третю сторону; завдяки зменшенню залежностей це забезпечує нейтральну основу для різноманітних програм, включаючи, але не обмежуючись, фінанси та самосуверенну ідентифікацію.
Однак, з точки зору конфіденційності, публічні набори даних володіють кожною транзакцією, що містить кожну адресу блокчейну. Щоразу, коли хтось передає актив на іншу адресу або взаємодіє зі смарт-контрактом, ця транзакція завжди буде видимою в блокчейні. Це явно не відповідає вимогам конфіденційності.
Наприклад: Аліса оплачує вечерю в ресторані за допомогою блокчейн-гаманця. Тепер одержувач знає адресу Аліси та може аналізувати всю минулу та майбутню діяльність за цією адресою. Так само Аліса тепер знає адресу гаманця ресторану та може використовувати цю інформацію, щоб отримати адреси гаманця інших гостей або переглянути дохід ресторану. Або третя сторона (наприклад, соціальні мережі), яка знає адресу ресторану та гаманця Аліси, може легко визначити фактичну адресу проживання Аліси та вивчити її минулі та майбутні операції.
**Поширення протоколів, що покращують конфіденційність, має вирішити вищевказані проблеми. Це дозволяє користувачам вносити кошти в протокол, використовуючи одну адресу, і знімати кошти з протоколу пізніше, використовуючи іншу адресу. Усі депозити та зняття коштів все ще видно в блокчейні, але відповідність між конкретними переказами та переказами більше не є публічною. **
Одним із найвідоміших протоколів для підвищення конфіденційності є Tornado Cash. Він успішно вирішує вищезазначені проблеми, дозволяючи користувачам зберегти певну конфіденційність. Однак, крім законних користувачів, які намагаються захистити свої дані, Tornado Cash також використовують різні зловмисники. Дані про депозит показують, що хакерська група переказувала кошти через цей протокол. Є докази того, що цей протокол для підвищення конфіденційності також використовується північнокорейськими хакерськими групами, що в кінцевому підсумку призвело до того, що адреси смарт-контрактів протоколу потрапили до списку спеціально визначених громадян і заблокованих осіб, який веде Управління з контролю за іноземними активами США (OFAC). (часто називають списком SDN) ).
**Основною проблемою Tornado Cash є стирання межі між законними та злочинними користувачами. **Таким чином, Tornado Cash надає функцію відповідності, яка дозволяє користувачам створювати підтвердження того, з якого депозиту надійшло дане зняття. Незважаючи на те, що цей механізм дозволяє людям доводити свою невинуватість, це відбувається за рахунок необхідності довіряти централізованому посереднику та створення інформаційної асиметрії. Зрештою, механізм майже не використовувався користувачами.
У цьому документі обговорюється розширення цього підходу, який дозволяє користувачам публічно засвідчувати інформацію про те, з яких депозитів могли походити їх зняття, не втрачаючи конфіденційності. **Пули конфіденційності пропонують загальну концепцію: Дозволити підтвердження членства («Я підтверджую, що мої зняття було здійснено з одного з цих депозитів») або докази виключення («Я підтверджую, що мої зняття коштів не походили з жодного з цих депозитів») ) . **У цій статті обговорюється ця пропозиція та пояснюється, як її можна використовувати для досягнення балансу між чесними та нечесними користувачами.
Зауважте, що пули конфіденційності надають додаткові параметри, розширюючи набір дій користувача. Вони все одно можуть надати більш детальну сертифікацію конкретним контрагентам, якщо це необхідно. Проте в деяких випадках може бути достатньо підтвердження членства або виключення. Крім того, можливість публічного оприлюднення цих сертифікатів пропонує ряд переваг порівняно з двостороннім розкриттям інформації.
2. Технічна підготовка
У цьому розділі ми надаємо короткий технічний огляд і обговорюємо технічну конструкцію та загальні принципи протоколів, таких як пули конфіденційності.
1. Конфіденційність блокчейну до ZK-SNARK
Історично прихильники блокчейну стверджували, що хоча всі транзакції прозорі, блокчейни можуть зберігати конфіденційність, оскільки вони забезпечують анонімність.
З появою сучасних інструментів кластеризації та аналізу цей захист конфіденційності став недостатнім. Щоб покращити конфіденційність загальнодоступних блокчейнів, були представлені більш потужні технології, такі як Token Join і Monero. Однак ці технології все ще несуть ризик витоку даних. **
Потім з’явилися технології загального призначення з нульовим знанням, такі як Zcash і Tornado Cash, які можуть зробити набір анонімності кожної транзакції рівним усьому набору всіх попередніх транзакцій. Цю техніку часто називають ZK-SNARK.
2、 ZK-SNARK
ZK-SNARK — це техніка, яка дозволяє перевіряльнику доводити певне математичне твердження щодо загальнодоступних і приватних даних, задовольняючи при цьому дві ключові властивості: нульовий рівень знань і простоту. **
● З нульовим знанням: не розкриває жодної інформації про особисті дані, крім підтвердження того, що зазначені особисті дані відповідають заяві.
● Стислість: Докази короткі та їх можна швидко перевірити, навіть якщо підтверджені твердження вимагають трудомістких обчислень.
ZK-SNARK отримали широку увагу з боку блокчейн-спільноти через їх значення для масштабованості, наприклад ZK-rollups. Для програм конфіденційності простота не особливо важлива, але необхідне знання.
«Заявку» доказу ZK-SNARKs можна розглядати як тип програми під назвою «схема», яка обчислює результат функції f(x, w) із загальнодоступними та приватними вхідними даними, а потім доводить, що для даного загальнодоступний вхід x , існує приватний вхід w такий, що f(x, w) оцінюється як True.
3. Застосування ZK-SNARK в таких системах, як Zcash і Tornado Cash
Існують деякі незначні відмінності між різними версіями Zcash і системами, натхненними нею (наприклад, Tornado Cash). Однак основна логіка, на яку вони спираються, дуже схожа. У цьому розділі описано просту версію, яка приблизно відповідає тому, як працюють ці протоколи.
Токени складаються з секретів, які зберігаються їх власниками. З s можна отримати два значення:
● Public Token ID L = хеш (s + 1)
● НуліфікаторU = хеш (s + 2)
Серед них хеш відноситься до хеш-функції пароля, наприклад SHA 256. Якщо задано s, можна обчислити ідентифікатор маркера та обнулювач. Однак, враховуючи набір обнулювачів і загальнодоступний ідентифікатор маркера, псевдовипадкова поведінка хеш-функції гарантує, що ви не зможете визначити, який зероайзер пов’язаний з яким ідентифікатором маркера, якщо не знаєте секрети, які згенерували обидва.
Блокчейн відстежує всі ідентифікатори токенів, які були «створені», і всі нуліфікатори, які були «витрачені». Обидва набори постійно зростають (якщо протокол не хоче примусово витрачати токени).
Колекція ідентифікаторів токенів зберігається в структурі даних, яка називається деревом Merkle: якщо дерево містить N елементів, кожен суміжний елемент хешується (результатом є ⌈ N/2 ⌉ хешів), кожен сусідній хеш знову хешується (результатом є ⌈ N/4 ⌉ хешів) і так далі, доки всі дані не будуть зафіксовані в одному «кореневому хеші».
Враховуючи конкретне значення в дереві та кореневий хеш, можна надати гілку Merkle: «сестринське значення», яке хешує разом на кожному кроці шляху від цього значення до кореня. Ця гілка Merkle є корисною, оскільки це невеликий (log 2(N) хешів) фрагмент даних, який можна використовувати для підтвердження того, що будь-яке конкретне значення насправді є в дереві. На малюнку нижче показано приклад дерева Merkle висотою 4.
Коли користувачі надсилають монети іншим, вони надають наступне:
● Zerizer U, який ви хочете витратити
● Ідентифікатор маркера L' нового маркера, який потрібно створити (одержувача просять надати це)
● ЗК-СНАРК.
ZK-SNARK містить такі приватні входи:
● секрети користувача
● Гілка Merkle у дереві ідентифікаторів маркерів, яка доводить, що маркер з ідентифікатором маркера L = hash(s + 1) дійсно був створений у певний момент у минулому
Він також містить такі загальнодоступні дані:
● U, обнулювач витрачених жетонів
● R, кореневий хеш, проти якого спрямовані докази Меркла
ZK-SNARK підтверджує дві властивості:
● U = хеш (s + 2)
● Відділення Merkle дійсні
Окрім ZK-SNARK, протокол перевіряє наступне:
● R — поточний або історичний кореневий хеш дерева ідентифікаторів маркерів
● U немає в наборі витрачених нуліфікаторів
Якщо транзакція дійсна, вона додає U до набору використаних обнулювачів і L' до списку ідентифікаторів токенів. Показ U запобігає подвійній витраті одного жетона. Однак іншу інформацію розголошувати не будуть. **Зовнішній світ може лише бачити, коли транзакції були надіслані; у них немає способу отримати шаблон того, хто відправив або отримав ці транзакції, і немає способу розрізнити уніфіковане джерело токенів. **
З наведеної вище моделі є два винятки: депозити та зняття коштів. У депозитах ідентифікатори токенів можна створювати без анулювання певного попереднього токена. Депозити не є анонімними з точки зору конфіденційності, оскільки зв’язок між заданим L і зовнішньою подією, яка дозволяє додавати L (у Tornado Cash, внесення ETH у систему; у Zcash, новий майнінг ZEC), є відкритим.
Іншими словами, **депозити прив’язані до минулої історії транзакцій. **Під час зняття коштів зеройзер використовуватиметься без додавання нового ідентифікатора токена. Це може відключити зняття з відповідних депозитів і опосередковано з минулою історією транзакцій. Однак зняття коштів можна пов’язати з будь-якими майбутніми транзакціями, які відбудуться після події зняття.
У першій версії Tornado Cash немає концепції внутрішніх переказів, вона дозволяє лише депозити та зняття коштів. Пізніші версії, все ще експериментальні, також дозволяли внутрішні перекази та монети різного номіналу, включаючи підтримку операцій «розділення» та «злиття». У наступних розділах ми обговоримо, як розширити базову систему переказу монет із збереженням конфіденційності та пули конфіденційності до довільних номіналів.
4. ZK-SNARK у пулі конфіденційності
**Основна ідея пулу конфіденційності полягає в тому, що користувач не тільки доводить, що зняття пов’язано з попереднім депозитом за допомогою підтвердження з нульовим знанням, але також доводить, що він належить до більш жорсткого набору асоціацій. **Пов’язана колекція може бути підмножиною всіх депозитів, зроблених раніше, або колекцією, що містить лише власні депозити користувача, або чимось середнім. Користувачі вказують набір, надаючи корінь Merkle пов’язаного набору як загальнодоступний вхід.
Як показано на малюнку нижче, для простоти ми безпосередньо не доводимо, що пов’язаний набір справді є підмножиною депозитів, зроблених раніше; замість цього ми лише вимагаємо, щоб користувач використовував той самий ідентифікатор монети, що й кінцевий вузол, щоб доведіть дві гілки Меркла через нульове знання:
● Введіть гілку Merkle кореня R загального набору ідентифікаторів монет
● Введіть гілку Merkle наданого кореневого RA набору асоціацій
Намір цього полягає в тому, щоб десь розмістити повний набір асоціацій (може бути в ланцюжку). Основна концепція така: замість того, щоб вимагати від користувачів точно вказувати, з якого саме депозиту вони зняли кошти, або, навпаки, не надавати жодної інформації, окрім підтвердження відсутності подвійних витрат, ми дозволяємо користувачам надавати набір варіантів, які можуть бути джерелом коштів, і ця колекція може бути такою широкою чи вузькою, як вони хочуть.
Ми підтримуємо екосистему, яка полегшує користувачам визначення набору асоціацій відповідно до їхніх уподобань. Далі в цій статті буде описано лише інфраструктуру, засновану на цьому простому базовому механізмі, і його наслідки.
3. Практичні міркування та випадки використання
Проаналізуйте, як протоколи підвищення конфіденційності використовуються на практиці з точки зору програми.
1. Варіанти використання асоціативних колекцій
Щоб проілюструвати цінність цієї програми в середовищі правоохоронних органів, ось приклад:
Припустимо, у нас є п'ять користувачів: Аліса, Боб, Карл, Девід, Єва. Перші чотири користувачі є чесними, законослухняними, але усвідомлюють конфіденційність, а Єва — злодійка. Оскільки громадськість знає, що Єва є злодієм через інформацію про те, що монети за адресою, позначеною «Єва», викрадені. На практиці це трапляється досить часто: у загальнодоступних блокчейнах кошти, згенеровані використанням уразливостей у протоколах DeFi, відстежуються для виявлення незаконних коштів, що надходять у Tornado Cash.
Коли кожен із п’яти користувачів робить виведення, вони можуть вибрати, який пов’язаний набір вказати. Їхній набір зв’язків має включати їхні власні депозити, але вони вільні вибирати, яку з інших адрес включити. Перші чотири користувачі були мотивовані, з одного боку, бажанням максимально захистити свою конфіденційність. Це спонукає їх прагнути розширити коло своїх асоціацій. З іншого боку, вони хочуть зменшити ймовірність того, що торговці чи біржі вважатимуть їхні монети підозрілими. Є простий спосіб зробити це: вони не включають Єву у свою пов’язану колекцію. Тому для чотирьох з них вибір очевидний: нехай їхній набір асоціацій буде {Аліса, Боб, Карл, Девід}.
Звичайно, Єва також хоче максимізувати свій набір асоціацій. Але вона не може виключити свої власні депозити, тому вона змушена мати пов’язаний набір, що дорівнює набору всіх п’яти депозитів. Відповідний вибір учасників показано на малюнку нижче.
Хоча сама Єва не надала жодної інформації, завдяки простому процесу виключення ми можемо зробити чіткий висновок: п’ятий крок відступу може вийти лише від Єви.
2. Побудова асоційованих колекцій
У попередньому розділі показано один із можливих способів використання пов’язаних колекцій у протоколі, подібному до пулу конфіденційності, і те, як чесних учасників можна відокремити від поганих. Зауважте, що система не залежить від альтруїзму Аліси, Боба, Карла та Девіда; вони мають чіткі стимули, щоб виправдати своє розлучення. Розглянемо тепер більш детально побудову асоціативної колекції. Загалом існує дві основні стратегії створення асоціативних колекцій. Вони описані нижче та візуалізовані на малюнку нижче.
● **Включення (або членство): **Визначає певний набір депозитів, які ми маємо переконливі докази, щоб вважати їх низькими ризиками, і створює пов’язаний набір, який включає лише ці депозити.
● Виключити: Визначте певний набір депозитів, які ми маємо переконливі докази, щоб вважати їх високим ризиком, і створіть набір асоціацій, який включає всі депозити, окрім цих депозитів.
На практиці користувачі не вибирають депозити вручну для включення їх до пов’язаної колекції. Замість цього користувачі підписатимуться на посередників, яких ми називаємо Постачальники колекцій асоціацій (ASP), які створюють колекції асоціацій із певними властивостями. **У деяких випадках ASP можна створювати повністю в ланцюжку, не потребуючи втручання людини (або ШІ). В інших випадках ASP генеруватимуть пов’язану колекцію незалежно та публікуватимуть пов’язану колекцію в ланцюжку або деінде.
Ми наполегливо рекомендуємо публікувати принаймні корінь Merkle набору асоціацій у ланцюжку; це позбавляє зловмисних ASP можливості виконувати певні типи атак на користувачів (наприклад, надаючи різним користувачам різні набори асоціацій у спробі деанонімізувати їх). Уся колекція має бути доступною через API або в ідеалі через недорогу децентралізовану систему зберігання, таку як IPFS.
Можливість завантажувати весь пов’язаний набір є важливою, оскільки вона дозволяє користувачам генерувати докази членства локально, не розкриваючи жодної додаткової інформації для ASP, навіть не про депозити, що відповідають їхнім зняттям.
Ось як ASP можуть бути структуровані на практиці:
● **Відкладене додавання для виключення зловмисників: **Будь-який депозит автоматично додається до пов’язаної колекції через фіксований проміжок часу (наприклад, 7 днів), але якщо система виявляє, що депозит пов’язаний із відомою поганою поведінкою (наприклад, великий -масштабна крадіжка або адреса в опублікованому урядом списку санкцій), депозит ніколи не буде додано. На практиці цього можна досягти за допомогою колекцій, які курує спільнота, або існуючих постачальників послуг скринінгу транзакцій, які вже виконали роботу з ідентифікації та відстеження депозитів, пов’язаних із поганою поведінкою.
● Щомісячна плата за одну особу: для того, щоб приєднатися до пов’язаного збору, вартість депозиту має бути нижчою за певний фіксований максимум, і вкладник повинен без жодних відомостей довести, що він володіє певним маркером ідентифікації (наприклад, за підтримки уряду національні ідентифікаційні системи або легкі механізми, такі як перевірка облікового запису в соціальних мережах). Змішано з додатковим параметром, який представляє механізм скасування поточного місяця, щоб гарантувати, що кожна особа може надсилати депозити до пов’язаної колекції лише раз на місяць. Розробка намагається реалізувати дух багатьох загальних правил боротьби з відмиванням грошей, згідно з якими невеликі платежі нижче певного порогу забезпечують вищий рівень конфіденційності. Зауважте, що це можна реалізувати повністю як смарт-контракт, який не вимагає ручного контролю для підтримки поточної роботи.
● Щомісячна плата для довіреного члена спільноти: Подібна до місячної плати для однієї особи, але більш обмежена: користувачі повинні довести, що вони є членами спільноти, якій дуже довіряють. Довірливі учасники спільноти погоджуються надавати конфіденційність один одному.
● **Оцінка в режимі реального часу на основі штучного інтелекту: **Система AI ASP може надати оцінку ризику для кожного депозиту в режимі реального часу, і система виведе відповідний набір, що містить депозити з оцінкою ризику нижче певного порогу. Потенційно ASP може виводити кілька наборів, що відповідають численним пороговим значенням оцінки ризику.
4. Подальший технічний опис
У цьому розділі ми аналізуємо, як пропозиція підтримує довільні найменування, і обговорюємо спеціальні випадки, такі як повторна сертифікація, двосторонні прямі докази та послідовні докази.
1. Підтримуйте будь-яку конфесію
Наведена вище спрощена система захисту конфіденційності монет підтримує лише перекази монет того самого номіналу. Zcash підтримує довільні номінали за допомогою моделі UTXO. Кожна транзакція може мати кілька входів (потрібно опублікувати обнулювач кожного входу) і кілька виходів (потрібно опублікувати ідентифікатор маркера кожного виходу). Кожен створений ідентифікатор токена має супроводжуватися криптографічним номіналом. На додаток до підтвердження дійсності зеройзера, кожна транзакція повинна супроводжуватися додатковим доказом того, що сума номіналів створених монет не перевищує суму номіналів витрачених монет. Малюнок нижче ілюструє цей додатковий доказ.
Цю конструкцію можна розширити для підтримки депозитів і зняття, розглядаючи депозити як (незашифровані) входи, а зняття як (незашифровані) виходи. Крім того, дизайн можна обмежити для спрощення аналізу. Наприклад, можна дозволити лише часткове зняття, дозволяючи транзакції мати один зашифрований вхід і два виходи: незашифрований вихід, що представляє зняття, і зашифрований вихід «зміна», що представляє залишкові кошти, які можна використовувати для майбутніх зняття.
Природне запитання полягає в тому, як розширити цей дизайн для підтримки пулів конфіденційності. Вставити його без змін у пул конфіденційності не є ідеальним, оскільки графік транзакцій не узгоджується з тим, що ми інтуїтивно очікуємо: якщо користувач вносить 10 токенів, а потім витрачає 1 + 2 + 3 + 4 у чотирьох послідовних жетонах зняття, ми хочемо розглядати всі чотири зняття як джерело початкового депозиту в 10 токенів. Але фактичний результат такий, як показано нижче: джерелом першого зняття є депозит 10 токенів, а потім джерелом другого зняття є результат зміни 9 токенів, створений першим зняттям, і так далі за аналогією. На практиці це створює проблеми, оскільки ASP вимагає перевірити проміжний депозит і додати його до пов’язаної колекції.
Для того, щоб усі чотири зняття коштів у цьому прикладі мали початковий депозит у 10 монет як джерело, нам потрібно вирішити дві проблеми:
● Переконайтеся, що кожне часткове зняття не пов’язане публічно з іншими зняттями
● Дозвольте кожному частковому зняттю включати депозит як член пов’язаної колекції
Якщо ми підтримуємо лише часткове зняття коштів, а не більш складні транзакції MIMO, і гарантуємо, що кожне зняття має певний відповідний «початковий депозит», існує кілька способів зробити це безпосередньо. Природним і масштабованим підходом є поширення обіцянки певної інформації через транзакції. Наприклад, ми могли б вимагати, щоб транзакції містили хеш зобов’язання (coinID+hash®) з додаванням деякого випадкового значення r, щоб забезпечити засліплення, і вимагали, щоб ZK-SNARK доводили, що зобов’язання в транзакції є таким самим, як і її батьківська транзакція. Якщо материнська транзакція сама по собі є зняттям коштів, зобов’язання збігається з ідентифікатором монети початкового депозиту, а якщо материнська транзакція є депозитом, зобов’язання збігається з ідентифікатором монети початкового депозиту. Таким чином, кожна транзакція в ланцюжку повинна містити зобов’язання щодо оригінального ідентифікатора депозитної монети та вимагати підтвердження того, що це значення є у пов’язаному наборі, наданому транзакцією.
Щоб покращити конфіденційність проти атак агрегації балансу, ми також можемо підтримувати злиття монет. Наприклад, якщо у мене залишилося кілька монет, я можу об’єднати їх із своїм наступним депозитом. Щоб врахувати це, ми можемо вимагати, щоб транзакції прив’язувалися до набору ідентифікаторів монет, а також вимагали, щоб транзакції з кількома вхідними даними прив’язувались до об’єднання їхніх батьківських транзакцій. Відкликання міститиме доказ того, що всі закріплені ідентифікатори монет є у пов’язаному наборі.
2. Особливі обставини
● Повторна сертифікація: користувачам потрібна інформація про секретний депозит, щоб зняти депозити, подібно до протоколів пулу конфіденційності. Та сама секретна інформація також використовується для створення доказів приналежності до набору асоціацій. Збереження секретної інформації дозволяє користувачам створювати нові докази для різних наборів або оновлювати пов’язані набори. Це дає користувачам більшу гнучкість, але також може створювати додаткові ризики.
● Пряма двостороння сертифікація: У деяких випадках користувачам може знадобитися розкрити іншій стороні точне джерело зняття коштів. Користувачі можуть створити пов’язану колекцію, що містить лише їхні депозити, і створити докази проти цієї колекції. Ці докази зазвичай є винятками та сприяють лише частковій конфіденційності, коли вони надаються двом сторонам. Однак обмін доказами вимагає встановлення сильних припущень довіри.
● Доказ послідовності: У економіці швидких транзакцій із використанням системи, як-от пул конфіденційності, протокол потрібно змінити, щоб адаптуватися до цього середовища. Окрім типів транзакцій депозиту та зняття коштів, протокол також має підтримувати внутрішні операції надсилання для підвищення ефективності. Крім того, передаючи філії та ключі Merkle, користувачі можуть поширювати інформацію, пов’язану з історією транзакцій, щоб одержувачі могли перевірити походження коштів. Це гарантує, що кожен користувач має мінімум інформації, необхідної для впевненості в отриманих коштах.
На практиці токен може мати кілька «походжень». Наприклад, Боб є власником кав’ярні, і він отримує 5 жетонів від Аліси, 4 жетони від Ешлі, 7 жетонів від Енн, і в кінці дня йому потрібно заплатити Карлу 15 жетонів, щоб заплатити за обід. Натомість Девід, можливо, отримав 15 жетонів від Карла, 25 жетонів від Кріса, і хоче внести 30 жетонів Еммі (обмін). У цих більш складних випадках ми дотримуємося того самого принципу: історію, яка була додана до пов’язаної колекції досить давно, можна ігнорувати, тоді як нову історію потрібно передавати.
П'ять, детальніше
Система, подібна до пулу конфіденційності, може дозволити користувачам отримати більший захист конфіденційності своїх даних про фінансові операції, зберігаючи при цьому можливість довести відокремленість від відомої незаконної діяльності. Ми очікуємо, що чесні користувачі будуть заохочені брати участь у таких схемах завдяки поєднанню двох факторів:
● Бажання приватності
● Бажання не викликати підозри
1. Соціальний консенсус і набори асоціацій
Якщо існує повний консенсус щодо того, хороші чи погані кошти, система вироблятиме просту розділову рівновагу. Усі користувачі, які володіють «хорошими» активами, мають сильний стимул і здатність довести, що вони належать до «тільки хорошого» пов’язаного набору. З іншого боку, погані актори не зможуть надати таких доказів. Вони все ще можуть вносити «погані» кошти в пул, але це їм не на користь. Кожен може легко визначити, що кошти були зняті з протоколу з підвищеною конфіденційністю, і побачити, що зняття посилається на пов’язану колекцію, яка містить депозити із сумнівних джерел. Більше того, «погані» гроші не псують «хороші». При знятті коштів із законних депозитів їх власники можуть просто виключити всі відомі «погані» депозити зі своєї пов’язаної колекції.
Там, де існує глобальний консенсус і де висновки про те, чи вважається фінансування «хорошим» чи «поганим», залежать від соціальної точки зору чи юрисдикції, набір асоціацій може значно відрізнятися. Припустімо, що існують дві юрисдикції з різними наборами правил. Організації в юрисдикціях A і B можуть використовувати ту саму угоду про покращення конфіденційності та видавати сертифікати, які відповідають вимогам їхніх відповідних юрисдикцій. Обидва можуть легко запровадити конфіденційність у своїх власних пов’язаних колекціях і виключити вилучення коштів, які не відповідають вимогам відповідних юрисдикцій. Якщо потрібно, підтвердження членства може бути видано для перетину двох пов’язаних наборів, тим самим достовірно доводячи, що депозити, які відповідають їх зняттю, відповідають вимогам обох юрисдикцій.
Тому пропозиція є дуже гнучкою, і її слід розглядати як нейтральну інфраструктуру. З одного боку, це бореться з цензурою. Це дозволяє будь-кому приєднатися до пов’язаної колекції за власним вибором і зберегти конфіденційність у власній спільноті. З іншого боку, сторонні особи можуть вимагати докази проти певного набору асоціацій, які відповідають їхнім нормативним вимогам. Таким чином, навіть якщо існує спільнота зловмисників у протоколі, що підвищує конфіденційність, вони не зможуть приховати підозріле походження депозитів, доки інформація точно відображається в побудові пов’язаного набору.
2. Властивості асоційованих колекцій
Щоб функціонувати, асоціативні колекції повинні мати певні властивості. Збір має бути точним, щоб користувачі могли бути впевненими, що вони безпечно використовують свої вилучені кошти. Крім того, властивості кожного набору повинні бути стабільними, тобто менш імовірно змінюватися з часом. Це зменшує потребу у повторній перевірці зняття з нових колекцій. Нарешті, щоб досягти суттєвого захисту конфіденційності, набір асоціацій має бути достатньо великим і містити різні типи депозитів. Однак ці властивості суперечать одна одній. Загалом, великі та різноманітні колекції можуть мати кращі властивості конфіденційності, але можуть бути менш точними та стабільними, тоді як менші колекції легше підтримувати, але вони забезпечують меншу конфіденційність.
3. Практичні міркування та змагання
Регульовані організації, які приймають криптоактиви, повинні переконатися, що закони та правила, яким вони підпадають, дозволяють приймати такі кошти. Сьогодні багато з цих організацій покладаються на так звані інструменти скринінгу транзакцій: програмне забезпечення або служби, які аналізують блокчейн, щоб виявити потенційно підозрілу активність, посилання на нелегітимні адреси або інші невідповідні транзакції. Інструменти перевірки часто виражають ризик, пов’язаний з кожною угодою, через оцінку ризику. Цей рейтинг базується на призначенні переказних коштів та історії їх транзакцій. Протоколи, що покращують конфіденційність, можуть створювати проблеми в цьому відношенні. Вони усувають видимий зв’язок між депозитами та зняттям. Таким чином, за наявності протоколів, що підвищують конфіденційність, оцінка ризику повинна брати до уваги атестацію та призначати оцінку на основі набору асоціацій.
Інструменти та послуги для перевірки транзакцій в основному надають професійні компанії, які мають досвід аналізу блокчейну та суміжних юридичних галузей. В ідеалі ці фірми (і будь-хто інший) мали б доступ до всіх сертифікатів членства та відповідних пов’язаних колекцій, щоб надавати точні показники ризику для всіх транзакцій. Тому ми рекомендуємо зберігати всі докази в блокчейні або інших загальнодоступних сховищах доказів. Єдиним винятком є докази членства розміром один, надані певному контрагенту. Зі зрозумілих причин ці докази не повинні бути загальнодоступними.
Зберігання доказів безпосередньо в ланцюжку додає додаткових транзакційних витрат, але зменшує зусилля з координації, робить конкуренцію більш справедливою та пом’якшує квазімонопольні ризики, які можуть створювати постачальники інструментів перевірки через знання непублічних доказів.
Загальні параметри конфіденційного пулу дуже гнучкі. Створюючи певну колекцію асоціацій, протокол можна адаптувати до різних випадків використання. Ось два приклади цих спеціальних колекцій асоціацій:
● **Альянси комерційних банків можуть створити пов’язану колекцію, що містить лише депозити їхніх клієнтів. **Це гарантує, що підтвердження будь-якого зняття коштів, створених для колекції, пройшло процедури «Знай свого клієнта» (KYC) і протидії відмиванню грошей (AML) в одному з банків-учасників, але не розкриває, яке зняття коштів належить якому клієнту.
● **У випадках, коли від фінансових посередників вимагається чітко задокументувати джерело коштів, вони можуть вимагати від користувачів надати доказ проти пов’язаного набору, який містить лише депозити користувачів. **Після цього підтвердження буде обміняно на двосторонній основі з посередником, що дозволить їм відстежувати кошти так, ніби користувач ніколи не використовував пул конфіденційності. Хоча це вимагає від користувачів довіри посереднику в тому, що він не розкриє докази, в ідеалі це дає змогу користувачам дотримуватися правил без необхідності розголошувати інформацію громадськості.
4. Вибір дизайну та альтернативи
Дуже гнучке налаштування на основі зборів асоціацій, перевірки zk і добровільного розкриття інформації. Хоча це корисно для забезпечення того, що пропозиція може бути адаптована до різних юрисдикцій, слід проявляти велику обережність щодо вибору конкретного дизайну. Зокрема, є два потенційні коригування, проти яких ми виступаємо. Ми вважаємо, що вони мають проблеми з вимогами довіри та можуть створити квазімонополістичні ринкові структури. Нижче ми коротко описуємо та обговорюємо ці альтернативи:
● Централізований доступ: Правоохоронні органи, постачальники оцінки крипторизику або подібні суб’єкти можуть отримати доступ до перегляду зв’язків між транзакціями користувачів, зберігаючи конфіденційність від інших.
● **Білий список для всієї системи: **Системи конфіденційності можуть накладати обмеження на типи користувачів, які можуть вносити монети в їхні пули, вимагаючи від них надати додаткові докази або вимагаючи, щоб депозити очікували певний період часу, протягом якого централізована оцінка ризиків система може відхиляти депозити.
Ці два методи подібні тим, що вони надають привілеї певним об’єктам. Це породжує складні питання управління: хто має доступ до цієї інформації? Хто має повноваження керувати дозволами? Приватна компанія не здається гарним варіантом, оскільки будь-які привілеї, швидше за все, створять олігополістичну структуру ринку, де кілька компаній матимуть доступ до даних, які надаватимуть ці послуги, тоді як інші не зможуть конкурувати.
Подібним чином існує багато питань управління та політичних питань, з якими потрібно зіткнутися при наданні повноважень державним установам, особливо в міжнародному середовищі. Навіть якщо інституція на 100% заслуговує на довіру, не зловживає своєю владою для реалізації політичних завдань і не залежить від інших суб’єктів, які могли б змусити її зловживати своєю владою, така ситуація є симптомом стану спокою. Організації, члени, країни та політичні структури всередині організацій змінюються з часом. Може існувати зовнішній тиск, і існування цих привілеїв може створити додаткові стимули для порушення та отримання впливу на системи управління організації.
Крім того, атаки всередині або за межами організації або помилки від імені централізованої організації можуть мати далекосяжні наслідки. Ми вважаємо, що слід запобігати створенню таких централізованих точок відмови.
Зважаючи на це, ми розуміємо, що різні розміри транзакцій і обставини можуть вимагати різних комбінацій сертифікацій. Наприклад, для великих транзакцій багато користувачів можуть надати основні докази виключення в мережі та надати своїм контрагентам більш детальну інформацію про джерело коштів.
5. Напрямок поглиблених досліджень
Хоча це дослідження містить огляд того, як протоколи підвищення конфіденційності на основі zkSNARK можна використовувати в регульованих умовах, є кілька аспектів, які заслуговують на подальше вивчення.
По-перше, потрібно усвідомити, що конфіденційність, отримана за допомогою цих протоколів, залежить від багатьох факторів. Зловмисники можуть пов’язати зняття з конкретними депозитами на основі недостатньо великого набору зв’язків, поганого вибору кореня та помилки користувача.
Крім того, вибір, зроблений іншими користувачами, може негативно вплинути на вашу конфіденційність. У крайніх випадках усі інші учасники пулу опублікували б підтвердження членства в розмірі один, виявляючи прямий зв’язок між їхніми депозитами та зняттям коштів. Очевидно, це неявно виявило б зв’язок між єдиними транзакціями депозиту та зняття коштів. У більш тонкому прикладі обмеження з різних доказів членства можуть бути використані для отримання інформації та потенційного співвіднесення депозитів і зняття з високою ймовірністю. Після поєднання цієї підтвердженої інформації з метаданими транзакцій конфіденційність протоколу може бути скомпрометована.
Нарешті, зловмисний ASP може скомпілювати запропонований набір асоціацій таким чином, щоб він міг максимізувати вилучення інформації або підвищити сприйняту анонімність шляхом додавання депозитів, де відомі відповідні зняття. Усі ці питання вимагають подальших досліджень для оцінки наданих властивостей конфіденційності. Подібним чином було б цікаво продовжити дослідження властивостей розділення рівноваг, моделюючи, як хороші та погані гравці поводяться за певних припущень і як публічне доказування першого впливає на конфіденційність другого.
Юридичні експерти можуть додатково дослідити конкретні вимоги щодо розкриття інформації. Схема, запропонована в цій статті, є гнучкою, а висновки юридичних експертів можуть допомогти адаптувати угоду та екосистему, побудовану навколо неї, щоб забезпечити відповідність у різних правових юрисдикціях.
6. Висновок
У багатьох випадках конфіденційність і відповідність вважаються такими, що суперечать одне одному. Ця стаття припускає, що це не обов’язково так, якщо протоколи підвищення конфіденційності дозволяють користувачам доводити певні атрибути джерела їхніх коштів. Наприклад, припустімо, що користувачі можуть довести, що їхні кошти не пов’язані з депозитами відомого незаконного походження, або що кошти є частиною певної колекції депозитів, не розкриваючи жодної додаткової інформації.
Така установка може створити роздільну рівновагу, в якій чесні користувачі сильно стимулюються доводити, що вони належать до деякого сумісного набору асоціацій, і зберігати конфіденційність у цьому наборі. Натомість для нечесних користувачів вони не можуть надати таких доказів. Це дозволяє чесним користувачам відмежуватися від депозитів третіх сторін, з якими вони не погоджуються, або заборонити їм використовувати свої кошти в сумісному середовищі. Ми вважаємо, що пропозиція є дуже гнучкою та може бути скоригована відповідно до потенційних різноманітних нормативних вимог.
Цей документ слід розглядати як внесок у потенційне майбутнє співіснування фінансової конфіденційності та регулювання. Ми хочемо сприяти обговоренню та спрямовувати розмову в більш позитивне, конструктивне русло. Щоб розширити та змінити цю пропозицію, знадобиться співпраця між фахівцями-практиками, науковцями з різних дисциплін, політиками та регуляторами; кінцевою метою є створення інфраструктури для підвищення конфіденційності, яку можна використовувати в регульованому середовищі.