Gdzie naprawdę stosuje się zero knowledge: zkLogin, koprocesory i kontrole tożsamości

2026-08-12

Zero knowledge najlepiej rozumieć wtedy, gdy każdy proof jest związany z konkretnym twierdzeniem. Dowód może ukrywać pole credential, potwierdzać wynik obliczenia off-chain albo pokazywać, że spełniono regułę tożsamości bez publikowania dokumentu źródłowego. Nie sprawia, że każdy komponent staje się trustless, ani nie zamienia logowania w uniwersalną tożsamość. Tekst sprawdzony względem wskazanych materiałów 10 sierpnia 2026 roku prowadzi od ZK proof przez zkLogin i ZK coprocessor do kontroli tożsamości.

Co naprawdę ukrywa zero-knowledge proof

Zero-knowledge proof pozwala proverowi przekonać verifiera, że twierdzenie jest prawdziwe, a jednocześnie ukryć wybrane dane witness. Twierdzenie może mówić, że podpisany token zawiera określoną relację, program zwrócił wskazany wynik albo credential spełnia regułę. Proof nie jest samym twierdzeniem. Jest dowodem relacji między publicznymi i prywatnymi wejściami określonej przez circuit lub program.

To rozróżnienie ma znaczenie, bo prywatność jest selektywna. Verifier może zobaczyć wynik Boolean, public commitment, identyfikator sieci, identyfikator programu lub czas, ale nie zobaczyć prywatnego wejścia. Dowód progu wieku może ukryć datę urodzenia, lecz sam nie dowodzi, kto wydał credential, czy issuer jest wiarygodny ani czy verifier użył właściwej policy.

Praktyczne pytanie nie brzmi więc, czy produkt używa ZK. Trzeba zapytać, co jest publiczne, co prywatne, kto tworzy witness, którym kluczom lub parametrom setup ufa system i kto sprawdza wynik. Nawet sound proof może zależeć od dostawcy OAuth, salt service, indexera, warstwy dostępności danych, issuera lub aplikacji ze słabą regułą.

Jak zkLogin wiąże logowanie z adresem

Osoby szukające zkLogin explained powinny zacząć od wiązania tożsamości, a nie od słowa wallet. Sui zkLogin korzysta z logowania OpenID Connect, które zwraca podpisany JSON Web Token. Aplikacja tworzy też krótkotrwałą ephemeral key pair. Nonce w tokenie powstaje z ephemeral public key, losowości i epoch wygaśnięcia, więc późniejsza sesja transakcyjna jest związana z tym flow logowania.

Dokumentacja Sui rozdziela salt service i proving service jako role backendowe. Salt jest używany wraz z issuerem, audience aplikacji i subject claim do wyprowadzenia seeda adresu. Gdy salt pozostaje prywatny, można odłączyć identyfikator OAuth od adresu onchain. Proving service otrzymuje token i wymagane wejścia oraz tworzy Groth16 proof, który sprawdza relacje między podpisem dostawcy, nonce, claimem i wyprowadzeniem adresu.

Adres i session key mają różne okresy życia. Adres może pozostać stały, jeśli issuer, audience, subject i user salt pozostają takie same, natomiast ephemeral key wygasa przy określonym epoch. Nowe logowanie tworzy nowy session key i proof dla tego samego adresu. Validators sprawdzają proof i ephemeral signature przed wykonaniem transakcji. To protocol-specific flow, a nie twierdzenie, że każde social login tworzy self-custodied identity.

Granica zaufania jest widoczna w szczegółach. Dostawca OAuth uwierzytelnia konto i podpisuje token. Aplikacja kontroluje frontend i ephemeral key. Salt service może widzieć wrażliwe wejścia zależnie od projektu, a proving service przetwarza token i wejścia proof. Sui wskazuje, że usługi te mogą powiązać identity i salt w swoim widoku, choć JWT nie jest publikowany onchain. Prywatność zależy od tych założeń oraz od ochrony salt i session key.

Co oblicza ZK coprocessor

Fraza zk coprocessor explained najlepiej opisuje pytanie architektoniczne. Coprocessor przenosi ciężkie zadanie danych lub obliczeń poza application chain, a następnie zwraca wynik wraz z dowodem, że użyto uwierzytelnionych wejść i zadeklarowanej computation. W pure ZK verifier contract sprawdza proof i wykorzystuje wynik bez powtarzania całego obliczenia.

