Нулевое разглашение проще понять, если каждый proof связан с конкретным утверждением. Доказательство может скрывать поле credentials, подтверждать результат off-chain вычисления или показывать, что правило идентичности выполнено, не публикуя исходный документ. Оно не делает каждый компонент автоматически trustless и не превращает логин в универсальную идентичность. Статья проверена по указанным материалам 10 августа 2026 года и проходит путь от ZK proof к zkLogin, ZK coprocessor и проверке личности.
Что на самом деле скрывает zero-knowledge proof
Zero-knowledge proof позволяет prover убедить verifier в истинности утверждения и одновременно скрыть выбранные witness-данные. Утверждением может быть наличие определенной связи в подписанном токене, корректный результат программы или выполнение правила credential. Сам proof не является утверждением. Это свидетельство связи между публичными и приватными входами, заданной конкретной схемой или программой.
Это различие важно, потому что приватность выборочна. Verifier может увидеть булев результат, публичное commitment, идентификатор сети, идентификатор программы или время, но не увидеть приватный вход. Proof возрастного порога скрывает дату рождения, однако сам по себе не доказывает, кто выдал credential, надежен ли issuer или выбрал ли verifier правильную policy.
Поэтому практический вопрос не в том, использует ли продукт ZK. Нужно спросить, что публично, что приватно, кто создает witness, каким ключам или параметрам setup доверяют и кто проверяет результат. Даже sound proof может зависеть от OAuth-провайдера, salt-сервиса, indexer, слоя доступности данных, issuer или приложения со слабым правилом.
Как zkLogin связывает веб-логин с адресом
Тем, кто ищет zkLogin explained, стоит начать с привязки идентичности, а не со слова wallet. В zkLogin от Sui используется вход через OpenID Connect, который возвращает подписанный JSON Web Token. Приложение также создает краткоживущую ephemeral key pair. Nonce в токене строится из публичного ephemeral key, случайности и epoch истечения, поэтому последующая транзакционная сессия связана с login flow.
Документация Sui разделяет salt service и proving service как разные backend-роли. Salt используется вместе с issuer, audience приложения и subject claim для вывода seed адреса. Если salt остается приватным, OAuth-идентификатор можно отделить от onchain-адреса. Proving service получает токен и нужные входы и создает Groth16 proof, проверяющий связь подписи провайдера, nonce, claim и вывода адреса.
У адреса и session key разные сроки жизни. Адрес может оставаться стабильным, пока issuer, audience, subject и user salt те же, а ephemeral key истекает на заданном epoch. Новый login создает новый session key и proof для того же адреса. Validators проверяют proof и ephemeral signature до выполнения транзакции. Это protocol-specific flow, а не утверждение, что любой social login создает self-custodied identity.
Граница доверия видна в деталях. OAuth-провайдер аутентифицирует аккаунт и подписывает токен. Приложение управляет frontend и ephemeral key. Salt service может видеть чувствительные входы в зависимости от дизайна, а proving service обрабатывает токен и входы для proof. Sui отмечает, что эти сервисы могут связать identity и salt в собственной области видимости, хотя JWT не публикуется onchain. Приватность зависит от этих допущений и защиты salt и session key.
Что вычисляет ZK coprocessor
Фразу zk coprocessor explained лучше рассматривать как архитектурный вопрос. Coprocessor выносит тяжелую работу с данными или вычислениями за пределы application chain и возвращает результат вместе с evidence, что использовались authenticated inputs и заявленная computation. В pure ZK-модели verifier contract проверяет proof и использует результат, не повторяя все вычисление.
Документация Brevis показывает три стадии: доступ к данным, вычисление приложения и использование результата. Приложение запрашивает исторические onchain-данные, off-chain prover запускает логику, затем результат и proof передаются для onchain-проверки. Такой шаблон подходит для порога активности, membership-правила, расчета reward или risk flag. Proof не доказывает автоматически, что источник данных был подходящим: он доказывает только реализованное отношение.
Это не то же самое, что получить ответ от indexer. Неподтвержденный ответ требует доверять стороне, которая выбрала данные и посчитала результат. ZK coprocessor может связать результат с authenticated chain data и circuit, уменьшая это доверие. Но circuit, commitments, proof system, verifier и процесс обновления сами становятся объектами проверки.
Coprocessor не является одной неизменной feature. Brevis различает pure ZK и coChain или optimistic model, у которых разные latency, cost и challenge assumptions. RISC Zero описывает verifiable computation шире: output программы сопровождается receipt, который verifier может проверить без повторного запуска и без просмотра приватных входов. Эти материалы объясняют идею, но каждый deployment требует собственной проверки statement, input authentication и failure policy.
Где заканчивается доказательство ID check
ID check можно представить как утверждение о credential, а не как магическое доказательство личности человека. Verifier может спросить, подписал ли issuer credential, находится ли она в сроке действия, достиг ли subject возрастного порога или находится ли идентификатор документа в revocation list. ZK circuit скрывает ненужные поля и раскрывает минимальный результат, требуемый приложению.
Поэтому выражение zero knowledge identity verification нужно разложить на роли issuer, holder и verifier. W3C Verifiable Credentials описывает credential как claims issuer, которыми владеет subject или holder и которые передаются verifier вместе с механизмами проверки подлинности и целостности. W3C DID описывает identifiers и verification methods, но наличие DID или формата credential само по себе не делает реального человека, организацию или документ правдивыми.
Возьмем age check. Proof может показать, что подписанная дата рождения раньше cutoff policy, не раскрывая саму дату. Но он не решает, надежно ли issuer проверил документ, принадлежит ли credential текущему holder, законен ли cutoff в конкретной юрисдикции или отозвана ли credential. Это разные вопросы issuer, binding, policy и lifecycle.
Та же граница действует для sanctions, residency, accreditation и account uniqueness. Circuit может закодировать predicate issuer approved set and claim satisfies rule. Он не исправляет слабый issuer registry, украденную credential, скомпрометированный wallet, ошибочную source record или неполный revocation feed. True означает, что заданный predicate прошел проверку на поданных входах, а не что все реальные факты за ними истинны.
Приватность является выбором дизайна
ZK уменьшает раскрытие, но приватность зависит от всего flow. Verifier все еще может видеть public address, время, сеть, application audience, частоту proof или сам факт попытки пройти policy. Повторные presentations могут быть связаны, если приложение повторно использует identifiers или public commitments. Metadata иногда раскрывает больше, чем circuit скрывает в witness.
zkLogin показывает это через salt и OpenID claims. Salt помогает разорвать связь между OAuth identifier и onchain address, но потеря salt может лишить доступа к адресу, а его раскрытие может сделать subject linkable. OAuth provider, frontend, salt service, proving service и validators видят разные части flow. Privacy review должен описывать эти views, а не считать proof одним privacy switch.
Для coprocessor приватность также зависит от места обработки raw data и witness. Onchain verifier может проверить результат, не видя private inputs, но off-chain prover или data provider могли видеть их во время вычисления. Приложение может публиковать result, query identifier, block range или commitment. Если входы нужно скрыть и от prover, одного public ZK verifier недостаточно: могут потребоваться private proving, secure execution или encrypted computation.
Полезен принцип minimum disclosure: доказывать только predicate, который нужен приложению, использовать purpose-specific audience или domain separator, менять session material по правилам протокола и документировать retention и correlation risks. Это не удаляет доверие, но делает оставшиеся пути доверия и раскрытия проверяемыми.
Какие роли должен назвать trust model
Сначала запишите statement и public inputs. Нужно точно указать, что принимает verifier, какие данные committed, как authenticated chain state или credential и какая версия software или circuit создала proof. Если contract может использовать result, назовите verifier code, upgrade authority, emergency path и обработку stale data.
Затем назовите actors. Для zkLogin это OpenID provider, application, holder ephemeral key, salt service, proving service и Sui validators. Для coprocessor добавьте data source, indexer или light client, prover, verifier и challenge или staking mechanism. Для ID check добавьте issuer, holder, wallet или presentation layer, verifier и revocation или status service. Отсутствующий actor на схеме сам является risk signal.
Отделяйте correctness от availability и recovery. Valid proof может прийти слишком поздно. Provider может rotate keys. Salt service может быть unavailable. Credential может expire. Reorganization или finality rule может изменить input set. Optimistic path coprocessor может зависеть от честного challenge в заданное окно. Это operational property, которую математический proof не исправляет.
Наконец, проверьте setup и upgrade assumptions. Sui описывает Groth16 common reference string ceremony для zkLogin. Другие системы используют transparent proof system, zkVM receipt, trusted setup, committee, staking layer или их комбинацию. Спросите, кто может изменить circuit, verifier, issuer registry, provider list, data source или policy. Proof может корректно проверить вчерашнюю policy и все же дать неправильный ответ сегодня.
Как читать утверждение о ZK identity
Когда документация говорит, что feature private, превратите это в таблицу: private от кого, видимо кому, на какой срок и каким способом возможна корреляция. Когда сказано trustless, спросите, какой actor удален и кто остается trusted для inputs, keys, availability, recovery и governance. Когда сказано verifiable, уточните конкретное computation или credential relation.
Проверьте описанную последовательность в пять шагов. Сначала изучите statement и witness. Затем проследите binding от provider token или credential до application address или presentation. Потом найдите off-chain computation и его authenticated data source. После этого перечислите issuer, policy, revocation и holder assumptions ID check. Наконец, проверьте privacy leakage через metadata, повторное использование и видимость сервисов.
Так три идеи остаются раздельными. zkLogin связывает краткоживущий transaction key с claims OpenID flow и скрывает выбранные claim data от chain. ZK coprocessor делает off-chain computation verifiable относительно заявленных data. ID check доказывает выполнение определенного credential predicate. Ни одно из этих утверждений не доказывает честность пользователя, надежность issuer, актуальность data или безвредность окружающих сервисов.
Именно здесь используется zero knowledge: в четко ограниченном отношении между input, computation и verification. Полезный результат не является обещанием невидимой identity. Это небольшой и аудируемый claim с явно записанными privacy и trust assumptions. Их следует хранить вместе с protocol version, датой источника и policy, чтобы будущие изменения не приняли за постоянную гарантию.
Дисклеймер: эта статья — образовательный материал Bitbase Academy, только для информационных целей. Она не является инвестиционным, торговым, налоговым или финансовым советом. Криптоактивы волатильны — оценивайте риски самостоятельно. Написано в августе 2026 года; сверяйтесь с актуальной официальной информацией.
Источники
[1] Sui: zkLogin documentation docs.sui.io
[2] OpenID Connect Core 1.0 openid.net
[3] Brevis documentation docs.brevis.network
[4] RISC Zero: Proof System dev.risczero.com
[5] W3C: Verifiable Credentials Data Model v2.0 w3.org
[6] W3C: DID Core w3.org
