Betrieb & Integration

Freitag, 11 Uhr: Der Armaturenhersteller schickt seinen Zahllauf an das Wallet. Vierzehn Lieferanten sollen zusammen 212.000 Euro-Stablecoins erhalten. Nach 30 Sekunden meldet die Schnittstelle eine Zeitüberschreitung, und der Treasurer startet den Lauf erneut. Am Montag meldet sich der erste Lieferant, weil er zweimal Geld bekommen hat. Alle vierzehn haben das. Der erste Lauf war längst ausgeführt, nur seine Antwort ging unterwegs verloren.

Eine Antwort geht verloren

An keinem Ende ist etwas kaputt. Das ERP-System hat richtig gesendet, das Wallet hat richtig gezahlt. Der Fehler liegt dazwischen: Der Auftrag kam an, die Bestätigung nicht. Wer dann wiederholt, ohne dass sich die Gegenseite an den ersten Auftrag erinnert, erzeugt einen zweiten. Bei Zahlungen in Token holt keine Bank das Geld zurück. Jeder der vierzehn Lieferanten muss den doppelten Betrag freiwillig zurücküberweisen, und bis dahin fehlt die Summe in der Liquidität.

Für einen CFO ist deshalb nicht die Frage, ob solche Störungen vorkommen. Netze verlieren Antworten, Dienste starten neu, Warteschlangen liefern doppelt. Entscheidend ist, ob eine Wiederholung eine zweite Wirkung haben kann. Dieser Artikel beschreibt den Betrieb zwischen ERP-System und Ledger in beiden Richtungen: Ereignisse abholen und Zahlungen senden. Welche Felder ein Auszug trägt, ist in Datenstandard & Kontoauszug beschrieben. Wer eine Zahlung freigibt und ab welchem Betrag ein Vier-Augen-Prinzip greift, steht in Custody & Verwahrung. Hier geht es darum, dass die freigegebene Zahlung genau einmal und unverändert zur Signatur kommt.

Wann ein Ereignis zählt

Die Schnittstelle eines Ethereum-Knotens kennt für jede Abfrage drei Stände: den neuesten Block, einen als sicher markierten und einen finalisierten. Der neueste Block ist am aktuellsten, er kann aber noch ersetzt werden. Einigt sich das Netz später auf einen anderen Block, spricht man von einer Reorganisation. Ein Ereignis, das aus dem ersetzten Block gelesen wurde, gibt es dann nicht mehr. Wer Ereignisse über einen Filter bezieht, bekommt es noch einmal geliefert, mit dem Kennzeichen removed. Wer nur neu abfragt, findet es nicht mehr. Ein Import, der weder das Kennzeichen auswertet noch gelesene Blöcke erneut prüft, behält eine Zahlung, die nie stattgefunden hat.

Ein finalisierter Block lässt sich dagegen nach der Dokumentation von Ethereum nur zurücknehmen, wenn ein Angreifer mindestens ein Drittel aller hinterlegten Ether verliert. Daraus folgt eine einfache Regel: alles lesen, aber nur Finalisiertes buchen. Was davor liegt, steht im Auszug als vorläufig. Andere Netze kennen andere Regeln, und manche Umsetzung zählt statt der Marke eine feste Zahl von Bestätigungen. Welche Grenze gilt, ist eine Festlegung wie die Tagesgrenze. Sie gehört in die Verfahrensdokumentation, wie in Treasury, Risiko & Reporting beschrieben.

Abholen oder gemeldet bekommen

Ereignisse kommen auf zwei Wegen ins Haus. Die Integration fragt einen Knoten regelmäßig nach den Übertragungen eines Tokens an die eigene Adresse. Oder ein Dienstleister, etwa der Verwahrer oder ein Zahlungsdienstleister, meldet sie per Webhook. Die Meldung ist schneller. Sie hat aber eine Schwäche: War das eigene System im falschen Moment nicht erreichbar, hängt es vom Dienstleister ab, ob und wie oft er die Meldung wiederholt. Die Abfrage ist langsamer, lässt sich dafür für jeden Blockbereich beliebig oft wiederholen.

Bewährt hat sich die Verbindung beider Wege. Der Webhook gibt den Anstoß, die Abfrage am Block liefert den Beleg. Nach jeder Meldung und zusätzlich in festem Takt liest die Integration den Blockbereich selbst. Eine verlorene Meldung fällt dann spätestens beim nächsten Takt auf. Wie ein Webhook gegen gefälschte und wiederholte Meldungen geschützt wird, steht im Glossar.

Ein Schlüssel je Ereignis

Beide Wege liefern Dubletten. Der Dienstleister meldet dasselbe Ereignis zweimal, zwei Abfragefenster überlappen, nach einem Neustart wird ein Bereich noch einmal gelesen. Jedes Ereignis braucht deshalb einen Schlüssel, unter dem es genau einmal gespeichert wird. Der Ledger liefert ihn mit: Chain ID, Transaktions-Hash und die Position des Ereignisses in der Transaktion. Die Position ist nötig, weil eine Transaktion mehrere Übertragungen enthalten kann, etwa bei einer Sammelzahlung, wie in Abgleich & Zahlungsflüsse beschrieben. Kommt ein Ereignis mit bekanntem Schlüssel ein zweites Mal, verwirft die Importtabelle es.

