zkAPI na Ethereum ukrywa, kto płaci za AI. Model nadal widzi prompt

Fundacja Ethereum i Open Anonymity Project uruchomiły zkAPI w głównej sieci Ethereum 1 października. Użytkownik może wpłacić środki i udowodnić, że późniejsze żądanie API AI jest opłacone, nie ujawniając serwerowi płatności swojej tożsamości ani dostawcy modelu adresu źródłowego finansowania. Dostawca nadal otrzymuje prompt. Ten rozdział jest użyteczny, ale to węższe twierdzenie o prywatności niż anonimowa rozmowa z modelem.

Ogłoszenie techniczne Fundacji Ethereum jest wyjątkowo jednoznaczne co do granicy. Dowód ukrywa, który banknot płaci za użycie, podczas gdy dostawca obsługuje model i widzi żądanie. Wymienia również metadane sieciowe i treść promptu jako pozostałe źródła korelacji. To ma znaczenie, ponieważ fraza prywatne płatności AI może łatwo być słyszana jako prywatne użycie AI.

Projekt jest aktywny, według Fundacji, z publicznym repozytorium GitHub, skarbcem w głównej sieci przechowującym kredyty USDC i demonstracyjnym interfejsem czatu podlinkowanym w ogłoszeniu. Aktywne wdrożenie dowodzi, że istnieje kod i kontrakt do zbadania. Nie dowodzi adopcji przez użytkowników, zakresu audytu bezpieczeństwa, anonimowości w każdej konfiguracji klienta ani ochrony przed dostawcą, który rozpoznaje pismo i dokumenty użytkownika.

Jedna wpłata zastępuje ślad faktur API

Większość komercyjnych API AI łączy klucz z kontem i metodą płatności. Dostawca może powiązać żądania z tożsamością rozliczeniową, nawet jeśli użytkownik nigdy nie podpisuje promptu nazwiskiem. zkAPI wprowadza zasilony skarbiec i prywatny banknot. Użytkownik wpłaca obsługiwane aktywa, takie jak USDC, do kontraktu; oprogramowanie na maszynie użytkownika później generuje dowód zerowej wiedzy, że ważny zasilony banknot może zapłacić za ograniczone użycie bez ujawniania, który to banknot.

Serwer płatności weryfikuje dowód i wydaje krótkotrwały klucz API z limitem dolarowym. W trybie bezpośredniego klucza wykonawczego opisanym przez Fundację, prompty przechodzą z urządzenia użytkownika do dostawcy AI z tym kluczem. Po sesji podpisany paragon rejestruje zmierzone użycie, a prywatne saldo jest obciążane za wykorzystaną kwotę, a nie tylko zarezerwowany limit. Jeden dowód może pokryć sesję wielu żądań.

To pozwala uniknąć umieszczania każdego żądania modelu na Ethereum. Łańcuch widzi wpłaty do skarbca, zamknięcia i wypłaty, podczas gdy serwer weryfikuje dowody wydatków offchain. Dostawca modelu widzi tekst i ruch API. Serwer płatności widzi dowód, że sesja jest finansowana i całkowitą opłatę, ale w trybie bezpośrednim nie otrzymuje promptu. To są twierdzenia o opisanej architekturze, a nie dowód, że logi lub konfiguracja sieci konkretnego wdrożenia nigdy nie mogą korelować użytkowników.

Istnieje prostszy tryb proxy. W nim serwer zkAPI przekazuje żądanie użytkownika do dostawcy modelu. Ten serwer może widzieć ruch, według Fundacji. Osoba decydująca między trybami powinna zapytać, której stronie ufa w zakresie treści, a która musi tylko zweryfikować dowód płatności. Lokalny interfejs, który wygląda identycznie, może kierować żądania inaczej pod spodem.

Banknot dowodzi wartości, nie ujawniając swojego deponenta

