Eine Sache hat mich beim Testnet von DuskEVM vom Scrollen abgehalten: Die Bridge ist kein simples „DUSK rüberbewegen und dann vergessen“-Szenario.
Ich bin in die Doku gegangen und hatte erwartet, dass der interessante Teil die EVM-Kompatibilität ist. Stattdessen bin ich immer weiter den Abhebemechaniken gefolgt.
Da wurde es seltsam interessant.
Eine Auszahlung aus DuskEVM erfordert drei separate On-Chain-Aktionen: auf EVM initiieren, auf Dusk L1 beweisen und dann auf L1 finalisieren. Vor allem aber heißt es in den Docs, dass die Einsatzbereitschaft von veröffentlichtem Netzwerkstatus, Reifegrad der Proofs und Checks für Dispute-Games abhängt – nicht einfach davon, eine feste Zeit abzuwarten.
Ich hab mir einen Kaffee geholt und bin es nochmal von vorn durchgegangen.
Mechanisch ergibt das Sinn für eine OP-Stack-ähnliche Ausführungsumgebung, die durch DuskDS abgewickelt wird. Aber strukturell bedeutet das, dass die Nutzererfahrung teilweise durch Bedingungen außerhalb der ursprünglichen EVM-Transaktion gesteuert wird.
Das ist der Teil, den niemand in die Überschrift „EVM ist live“ packt.
Vielleicht ist das einfach der unvermeidliche Trade-off, zwei Ausführungsebenen miteinander zu verbinden.
Aber es hat mich zum Nachdenken gebracht: Wenn sich DuskEVM von Testnet-Experimenten hin zu echter finanzieller Aktivität bewegt – werden Nutzer eine Bridge akzeptieren, bei der „fertig“ nicht unbedingt „abhebbar“ bedeutet?
@Dusk
#dusk $DUSK
Ich bin in die Doku gegangen und hatte erwartet, dass der interessante Teil die EVM-Kompatibilität ist. Stattdessen bin ich immer weiter den Abhebemechaniken gefolgt.
Da wurde es seltsam interessant.
Eine Auszahlung aus DuskEVM erfordert drei separate On-Chain-Aktionen: auf EVM initiieren, auf Dusk L1 beweisen und dann auf L1 finalisieren. Vor allem aber heißt es in den Docs, dass die Einsatzbereitschaft von veröffentlichtem Netzwerkstatus, Reifegrad der Proofs und Checks für Dispute-Games abhängt – nicht einfach davon, eine feste Zeit abzuwarten.
Ich hab mir einen Kaffee geholt und bin es nochmal von vorn durchgegangen.
Mechanisch ergibt das Sinn für eine OP-Stack-ähnliche Ausführungsumgebung, die durch DuskDS abgewickelt wird. Aber strukturell bedeutet das, dass die Nutzererfahrung teilweise durch Bedingungen außerhalb der ursprünglichen EVM-Transaktion gesteuert wird.
Das ist der Teil, den niemand in die Überschrift „EVM ist live“ packt.
Vielleicht ist das einfach der unvermeidliche Trade-off, zwei Ausführungsebenen miteinander zu verbinden.
Aber es hat mich zum Nachdenken gebracht: Wenn sich DuskEVM von Testnet-Experimenten hin zu echter finanzieller Aktivität bewegt – werden Nutzer eine Bridge akzeptieren, bei der „fertig“ nicht unbedingt „abhebbar“ bedeutet?
@Dusk
#dusk $DUSK
