Ich habe heute halb zugesehen, wie ein Freund ein neues Wallet eingerichtet hat. Ich habe ihn währenddessen am Telefon durch alles geführt, während ich an meinem Schreibtisch übrig gebliebenes Pad Thai gegessen habe. Er hat ständig gesagt: „Also solange der Code sicher ist, ist doch alles gut, oder?“ Und ich hab dann einfach gesagt: ja, im Grunde, klar — die übliche Reflexantwort, die alle geben. Dann hab ich aufgelegt und weiter darüber nachgedacht, was nervig ist, weil es eigentlich ein kurzer Anruf sein sollte.
Also habe ich am Ende statt dem, was ich geplant hatte, wieder in den Docs von Newton Protocol gelandet—genauer gesagt bei dem Teil darüber, wie deren Operator-Netzwerk Policy-Checks attestiert. Und der Gedanke, der klick gemacht hat, ging gar nicht darum, dass Newton gut oder schlecht ist. Es war dieses hier — „Vertraue dem Code“ war nie wirklich das, was irgendwer von uns gemacht hat. Niemand liest den Bytecode. Niemand prüft den Vertrag selbst. Du vertraust darauf, dass jemand anderes das getan hat, oder dass genug Zeit vergangen ist, ohne dass es einen Exploit gab—also dass es wahrscheinlich schon okay ist. „Code ist Gesetz“ war immer nur ausgelagerter Vertrauensvorschuss, der ein vertrauensloses Kostüm trägt.
Das hat mich dazu gebracht, Newtons kompletten Pitch anders zu betrachten. Es ist nicht so, dass hier wirklich Vertrauen zu Berechtigungen hinzugefügt wird. Was es macht, ist, das Vertrauen dorthin zu verlagern, wo man es tatsächlich sehen kann. Anstatt blind darauf zu vertrauen, dass ein Vertrag stillschweigend alles richtig macht, bekommst du ein Operator-Netzwerk — wirtschaftlich gestaked, slashbar — das bestätigt, dass eine Policy geprüft und bestanden wurde, sichtbar auf dem Newton Explorer. Also verschwindet das Vertrauen nicht, es verlagert sich nur von „Ich hoffe, dieser Vertrag ist in Ordnung“ zu „Ich vertraue einer gebundenen Menge von Operatoren, dass sie das korrekt geprüft haben, und ich kann nachprüfen, dass sie es getan haben.“
Das ist die Annahme, die Menschen in solche Dinge mitnehmen — dass Newton Berechtigungen endlich vertrauenslos macht und das Problem damit endgültig löst. Was tatsächlich passiert, ist eher: Es macht das Vertrauen nachvollziehbar statt implizit. Du vertraust immer noch jemandem. Du bekommst nur jetzt Belege.
Aber der Teil, der mich stört: Ich bin beim Schreiben zweimal hin und her gegangen — nachvollziehbares Vertrauen bleibt Vertrauen. Wenn der Operator-Set kolludiert, oder wenn sich genügend Anteil auf ein paar wenige Hände konzentriert, dann hast du den Ausfallmodus nicht entfernt, sondern nur geändert, worauf du angewiesen bist, und dazu eine Protokollkette für den Fall ergänzt, dass es schiefgeht. Diese Protokollkette ist wirklich nützlich, ich will sie nicht schlechtreden. Aber „verifizierbar“ und „sicher“ sind nicht dasselbe Wort, und ich glaube, das Marketing nutzt diese Überlappung ein wenig stärker, als das Mechanismus wirklich hergibt. Slashing schreckt schlechtes Verhalten ab, verhindert es nicht vollständig — frag jemanden, der gesehen hat, wie ein Slashing-Vorfall passiert, nachdem der Schaden bereits angerichtet war.
Ich habe darüber noch einmal nachgedacht, als mir die exakte Frage meines Freundes wieder eingefallen ist — „solange der Code sicher ist, ist doch alles gut, oder?“ — und tatsächlich, nein. Sicherer Code plus ein bösartiger Signer, sicherer Code plus ein kompromittierter Schlüssel, sicherer Code plus eine Berechtigung, an die sich niemand erinnert hat, zweimal zu prüfen … das wird durch „dass der Code in Ordnung ist“ nicht behoben. Es wird behoben, wenn es überhaupt behoben wird, durch etwas, das die Berechtigung selbst kontinuierlich im Blick hat — das ist die eigentliche Lücke, in die Newton hineinzustehen versucht. Das ist eine engere und ehrlicheren Aussage als „Vertraue dem Code“, und seltsamerweise finde ich die engere Version überzeugender als die große Behauptung.
Für wen das tatsächlich relevant ist, denke ich, ist weniger der typische „degen“ da, der um 2 Uhr morgens auf „Approve“ klickt, und mehr der Builder, der entscheiden muss, ob er eine Regel für immer fest in einen Smart Contract hardcodet oder sie stattdessen über etwas laufen lässt, das jedes Mal geprüft, aktualisiert und bezeugt werden kann. Ob das zum Standard-Instinkt wird oder eher eine Nischenpraxis für institutionelle Integrationen bleibt — das weiß ich ehrlich gesagt noch nicht. Fühlt sich in jedem Fall früh an.
Wie auch immer. Ich denke immer noch über den Ausdruck „Code is law“ nach und darüber, wie beiläufig wir ihn alle wiederholen, ohne ihn wörtlich zu meinen. Die Wallet meines Freundes ist jedenfalls korrekt eingerichtet. Ich habe nur meinen Pad Thai nicht fertig gegessen.