Konstrukcja kryptograficzna wykorzystuje zobowiązania w drzewie Merkle'a. Dowód mówi, że banknot użytkownika znajduje się wśród ważnych, zasilonych banknotów, nie identyfikując jego liścia. Nulifikator, wyprowadzony z sekretu banknotu, zapobiega dwukrotnemu wydaniu tego samego salda. Fundacja wymienia dowody Groth16 na BN254 i hasze Poseidon, z drzewem o 32 poziomach. Te szczegóły mają znaczenie dla implementujących, ale zasada finansowa jest prostsza: zweryfikuj członkostwo i pozostałe uprawnienie do wydania środków bez publikowania konta, które dostarczyło kredyt.

Użytkownik nie uzyskuje darmowego korzystania poprzez ukrycie tożsamości. Serwer musi sprawdzić dowód wydania i zarezerwować limit, zanim wyda tymczasowy klucz. Dostawca mierzy użycie. Paragon rozlicza rzeczywistą kwotę po wygaśnięciu klucza. Jeśli zarezerwowano limit 10 dolarów, a zużyto usługę o wartości 3 dolarów, system ma obciążyć 3 dolary, a nie 10 dolarów. Ten przykład ilustruje logikę rezerwacji, a nie opublikowaną cenę ani gwarantowane minimum. Pozostałe saldo pozostaje w prywatnym banknocie, z zastrzeżeniem zasad implementacji.

Nulifikator rozwiązuje konkretny problem: próbę dwukrotnego wydania jednego banknotu. Nie dowodzi, że model AI odpowiedział dokładnie, nie zachowuje poufności zapytania ani nie zapobiega rejestrowaniu żądań przez dostawcę. Dowód wiedzy zerowej to stwierdzenie o ważności transakcji w ramach zdefiniowanego obwodu. Jego gwarancje nie rozszerzają się automatycznie na inne dane, które przemieszczają się wraz z transakcją.

Ścieżka wyjścia z kontraktu również ma znaczenie. Fundacja twierdzi, że użytkownik może zamknąć saldo sejfu i wypłacić onchain, nawet jeśli serwery zkAPI znikną. Pozwala to uniknąć sytuacji, w której serwer płatności staje się jedyną drogą do odzyskania środków. Nie czyni to jednak wyjść niewidocznymi: Ethereum rejestruje odpowiednie transakcje. Zdolność użytkownika do wyjścia zależy od kontraktu i posiadania niezbędnego sekretu, a rozważny użytkownik powinien sprawdzić adresy wdrożenia, uprawnienia i wszelkie niezależne audyty przed przypisaniem dużej wartości do tego mechanizmu.

Dostawca może rozpoznać to, czego dowód nie może ujawnić

Dowód płatności może ukryć źródło finansowania, podczas gdy treść żądania zawiera imię i nazwisko osoby, pracodawcę, historię medyczną lub zastrzeżony kod. Dostawca modelu, który czyta zapytanie, może powiązać je z wcześniejszymi sesjami za pomocą powtarzających się zwrotów, przesłanych plików, historii rozmów lub wysoce charakterystycznych faktów. Powiązanie z portfelem nie jest potrzebne. Zapytanie o nieopublikowany produkt z tą samą wewnętrzną nazwą projektu w trzech sesjach samo w sobie jest identyfikatorem.

Metadane sieciowe dostarczają kolejnej ścieżki. W trybie klucza środowiska uruchomieniowego dostawca może zobaczyć adres IP, z którego łączy się urządzenie. W trybie proxy pośrednik może zobaczyć ruch i potencjalnie informacje o sieci pochodzenia. Fundacja wyraźnie stwierdza, że stały adres IP i skorelowane czasy mogą osłabić prywatność, i sugeruje narzędzia anonimowości sieciowej użytkownikom szukającym silniejszej ochrony. VPN lub Tor mogą zmienić ścieżkę sieciową, ale żaden z nich nie usuwa imienia wpisanego w zapytanie.

Istnieje trójwarstwowy test prywatności. Prywatność płatności pyta, czy rachunek można powiązać z banknotem finansującym lub osobą. Prywatność sieciowa pyta, czy usługa może zidentyfikować połączenie na podstawie adresu IP, czasu lub cech urządzenia. Prywatność treści pyta, czy ktokolwiek obsługujący model może przeczytać zapytanie. zkAPI jest zaprojektowane głównie dla pierwszej warstwy. Może zmniejszyć powiązanie na poziomie konta między dziennikiem użycia dostawcy modelu a źródłem płatności użytkownika. Nie zapewnia jednak samodzielnie pozostałych dwóch.

