Wenn wir normalerweise über Cross-Chain-Brücken schauen, richten wir unsere Augen immer nur darauf, ob das Geld schon angekommen ist. Aber auf einer Brücke laufen tatsächlich zwei Dinge: Geld und Nachrichten. Geld hat ein Guthaben, Bestätigungen – und fehlt auch nur ein Cent, lässt sich das nachprüfen. Doch die „Nachricht“, die über die Cross-Chain geschickt wird – wurde sie wirklich korrekt zugestellt? Oder wurde sie von jemandem abgefangen und dann ein zweites Mal abgespielt? Gerade darum kümmern sich erstaunlich wenige.
In dem Architekturdiagramm von @Dusk steht es ganz offen: Die Bridge transportiert gleichzeitig zwei Dinge, DUSK und die Nachricht. Das eine hat On-Chain Gas, Guthaben und Bestätigungen – wie eine Fahrspur mit klar angeschriebenem Preis. Das andere ist eher wie ein Feldweg auf der Brücke, für den niemand extra separat bezahlt wird; wenn da etwas schiefgeht, weiß man nicht, wer dafür verantwortlich ist.
Welche Rolle DUSK in diesem System hat, muss man nicht lange erklären: Die Execution-Layer verbraucht es, und L1 und DuskEVM müssen es hin und her „mitnehmen“. Jede Bewegung – Transaktion, Abwicklung, Vertragsaufruf – kostet $DUSK . Deshalb kann man seinen Wert grundsätzlich an den Durchsatz koppeln. Aber Nachrichten sind keine Tokens. Sie können Cross-Chain-Aufrufe sein, Autorisierungen, Statusänderungen oder irgendeine Art von Anweisungen, die zwingend in einer bestimmten Reihenfolge ausgeführt werden müssen.
Die Unterlagen erkennen im Wesentlichen nur die Art an, wie Dusk-Verträge den Aufrufer identifizieren – anders als bei Ethereum. Die Bridge-Semantik und die Wert-Erfassung müssen für Dusk angepasst werden. Aber die Zustellgarantien für diese Nachrichten, der Schutz vor Replay-Angriffen, die Regeln zur Reihenfolge sowie die Fehlerpfade werden kaum ausgeführt. Denk mal drüber nach: In regulierten Finanzsystemen ist das genau die tödlichste Blindstelle. Wenn bei einer Geldüberweisung etwas schiefgeht, kann es oft zurückgebucht werden; aber wenn eine Anweisung heimlich zweimal ausgeführt wird, lässt sich die Verantwortung nicht mehr „zurückspulen“.
Ist das nicht eher der Bereich, der mit mehr Strenge geprüft werden sollte als die Assets? Ganz ehrlich: DUSK zahlt man für die „Geld-Fahrspur“ mit, aber es kann die „Nachrichten-Fahrspur“ nicht automatisch garantieren. Wer Coins hält, kauft Netzwerkberechnung – nicht die Abrechnungs-/Haftungsverantwortung für die Bridge-Nachrichten. Wenn wirklich etwas schiefgeht, muss möglicherweise die Anwendung, der Nutzer oder irgendein unglücklicher Dritter die Lücke schließen. DUSK-Gas wird nicht einfach zu einer Entschädigungszusage.
#dusk
Ich habe mir das angesehen: Die echten Minen in einem Cross-Chain-System liegen oft nicht im Asset-Bereich, sondern im Nachrichtenbereich. Assets haben einen Preis, Nachrichten haben nur Reihenfolge und Berechtigungen. Das eine lässt sich wenigstens beobachten; sobald das andere durcheinander gerät, ist es ein Vertragsbruch, den man sogar beim Gegenüber nicht mehr festnageln kann. DYOR – mach deine Hausaufgaben selbst, hör nicht nur auf das, was ich hier so aus dem Bauch erzähle.
In dem Architekturdiagramm von @Dusk steht es ganz offen: Die Bridge transportiert gleichzeitig zwei Dinge, DUSK und die Nachricht. Das eine hat On-Chain Gas, Guthaben und Bestätigungen – wie eine Fahrspur mit klar angeschriebenem Preis. Das andere ist eher wie ein Feldweg auf der Brücke, für den niemand extra separat bezahlt wird; wenn da etwas schiefgeht, weiß man nicht, wer dafür verantwortlich ist.
Welche Rolle DUSK in diesem System hat, muss man nicht lange erklären: Die Execution-Layer verbraucht es, und L1 und DuskEVM müssen es hin und her „mitnehmen“. Jede Bewegung – Transaktion, Abwicklung, Vertragsaufruf – kostet $DUSK . Deshalb kann man seinen Wert grundsätzlich an den Durchsatz koppeln. Aber Nachrichten sind keine Tokens. Sie können Cross-Chain-Aufrufe sein, Autorisierungen, Statusänderungen oder irgendeine Art von Anweisungen, die zwingend in einer bestimmten Reihenfolge ausgeführt werden müssen.
Die Unterlagen erkennen im Wesentlichen nur die Art an, wie Dusk-Verträge den Aufrufer identifizieren – anders als bei Ethereum. Die Bridge-Semantik und die Wert-Erfassung müssen für Dusk angepasst werden. Aber die Zustellgarantien für diese Nachrichten, der Schutz vor Replay-Angriffen, die Regeln zur Reihenfolge sowie die Fehlerpfade werden kaum ausgeführt. Denk mal drüber nach: In regulierten Finanzsystemen ist das genau die tödlichste Blindstelle. Wenn bei einer Geldüberweisung etwas schiefgeht, kann es oft zurückgebucht werden; aber wenn eine Anweisung heimlich zweimal ausgeführt wird, lässt sich die Verantwortung nicht mehr „zurückspulen“.
Ist das nicht eher der Bereich, der mit mehr Strenge geprüft werden sollte als die Assets? Ganz ehrlich: DUSK zahlt man für die „Geld-Fahrspur“ mit, aber es kann die „Nachrichten-Fahrspur“ nicht automatisch garantieren. Wer Coins hält, kauft Netzwerkberechnung – nicht die Abrechnungs-/Haftungsverantwortung für die Bridge-Nachrichten. Wenn wirklich etwas schiefgeht, muss möglicherweise die Anwendung, der Nutzer oder irgendein unglücklicher Dritter die Lücke schließen. DUSK-Gas wird nicht einfach zu einer Entschädigungszusage.
#dusk
Ich habe mir das angesehen: Die echten Minen in einem Cross-Chain-System liegen oft nicht im Asset-Bereich, sondern im Nachrichtenbereich. Assets haben einen Preis, Nachrichten haben nur Reihenfolge und Berechtigungen. Das eine lässt sich wenigstens beobachten; sobald das andere durcheinander gerät, ist es ein Vertragsbruch, den man sogar beim Gegenüber nicht mehr festnageln kann. DYOR – mach deine Hausaufgaben selbst, hör nicht nur auf das, was ich hier so aus dem Bauch erzähle.
