#dusk $DUSK @Dusk Beim Lesen der Versionshinweise zu Boreas blieb ich an einer kleinen Änderung hängen: DUSK setzt nun keine Preise mehr für SHA-256, Keccak und generisches Hashing, als würden alle Eingaben gleich viel kosten.
Ein 32-Byte-Hash und ein Hash-Aufruf mit mehreren Kilobytes rufen die gleiche Host-Abfrage auf, verlangen aber keine gleiche Rechenarbeit. Boreas führt größenbasierte Preise für diese drei ein, während die BLS-Multisig-Verifikation mit der Anzahl der Schlüssel skaliert. KZG-Verifikation und secp256k1-Recovery werden nicht als nach Eingabelänge bepreist beschrieben. Nach der „am teuersten“ Abfrage zu fragen, ohne Eingabelänge und Schlüsselanzahl festzulegen, ist fast die falsche Frage.
Der Vergleich stellt eine pauschale API-Call-Bepreisung der Rechenarbeit gegenüber, die bei Validatoren erzwungen wird. DUSK ist der zweiten Komponente nähergekommen.
Es gibt eine Verkomplizierung. Boreas ist fork-abhängig: Historische Ausführung behält die Pre-Fork-Semantik, während aktuelle Verträge den neuen Zeitplan erhalten. Äquivalente Berechnungen können je nach Ausführungskontext unterschiedlich viel Gas kosten – notwendig für Replay, für Entwickler beim Abschätzen von Kosten eher unpraktisch.
Für DUSK sollte eine bessere Gas-Genauigkeit unterbepreiste kryptografische Workloads reduzieren und die Ausführung konsistenter über Knoten hinweg machen. Das beweist nicht, dass erfolgreiche Zustandsübergänge günstiger wurden. Vielleicht wurden sie nur ehrlicher bepreist, auch wenn die Werte steigen.
Ich warte immer noch auf Benchmark-Daten nach Input-Bucket. Deterministische Abrechnung ist nur überzeugend, wenn das berechnete Gas die reale CPU-Arbeit abbildet.
@Dusk #dusk #Dusk
Ein 32-Byte-Hash und ein Hash-Aufruf mit mehreren Kilobytes rufen die gleiche Host-Abfrage auf, verlangen aber keine gleiche Rechenarbeit. Boreas führt größenbasierte Preise für diese drei ein, während die BLS-Multisig-Verifikation mit der Anzahl der Schlüssel skaliert. KZG-Verifikation und secp256k1-Recovery werden nicht als nach Eingabelänge bepreist beschrieben. Nach der „am teuersten“ Abfrage zu fragen, ohne Eingabelänge und Schlüsselanzahl festzulegen, ist fast die falsche Frage.
Der Vergleich stellt eine pauschale API-Call-Bepreisung der Rechenarbeit gegenüber, die bei Validatoren erzwungen wird. DUSK ist der zweiten Komponente nähergekommen.
Es gibt eine Verkomplizierung. Boreas ist fork-abhängig: Historische Ausführung behält die Pre-Fork-Semantik, während aktuelle Verträge den neuen Zeitplan erhalten. Äquivalente Berechnungen können je nach Ausführungskontext unterschiedlich viel Gas kosten – notwendig für Replay, für Entwickler beim Abschätzen von Kosten eher unpraktisch.
Für DUSK sollte eine bessere Gas-Genauigkeit unterbepreiste kryptografische Workloads reduzieren und die Ausführung konsistenter über Knoten hinweg machen. Das beweist nicht, dass erfolgreiche Zustandsübergänge günstiger wurden. Vielleicht wurden sie nur ehrlicher bepreist, auch wenn die Werte steigen.
Ich warte immer noch auf Benchmark-Daten nach Input-Bucket. Deterministische Abrechnung ist nur überzeugend, wenn das berechnete Gas die reale CPU-Arbeit abbildet.
@Dusk #dusk #Dusk