Nie jest to wada ukryta drobnym drukiem. Samo ogłoszenie projektu mówi, że dostawca widzi żądania. Uczciwy opis jest silniejszy niż rozbudowane hasło anonimowości, ponieważ mówi użytkownikom, na czym powinni skupić dodatkowe środki ostrożności. Osoba, która używa usługi do zadawania ogólnych pytań, może zyskać znaczną niepowiązalność płatności. Osoba, która wkleja podpisaną umowę i pełne imię i nazwisko, ujawniła tożsamość w treści niezależnie od drogi płatności.

Zbiór anonimowości może być mały nawet przy solidnych dowodach

Wiedza zerowa może ukryć, który z kilku banknotów zapłacił, ale praktyczny tłum ma znaczenie. Jeśli tylko jeden użytkownik zasili sejf w wąskim oknie czasowym nietypową kwotą depozytu, a po sesji nastąpi równie charakterystyczna wypłata, obserwator może utworzyć prawdopodobną korelację na podstawie publicznego czasu i kwot. Dowód może pozostać kryptograficznie ważny i nieprzerwany. Wnioskowanie z informacji zewnętrznych to odrębny atak.

Drzewo o 32 poziomach to parametr pojemności w projekcie, a nie dowód, że miliardy różnych użytkowników mieszają dziś swoje kredyty. Nowo uruchomiona usługa może mieć niewielki zestaw zasilonych banknotów. Aby ocenić anonimowość w praktyce, potrzebne byłyby datowane liczby depozytów, różnych aktywnych banknotów i wzorców wypłat, z agregacją dbającą o prywatność. Repozytorium lub teoretyczny rozmiar drzewa nie dostarczają tych liczb.

Załóżmy, że dziesięć not jest kwalifikowanych do sesji, a publiczne fakty wykluczają dziewięć z nich. Dowód matematyczny może nadal doskonale ukrywać swojego świadka, podczas gdy otaczające informacje wskazują na dziesiątą. Ten zabawkowy przykład wyjaśnia, dlaczego rozmiar i różnorodność prawdopodobnego zbioru mają większe znaczenie niż surowa liczba transakcji w skarbcu. Standaryzacja kwot, opóźniona aktywność i regularne użytkowanie mogą pomóc, ale zachowanie użytkownika i projekt usługi określają, co jest dostępne do korelacji.

Istnieje drugi rodzaj zbioru u dostawcy AI: grupa żądań współdzielących krótkotrwały klucz. Klucz może łączyć żądania w ramach swojej ograniczonej sesji, nawet jeśli nie może zidentyfikować depozytu. Jest to nieodłączne przy mierzeniu sesji. Jeśli klient wielokrotnie wysyła te same dokumenty w późniejszych sesjach, dostawca może je również połączyć między kluczami. Ukrycie konta rozliczeniowego jest cenne, ale nie zmusza dostawcy do zapomnienia tego, co przeczytał.

Narysuj zapisy dla pojedynczej sesji, nie zakładając, że ktokolwiek oszukuje. Ethereum rejestruje transakcję depozytu i jej adres finansujący. Urządzenie użytkownika zachowuje sekret noty i wysyła dowód do serwera płatności. Serwer rejestruje ważność dowodu, nullifier i zdarzenie emisji dla ograniczonego klucza. Dostawca modelu rejestruje ten klucz, żądania i wykorzystanie, za które naliczył opłatę. Podpisany paragon wiąże klucz z zmierzonym totalem. Przy zamknięciu kontrakt może zarejestrować wyjście. Każda strona ma częściowy rejestr.

Zamierzoną właściwością prywatności jest to, że żaden pojedynczy uczciwy rejestr strony nie łączy bezpośrednio adresu finansującego z podpowiedziami dostawcy. Koalicja, wyciek danych lub zewnętrzny obserwator z znacznikami czasu może mieć więcej informacji. Jeśli użytkownik wpłaca nietypową kwotę i natychmiast wysyła pojedyncze nietypowe żądanie, korelacja zdarzeń może stać się łatwiejsza. Jeśli dostawca otrzyma dokument identyfikujący użytkownika, może wiedzieć, kto zapytał, mimo że nigdy nie widział adresu skarbca. Jest to problem kompozycji, a nie nieudany dowód zerowej wiedzy.

