Standardmäßig können hier 10.000 Transaktionen verarbeitet werden. Ich dachte, das würde zumindest belegen, dass das Netzwerk einen institutionellen Order-Highpeak einmalig abfedern kann. Heute lese ich aber weiter das Dokument zur Transaktionslebenszeit von <c-1/>@Dusk und komme stattdessen zu einer gegenteiligen Schlussfolgerung: Die Antwort der mempool-Kapazität lautet „wie viele Transaktionen ein Knoten vorübergehend aufnehmen kann“, während das, was Institutionen wirklich kaufen, „ob eine Order vor dem geschäftlichen Stichtag bis zur Abrechnung abgeschlossen werden kann“ ist.
Die offiziellen Dokumente schreiben ausdrücklich, dass die mempool-Kapazität eines Dusk L1-Knotens vom Betreiber konfiguriert wird, standardmäßig sind es 10.000 Transaktionen. Bei Vollauslastung können Transaktionen mit höherem Gas-Preis Einträge mit dem niedrigsten Preis verdrängen; außerdem sieht jeder Knoten eine lokale Warteschlange, nicht einen einheitlichen Snapshot für das gesamte Netzwerk. Diese Zahl kann belegen, dass der Knoten einen Puffermechanismus bereitstellt, aber nicht, dass wirklich 10.000 Transaktionen auch ausgeführt werden, und schon gar nicht, dass sie nach geschäftlicher Priorität abgeschlossen werden.
Wenn man das in eine Anleihezeichnung oder die Ausgabe von Fondsanteilen einordnet, wird es besonders klar. Vor dem Stichtag müssen Anleger Qualifikationsprüfungen durchführen, die Orders einreichen, bezahlen und die Vermögensübergabe abschließen. Geschäftlich sind möglicherweise vor allem der gleiche Emissionsjahrgang, dasselbe Zahlungsfenster und Ausgleich bei Fehlschlägen entscheidend; aber die Auswahl der Blockkandidaten erfolgt technisch nach Gas-Preis absteigend. Wenn die Warteschlange verstopft ist, bedeutet technische Preispriorität nicht zwangsläufig eine faire Reihenfolge innerhalb der Markt-Workflows.
Transaktionen müssen außerdem nacheinander den Build/Sign-Konstruktionsschritt, die Knoten-Zulassung, die Verbreitung, die Auswahl, die Ausführung und schließlich die Finalisierung durchlaufen. Selbst ein Fehlschlag beim Ausführen verbraucht Gas; das `removed`-Event zeigt nur, dass eine Transaktion eine lokale mempool verlassen hat – möglich sind Blockeintrag, Ersetzung, Ablauf oder Verdrängung wegen Kapazität. Daraus lässt sich nicht allein das Ergebnis ableiten. Die Startseite von Dusk zeigt heute noch etwa 10 Sekunden deterministische Finalität – aber diese Beschreibung bezieht sich auf die Determiniertheit nach der endgültigen Bestätigung eines Blocks, nicht auf ein Ende-zu-Ende-SLA von der Einreichung bis zur geschäftlichen Fertigstellung.
Noch besorgniserregender ist eine mögliche Differenz lokaler Strategien. Das Dokument erläutert außerdem, dass Transaktionsablauf eine Knotenrichtlinie ist: In Rusk ist standardmäßig drei Tage eingebaut, und node-installer v0.5.22 konfiguriert für das Mainnet und Testnet 30 Minuten. Der Client muss die Regeln des jeweiligen angeschlossenen Knotens berücksichtigen; man darf keinen beliebigen Zahlenwert als Netzwerkgarantie missverstehen.
#dusk $DUSK
Die offiziellen Dokumente schreiben ausdrücklich, dass die mempool-Kapazität eines Dusk L1-Knotens vom Betreiber konfiguriert wird, standardmäßig sind es 10.000 Transaktionen. Bei Vollauslastung können Transaktionen mit höherem Gas-Preis Einträge mit dem niedrigsten Preis verdrängen; außerdem sieht jeder Knoten eine lokale Warteschlange, nicht einen einheitlichen Snapshot für das gesamte Netzwerk. Diese Zahl kann belegen, dass der Knoten einen Puffermechanismus bereitstellt, aber nicht, dass wirklich 10.000 Transaktionen auch ausgeführt werden, und schon gar nicht, dass sie nach geschäftlicher Priorität abgeschlossen werden.
Wenn man das in eine Anleihezeichnung oder die Ausgabe von Fondsanteilen einordnet, wird es besonders klar. Vor dem Stichtag müssen Anleger Qualifikationsprüfungen durchführen, die Orders einreichen, bezahlen und die Vermögensübergabe abschließen. Geschäftlich sind möglicherweise vor allem der gleiche Emissionsjahrgang, dasselbe Zahlungsfenster und Ausgleich bei Fehlschlägen entscheidend; aber die Auswahl der Blockkandidaten erfolgt technisch nach Gas-Preis absteigend. Wenn die Warteschlange verstopft ist, bedeutet technische Preispriorität nicht zwangsläufig eine faire Reihenfolge innerhalb der Markt-Workflows.
Transaktionen müssen außerdem nacheinander den Build/Sign-Konstruktionsschritt, die Knoten-Zulassung, die Verbreitung, die Auswahl, die Ausführung und schließlich die Finalisierung durchlaufen. Selbst ein Fehlschlag beim Ausführen verbraucht Gas; das `removed`-Event zeigt nur, dass eine Transaktion eine lokale mempool verlassen hat – möglich sind Blockeintrag, Ersetzung, Ablauf oder Verdrängung wegen Kapazität. Daraus lässt sich nicht allein das Ergebnis ableiten. Die Startseite von Dusk zeigt heute noch etwa 10 Sekunden deterministische Finalität – aber diese Beschreibung bezieht sich auf die Determiniertheit nach der endgültigen Bestätigung eines Blocks, nicht auf ein Ende-zu-Ende-SLA von der Einreichung bis zur geschäftlichen Fertigstellung.
Noch besorgniserregender ist eine mögliche Differenz lokaler Strategien. Das Dokument erläutert außerdem, dass Transaktionsablauf eine Knotenrichtlinie ist: In Rusk ist standardmäßig drei Tage eingebaut, und node-installer v0.5.22 konfiguriert für das Mainnet und Testnet 30 Minuten. Der Client muss die Regeln des jeweiligen angeschlossenen Knotens berücksichtigen; man darf keinen beliebigen Zahlenwert als Netzwerkgarantie missverstehen.
#dusk $DUSK
