Ich habe „unveränderlich“ früher als Beruhigung betrachtet. Code wird deployed, die Regeln sind fest, niemand mischt sich ein. Dann sitzt man mit einer Bindung, die zwanzig Jahre leben muss. In diesem Zeitraum taucht ein Bug auf, ein Gesetz ändert sich, ein Fehler muss korrigiert werden. Unveränderlicher Code lässt sich nicht patchen. Die Funktion wird zur Falle.
Also fügen Teams still und leise Aufrüstbarkeit hinzu – Admin-Keys, ein Governance-Votum, das die Logik austauschen kann. Und jetzt hast du genau das wieder eingeführt, was Unveränderlichkeit eigentlich abstellen sollte: jemanden, der die Regeln deines Assets umschreiben kann, nachdem du es gekauft hast. Unveränderlich und aufrüstbar sind Gegensätze, und ein langfristiges, reguliertes Asset scheint beides zu brauchen.
Das heißt: Die ehrliche Frage war nie „Ist es unveränderlich?“ Sie lautet „Wer kann den Code ändern, und wirst du es rechtzeitig sehen?“ Ein stiller Admin-Key ist eine Hintertür mit Markenaufdruck.
Hier muss so eine Kette wie @Dusk vorsichtig sein. Regeln, die nur im Asset leben, helfen nur, wenn Änderungen begrenzt, versioniert, sichtbar sind – eine rechtmäßige Änderung, nicht ein Tausch durch einen versteckten Key. Die Kette muss es unmöglich machen, zu verstecken, wer was geändert hat.
Ich bleibe skeptisch. Die meisten „upgradeable“ Contracts stützen sich auf dünne Multisigs – ein einziger Kompromiss kann alles kippen. Und eine Governance, die langsam genug ist, um sicher zu sein, ist möglicherweise zu langsam für einen Bug, der aktiv weiter blutet.
Wer braucht das? Emittenten von Assets, die länger über ihre erste Codebasis hinaus existieren. Was es zerstört: versteckte Keys oder Governance, die zu langsam für einen Brand ist.
Es lohnt sich, das im Blick zu behalten. Die eigentliche Frage ist, wer den Stift in der Hand hält.
$DUSK #dusk