WARUM BRAUCHT DUSK IHNES BLUBS-IDEEN VON ETHEREUM?
EIP-4844 war die DuskEVM-Details, die ich anfangs nicht ganz einordnen konnte. Ethereum hat Blobs eingeführt, um die Datenverfügbarkeit günstiger zu machen. Dusk hat jedoch bereits DuskDS für Settlement und Datenverfügbarkeit. Also: Warum bringt man dieses Design in Dusk?
Der Layer-Split gibt mir einen besseren Hinweis. DuskEVM übernimmt die EVM-Ausführung, während DuskDS Settlement und Datenverfügbarkeit übernimmt. Das bedeutet: Blobs haben hier eine spezifische Aufgabe. Sie können der Ausführungsebene einen standardisierten Weg geben, mit Daten zu arbeiten, ohne diese Verantwortung vollständig auf DuskEVM zu verlagern.
Rusk macht die Umsetzung schwerer abzutun, als wäre es nur ein Kompatibilitäts-Häkchen. Es hat Blob-Endpunkte, um Blobs über deren Commitment oder Hash abzurufen.
Rusk Wallet unterstützt ebenfalls Blob-Transaktionen. Rusk prüft sie auch im Rahmen der Vorbedingungen-Überprüfung. Das hat meine Aufmerksamkeit geweckt, weil der Blob jetzt Teil des Transaktionspfads ist – nicht nur etwas, das die EVM versteht.
KZG macht die Verbindung noch konkreter. EIP-4844 verwendet KZG-Commitments und -Proofs. Dusk-Tools verifizieren Blob-Commitments, während die Snapshot-Tools die KZG-Beziehung prüfen, bevor sie Blob-Objekte speichern.
So scheinen die Bausteine zusammenzupassen. DuskEVM übernimmt die Ausführung. DuskDS übernimmt Settlement und Datenverfügbarkeit. Blob-Transaktionen, -Abruf und KZG-Verifikation verbinden diese Verantwortlichkeiten.
Ich würde EIP-4844 nicht als etwas beschreiben, das Dusk nur aus Gründen der Vertrautheit mit Ethereum hinzugefügt hat. Dafür gibt es einen tieferen architektonischen Grund.
Aber warum genau dieses Ethereum-Design für ein Netzwerk, das seine eigene Architektur um regulierte Märkte aufbaut?
#dusk . $DUSK @Dusk
EIP-4844 war die DuskEVM-Details, die ich anfangs nicht ganz einordnen konnte. Ethereum hat Blobs eingeführt, um die Datenverfügbarkeit günstiger zu machen. Dusk hat jedoch bereits DuskDS für Settlement und Datenverfügbarkeit. Also: Warum bringt man dieses Design in Dusk?
Der Layer-Split gibt mir einen besseren Hinweis. DuskEVM übernimmt die EVM-Ausführung, während DuskDS Settlement und Datenverfügbarkeit übernimmt. Das bedeutet: Blobs haben hier eine spezifische Aufgabe. Sie können der Ausführungsebene einen standardisierten Weg geben, mit Daten zu arbeiten, ohne diese Verantwortung vollständig auf DuskEVM zu verlagern.
Rusk macht die Umsetzung schwerer abzutun, als wäre es nur ein Kompatibilitäts-Häkchen. Es hat Blob-Endpunkte, um Blobs über deren Commitment oder Hash abzurufen.
Rusk Wallet unterstützt ebenfalls Blob-Transaktionen. Rusk prüft sie auch im Rahmen der Vorbedingungen-Überprüfung. Das hat meine Aufmerksamkeit geweckt, weil der Blob jetzt Teil des Transaktionspfads ist – nicht nur etwas, das die EVM versteht.
KZG macht die Verbindung noch konkreter. EIP-4844 verwendet KZG-Commitments und -Proofs. Dusk-Tools verifizieren Blob-Commitments, während die Snapshot-Tools die KZG-Beziehung prüfen, bevor sie Blob-Objekte speichern.
So scheinen die Bausteine zusammenzupassen. DuskEVM übernimmt die Ausführung. DuskDS übernimmt Settlement und Datenverfügbarkeit. Blob-Transaktionen, -Abruf und KZG-Verifikation verbinden diese Verantwortlichkeiten.
Ich würde EIP-4844 nicht als etwas beschreiben, das Dusk nur aus Gründen der Vertrautheit mit Ethereum hinzugefügt hat. Dafür gibt es einen tieferen architektonischen Grund.
Aber warum genau dieses Ethereum-Design für ein Netzwerk, das seine eigene Architektur um regulierte Märkte aufbaut?
#dusk . $DUSK @Dusk