Concours de sécurité : focus développeurs sur l’audit de fusaka

À retenir

• Un concours d’audit doté de 2 millions de dollars a été lancé pour durcir le code de l’upgrade Fusaka.
• L’opération vise les composants nouveaux : PeerDAS (échantillonnage de disponibilité des données), la gestion des blobs et un precompile pour la courbe secp256r1.
• Le concours court quatre semaines, a débuté le 15 septembre et se termine mi-octobre, avant une mise en production visée en novembre.

Le réseau se prépare à une mise à jour majeure et la stratégie choisie met l’accent sur l’audit ouvert et la participation de la communauté de sécurité. Pour les développeurs et ingénieurs d’infrastructure, c’est une occasion d’examiner en profondeur des primitives protocolaires nouvelles et sensibles — pas seulement des contrats utilisateurs.

Le détail technique

Fusaka introduit plusieurs changements bas niveau qui touchent directement la propagation et la validation des blocs. Parmi eux, PeerDAS (data availability sampling, soit un mécanisme d’échantillonnage pour vérifier la disponibilité des données) vise à rendre plus efficace la preuve que les données d’un bloc sont réellement disponibles sans télécharger l’intégralité du blob. Les blobs sont des unités de données étendues permettant d’augmenter la capacité d’onchain data, cruciales pour certains cas d’usage comme les rollups.

Autres éléments ciblés : l’augmentation progressive des limites de gas pour tester l’échelle, et un precompile secp256r1 (une implémentation native pour la courbe elliptique secp256r1) destinée à accélérer les opérations cryptographiques pour certains wallets ou standards. Ces composants, à l’intersection réseau/crypto, demandent une approche d’audit spécifique : fuzzing réseau, simulations de partitionnement, tests de compatibilité des precompiles et revue cryptographique formelle.

Calendrier et prochaines étapes

Le concours d’audit dure quatre semaines et se déroule avant la phase finale de testnet. Les rapports de vulnérabilité sont triés rapidement : un juge principal évalue la sévérité, puis les issues sont attribuées aux équipes responsables du sous-système concerné pour correction. Pendant la période de test, des devnets sont relancés fréquemment afin de pousser progressivement les limites (par exemple en augmentant agressivement les blobs et le gas) et détecter les regressions opérationnelles.

Les équipes d’implémentation publient des correctifs en continu ; le cycle est donc court entre découverte, triage et patch. Pour un développeur, cela signifie qu’un PoC (proof of concept) bien documenté et reproductible augmente fortement la valeur d’un rapport.

Risques et limites

L’ouverture d’un concours sur du code de protocole soulève des défis particuliers. Les guidelines d’audit traditionnelles sont souvent conçues pour des applications (dApps) et doivent être adaptées aux primitives de chaîne. De plus, travailler simultanément avec plusieurs équipes d’implémentation complique la coordination du triage et des backports.

Côté technique, les risques à surveiller incluent les comportements en réseau non déterministes (orphan blocks, latences exacerbées par des builders MEV — maximal extractable value — mal configurés), les régressions de consensus lors d’augmentation des blobs, et les erreurs cryptographiques autour du precompile secp256r1. Enfin, un concours attire l’attention — positive comme critique — mais n’exempte pas d’une vérification additionnelle par audits formels et tests de mise en production.

Pour les contributeurs : ciblez les scénarios de bord (partition réseau, adversaire actif injectant données non disponibles, saturation de validators) et fournissez des reproductions faciles à exécuter. C’est en multipliant ces vérifications que l’écosystème maximise les chances d’un déploiement propre.

Partager sur vos réseaux !