Gestaffelte Bestätigungen: Wartezeit nach Betrag

Eine Bestätigungsregel entscheidet, wann eine Zahlung gutgeschrieben werden kann. Paymos liest dafür zwei Werte: das Netzwerk, das der Zahler gewählt hat, und den Dollarwert der Rechnung. Jedes Netzwerk trägt je Betragsstufe seine eigene Bestätigungstiefe, eine kleine Rechnung ist auf derselben Chain also flacher durch als eine große. Diese Tiefen sind Konfiguration und keine Schätzung — deshalb kann dieser Text sie nennen. Was sie nicht sind, ist eine Uhr: Die Minuten hinter einer Zahl gehören der Blockproduktion der Chain, und eine Integration gibt Ware auf den bestätigten Rechnungsstatus hin frei, nicht auf einen Timer.

Worüber entscheidet eine Bestätigungsregel?

Eine Bestätigungsregel macht aus einem rohen Ereignis in der Kette ein Zahlungsergebnis. Auf den meisten Netzwerken heißt das: Blöcke zählen, die auf dem Block mit der Zahlung aufbauen. Gibt ein Netzwerk ein ausdrückliches Finalitätssignal aus, liest die Regel stattdessen dieses Signal. Der Händler sieht in beiden Fällen dasselbe — den Rechnungsstatus — und muss die Bewertung nie selbst führen.

Die Regel existiert, weil eine frische Beobachtung in der Kette noch keine abgeschlossene Zahlung ist. Ein Reorg — eine Reorganisation der Kette — kann jüngste Blöcke ersetzen; ein Wallet, das eine Bestätigung anzeigt, hat damit die Aufnahme belegt, nicht die Dauerhaftigkeit. Tiefe kauft Wahrscheinlichkeit. Ein Finalitätssignal des Protokolls kauft eine stärkere Zusage nach dessen eigenen Regeln. Die Grenze der Anbindung liegt beim bestätigten Rechnungsstatus, nicht bei dem Block-Explorer, den gerade jemand im Support offen hat.

Warum hängt die sichere Wartezeit vom Betrag ab?

Der Betrag ist der Wert, der im Feuer steht, wenn ein junger Block verdrängt wird. Sicherheit ist eine Eigenschaft des Netzwerks; die Höhe des Schadens ist eine Eigenschaft der Rechnung. Eine Regel, die das Zweite ignoriert, muss für beide eine einzige Wartezeit wählen, und keine Antwort passt: Tief genug für einen fünfstelligen Transfer lässt eine Bestellung über 20 $ kriechen, schnell genug für die 20 $ behandelt den fünfstelligen Transfer zu billig.

Stufen über den Dollarwert der Rechnung lösen das auf. Die Schwellen liegen bei 100 $, 1.000 $ und 10.000 $, und eine Stufe gilt bis einschließlich ihrer eigenen Schwelle. Die Zahlen innerhalb dieser Stufen unterscheiden sich je Netzwerk, und manche Netzwerke nutzen weniger Stufen als andere, weil ein Block nicht auf jeder Chain dasselbe bedeutet.

Wie sieht eine gestaffelte Bestätigungsregel in der Praxis aus?

Hier ist die ganze Regel für die Netzwerke, in denen die Stufen die Arbeit machen. Eine Ethereum-Rechnung wartet bis einschließlich 100 $ auf 2 Bestätigungen, bis 1.000 $ auf 6, bis 10.000 $ auf 12 und darüber auf 32. Tron beginnt bei 2, geht auf 6 und endet oberhalb von 1.000 $ bei 19 — dem Punkt, an dem 19 der 27 Super Representatives den Block verfestigt haben. Base und Optimism fahren über dieselben Schwellen 5 / 15 / 30 / 100. Arbitrum fährt 40 / 120 / 240 / 800, was extrem klingt, bis man die Blockzeit unter einer Sekunde mitrechnet: Die vier Horizonte landen dort, wo die von Base liegen.

Mehrere Chains brauchen gar keine Stufen. BSC und Polygon schließen über ihr eigenes Finalitätssignal ab, ebenso Avalanche und Plasma. Solana wird auf der Zusage finalized gescannt und mit dem Fund bestätigt. TON verlangt einen Block, weil dort jeder Masterchain-Block final ankommt.

Eine dieser Zahlen allein zu nennen, ist der Weg, auf dem die Regel falsch wiedergegeben wird. „Finalität bei 19 Bestätigungen auf Tron“ trifft oberhalb von 1.000 $ zu und darunter nicht. Nehmen Sie die Stufe mit oder geben Sie die ganze Zeile. Der Leitfaden zu Bestätigungen erklärt, warum dieselbe rohe Blockzahl nicht in jedem Netzwerk dieselbe Sicherheit bedeutet.

