Ich habe vor ein paar Abenden durch einige der neueren Diskussionen zur Account-Abstraction bei Ethereum gelesen, und zwar insbesondere rund um die Auslieferung von EIP-7702 mit dem Pectra-Upgrade letztes Jahr. Irgendwo in der Mitte ist mir dann wieder Newton Protocol eingefallen, nicht weil es jemand direkt erwähnt hätte, sondern weil ein konkretes Problem immer wieder auftauchte, das Newton auf eine Weise gelöst zu haben scheint, die ich zuvor nicht vollständig gewürdigt hatte. Die zentrale Spannung in jedem Delegationsmodell wirkt täuschend einfach: Wenn du einem anderen Schlüssel die Erlaubnis gibst, in deinem Namen zu handeln, wie stellst du sicher, dass er nur genau das tut, was du beabsichtigt hast, und nichts darüber hinaus? Die meisten Implementierungen für Smart Accounts lösen das über Session Keys: temporäre Zugangsdaten mit begrenzten, an sie gebundenen Berechtigungen. Die Bindung wird dabei typischerweise auf Vertragsebene auf einer einzelnen Kette durchgesetzt – und zwar anhand der Logik, die der Wallet-Entwickler geschrieben hat. Was Newton offenbar anders macht, ist, diese Grenzen in einen Zero-Knowledge-Ziruit einzubetten: eine zkPermission, bevor der Session Key überhaupt ausgegeben wird. Dadurch ist die Einschränkung nicht nur eine Regel, die irgendwo in einem Vertrag niedergeschrieben wurde, sondern eine kryptografische Eigenschaft des Schlüssels selbst.
Interessant erscheint mir, wie stark diese Unterscheidung in der Praxis ins Gewicht fällt, wenn man versucht, die Fehlerfälle statt nur den „Happy Path“ zu durchdenken. Ein Standard-Session-Key-Ansatz ist nur so vertrauenswürdig wie die Implementierung des Vertrags, der seinen Geltungsbereich durchsetzt. Wenn der Entwickler in dieser Logik einen Fehler gemacht hat oder wenn es einen Sonderfall gibt, der nicht bedacht wurde, als die Berechtigungen definiert wurden, könnte der Key potenziell auf eine Art verwendet werden, die zwar technisch die Validierung besteht, aber das verletzt, was die Nutzerin oder der Nutzer eigentlich beabsichtigt hat. Ein zkPermission-Zircut hingegen kodiert die Automatisierungsregel als mathematische Einschränkung und beweist, dass jede gegebene Aktion sie erfüllt, bevor die Ausführung fortgesetzt wird. Ich frage mich manchmal, ob die meisten Menschen, die über Agent-Delegation in DeFi sprechen, diese Unterscheidung wirklich sorgfältig durchdacht haben, denn aus Sicht des Nutzervertrauens sind diese beiden Modelle inhaltlich deutlich verschieden — selbst wenn sie bei oberflächlicher Betrachtung ähnlich wirken, solange alles richtig läuft. Der Unterschied zeigt sich genau dann, wenn etwas schiefgeht oder wenn jemand aktiv versucht, die Grenzen dessen auszunutzen, was einem Agent erlaubt ist zu tun.
Der Teil, den ich in meinem Denken noch nicht vollständig geklärt habe, betrifft die Nutzererfahrung bei der Definition dieser zkPermission-Einschränkungen an sich. Zero-Knowledge-Zircuits sind ausdrucksstark und mathematisch streng, aber sie sind auch berüchtigt dafür, auf Spezifikationsebene schwierig zu handhaben. Die Frage, die mir dabei in den Sinn kommt, ist: Was passiert eigentlich, wenn eine normale Nutzerin oder ein normaler Nutzer, also kein Entwickler, versucht, eine differenzierte Berechtigung auszudrücken wie „nur dieses Asset handeln, wenn der Preis über einer bestimmten Schwelle liegt, und nur zwischen diesen Stunden, und niemals mehr als diesen Prozentsatz meines Guthabens in einer einzigen Transaktion“. Eine solche Form menschlicher Intention präzise in einen Zircut zu übersetzen, ohne versehentlich entweder zu restriktiv oder zu permissiv zu werden, wirkt wie ein wirklich schweres Problem des Interface-Designs, das „vor“ der gesamten kryptografischen Eleganz liegt. Newtons VaultKit SDK ist dafür entworfen, das für Entwickler zu abstrahieren, aber ich bin nicht ganz sicher, wie weit diese Abstraktion in Richtung Endnutzer reicht, die keinerlei Interesse daran haben, sich mit Zircut-Einschränkungen zu beschäftigen.
Von außen betrachtet gibt es außerdem eine größere Timing-Frage, zu der ich immer wieder zurückkehre. Newton baut auf sowohl ERC-4337 als auch EIP-7702 auf, die zusammen die Landschaft sowohl für speziell entwickelte Smart Accounts als auch für die Hunderte Millionen existierender extern verwalteter Wallets abdecken, die EIP-7702 nun mit Smart-Account-Verhalten nachrüsten kann, ohne dass eine Migration erforderlich ist. Das ist theoretisch eine enorme adressierbare Fläche, aber die praktische Einführung dieser Standards ist über Wallets, Chains und Entwickler-Tooling hinweg noch immer uneinheitlich. Das Delegations- und Autorisierungsmodell von Newton ist am stärksten, wenn die darunterliegende Wallet-Schicht bereits smart-account-nativ ist, und diese Voraussetzung wird zwar allmählich wahr, aber ist noch nicht bereits universell gegeben. Ob sich die Abstraktionslandschaft der Wallets schnell genug weiterentwickelt, um Newtons Infrastruktur in der Mitte zu treffen, oder ob Newton am Ende mehr von dieser Brücke selbst bauen muss, wirkt wie eine dieser stillen Abhängigkeiten, die in der Dokumentation nicht auffällt, aber die tatsächliche Einführungskurve mehr als fast alles andere prägt — na ja, die Zeit wird es zeigen💻