Contournement du goulot d'étranglement de Bitcoin : Guide complet d'audit des technologies de mise à l'échelle BTC Layer2
TechFlow SélectionTechFlow Sélection
Contournement du goulot d'étranglement de Bitcoin : Guide complet d'audit des technologies de mise à l'échelle BTC Layer2
Les technologies telles que le Lightning Network, les sidechains et les Rollups sont collectivement appelées solutions de mise à l'échelle de la couche 2 (Layer 2) pour BTC.
Dédié à des analyses Web3 approfondiesRédaction : Beosin
Bitcoin (BTC), en tant que première monnaie numérique au monde, est progressivement devenu la pierre angulaire des actifs numériques et de la finance décentralisée depuis son apparition en 2009. Cependant, avec l'augmentation du nombre d'utilisateurs et du volume des transactions, les problèmes liés au réseau BTC deviennent de plus en plus évidents, principalement visibles à travers les points suivants :
-
Frais de transaction élevés : Lorsque le réseau Bitcoin est congestionné, les utilisateurs doivent payer des frais plus élevés pour garantir une confirmation rapide de leurs transactions.
-
Délai de confirmation des transactions : La blockchain Bitcoin génère en moyenne un nouveau bloc toutes les 10 minutes, ce qui signifie que les transactions sur chaîne nécessitent généralement plusieurs confirmations de blocs avant d'être considérées comme définitives.
-
Limites des contrats intelligents : Le langage script de Bitcoin est fonctionnellement limité, rendant difficile la mise en œuvre de contrats intelligents complexes.
Dans cet article, nous regroupons sous le terme « solutions de mise à échelle BTC Layer2 » des technologies telles que le réseau Lightning, les sidechains et les Rollups. Ces solutions permettent d’effectuer des transactions rapides et peu coûteuses tout en préservant la décentralisation et la sécurité du réseau BTC. L'introduction de ces technologies Layer2 améliore la vitesse des transactions, réduit les coûts, optimise l'expérience utilisateur et étend la capacité du réseau, offrant ainsi un soutien technique crucial et une orientation innovante pour l'avenir du BTC.
Réseau Lightning
Le concept initial du réseau Lightning était appelé « canal de paiement ». Son principe repose sur la mise à jour continue de l'état d'une transaction non confirmée via le remplacement de transactions, jusqu'à ce qu'elle soit finalement diffusée sur le réseau Bitcoin. Dès la création du Bitcoin par Satoshi Nakamoto en 2009, l'idée de canaux de paiement a été proposée, et un brouillon de code implémentant cette fonctionnalité a été inclus dans Bitcoin 1.0. Ce brouillon permettait aux utilisateurs de mettre à jour l’état d’une transaction avant sa confirmation par le réseau. Toutefois, ce n’est qu’avec la publication du livre blanc intitulé « The Bitcoin Lightning Network: Scalable Off-Chain Instant Payment » que le réseau Lightning a véritablement vu le jour et s’est imposé dans le paysage général.
Aujourd’hui, les solutions pratiques basées sur les canaux de paiement et le réseau Lightning sont très matures. À ce jour, le réseau Lightning compte 13 325 nœuds, 49 417 canaux, et un montant total de BTC verrouillé atteignant 4 975.
https://1ml.com/
Dans le réseau Lightning, assurer la sécurité des actifs des utilisateurs pendant leur transfert est primordial. Nous allons maintenant expliquer le fonctionnement du réseau Lightning et comment il protège la sécurité des actifs des utilisateurs, selon l'échelle des nœuds du réseau.
Les deux parties impliquées soumettent deux transactions au réseau principal Bitcoin : une pour ouvrir le canal, une autre pour le fermer. Ce processus se décompose en trois grandes étapes :
1. Ouverture du canal :
Tout d'abord, les deux participants verrouillent des bitcoins dans un portefeuille multisignature associé au réseau Lightning sur la blockchain BTC. Une fois les bitcoins correctement déposés et verrouillés, le canal de paiement est activé, permettant aux deux parties d'effectuer des transactions hors chaîne via ce canal.
2. Transactions hors chaîne :
Une fois le canal ouvert, tous les transferts entre les utilisateurs sont traités au sein du réseau Lightning. Ces transactions hors chaîne ne sont pas limitées en nombre. Elles n'ont pas besoin d'être immédiatement soumises à la blockchain Bitcoin, mais sont exécutées instantanément grâce au mécanisme hors chaîne du réseau Lightning.
Ce traitement hors chaîne améliore considérablement la rapidité et l'efficacité des transactions, évitant la congestion du réseau principal Bitcoin et ses frais élevés.
3. Fermeture du canal et règlement final :
Lorsqu’un utilisateur décide de quitter le canal, un règlement final du solde est effectué. Ce processus garantit que tous les fonds du canal sont distribués selon le dernier état enregistré. Les deux parties retirent ensuite leur solde final du portefeuille multisignature, reflétant la répartition effective des fonds au moment de la fermeture. Enfin, l’état final de la transaction est soumis à la blockchain Bitcoin.
Les avantages du réseau Lightning sont les suivants :
-
Amélioration de la vitesse des transactions : Le réseau Lightning permet aux utilisateurs d’effectuer des transactions hors chaîne, pouvant être complétées presque instantanément, sans attendre la confirmation des blocs. Cela permet d’atteindre des vitesses de transaction en quelques secondes, améliorant grandement l’expérience utilisateur.
-
Confidentialité renforcée : Les transactions hors chaîne du réseau Lightning ne sont pas enregistrées publiquement sur la chaîne principale Bitcoin, ce qui améliore la confidentialité. Seules l’ouverture et la fermeture du canal sont enregistrées sur la chaîne principale, donc les activités transactionnelles des utilisateurs ne sont pas entièrement exposées.
-
Prise en charge des micropaiements : Le réseau Lightning est particulièrement adapté aux micropaiements fréquents, tels que les paiements pour contenu ou entre dispositifs IoT. Les transactions traditionnelles Bitcoin, à cause de leurs frais élevés, ne conviennent pas à ce type d’usage, alors que le réseau Lightning résout efficacement ce problème.
Les défis auxquels fait face le réseau Lightning :
-
Problème de liquidité : Le réseau Lightning dépend des bitcoins préalablement verrouillés dans les canaux. Cela signifie que les utilisateurs doivent déposer suffisamment de bitcoins dans leurs canaux pour effectuer des transactions. Un manque de liquidité peut entraîner des échecs de paiement, notamment pour des montants importants.
-
Problème de routage : Trouver un chemin efficace entre l’émetteur et le destinataire peut être complexe, surtout lorsque le réseau est vaste. Avec l’augmentation du nombre de nœuds et de canaux, la difficulté d’acheminer correctement les paiements croît également.
-
Problème de confiance dans la gestion des fonds : Les nœuds peuvent être victimes d’attaques malveillantes, et les utilisateurs doivent faire confiance aux nœuds auxquels ils se connectent pour qu’ils ne tentent pas de voler les fonds. La question de la protection contre la fuite des clés privées se pose.
-
Normes techniques et interopérabilité : Différentes implémentations du réseau Lightning doivent adopter des normes et protocoles cohérents pour assurer l’interopérabilité. Actuellement, plusieurs équipes de développement travaillent sur différentes versions, ce qui peut entraîner des problèmes de compatibilité.
-
Problèmes de confidentialité : Bien que le réseau Lightning améliore la confidentialité des transactions Bitcoin, certaines informations peuvent encore être tracées ou analysées. De plus, les opérateurs de nœuds peuvent observer les transactions transitant par leurs nœuds, risquant ainsi de divulguer certaines données confidentielles.
La sécurité du réseau Lightning affecte directement la capacité de mise à l’échelle hors chaîne du Bitcoin et la sécurité des fonds des utilisateurs. Par conséquent, outre les audits standards applicables aux blockchains publiques (voir annexe à la fin de cet article), le réseau Lightning doit prêter attention aux risques de sécurité suivants :
-
Congestion des canaux : Vérifier si la conception du système Lightning est suffisamment robuste pour éviter une congestion due à des attaques malveillantes.
-
Perturbation des canaux : Examiner la sécurité de la structure des canaux afin de prévenir les attaques de perturbation.
-
Verrouillage et déverrouillage des actifs : Auditer les processus de verrouillage et de déverrouillage des actifs dans le réseau Lightning, afin de garantir que les transferts entre chaîne et hors chaîne soient sûrs et fiables lors de l’ouverture ou de la fermeture des canaux.
-
Mise à jour d’état et fermeture forcée : Évaluer le processus de mise à jour d’état des canaux et le mécanisme de fermeture forcée (force-close), afin de garantir qu’en cas d’anomalie, l’état le plus récent puisse être correctement identifié et appliqué.
-
Contrats Time Lock et Hashed Time Lock (HTLC) : Évaluer l’implémentation des HTLC pour s’assurer que les conditions de verrouillage temporel et de hachage s’exécutent correctement, empêchant toute perte de fonds due à des fenêtres temporelles inappropriées.
-
Dépendance au timestamp de la blockchain : Évaluer la dépendance du réseau Lightning aux timestamps de la blockchain Bitcoin, afin d’assurer une coordination correcte entre les temps chaîne et hors chaîne, et de prévenir les attaques temporelles.
-
Sécurité de l’algorithme de routage : Examiner l’efficacité et la sécurité de l’algorithme de routage pour éviter l’exposition de la vie privée des utilisateurs ou la manipulation malveillante des chemins de routage.
-
Stockage des canaux et récupération des données : Vérifier les mécanismes de stockage des canaux et les stratégies de récupération des données, afin de pouvoir restaurer l’état du canal en cas de panne ou de déconnexion accidentelle, évitant ainsi toute perte de fonds.
Sidechain
Contrairement au réseau Lightning, une sidechain est une blockchain indépendante qui fonctionne parallèlement à la chaîne principale (comme la blockchain BTC), et interagit avec elle via un mécanisme d’ancrage bidirectionnel (Two-Way Peg). L’objectif de la sidechain est d’ajouter des fonctionnalités et d’améliorer l’extensibilité sans modifier le protocole de la chaîne principale.
En tant que blockchain autonome, la sidechain dispose de son propre mécanisme de consensus, de ses propres nœuds et de ses règles de traitement des transactions. Elle peut adopter des technologies et protocoles différents de ceux de la chaîne principale, adaptés à des cas d’usage spécifiques. Grâce au mécanisme d’ancrage bidirectionnel (2WP), la sidechain communique avec la chaîne principale, permettant un transfert libre et sécurisé des actifs entre les deux. Le fonctionnement du 2WP est approximativement le suivant :
-
L’utilisateur verrouille des BTC sur la chaîne principale. Une institution de confiance 1 récupère ces informations et utilise la validation SPV 2 pour confirmer que la transaction de verrouillage est bien confirmée.
-
L’institution de confiance émet sur la sidechain un jeton équivalent à l’utilisateur.
-
Après avoir réalisé des transactions libres, l’utilisateur verrouille le solde restant sur la sidechain.
-
L’institution de confiance, après vérification de la légitimité de la transaction, déverrouille et restitue sur la chaîne principale une valeur équivalente en BTC à l’utilisateur.
Note 1 : L'institution de confiance joue un rôle central dans le mécanisme d’ancrage bidirectionnel, en gérant le verrouillage et le déverrouillage des actifs. Elle doit posséder une grande fiabilité et des compétences techniques solides pour garantir la sécurité des actifs des utilisateurs.
Note 2 : La validation SPV permet à un nœud de vérifier la validité d’une transaction spécifique sans télécharger l’intégralité de la blockchain. Un nœud SPV télécharge uniquement les en-têtes de blocs et utilise l’arbre de Merkle pour confirmer qu’une transaction est incluse dans un bloc.
Projets représentatifs de sidechains :
CKB (Nervos Network)
Nervos Network est un écosystème blockchain public open source qui cherche à tirer parti de la sécurité et de la décentralisation du mécanisme de consensus PoW du BTC, tout en introduisant un modèle UTXO plus évolutif et flexible pour traiter les transactions. Son cœur est la Common Knowledge Base (CKB), une blockchain de niveau 1 construite sur RISC-V et utilisant PoW comme consensus. Il étend le modèle UTXO en un modèle Cell, capable de stocker n’importe quel type de données, et supporte l’écriture de scripts dans n’importe quel langage afin d’exécuter des contrats intelligents sur chaîne.
Stacks
Stacks relie chaque bloc Stacks à un bloc Bitcoin via son mécanisme PoX (Proof of Transfer). Pour développer des contrats intelligents, Stacks a conçu un langage de programmation spécifique appelé Clarity. Dans Clarity, la fonction get-burn-block-info? permet d’entrer la hauteur d’un bloc Bitcoin et d’obtenir son hash d’en-tête. En outre, le mot-clé burn-block-height permet d’obtenir la hauteur actuelle de la chaîne Bitcoin. Ces deux fonctions permettent aux contrats intelligents Clarity de lire l’état de la chaîne Bitcoin de base, faisant ainsi des transactions Bitcoin des déclencheurs de contrats. En exécutant automatiquement ces contrats, Stacks étend les fonctionnalités du Bitcoin.
Pour une analyse détaillée de Stacks, veuillez consulter l'article précédent de Beosin : Qu'est-ce que Stacks ? Quels défis potentiels le réseau de deuxième couche de BTC, Stacks, pourrait-il rencontrer ?
Les avantages des sidechains :
-
Les sidechains peuvent expérimenter différentes technologies et protocoles sans affecter la stabilité ni la sécurité de la chaîne principale.
-
Elles peuvent introduire des fonctionnalités absentes de la chaîne principale, comme les contrats intelligents, la protection de la vie privée ou l’émission de jetons, enrichissant ainsi les cas d’usage de l’écosystème blockchain.
Les défis des sidechains :
-
Les sidechains disposent de leur propre mécanisme de consensus, qui peut être moins sûr que celui de la chaîne principale BTC. Si ce mécanisme est faible ou présente des failles, cela peut conduire à des attaques de type 51 % ou autres, compromettant la sécurité des actifs. La sécurité de la chaîne principale BTC repose sur sa puissance de calcul massive et sa large distribution de nœuds, tandis que les sidechains peuvent ne pas atteindre ce même niveau de sécurité.
-
La mise en œuvre du mécanisme d’ancrage bidirectionnel nécessite des algorithmes cryptographiques et des protocoles complexes. Toute vulnérabilité peut entraîner des problèmes lors du transfert d’actifs entre les chaînes, voire des pertes ou vols d’actifs.
-
Pour trouver un équilibre entre rapidité et sécurité, la plupart des sidechains présentent un degré de centralisation supérieur à celui de la chaîne principale.
Un Layer2 étant un système blockchain complet, les audits standards applicables aux blockchains publiques s’appliquent également aux sidechains (voir annexe à la fin de l’article).
En outre, en raison de leurs particularités, les sidechains requièrent des audits supplémentaires :
-
Sécurité du protocole de consensus : Examiner si le protocole de consensus de la sidechain (PoW, PoS, DPoS) a été suffisamment testé et validé, s’il comporte des failles potentielles ou des vecteurs d’attaque tels que les attaques 51 % ou les attaques à long terme.
-
Sécurité des nœuds de consensus : Évaluer la sécurité des nœuds de consensus, y compris la gestion des clés, la protection des nœuds et les sauvegardes redondantes, pour éviter leur compromission ou utilisation abusive.
-
Verrouillage et déverrouillage des actifs : Auditer le mécanisme d’ancrage bidirectionnel entre la sidechain et la chaîne principale, afin de garantir que les contrats intelligents gérant ces opérations sont sûrs et fiables, évitant les doubles dépenses, pertes ou échecs de verrouillage.
-
Validation inter-chaînes : Vérifier l’exactitude et la sécurité du processus de validation inter-chaînes, en s’assurant qu’il est décentralisé et inviolable, empêchant les échecs ou validations malveillantes.
-
Audit du code des contrats : Examiner en profondeur tous les contrats intelligents exécutés sur la sidechain, en particulier ceux impliqués dans les opérations inter-chaînes, pour détecter d’éventuelles vulnérabilités ou portes dérobées.
-
Mécanisme de mise à jour : Vérifier que le mécanisme de mise à jour des contrats est sécurisé, avec des processus appropriés d’audit et de consensus communautaire, pour éviter les mises à jour malveillantes ou altérations.
-
Communication entre nœuds : Examiner le protocole de communication entre les nœuds de la sidechain pour s’assurer qu’il est sécurisé et utilise des canaux chiffrés afin d’éviter les attaques de l’homme du milieu ou les fuites de données.
-
Communication inter-chaînes : Vérifier le canal de communication entre la sidechain et la chaîne principale, garantissant l’intégrité et l’authenticité des données, et empêchant toute interception ou altération.
-
Horodatage et temps des blocs : Vérifier le mécanisme de synchronisation temporelle de la sidechain, assurant la cohérence et l’exactitude du temps de génération des blocs, pour éviter les attaques ou rollbacks dus à des écarts horaires.
-
Sécurité de la gouvernance sur chaîne : Examiner le mécanisme de gouvernance de la sidechain, garantissant la transparence et la sécurité des processus de vote, de propositions et de décision, pour éviter tout contrôle malveillant ou attaque.
-
Audit du modèle économique : Examiner le modèle économique de la sidechain, notamment la distribution des jetons, les incitations et le modèle d’inflation, afin de s’assurer qu’il n’encourage pas de comportements malveillants ou n’affecte pas la stabilité du système.
-
Mécanisme des frais : Examiner le système de frais de transaction de la sidechain, en s’assurant qu’il correspond aux besoins des utilisateurs de la chaîne principale et de la sidechain, évitant la manipulation des frais ou la congestion du réseau.
-
Sécurité des actifs : Auditer les mécanismes de gestion des actifs sur chaîne, garantissant que les processus de stockage, transfert et destruction sont sûrs, sans risque d’accès non autorisé ou de vol.
-
Gestion des clés : Examiner la stratégie de gestion des clés de la sidechain, assurant la sécurité des clés privées et un contrôle d’accès strict, pour éviter les fuites ou usurpations.
Rollup
Un Rollup est une solution de mise à l’échelle de niveau 2 (Layer2) destinée à améliorer le débit et l’efficacité des transactions sur une blockchain. Il agrège un grand nombre de transactions (« Rollup »), les traite hors chaîne, puis ne soumet à la chaîne principale que le résultat final, réduisant ainsi considérablement la charge supportée par celle-ci.
Les Rollups se divisent principalement en zk-Rollup et op-Rollup. Contrairement à Ethereum, en raison de l'impossibilité de Turing du BTC, il n’est pas possible d’utiliser des contrats pour valider des preuves à connaissance nulle sur BTC. Les solutions zk-Rollup traditionnelles ne peuvent donc pas être mises en œuvre directement sur BTC. Comment alors utiliser zk-Rollup pour un Layer2 BTC ? Prenons l’exemple du projet B² Network :
Pour réaliser la validation de preuve à connaissance nulle sur BTC, B² Network crée un script Taproot combinant à la fois la validation zk-Rollup et le mécanisme d’incitation-challenge de l’op-Rollup. Son fonctionnement est le suivant :
-
B² Network agrège d’abord toutes les transactions initiées par les utilisateurs.
-
Un séquenceur ordonne ces transactions Rollup, les sauvegarde via un stockage décentralisé, et les transmet à zkEVM pour traitement.
-
zkEVM, après synchronisation avec l’état de la chaîne BTC, traite les exécutions de contrats, puis fusionne et transmet les résultats à l’agrégateur.
-
Le Prover génère une preuve à connaissance nulle et l’envoie à l’agrégateur, qui regroupe les transactions et les preuves avant de les envoyer aux nœuds B².
-
Les nœuds B² valident la preuve à connaissance nulle et créent un script Taproot à partir des données Rollup stockées de manière décentralisée.
-
Taproot est un UTXO dont la valeur est de 1 satoshi. Sa structure de données contient dans B² Inscription toutes les données Rollup, et dans Tapleaf toutes les données de vérification des preuves. Après passage par le mécanisme d’incitation-challenge, il est envoyé à BTC comme engagement basé sur la preuve zk.
Les avantages des Rollups :
-
Les Rollups héritent de la sécurité et de la décentralisation de la chaîne principale. En soumettant régulièrement les données de transaction et l’état à la chaîne principale, ils garantissent l’intégrité et la transparence des données.
-
Les Rollups s’intègrent parfaitement aux réseaux blockchain existants, comme Ethereum, permettant aux développeurs d’en tirer profit sans avoir à modifier profondément leurs contrats ou applications existants.
-
En traitant massivement les transactions hors chaîne et en les regroupant en lots pour les soumettre à la chaîne principale, les Rollups augmentent fortement la capacité de traitement, augmentant significativement le nombre de transactions par seconde (TPS).
-
Les transactions Rollup étant traitées hors chaîne, elles réduisent fortement les ressources de calcul et de stockage nécessaires sur chaîne, abaissant ainsi sensiblement les frais pour les utilisateurs.
Les défis des Rollups :
-
Si les données hors chaîne ne sont pas disponibles, les utilisateurs pourraient être incapables de vérifier les transactions ou de restaurer l’état.
-
Les transactions Rollup doivent être traitées par lots puis soumises à la chaîne principale, ce qui peut entraîner des délais de règlement plus longs. En particulier dans les op-Rollups, une période de contestation existe, obligeant les utilisateurs à attendre longtemps avant la confirmation finale.
-
Bien que les zk-Rollups offrent une sécurité accrue et une confirmation immédiate, ils exigent beaucoup de ressources computationnelles et de stockage, car la génération de preuves à connaissance nulle est très coûteuse en puissance de calcul.
Étant donné que la solution adoptée est un Rollup, les points clés d’audit de sécurité sont essentiellement similaires à ceux des Layer2 d’Ethereum.
Autres (Babylon)
Outre les solutions traditionnelles de Layer2 BTC, de nouveaux protocoles tiers émergent récemment autour de l’écosystème BTC, comme Babylon :
Babylon vise à transformer les 21 millions de BTC en actifs de mise en gage décentralisés. Contrairement aux autres Layer2 BTC, Babylon n’étend pas la capacité de la chaîne BTC. Il s’agit d’une chaîne unique dotée d’un protocole spécial de mise en gage BTC, dont l’objectif principal est de se connecter aux chaînes PoS, en utilisant le BTC mis en gage pour renforcer leur sécurité, et en résolvant des problèmes tels que les attaques à distance et la centralisation.
L’architecture se compose de trois couches :
-
Couche Bitcoin : C’est la base solide de Babylon, exploitant la sécurité bien connue du Bitcoin pour garantir que toutes les transactions soient extrêmement sûres, comme sur le réseau Bitcoin lui-même.
-
Couche Babylon : Le cœur de Babylon est cette couche personnalisée, une blockchain conçue pour relier le Bitcoin aux différentes chaînes Proof-of-Stake (PoS). Elle traite les transactions, exécute les contrats intelligents et assure le bon fonctionnement de l’écosystème.
-
Couche des chaînes PoS : Cette couche supérieure rassemble plusieurs chaînes PoS sélectionnées pour leurs avantages spécifiques. Cela confère à Babylon une extensibilité et une flexibilité remarquables, permettant aux utilisateurs de bénéficier des meilleures fonctionnalités de différentes blockchains PoS.
Le fonctionnement consiste à signer les blocs finaux sur la chaîne BTC afin de protéger les chaînes PoS. Cela étend essentiellement le protocole de base par une ronde supplémentaire de signatures. Ces signatures de la dernière ronde (+1) ont une caractéristique unique : ce sont des signatures ponctuelles extractibles (EOTS). L’objectif est d’intégrer les points de contrôle PoS dans BTC, résolvant ainsi les problèmes de longues périodes de déliaison et d’attaques à distance sur les chaînes PoS.
Les avantages de Babylon :
-
Raccourcit la période de déliaison des systèmes PoS
-
Grâce au staking de BTC, dont le prix est indexé sur BTC, il atténue la pression inflationniste sur les réseaux PoS concernés
-
Ouvre de nouvelles sources de revenus pour le BTC
Les défis de Babylon :
-
La conception du modèle économique, notamment le taux de rendement du staking, influence fortement l’engagement des utilisateurs au staking du BTC
-
Il manque des règles harmonisées de récompense entre les différentes chaînes PoS
Les protocoles tiers, selon leurs implémentations, présentent des enjeux de sécurité variés. À titre d'exemple avec Babylon, les points clés d’audit de sécurité à surveiller sont les suivants :
-
Sécurité des contrats intelligents : Les contrats de staking sur BTC sont implémentés via des scripts UTXO ; leur sécurité doit être soigneusement examinée.
-
Sécurité de l’algorithme de signature : Les contrats utilisent des signatures pour gérer le staking des utilisateurs ; la sécurité de l’algorithme impacte directement la génération et la vérification des signatures.
-
Conception du modèle économique du protocole : Le modèle économique doit être bien équilibré en matière de récompenses et de pénalités, afin d’éviter toute perte d’actifs pour les utilisateurs.
Annexe :
Points d’audit généraux applicables aux blockchains publiques et Layer2
-
Dépassement d’entiers : Vérifier les dépassements arithmétiques (overflow/underflow)
-
Boucle infinie : Vérifier que les conditions de sortie des boucles sont correctement définies
-
Récursion infinie : Vérifier que les conditions de sortie des appels récursifs sont adéquates
-
Conditions de course : Vérifier l'accès concurrent aux ressources partagées
-
Plantage par exception : Identifier les codes pouvant provoquer un arrêt anormal du programme
-
Division par zéro : Vérifier l’absence de divisions par zéro
-
Conversion de type : Vérifier la justesse des conversions de type et l’absence de perte d’information
-
Débordement de tableau : Vérifier qu’aucun accès ne dépasse les limites d’un tableau
-
Vulnérabilité de désérialisation : Vérifier les failles potentielles lors de la désérialisation
-
Sécurité de l’implémentation des fonctionnalités : Vérifier que chaque interface RPC est sécurisée et conforme à sa spécification fonctionnelle
-
Permissions des interfaces RPC sensibles : Vérifier que l’accès aux interfaces RPC critiques est correctement restreint
-
Mécanisme de transmission chiffrée : Vérifier l'utilisation de protocoles sécurisés comme TLS
-
Analyse du format des données reçues : Vérifier le traitement des formats de données entrantes
-
Attaque par déverrouillage de portefeuille : Vérifier que les fonds ne peuvent pas être volés lors du déverrouillage via une requête RPC
-
Sécurité web classique : Vérifier l’absence des vulnérabilités suivantes : XSS / injection de template / vulnérabilités de composants tiers / pollution de paramètres HTTP / injection SQL / injection XXE / désérialisation / SSRF / injection de code / inclusion de fichiers locaux / inclusion de fichiers distants / exécution de commandes, etc.
-
Mécanisme d’authentification et d’identification des nœuds : Vérifier que les nœuds peuvent s’identifier et que ce mécanisme ne peut pas être contourné
-
Pollution de table de routage : Vérifier qu’aucune donnée ne peut être insérée ou écrasée arbitrairement dans la table de routage
-
Algorithme de découverte de nœuds : Vérifier que l’algorithme est équilibré et imprévisible (ex : absence de biais dans l’algorithme de distance)
-
Audit de la limitation du nombre de connexions : Vérifier que la gestion du nombre de connexions P2P est raisonnable
-
Attaque d’éclipse : Évaluer le coût et l’impact d’une attaque d’éclipse, avec analyse quantitative si nécessaire
-
Attaque Sybil : Évaluer le mécanisme de consensus par vote et analyser la stratégie de vérification des droits de vote
-
Attaque d’écoute : Vérifier que le protocole de communication ne divulgue pas de données privées
-
Attaque d’hétérogénéité : Évaluer la capacité des nœuds à reconnaître d’autres nœuds de la même chaîne
-
Usurpation temporelle : Vérifier le mécanisme de calcul du temps réseau des nœuds
-
Attaque par épuisement de la mémoire : Identifier les zones à forte consommation mémoire
-
Attaque par saturation du disque : Identifier les zones générant de gros fichiers
-
Attaque par pression sur les sockets : Vérifier la politique de limitation du nombre de connexions
-
Attaque par épuisement des handles noyau : Vérifier les limitations à la création de handles noyau (ex : handles de fichiers)
-
Fuites mémoire persistantes : Identifier les zones de fuite mémoire
-
Sécurité des fonctions de hachage : Vérifier la résistance aux collisions
-
Sécurité des algorithmes de signature : Vérifier la sécurité des algorithmes et de leur implémentation
-
Sécurité des algorithmes de chiffrement : Vérifier la sécurité des algorithmes et de leur implémentation
-
Sécurité du générateur de nombres aléatoires : Vérifier la qualité des générateurs de nombres aléatoires critiques
-
Sécurité de l’implémentation BFT : Évaluer la sécurité de l’algorithme BFT implémenté
-
Règle de sélection de fork : Vérifier la règle de sélection de fork pour garantir la sécurité
-
Détection du degré de centralisation : Identifier toute conception excessivement centralisée
-
Audit des incitations : Évaluer l’impact des mécanismes d’incitation sur la sécurité
-
Attaque de double dépense : Vérifier que le consensus protège contre les doubles dépenses
-
Audit des attaques MEV : Vérifier l’impact des MEV des validateurs sur l’équité de la chaîne
-
Audit du processus de synchronisation des blocs : Identifier les failles de sécurité durant la synchronisation
-
Audit de l’analyse du format des blocs : Identifier les failles lors de l’analyse du format, comme les plantages
-
Audit du processus de génération des blocs : Vérifier la sécurité de la génération des blocs, notamment la construction de la racine Merkle
-
Audit du processus de vérification des blocs : Vérifier que la signature et la logique de vérification des blocs sont complètes
-
Audit de la logique de confirmation des blocs : Vérifier que l’algorithme et son implémentation sont corrects
-
Collision de hachage de bloc : Vérifier la méthode de construction d’une collision et la gestion appropriée en cas de collision
-
Limitation des ressources lors du traitement des blocs : Vérifier que les limites (orphelins, calculs, accès disque) sont raisonnables
-
Audit du processus de synchronisation des transactions : Identifier les failles de sécurité durant la synchronisation
-
Collision de hachage de transaction : Vérifier la méthode de construction d’une collision et la gestion en cas de collision
-
Analyse du format des transactions : Identifier les failles lors de l’analyse du format, comme les plantages
-
Vérification de la légalité des transactions : Vérifier que les signatures et la logique de vérification sont complètes
-
Limitation des ressources pour le traitement des transactions : Vérifier que les limites (pool, calculs, accès disque) sont raisonnables
-
Attaque par malléabilité des transactions : Vérifier si des champs internes (ex : ScriptSig) peuvent être modifiés sans invalider la transaction
-
Audit des attaques par rejeu de transaction : Vérifier que le système détecte les tentatives de rejeu
-
Vérification du bytecode des contrats : Vérifier la sécurité du processus de vérification des contrats par la machine virtuelle (ex : overflow, boucle infinie)
-
Exécution du bytecode des contrats : Vérifier la sécurité de l’exécution du bytecode (ex : overflow, boucle infinie)
-
Modèle Gas : Vérifier que les frais unitaires des opérations correspondent proportionnellement à la consommation de ressources
-
Intégrité des journaux : Vérifier que les informations critiques sont bien journalisées
-
Sécurité des journaux : Vérifier que le traitement des journaux n’entraîne pas de failles (ex : overflow)
-
Journaux contenant des données privées : Vérifier que les journaux ne contiennent pas de clés ou d’informations sensibles
-
Stockage des journaux : Vérifier que les journaux ne consomment pas excessivement les ressources des nœuds
-
Sécurité de la chaîne d’approvisionnement du code : Vérifier les bibliothèques tierces, composants et frameworks utilisés, ainsi que leurs versions connues vulnérables
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@Beosin_com
