#dusk $DUSK Dusk-Caps begrenzen Blöcke auf 1 MB.
Das entspricht laut den eigenen Engineering-Notizen von Dusk ungefähr 250 Phoenix-Transaktionen pro Block. Wenn man das durchrechnet, liegt eine einzelne abgeschirmte Übertragung bei rund 4 KB.
Eine normale UTXO-Übertragung auf einer transparenten Kette liegt unter 500 Bytes. Das PLONK-Beweisobjekt selbst bleibt kompakt und hat eine konstante Größe und liegt bei knapp einem halben Kilobyte – egal wie komplex der Schaltkreis wird. Das zusätzliche Gewicht ist also nicht der Beweis. Es sind die Notizen, Nullifier und Commitments, die eine abgeschirmte Übertragung mit sich tragen muss, damit ein Spend nicht auf eine bestimmte Person zurückverfolgt werden kann.
Privatsphäre kostet Bytes – nicht Rechenaufwand.
Ich dachte, das wäre die gesamte Skalierungsstory, bis ich tiefer in DuskEVM eingestiegen bin. Es läuft auf dem OP Stack und führt EVM-Transaktionen aus, während ein Batcher die Transaktionsdaten als Blobs zurück zu DuskDS postet – statt auf Ethereum. Klingt auf dem Papier clever. Man verlagert die allgemeine Contract-Ausführung von der privacy-nativen Settlement-Ebene weg, gibt ihr einen eigenen Gas-Markt und hält DuskDS schlank.
Allerdings landen diese Blobs immer noch innerhalb des eigenen Blockbudgets von DuskDS. Also dieselben begrenzten Bytes, um die sich die abgeschirmten Übertragungen ohnehin schon streiten. Und aktuell läuft DuskEVM sequencer-only, ohne öffentlichen Mempool.
Damit ist der Engpass nicht verschwunden. Er wurde nur verlagert, und die Reihenfolge wurde auf dem Weg dorthin stärker zentralisiert. DUSK ist der native Gas-Token über beide Ebenen hinweg – DuskDS und DuskEVM. Daher hängt die reale Nutzungskurve davon ab, ob dieses gemeinsame Byte-Budget auch dann noch trägt, wenn tatsächlich EVM-Verkehr im großen Maßstab auftaucht.
Löst eine modulare Privacy-Chain Staus, indem sie Schichten hinzufügt – oder verlagert sie das Problem nur an einen Ort, der schwerer zu prüfen ist?
#Dusk @Dusk
Das entspricht laut den eigenen Engineering-Notizen von Dusk ungefähr 250 Phoenix-Transaktionen pro Block. Wenn man das durchrechnet, liegt eine einzelne abgeschirmte Übertragung bei rund 4 KB.
Eine normale UTXO-Übertragung auf einer transparenten Kette liegt unter 500 Bytes. Das PLONK-Beweisobjekt selbst bleibt kompakt und hat eine konstante Größe und liegt bei knapp einem halben Kilobyte – egal wie komplex der Schaltkreis wird. Das zusätzliche Gewicht ist also nicht der Beweis. Es sind die Notizen, Nullifier und Commitments, die eine abgeschirmte Übertragung mit sich tragen muss, damit ein Spend nicht auf eine bestimmte Person zurückverfolgt werden kann.
Privatsphäre kostet Bytes – nicht Rechenaufwand.
Ich dachte, das wäre die gesamte Skalierungsstory, bis ich tiefer in DuskEVM eingestiegen bin. Es läuft auf dem OP Stack und führt EVM-Transaktionen aus, während ein Batcher die Transaktionsdaten als Blobs zurück zu DuskDS postet – statt auf Ethereum. Klingt auf dem Papier clever. Man verlagert die allgemeine Contract-Ausführung von der privacy-nativen Settlement-Ebene weg, gibt ihr einen eigenen Gas-Markt und hält DuskDS schlank.
Allerdings landen diese Blobs immer noch innerhalb des eigenen Blockbudgets von DuskDS. Also dieselben begrenzten Bytes, um die sich die abgeschirmten Übertragungen ohnehin schon streiten. Und aktuell läuft DuskEVM sequencer-only, ohne öffentlichen Mempool.
Damit ist der Engpass nicht verschwunden. Er wurde nur verlagert, und die Reihenfolge wurde auf dem Weg dorthin stärker zentralisiert. DUSK ist der native Gas-Token über beide Ebenen hinweg – DuskDS und DuskEVM. Daher hängt die reale Nutzungskurve davon ab, ob dieses gemeinsame Byte-Budget auch dann noch trägt, wenn tatsächlich EVM-Verkehr im großen Maßstab auftaucht.
Löst eine modulare Privacy-Chain Staus, indem sie Schichten hinzufügt – oder verlagert sie das Problem nur an einen Ort, der schwerer zu prüfen ist?
#Dusk @Dusk