Wie lange dauert eine Stufe in Minuten?

Aus einer Zahl wird erst über die aktuelle Blockrate des Netzwerks eine Dauer. Die flachste Stufe von Ethereum läuft bei gewöhnlichem Takt rund 24 Sekunden, die tiefste etwas über sechs Minuten; die flachste von Tron liegt bei etwa sechs Sekunden. Lesen Sie jede dieser Angaben als Näherung.

Ist ein Netzwerk überlastet, kommen Blöcke langsamer, und die Rechnung wandert mit. Genau dort verläuft die Grenze zwischen den beiden Hälften dieser Regel: Die Zahl ist eine Einstellung, die Zeit eine Prognose. Ein Etikett im Checkout, ein Textbaustein im Support oder eine Vertragsklausel, die aus der Prognose eine Zusage macht, liegt am ersten vollen Nachmittag daneben.

Wie wirkt die Finalität des Protokolls auf die Regel?

Ein Proof-of-Stake-Netzwerk kann Finalität ausgeben, statt sie nur nahezulegen. Ethereum ordnet das über Prüfpunkte nach Casper FFG, die Geschichte in Epochen abschließen statt Block für Block. Paymos zählt auf Ethereum trotzdem Blöcke — 2 bis 32, je nach Stufe —, der Betrag bleibt dort also Teil der Entscheidung.

Wo die Finalität einer Chain schnell und ohne Vorbehalt eintritt, verschwinden die Stufen ganz; deshalb fahren die oben genannten Netzwerke eine einzige Stufe. Der Konsens beantwortet dort direkt, was eine Tiefenzählung nur wahrscheinlich machen kann. Verschiedene Modelle, ein Ergebnis für den Händler: der Rechnungsstatus.

Warum muss die Regel dem aktuellen Verhalten des Netzwerks folgen?

Netzwerke ändern, wie schnell und wie fest sie Blöcke produzieren. Das Fermi-Upgrade der BSC hat die Blockzeiten gesenkt, Heimdall v2 bei Polygon den Weg zur Finalität verkürzt. Beides verschiebt die zeitliche Bedeutung einer Zahl, ohne die Zahl anzurühren.

Das ist das Argument gegen eine eingefrorene Zahl im Händler-Code. Bewegt sich eine Chain, ist die Tiefenkonfiguration unsere Sache; eine Konstante in einem fremden Repository ändert sich, wenn jemand daran denkt, einen Pull Request zu öffnen. Die Stufen oben sind eine Momentaufnahme von Einstellungen, die Paymos pflegt, keine Klausel in einem Vertrag.

Wann ist eine fest verdrahtete Bestätigungszahl die richtige Wahl?

Selten, und nie als Ersatz für den Rechnungsstatus. Die Tabelle zu lesen, um die Wartezeit zu verstehen, ist eine faire Nutzung. Ein if um 12 Bestätigungen herum zu bauen, ist es nicht: Die Konstante lässt das gewählte Netzwerk weg, die Stufe, in der die Rechnung gelandet ist, und die nächste Änderung an beidem.

Die Aufgabe der Integration ist enger und überlebt all das. Speichern Sie die Paymos-Rechnungskennung, prüfen Sie die Signatur der Statusmeldungen und machen Sie die Auslieferung idempotent. Eine Bestellung sollte nicht herausgehen, weil ein Timer abgelaufen ist, weil ein Wallet einen Block angezeigt hat oder weil eine frühere Zahlung auf einer anderen Chain schnell durch war. Solche Beobachtungen helfen dem Support; sie ersetzen nicht das bestätigte Ergebnis der Rechnung, um die es gerade geht.

Wie wendet Paymos die Regel an?

Paymos bewertet Netzwerk und Betrag gemeinsam und meldet dann das Ergebnis. Kleinere Zahlungen sind bei weniger Bestätigungen durch, größere warten auf eine stärkere Schwelle, und die verstrichene Zeit folgt dem, was die Chain in diesem Moment tut. Die Zahlen bewegen sich nur, wenn Paymos sie bewegt — genau das trennt sie von der Netzwerkgebühr, einem Preis, den die Kette setzt und den keine Seite hier als festen Betrag nennt.

Die Seite zu unterstützten Chains zeigt die verfügbaren Zahlungswege. Die Erklärung zu Bestätigungen behandelt, was eine Blockzahl belegt und wo die eigene Finalität eines Protokolls das stärkere Signal ist.