Ich ging davon aus, dass die Bedeutung einer Transaktion in dem Moment feststeht, in dem ihre Bytes existieren: Einmal decodieren, überall die gleiche Antwort erhalten. Dusk-eigener Rusk-Change-Log für das Boreas-Upgrade behandelt das als etwas, das man gezielt entwickeln muss, nicht als etwas, das man einfach voraussetzen darf.
Boreas hat versionenabhängiges Decoding von Transaktionen hinzugefügt, das an einen konkreten Hardfork gebunden ist, plus eine hardfork-gesteuerte Auswahl des Formats dafür, wie alte Blöcke beim Replay erneut abgespielt werden. Der Codebestand hat nun zwei explizit getrennte Typen, CanonicalTransaction und LedgerTransaction: Sie trennen die In-Memory-Darstellung einer Transaktion von dem Format, in dem sie tatsächlich im Ledger gespeichert wird. Sogar ein eigener Regressionstest existiert, der ausschließlich dafür da ist, Transaktionen vor der Aegis-Ära beim Block-Serialisieren korrekt zu decodieren.
Das wird erst dann nötig, wenn das Decoding von Transaktionen unterschiedliche Protokoll-Epochen und Verarbeitungsstufen berücksichtigen muss: frisch vom Draht von einem Client, im Speicher als kanonisches Objekt abgelegt und anschließend aus einem Block wiedergegeben, der die aktuellen Regeln noch nicht kannte.
Das bedeutet: Ein Protokoll-Upgrade ist nicht schon deshalb sicher, weil neue Transaktionen unter den neuen Regeln funktionieren. Es ist nur dann sicher, wenn diese neuen Regeln nicht still und heimlich die Fähigkeit zerstören, den alten Ledger-Zustand korrekt unter den Regeln zu replizieren, die ihn hervorgebracht haben. Genau diese Klasse von Versions-Mismatch-Fehlern – die historische-Replay-Kompatibilität und das hardfork-gesteuerte Decoding – sollen verhindern.
„Eine Transaktion ist nur dann zuverlässig, wenn jede Stufe, die sie berührt, sich darüber einig ist, was sie bedeutet.“
Was ich tatsächlich sehen möchte: Ein echter Block aus der Zeit vor Aegis, der auf einem aktuellen Knoten neu abgespielt wird, ohne daran etwas zu ändern, wie seine historischen Transaktionen unter den jeweils anwendbaren Regeln decodiert werden – nicht nur ein isolierter, kurzer Regressionstest.
#dusk $DUSK @Dusk
Boreas hat versionenabhängiges Decoding von Transaktionen hinzugefügt, das an einen konkreten Hardfork gebunden ist, plus eine hardfork-gesteuerte Auswahl des Formats dafür, wie alte Blöcke beim Replay erneut abgespielt werden. Der Codebestand hat nun zwei explizit getrennte Typen, CanonicalTransaction und LedgerTransaction: Sie trennen die In-Memory-Darstellung einer Transaktion von dem Format, in dem sie tatsächlich im Ledger gespeichert wird. Sogar ein eigener Regressionstest existiert, der ausschließlich dafür da ist, Transaktionen vor der Aegis-Ära beim Block-Serialisieren korrekt zu decodieren.
Das wird erst dann nötig, wenn das Decoding von Transaktionen unterschiedliche Protokoll-Epochen und Verarbeitungsstufen berücksichtigen muss: frisch vom Draht von einem Client, im Speicher als kanonisches Objekt abgelegt und anschließend aus einem Block wiedergegeben, der die aktuellen Regeln noch nicht kannte.
Das bedeutet: Ein Protokoll-Upgrade ist nicht schon deshalb sicher, weil neue Transaktionen unter den neuen Regeln funktionieren. Es ist nur dann sicher, wenn diese neuen Regeln nicht still und heimlich die Fähigkeit zerstören, den alten Ledger-Zustand korrekt unter den Regeln zu replizieren, die ihn hervorgebracht haben. Genau diese Klasse von Versions-Mismatch-Fehlern – die historische-Replay-Kompatibilität und das hardfork-gesteuerte Decoding – sollen verhindern.
„Eine Transaktion ist nur dann zuverlässig, wenn jede Stufe, die sie berührt, sich darüber einig ist, was sie bedeutet.“
Was ich tatsächlich sehen möchte: Ein echter Block aus der Zeit vor Aegis, der auf einem aktuellen Knoten neu abgespielt wird, ohne daran etwas zu ändern, wie seine historischen Transaktionen unter den jeweils anwendbaren Regeln decodiert werden – nicht nur ein isolierter, kurzer Regressionstest.
#dusk $DUSK @Dusk
