Ich habe einige Notizen zu Midnight durchgesehen und... ich denke, ich habe anfangs missverstanden, was sie zu tun versuchten. Ich nahm an, es sei ein weiteres "geschützte Transaktionen + zk Beweise"-Setup. Wie, nimm eine normale Kette und füge oben drauf Privatsphäre hinzu. Aber je mehr ich mir das anschaue, desto mehr fühlt es sich so an, als würden sie zk als eine Steuerungsebene über Daten behandeln, nicht nur als ein Werkzeug zur Verschleierung.
Und ich schätze, das ist der Punkt, an dem die gängige Erzählung zusammenbricht. Die meisten Leute hören "Privatsphäre-Kette" und denken in Bezug auf das Verstecken von Salden, Adressen, vielleicht Vertragsinputs. Aber Midnight scheint darauf abzuzielen, selektive Offenlegung als erste Klasse zu betrachten. Nicht nur Daten zu verstecken, sondern zu strukturieren, wie sie in verschiedenen Kontexten offenbart werden können.
Das erste Stück, das auffällt, ist, wie sie Zugriffslogik in die Beweise selbst einbetten. Anstatt dass Verträge Berechtigungen in einer klaren Ausführung überprüfen, kodiert der zk-Beweis "diese Berechnung ist gültig und gibt nur diese Ausgaben preis." Das ist irgendwie elegant, verschiebt aber auch die Komplexität in das Design der Schaltkreise. Sie beweisen nicht mehr nur die Richtigkeit – Sie beweisen die Einhaltung der Richtlinien. Das ist eine schwerere Last. Und ich bin mir nicht ganz sicher, wie ergonomisch das für Entwickler ist, es sei denn, sie abstrahieren es wirklich gut.
Dann gibt es die Idee eines verschlüsselten Zustands mit benutzerkontrolliertem Zugriff. Ich denke, hierher kommt die Erzählung über "Datenbesitz". Benutzer halten Schlüssel, die bestimmen, wer sehen kann, was. Klingt einfach, aber in der Praxis ist das Management des Lebenszyklus von Schlüsseln immer kompliziert. Angenommen, ein Benutzer teilt den Zugriff mit einer App und möchte ihn später widerrufen – verschlüsseln sie den Zustand erneut? Rotieren sie die Schlüssel? Verlassen sie sich auf zeitlich gebundene Beweise? Jede Option bringt einige Komplexität in das Protokoll oder die App-Schicht ein.
Das Ausführungsmodell ist der Bereich, in dem ich noch ein wenig unsicher bin. Wenn der Großteil der sensiblen Logik innerhalb von zk-Schaltkreisen stattfindet, wird die Ausführung effektiv aufgeteilt: Off-Chain-Beweisführung + On-Chain-Überprüfung. Das bedeutet, dass Beweiser zu kritischen Akteuren werden. Vielleicht auch Relayer, je nachdem, wie Transaktionen eingereicht werden. Ich sehe dafür noch kein vollständig ausgearbeitetes Anreizmodell. Wie, werden Beweiser einfach über Gebühren bezahlt? Gibt es einen Markt? Oder wird angenommen, dass Infrastruktur-Anbieter diese Rolle frühzeitig übernehmen?
Validatoren scheinen unterdessen fast sekundär zu sein – sie überprüfen Beweise und erhalten Konsens, aber sie führen keine schweren Berechnungen durch. Das ist in Ordnung, aber es schafft diese Asymmetrie, bei der die Richtigkeit von einer kleinen Gruppe fähiger Beweiser abhängt, auch wenn die Überprüfung dezentralisiert ist.
Was interessant (und vielleicht unterdiskutiert) ist, wie all diese Komponenten ziemlich eng voneinander abhängen. Selektive Offenlegung funktioniert nur, wenn:
* zk-Schaltkreise sind ausreichend ausdrucksstark
* Schlüsselmanagement benutzbar ist
* Ausführung bleibt deterministisch trotz verborgenem Zustand
Wenn eines davon kaputtgeht, verschlechtert sich das gesamte Modell. Wenn zum Beispiel die Schaltkreise zu starr sind, verlieren Sie die Flexibilität. Wenn das Schlüsselmanagement umständlich ist, werden Benutzer tatsächlich nichts kontrollieren. Wenn die Annahmen zur Ausführung brechen, leidet die Komponierbarkeit.
Und Komponierbarkeit… das ist ein weiteres Fragezeichen. Wenn Vertrag A teilweise enthüllte Daten an Vertrag B ausgibt, welche Garantien gibt es dafür, wie B sie verwendet? Erzwingt das Protokoll nachgelagerte Einschränkungen oder bleibt das den Entwicklern überlassen? Denn wenn es letzteres ist, könnte man ziemlich leicht mit versehentlichem Datenleck enden.
Es gibt auch eine implizite Annahme, dass Entwickler bereit sind, in Bezug auf zk-native Design zu denken. Nicht nur Verträge zu schreiben, sondern Schaltkreise zu entwerfen, über Sichtbarkeit nachzudenken und Beweisgrenzen zu verwalten. Das ist eine höhere kognitive Belastung, als die meisten aktuellen Ökosysteme verlangen.
Zeitlich fühlt es sich an, als würde Mitternacht auf zk-Tools setzen, die aufholen. Schnellere Beweiser, bessere DSLs für Schaltkreise, vielleicht standardisierte Muster für den Zugriffskontrolle. Ohne diese wird das System entweder langsam oder entwicklerfeindlich.
Ich komme immer wieder auf ein einfaches Szenario zurück: Ein Benutzer beweist die Berechtigung (sagen wir, Kreditwürdigkeit oder Identitätsmerkmale) für mehrere dapps, jede mit unterschiedlichen Offenlegungsanforderungen. Das Koordinieren dessen über Verträge hinweg, ohne Beweise zu duplizieren oder Daten zu leaken, scheint nicht trivial zu sein. Vielleicht haben sie eine saubere Lösung, aber ich habe sie bisher nicht klar gesehen.
Also ja… ich bin neugierig, aber auch ein wenig vorsichtig. Es ist ein geschichtetes Problem – Datenschutz, Ausführung, Zugriffskontrolle – alles miteinander verwoben.
Beobachtung:
* ob ein Markt für Beweiser/Relayer tatsächlich entsteht oder zentralisiert bleibt
* wie Entwickler-Tools die Komplexität von Schaltkreisen abstrahieren (wenn überhaupt)
* echte Apps, die selektive Offenlegung über einfache Identitätsprüfungen hinaus nutzen
* wie sie die Widerrufung von Berechtigungen ohne schweres erneutes Verschlüsseln handhaben
Es fühlt sich an, als würde dies entweder zu einem sehr spezialisierten Stack für bestimmte Anwendungsfälle werden… oder es zwingt zu einem Umdenken, wie wir Verträge ganz gestalten. Ich bin mir noch nicht sicher, in welche Richtung es geht.
