Assurance continue de l'intégrité du protocole blockchain par les primitives open source et les programmes de récompense de bugs @immunefi, @commonwarexyz, @arbitrum L'intégrité d'un protocole blockchain n'est pas une propriété qui peut être achevée par une seule vérification ou une évaluation à un moment donné, mais plutôt une caractéristique qui doit être constamment maintenue et surveillée au fil du temps. Les systèmes blockchain modernes sont constitués de nombreux composants interconnectés, et en particulier dans les solutions d'extension comme les rollups, l'environnement d'exécution, les ponts, les séquenceurs et les mécanismes de vérification sont étroitement interdépendants. Dans un tel environnement, même si le code est soigneusement écrit, de nouvelles vulnérabilités peuvent apparaître en raison des mises à jour, des changements de configuration ou des modifications des structures d'incitations économiques. En conséquence, les audits ponctuels, bien qu'utiles pour vérifier l'état du code à un moment donné, présentent des limites évidentes pour assurer à long terme l'intégrité globale du protocole. Les cas d'application d'Arbitrum illustrent bien cette réalité. La pile de production d'Arbitrum comprend l'environnement d'exécution Nitro, les contrats de preuve en une étape, l'infrastructure de ponts gérant les transferts d'actifs entre les couches, la logique du séquenceur déterminant l'ordre des transactions, et le mécanisme de preuve de fraude. Ces éléments ne sont pas indépendants, mais interagissent pour former un système unique. La mise à jour ArbOS 31 Bianca en mars 2024 a eu un impact simultané sur Arbitrum One et Arbitrum Nova, démontrant comment une mise à jour unique peut entraîner des changements en chaîne à travers plusieurs composants du réseau. De plus, Arbitrum a effectué six mises à jour majeures d'ArbOS entre 2024 et 2026, et a maintenu un cycle de développement rapide, intégrant les versions de testnet sur le mainnet en un délai relativement court. Cette rapidité crée un environnement difficile à suivre pour les processus d'audit traditionnels, ce qui peut entraîner des périodes où du code non encore audité est utilisé en production. De plus, il a été démontré à plusieurs reprises que la simple revue du code n'est pas suffisante pour prédire efficacement les attaques qui peuvent survenir dans le réseau. Les attaques sur le pont Wormhole en février 2022 et la vulnérabilité du pont Polygon Plasma en décembre 2021 ont toutes deux eu lieu dans des codes audités, et les attaquants ont trouvé des chemins d'attaque dynamiques en exploitant les incitations économiques plutôt que des défauts de code. Cela montre clairement que l'intégrité du protocole ne se limite pas à la correction syntaxique du code, mais englobe également les structures économiques, les modes d'opération et les processus de gouvernance. Dans ce contexte, la réutilisation de primitives blockchain open source s'est positionnée comme un pilier de la stratégie de sécurité. L'approche dite d'« anti-framework » proposée par Commonware consiste à décomposer les fonctionnalités fondamentales du réseau, du consensus, de la cryptographie, du stockage et des tests en primitives modulaires. Ces primitives sont implémentées sous forme de bibliothèques en Rust, et comprennent des composants tels que la communication P2P certifiée, des algorithmes de consensus tolérants aux fautes byzantines, la génération de signatures seuil et de nombres aléatoires, des interfaces de stockage abstraites, ainsi que des composants de runtime pour la simulation déterministe. Chaque primitive est classée selon un niveau de stabilité (alpha, bêta, gamma, delta, epsilon), ce classement étant basé sur l'étendue des tests et l'expérience d'utilisation en production. Le principal avantage de la réutilisation de primitives est la réduction des risques d'implémentation. Par exemple, en utilisant une primitive de consensus déjà vérifiée mathématiquement au lieu d'implémenter soi-même un consensus tolérant aux fautes byzantines, on peut réduire les erreurs d'implémentation récurrentes. De plus, les primitives hautement stables ont des cibles d'audit et de bug bounty clairement définies, permettant de concentrer les ressources de sécurité sur les logiques critiques. L'environnement de simulation déterministe fourni par le runtime Commonware permet de reproduire les conditions du réseau et d'effectuer des tests de régression entre les versions, ce qui joue un rôle important dans la préservation de l'intégrité lors des mises à jour. Cependant, cette approche comporte également un autre type de risque. Si plusieurs protocoles partagent la même primitive, une vulnérabilité unique peut affecter l'ensemble de l'écosystème, créant un risque de monétisation structurelle. Pour atténuer cela, Commonware a introduit un système de niveaux de stabilité, a clairement séparé les interfaces, et encourage la concurrence entre les implémentations pour les mêmes interfaces.Cependant, il est incontestable que les risques peuvent se concentrer au niveau de la conception, ce qui soulève l'importance croissante d'une détection continue des vulnérabilités. Dans l'environnement des rollups, la surface sur laquelle l'intégrité du protocole est requise est très vaste. Dans le cas d'Arbitrum, le contrat Nitro Prover peut contenir des erreurs mathématiques ou des problèmes de calcul du gaz, tandis que le contrat de pont reliant L1 et L2 comporte des risques critiques tels que le vol de fonds ou le blocage des retraits. La logique du séquenceur implique la possibilité de rechercher des profits injustes par censure ou réorganisation des transactions, et le mécanisme de gouvernance peut également être exposé à des attaques telles que la manipulation des propositions ou l'évitement des verrous temporels. En outre, du point de vue opérationnel, des facteurs tels qu'une interruption du séquenceur, une échec de gestion des clés, ou l'absence de surveillance affectent directement l'intégrité. Pour détecter continuellement ces divers risques, les programmes de chasse aux bugs jouent un rôle important. Le programme de chasse aux bugs d'Immunefi classe la gravité selon l'impact, et pour des vulnérabilités critiques telles que le vol de fonds ou l'interruption du réseau, il propose un pourcentage déterminé des actifs à risque comme récompense. Cette approche est conçue pour que les récompenses augmentent en parallèle avec l'échelle du réseau, alignant ainsi à long terme les incitations entre les chercheurs et le protocole. De plus, via la procédure de divulgation responsable, les vulnérabilités sont divulguées uniquement après leur correction, minimisant ainsi les dommages pour les utilisateurs. Cependant, le programme de chasse aux bugs ne couvre pas tous les risques. Les attaques économiques telles que l'extraction de MEV ou les erreurs de conception des incitations, les scénarios exploitant les procédures de gouvernance, ou les erreurs opérationnelles sont souvent hors de portée. En effet, l'incident Wormhole illustre clairement que même avec des récompenses massives, l'incident lui-même n'a pas pu être complètement évité. Cela suggère que bien que le programme de chasse aux bugs soit un élément de sécurité important, il ne constitue pas une solution complète en soi. La combinaison de primitives open source et de programmes de chasse aux bugs forme un système de cycle de vie pour assurer l'intégrité. Les primitives deviennent des cibles pour la vérification externe et les revues basées sur les récompenses à mesure que leur niveau de stabilité augmente, réduisant ainsi la probabilité d'erreurs à l'étape d'implémentation. Le périmètre du programme de chasse aux bugs d'Arbitrum est actuellement limité aux versions déployées, incitant ainsi les chercheurs à se concentrer sur les codes réellement exposés à des risques. Lorsqu'une vulnérabilité est découverte, elle est intégrée dans les tests de simulation pour éviter qu'elle ne se reproduise dans les versions futures. Dans ce processus, les limites de responsabilité doivent également être clairement comprises. Le responsable de la maintenance des primitives doit garantir la précision et la compatibilité dans la portée des interfaces, tandis que l'intégrateur assume la responsabilité de les combiner et les exploiter de manière sécurisée dans l'environnement réel. Bien que les licences open source limitent la responsabilité juridique, la garantie réelle de l'intégrité dépend de cette répartition des rôles et de la coopération. La coordination entre les projets est également nécessaire lors de la divulgation des vulnérabilités et de la distribution des correctifs. Le processus de gouvernance et les mises à jour constituent également un élément clé pour maintenir l'intégrité. Arbitrum gère les risques liés aux mises à jour via des verrous temporels sur les propositions constitutionnelles, des périodes de défi des messages L1, des pouvoirs d'urgence du comité de sécurité, et une procédure de déploiement progressif via le testnet. Ces procédures peuvent être interprétées comme une tentative de maintenir un équilibre entre une réponse rapide et la décentralisation. En fin de compte, les primitives open source de la blockchain et les programmes de chasse aux bugs continus permettent une approche selon laquelle l'intégrité du protocole est un processus continu plutôt qu'une certification ponctuelle. Les primitives réduisent les erreurs d'implémentation répétées, tandis que les programmes de chasse aux bugs incitent à une vérification externe constante via des incitations économiques. L'expérience d'Arbitrum montre comment cette combinaison fonctionne dans un réseau à grande échelle, illustrant clairement que l'intégrité n'est pas un état fixe, mais une propriété qui doit être constamment vérifiée et maintenue. $ARB $ETH $XRP $POL