zk-SNARKs и цифровая идентификация: Множественные проблемы и потенциальные решения

В настоящее время системы цифровой идентификации, использующие zk-SNARKs для защиты конфиденциальности, постепенно становятся мейнстримом. Разрабатываются различные проекты паспортов на основе zk-SNARKs, которые предлагают удобные программные решения, позволяющие пользователям подтверждать наличие действительной идентификации без необходимости раскрывать детали своей личности. Количество пользователей World ID, проверенных с использованием биометрических технологий и защищенных с помощью zk-SNARKs, недавно превысило 10 миллионов. Некоторые государственные проекты цифровой идентификации также начали применять технологии zk-SNARKs, а работа Европейского союза в этой области все больше акцентируется на zk-SNARKs.

На первый взгляд, широкое применение цифровой идентификации на основе zk-SNARKs кажется большой победой децентрализованного ускорения (d/acc). Это может защитить социальные сети, системы голосования и различные интернет-сервисы от атак ведьм и манипуляций роботами без ущерба для конфиденциальности. Но действительно ли все так просто? Существуют ли все еще риски, связанные с идентификацией на основе zk-SNARKs? В данной статье будут изложены следующие точки зрения:

• zk-SNARKs упаковка решила многие важные проблемы.
• Упакованная в zk-SNARKs идентификация все еще несет риски. Эти риски, кажется, не сильно связаны с биометрией или паспортами, большая часть рисков ( связана с утечкой конфиденциальной информации, подвержен давлению, системные ошибки и т.д. ) в основном возникает из-за жесткого поддержания свойства "один человек - одна идентификация".
• Другой крайностью является использование "доказательства богатства" для предотвращения атак ведьм, что в большинстве случаев приложений оказывается недостаточным, поэтому нам нужно какое-то решение, подобное "идентификации".
• Теоретически идеальное состояние находится между двумя этими вариантами, то есть стоимость получения N идентификаций составляет N².
• Эта идеальная ситуация трудно достижима на практике, но подходящая "многофункциональная идентификация" приближает к ней, поэтому является наиболее реалистичным решением. Многофункциональная идентификация может быть явной (, например, идентификация на основе социальных графов ), а также может быть скрытой (, где сосуществуют различные типы идентификаций на основе zk-SNARKs, и ни один из типов не занимает рынок близко к 100% ).

Как работает идентификация, упакованная в zk-SNARKs?

Представьте себе, что вы получили World ID, сканируя свой радужку глаза, или использовали NFC-ридер на телефоне для сканирования паспорта, получив идентификацию на основе zk-SNARKs. В контексте аргумента этой статьи основные свойства обоих методов согласованы (, существует лишь несколько краевых различий, таких как случаи с множественным гражданством ).

На вашем телефоне есть секретное значение s. В глобальном реестре на блокчейне есть открытое хэш-значение H(s). При входе в приложение вы будете генерировать уникальный для этого приложения идентификатор пользователя, т.е. H(s, app_name), и проверять его с помощью zk-SNARKs: этот идентификатор соответствует какому-то открытом хэш-значению в реестре, исходящему от того же секретного значения s. Таким образом, для каждого открытого хэш-значения можно сгенерировать только один идентификатор для каждого приложения, но при этом никогда не будет раскрыто, какой уникальный идентификатор приложения соответствует какому открытому хэш-значению.

На самом деле, проект может быть немного сложнее. В World ID специализированный ID приложения на самом деле представляет собой хэш-значение, состоящее из ID приложения и ID сессии, поэтому различные действия в одном и том же приложении также могут быть отвязаны друг от друга. Дизайн паспорта на основе zk-SNARKs также может быть построен аналогичным образом.

Перед тем как обсудить недостатки этого типа идентификации, необходимо сначала признать его преимущества. За пределами узкой сферы цифровой идентификации на основе zk-SNARKs (ZKID), чтобы доказать свою личность для сервисов, требующих идентификации, вам придется раскрыть свою полную законную идентификацию. Это серьезно нарушает принцип «минимальных привилегий» в компьютерной безопасности: процесс должен получать только минимальные привилегии и информацию, необходимые для выполнения своей задачи. Им нужно доказать, что вы не робот, что вам исполнилось 18 лет или что вы из определенной страны, но они получают указание на вашу полную идентификацию.

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

Однако с помощью технологии упаковки zk-SNARKs вышеупомянутая проблема в значительной степени решена. Но следующим, что следует обсудить, является менее упоминаемый момент: все еще существуют некоторые проблемы, которые не только не были решены, но могут стать еще более серьезными из-за строгого ограничения "один человек - одна идентификация" в таких схемах.

zk-SNARKs сами по себе не могут обеспечить анонимность

Предположим, что платформа идентификации на основе zk-SNARKs полностью работает по плану, строго воспроизводя всю вышеупомянутую логику, и даже нашла способ долгосрочно защищать конфиденциальную информацию не технических пользователей без зависимости от централизованных учреждений. Однако одновременно мы можем сделать реалистичное предположение: приложения не будут активно сотрудничать в вопросах защиты конфиденциальности, они будут придерживаться принципа "прагматизма", а используемые ими проектные решения, хотя и под флагом "максимизации удобства для пользователей", на самом деле, похоже, всегда будут склоняться к их собственным политическим и коммерческим интересам.

