Cross-Chain-Anwendungen werden zur Grundlage des modernen Web3 und ermöglichen, dass Assets, Nutzer und Protokolle über mehrere Blockchain-Netzwerke hinweg miteinander interagieren. Interoperabilität bringt jedoch auch neue Sicherheitsherausforderungen mit sich. Unterschiedliche Chains unterhalten separate Validator-Sets, Konsensmechanismen und Vertrauensannahmen, wodurch es schwierig wird zu verifizieren, dass eine Cross-Chain-Aktion tatsächlich echt autorisiert ist.
Newton Protocol begegnet dieser Herausforderung mit einem dezentralen Cross-Chain-Autorisierungsframework, das die Sicherheit bewahrt und zugleich eine nahtlose Interoperabilität ermöglicht. Anstatt auf zentrale Bridges oder vertrauenswürdige Relays zu setzen, verwendet Newton ein kryptografisch nachprüfbares Modell, das um EigenLayer-Operatoren, BLS-Signaturen und synchronisierte Operator-Tabellen aufgebaut ist.
Im Zentrum der Architektur von Newton steht das Modell „Source Chain“ und „Destination Chain“. Die Source Chain – etwa Ethereum Mainnet oder Sepolia – ist die Heimat des Operator-Netzwerks. Hier registrieren sich Operatoren, staken Assets, veröffentlichen ihre BLS-öffentlichen Schlüssel und bleiben durch EigenLayer’s Slashing-Mechanismus verantwortlich. Destination Chains, einschließlich Netzwerken wie Base, Arbitrum, Optimism und Polygon, sind dort, wo Anwendungen tatsächlich Transaktionen ausführen und Policy-Entscheidungen durchsetzen.
Anstatt dass jede Destination Chain ständig mit Ethereum kommunizieren muss, synchronisiert Newton Informationen zu Operatoren über ein dezentrales Protokoll zur Synchronisierung der Operatorentabelle.
Wenn sich der Operatorsatz durch neue Registrierungen, Stake-Updates, Deregistrierungen oder Slashing-Ereignisse ändert, erzeugen Newton-Operatoren gemeinsam eine BLS-signierte Merkle-Root, die die aktuellste Operatorentabelle darstellt. Dieses kryptografische Abbild umfasst Operatoridentitäten, öffentliche Schlüssel und Stake-Gewichte in einer bestimmten Blockhöhe.
Jeder kann dieses signierte Snapshot zustimmungsfrei (permissionless) an Destination Chains weiterleiten. Da jede Aktualisierung eine gültige aggregierte BLS-Signatur trägt, können Destination Chains die Echtheit der Operatorentabelle unabhängig verifizieren, ohne dem Boten zu vertrauen. Das schafft eine hochdezentrale Synchronisationsmechanik und vermeidet zugleich eine kontinuierliche Kommunikation mit der Source Chain.
Newton trennt die Synchronisierung außerdem in zwei unabhängige Workflows.
Der Slow-Path aktualisiert die Operatorentabelle nur dann, wenn sich die Zugehörigkeit von Operatoren ändert. Da diese Ereignisse relativ selten auftreten, bleibt die Synchronisierung effizient.
Der Fast-Path konzentriert sich auf die Verifizierung von Transaktionszertifikaten. Sobald die aktuellste Operatorentabelle lokal verfügbar ist, müssen Destination Chains nur noch eine leichte BLS-Verifizierung durchführen, wann immer eine Policy-Auswertung abgeschlossen ist. Das senkt die Verifizierungskosten drastisch und bewahrt gleichzeitig starke Sicherheitsgarantien.
Um die Verifizierung noch effizienter zu machen, unterhält jede Destination Chain einen „Operator Table Calculator“. Anstatt jeden Operator einzeln nachzuschlagen, berechnet der Calculator fortlaufend aggregierte öffentliche Schlüssel für jedes Quorum. Wenn eine neue Operatorentabelle eintrifft, werden nur die Änderungen verarbeitet, sodass die Verifizierung auch dann schnell bleibt, wenn das Netzwerk wächst.
Die Cross-Chain-Verifizierung selbst folgt einem konsistenten Sicherheitsmodell.
Auf Ethereum kann Newton direkt auf die BLS-Registry von EigenLayer verweisen. Auf Destination Chains verifiziert Newton stattdessen ein BN254-Zertifikat, das die aggregierte BLS-Signatur zusammen mit dem Operator-Snapshot verpackt, der während der Auswertung verwendet wurde. Da das Zertifikat an eine bestimmte Chain, eine Blocknummer und einen Operatorentabellen-Snapshot gebunden ist – unter Verwendung von EIP-712 typisierten Daten – werden Replay-Angriffe über Chains hinweg effektiv verhindert.
Sicherheit bleibt in den ökonomischen Garantien von EigenLayer verwurzelt.
Operatoren, die betrügerische Operatorentabellen freigeben, sehen dieselben Slashing-Strafen wie Operatoren, die ungültige Policy-Bewertungen einreichen. Um die Synchronisierungslogik erfolgreich zu sabotieren, müsste man ein Quorum an gestakten Operatoren kompromittieren, wodurch Angriffe ökonomisch sehr teuer und äußerst unpraktisch werden.
Die Architektur priorisiert außerdem die Liveness. Wenn vorübergehende Netzwerkbedingungen verhindern, dass genug Operatoren eine neue Operatorentabelle signieren, arbeiten Destination Chains weiterhin mit dem zuletzt verifizierten Snapshot. Erst nachdem eine konfigurierbare Staleness-Grenze abgelaufen ist, werden neue Zertifikate abgelehnt, bis eine aktualisierte Operatorentabelle synchronisiert wurde. Diese Balance hält Anwendungen funktionsfähig und verhindert zugleich eine langfristige Abhängigkeit von veralteten Validatorinformationen.
Mit Blick nach vorn ist die Architektur von Newton so ausgelegt, dass sie Zero-Knowledge-(ZK)-Verifizierung für Updates der Operatorentabelle unterstützt. Anstatt ein Quorum an Signaturen zu benötigen, könnten zukünftige Implementierungen kompakte kryptografische Beweise erzeugen, die zeigen, dass die Operatorregistrierung korrekt von einem Zustand in den nächsten überführt wurde. Das würde die Vertrauensannahmen weiter reduzieren und die Skalierbarkeit in einem wachsenden Multi-Chain-Ökosystem verbessern.
Letztlich macht das Newton-Protokoll die Cross-Chain-Interoperabilität von einem vertrauensbasierten Prozess zu einem kryptografisch verifizierbaren. Durch die Kombination aus dezentraler Operator-Synchronisierung, aggregierten BLS-Signaturen, effizienter Zertifikatsverifizierung und zukunftssicherer Zero-Knowledge-Technologie schafft Newton eine Infrastruktur, in der Anwendungen Transaktionen über mehrere Blockchains hinweg zuverlässig autorisieren können – ohne Dezentralisierung oder Sicherheit zu opfern.