Gestern Abend habe ich die offizielle Seite mit den Contract-Adressen von Anfang bis Ende durchgesehen: Hinter jedem Contract steht jeweils eine Versionsnummer. Die Planung für das Sepolia-Testnetz und das Mainnet ist in jeweils zwei Zeilen getrennt. Die Seite ist kurz, aber die Informationsdichte ist hoch – und schon die Adressen selbst sind ein Beleg: Test-Assets und echte Assets werden bereits am Eingang getrennt.
Drei Komponenten – „Vault Registry“, „ProtocolParams“ und „Adapter“ – hängen jeweils an drei Gruppen von Kennungen: die Version des „Vault Core“, die Version der Offline-Parameter und die Version der beteiligten Teilnehmermenge. Zuerst habe ich diese Nummern nicht ernst genommen; ich dachte, Versionsnummern seien Sache der Entwickler. @BabylonLabs_io
Später, als ich die Beschreibungen beider Umgebungen nebeneinander las, wurde mir klar, worauf sie fest „verriegelt“: Bei der Registrierung eines Vault wird nach den Bindungsregeln versioniert; ein einziger Vault ist seit dem Zeitpunkt seiner Erstellung untrennbar mit genau diesem Parametersatz verknüpft – spätere Upgrades dürfen die Regeln, die damals galten, nicht stillschweigend ändern.
Hinter Versionsnummern folgen üblicherweise Datum und Deployment-Notizen; vor und nach dem Upgrade kann man die Unterschiede Schritt für Schritt vergleichen. Die Deployment-Parameter für die zwei Umgebungen – Testnetz und Mainnet – haben jeweils eigene Werte. Genau deshalb müssen die Versionsfelder separat geführt werden. Die Versionsverriegelung zieht ein konkretes Problem nach sich: Der im Testnetz verifizierte Ablauf lässt sich nicht 1:1 auf die Mainnet-Adresse übertragen, sondern muss erneut durch Deployment und Verifikation gehen. Die offizielle Trennung beider Umgebungen in zwei Listen ist selbst schon eine Warnung: In einer Asset-Umgebung ist jede Deployment-Variante eine eigenständige Vertrauensgrenze. Was im Testnetz validiert wurde, beweist auch nur Verhalten der Testnetz-Contracts. $BABY
Früher hielt ich es für selbstverständlich, dass man, wenn das Testnetz durchläuft, direkt ins Mainnet gehen kann – erst beim erneuten Durchlesen wurde mir klar, welchen Wert die Umgebungs-Tags und Versionsnummern auf der Adressseite haben: Sie sind nicht weniger wert als Funktionsdokumente. Die eigentliche Schlussfolgerung lautet: Lies die TBV-Unterlagen, bestätige zuerst, welche Umgebung gemeint ist, schaue dann auf die Versionsnummer und erst danach auf die Funktionsbeschreibung. Zwischen der Testnetz-Adresse und der Mainnet-Adresse liegt nicht nur eine einzige Aktion mit einem Klick, sondern das gesamte Paket aus Deployment und Verifikation. In der Ökologie ist die Isolation der Umgebungen kein Versehen, sondern Design.
Zurück zu dieser Adresse-Seite von gestern Abend: Zwei Zeilen Adressen bedeuten zwei Welten. Umgebungs-Tags und Versionsnummern sind es wert, zuerst gelesen zu werden – mehr als die Funktionsbeschreibung. #baby
Drei Komponenten – „Vault Registry“, „ProtocolParams“ und „Adapter“ – hängen jeweils an drei Gruppen von Kennungen: die Version des „Vault Core“, die Version der Offline-Parameter und die Version der beteiligten Teilnehmermenge. Zuerst habe ich diese Nummern nicht ernst genommen; ich dachte, Versionsnummern seien Sache der Entwickler. @BabylonLabs_io
Später, als ich die Beschreibungen beider Umgebungen nebeneinander las, wurde mir klar, worauf sie fest „verriegelt“: Bei der Registrierung eines Vault wird nach den Bindungsregeln versioniert; ein einziger Vault ist seit dem Zeitpunkt seiner Erstellung untrennbar mit genau diesem Parametersatz verknüpft – spätere Upgrades dürfen die Regeln, die damals galten, nicht stillschweigend ändern.
Hinter Versionsnummern folgen üblicherweise Datum und Deployment-Notizen; vor und nach dem Upgrade kann man die Unterschiede Schritt für Schritt vergleichen. Die Deployment-Parameter für die zwei Umgebungen – Testnetz und Mainnet – haben jeweils eigene Werte. Genau deshalb müssen die Versionsfelder separat geführt werden. Die Versionsverriegelung zieht ein konkretes Problem nach sich: Der im Testnetz verifizierte Ablauf lässt sich nicht 1:1 auf die Mainnet-Adresse übertragen, sondern muss erneut durch Deployment und Verifikation gehen. Die offizielle Trennung beider Umgebungen in zwei Listen ist selbst schon eine Warnung: In einer Asset-Umgebung ist jede Deployment-Variante eine eigenständige Vertrauensgrenze. Was im Testnetz validiert wurde, beweist auch nur Verhalten der Testnetz-Contracts. $BABY
Früher hielt ich es für selbstverständlich, dass man, wenn das Testnetz durchläuft, direkt ins Mainnet gehen kann – erst beim erneuten Durchlesen wurde mir klar, welchen Wert die Umgebungs-Tags und Versionsnummern auf der Adressseite haben: Sie sind nicht weniger wert als Funktionsdokumente. Die eigentliche Schlussfolgerung lautet: Lies die TBV-Unterlagen, bestätige zuerst, welche Umgebung gemeint ist, schaue dann auf die Versionsnummer und erst danach auf die Funktionsbeschreibung. Zwischen der Testnetz-Adresse und der Mainnet-Adresse liegt nicht nur eine einzige Aktion mit einem Klick, sondern das gesamte Paket aus Deployment und Verifikation. In der Ökologie ist die Isolation der Umgebungen kein Versehen, sondern Design.
Zurück zu dieser Adresse-Seite von gestern Abend: Zwei Zeilen Adressen bedeuten zwei Welten. Umgebungs-Tags und Versionsnummern sind es wert, zuerst gelesen zu werden – mehr als die Funktionsbeschreibung. #baby