Was meine Aufmerksamkeit geweckt hat, ist, dass Dusk’s Boreas-Upgrade die fehlgeschlagene Ausführung von Verträgen sichtbarer gemacht hat – nicht weniger.
Seit der Boreas-Deployment auf dem Mainnet am 10. Juni 2026 bei Block 4.414.095 können rückgängig gemachte Vertragsevents weiterhin in Archivdaten mit einem expliziten „reverted“-Marker aufbewahrt werden. Gleichzeitig werden diese fehlgeschlagenen Events aus dem kanonischen Block-Bloom entfernt, und zurückgesetzte Stake-Events werden von Aktualisierungen des Provisioner-States ausgeschlossen.
Dieser Unterschied ist wichtiger, als er zunächst wirkt.
Ein zurückgesetzter Aufruf sollte den kanonischen State nicht ändern. Aber für finanzielle Anwendungen kann das vollständige Löschen der Event-Spur das Debugging, die Abstimmung (Reconciliation) und die forensische Prüfung erschweren. Dusk trennt „dieses Event ist während der Ausführung passiert“ von „dieses Event ist Teil des gültigen States geworden“.
Ich hatte erwartet, dass eine datenschutzorientierte Kette die beibehaltenen Ausführungsdetails minimiert. Stattdessen bewahrt die DuskFoundation eine klarere Audit-Spur für fehlgeschlagene Vertragstätigkeiten auf und hält dabei das kanonische Indexing sauber.
Meine Interpretation: Das ist eine kleine Protokolldetailfrage mit ungewöhnlich starker Relevanz für regulierte Onchain-Finanzen. Nachvollziehbarkeit (Auditability) geht nicht nur darum, erfolgreiche Überweisungen zu sehen; sie bedeutet auch, nachzuweisen, was fehlgeschlagen ist, und sicherzustellen, dass es den State niemals kontaminiert hat.
Die Frage, die ich beobachte: Werden Explorer und institutionelle Tools diese Metadaten zu zurückgesetzten Events klar genug sichtbar machen, damit Nutzer davon profitieren können?
@Dusk $DUSK #dusk
Seit der Boreas-Deployment auf dem Mainnet am 10. Juni 2026 bei Block 4.414.095 können rückgängig gemachte Vertragsevents weiterhin in Archivdaten mit einem expliziten „reverted“-Marker aufbewahrt werden. Gleichzeitig werden diese fehlgeschlagenen Events aus dem kanonischen Block-Bloom entfernt, und zurückgesetzte Stake-Events werden von Aktualisierungen des Provisioner-States ausgeschlossen.
Dieser Unterschied ist wichtiger, als er zunächst wirkt.
Ein zurückgesetzter Aufruf sollte den kanonischen State nicht ändern. Aber für finanzielle Anwendungen kann das vollständige Löschen der Event-Spur das Debugging, die Abstimmung (Reconciliation) und die forensische Prüfung erschweren. Dusk trennt „dieses Event ist während der Ausführung passiert“ von „dieses Event ist Teil des gültigen States geworden“.
Ich hatte erwartet, dass eine datenschutzorientierte Kette die beibehaltenen Ausführungsdetails minimiert. Stattdessen bewahrt die DuskFoundation eine klarere Audit-Spur für fehlgeschlagene Vertragstätigkeiten auf und hält dabei das kanonische Indexing sauber.
Meine Interpretation: Das ist eine kleine Protokolldetailfrage mit ungewöhnlich starker Relevanz für regulierte Onchain-Finanzen. Nachvollziehbarkeit (Auditability) geht nicht nur darum, erfolgreiche Überweisungen zu sehen; sie bedeutet auch, nachzuweisen, was fehlgeschlagen ist, und sicherzustellen, dass es den State niemals kontaminiert hat.
Die Frage, die ich beobachte: Werden Explorer und institutionelle Tools diese Metadaten zu zurückgesetzten Events klar genug sichtbar machen, damit Nutzer davon profitieren können?
@Dusk $DUSK #dusk