#termmax @TermMax Wenn der Projektbetreiber mir sagt „Der Kernvertrag ist nicht upgradebar“, werde ich nicht sofort Beifall klatschen. Wenn wirklich ein Bug auftritt, ist „nicht aufrüsten können“ dann nur die Leitplanke – oder wird das Problem einfach fest eingeschlossen? Die Upgrade-Erklärung von TermMax gibt darauf eine relativ klare Antwort: UUPS wird nur bei AccessManager und TermMaxRouter eingesetzt; die Kernlogik der Protokolle liegt nicht im Upgrade-Bereich.
Ich habe mir diese Darstellung der Berechtigungsgrenzen ein paar Mal genauer angesehen und festgestellt, dass sie im Grunde ein Abwägen darstellt. Routing und das Berechtigungssystem müssen Spielraum für spätere Korrekturen haben, während die zentralen Kredit-/Leih-Regeln selbst möglichst nicht so gemacht sind, dass ein Admin sie mal eben schnell ändern kann. Für die Nutzer ist der Nachteil: Wenn eine echte Störung in einer Kernlogik auftritt, kann man nicht darauf hoffen, dass das Backend einfach ein Upgrade ausrollt und alles ist gelöst. Für die Integrationspartner ist der Vorteil: Wenn die Infrastruktur aktualisiert wird, werden die Kreditregeln nicht aus Versehen „mit ausgetauscht“.
Die Schwierigkeiten kommen dann, wenn es am dringendsten ist. Angenommen, der Router-Vertrag entdeckt eine schwerwiegende Sicherheitslücke und der Fix muss erst durch eine 4/6-Multisig laufen; die Nutzer stehen möglicherweise zuerst vor einer Sperrung, warten und müssen anschließend erneut bestätigen. Und wenn das Problem genau in der nicht upgradebaren Kernlogik liegt, bleibt dem Team womöglich nur, die Auswirkungen zu isolieren – statt den Code direkt zu ersetzen. Ausgerechnet dort stoßen Flexibilität und Determinismus im Ernstfall ungebremst aufeinander.
Darum betrachte ich das Upgrade-Design von @TermMax nicht nur danach, „wie viele Signaturen reichen“. Was mich mehr interessiert, ist bei jeder einzelnen Aktualisierung: Welche Ebene wird wirklich berührt – geht es um den Einstieg und die Berechtigungen, oder um die Kernregeln, von denen die Nutzer glauben, dass sie sich nicht ändern würden. Das Vertrauen, das hinter $TMX aufgebaut werden soll, ist nicht das Versprechen, dass nie etwas schiefgeht, sondern dass jeder upgradefähige Bereich von außen gegengeprüft werden kann. #TermMax
Ich habe mir diese Darstellung der Berechtigungsgrenzen ein paar Mal genauer angesehen und festgestellt, dass sie im Grunde ein Abwägen darstellt. Routing und das Berechtigungssystem müssen Spielraum für spätere Korrekturen haben, während die zentralen Kredit-/Leih-Regeln selbst möglichst nicht so gemacht sind, dass ein Admin sie mal eben schnell ändern kann. Für die Nutzer ist der Nachteil: Wenn eine echte Störung in einer Kernlogik auftritt, kann man nicht darauf hoffen, dass das Backend einfach ein Upgrade ausrollt und alles ist gelöst. Für die Integrationspartner ist der Vorteil: Wenn die Infrastruktur aktualisiert wird, werden die Kreditregeln nicht aus Versehen „mit ausgetauscht“.
Die Schwierigkeiten kommen dann, wenn es am dringendsten ist. Angenommen, der Router-Vertrag entdeckt eine schwerwiegende Sicherheitslücke und der Fix muss erst durch eine 4/6-Multisig laufen; die Nutzer stehen möglicherweise zuerst vor einer Sperrung, warten und müssen anschließend erneut bestätigen. Und wenn das Problem genau in der nicht upgradebaren Kernlogik liegt, bleibt dem Team womöglich nur, die Auswirkungen zu isolieren – statt den Code direkt zu ersetzen. Ausgerechnet dort stoßen Flexibilität und Determinismus im Ernstfall ungebremst aufeinander.
Darum betrachte ich das Upgrade-Design von @TermMax nicht nur danach, „wie viele Signaturen reichen“. Was mich mehr interessiert, ist bei jeder einzelnen Aktualisierung: Welche Ebene wird wirklich berührt – geht es um den Einstieg und die Berechtigungen, oder um die Kernregeln, von denen die Nutzer glauben, dass sie sich nicht ändern würden. Das Vertrauen, das hinter $TMX aufgebaut werden soll, ist nicht das Versprechen, dass nie etwas schiefgeht, sondern dass jeder upgradefähige Bereich von außen gegengeprüft werden kann. #TermMax