Ćwiczenie z rejestrem ujawnia również znaczenie czasów życia kluczy. Poświadczenie sesji celowo grupuje wszystkie żądania, które autoryzuje, aby dostawca mógł je mierzyć. Limit 50 USD może pozwolić na wiele podpowiedzi pod jednym kluczem. Niższe limity i krótsze sesje mogą zmniejszyć ilość treści powiązanych w ramach jednego poświadczenia, ale wymagają częstszych dowodów i mogą zwiększyć opóźnienia lub koszty. Nie ma uniwersalnie prywatnego ustawienia; użytkownik i dostawca wybierają między wygodą, kosztem a możliwością powiązania.

Publiczny model zagrożeń powinien dokładnie określać, które zapisy są przechowywane i jak długo. Powinien mówić, czy serwer rejestruje źródłowe adresy IP podczas składania dowodu, czy przechowuje nullifiery bezterminowo i czy dostawca może powiązać identyfikatory paragonów z treścią żądania po rozliczeniu. Usunięcie nazwy rozliczeniowej z bazy danych jest pomocne. Jest niewystarczające, jeśli trwały identyfikator urządzenia po cichu odtwarza ten sam profil.

Podpisany paragon użycia przenosi zaufanie do pomiaru

Dostawca lub serwer potrzebuje sposobu na pobranie opłaty za faktycznie wykonaną pracę. Projekt wykorzystuje podpisany paragon powiązany z krótkotrwałym kluczem i jego użyciem. Przenosi to centralne pytanie komercyjne na dokładność pomiaru. Jeśli dostawca zawyża liczbę tokenów, żądań lub czas, ważny dowód płatności nie może poprawić podstawowego rachunku. Podpis sprawia, że stwierdzona suma jest trudna do przepisania później; nie ustala, że stwierdzone użycie było sprawiedliwe zgodnie z cennikiem dostawcy.

Klient powinien zapytać, jaka jednostka jest rozliczana, kto podpisuje paragon, jak uwalniana jest niewykorzystana rezerwacja i co się dzieje, gdy żądanie zawiedzie w połowie. To zwykłe pytania rozliczeniowe w nietypowym kryptograficznym przebraniu. Limit ogranicza rozmiar nieoczekiwanej opłaty w jednej sesji, ale wiele małych sesji może nadal narosnąć do znacznych kosztów. Limity szybkości i faktury mogą wymagać procesu rozstrzygania sporów chroniącego prywatność.

Kompromis jest operacyjny. Tradycyjne konta API upraszczają obsługę klienta, zwroty i dochodzenia w sprawie nadużyć, ponieważ dostawca może zidentyfikować nabywcę. zkAPI usuwa trwałą tożsamość rozliczeniową z zamierzonej ścieżki płatności. Dostawcy mogą nadal potrzebować kontroli nadużyć, screeningu sankcji tam, gdzie ma to zastosowanie, i egzekwowania użycia. Fundacja twierdzi, że ceny i limity szybkości mogą pozostać, ale rzeczywiste integracje pokażą, jak usługi równoważą płatności bez konta ze swoimi obowiązkami i kontrolami oszustw.

Jednym praktycznym testem jest celowo przerwana sesja. Klient otrzymuje ograniczony klucz, wykonuje kilka żądań, traci dostęp do sieci i później ponownie się łączy. Czy paragon odzwierciedla tylko dostarczone użycie? Czy użytkownik może lokalnie zweryfikować zmierzoną kwotę bez wysyłania podpowiedzi do serwera płatności? Jeśli serwer zniknie, czy użytkownik może odzyskać niewykorzystane saldo poprzez kontrakt, jak reklamowano? Te testy wykraczają poza to, czy dowód weryfikuje się, do tego, czy produkt zachowuje obiecaną separację w przypadku awarii.

Kontrakt onchain jest drogą ucieczki, a nie tarczą prywatności

