Перейти к содержанию
Financial Context Wiki

Доказательство уникальности человека

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

Обновлено

Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.

Прямой ответ

Доказательство уникальности человека (PoP) — это семейство систем, которое пытается позволить приложению обеспечивать наличие одного допустимого человека на учетную запись, учетные данные, голос, претензию или другое ограниченное действие. Учетные данные PoP могут быть псевдонимными: приложение может узнать только о том, что принятый эмитент зарегистрировал уникального человека и что эти учетные данные еще не использовались в этом контексте. Приложению не нужно знать имя, адрес или государственный идентификатор человека.

Это компактное описание скрывает несколько независимых требований. Человечность спрашивает, участвовал ли живой человек. Уникальность спрашивает, имеет ли этот человек уже другой документ в рамках правил системы. Контроль спрашивает, контролирует ли презентатор данный документ в данный момент. Право на участие спрашивает, принадлежит ли этот человек к населению, которому разрешено действовать. Несвязываемость спрашивает, можно ли сопоставить презентации в разных контекстах. Дизайн может удовлетворять одному требованию и не соответствовать другому: проверка на жизнь не исключает дублирование людей, уникальный паспорт не доказывает, что его презентатор по-прежнему контролирует полученный аккаунт, а анонимное доказательство не делает предвзятый процесс регистрации справедливым.

PoP не то же самое, что проверка идентификации клиента (KYC). KYC обычно устанавливает гражданскую идентичность и собирает атрибуты в юридических или комплаенс-целях. PoP, напротив, может выдавать узкий атрибут, такой как «один принятый участник в этом реестре», и впоследствии подтвердить его, не раскрывая гражданскую идентичность. С другой стороны, запись KYC может помочь устранить дублирующихся заявителей, но автоматически не обеспечивает создание неперсонифицируемых представлений, стойкость к передаче или глобальное покрытие.

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

Как это работает

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

Реализация должна явно указывать следующий жизненный цикл:

  1. Определите объем и политику. Укажите действие, которое защищается, подходящую аудиторию, временной интервал, приемлемые уровни ошибок и что означает «один человек» в крайних случаях. Глобальное человечество, местное проживание, совершеннолетие и членство — это разные утверждения.
  2. Моделируйте противника и стимулы. Оцените ценность дополнительного удостоверения и возможность того, что злоумышленники могут подделать доказательства, привлекать реальных людей, подкупать операторов, взламывать устройства, сговариваться в социальной сети или покупать удостоверения после их выдачи.
  3. Запишитесь и проверьте человечность. Собирайте только те доказательства, которые требуются политикой. Проверка живости или обнаружение попытки подделки может помочь показать, что присутствует живой человек, но это не тест на уникальность.
  4. Удалите дубликаты внутри зарегистрированной популяции. Сравнивайте документы, биометрию, посещение церемонии, аттестации или другие сигналы в соответствии с опубликованными правилами. Результат показывает уникальность относительно данного реестра, времени и метода, а не является доказательством того, что учетные данные не существуют где-либо еще.
  5. Выдать и привязать учетные данные. Привяжите одобренную регистрацию к ключу, аутентификатору или восстанавливаемой учетной записи. Запишите эмитента, срок действия, метод статуса и уровень надежности. Криптографическая проверяемость доказывает, кто подписал утверждение и было ли оно изменено; как отмечает W3C, это само по себе не доказывает, что утверждение является истинным.
  6. Представьте ограниченное доказательство. Держатель может раскрыть учетные данные напрямую или создать презентацию с выборочным раскрытием или нулевым разглашением знаний. Конструкция может доказать членство в группе и вывести специфический для области нулевизатор, чтобы проверяющий отклонил второе действие, не узнавая повторно используемый глобальный идентификатор.
  7. Управляйте жизненным циклом. Проверяйте актуальность и охват, предотвращайте повторное использование, обрабатывайте отзыв и восстановление, публикуйте изменения правил и программного обеспечения, измеряйте ложное принятие и ложный отказ, обеспечивайте проверку человеком и апелляции, и определяйте, что происходит, если эмитент или сервис закрываются.

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

Метрики должны сохранять свои знаменатели. Показатели ложного принятия измеряют количество заявителей или дубликатов, принятых неправильно; показатели ложного отказа измеряют количество законных заявителей, отклонённых неправильно; покрытие измеряет, какая часть целевой популяции реально может зарегистрироваться; стоимость атаки оценивает предельные ресурсы, необходимые для получения ещё одного пригодного удостоверения. Одиночная «точность» в процентах может скрывать небольшую исключённую группу, ошибку при низкой исходной частоте или экономически выгодную атаку.

Рабочие примеры

Ошибки при зачислении

Предположим, что среди 100 000 заявок есть 90 000 уникальных правомочных людей и 10 000 дубликатов или ботов. При уровне ложного отказа 2% будут отклонены 1 800 правомочных людей. При уровне ложного принятия 5% будут приняты 500 недопустимых заявок. Система правильно классифицирует 97 700 заявок, то есть 97,7%, однако этот совокупный показатель не устраняет необходимость исправить 1 800 ошибочных исключений и сдержать риск от 500 дополнительных учетных данных.

Аренда учетных данных при закрытом голосовании

Голосование с участием 8 000 учетных данных заканчивается со счетом 4 050 против 3 950. Если каждую учетную запись можно арендовать за US$ 5, проигрывающей стороне достаточно получить контроль еще над 101 голосом, чтобы победить со счетом 4 051 против 4 050; это обойдется в US$ 505. Уникальность при регистрации не предотвращает передачу, принуждение или платный контроль. Снимок блокирует позднее создание учетных записей только в том случае, если до снимка атакующий ими еще не управлял.

