#dusk $DUSK Ich habe den Verifizierungsprozess der Dusk-Transaktionsgebühren einmal aus der Nutzerperspektive durchgesehen und festgestellt, dass „voraussichtliche Gebühren“ in der Wallet nur die äußerste Informationsschicht sind. Wenn die Transaktion tatsächlich in die Netzwerkprüfung gelangt, achtet das System nicht nur darauf, wie hoch der gas limit und wie hoch der gas price jeweils sind, sondern überprüft auch, ob das Produkt daraus – also die maximalen Gebühren – vollständig mit dem übereinstimmt, was in der Transaktion bereits als max fee nachgewiesen wurde. Sobald diese Felder nicht zueinander passen, gibt es einen Konflikt in den Transaktionsparametern.
Hier lohnt sich die Beachtung: Die gleiche Kosten-Einschränkung wird sowohl in der Phase des mempool-Zugangs als auch während der VM-Ausführung jeweils separat geprüft. Die Aufgabe der ersten Ebene besteht darin, bevor die Transaktion sich weiter verbreitet, widersprüchliche Eingaben möglichst früh abzuweisen und so zu verhindern, dass ungültige Daten unnötig Ressourcen auf Knoten binden. Allerdings ist der mempool nicht die letzte Grenze, denn der Inhalt im Block durchläuft möglicherweise nicht zwingend denselben, von jedem normalen Knoten vertrauten Empfangspfad.
Daher muss die VM die Validierung noch einmal durchführen. Das ist keine bloße Wiederholung, sondern stellt sicher, dass – unabhängig davon, über welchen Einstieg die Transaktion erscheint – sobald sie beabsichtigt ist, den Zustand der Kette zu verändern, stets dieselbe Gebührengleichung eingehalten werden muss. Man kann den mempool als eine Art Eingangsfilter verstehen, während die VM-Prüfung entscheidet, ob die Transaktion überhaupt ausführen darf. Der eine Teil erhöht die Effizienz bei der Netzwerkverarbeitung, der andere sorgt für die Konsistenz des Protokollergebnisses.
ETH-Nutzer sehen beim gas limit und gas price häufig zuerst die Frage: Sind die Gebühren hoch, stimmt die Schätzung? Bei Dusk liegt der Schwerpunkt dieser Sicherheitsprüfung jedoch darauf, ob die Gebührennachweise, die Signaturinhalte, die tatsächliche Ausführung und die Berechnung der Rückerstattung miteinander konsistent sind. Selbst wenn die Schätzung der Wallet plausibel wirkt: Solange die Felder nicht streng miteinander verknüpft sind, kann dennoch ein Spielraum für anormale Fehlerbehandlung bleiben.
Das bedeutet auch: Eine Sicherheitskorrektur führt nicht unbedingt dazu, dass ein normaler Nutzer sofort eine sinkende Gebühr wahrnimmt. Ihr unmittelbarerer Nutzen liegt darin, widersprüchliche Gebührendaten daran zu hindern, in den Ausführungsprozess zu gelangen. In der Folge interessiert mich besonders, ob die @Dusk -Wallet die maximal reservierten Gebühren, die tatsächlich verbrauchten Gebühren und die finale Rückerstattung jeweils getrennt anzeigen kann. Für Nutzer, die DUSK nutzen, um Netzwerkgebühren zu bezahlen, lässt sich mit einer allgemeinen „gas“-Zahl nur schwer erklären, an welcher konkreten Stelle die Transaktion scheitert – und es ist auch nicht ersichtlich, ob unterschiedliche Clients dieselben Regeln ausführen. @Dusk $BTC