przechodziłem przez notatki na temat midnight i… myślę, że początkowo źle zrozumiałem, co próbowali zrobić. Założyłem, że to kolejna konfiguracja „transakcji z zabezpieczeniem + dowody zk”. Jakby, wziąć normalny łańcuch i dodać prywatność na wierzchu. Ale im więcej na to patrzę, tym bardziej czuję, że traktują zk jako powierzchnię kontrolną nad danymi, a nie tylko jako narzędzie ukrywania.
i zgaduję, że to tam, gdzie wspólna narracja się łamie. Większość ludzi słyszy „łańcuch prywatności” i myśli w kategoriach ukrywania sald, adresów, może danych wejściowych kontraktu. Ale midnight wydaje się dążyć do selektywnego ujawnienia jako podstawowego elementu. Nie tylko ukrywania danych, ale strukturyzowania, jak mogą być ujawniane w różnych kontekstach.
pierwsza rzecz, która się wyróżnia, to jak wbudowują logikę dostępu w same dowody. więc zamiast tego, aby kontrakty sprawdzały uprawnienia w zwykłym wykonaniu, dowód zk koduje "to obliczenie jest ważne i ujawnia tylko te wyniki." co jest dość eleganckie, ale także przenosi złożoność do projektowania obwodów. już nie tylko dowodzisz poprawności — dowodzisz zgodności z polityką. to cięższe obciążenie. i nie jestem do końca pewien, jak ergonomiczne to jest dla deweloperów, chyba że dobrze to abstrahują.
potem jest pomysł zaszyfrowanego stanu z kontrolowanym przez użytkownika dostępem. myślę, że stąd pochodzi narracja o "własności danych". użytkownicy mają klucze, które określają, kto może widzieć co. brzmi prosto, ale w praktyce zarządzanie cyklem życia kluczy zawsze jest skomplikowane. powiedzmy, że użytkownik dzieli się dostępem z aplikacją, a potem później chce go cofnąć — czy ponownie szyfrują stan? zmieniają klucze? polegają na dowodach czasowych? każda opcja wprowadza pewną złożoność do protokołu lub warstwy aplikacji.
model wykonania to miejsce, w którym wciąż jestem nieco niepewny. jeśli większość wrażliwej logiki dzieje się wewnątrz obwodów zk, to wykonanie jest efektywnie podzielone: dowodzenie off-chain + weryfikacja on-chain. co oznacza, że dowodzący stają się kluczowymi aktorami. może także relayerzy, w zależności od tego, jak są składane transakcje. nie widzę jeszcze w pełni rozwiniętego modelu motywacyjnego dla tego. na przykład, czy dowodzący są po prostu opłacani za pomocą opłat? czy istnieje rynek? czy zakłada się, że dostawcy infrastruktury wypełnią tę rolę na początku?
walidatorzy, tymczasem, wydają się prawie drugorzędni — weryfikują dowody i utrzymują konsensus, ale nie wykonują ciężkich obliczeń. to w porządku, ale tworzy asymetrię, gdzie poprawność zależy od małego zestawu zdolnych dowodzących, nawet jeśli weryfikacja jest zdecentralizowana.
Ciekawe (i może niedostatecznie omawiane) jest to, jak wszystkie te komponenty zależą od siebie dość ściśle. selektywna ujawnienie działa tylko jeśli:
* obwody zk są wystarczająco ekspresywne
* zarządzanie kluczami jest użyteczne
* wykonanie pozostaje deterministyczne mimo ukrytego stanu
jeśli jedna z tych rzeczy się zepsuje, cały model się degraduje. na przykład, jeśli obwody są zbyt sztywne, tracisz elastyczność. jeśli zarządzanie kluczami jest toporne, użytkownicy nie będą faktycznie kontrolować niczego. jeśli założenia dotyczące wykonania się załamują, kompozycyjność ucierpi.
i kompozycyjność… to kolejny znak zapytania. jeśli kontrakt A przekazuje częściowo ujawnione dane do kontraktu B, jakie gwarancje istnieją co do tego, jak B je wykorzystuje? czy protokół egzekwuje ograniczenia w dół, czy to pozostawione deweloperom? bo jeśli to drugie, można łatwo skończyć z przypadkowym wyciekiem danych.
istnieje również domniemanie, że deweloperzy są gotowi myśleć w kategoriach projektowania natywnego dla zk. nie tylko pisanie kontraktów, ale projektowanie obwodów, rozumienie widoczności, zarządzanie granicami dowodów. to wyższe obciążenie poznawcze niż większość obecnych ekosystemów wymaga.
pod względem harmonogramu, wydaje się, że północ opiera się na narzędziach zk, które doganiają. szybsze dowodzące, lepsze DSL dla obwodów, może standardowe wzorce dla kontroli dostępu. bez nich system staje się wolny lub wrogi dla deweloperów.
ciągle wracam do prostego scenariusza: użytkownik dowodzi uprawnienia (powiedzmy, zdolności kredytowej lub atrybutów tożsamości) do wielu dapps, z różnymi wymaganiami ujawnienia. koordynacja tego w ramach kontraktów bez duplikowania dowodów lub ujawniania danych wydaje się niebanalna. może mają czyste rozwiązanie, ale jeszcze tego nie widziałem wyraźnie.
więc tak... jestem zaintrygowany, ale też nieco ostrożny. to złożony problem — prywatność, wykonanie, kontrola dostępu — wszystko ze sobą powiązane.
obserwując:
* czy rynek dowodzących/relayerów faktycznie się formuje, czy pozostaje scentralizowany
* jak narzędzia deweloperskie abstrakcyjne złożoność obwodu (jeśli w ogóle)
* prawdziwe aplikacje wykorzystujące selektywne ujawnienie poza prostymi kontrolami tożsamości
* jak radzą sobie z cofnięciem uprawnień bez ciężkiego ponownego szyfrowania
wydaje się, że to albo staje się bardzo wyspecjalizowanym stosem dla określonych przypadków użycia... albo zmusza do przemyślenia, jak całkowicie projektujemy kontrakty. nie jestem jeszcze pewien, w którą stronę to idzie.
