Системи zero knowledge легше зрозуміти, коли кожен proof пов'язаний із конкретним твердженням. Доказ може приховати поле посвідчення, підтвердити результат off-chain обчислення або показати виконання правила ідентичності без публікації документа. Він не робить кожен компонент автоматично trustless і не перетворює логін на універсальну особу. Ця стаття проходить межу між ZK proof, zkLogin, ZK coprocessor і перевіркою особи.
Що насправді приховує zero-knowledge proof
Zero-knowledge proof дає змогу prover переконати verifier у правдивості твердження, приховуючи вибрані witness-дані. Твердження може стосуватися підписаного токена, результату програми або credential, що відповідає правилу. Proof не є самим твердженням: це доказ зв'язку між публічними й приватними входами, заданого конкретною схемою або програмою.
Тому приватність є вибірковою. Verifier може побачити булевий результат, публічний commitment, ідентифікатор мережі, програми або час, але не приватний вхід. Proof вікового порогу може приховати дату народження, проте не доводить надійність issuer чи правильність політики verifier.
Практичне питання полягає не лише в тому, чи використовує продукт ZK. Потрібно з'ясувати, що публічне, що приватне, хто створює witness, яким ключам або setup довіряють і хто перевіряє результат. Навіть sound proof може залежати від OAuth-провайдера, salt service, indexer, issuer credential або застосунку зі слабким правилом.
Як zkLogin пов'язує веблогін з адресою
Для запиту zk login explained спочатку треба зрозуміти зв'язок ідентичності, а не слово wallet. Sui zkLogin використовує OpenID Connect і підписаний JSON Web Token. Застосунок також створює короткоживучу пару ключів. Nonce у токені поєднує ephemeral public key, випадковість і epoch завершення, тому сесія транзакції пов'язана з потоком логіну.
Документація Sui розділяє salt service і proving service. Salt, issuer, audience застосунку та subject claim беруть участь у виведенні seed адреси. Якщо salt залишається приватним, OAuth-ідентифікатор можна відокремити від on-chain адреси. Proving service отримує токен і потрібні входи та створює Groth16 proof, що перевіряє підпис провайдера, nonce, claim і виведення адреси.
Адреса і session key мають різний строк життя. Адреса може залишатися стабільною, якщо issuer, audience, subject і user salt не змінюються, а ephemeral key завершується у визначену epoch. Новий логін може створити новий ключ і proof для тієї самої адреси. Validators перевіряють proof та ephemeral signature до виконання транзакції. Це protocol-specific flow, а не твердження, що кожен social login створює self-custodied identity.
Межа довіри видно в деталях. OAuth-провайдер автентифікує обліковий запис і підписує токен. Застосунок контролює frontend та ephemeral key. Salt service і proving service можуть бачити чутливі дані залежно від дизайну. Sui зазначає, що ці сервіси можуть пов'язувати identity і salt у власному поданні, хоча JWT не публікується on-chain. Приватність залежить від цих припущень і захисту salt та session key.
Що обчислює ZK coprocessor
Фразу zk coprocessor explained краще розглядати як архітектурне питання. Coprocessor виносить важке для даних або обчислень завдання за межі application chain і повертає результат із доказом, що використано автентичні входи та заявлене обчислення. У pure ZK моделі verifier contract перевіряє proof, не повторюючи весь розрахунок.
Документація Brevis показує три етапи: доступ до даних, обчислення застосунку й використання результату. Застосунок запитує історичні дані, off-chain prover виконує логіку, а результат і proof подаються для on-chain перевірки. Схема може підтримувати поріг активності, membership rule, розрахунок reward або risk flag. Proof не доводить автоматично придатність джерела даних, а лише фактично доведену relation.
Це відрізняється від простого запиту до indexer. Непідтверджена відповідь вимагає довіри до того, хто вибрав дані й обчислив результат. ZK coprocessor може зменшити таку довіру, пов'язавши результат з authenticated chain data та circuit. Але circuit, commitments, proof system, verifier і процес оновлення самі потребують перевірки.
Coprocessor не є однією незмінною функцією. Brevis розрізняє pure ZK і coChain або optimistic модель із різними latency, cost і challenge assumptions. RISC Zero описує verifiable computation ширше: output програми має receipt, який verifier може перевірити без повторного запуску та без перегляду приватних входів. Кожне розгортання все одно потребує власного 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 описує claims issuer, якими володіє subject або holder і які подаються verifier із механізмами перевірки автентичності та цілісності. W3C DID описує ідентифікатори й verification methods, але сам формат DID або credential не гарантує правдивість реальної людини, організації чи документа.
Візьмімо перевірку віку. Proof може показати, що підписана дата народження раніша за policy cutoff, не розкриваючи дату. Але він не вирішує, чи issuer надійно перевірив документ, чи credential належить поточному holder, чи законний cutoff у певній юрисдикції, чи credential відкликано. Це окремі issuer, binding, policy і lifecycle питання.
Та сама межа діє для санкцій, резидентства, акредитації та унікальності облікового запису. Circuit може закодувати predicate “issuer approved set і claim satisfies rule”, але не виправляє слабкий issuer registry, викрадену credential, зламаний wallet, помилковий source record або неповний revocation feed. True означає, що заданий predicate пройшов перевірку на наданих входах, а не що всі реальні факти за ними правдиві.
Приватність — це вибір дизайну, а не результат proof
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 могли бачити їх під час обчислення. Якщо входи треба приховати й від 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 може змінити ключі, salt service — бути недоступним, credential — завершити строк дії. 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; 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, а менший audit-able claim із явно записаними privacy і trust assumptions. Їх слід зберігати разом із protocol version, датою джерел і policy, щоб майбутні зміни не сприймалися як постійна гарантія.
Схожі матеріали
Інші матеріали Bitbase на цю тему:
- Доказ особистості та стійкість до атак Сивіли
- Приватні транзакції, shielded addresses і view keys
- Як визначається право на аірдроп: знімки стану, бали та фільтри Sybil
Застереження: Ця стаття є освітнім матеріалом 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
