Die meisten stark vernetzten Systeme haben einen Moment, in dem eine Anfrage nicht mehr nur ein roher Blob ist, sondern zu etwas wird, das das System weiterleiten kann. Ein Paket trifft auf einen Load Balancer, wird überprüft, und der Balancer entscheidet, an welches Backend es weitergeht. Genau dieser Moment des Entpackens und Entscheidens ist oft der Ort, an dem sich die interessantere Logik befindet. Der Rest ist nur Transport.
Newton's Gateway sitzt genau an diesem Wendepunkt. Ein Intent kommt als JSON-RPC-Payload an, mit Feldern für Absender, Empfänger, Wert, Calldata und Chain-ID. Zunächst stellte ich mir das Gateway als passives Relay vor, das Intents lediglich an Operatoren weiterleitet. Das ist es nicht. Es validiert die Struktur, prüft, ob die erforderlichen Signaturen vorhanden sind, falls die Aufgabe verschlüsselte Daten umfasst, und koordiniert anschließend den zweiphasigen Prepare-Commit-Flow. Operatoren holen externe Daten unabhängig voneinander, das Gateway berechnet Median-Konsenswerte, sendet die kanonischen Daten wieder aus und aggregiert BLS-Signaturen, bis das Quorum erreicht ist.
Das SDK verbirgt den Großteil davon. Du rufst submitEvaluationRequest auf, und das Routing wird abstrahiert. Aber diese Trennung ist entscheidend. Das Gateway entkoppelt den Aufrufer vollständig vom Operator-Netzwerk. Eine dApp sendet einen Intent an einen einzigen Endpunkt. Sie muss nicht wissen, welche Operatoren online sind oder wie der Konsens zustande kommt. Sie erhält einfach eine Bestätigung (Attestation) oder eine Zurückweisung zurück.
Ich überdenke gerade noch, was passiert, wenn das Gateway selbst nicht verfügbar ist. Die Doku erwähnt Webhook-Unterstützung für Failure-Benachrichtigungen, also weiß das System, dass dies eine kritische Abhängigkeit ist. Wenn es ausfällt, werden keine Intents mehr geroutet, keine Attestationen werden erzeugt, und jede policy-gestützte Transaktion bleibt stecken. Das ist ein zentraler Engpass in einer ansonsten dezentralen Architektur. Ich bin mir nicht sicher, ob das ein Übergangslayout oder ein dauerhaftes Trade-off ist.
#newt $NEWT @NewtonProtocol
Newton's Gateway sitzt genau an diesem Wendepunkt. Ein Intent kommt als JSON-RPC-Payload an, mit Feldern für Absender, Empfänger, Wert, Calldata und Chain-ID. Zunächst stellte ich mir das Gateway als passives Relay vor, das Intents lediglich an Operatoren weiterleitet. Das ist es nicht. Es validiert die Struktur, prüft, ob die erforderlichen Signaturen vorhanden sind, falls die Aufgabe verschlüsselte Daten umfasst, und koordiniert anschließend den zweiphasigen Prepare-Commit-Flow. Operatoren holen externe Daten unabhängig voneinander, das Gateway berechnet Median-Konsenswerte, sendet die kanonischen Daten wieder aus und aggregiert BLS-Signaturen, bis das Quorum erreicht ist.
Das SDK verbirgt den Großteil davon. Du rufst submitEvaluationRequest auf, und das Routing wird abstrahiert. Aber diese Trennung ist entscheidend. Das Gateway entkoppelt den Aufrufer vollständig vom Operator-Netzwerk. Eine dApp sendet einen Intent an einen einzigen Endpunkt. Sie muss nicht wissen, welche Operatoren online sind oder wie der Konsens zustande kommt. Sie erhält einfach eine Bestätigung (Attestation) oder eine Zurückweisung zurück.
Ich überdenke gerade noch, was passiert, wenn das Gateway selbst nicht verfügbar ist. Die Doku erwähnt Webhook-Unterstützung für Failure-Benachrichtigungen, also weiß das System, dass dies eine kritische Abhängigkeit ist. Wenn es ausfällt, werden keine Intents mehr geroutet, keine Attestationen werden erzeugt, und jede policy-gestützte Transaktion bleibt stecken. Das ist ein zentraler Engpass in einer ansonsten dezentralen Architektur. Ich bin mir nicht sicher, ob das ein Übergangslayout oder ein dauerhaftes Trade-off ist.
#newt $NEWT @NewtonProtocol