Ce qui m’a fait réfléchir en examinant la sécurité de Bedrock, c’est la différence entre un rapport d’audit et les risques qui subsistent ensuite. Je me penchais sur Bedrock, $BR , #Bedrock , @Bedrock _DeFi, et un détail revenait sans cesse : qui contrôle réellement les contrats en cas de problème ?
Le dossier de sécurité de Trustblock, mis à jour le 11 octobre, répertorie un audit de PeckShield sur uniBTC daté du 1er octobre 2024. Il signale également un problème non résolu de gravité moyenne concernant les clés d’administration. Cela ne signifie pas automatiquement que les fonds sont en danger, mais cela m’incite à ne pas m’arrêter au mot « audité ». Un audit est un instantané du code examiné, pas une garantie permanente couvrant chaque action privilégiée ou toute modification future du contrat.
Trustblock
D’habitude, je consulte d’abord l’audit, puis je passe à autre chose. Cette fois, je me suis arrêté pour réfléchir aux autorisations dont dépend le système. La documentation de Bedrock indique que ses contrats intelligents sont open source, ce qui facilite leur examen indépendant, mais la visibilité et le contrôle sont deux choses différentes.
Bedrock Technology
Cette distinction compte davantage lorsque les utilisateurs déposent des actifs dans un système de restaking que lorsqu’ils interagissent simplement avec une application ordinaire. Je voudrais comprendre précisément quelles actions d’administration restent possibles, qui peut les autoriser et quelles protections existent en cas d’abus de ces autorisations. Un ancien audit accompagné d’un signalement de risque actuel ne suffit pas à évaluer l’ensemble du protocole, mais il me laisse une question : dans quelle mesure les personnes capables de modifier le système sont-elles soumises à des contraintes indépendantes ?