#dusk $DUSK @Dusk Ich war heute Morgen halb mit meinem ersten Kaffee, als mich ein Gedanke an Blockchain-Unveränderlichkeit zu stören begann. Die Historie bleibt On-chain, aber die Regeln, die verwendet werden, um neue Blöcke zu verarbeiten, entwickeln sich weiter.
Das brachte mich dazu, die Upgrades von Dusk anders zu betrachten. Normalerweise verbinde ich ein Protokoll-Upgrade mit neuen Fähigkeiten. Boreas hat mich auf eine weniger sichtbare Anforderung aufmerksam gemacht. Neue Transaktionsregeln müssen sich weiterentwickeln, ohne die Art zu ändern, wie ältere Blöcke unter den Regeln interpretiert werden, die sie hervorgebracht haben.
Boreas führte eine separate Handhabung für Client-Transaktionen, kanonische Transaktionsdaten und das Ledger-Format ein, das in Blöcke übernommen wird. Rusk behält außerdem die historischen Decodierer bei, die nötig sind, um Pre-Aegis- und Pre-Boreas-Blöcke erneut abzuspielen. Aegis macht etwas Ähnliches bei der Proof-Verifizierung. Rusk wählt den Verifizierer anhand der Blockhöhe: Dabei bleiben die PLONK V1/V2-Regeln für historische Blöcke erhalten, während für neuere Beweise V3 verwendet wird.
Dieser eine Detailpunkt hat bei mir den Groschen zum Klicken gebracht. Eine alte Transaktion On-chain beizubehalten bewahrt zwar das Protokoll, aber es bewahrt nicht automatisch die Fähigkeit, nachzuvollziehen, warum diese Transaktion gültig war.
Daher sehe ich historische Semantik als einen echten Bestandteil von Unveränderlichkeit. Die Kette muss nicht nur bewahren, was passiert ist, sondern auch genug Protokollkontext, um zu reproduzieren, wie dieser historische Zustand validiert wurde.
Es gibt jedoch einen Trade-off. Das Beibehalten alter Decodierer und Verifizierungspfade bedeutet, mehr Protokollkomplexität in die Zukunft mitzuschleppen. Aber wenn man sie entfernt, verlagert man ein anderes Risiko auf zukünftige Software: Sie muss für sich selbst entscheiden, wie historische Aufzeichnungen interpretiert werden sollen.
An genau dieser Stelle wird das für mich mehr als nur ein Problem der Software-Wartung.
In regulierten Märkten sollte Nachvollziehbarkeit mehr beantworten als „Zeig mir die Transaktion“. Sie sollte auch beantworten: Welche Regeln machten diese Transaktion zu diesem Zeitpunkt in der Kette gültig?
Je tiefer ich in die Protokollentwicklung einsteige, desto mehr denke ich, dass Unveränderlichkeit eine zweite Anforderung hat — neben dem Bewahren der Historie.
Wenn der Datensatz überlebt, aber die Regeln, die nötig sind, um seine Bedeutung zu reproduzieren, nicht, wie unveränderlich ist diese Geschichte dann wirklich? 🧩
$FF $P
Das brachte mich dazu, die Upgrades von Dusk anders zu betrachten. Normalerweise verbinde ich ein Protokoll-Upgrade mit neuen Fähigkeiten. Boreas hat mich auf eine weniger sichtbare Anforderung aufmerksam gemacht. Neue Transaktionsregeln müssen sich weiterentwickeln, ohne die Art zu ändern, wie ältere Blöcke unter den Regeln interpretiert werden, die sie hervorgebracht haben.
Boreas führte eine separate Handhabung für Client-Transaktionen, kanonische Transaktionsdaten und das Ledger-Format ein, das in Blöcke übernommen wird. Rusk behält außerdem die historischen Decodierer bei, die nötig sind, um Pre-Aegis- und Pre-Boreas-Blöcke erneut abzuspielen. Aegis macht etwas Ähnliches bei der Proof-Verifizierung. Rusk wählt den Verifizierer anhand der Blockhöhe: Dabei bleiben die PLONK V1/V2-Regeln für historische Blöcke erhalten, während für neuere Beweise V3 verwendet wird.
Dieser eine Detailpunkt hat bei mir den Groschen zum Klicken gebracht. Eine alte Transaktion On-chain beizubehalten bewahrt zwar das Protokoll, aber es bewahrt nicht automatisch die Fähigkeit, nachzuvollziehen, warum diese Transaktion gültig war.
Daher sehe ich historische Semantik als einen echten Bestandteil von Unveränderlichkeit. Die Kette muss nicht nur bewahren, was passiert ist, sondern auch genug Protokollkontext, um zu reproduzieren, wie dieser historische Zustand validiert wurde.
Es gibt jedoch einen Trade-off. Das Beibehalten alter Decodierer und Verifizierungspfade bedeutet, mehr Protokollkomplexität in die Zukunft mitzuschleppen. Aber wenn man sie entfernt, verlagert man ein anderes Risiko auf zukünftige Software: Sie muss für sich selbst entscheiden, wie historische Aufzeichnungen interpretiert werden sollen.
An genau dieser Stelle wird das für mich mehr als nur ein Problem der Software-Wartung.
In regulierten Märkten sollte Nachvollziehbarkeit mehr beantworten als „Zeig mir die Transaktion“. Sie sollte auch beantworten: Welche Regeln machten diese Transaktion zu diesem Zeitpunkt in der Kette gültig?
Je tiefer ich in die Protokollentwicklung einsteige, desto mehr denke ich, dass Unveränderlichkeit eine zweite Anforderung hat — neben dem Bewahren der Historie.
Wenn der Datensatz überlebt, aber die Regeln, die nötig sind, um seine Bedeutung zu reproduzieren, nicht, wie unveränderlich ist diese Geschichte dann wirklich? 🧩
$FF $P