Zgodnie z Fundacją, kontrakt skarbca może weryfikować dowody dla operacji depozytu, zamknięcia i ucieczki. Trasa wyjścia onchain ma znaczenie, ponieważ zamknięcie dostawcy nie powinno pozostawiać środków użytkownika uwięzionych w bazie danych operatora. Kontrakt zastępuje część zaufania instytucjonalnego ryzykiem smart-kontraktu. Błąd w weryfikacji dowodów, księgowaniu lub logice wypłat może wpłynąć na środki pomimo solidnej koncepcji prywatności. Aktywny adres jest dowodem wdrożenia, a nie certyfikatem audytu.

Publiczne depozyty i wypłaty również mają koszt prywatności. Ktoś, kto zna adres finansowania użytkownika, może zaobserwować, że wchodził on w interakcję ze skarbcem. Może nie widzieć, za którą sesję API zapłacono, ale może zobaczyć uczestnictwo i kwoty. Jeśli ten sam użytkownik szybko wypłaci nietypową kwotę na adres już z nim powiązany, część otaczającej anonimowości może się zmniejszyć. Prywatna nota zrywa deterministyczne powiązanie rozliczeniowe; nie usuwa publicznej transakcji finansowania.

Projekt ma korzenie w projekcie Ethereum Research dotyczącym kredytów API o wiedzy zerowej, który Fundacja identyfikuje jako pracę Davide Crapisa i Vitalika Buterina. Propozycja badawcza i system produkcyjny odpowiadają na różne pytania. Pierwsza przedstawia konstrukcję; drugi musi obsługiwać przechowywanie kluczy, zachowanie front-endu, awarie, spory dotyczące paragonów, aktualizacje i rzeczywistych przeciwników. Wydanie z 1 października przenosi ten pomysł do testowalnego wdrożenia i to jest istotny świeży haczyk.

Szersze wysiłki Ethereum na rzecz prywatności to nie ten sam produkt. Relacja Crypto.news o proponowanym natywnym projekcie prywatności dotyczy projektu zmiany protokołu, podczas gdy zkAPI to aplikacja działająca teraz. Niedawne uruchomienie portfela zk.money dotyczy prywatnych transferów w innym środowisku. Żadnego z nich nie należy cytować jako dowodu, że prompt AI wysłany przez zkAPI jest ukryty przed dostawcą modelu.

Twierdzenia o prywatności powinny przetrwać powtarzalny test

Niezależny recenzent mógłby utworzyć dwie finansowane noty z niepowiązanych adresów, przeprowadzić krótkie sesje z tym samym dostawcą modelu i zbadać każdy pakiet oraz log widoczny dla klienta, serwera płatności i dostawcy. Recenzent powinien przetestować tryby bezpośredni i proxy oddzielnie. Jeśli serwer płatności w trybie bezpośrednim otrzymuje prompt, jest to sprzeczne z opisanym rozdziałem. Jeśli dostawca otrzymuje adres depozytu lub trwały identyfikator konta rozliczeniowego, zamierzona niepowiązalność zawiodła na warstwie integracji, nawet jeśli obwód dowodu jest solidny.

Trudniejszy test jest statystyczny. Przeprowadź wiele sesji o zróżnicowanych kwotach i czasie, a następnie zapytaj, czy strona mająca tylko publiczne dane łańcucha i logi serwera może skorelować finansowanie i użycie lepiej niż losowo. Benchmark zależy od rzeczywistego zbioru anonimowości i tego, jakie dane pomocnicze ma przeciwnik. Udana mała demonstracja laboratoryjna nie ustala prywatności przy malutkiej bazie użytkowników produkcyjnych, ale tworzy metodę pomiaru, czy wdrożenia poprawiają się z czasem.

Test treści jest prosty i trzeźwiący. Prześlij ten sam charakterystyczny dokument pod dwoma świeżymi kluczami sesji. Jeśli dostawca może go rozpoznać w obu, niepowiązalność płatności nie dała użytkownikowi niepowiązalności rozmowy. Twierdzenie o płatności powinno być oceniane przez dwa pierwsze testy; twierdzenie o anonimowym korzystaniu z AI musi również przetrwać trzeci. Opublikowanie trybu, modelu zagrożeń i wyników pozwoliłoby użytkownikom wybrać właściwe narzędzie do ich rzeczywistego problemu.

