Ich habe mir die Protokolländerungen angesehen, die von #Dusk vorgenommen wurden, und eine Einzelheit in Boreas hat meine Aufmerksamkeit erregt.
Boreas war keine Funktion.
Boreas ging darum sicherzustellen, dass das Netzwerk Transaktionen so interpretiert, wie.
Boreas führte Grenzen ein zwischen dem, wie Transaktionen akzeptiert werden – von Clients dargestellt in Rusk – und dem, wie sie im Ledger gespeichert werden.
Das klingt nach Engineering.
Ich glaube, Boreas ist wichtiger, als es aussieht.
Eine Transaktion durchläuft verschiedene Phasen, bevor sie Teil der historischen Kettendaten wird: Ingress, Mempool-Handling, Blockproduktion, Konsensvalidierung und schließlich Replay.
Wenn unterschiedliche Teile des Knotens die Bytes unterschiedlich interpretieren, ist das Problem nicht nur eine fehlgeschlagene Transaktion.
Es kann zu einem Konsistenzproblem werden.
Boreas begegnet dem, indem es zustands-/versionsbewusstes Decoding an der Netzwerkgrenze verwendet und Transaktionen kanonisiert, bevor sie in Blöcke übernommen werden.
Das Interessante ist, dass Dusk auch Decoder beibehält, damit ältere Blöcke weiterhin korrekt wiedergegeben werden können.
So ist das Design nicht einfach: „das Transaktionsformat ändern“.
Es ist eher: „die Regeln ändern, ohne dass alte Historie mehrdeutig wird“.
Das ist eine Anforderung für ein Netzwerk, das dazu gedacht ist, langlebige finanzielle Infrastruktur zu unterstützen.
Das lässt mich Protokoll-Updates aus einer anderen Perspektive betrachten.
Ein erfolgreicher Hard Fork geht nicht nur darum, neue Fähigkeiten hinzuzufügen.
Es geht auch darum sicherzustellen, dass jede Ebene darüber übereinstimmt, was die Transaktion bedeutet.
Was ich jetzt beobachte, ist, ob diese Art von Protokolldisziplin robust bleibt, während Dusk Ausführungspfade und Finanzanwendungen hinzufügt.
Denn Komplexität verschwindet nicht, wenn man eine Blockchain modularisiert.
Sie verlagert sich nur zu den Grenzen zwischen den Modulen.
#dusk $DUSK @Dusk
Boreas war keine Funktion.
Boreas ging darum sicherzustellen, dass das Netzwerk Transaktionen so interpretiert, wie.
Boreas führte Grenzen ein zwischen dem, wie Transaktionen akzeptiert werden – von Clients dargestellt in Rusk – und dem, wie sie im Ledger gespeichert werden.
Das klingt nach Engineering.
Ich glaube, Boreas ist wichtiger, als es aussieht.
Eine Transaktion durchläuft verschiedene Phasen, bevor sie Teil der historischen Kettendaten wird: Ingress, Mempool-Handling, Blockproduktion, Konsensvalidierung und schließlich Replay.
Wenn unterschiedliche Teile des Knotens die Bytes unterschiedlich interpretieren, ist das Problem nicht nur eine fehlgeschlagene Transaktion.
Es kann zu einem Konsistenzproblem werden.
Boreas begegnet dem, indem es zustands-/versionsbewusstes Decoding an der Netzwerkgrenze verwendet und Transaktionen kanonisiert, bevor sie in Blöcke übernommen werden.
Das Interessante ist, dass Dusk auch Decoder beibehält, damit ältere Blöcke weiterhin korrekt wiedergegeben werden können.
So ist das Design nicht einfach: „das Transaktionsformat ändern“.
Es ist eher: „die Regeln ändern, ohne dass alte Historie mehrdeutig wird“.
Das ist eine Anforderung für ein Netzwerk, das dazu gedacht ist, langlebige finanzielle Infrastruktur zu unterstützen.
Das lässt mich Protokoll-Updates aus einer anderen Perspektive betrachten.
Ein erfolgreicher Hard Fork geht nicht nur darum, neue Fähigkeiten hinzuzufügen.
Es geht auch darum sicherzustellen, dass jede Ebene darüber übereinstimmt, was die Transaktion bedeutet.
Was ich jetzt beobachte, ist, ob diese Art von Protokolldisziplin robust bleibt, während Dusk Ausführungspfade und Finanzanwendungen hinzufügt.
Denn Komplexität verschwindet nicht, wenn man eine Blockchain modularisiert.
Sie verlagert sich nur zu den Grenzen zwischen den Modulen.
#dusk $DUSK @Dusk
