Manchmal ertappe ich mich dabei, anzunehmen, dass etwas, sobald es ein System verlässt, einfach im nächsten auftauchen sollte und sich die Aufzeichnungen danach von selbst ordnen. So scheint ein Großteil der Software zu funktionieren. Protokolliere die Übertragung, aktualisiere die Salden später, falls nötig. Dann habe ich mir angesehen, wie DUSK tatsächlich zwischen L1 und DuskEVM wechselt, und der Pfad basiert auf einer anderen Annahme.

Die Deposit-Seite sieht zunächst ganz normal aus. Du sendest von der Settlement-Ebene und später erscheinen die gleichen Tokens auf der EVM-Seite als nativer Gas. Kein Wrap. Zuerst dachte ich, die Rückgabe würde einfach diesen Prozess umkehren. Das tut sie nicht. Du initiierst auf DuskEVM und musst dann dennoch mit separaten Transaktionen zurück auf der L1 beweisen und abschließen. Das Asset wird nie zu einem anderen Anspruch. Nur das endgültige Eigentum muss von der Settlement-Ebene erneut bekräftigt werden, bevor es als vollständig „zu Hause“ gilt.

In dieser Abfolge hört das modulare Design auf, abstrakt zu sein. Die Ausführung kann unter ihren eigenen Regeln laufen. Das Settlement behält das letzte Wort. Indem sie sich weigern, eine dritte Repräsentation zu erfinden, beseitigen sie eine Klasse von Bridge-Ausfällen. Der Preis sind die längere Exit-Phase und die zusätzlichen L1-Gebühren. Es scheint, als hätten sie entschieden, dass die Unbequemlichkeit vorzuziehen ist, um zu verhindern, dass der finale Anspruch zwischen zwei Umgebungen „schwimmt“.

Ich bin immer noch nicht sicher, ob das schwierigere Problem darin besteht, ein einzelnes natives Asset über die Schichten hinweg beizubehalten, oder darin zu entscheiden, wie viel Korrektheit des EVM-Zustands die Settlement-Ebene jedes Mal erneut verifizieren soll, wenn ein Wert zurückkommen möchte.

#dusk $DUSK @Dusk $BTC