Najsilniejszym argumentem jest odłączenie rozliczeń od użytecznej treści

Istnieje wiele uzasadnionych powodów, aby zadać dostawcy AI wrażliwe pytanie bez budowania trwałego dossier użycia powiązanego z kontem. Dziennikarz testujący publiczny dokument, badacz zgłębiający kontrowersyjną hipotezę lub deweloper używający API wewnątrz agenta mogą chcieć, aby dostawca widział bieżące żądanie, jednocześnie przerywając trwałą relację rozliczeniową. Projekt zkAPI odpowiada na tę węższą potrzebę. Pozwala również maszynie płacić za usługi rozliczane bez zarządzania długotrwałym osobistym kontem dla każdego żądania.

Argument przeciw nadmiernym twierdzeniom jest równie silny. Dostawcy nadal widzą prompty, a niektóre prompty z konieczności ujawniają tożsamość. Przedsiębiorstwo z surowymi wymogami poufności może potrzebować kontroli umownych, modeli lokalnych lub przetwarzania poufnego, a także niepowiązalności płatności. Niektórzy użytkownicy mogą preferować zwykłe konto z ugruntowanym wsparciem i zwrotami niż kryptograficzną warstwę płatności, której mechanizmy rozstrzygania sporów są wciąż niedojrzałe. Wybór zależy od rzeczywistego modelu zagrożeń.

Omawiany przez crypto.news plan prywatności Ethereum przedstawia prywatność jako szerszy cel. Plan nie przyznaje jednak swoich przyszłych zabezpieczeń tej aplikacji już dziś. Użytkownik AI musi ocenić rzeczywistą ścieżkę klienta i dostawcy, która faktycznie obsługuje prompt.

Crypto.news wyjaśnił węższą mechanikę dowodów wiedzy zerowej w osobnym wprowadzeniu. Dowód ujawnia określony fakt bez ujawniania świadka; nie jest uniwersalnym płaszczem niewidzialności. Wywiad na temat infrastruktury Ethereum skoncentrowanej na prywatności podkreśla, jak różne produkty chronią różne dane. Użytecznym pytaniem dla zkAPI jest to, która strona widzi który zapis na każdym etapie, a nie czy projekt kwalifikuje się do szerokiego słowa „prywatny”.

Najlepszym dowodem przeciwnym wobec sceptycznej interpretacji byłoby mierzone użycie bez trwałego powiązania tożsamości, jasne etykiety trybów, niezależny przegląd bezpieczeństwa i opublikowany model zagrożeń obejmujący IP, telemetrię przeglądarki i potwierdzenia. Najlepszy dowód przeciwny wobec ekspansywnego twierdzenia marketingowego znajduje się już w poście Fundacji: dostawca widzi prompt. Obie obserwacje mogą być prawdziwe jednocześnie.

Fundacja wymienia płatności API typu maszyna-do-maszyny jako możliwe zastosowanie. Autonomiczny agent może wysłać setki wywołań, używając jednego zasilonego nota lub wielu krótkich sesji. Jeśli jego zadania zawierają dane klientów, dostawca modelu może dowiedzieć się o tych klientach, nawet gdy źródło płatności agenta pozostaje prywatne. Korzyść z prywatności należy do powiązania rozliczeniowego; nie powinna być przenoszona na każdego podmiot wymieniony w żądaniu.

Agent potrzebuje również kontroli budżetu. Limit na klucz ogranicza jedną sesję, ale pętla może uzyskać powtarzane klucze, aż not zostanie wyczerpany, chyba że klient egzekwuje szerszą politykę wydatków. Operator powinien zdefiniować limit dzienny lub na poziomie zadania, alerty oraz kontrolę wstrzymania niezależną od dowodu kryptograficznego. Dowód weryfikuje autoryzowany kredyt, a nie to, czy wywołanie agenta było konieczne lub ekonomiczne.

