Ich habe heute Morgen den Dusk-Block-Explorer überprüft, als mir etwas Seltsames aufgefallen ist. Die Transaktionsfinalität lag bei etwa 5–6 Sekunden, was für DuskDS normal ist. Aber mein Test-Transfer hat fast 45 Sekunden gebraucht, bis er zur Ruhe kam.
Ich habe es auf das RPC geschoben. Ich dachte, es sei ein Problem mit dem Knoten oder eine Netzwerküberlastung.
Das war zu einfach.
Wie sich herausstellte: Bestätigung ≠ Finalität. Die Transaktion wurde bestätigt. Der ZK-Beweis wurde verifiziert. Aber DuskDS arbeitet mit einem deterministischen Settlement-Modell mit 1-Sekunden-Blockzeiten. Was ich übersehen habe: Die Transaktion hatte einen Cold Start auf der Prover-Seite – der erste vertrauliche Transfer nach einer Phase der Inaktivität dauert länger, weil die Pipeline zur ZK-Beweisgenerierung erst hochfahren muss.
Was niemand anspricht? Queue-Intervalle. Das Netzwerk hat derzeit 47 Knoten. Das ist nicht viel für eine Layer 1. Wenn mehrere Institutionen gleichzeitig Compliance-Checks einreichen – zum Beispiel im Rahmen der NPEX €200M+ bestätigten Emission – dann stauen sich diese Warteschlangen sehr schnell.
Die Infrastruktur ist für regulierte Assets mit selektiver Offenlegung gebaut. Aber ich komme immer wieder auf Folgendes zurück: 47 Knoten, 500M umlaufende Menge und ein Emissionsplan mit 36 Jahren. Die Validator-Ökonomik ist langfristig – so ist es vom Design her vorgesehen. Aber dauerhaftes Nutzungsaufkommen aus echtem institutionellem Volumen? Das unterscheidet sich von Testnet-Verkehr.
Was passiert, wenn die €200M tatsächlich gehandelt werden und alle 47 Knoten auf einmal völlig überlastet sind?
#dusk $DUSK @Dusk
Ich habe es auf das RPC geschoben. Ich dachte, es sei ein Problem mit dem Knoten oder eine Netzwerküberlastung.
Das war zu einfach.
Wie sich herausstellte: Bestätigung ≠ Finalität. Die Transaktion wurde bestätigt. Der ZK-Beweis wurde verifiziert. Aber DuskDS arbeitet mit einem deterministischen Settlement-Modell mit 1-Sekunden-Blockzeiten. Was ich übersehen habe: Die Transaktion hatte einen Cold Start auf der Prover-Seite – der erste vertrauliche Transfer nach einer Phase der Inaktivität dauert länger, weil die Pipeline zur ZK-Beweisgenerierung erst hochfahren muss.
Was niemand anspricht? Queue-Intervalle. Das Netzwerk hat derzeit 47 Knoten. Das ist nicht viel für eine Layer 1. Wenn mehrere Institutionen gleichzeitig Compliance-Checks einreichen – zum Beispiel im Rahmen der NPEX €200M+ bestätigten Emission – dann stauen sich diese Warteschlangen sehr schnell.
Die Infrastruktur ist für regulierte Assets mit selektiver Offenlegung gebaut. Aber ich komme immer wieder auf Folgendes zurück: 47 Knoten, 500M umlaufende Menge und ein Emissionsplan mit 36 Jahren. Die Validator-Ökonomik ist langfristig – so ist es vom Design her vorgesehen. Aber dauerhaftes Nutzungsaufkommen aus echtem institutionellem Volumen? Das unterscheidet sich von Testnet-Verkehr.
Was passiert, wenn die €200M tatsächlich gehandelt werden und alle 47 Knoten auf einmal völlig überlastet sind?
#dusk $DUSK @Dusk
