Eine Sache hat mich beim Scrollen über das DuskEVM-Testnet stoppen lassen: Die Bridge ist nicht einfach nur ein „DUSK verschieben und vergessen“-Flow.
Ich bin in die Doku gegangen und habe erwartet, dass der spannende Teil die EVM-Kompatibilität ist. Stattdessen habe ich immer weiter den Auszahlungsmechaniken gefolgt.
Und genau dort wurde es seltsam interessant.
Eine Auszahlung aus DuskEVM erfordert drei getrennte On-Chain-Aktionen: erst auf EVM initiieren, dann auf Dusk L1 beweisen und anschließend auf L1 finalisieren. Noch wichtiger: Die Doku sagt, dass die Bereitschaft von veröffentlichtem Netzwerkzustand, Proof-Reife und Dispute-Game-Checks abhängt – nicht einfach davon, eine feste Zeit abzuwarten.
Ich hab mir einen Kaffee geholt und bin nochmal von vorn durchgegangen.
Mechanisch ergibt das Sinn für eine OP-Stack-artige Ausführungsumgebung, die über DuskDS abgewickelt wird. Aber strukturell bedeutet das, dass die Nutzererfahrung teilweise von Bedingungen außerhalb der ursprünglichen EVM-Transaktion gesteuert wird.
Das ist der Teil, den niemand in die Schlagzeile „EVM ist live“ packt.
Vielleicht ist das einfach der unvermeidliche Tradeoff beim Verbinden zweier Execution-Layer.
Aber es hat mich zum Nachdenken gebracht: Wenn sich DuskEVM vom Testnet-Experimentieren hin zu echter finanzieller Aktivität bewegt – werden Nutzer eine Bridge akzeptieren, bei der „fertig“ nicht zwangsläufig „auszahlbar“ bedeutet?
@Dusk_Foundation
#dusk $DUSK
Ich bin in die Doku gegangen und habe erwartet, dass der spannende Teil die EVM-Kompatibilität ist. Stattdessen habe ich immer weiter den Auszahlungsmechaniken gefolgt.
Und genau dort wurde es seltsam interessant.
Eine Auszahlung aus DuskEVM erfordert drei getrennte On-Chain-Aktionen: erst auf EVM initiieren, dann auf Dusk L1 beweisen und anschließend auf L1 finalisieren. Noch wichtiger: Die Doku sagt, dass die Bereitschaft von veröffentlichtem Netzwerkzustand, Proof-Reife und Dispute-Game-Checks abhängt – nicht einfach davon, eine feste Zeit abzuwarten.
Ich hab mir einen Kaffee geholt und bin nochmal von vorn durchgegangen.
Mechanisch ergibt das Sinn für eine OP-Stack-artige Ausführungsumgebung, die über DuskDS abgewickelt wird. Aber strukturell bedeutet das, dass die Nutzererfahrung teilweise von Bedingungen außerhalb der ursprünglichen EVM-Transaktion gesteuert wird.
Das ist der Teil, den niemand in die Schlagzeile „EVM ist live“ packt.
Vielleicht ist das einfach der unvermeidliche Tradeoff beim Verbinden zweier Execution-Layer.
Aber es hat mich zum Nachdenken gebracht: Wenn sich DuskEVM vom Testnet-Experimentieren hin zu echter finanzieller Aktivität bewegt – werden Nutzer eine Bridge akzeptieren, bei der „fertig“ nicht zwangsläufig „auszahlbar“ bedeutet?
@Dusk_Foundation
#dusk $DUSK