Сфокусированные нули

В упрощённой конструкции держатель получает N = H(person_secret || action_id) и доказывает в нулевом знании, что N был получен из учётных данных в принятом наборе. Две попытки с action_id = grant-2026 дают одинаковое N, поэтому вторая отклоняется. Использование action_id = forum-2026 даёт другой N и может уменьшить взаимосвязь между приложениями. Это концептуальный пример; точные входные данные хеширования, области и заявление о доказательстве зависят от протокола, и метаданные всё ещё могут связывать пользователей.

Охват меняет результат

Эйрдроп имеет токены 1,000,000 и намерен выплатить их каждому правомочному участнику поровну. Если зарегистрируются 10,000 человек, каждый получит 100 токенов. Если требования к поездкам, устройствам или документам исключают 2,000 иных правомочных людей, зарегистрированные 8,000 участника получат по 125 токенов каждый. Контракт выполняет свой реестр корректно, но распределение не равно по всей предполагаемой популяции. Таким образом, охват является частью модели безопасности и справедливости, а не просто показателем пользовательского опыта.

Риски и контроль

Запись и уникальность

  • Ложное принятие: поддельные документы, повторно использованные записи, синтетические медиа, близнецы, пробелы в базе данных или сговорившиеся аттестаторы могут создавать дополнительные учетные данные. Тестируйте весь рабочий процесс, а не только лабораторный алгоритм сопоставления.
  • Ложный отказ: ошибки сопоставления и строгие правила доказательств могут исключать законных участников. Публикуйте показатели по отдельным группам, требуйте ручной проверки для значимых совпадений при дедупликации и обеспечьте доступные способы исправления.
  • Ограниченная область уникальности: реестр обычно может устранять дубликаты только среди записей, которые он может проверить. Укажите географию, эмитентов, каналы регистрации и период, охваченные требованием.
  • Захват проверяющей стороны: подкуп оператора или компрометация регистрационного оборудования могут обойти даже надежную криптографию. Разделяйте обязанности, проверяйте выдачу, меняйте операторов и ограничивайте единоличные полномочия.

Конфиденциальность и защита данных

  • Незаменимая утечка биометрических данных: шаблон лица или радужки нельзя поворачивать как пароль. Минимизируйте сбор, защищайте шаблоны, документируйте хранение и удаление, и получайте информированное согласие там, где это требуется.
  • Корреляция между контекстами: стабильный идентификатор, подпись, нулификатор или временной шаблон могут связывать активность между приложениями. Используйте разделение доменов и несвязываемые презентации, затем тестируйте пути метаданных, а также значения доказательств.
  • Сговор эмитента и проверяющего: доказательство с нулевым разглашением может скрывать атрибуты от проверяющего, в то время как журналы выдачи по-прежнему идентифицируют держателя. Документируйте точку зрения каждой стороны, политику хранения и возможность объединения данных.
  • Постоянная публикация: размещение необработанных биометрических данных, изображений документов или стабильных личных хэшей в блокчейне затрудняет удаление и снижение будущих рисков. Храните конфиденциальные данные регистрации вне публичных реестров.

Жизненный цикл учетных данных

  • Продажа, аренда и принуждение: уникальная учетная запись все еще может быть контролируема кем-то другим. Моделируйте рынки учетных данных и принуждение; не утверждайте о невозможности передачи только потому, что токен не может перемещаться в сети.
  • Компрометация ключа или устройства: криптографическое владение доказывает контроль над секретом, а не личность использующего его человека. Поддерживайте безопасные аутентификаторы, сообщения о компрометации и тщательно ограниченное восстановление.
  • Дублирование при восстановлении: выдача замены без отзыва старых учетных данных создает две действующие личности; чрезмерно строгий процесс восстановления навсегда исключает владельца. Сделайте замену атомарной и проверяемой.
  • Зависимость от отзыва: проверки состояния могут создавать возможности для цензуры, отслеживания или сбоев. Ограничьте полномочия на отзыв, публикуйте причины и уровни обслуживания, поддерживайте апелляции или миграцию.

Управление и включение

  • Централизованные узкие места: ончейн-проверяющий не децентрализует проприетарные сенсоры, одного эмитента, ключ обновления или биометрическую базу данных. Картируйте компонент полномочий по компоненту.
  • Изменения правил: администраторы могут изменять пороговые значения, допустимые документы или критерии соответствия после регистрации пользователей. Используйте версионируемые политики, сроки уведомления, оценки воздействия и процедуры отката.
  • Барьеры доступа: стоимость, поездки, язык, инвалидность, возраст, документы, подключение и требования к устройствам влияют на возможность участия. Измеряйте показатели завершения и отказа во всей целевой аудитории.
  • Институциональный сбой: эмитенты могут закрыться, потерять ключи или прекратить поддержку данных об отзыве. До запуска определите пути экспорта, преемства, завершения работы и повторной регистрации.

Применение и экономическая целостность

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

Распространённые заблуждения

“Доказательство уникальности человека раскрывает юридическую личность”

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

Живость, CAPTCHA или селфи доказывают уникальность

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

Доказательство с нулевым разглашением делает регистрацию надежной

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

Размещение реестра в блокчейне делает систему децентрализованной

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

Один человек, один идентификатор автоматически создает справедливый консенсус или управление

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

Связанные темы

Источники

Навигация

Поиск по вики...