#bedrock $BR Vor einiger Zeit ist mir etwas ziemlich Peinliches passiert. Ein DeFi-Protokoll gab eine Ankündigung heraus, dass die Verträge aktualisiert werden sollen, und forderte die Nutzer auf, ihre Liquidität manuell zu migrieren. Ich habe die Anleitung befolgt – aber im Rahmen der Autorisierung ist etwas schiefgelaufen. Nachdem ich eine Gas-Gebühr verbrannt hatte, schlug die Migration fehl. Ein zweiter Versuch scheiterte ebenfalls. Schließlich habe ich in der Community nachgefragt und festgestellt: Das war kein Einzelfall, sondern ein Kompatibilitätsproblem bei Vertrags-Updates. Ich habe über eine halbe Stunde herumprobiert, bis es endlich geklappt hat. Seitdem bin ich bei den vier Worten „Protokoll-Upgrade“ deutlich vorsichtiger.
$ETH
Später habe ich mir dann die Doku von @Bedrock angeschaut und gezielt nach dem Mechanismus für Contract Upgrades gesucht.
In der Architektur von Bedrock 2.0 können zentrale Verträge wie die Emissionslogik von uniBTC und brBTC nicht einfach beliebig ausgetauscht werden. Die Upgrade-Berechtigungen liegen bei einem Multi-Sig, und der Multi-Sig ist nicht Bedrock selbst. Bei jedem Upgrade müssen mehrere unabhängige Parteien mit ihrer Unterschrift gemeinsam zustimmen, damit es ausgeführt werden kann. Dieses System kann das Risiko von „Fehlverhalten seitens des Projekts“ zwar nicht vollständig ausschließen, aber es erhöht zumindest die Hürde. Eine Person allein reicht nicht – es müssen mehrere zustimmen.
Was mich besonders aufmerksam gemacht hat: Bedrock macht bei Upgrades viele Parameter nicht austauschbar, sondern konfigurierbar. Was heißt das? Wenn manche Protokolle nur einen einzigen Renditeparameter ändern wollen, müssen sie gleich den gesamten Vertrag ersetzen – das ist riskanter und komplizierter in der Umsetzung. Bedrock hat schon beim Design gängige Parameter wie Gebühren, Anreizverteilung und Pool-Gewichte als konfigurierbare Optionen umgesetzt. Durch Governance-Votings können sie angepasst werden, ohne dass man am Kernvertrag etwas ändern muss. So bleibt die Flexibilität erhalten, und gleichzeitig wird die Angriffsfläche durch Upgrades reduziert.
Ich habe mir auch seine historischen Auditberichte angesehen. Die Kernverträge von Bedrock wurden von mehreren Audit-Firmen im Wechsel geprüft, unter anderem von SlowMist und CertiK. Audits können zwar nie garantieren, dass es zu 100 % keine Schwachstellen gibt, aber mehrere Runden zeigen zumindest, dass das Team bei Sicherheit nicht gespart hat. $BTC
Noch ein Detail: Bedrock hat einen Time-Lock für Contract Upgrades. Für jedes Update, das nicht als Notfall gilt, wird nach der Auslösung eine gewisse Verzögerung benötigt, bis es wirksam wird. Dieses Zeitfenster gibt der Community Zeit zu reagieren. Wenn es bei einem Upgrade-Vorschlag Streit oder Kontroversen gibt, kann die Community in dieser Phase Probleme entdecken und Einspruch erheben. Solche Designs sind im DeFi-Bereich nicht völlig ungewöhnlich, aber wirklich konsequent umgesetzte Projekte sind eher selten.
$ETH
Später habe ich mir dann die Doku von @Bedrock angeschaut und gezielt nach dem Mechanismus für Contract Upgrades gesucht.
In der Architektur von Bedrock 2.0 können zentrale Verträge wie die Emissionslogik von uniBTC und brBTC nicht einfach beliebig ausgetauscht werden. Die Upgrade-Berechtigungen liegen bei einem Multi-Sig, und der Multi-Sig ist nicht Bedrock selbst. Bei jedem Upgrade müssen mehrere unabhängige Parteien mit ihrer Unterschrift gemeinsam zustimmen, damit es ausgeführt werden kann. Dieses System kann das Risiko von „Fehlverhalten seitens des Projekts“ zwar nicht vollständig ausschließen, aber es erhöht zumindest die Hürde. Eine Person allein reicht nicht – es müssen mehrere zustimmen.
Was mich besonders aufmerksam gemacht hat: Bedrock macht bei Upgrades viele Parameter nicht austauschbar, sondern konfigurierbar. Was heißt das? Wenn manche Protokolle nur einen einzigen Renditeparameter ändern wollen, müssen sie gleich den gesamten Vertrag ersetzen – das ist riskanter und komplizierter in der Umsetzung. Bedrock hat schon beim Design gängige Parameter wie Gebühren, Anreizverteilung und Pool-Gewichte als konfigurierbare Optionen umgesetzt. Durch Governance-Votings können sie angepasst werden, ohne dass man am Kernvertrag etwas ändern muss. So bleibt die Flexibilität erhalten, und gleichzeitig wird die Angriffsfläche durch Upgrades reduziert.
Ich habe mir auch seine historischen Auditberichte angesehen. Die Kernverträge von Bedrock wurden von mehreren Audit-Firmen im Wechsel geprüft, unter anderem von SlowMist und CertiK. Audits können zwar nie garantieren, dass es zu 100 % keine Schwachstellen gibt, aber mehrere Runden zeigen zumindest, dass das Team bei Sicherheit nicht gespart hat. $BTC
Noch ein Detail: Bedrock hat einen Time-Lock für Contract Upgrades. Für jedes Update, das nicht als Notfall gilt, wird nach der Auslösung eine gewisse Verzögerung benötigt, bis es wirksam wird. Dieses Zeitfenster gibt der Community Zeit zu reagieren. Wenn es bei einem Upgrade-Vorschlag Streit oder Kontroversen gibt, kann die Community in dieser Phase Probleme entdecken und Einspruch erheben. Solche Designs sind im DeFi-Bereich nicht völlig ungewöhnlich, aber wirklich konsequent umgesetzte Projekte sind eher selten.