Використання технології zk-SNARKs для захисту конфіденційності в системах цифрової ідентичності стало звичайною практикою. Різноманітні проекти цифрової ідентичності на основі zk-SNARKs розробляють зручні для користувача програмні пакети, які дозволяють користувачам доводити наявність дійсної ідентичності без розкриття деталей ідентифікації. Кількість користувачів World ID, які проходять верифікацію за допомогою біометричних технологій і забезпечують конфіденційність за допомогою zk-SNARKs, нещодавно перевищила 10 мільйонів. Деякі урядові проекти цифрової ідентичності також почали використовувати технологію zk-SNARKs.
На перший погляд, широке впровадження цифрової ідентичності на основі zk-SNARKs здається великою перемогою в прискоренні децентралізованої концепції (d/acc). Це дозволяє захистити наші соціальні медіа, системи голосування та різноманітні інтернет-сервіси від атак відьом і маніпуляцій роботів, не жертвуючи приватністю. Але чи дійсно все так просто? Чи існують ризики для ідентифікації на основі zk-SNARKs? У цій статті буде викладено наступні думки:
zk-SNARKs упаковка вирішила багато важливих проблем.
Ідентифікація, упакована в zk-SNARKs, все ще несе ризики. Ці ризики головним чином виникають через жорстке дотримання властивості "одна особа - одна ідентичність".
Використання лише "доказу багатства" для захисту від атак "відьом" у більшості випадків недостатньо, нам потрібне якесь рішення "подібного до ідентифікації".
Ідеальний стан - це отримання N ідентифікацій з вартістю N².
Багатогранна ідентифікація є найреалістичнішим рішенням. Багатогранна ідентифікація може бути явною (, як-от ідентифікація на основі соціальних графів ), а також може бути прихованою (, де існує кілька типів zk-SNARKs ).
Як працює ідентифікація, упакована в zk-SNARKs?
Уявіть, що ви отримали World ID, скануючи райдужну оболонку ока, або зчитуючи паспорт за допомогою NFC на телефоні, отримавши ідентифікацію на основі zk-SNARKs. У вас на телефоні є секретне значення s. В глобальному реєстрі на блокчейні є публічний хеш-значення H(s). Під час входу в додаток ви генеруєте унікальний для цього додатку користувацький ID, тобто H(s, app_name), і перевіряєте за допомогою zk-SNARKs: цей ID походить з того ж секретного значення s, що й якесь публічне хеш-значення в реєстрі. Таким чином, кожне публічне хеш-значення може генерувати лише один ID для кожного додатку, але ніколи не розкриває, з яким публічним хеш-значенням пов'язаний конкретний ID для додатку.
Насправді, дизайн може бути дещо складнішим. У World ID спеціальний ID програми насправді є хеш-значенням ID програми та ID сеансу, тому різні операції в одному і тому ж застосунку також можуть бути взаємно відокремлені. Дизайн паспорта на основі zk-SNARKs також може бути побудований подібним чином.
zk-SNARKs самі по собі не можуть забезпечити анонімність
Припустимо, що платформа ідентифікації на основі zk-SNARKs працює повністю так, як очікується, строго відтворюючи всі наведені вище логіки, і навіть знайдена методика тривалого захисту конфіденційної інформації не технічних користувачів без залежності від централізованих установ. Але в той же час ми можемо зробити реалістичне припущення: програми не будуть активно співпрацювати з захистом конфіденційності, вони дотримуватимуться принципу "прагматизму", а обрані дизайн-рішення, хоч і під гаслом "максимізації зручності для користувачів", насправді, здається, завжди схиляються до власних політичних і комерційних інтересів.
У таких сценах додатки соціальних медіа не використовуватимуть складні рішення, такі як часта зміна сеансових ключів, а натомість призначать кожному користувачеві унікальний ідентифікатор програми, і оскільки система ідентифікації дотримується правила "одна людина - один ідентифікатор", користувач може мати лише один обліковий запис. У реальному світі реалізація анонімності зазвичай вимагає наявності кількох облікових записів: один для "звичайної ідентичності", інші - для різних анонімних ідентичностей. Тому в цій моделі анонімність, яку користувачі можуть насправді отримати, ймовірно, буде нижча за поточний рівень. Таким чином, навіть система "одна людина - один ідентифікатор", упакована за допомогою zk-SNARKs, може поступово привести нас до світу, де всі дії повинні бути пов'язані з єдиною публічною ідентичністю. У часи зростаючих ризиків позбавлення людей можливості захистити себе через анонімність може призвести до серйозних негативних наслідків.
zk-SNARKs самі по собі не можуть захистити вас від примусу
Навіть якщо ви не публікуєте своє секретне значення s, ніхто не може побачити публічні зв'язки між вашими рахунками, але що якщо хтось змусить вас розкрити їх? Уряд може змусити вас розкрити ваше секретне значення, щоб переглянути всю вашу діяльність. Це не порожні слова: деякі країни вже почали вимагати від заявників на візу розкрити свої облікові записи в соціальних мережах. Крім того, роботодавці також можуть легко зробити розкриття всієї публічної інформації умовою найму. Навіть окремі додатки на технічному рівні можуть вимагати від користувачів розкривати свою ідентифікацію в інших додатках, щоб дозволити реєстрацію.
Так само, у цих випадках цінність атрибутів zk-SNARKs зникає, але недоліки нового атрибута "одна людина - один обліковий запис" все ще залишаються.
Ми, можливо, можемо зменшити ризики примусу шляхом оптимізації дизайну: наприклад, використовуючи механізми багатосторонніх обчислень для генерації унікальних ID для кожного застосунку, що дозволяє користувачам і постачальникам послуг брати участь у цьому процесі. Таким чином, якщо в цьому процесі не бере участь оператор застосунку, користувач не зможе довести свій унікальний ID у цьому застосунку. Це ускладнить примус інших розкривати повну ідентичність, але не може повністю виключити цю можливість, і такі рішення мають інші недоліки, такі як вимога, щоб розробники застосунків були активними реальними суб'єктами, а не пасивними смарт-контрактами в ланцюгу.
zk-SNARKs самі по собі не можуть вирішити ризики, що не пов'язані з конфіденційністю
Усі форми ідентифікації мають крайні випадки:
На основі ідентифікації, що видається урядом, включаючи паспорти, не охоплює осіб без громадянства та не включає тих, хто ще не отримав такі документи.
З іншого боку, такі урядові системи ідентифікації надають унікальні привілеї власникам множинного громадянства.
Органи, що видають паспорти, можуть стати жертвами хакерських атак, а розвідувальні служби ворожих країн навіть можуть підробити велику кількість фальшивих ідентифікацій.
Для тих, чиї біометричні характеристики були пошкоджені через травми чи хвороби, біометрична ідентифікація буде повністю неефективною.
Біометрична ідентифікація, ймовірно, може бути обманута підробками. Якщо цінність біометричної ідентифікації стане надзвичайно високою, ми навіть можемо побачити, як хтось спеціально вирощує людські органи, лише для того, щоб "масово виробляти" такого роду ідентифікацію.
Ці крайні випадки є найбільшими загрозами для систем, які намагаються підтримувати властивість "одна особа - одна ідентичність", і вони не мають жодного зв'язку з конфіденційністю. Тому zk-SNARKs не можуть допомогти в цьому.
Підтримка "доказів багатства" для запобігання атакам від відьом не є достатнім рішенням, тому нам потрібна якась форма системи ідентифікації.
У чисто криптопанк-спільноті поширеною альтернативою є: повна залежність від "доказу багатства" для запобігання атак відьом, а не створення будь-якої форми системи ідентифікації. Дозволяючи кожному рахунку генерувати певні витрати, можна запобігти створенню великої кількості облікових записів. Така практика має свої приклади в Інтернеті, наприклад, деякі форуми вимагають від зареєстрованих користувачів сплачувати одноразовий внесок, і якщо обліковий запис буде заблоковано, ця плата не повертається.
Теоретично, навіть можна зробити так, щоб платежі мали умовний характер: під час реєстрації облікового запису вам потрібно лише заблокувати певну суму коштів, і лише у випадку, якщо обліковий запис буде заблоковано, ви втратите ці кошти. Теоретично, це може суттєво підвищити вартість атаки.
Цей підхід показує значні результати в багатьох сценаріях, але в деяких типах сценаріїв він абсолютно не працює. Я зосереджуся на двох типах сценаріїв, які поки що назвемо "сценаріями, подібними до загального базового доходу", і "сценаріями, подібними до управління".
Потреба в ідентифікації в сценах загального базового доходу
Термін "сцена універсального базового доходу" означає ситуацію, коли потрібно виплачувати певну кількість активів або послуг дуже широкій групі користувачів, не враховуючи їх платоспроможність. Деякі проекти систематично реалізують це: будь-яка особа з певною ідентифікацією може регулярно отримувати невелику кількість токенів. Багато аірдропів токенів також досягають подібної мети неформальними способами, намагаючись, щоб принаймні частина токенів потрапила до якомога більшої кількості користувачів.
Цей тип "малого загального базового доходу" може реально вирішити такі проблеми: дати людям достатню кількість криптовалюти для виконання деяких базових on-chain транзакцій та онлайн-покупок. Конкретно це може включати:
Отримати ENS ім'я
Опублікуйте хеш в мережі для ініціалізації певної zk-SNARKs ідентичності
Оплата комісій соціальних медіа платформ
Якщо криптовалюти будуть широко використовуватися в усьому світі, це питання більше не існуватиме. Але поки криптовалюти ще не стали поширеними, це може бути єдиним способом для людей отримати доступ до нефінансових застосувань на блокчейні та пов'язаних онлайн-товарів і послуг, інакше вони можуть повністю не мати доступу до цих ресурсів.
Крім того, є ще один спосіб досягти подібного ефекту, а саме "універсальні базові послуги": надання кожному, хто має ідентифікацію, можливості надсилати обмежену кількість безкоштовних транзакцій у певному додатку. Цей підхід може краще відповідати механізму стимулювання та мати вищу капітальну ефективність, оскільки кожен додаток, що отримує вигоду від такого впровадження, може робити це без необхідності оплати для не користувачів; однак це також супроводжується певними компромісами, оскільки універсальність зменшується. Але навіть так, тут все ще потрібне рішення для ідентифікації, щоб запобігти атакам системи спамом, а також уникнути виникнення ексклюзивності, яка походить від вимоги, щоб користувачі сплачували за певний спосіб оплати, і такі способи оплати можуть бути недоступні для всіх.
Остання важлива категорія, на яку варто звернути увагу, – це "гарантія базового забезпечення для всіх". Однією з функцій ідентифікації є надання об'єкта для притягнення до відповідальності, без необхідності, щоб користувачі заставляли кошти, що відповідають масштабам стимулів. Це також допомагає досягти мети: зменшити залежність від обсягу особистого капіталу при вході.
потреба в ідентифікації в сценаріях управління
Уявіть собі систему голосування: якщо ресурси користувача A в 10 разів більші, ніж у користувача B, тоді його право голосу також буде в 10 разів більшим, ніж у B. Але з економічної точки зору, кожна одиниця права голосу приносить A в 10 разів більше вигоди, ніж B. Отже, в цілому, вигода від голосування A для самого себе в 100 разів перевищує вигоду голосування B для себе. Саме тому ми помічаємо, що A витрачає набагато більше зусиль на участь у голосуванні, досліджуючи, як голосувати, щоб максимізувати свої цілі, і навіть може стратегічно маніпулювати алгоритмом. Це також є основною причиною, чому "великі китові" можуть мати надмірний вплив у механізмі голосування токенів.
Більш загальною та глибшою причиною є те, що система управління не повинна надавати однакову вагу "одна особа контролює 100 тисяч доларів" та "1000 осіб спільно володіють 100 тисячами доларів". Останнє представляє 1000 незалежних індивідів, тому воно міститиме більш різноманітну цінну інформацію, а не високу повторюваність незначної інформації. Сигнали від 1000 людей також часто є більш "помірними", оскільки думки різних індивідів часто взаємно компенсують одна одну.
Ця точка стосується як офіційних систем голосування, так і "неофіційних систем голосування", наприклад, можливості людей брати участь у культурній еволюції через публічні висловлювання.
Це свідчить про те, що системи управління не будуть насправді задоволені практикою "незалежно від джерела фінансування, однакові за обсягом кошти розглядаються однаково". Система насправді повинна розуміти внутрішній рівень координації цих фінансових ресурсів.
Потрібно звернути увагу, що якщо ви погоджуєтеся з моєю описовою рамкою вищезгаданих двох категорій сцен, то з технічної точки зору потреба в чітких правилах, таких як "одна людина - один голос", більше не існує.
Для застосування сценаріїв, подібних до універсального базового доходу, справжнім потрібним рішенням для ідентифікації є: перша ідентифікація безкоштовна, з обмеженням на кількість доступних ідентифікацій. Коли вартість отримання більшої кількості ідентифікацій стає настільки високою, що атакувати систему втрачає сенс, досягається ефект обмеження.
Для застосування в сценаріях управління основною вимогою є: можливість через певний непрямий показник визначити, чи є за цією ресурсною транзакцією єдиний контрольний суб'єкт, чи це певна "природна формація", що має нижчий рівень координації.
У цих двох сценаріях ідентифікація все ще є дуже корисною, але її слід дотримуватись "одна особа – одна ідентичність".
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
zk-SNARKs цфрова ідентичність таємниця проблеми та різноманітні рішення
zk-SNARKs цифрова ідентичність багатогранні дилеми
Використання технології zk-SNARKs для захисту конфіденційності в системах цифрової ідентичності стало звичайною практикою. Різноманітні проекти цифрової ідентичності на основі zk-SNARKs розробляють зручні для користувача програмні пакети, які дозволяють користувачам доводити наявність дійсної ідентичності без розкриття деталей ідентифікації. Кількість користувачів World ID, які проходять верифікацію за допомогою біометричних технологій і забезпечують конфіденційність за допомогою zk-SNARKs, нещодавно перевищила 10 мільйонів. Деякі урядові проекти цифрової ідентичності також почали використовувати технологію zk-SNARKs.
На перший погляд, широке впровадження цифрової ідентичності на основі zk-SNARKs здається великою перемогою в прискоренні децентралізованої концепції (d/acc). Це дозволяє захистити наші соціальні медіа, системи голосування та різноманітні інтернет-сервіси від атак відьом і маніпуляцій роботів, не жертвуючи приватністю. Але чи дійсно все так просто? Чи існують ризики для ідентифікації на основі zk-SNARKs? У цій статті буде викладено наступні думки:
Як працює ідентифікація, упакована в zk-SNARKs?
Уявіть, що ви отримали World ID, скануючи райдужну оболонку ока, або зчитуючи паспорт за допомогою NFC на телефоні, отримавши ідентифікацію на основі zk-SNARKs. У вас на телефоні є секретне значення s. В глобальному реєстрі на блокчейні є публічний хеш-значення H(s). Під час входу в додаток ви генеруєте унікальний для цього додатку користувацький ID, тобто H(s, app_name), і перевіряєте за допомогою zk-SNARKs: цей ID походить з того ж секретного значення s, що й якесь публічне хеш-значення в реєстрі. Таким чином, кожне публічне хеш-значення може генерувати лише один ID для кожного додатку, але ніколи не розкриває, з яким публічним хеш-значенням пов'язаний конкретний ID для додатку.
Насправді, дизайн може бути дещо складнішим. У World ID спеціальний ID програми насправді є хеш-значенням ID програми та ID сеансу, тому різні операції в одному і тому ж застосунку також можуть бути взаємно відокремлені. Дизайн паспорта на основі zk-SNARKs також може бути побудований подібним чином.
zk-SNARKs самі по собі не можуть забезпечити анонімність
Припустимо, що платформа ідентифікації на основі zk-SNARKs працює повністю так, як очікується, строго відтворюючи всі наведені вище логіки, і навіть знайдена методика тривалого захисту конфіденційної інформації не технічних користувачів без залежності від централізованих установ. Але в той же час ми можемо зробити реалістичне припущення: програми не будуть активно співпрацювати з захистом конфіденційності, вони дотримуватимуться принципу "прагматизму", а обрані дизайн-рішення, хоч і під гаслом "максимізації зручності для користувачів", насправді, здається, завжди схиляються до власних політичних і комерційних інтересів.
У таких сценах додатки соціальних медіа не використовуватимуть складні рішення, такі як часта зміна сеансових ключів, а натомість призначать кожному користувачеві унікальний ідентифікатор програми, і оскільки система ідентифікації дотримується правила "одна людина - один ідентифікатор", користувач може мати лише один обліковий запис. У реальному світі реалізація анонімності зазвичай вимагає наявності кількох облікових записів: один для "звичайної ідентичності", інші - для різних анонімних ідентичностей. Тому в цій моделі анонімність, яку користувачі можуть насправді отримати, ймовірно, буде нижча за поточний рівень. Таким чином, навіть система "одна людина - один ідентифікатор", упакована за допомогою zk-SNARKs, може поступово привести нас до світу, де всі дії повинні бути пов'язані з єдиною публічною ідентичністю. У часи зростаючих ризиків позбавлення людей можливості захистити себе через анонімність може призвести до серйозних негативних наслідків.
zk-SNARKs самі по собі не можуть захистити вас від примусу
Навіть якщо ви не публікуєте своє секретне значення s, ніхто не може побачити публічні зв'язки між вашими рахунками, але що якщо хтось змусить вас розкрити їх? Уряд може змусити вас розкрити ваше секретне значення, щоб переглянути всю вашу діяльність. Це не порожні слова: деякі країни вже почали вимагати від заявників на візу розкрити свої облікові записи в соціальних мережах. Крім того, роботодавці також можуть легко зробити розкриття всієї публічної інформації умовою найму. Навіть окремі додатки на технічному рівні можуть вимагати від користувачів розкривати свою ідентифікацію в інших додатках, щоб дозволити реєстрацію.
Так само, у цих випадках цінність атрибутів zk-SNARKs зникає, але недоліки нового атрибута "одна людина - один обліковий запис" все ще залишаються.
Ми, можливо, можемо зменшити ризики примусу шляхом оптимізації дизайну: наприклад, використовуючи механізми багатосторонніх обчислень для генерації унікальних ID для кожного застосунку, що дозволяє користувачам і постачальникам послуг брати участь у цьому процесі. Таким чином, якщо в цьому процесі не бере участь оператор застосунку, користувач не зможе довести свій унікальний ID у цьому застосунку. Це ускладнить примус інших розкривати повну ідентичність, але не може повністю виключити цю можливість, і такі рішення мають інші недоліки, такі як вимога, щоб розробники застосунків були активними реальними суб'єктами, а не пасивними смарт-контрактами в ланцюгу.
zk-SNARKs самі по собі не можуть вирішити ризики, що не пов'язані з конфіденційністю
Усі форми ідентифікації мають крайні випадки:
Ці крайні випадки є найбільшими загрозами для систем, які намагаються підтримувати властивість "одна особа - одна ідентичність", і вони не мають жодного зв'язку з конфіденційністю. Тому zk-SNARKs не можуть допомогти в цьому.
Підтримка "доказів багатства" для запобігання атакам від відьом не є достатнім рішенням, тому нам потрібна якась форма системи ідентифікації.
У чисто криптопанк-спільноті поширеною альтернативою є: повна залежність від "доказу багатства" для запобігання атак відьом, а не створення будь-якої форми системи ідентифікації. Дозволяючи кожному рахунку генерувати певні витрати, можна запобігти створенню великої кількості облікових записів. Така практика має свої приклади в Інтернеті, наприклад, деякі форуми вимагають від зареєстрованих користувачів сплачувати одноразовий внесок, і якщо обліковий запис буде заблоковано, ця плата не повертається.
Теоретично, навіть можна зробити так, щоб платежі мали умовний характер: під час реєстрації облікового запису вам потрібно лише заблокувати певну суму коштів, і лише у випадку, якщо обліковий запис буде заблоковано, ви втратите ці кошти. Теоретично, це може суттєво підвищити вартість атаки.
Цей підхід показує значні результати в багатьох сценаріях, але в деяких типах сценаріїв він абсолютно не працює. Я зосереджуся на двох типах сценаріїв, які поки що назвемо "сценаріями, подібними до загального базового доходу", і "сценаріями, подібними до управління".
Потреба в ідентифікації в сценах загального базового доходу
Термін "сцена універсального базового доходу" означає ситуацію, коли потрібно виплачувати певну кількість активів або послуг дуже широкій групі користувачів, не враховуючи їх платоспроможність. Деякі проекти систематично реалізують це: будь-яка особа з певною ідентифікацією може регулярно отримувати невелику кількість токенів. Багато аірдропів токенів також досягають подібної мети неформальними способами, намагаючись, щоб принаймні частина токенів потрапила до якомога більшої кількості користувачів.
Цей тип "малого загального базового доходу" може реально вирішити такі проблеми: дати людям достатню кількість криптовалюти для виконання деяких базових on-chain транзакцій та онлайн-покупок. Конкретно це може включати:
Якщо криптовалюти будуть широко використовуватися в усьому світі, це питання більше не існуватиме. Але поки криптовалюти ще не стали поширеними, це може бути єдиним способом для людей отримати доступ до нефінансових застосувань на блокчейні та пов'язаних онлайн-товарів і послуг, інакше вони можуть повністю не мати доступу до цих ресурсів.
Крім того, є ще один спосіб досягти подібного ефекту, а саме "універсальні базові послуги": надання кожному, хто має ідентифікацію, можливості надсилати обмежену кількість безкоштовних транзакцій у певному додатку. Цей підхід може краще відповідати механізму стимулювання та мати вищу капітальну ефективність, оскільки кожен додаток, що отримує вигоду від такого впровадження, може робити це без необхідності оплати для не користувачів; однак це також супроводжується певними компромісами, оскільки універсальність зменшується. Але навіть так, тут все ще потрібне рішення для ідентифікації, щоб запобігти атакам системи спамом, а також уникнути виникнення ексклюзивності, яка походить від вимоги, щоб користувачі сплачували за певний спосіб оплати, і такі способи оплати можуть бути недоступні для всіх.
Остання важлива категорія, на яку варто звернути увагу, – це "гарантія базового забезпечення для всіх". Однією з функцій ідентифікації є надання об'єкта для притягнення до відповідальності, без необхідності, щоб користувачі заставляли кошти, що відповідають масштабам стимулів. Це також допомагає досягти мети: зменшити залежність від обсягу особистого капіталу при вході.
потреба в ідентифікації в сценаріях управління
Уявіть собі систему голосування: якщо ресурси користувача A в 10 разів більші, ніж у користувача B, тоді його право голосу також буде в 10 разів більшим, ніж у B. Але з економічної точки зору, кожна одиниця права голосу приносить A в 10 разів більше вигоди, ніж B. Отже, в цілому, вигода від голосування A для самого себе в 100 разів перевищує вигоду голосування B для себе. Саме тому ми помічаємо, що A витрачає набагато більше зусиль на участь у голосуванні, досліджуючи, як голосувати, щоб максимізувати свої цілі, і навіть може стратегічно маніпулювати алгоритмом. Це також є основною причиною, чому "великі китові" можуть мати надмірний вплив у механізмі голосування токенів.
Більш загальною та глибшою причиною є те, що система управління не повинна надавати однакову вагу "одна особа контролює 100 тисяч доларів" та "1000 осіб спільно володіють 100 тисячами доларів". Останнє представляє 1000 незалежних індивідів, тому воно міститиме більш різноманітну цінну інформацію, а не високу повторюваність незначної інформації. Сигнали від 1000 людей також часто є більш "помірними", оскільки думки різних індивідів часто взаємно компенсують одна одну.
Ця точка стосується як офіційних систем голосування, так і "неофіційних систем голосування", наприклад, можливості людей брати участь у культурній еволюції через публічні висловлювання.
Це свідчить про те, що системи управління не будуть насправді задоволені практикою "незалежно від джерела фінансування, однакові за обсягом кошти розглядаються однаково". Система насправді повинна розуміти внутрішній рівень координації цих фінансових ресурсів.
Потрібно звернути увагу, що якщо ви погоджуєтеся з моєю описовою рамкою вищезгаданих двох категорій сцен, то з технічної точки зору потреба в чітких правилах, таких як "одна людина - один голос", більше не існує.
У цих двох сценаріях ідентифікація все ще є дуже корисною, але її слід дотримуватись "одна особа – одна ідентичність".