Przepływ ZK proof od prywatnego wejścia do weryfikowalnego wyniku aplikacji

Dokumentacja Brevis pokazuje trzy etapy: data access, obliczenie aplikacji i użycie wyniku. Aplikacja pobiera historyczne dane onchain, off-chain prover uruchamia własną logikę, a następnie wynik i proof trafiają do weryfikacji onchain. Ten schemat pasuje do progu aktywności, reguły membership, obliczenia reward lub risk flag. Proof nie dowodzi automatycznie, że źródło danych było właściwe. Dowodzi tylko zdefiniowanej relacji.

To coś innego niż zwykła odpowiedź indexera. Nieudowodniona odpowiedź wymaga zaufania stronie, która wybrała dane i policzyła wynik. ZK coprocessor może połączyć wynik z authenticated chain data i circuit, ograniczając to zaufanie. Circuit, commitments, proof system, verifier i proces aktualizacji stają się jednak kolejnymi elementami do audytu.

Coprocessor nie jest jedną stałą funkcją produktu. Brevis rozróżnia pure ZK oraz coChain lub model optimistic, które mają inne założenia dotyczące latency, cost i challenge. RISC Zero opisuje verifiable computation szerzej: output programu ma receipt, który verifier może sprawdzić bez ponownego uruchomienia i bez oglądania prywatnych wejść. Każde wdrożenie nadal wymaga własnej analizy statement, input authentication i failure policy.

Gdzie kończy się dowód kontroli ID

Kontrolę ID można opisać jako twierdzenie o credential, a nie magiczny dowód o człowieku. Verifier może sprawdzić, czy issuer podpisał credential, czy mieści się ona w okresie ważności, czy subject przekracza próg wieku albo czy identyfikator dokumentu znajduje się na revocation list. ZK circuit ukrywa niepotrzebne pola i ujawnia minimalny wynik potrzebny aplikacji.

Wyrażenie zero knowledge identity verification trzeba więc rozłożyć na role issuer, holder i verifier. W3C Verifiable Credentials opisuje credential jako claims issuera posiadane przez subject lub holdera i przedstawione verifierowi z mechanizmami sprawdzania autentyczności oraz integralności. W3C DID opisuje identyfikatory i verification methods, ale sam format DID lub credential nie gwarantuje prawdziwości osoby, organizacji ani dokumentu.

Weźmy age check. Proof może pokazać, że podpisana data urodzenia jest wcześniejsza niż cutoff policy, bez ujawnienia daty. Nie rozstrzyga jednak, czy issuer rzetelnie sprawdził dokument, czy credential należy do obecnego holdera, czy cutoff jest właściwy w danej jurysdykcji ani czy credential została unieważniona. To osobne pytania dotyczące issuer, binding, policy i lifecycle.

Ta sama granica dotyczy sanctions, residency, accreditation i account uniqueness. Circuit może zakodować predicate issuer approved set and claim satisfies rule. Nie naprawi słabego issuer registry, skradzionej credential, przejętego wallet, błędnego source record ani niepełnego revocation feed. True oznacza, że predicate przeszedł weryfikację dla podanych wejść, a nie że wszystkie fakty świata rzeczywistego są prawdziwe.

Prywatność jest wyborem projektu

ZK ogranicza ujawnianie, ale prywatność zależy od całego flow. Verifier może nadal widzieć public address, czas, sieć, application audience, częstotliwość proof lub fakt próby spełnienia policy. Powtarzane presentations mogą być łączone, jeśli aplikacja używa tych samych identyfikatorów lub public commitments. Metadata może ujawnić więcej niż witness ukryty przez circuit.

zkLogin pokazuje to przez salt i OpenID claims. Salt pomaga rozłączyć OAuth identifier i onchain address, ale jego utrata może odebrać dostęp do adresu, a ujawnienie może ułatwić powiązanie subject. OAuth provider, frontend, salt service, proving service i validators widzą różne fragmenty flow. Privacy review powinien opisać te widoki, a nie traktować proof jako jednego przełącznika prywatności.

