L’équipe Aave s’associe à Sherlock pour la mise à niveau V4 à travers trois phases distinctes : un audit collaboratif en plusieurs phases mené aux côtés de Blackthorn, un concours d’audit de 365 000 $ et un programme continu de bug bounty couvrant le code en direct après le lancement. Pour l’un des changements architecturaux les plus importants de l’histoire d’Aave, la couverture de sécurité ne s’arrête pas à l’examen préalable au lancement. Il s’étend du déploiement aux opérations en direct.
Pourquoi la V4 a besoin de ce niveau de couverture
Aave V4 introduit une architecture Hub-and-Spoke ainsi qu’un nouveau système de prime de risque. Il ne s’agit pas de modifications incrémentielles du code existant. Ils représentent une refonte fondamentale de la manière dont le protocole achemine les risques de liquidité et de prix sur ses marchés.
Une nouvelle architecture signifie de nouvelles surfaces d’attaque, et de nouvelles surfaces d’attaque dans un protocole gérant des milliards de fonds d’utilisateurs signifient que la marge pour les problèmes manqués est effectivement nulle.
Sherlock est spécifiquement amené à approfondir les parties de la V4 qui sont entièrement nouvelles. Un audit standard couvre ce qui existe. Ce dont Aave a besoin pour la V4, c’est d’une couverture qui comprend ce que les nouveaux composants sont censés faire, comment ils interagissent avec le code existant et où la nouvelle conception crée une exposition que les cadres d’audit précédents n’ont pas été conçus pour capturer.
Trois phases, une couche de sécurité continue
L’audit collaboratif en plusieurs phases avec Blackthorn constitue la base. Plutôt qu’un examen en une seule étape, la structure permet aux conclusions des premières phases d’éclairer la portée des phases ultérieures. À mesure que les composants de la V4 se développent et s’intègrent, le processus d’audit s’adapte plutôt que de traiter la base de code comme un artefact fini.
Le concours d’audit de 365 000 $ ouvre le code à un champ plus large de chercheurs en sécurité indépendants ayant une peau financière dans le jeu. L’audit par concours fait systématiquement ressortir des problèmes que les audits traditionnels en entreprise négligent, car la structure d’incitation récompense la découverte de vulnérabilités réelles plutôt que de remplir une liste de contrôle.
À 365 000 $, la cagnotte est suffisamment importante pour attirer des chercheurs sérieux qui la considèrent comme un engagement professionnel plutôt que comme un effort secondaire.
Le programme Bug Bounty étend la couverture au-delà de la date de lancement. C’est la partie que la plupart des processus d’audit sautent complètement. Le code qui réussit l’examen préalable au lancement est toujours confronté à des conditions réelles, à de nouveaux modèles de transactions et à des scénarios d’interaction qu’aucun audit n’anticipe pleinement. Un bug bounty en direct maintient active l’incitation financière à la divulgation responsable après le déploiement, ce qui signifie que la couche de sécurité n’expire pas au moment où les utilisateurs commencent à interagir avec la V4.
L’architecture Hub-and-Spoke et pourquoi elle est au centre de nos préoccupations
Le modèle Hub-and-Spoke est au cœur de ce qui rend la V4 différente sur le plan architectural des versions précédentes d’Aave. Il centralise certaines fonctions de protocole au niveau du hub tout en permettant aux marchés individuels de fonctionner comme des rayons avec leurs propres paramètres.
Le système de prime de risque s’ajoute à cela, ajustant dynamiquement les coûts d’emprunt en fonction du profil de risque spécifique de chaque actif et de la configuration du marché.
Les deux composants sont suffisamment nouveaux pour qu’il n’y ait aucun historique d’audit antérieur sur lequel s’appuyer. L’accent mis par Sherlock sur ces domaines reflète un principe de sécurité simple : le code le plus récent et le plus complexe comporte le risque résiduel le plus élevé, et c’est là que doit se concentrer un examen indépendant. Le travail collaboratif avec Blackthorn permet aux deux sociétés de recouper les résultats sur des composants pour lesquels les angles morts d’un seul évaluateur pourraient avoir de réelles conséquences.
Ce que signifie réellement la sécurité du cycle de vie complet
Le modèle de Sherlock va au-delà des audits ponctuels de par sa conception. La structure en trois phases sur Aave V4 est un exemple de ce à quoi cela ressemble dans la pratique : une couverture qui commence pendant le développement, s’intensifie au stade de pré-lancement grâce à un examen concurrentiel, et se poursuit ensuite dans les opérations en direct grâce à des primes incitatives continues.
Pour un protocole à l’échelle d’Aave, cette approche reflète une vision réaliste de l’endroit où les failles de sécurité se produisent réellement. Les audits préalables au lancement en détectent beaucoup. Ils ne captent pas tout.
La combinaison d’un audit professionnel, d’un concours participatif et d’une prime post-lancement crée des couches superposées qui couvrent différents modes de défaillance à différentes étapes de la vie du protocole.
Conclusion
Le processus de sécurité d’Aave V4 avec Sherlock mérite qu’on s’y intéresse en tant que modèle. Trois phases, deux avant le lancement et une après le lancement, couvrant les composants les plus novateurs du protocole sur le plan architectural avec une combinaison d’examen par des experts, de concours ouvert et de surveillance en direct. Pour les protocoles qui embarquent une infrastructure véritablement nouvelle, il s’agit du type de couverture qui correspond au profil de risque réel de ce qui est déployé. Le partenariat d’Aave V4 avec la plateforme DeFi de Sherlock dans le cadre d’un audit collaboratif, d’un concours de 365 000 $ et d’une prime aux bogues en direct a établi une nouvelle barre en matière de sécurité des protocoles. Lorsque l’architecture est entièrement nouvelle, le processus de sécurité doit être adapté.
