Ich hab heute Morgen damit verbracht, mir anzuschauen, wie eine DuskEVM-Transaktion tatsächlich durch das System läuft, und ehrlich? 😂 Ich dachte, sobald sie in einem Block auftaucht, bin ich damit durch, aber das ist so nicht ganz richtig.
DuskEVM ist die EVM-kompatible Schicht auf Dusk. Das heißt: Du schreibst Solidity, nutzt normale EVM-Wallets und gängige Tools wie Foundry oder Hardhat und bezahlst Gas in Dusk. Aber die Transaktion lebt nicht einfach für sich allein und stirbt auch nicht einfach auf DuskEVM. Sie durchläuft einen Rollup-ähnlichen Lebenszyklus. Zuerst wird sie beim DuskEVM-Sequencer eingereicht und dann relativ schnell in einen L2-Block aufgenommen. Danach veröffentlicht ein Batcher die Transaktionsdaten über DuskDS – also die tatsächliche Settlement- und Data-Availability-Schicht von Dusk. State-Commitments und Fault-Proofs verbinden diesen resultierenden Zustand wieder mit DuskDS, sodass es wirklich „settled“ ist, und nicht nur irgendwo in einem L2-Block liegt und wartet.
Was ich immer wieder im Kopf habe, ist ein Satz in der Doku, der darauf hinweist, dass Aufnahme (Inclusion) und Settlement echte, verschiedene Phasen sind. Und dass Apps, die Value zwischen DuskEVM und Dusk L1 bewegen, den Protokoll- oder Wallet-Status prüfen sollten, statt einfach anzunehmen, dass etwas final ist, nur weil Zeit vergangen ist. Das ist eine echte Unterscheidung, keine technische Kleinigkeit. Ich hab nirgendwo gefunden, wo explizit steht, wie lange diese Lücke in der Praxis typischerweise ist: Schnelle Inclusion heißt nicht automatisch sofortiges Settlement, aber ich weiß nicht, welches echte Zeitfenster man jemanden warten lassen sollte.
Trotzdem ergibt die Design-Entscheidung für mich Sinn. Man baut nicht einfach eine komplett separate EVM-Kette, die für sich allein herumfliegt. Stattdessen bleibt DuskEVM an DuskDS für Settlement und Data Availability „verankert“. So bekommst du volles Solidity-Tooling, ohne die grundlegenden Garantien der Basisschichten rund um Finalität zu verlieren.
Ehrlich gesagt: Ich weiß nicht, ob diese Lücke von Inclusion bis Settlement klein genug ist, um sie im Alltag zu ignorieren, oder ob Builder sie aktiv berücksichtigen müssen??
🤔
#dusk @Dusk $DUSK
DuskEVM ist die EVM-kompatible Schicht auf Dusk. Das heißt: Du schreibst Solidity, nutzt normale EVM-Wallets und gängige Tools wie Foundry oder Hardhat und bezahlst Gas in Dusk. Aber die Transaktion lebt nicht einfach für sich allein und stirbt auch nicht einfach auf DuskEVM. Sie durchläuft einen Rollup-ähnlichen Lebenszyklus. Zuerst wird sie beim DuskEVM-Sequencer eingereicht und dann relativ schnell in einen L2-Block aufgenommen. Danach veröffentlicht ein Batcher die Transaktionsdaten über DuskDS – also die tatsächliche Settlement- und Data-Availability-Schicht von Dusk. State-Commitments und Fault-Proofs verbinden diesen resultierenden Zustand wieder mit DuskDS, sodass es wirklich „settled“ ist, und nicht nur irgendwo in einem L2-Block liegt und wartet.
Was ich immer wieder im Kopf habe, ist ein Satz in der Doku, der darauf hinweist, dass Aufnahme (Inclusion) und Settlement echte, verschiedene Phasen sind. Und dass Apps, die Value zwischen DuskEVM und Dusk L1 bewegen, den Protokoll- oder Wallet-Status prüfen sollten, statt einfach anzunehmen, dass etwas final ist, nur weil Zeit vergangen ist. Das ist eine echte Unterscheidung, keine technische Kleinigkeit. Ich hab nirgendwo gefunden, wo explizit steht, wie lange diese Lücke in der Praxis typischerweise ist: Schnelle Inclusion heißt nicht automatisch sofortiges Settlement, aber ich weiß nicht, welches echte Zeitfenster man jemanden warten lassen sollte.
Trotzdem ergibt die Design-Entscheidung für mich Sinn. Man baut nicht einfach eine komplett separate EVM-Kette, die für sich allein herumfliegt. Stattdessen bleibt DuskEVM an DuskDS für Settlement und Data Availability „verankert“. So bekommst du volles Solidity-Tooling, ohne die grundlegenden Garantien der Basisschichten rund um Finalität zu verlieren.
Ehrlich gesagt: Ich weiß nicht, ob diese Lücke von Inclusion bis Settlement klein genug ist, um sie im Alltag zu ignorieren, oder ob Builder sie aktiv berücksichtigen müssen??
🤔
#dusk @Dusk $DUSK