W coprocessor prywatność zależy również od tego, gdzie przetwarzane są raw data i witness. Onchain verifier może sprawdzić wynik bez oglądania private inputs, ale off-chain prover lub data provider mogli je widzieć podczas obliczeń. Aplikacja może publikować result, query identifier, block range lub commitment. Gdy dane mają być ukryte również przed proverem, sam public ZK verifier może nie wystarczyć; potrzebne mogą być private proving, secure execution lub encrypted computation.

Pomaga zasada minimum disclosure: dowodzić tylko predicate potrzebnego aplikacji, używać purpose-specific audience lub domain separator, rotować session material zgodnie z protokołem i dokumentować retention oraz correlation risks. Nie usuwa to zaufania, lecz czyni pozostałe ścieżki zaufania i ujawnienia możliwymi do przeglądu.

Jakie role musi nazwać trust model

Najpierw zapisz statement i public inputs. Określ dokładnie, co akceptuje verifier, jakie dane są committed, jak uwierzytelniono chain state lub credential oraz jaka wersja software albo circuit stworzyła proof. Jeśli contract może używać wyniku, nazwij verifier code, upgrade authority, emergency path i obsługę stale data.

Następnie nazwij actors. W zkLogin są to OpenID provider, application, posiadacz ephemeral key, salt service, proving service i Sui validators. W coprocessor dodaj data source, indexer lub light client, prover, verifier oraz challenge albo staking mechanism. W kontroli ID dodaj issuer, holder, wallet lub presentation layer, verifier i revocation albo status service. Brak aktora na schemacie jest sygnałem ryzyka.

Oddziel correctness od availability i recovery. Valid proof może przyjść zbyt późno. Provider może rotate keys. Salt service może być unavailable. Credential może expire. Reorganization lub finality rule może zmienić input set. Optimistic path coprocessora może zależeć od uczciwego challenge w określonym oknie. To cecha operacyjna, której proof matematyczny nie naprawia.

Na końcu sprawdź setup i upgrade assumptions. Sui opisuje Groth16 common reference string ceremony dla zkLogin. Inne systemy używają transparent proof system, zkVM receipt, trusted setup, committee, staking layer lub kombinacji. Zapytaj, kto może zmienić circuit, verifier, issuer registry, provider list, data source albo policy. Proof może poprawnie sprawdzić wczorajszą policy i nadal dać dziś niewłaściwą odpowiedź.

Jak czytać twierdzenie o ZK identity

Gdy dokumentacja mówi, że feature jest private, zapisz: private dla kogo, widoczne dla kogo, jak długo i jaką metodą można je korelować. Gdy mówi trustless, zapytaj, którego aktora usunięto i komu nadal ufa się w sprawie inputs, keys, availability, recovery i governance. Gdy mówi verifiable, ustal dokładną computation albo credential relation.

Przejrzyj opisaną sekwencję w pięciu krokach. Najpierw sprawdź statement i witness. Następnie prześledź binding od provider token albo credential do application address lub presentation. Potem wskaż off-chain computation i jego authenticated data source. Następnie wypisz issuer, policy, revocation i holder assumptions kontroli ID. Na końcu sprawdź privacy leakage przez metadata, ponowne użycie i widoczność usług.

W ten sposób trzy idee pozostają osobne. zkLogin wiąże krótkotrwały transaction key z claims przepływu OpenID i ukrywa wybrane claim data przed chain. ZK coprocessor czyni off-chain computation verifiable względem zadeklarowanych data. Kontrola ID dowodzi spełnienia określonego credential predicate. Żadne z tych twierdzeń samo nie dowodzi uczciwości użytkownika, wiarygodności issuera, aktualności danych ani bezpieczeństwa usług pomocniczych.

Właśnie tu zero knowledge jest faktycznie używane: w precyzyjnie ograniczonej relacji między input, computation i verification. Wynik nie jest obietnicą niewidzialnej identity. Jest mniejszym, audytowalnym claimem z jawnymi założeniami prywatności i zaufania. Założenia powinny być zapisane razem z protocol version, datą źródła i policy, aby późniejszej zmiany nie pomylić z trwałą gwarancją.

Zastrzeżenie: ten artykuł to treść edukacyjna Bitbase Academy, wyłącznie w celach informacyjnych. Nie stanowi porady inwestycyjnej, handlowej, podatkowej ani finansowej. Kryptoaktywa są zmienne — samodzielnie oceń ryzyko. Napisano w sierpniu 2026 r.; sprawdzaj aktualne oficjalne informacje.