Das hat mich beim Graben in DuskEVM nicht der EVM-Teil selbst aufgehalten. Es war die Stelle, an der die Ausführung tatsächlich sitzt.
Ich habe mir @DuskNetwork angesehen. Die aktuellen Dokus zeigen, dass DuskEVM die Chain-ID 744 nutzt und DUSK als natives Gas-Token. Während DuskDS Settlement und Datenverfügbarkeit übernimmt. Diese Trennung klingt auf dem Papier sauber, aber sie hat meine Sicht auf das Netzwerk verändert: Die EVM-Umgebung ersetzt nicht die Basisschicht von Dusk; sie liegt vielmehr darüber.
Was mich zum Innehalten gebracht hat, war die jüngste OpenDusk-Governance-Aktivität.
Die August-Abstimmung befasst sich damit, ob verbrannte Block Rewards in eine Community-Treasury fließen sollen, während DuskEVM als Anwendungsschicht positioniert wird. Es ergibt sich also ein spannender Kontrast: Governance und Settlement bleiben an DuskDS gebunden, während Entwickler die vertraute Solidity/EVM-Umgebung darüber bekommen.
Ursprünglich dachte ich, dass EVM auf Dusk vor allem eine einfachere Bereitstellung bedeutet. Nach der Nachverfolgung der Architektur bin ich mir weniger sicher, dass das der entscheidende Punkt ist.
Die eigentliche Frage für mich ist, ob Entwickler diese Trennung in der Praxis wirklich nutzen oder ob DuskEVM größtenteils weiterhin nur eine Kompatibilitätsschicht bleibt, während die tiefergehende Aktivität auf DuskDS stattfindet…
@Dusk_Foundation $DUSK #dusk
Ich habe mir @DuskNetwork angesehen. Die aktuellen Dokus zeigen, dass DuskEVM die Chain-ID 744 nutzt und DUSK als natives Gas-Token. Während DuskDS Settlement und Datenverfügbarkeit übernimmt. Diese Trennung klingt auf dem Papier sauber, aber sie hat meine Sicht auf das Netzwerk verändert: Die EVM-Umgebung ersetzt nicht die Basisschicht von Dusk; sie liegt vielmehr darüber.
Was mich zum Innehalten gebracht hat, war die jüngste OpenDusk-Governance-Aktivität.
Die August-Abstimmung befasst sich damit, ob verbrannte Block Rewards in eine Community-Treasury fließen sollen, während DuskEVM als Anwendungsschicht positioniert wird. Es ergibt sich also ein spannender Kontrast: Governance und Settlement bleiben an DuskDS gebunden, während Entwickler die vertraute Solidity/EVM-Umgebung darüber bekommen.
Ursprünglich dachte ich, dass EVM auf Dusk vor allem eine einfachere Bereitstellung bedeutet. Nach der Nachverfolgung der Architektur bin ich mir weniger sicher, dass das der entscheidende Punkt ist.
Die eigentliche Frage für mich ist, ob Entwickler diese Trennung in der Praxis wirklich nutzen oder ob DuskEVM größtenteils weiterhin nur eine Kompatibilitätsschicht bleibt, während die tiefergehende Aktivität auf DuskDS stattfindet…
@Dusk_Foundation $DUSK #dusk