Schwieriger ist die Seite des ERP-Systems. Nimmt seine Schnittstelle beim Anlegen einer Buchung einen Idempotenzschlüssel an, gibt die Integration den Schlüssel des Ereignisses mit. Nimmt sie keinen an, muss die Integration vor jeder Buchung nachsehen, ob es sie schon gibt, etwa über den Transaktions-Hash im Buchungstext. Nachsehen und Buchen sind dann zwei Schritte, und zwei gleichzeitige Durchläufe könnten beide nichts finden. Deshalb bucht je Wallet nur ein Prozess. Eine Umsetzung ist HashBuch der Setrion GmbH, die auch diesen Wissenshub betreibt. Es speichert jedes Ereignis unter Transaktions-Hash, Position und Wallet genau einmal und liest dafür in jedem Durchlauf die letzten Blöcke erneut.

Was nach dem letzten Versuch bleibt

Viele Fehler vergehen von selbst: Der Knoten ist überlastet, die Datenbank kurz nicht erreichbar. Dann hilft eine Wiederholung, aber nicht sofort. Die Abstände wachsen besser, etwa eine Minute, dann fünf, dann dreißig, damit ein überlasteter Dienst sich erholen kann. Andere Fehler vergehen nicht. Das ERP-System lehnt eine Buchung ab, weil die Periode gesperrt ist oder die Gegenpartei fehlt. Nach einer festen Zahl von Versuchen kommt das Ereignis deshalb mit dem Grund in eine eigene Ablage, und jemand leert sie jeden Tag.

Eine Regel ist dabei wichtiger als jeder Abstand. Die Marke, bis zu welchem Block gelesen wurde, darf nie über ein Ereignis hinauslaufen, das nicht gespeichert ist. Sonst geht es still verloren, ohne Fehlermeldung und ohne Eintrag in einer Ablage. Die Ablage ist auch nicht das Klärungskonto. Auf dem Klärungskonto liegen gebuchte Beträge, deren Zuordnung offen ist. In der Ablage liegen Ereignisse, die noch gar nicht gebucht sind. Zum Monatsende gehören beide in die Liste der Differenzen.

Wenn sich die Gegenseite ändert

Eine Integration hängt an drei Gegenseiten, die sich ändern, ohne zu fragen: dem Anbieter des Knotens, der Schnittstelle des Dienstleisters und dem Token-Vertrag. Ein Dienstleister kündigt eine neue Version seiner Schnittstelle an und schaltet die alte zu einem Datum ab. Heißt ein Feld dort anders, fehlt es beim Import still. Die Integration nennt deshalb die Version, die sie erwartet, ausdrücklich und prüft eine neue vor dem Stichtag.

Beim Token-Vertrag ist die Änderung weniger sichtbar. Manche Verträge sind so gebaut, dass ihre Programmlogik ausgetauscht werden kann, während die Adresse bleibt. Der Standard ERC-1967 für solche Verträge sieht vor, dass ein Austausch mit dem Ereignis Upgraded gemeldet wird. Die Integration beobachtet dieses Ereignis für jeden Token, den sie bucht, und gibt dem Treasury Bescheid. Ein Testnetz hilft hier nur begrenzt. Dort läuft ein Test-Token, den irgendjemand ausgegeben hat, nicht der Vertrag des Emittenten.

Die Nonce als Zahllaufnummer

Für die Ausgangsseite hat Ethereum eine Sperre schon eingebaut. Jede Transaktion eines Kontos trägt eine Nonce, einen Zähler, der mit jeder Transaktion um eins steigt. Je Konto kann nur eine Transaktion mit einer bestimmten Nonce ausgeführt werden. Die Schnittstelle erlaubt ausdrücklich, eine noch offene Transaktion mit derselben Nonce zu überschreiben. Wird eine Zahlung mit derselben Nonce ein zweites Mal gesendet, entsteht also keine zweite Zahlung. Doppelt zahlt nur, wer eine neue Nonce vergibt, und genau das tut ein Wallet, das die Nonce beim Senden selbst zieht.

Daraus folgt ein Baustein: Die Freigabe im ERP-System legt je Zahlung die Nonce fest und speichert sie mit der Zahlung. Die Nonce wird damit zum Idempotenzschlüssel der Ausgangsseite, und das Netz setzt ihn selbst durch. Die Grenze liegt im Zähler. Er läuft fortlaufend, also wartet eine Zahlung mit der Nonce 42, bis die 41 ausgeführt ist. Wird eine Zahlung nach der Freigabe gestoppt, hält sie alle folgenden auf. Das endet erst, wenn eine Ersatztransaktion mit derselben Nonce ihren Platz einnimmt, etwa eine Übertragung von null an die eigene Adresse.

Der Standard ERC-4337 lockert diese Grenze. Er teilt die Nonce in einen Schlüssel und eine Folge, und jeder Schlüssel zählt für sich. Ein Zahllauf kann so einen eigenen Schlüssel bekommen, und ein gestoppter Lauf hält den nächsten nicht auf. Voraussetzung ist wie beim Paymaster, dass das Wallet als Smart Contract geführt wird, wie in Buchung, Bewertung & Steuer beschrieben. Der Lauf vom Freitag hätte beim zweiten Senden dieselben vierzehn Nonces getragen, und das Netz hätte keine der vierzehn Zahlungen ein zweites Mal ausgeführt.