Ich dachte immer wieder darüber nach, wie Institutionen Tausende von Blockchain-Transaktionen automatisieren, ohne dabei ständig ihre eigenen Sicherheitsregeln zu verletzen.
Zunächst sah es nach einem einfachen Berechtigungsproblem aus.
Je genauer ich hinsah, desto deutlicher wurde, dass es ein Timing-Problem ist.
Moderne Smart Accounts verarbeiten selten eine einzelne Anfrage isoliert. Automatisierte Handelsstrategien, Treasury-Operationen und Unternehmens-Zahlungssysteme reichen häufig mehrere Transaktionen fast gleichzeitig ein. Von außen betrachtet wirkt jede Anfrage unabhängig.
Intern können sie jedoch alle von genau demselben Berechtigungsstatus abhängen.
Das schafft eine interessante Ingenieursherausforderung.
Stellen Sie sich ein Smart Account mit einem vorgegebenen Ausgabenlimit vor.
Transaktion A kommt zuerst an.
Die Autorisierungs-Engine prüft, ob das verbleibende Limit ausreicht, und genehmigt die Anfrage.
Nur Millisekunden später gelangt Transaktion B in die Validierungspipeline.
Da Transaktion A noch nicht on-chain bestätigt wurde, beobachtet die Validierungs-Engine weiterhin das ursprüngliche verfügbare Limit.
Es genehmigt auch Transaktion B.
Keine der Transaktionen ist technisch falsch.
Beide Entscheidungen wurden anhand von Informationen getroffen, die zum Zeitpunkt jedes Beginns der Auswertung gültig waren.
Das Problem ist, dass sich beide Freigaben auf dieselbe verfügbare Berechnungskapazität stützten.
Diese Situation wird üblicherweise als Race Condition beschrieben, aber in unternehmensweiten Autorisierungssystemen wird daraus etwas noch Wichtigeres: Berechtigungseingriffe.
Die Blockchain selbst ist nicht dafür verantwortlich, das Problem zu erzeugen.
Das Problem existiert, bevor die Transaktion überhaupt den Konsens erreicht.
Es beginnt innerhalb des Autorisierungs-Workflows, der darüber entscheidet, ob eine Ausführung erlaubt sein soll.
Mit zunehmender Raffinesse der Automatisierung wird dieses Zeitfenster immer bedeutender.
Große Organisationen führen selten isolierte Aktionen aus.
Treasury-Systeme können Gelder gleichzeitig auf mehrere Protokolle verteilen.
Risiko-Engines können Portfolios kontinuierlich umschichten.
Market-Making-Strategien können innerhalb von Millisekunden mehrere Absichten erzeugen.
Ohne zusätzliche Abstimmung konkurriert jede gleichzeitige Anfrage um denselben Berechtigungsstatus.
Eine mögliche Lösung ist eine deterministische Sequenzsperre.
Anstatt zuzulassen, dass jede Anfrage Berechtigungen unabhängig voneinander auswertet, reserviert die Autorisierungsschicht vorübergehend die verfügbare Kapazität für die erste genehmigte Transaktion, bevor die nächste ausgewertet wird.
Dadurch entsteht eine vorhersehbare Ausführungsreihenfolge, noch bevor die On-Chain-Settlement erfolgt.
Der Ansatz reduziert die Parallelität leicht, verbessert aber die Konsistenz deutlich.
Aus Infrastruktursicht wird dieser Trade-off zunehmend attraktiver, wenn die Transaktionsvolumina weiter wachsen.
Außerdem zeigt es eine interessante Ausrichtung für programmierbare Autorisierungs-Frameworks wie @NewtonProtocol.
Wenn Berechtigungssysteme ausdrucksstärker werden, reicht es möglicherweise nicht mehr aus, Anfragen lediglich schnell zu validieren.
Die Infrastruktur muss außerdem sicherstellen, dass mehrere gleichzeitige Entscheidungen logisch konsistent miteinander bleiben.
Die Ausführungsgeschwindigkeit ist wichtig.
Genauigkeit der Berechtigungen ist ebenso wichtig.
Die nächste Generation von Autorisierungs-Engines wird möglicherweise nicht dadurch definiert, wie viele Transaktionen sie jede Sekunde genehmigen.
Sie können dadurch definiert werden, wie zuverlässig sie verhindern, dass diese Transaktionen zweimal dieselben Ressourcen freigeben.
Das fühlt sich weniger nach einem Blockchain-Scaling-Problem an...
...und sehr viel mehr wie ein Problem verteilter Systeme.
#Newt #BinanceTurns9 #BinancePickAndWin #ZcashRises1190%OverPastYear #SKHynixSharesFallInSeoulAfterUSDebut @NewtonProtocol $NEWT $ZEC $CL