В таких сценариях приложения социальных сетей не будут использовать сложные конструкции, такие как частая смена ключей сеанса, а будут назначать уникальный идентификатор приложения для каждого пользователя. Поскольку система идентификации следует правилу "один человек - одна идентификация", у пользователя может быть только одна учетная запись (, что контрастирует с текущей "слабой идентификацией", например, учетной записью Google, где обычный человек может легко зарегистрировать около 5 учетных записей ). В реальном мире для реализации анонимности обычно требуется несколько учетных записей: одна для "обычной идентификации", а другие для различных анонимных идентификаций ( см. "finsta и rinsta" ). Таким образом, в этой модели анонимность, которую пользователи могут фактически получить, вероятно, будет ниже текущего уровня. Таким образом, даже система "один человек - одна идентификация", упакованная с помощью zk-SNARKs, может постепенно привести нас к миру, где все действия должны зависеть от единственной открытой идентификации. В эпоху нарастающих рисков (, например, мониторинг с использованием дронов ), лишение людей возможности защищать себя через анонимность приведет к серьезным негативным последствиям.

zk-SNARKs сама по себе не может защитить вас от принуждения

Даже если вы не раскрываете свое секретное значение s, никто не может видеть открытые связи между вашими учетными записями. Но что если кто-то заставит вас раскрыть это? Государство может настоятельно требовать раскрытия вашего секретного значения, чтобы просмотреть все ваши действия. Это не пустые слова: правительство США уже начало требовать от заявителей на визу раскрытия своих аккаунтов в социальных сетях. Кроме того, работодатели могут легко сделать раскрытие полной открытой информации условием для найма. Даже отдельные приложения на технологическом уровне могут потребовать от пользователей раскрытия своей идентификации в других приложениях, прежде чем позволить зарегистрироваться и использовать ( для входа в приложение по умолчанию.

Точно так же, в этих случаях ценность атрибутов zk-SNARKs исчезает, но недостатки нового атрибута "один человек — один счет" все еще присутствуют.

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

zk-SNARKs сами по себе не могут решить риски, не связанные с конфиденциальностью

Все формы идентификации имеют крайние случаи:

• Основанные на государственных удостоверениях личности, включая паспорта, не охватывают лиц без гражданства и не включают группы людей, которые еще не получили такие документы.
• С другой стороны, такие основанные на правительстве системы идентификации будут предоставлять уникальные привилегии обладателям многогражданства.
• Орган, выдавший паспорт, может стать жертвой хакерской атаки, а разведывательные службы враждебных государств могут даже подделать миллионы ложных идентификаций ). Например, если "партизанские выборы" в российском стиле постепенно станут популярными, то можно использовать ложные идентификации для манипуляции выборами (.
• Для тех, у кого биометрические характеристики повреждены из-за травм или болезней, биометрическая идентификация будет полностью недействительна.
• Биометрическая идентификация может быть обманута подделками. Если ценность биометрической идентификации станет чрезвычайно высокой, мы даже можем увидеть, как кто-то специально выращивает человеческие органы только для того, чтобы "массово производить" такие идентификации.

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

![Виталик: цифровая идентификация + ZK-технологии в условиях многократных затруднений])https://img-cdn.gateio.im/webp-social/moments-5c5e98a8645b7a2cc02bf3f26d7bf4d7.webp(

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

В чисто криптопанк-сообществе распространенной альтернативой является: полное доверие к "доказательству богатства" для защиты от атак ведьм, а не создание какой-либо формы системы идентификации. Путем установления определенной стоимости для каждого аккаунта можно предотвратить легкое создание множества аккаунтов. Эта практика уже имеет прецеденты в Интернете, например, форум Somethingawful требует от зарегистрированных пользователей одноразовую плату в размере 10 долларов, которая не возвращается, если аккаунт заблокирован. Однако на практике это не является настоящей криптоэкономической моделью, поскольку главное препятствие для создания нового аккаунта заключается не в повторной оплате 10 долларов, а в получении новой кредитной карты.

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

Этот подход показывает значительные результаты во многих ситуациях, но в некоторых типах сценариев он совершенно не работает. Я сосредоточусь на двух классах сценариев, которые пока назовем "сценарии, подобные универсальному базовому доходу )UBI-like(" и "сценарии, подобные управлению )governance-like(".

) необходимость в идентификации в сценарии всеобщего базового дохода

Так называемый "сценарий универсального базового дохода" подразумевает необходимость выдачи определенного количества активов или услуг очень широкой (, в идеале всем ) пользователям, без учета их платежеспособности. Worldcoin именно систематически реализует это: любой, кто имеет World ID, может регулярно получать небольшое количество токенов WLD. Многие раздачи токенов также достигают аналогичных целей более неформальным способом, пытаясь обеспечить, чтобы по крайней мере часть токенов попала к как можно большему количеству пользователей.

Что касается меня лично, я не считаю, что стоимость таких токенов может достичь уровня, достаточного для обеспечения личного существования. В экономике, управляемой искусственным интеллектом, с размерами богатства, достигающими текущих тысяч раз, такие токены могут иметь ценность для поддержания жизни; но даже в этом случае, проекты с государственным руководством, по крайней мере, с поддержкой природных ресурсов, все равно займут более важное место в экономическом плане. Тем не менее, я считаю, что такая "маленькая универсальная базовая доходность" действительно может решить следующую проблему: предоставить людям достаточное количество криптовалюты для выполнения некоторых основных транзакций в блокчейне и онлайн-покупок. Конкретно это может включать:

• Получить ENS имя
• Опубликовать хэш в блокчейне для инициализации какой-либо идентификации zk-SNARKs
• Оплата сборов социальных медиа платформ

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

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