Gdy kilka agentów dzieli jedną pulę kredytów, wewnętrzna księgowość może stać się ukrytym systemem rozliczeniowym. Operator może potrzebować przypisać opłaty do zespołów lub klientów bez eksportowania ich tożsamości do dostawcy API. Można to zrobić za pomocą lokalnego rejestru, ale tworzy to kolejny wrażliwy zbiór danych, który trzeba chronić. Przejście z rozliczania kont na rozliczanie not nie znosi uzgadniania; ono je przenosi.

Wreszcie agent może ujawnić się poprzez zachowanie. Powtarzane wywołania według tego samego harmonogramu, te same nagłówki narzędzi i te same frazy specyficzne dla zadania mogą sprawić, że osobne krótkotrwałe klucze staną się łatwe do zgrupowania. Ukrycie noty finansowania onchain jest przydatne przeciwko nadzorowi płatności. Nie jest jednak obroną przed odciskiem behawioralnym, który agent wysyła z każdym żądaniem.

Wdrożenie nadal wymaga audytu modelu zagrożeń

Na dzień 2 października Fundacja twierdzi, że kod, serwer, klient i skarbiec są aktywne. Post zawiera link do kontraktu mainnet i repozytorium. Nie publikuje w ogłoszeniu ostatecznej liczby użytkowników, audytowanej całkowitej wartości, wszystkich integracji zewnętrznych ani gwarancji, że każda konfiguracja klienta używa bezpośredniego trybu klucza wykonawczego. Ta funkcja nie twierdzi, że miało miejsce naruszenie lub niewłaściwe zachowanie nazwanego dostawcy. Wskazuje informacje, które każda strona ma otrzymywać, oraz dodatkowe wycieki, które uznają autorzy projektu.

Zewnętrzna ocena powinna zbadać domyślne ustawienia klienta i połączenia wychodzące. Czy demonstracja w przeglądarce wysyła telemetrię do niepowiązanych domen? Czy lokalny klient przechowuje klucze lub dzienniki promptów? Czy serwer płatności może połączyć znaczniki czasu wystawienia z adresami sieciowymi? Czy potwierdzenia są łączliwe między sesjami? Jak zarządza się aktualizacjami obwodów i kontraktów? Dowód może być matematycznie poprawny, podczas gdy interfejs użytkownika przypadkowo ujawnia tożsamość, którą miał oddzielić.

Ta sama ocena powinna przetestować widok dostawcy AI. Zobaczy on treść, którą przetwarza, oraz poświadczenie sesji. Może gromadzić metadane urządzenia lub sieci w zależności od ścieżki żądania. Polityka retencji danych dostawcy i wszelkie warunki umowne pozostają kluczowe. Warstwa płatności może zmniejszyć jedno źródło informacji identyfikujących, nie ograniczając wszystkich pozostałych.

zkAPI stanowi prawdziwy postęp, jeśli w sposób niezawodny uniemożliwia dostawcy modelu powiązanie użytecznych żądań z kontem rozliczeniowym, zachowując jednocześnie możliwość odzyskania środków przez użytkownika. Rozczaruje każdego, kto oczekuje prywatnej rozmowy tylko dlatego, że płatność została udowodniona w dowodzie wiedzy zerowej. Te dwa twierdzenia należy oceniać osobno.

Na co zwrócić uwagę

• Oznaczanie trybu: Sprawdź, czy każdy klient uwidacznia bezpośredni klucz środowiska uruchomieniowego lub routing przez proxy, zanim użytkownik wyśle polecenia.
• Aktywność w mainnecie: Szukaj opatrzonych datami liczb sfinansowanych not i użycia, raportowanych bez naruszania anonimowości użytkowników.
• Przeglądy bezpieczeństwa: Przeczytaj zakres niezależnych ocen obejmujących wyjścia z kontraktów, obwody dowodowe, przechowywanie po stronie klienta i rozliczanie pokwitowań.
• Kontrole metadanych: Przetestuj obsługę adresów IP, telemetrię, czasy życia kluczy i retencję u dostawcy w rzeczywistych integracjach.
• Spory rozliczeniowe: Sprawdź, jak obsługiwane są nieudane żądania, zwolnienie limitu i kwestionowane pokwitowania bez wymuszania ujawnienia tożsamości.

FAQ