Ich denke immer wieder über zwei Transaktionstypen nach, die Dusk in Rusk eingeführt hat: CanonicalTransaction und LedgerTransaction.
Sie repräsentieren unterschiedliche Schichten derselben Transaktion. CanonicalTransaction ist die Form, mit der Rusk logisch arbeitet, während LedgerTransaction diese Transaktion in der Ledger-Darstellung einhüllt, die von einer bestimmten Protokollversion benötigt wird. Die Spannung besteht darin, dass Dusk möchte, dass sich diese Speicherformate weiterentwickeln, ohne die Bedeutung einer Transaktion mit ihnen mitentwickeln zu müssen – eine wichtige Eigenschaft, da das Unternehmen darauf hinarbeitet, Finanzmärkte onchain mit EU-lizenzierten Institutionen zu bringen. Was ich noch nicht weiß, ist, ob diese Trennung Versionsänderungen tatsächlich innerhalb von Rusk eingrenzen wird oder ob sich Formatänderungen dennoch auf Wallets, Anwendungen und das historische Replay auswirken werden.
Die Details, auf die man achten sollte, sind, wie Dusk eingehende Transaktionen normalisiert, die richtige Ledger-Darstellung auswählt und ältere Transaktionen nach Protokoll-Upgrades interpretiert.
Eine Wallet, die auch nach einem Upgrade weiterhin Transaktionen einreicht, ist ein nützlicher Beleg für Kompatibilität. Der stärkere Test ist, ob Dusk die Darstellung darunter ändern kann, während die gleiche Transaktionssemantik darüber erhalten bleibt.
Ich würde diese Abstraktion danach beurteilen, wie wenig die Anwendungen über die Versionierungskomplexität wissen müssen.
Die Frage ist, ob Dusk wirklich getrennt hat, was eine Transaktion bedeutet, und wie das Ledger sie speichert, oder ob die Last der Versionsverwaltung lediglich an eine andere Stelle im Stack verschoben wurde.
Ich beobachte, wie sich diese Grenze bei zukünftigen Formatänderungen und beim historischen Replay bewährt.
#dusk $DUSK @Dusk
Sie repräsentieren unterschiedliche Schichten derselben Transaktion. CanonicalTransaction ist die Form, mit der Rusk logisch arbeitet, während LedgerTransaction diese Transaktion in der Ledger-Darstellung einhüllt, die von einer bestimmten Protokollversion benötigt wird. Die Spannung besteht darin, dass Dusk möchte, dass sich diese Speicherformate weiterentwickeln, ohne die Bedeutung einer Transaktion mit ihnen mitentwickeln zu müssen – eine wichtige Eigenschaft, da das Unternehmen darauf hinarbeitet, Finanzmärkte onchain mit EU-lizenzierten Institutionen zu bringen. Was ich noch nicht weiß, ist, ob diese Trennung Versionsänderungen tatsächlich innerhalb von Rusk eingrenzen wird oder ob sich Formatänderungen dennoch auf Wallets, Anwendungen und das historische Replay auswirken werden.
Die Details, auf die man achten sollte, sind, wie Dusk eingehende Transaktionen normalisiert, die richtige Ledger-Darstellung auswählt und ältere Transaktionen nach Protokoll-Upgrades interpretiert.
Eine Wallet, die auch nach einem Upgrade weiterhin Transaktionen einreicht, ist ein nützlicher Beleg für Kompatibilität. Der stärkere Test ist, ob Dusk die Darstellung darunter ändern kann, während die gleiche Transaktionssemantik darüber erhalten bleibt.
Ich würde diese Abstraktion danach beurteilen, wie wenig die Anwendungen über die Versionierungskomplexität wissen müssen.
Die Frage ist, ob Dusk wirklich getrennt hat, was eine Transaktion bedeutet, und wie das Ledger sie speichert, oder ob die Last der Versionsverwaltung lediglich an eine andere Stelle im Stack verschoben wurde.
Ich beobachte, wie sich diese Grenze bei zukünftigen Formatänderungen und beim historischen Replay bewährt.
#dusk $DUSK @Dusk