#bedrock $BR Il y a quelque temps, j’ai vécu une situation assez gênante. Un certain protocole DeFi a publié une annonce indiquant qu’il fallait mettre à niveau le contrat, et demandait aux utilisateurs de migrer manuellement leur liquidité. J’ai suivi le tutoriel, mais lors de l’étape d’autorisation, il y a eu un problème : après qu’une facture de gas a été brûlée, la migration a échoué. J’ai réessayé une deuxième fois, et ça a encore échoué. Finalement, j’ai demandé autour de moi dans le groupe, et j’ai découvert que ce n’était pas un cas isolé : le problème venait de la compatibilité lors des mises à niveau des contrats. J’ai dû passer plus d’une demi-heure à m’en sortir, et depuis, quand j’entends « mise à niveau du protocole », je me méfie davantage. $ETH
Plus tard, en lisant la documentation de @Bedrock , je me suis renseigné spécifiquement sur son mécanisme de mise à niveau des contrats.
Dans l’architecture de Bedrock 2.0, la logique d’émission des contrats principaux, comme uniBTC et brBTC, n’est pas faite pour être remplacée arbitrairement. Les droits de mise à niveau sont détenus par un multisig, et le multisig n’est pas un membre de Bedrock lui-même. À chaque mise à niveau, plusieurs parties indépendantes doivent signer ensemble pour que l’exécution puisse avoir lieu. Ce mécanisme ne peut pas totalement éliminer le risque de « mauvaise intention » de la part du projet, mais il augmente au moins le seuil. Une seule personne ne suffit pas : il faut qu’un groupe soit d’accord.
Ce qui m’a aussi particulièrement attiré l’attention, c’est que, lors des mises à niveau, Bedrock transforme beaucoup de paramètres en éléments configurables plutôt qu’en éléments remplaçables. Concrètement : certains protocoles doivent modifier un paramètre de taux de rendement, et doivent alors remplacer tout le contrat, ce qui implique des risques plus élevés et une opération plus complexe. Dès la conception, Bedrock a prévu de rendre configurables des paramètres courants comme les frais, la répartition des incitations, et les pondérations des pools. On peut les ajuster via des votes de gouvernance, sans toucher au contrat central. Ainsi, on conserve la flexibilité tout en réduisant l’exposition aux risques liés aux mises à niveau.
J’ai parcouru ses rapports d’audit historiques. Les contrats centraux de Bedrock ont fait l’objet d’audits croisés menés par plusieurs sociétés d’audit, dont SlowMist et CertiK. Un audit ne garantit pas à 100 % l’absence de failles, mais plusieurs tours d’audit indiquent au moins que l’équipe ne bâcle pas l’investissement en sécurité. $BTC
Un autre détail : le time-lock de mise à niveau des contrats chez Bedrock. Pour toute mise à niveau non urgente, une fois déclenchée, il faut un certain délai avant qu’elle prenne effet. Cette fenêtre laisse du temps à la communauté pour réagir. Si une proposition de mise à niveau suscite une controverse, la communauté peut repérer des problèmes pendant cette période et y faire objection. Ce type de conception n’est pas rare dans le domaine DeFi, mais les projets qui l’appliquent avec une vraie rigueur ne sont pas si nombreux.
Plus tard, en lisant la documentation de @Bedrock , je me suis renseigné spécifiquement sur son mécanisme de mise à niveau des contrats.
Dans l’architecture de Bedrock 2.0, la logique d’émission des contrats principaux, comme uniBTC et brBTC, n’est pas faite pour être remplacée arbitrairement. Les droits de mise à niveau sont détenus par un multisig, et le multisig n’est pas un membre de Bedrock lui-même. À chaque mise à niveau, plusieurs parties indépendantes doivent signer ensemble pour que l’exécution puisse avoir lieu. Ce mécanisme ne peut pas totalement éliminer le risque de « mauvaise intention » de la part du projet, mais il augmente au moins le seuil. Une seule personne ne suffit pas : il faut qu’un groupe soit d’accord.
Ce qui m’a aussi particulièrement attiré l’attention, c’est que, lors des mises à niveau, Bedrock transforme beaucoup de paramètres en éléments configurables plutôt qu’en éléments remplaçables. Concrètement : certains protocoles doivent modifier un paramètre de taux de rendement, et doivent alors remplacer tout le contrat, ce qui implique des risques plus élevés et une opération plus complexe. Dès la conception, Bedrock a prévu de rendre configurables des paramètres courants comme les frais, la répartition des incitations, et les pondérations des pools. On peut les ajuster via des votes de gouvernance, sans toucher au contrat central. Ainsi, on conserve la flexibilité tout en réduisant l’exposition aux risques liés aux mises à niveau.
J’ai parcouru ses rapports d’audit historiques. Les contrats centraux de Bedrock ont fait l’objet d’audits croisés menés par plusieurs sociétés d’audit, dont SlowMist et CertiK. Un audit ne garantit pas à 100 % l’absence de failles, mais plusieurs tours d’audit indiquent au moins que l’équipe ne bâcle pas l’investissement en sécurité. $BTC
Un autre détail : le time-lock de mise à niveau des contrats chez Bedrock. Pour toute mise à niveau non urgente, une fois déclenchée, il faut un certain délai avant qu’elle prenne effet. Cette fenêtre laisse du temps à la communauté pour réagir. Si une proposition de mise à niveau suscite une controverse, la communauté peut repérer des problèmes pendant cette période et y faire objection. Ce type de conception n’est pas rare dans le domaine DeFi, mais les projets qui l’appliquent avec une vraie rigueur ne sont pas si nombreux.