#dusk $DUSK @Dusk ........Ich erwartete, dass Boreas Dusk schneller und sauberer macht. Die tiefere Veränderung war schwerer zu bemerken: Sie änderte die Regeln dafür, was das Netzwerk als gültige Transaktion betrachtet.
Stell dir eine Blockchain wie ein Regelwerk für einen Schiedsrichter vor. Ein Software-Upgrade ist nicht wichtig, weil der Schiedsrichter schneller läuft. Es ist wichtig, wenn sich die Regeln selbst ändern und jeder Knoten das Spiel auf die gleiche Weise interpretieren muss.....
Genau das hat Boreas getan.
Mit Rusk 1.7 führte Dusk eine explizite Versionierung zwischen eingehenden Transaktionen, ihrer kanonischen Form und dem ein, was schließlich im Ledger festgeschrieben wird. Die Gasabrechnung wurde zudem fork-bewusst: Die Ressourcen-Kosten für Vorgänge wie Hashing und kryptografische Verifikation sind an die jeweils aktiven Protokollregeln gekoppelt.......
Es ging noch tiefer.
Boreas änderte die Reihenfolge der Zustandsübergänge, machte rückgängig gemachte Contract-Events für Archiv-Nutzer explizit und schuf eine klare Protokollgrenze für das ältere Transaktionsverhalten. Am wichtigsten war jedoch: Phoenix-Transaktionen wurden im Zuge des Neustarts am 10. Juni auf Dusk Mainnet bei Block 4.414.095 deaktiviert, während das Testnet sie während einer Testphase beibehielt, bevor sie dort am 7. August bei Block 4.000.000 deaktiviert wurden. Historische Phoenix-Daten bleiben weiterhin abspielbar.....
Dieser letzte Punkt hat meine Aufmerksamkeit erregt.
Ein reifes Netzwerk geht nicht nur darum, neue Funktionen hinzuzufügen. Manchmal besteht das wichtige Upgrade darin zu entscheiden, was das Protokoll aufhören sollte zu tun – und dabei gleichzeitig genug Historie zu bewahren, sodass die Kette weiterhin reproduzierbar bleibt.......
Und da mit Rusk v1.7.1 nun die neueste gelistete Veröffentlichung vorliegt, wirkt die Engineering-Arbeit an Dusk weniger wie ein einzelnes Upgrade und mehr wie eine fortlaufende Verschärfung der Regeln unterhalb des Finanz-Stacks.
Für regulierte Märkte: Ist vorhersehbares Protokollverhalten nicht genauso wichtig wie das Hinzufügen neuer Funktionalität?
$ACE $BTW
Stell dir eine Blockchain wie ein Regelwerk für einen Schiedsrichter vor. Ein Software-Upgrade ist nicht wichtig, weil der Schiedsrichter schneller läuft. Es ist wichtig, wenn sich die Regeln selbst ändern und jeder Knoten das Spiel auf die gleiche Weise interpretieren muss.....
Genau das hat Boreas getan.
Mit Rusk 1.7 führte Dusk eine explizite Versionierung zwischen eingehenden Transaktionen, ihrer kanonischen Form und dem ein, was schließlich im Ledger festgeschrieben wird. Die Gasabrechnung wurde zudem fork-bewusst: Die Ressourcen-Kosten für Vorgänge wie Hashing und kryptografische Verifikation sind an die jeweils aktiven Protokollregeln gekoppelt.......
Es ging noch tiefer.
Boreas änderte die Reihenfolge der Zustandsübergänge, machte rückgängig gemachte Contract-Events für Archiv-Nutzer explizit und schuf eine klare Protokollgrenze für das ältere Transaktionsverhalten. Am wichtigsten war jedoch: Phoenix-Transaktionen wurden im Zuge des Neustarts am 10. Juni auf Dusk Mainnet bei Block 4.414.095 deaktiviert, während das Testnet sie während einer Testphase beibehielt, bevor sie dort am 7. August bei Block 4.000.000 deaktiviert wurden. Historische Phoenix-Daten bleiben weiterhin abspielbar.....
Dieser letzte Punkt hat meine Aufmerksamkeit erregt.
Ein reifes Netzwerk geht nicht nur darum, neue Funktionen hinzuzufügen. Manchmal besteht das wichtige Upgrade darin zu entscheiden, was das Protokoll aufhören sollte zu tun – und dabei gleichzeitig genug Historie zu bewahren, sodass die Kette weiterhin reproduzierbar bleibt.......
Und da mit Rusk v1.7.1 nun die neueste gelistete Veröffentlichung vorliegt, wirkt die Engineering-Arbeit an Dusk weniger wie ein einzelnes Upgrade und mehr wie eine fortlaufende Verschärfung der Regeln unterhalb des Finanz-Stacks.
Für regulierte Märkte: Ist vorhersehbares Protokollverhalten nicht genauso wichtig wie das Hinzufügen neuer Funktionalität?
$ACE $BTW