Bitcoin (BTC), en tant que première cryptomonnaie au monde, est progressivement devenu la pierre angulaire des actifs numériques et de la finance décentralisée depuis son arrivée en 2009. Cependant, à mesure que le nombre d'utilisateurs et de transactions augmente, les problèmes du réseau BTC deviennent de plus en plus apparents, principalement comme suit: ：

• Frais de transaction élevés : Lorsque le réseau Bitcoin est congestionné, les utilisateurs doivent payer des frais plus élevés pour s'assurer que les transactions sont confirmées le plus rapidement possible.
• Temps de confirmation de la transaction : La blockchain Bitcoin génère un nouveau bloc toutes les 10 minutes en moyenne, ce qui signifie que les transactions sur chaîne ont souvent besoin d'attendre plusieurs confirmations de bloc avant d'être considérées comme définitives.
• Limitations des contrats intelligents: le langage de script de Bitcoin a des fonctions limitées et il est difficile de mettre en œuvre des contrats intelligents complexes.

Dans cet article, nous allonsLightning Network(Lightning Network), Sidechains, Rollup et d’autres technologies sont collectivement désignées sous le nom de solutions d’extension BTC Layer2. Ils maintiennent la décentralisation et la sécurité du réseau BTC tout en réalisant des transactions rapides et à faible coût. L’introduction de la technologie de couche 2 peut améliorer la vitesse des transactions et réduire les coûts de transaction, optimiser l’expérience utilisateur et étendre la capacité du réseau, elle fournit un soutien technique important et une orientation de l’innovation pour le développement futur du BTC.

À l'heure actuelle, Beosin est devenu le partenaire de sécurité officiel de BTC Layer2 tel que Merlin Chain, a audité plusieurs protocoles écologiques BTC, tels que Bitmap.Games, Surf Protocol, Savmswap, Mineral. Lors des audits précédents, de nombreuses chaînes publiques bien connues ont passé les audits de sécurité de la chaîne publique de Beosin, notamment Ronin Network, Clover, Self Chain, Crust Network. Beosin lance maintenant une solution d'audit pour BTC Layer2 afin de fournir des services d'audit de sécurité complets et fiables pour l'ensemble de l'écosystème BTC.

Lightning Network

Le concept le plus ancien du Lightning Network est appelé “channel de paiement”. Son idée de conception est de mettre à jour en continu l'état de la transaction non confirmée par le remplacement de la transaction jusqu'à ce qu'elle soit finalement diffusée sur le réseau Bitcoin. Satoshi Nakamoto avait déjà proposé l'idée des canaux de paiement lorsqu'il a créé Bitcoin en 2009, et avait inclus un code brouillon pour les canaux de paiement dans Bitcoin 1.0, qui permettait aux utilisateurs de mettre à jour l'état de la transaction avant que la transaction ne soit confirmée par le réseau. Cependant, ce n'est qu'avec la publication du livre blanc “The Bitcoin Lightning Network: Scalable Off-Chain Instant Payment” que le Lightning Network est véritablement né et est entré dans le domaine public.

Aujourd'hui, la mise en œuvre des canaux de paiement et du Lightning Network est très mature. À ce jour, le réseau Lightning compte un total de 13 325 nœuds, 49 417 canaux et le nombre total de BTC engagés a atteint 4 975.

https://1ml.com/

Dans le Lightning Network, il est très important de garantir la sécurité des actifs des utilisateurs pendant le processus de transfert. Ce qui suit expliquera le fonctionnement du Lightning Network et comment protéger la sécurité des actifs des utilisateurs en fonction de l'échelle des nœuds du réseau.

Les utilisateurs des deux parties soumettent deux transactions au réseau principal de Bitcoin : une pour ouvrir le canal et une pour fermer le canal. Il est grossièrement divisé en trois étapes suivantes :

1. Ouverture de canal:

Tout d’abord, les utilisateurs des deux parties mettent en gage des bitcoins sur le portefeuille multi-signatures du Lightning Network sur BTC. Une fois que le Bitcoin est mis en gage et verrouillé avec succès, le canal de paiement est ouvert et les deux parties peuvent effectuer des transactions hors chaîne dans ce canal.

2. Transactions hors-chaîne :

Une fois que le canal est ouvert, toutes les transactions de transfert entre les utilisateurs seront traitées dans le Lightning Network, et il n'y a pas de limite sur le nombre de ces transactions hors chaîne. Bien sûr, ces transactions n'ont pas besoin d'être soumises immédiatement au réseau principal Bitcoin, mais sont réalisées instantanément grâce au mécanisme hors chaîne du Lightning Network.

Cette méthode de traitement hors chaîne améliore considérablement la vitesse et l'efficacité des transactions, évitant la congestion et les frais de transaction élevés de la blockchain Bitcoin.

3. Fermeture du canal et règlement du grand livre :

Lorsque les utilisateurs des deux côtés décident de quitter le canal, le règlement final du grand livre aura lieu. Ce processus garantit que tous les fonds du canal sont attribués à jour. En même temps, les utilisateurs des deux côtés retireront l'équilibre post-règlement du portefeuille multi-signatures, ce qui reflète la distribution réelle des fonds lorsque le canal est fermé. Finalement, le canal soumettra l'état final de la transaction du grand livre au réseau principal Bitcoin.

L'avantage du Lightning Network est que:

• Vitesse de transaction accrue. Le Lightning Network permet aux utilisateurs d'effectuer des transactions hors chaîne, ce qui signifie que les transactions peuvent être complétées presque instantanément sans attendre le temps de confirmation du bloc. Cela peut permettre d'atteindre des vitesses de transaction de deuxième niveau, améliorant considérablement l'expérience utilisateur.
• Confidentialité accrue. Les transactions hors chaîne de Lightning Network n’ont pas besoin d’être enregistrées publiquement sur la chaîne principale Bitcoin, ce qui améliore la confidentialité des transactions. Seules l’ouverture et la fermeture du canal doivent être enregistrées sur la chaîne principale, de sorte que le comportement de transaction de l’utilisateur ne sera pas entièrement divulgué.
• Prise en charge des micropaiements. Le Lightning Network est très adapté au traitement de petits paiements (micropaiements), tels que les paiements de contenu, les paiements de périphériques IoT, etc. Les transactions Bitcoin traditionnelles ne sont pas adaptées aux petits paiements fréquents en raison des frais de traitement élevés, tandis que le Lightning Network résout ce problème.

Les défis auxquels est confronté le Lightning Network :

• problèmes de liquidité du réseau: Le Lightning Network repose sur des Bitcoins qui sont pré-verrouillés dans des canaux. Cela signifie que les utilisateurs doivent préalablement déposer suffisamment de Bitcoin dans leur canal de paiement pour pouvoir effectuer une transaction. Une liquidité insuffisante peut entraîner des échecs de paiement, en particulier pour les transactions importantes.
• problème de routage: Trouver un chemin efficace d'un expéditeur de paiement à un destinataire peut être un problème complexe, surtout pour les réseaux de plus grande taille. À mesure que le nombre de nœuds et de canaux du réseau augmente, la difficulté de garantir l'achèvement fluide des paiements augmente également.
• Problèmes de confiance en matière de garde de fonds : Les nœuds peuvent être soumis à des attaques malveillantes et les utilisateurs doivent avoir confiance que les nœuds auxquels ils sont connectés ne chercheront pas à voler des fonds. Les nœuds peuvent-ils empêcher les fuites de clés privées ?
• Normes techniques et interopérabilité : Des normes techniques et des protocoles cohérents sont nécessaires entre différentes implémentations du Lightning Network pour assurer l'interopérabilité. Actuellement, plusieurs équipes de développement travaillent sur différentes implémentations du Lightning Network, ce qui peut entraîner des problèmes de compatibilité.
• problèmes de confidentialité : Bien que le Lightning Network améliore la confidentialité des transactions Bitcoin, les informations de transaction peuvent encore être suivies ou analysées. De plus, les opérateurs de nœuds du réseau peuvent voir les transactions passant par leurs nœuds, révélant potentiellement certaines informations privées.

La sécurité du Lightning Network affecte directement la scalabilité hors chaîne de Bitcoin et la sécurité des fonds des utilisateurs. Par conséquent, en plus des éléments d'audit généraux de la chaîne publique (voir l'annexe à la fin de cet article pour plus de détails), le Lightning Network doit également prêter attention aux risques de sécurité importants suivants:

• Congestion des canaux : Vérifiez l'exhaustivité de la conception du système Lightning Network et si cela entraînera une congestion des canaux en raison d'attaques de deuil.
• Interférence de canal : Vérifiez la sécurité de la structure du canal du réseau Lightning et si elle sera sujette à des attaques d'interférence de canal.
• Verrouillage et déverrouillage des actifs de canal : Examinez le processus de verrouillage et de déverrouillage des actifs dans le réseau Lightning pour vous assurer que lors de l'ouverture ou de la fermeture d'un canal de paiement, le transfert de fonds sur et hors de la chaîne est sûr et fiable.
• Mise à jour de l'état et fermeture : Évaluer le processus de mise à jour de l'état et le mécanisme de fermeture forcée du canal pour garantir que le dernier état peut être correctement identifié et exécuté en cas de conditions anormales.
• Contrat de verrouillage temporel et de hachage (HTLC) : Évaluer la mise en œuvre de HTLC pour s'assurer que les conditions de verrouillage temporel et de hachage peuvent être exécutées correctement afin de prévenir les pertes de fonds causées par des problèmes de fenêtre temporelle.
• Dépendance de la blockchain à l'horodatage : évaluez la dépendance du réseau Lightning à l'horodatage de la blockchain Bitcoin pour vous assurer que le temps sur chaîne et hors chaîne peut être correctement coordonné afin de prévenir les attaques temporelles.
• Sécurité de l'algorithme de routage : Vérifiez l'efficacité et la sécurité de l'algorithme de routage pour prévenir l'exposition de la vie privée de l'utilisateur et les risques de manipulation malveillante du routage.
• Stockage des canaux et récupération des données : Vérifiez le mécanisme de stockage du canal et la stratégie de récupération des données pour garantir que l'état du canal puisse être restauré en cas de défaillance du nœud ou de déconnexion inattendue afin d'éviter toute perte de fonds.

side chain

Contrairement au Lightning Network, la side chain est une blockchain indépendante qui fonctionne en parallèle à la chaîne principale (comme la blockchain BTC) et interagit avec la chaîne principale par l'intermédiaire d'un ancrage bidirectionnel (Two-Way Peg). Le but de la side chain est d'atteindre plus de fonctionnalités et d'améliorer la scalabilité sans modifier le protocole de la chaîne principale.

En tant que blockchain indépendante, la side chain possède son propre mécanisme de consensus, ses noeuds et ses règles de traitement des transactions. Elle peut adopter des technologies et des protocoles différents de ceux de la chaîne principale en fonction des besoins de scénarios d'application spécifiques. Grâce au mécanisme d'ancrage bidirectionnel (2WP), la side chain communique avec la chaîne principale pour garantir que les actifs peuvent être transférés librement et en toute sécurité entre les deux. Le mécanisme d'exploitation du mécanisme d'ancrage bidirectionnel (2WP) est grosso modo le suivant :

1. L'utilisateur verrouille BTC sur la chaîne principale et l'institution de confiance 1 obtient et utilise la vérification SPV 2 pour garantir si la transaction verrouillée de l'utilisateur est confirmée.

2. L'institution de confiance émettra des jetons équivalents aux utilisateurs sur la chaîne latérale.

3. Après des transactions gratuites, les utilisateurs bloquent les jetons restants sur la chaîne latérale.

4. Après vérification de la légalité de la transaction, l'institution de confiance déverrouille le BTC sur la chaîne principale et libère la valeur correspondante de BTC à l'utilisateur.

Remarque 1: L'autorité de confiance joue un rôle clé dans le mécanisme d'ancrage bidirectionnel et est responsable de la gestion du verrouillage et du déverrouillage des actifs. Ces institutions doivent avoir un haut degré de crédibilité et de capacités techniques pour garantir la sécurité des actifs des utilisateurs.

Note 2: Vérification SPVPermet aux nœuds de vérifier la validité de transactions spécifiques sans télécharger l'intégralité de la blockchain. Les nœuds SPV ont seulement besoin de télécharger l'en-tête du bloc et de vérifier si la transaction est incluse dans le bloc via l'arbre de Merkle.

Projets représentatifs de side chains :

CKB (Réseau Nervos)

Nervos Network est un écosystème de blockchain publique open source qui vise à tirer parti des avantages de sécurité et de décentralisation du mécanisme de consensus POW de BTC tout en introduisant un modèle UTXO plus évolutif et flexible pour traiter les transactions. Son noyau est Common Knowledge Base (CKB), qui est une blockchain de couche 1 construite sur RISC-V et utilisant PoW (Proof of Work) comme consensus. Il étend le modèle UTXO en un modèle de cellule, ce qui lui permet de stocker n'importe quelle donnée et de prendre en charge l'écriture de scripts dans n'importe quel langage pour s'exécuter sur la chaîne en tant que contrat intelligent.

Stacks

Stacks connecte chaque bloc Stacks au bloc Bitcoin grâce à son mécanisme PoX (Proof of Transfer). Pour développer des contrats intelligents, Stacks a conçu le langage de programmation spécialisé Clarity. Dans Clarity, l’option get-burn-block-info ? permet de passer la hauteur du bloc Bitcoin et d’obtenir le hachage d’en-tête du bloc. Dans le même temps, le mot-clé burn-block-height peut obtenir la hauteur de bloc actuelle de la chaîne Bitcoin. Ces deux fonctions permettent aux contrats intelligents Clarity de lire l’état de la chaîne de base Bitcoin, ce qui permet aux transactions Bitcoin de servir de déclencheurs de contrat. En automatisant l’exécution de ces contrats intelligents, Stacks étend les capacités de Bitcoin.

Pour une analyse détaillée de Stacks, vous pouvez lire l’article de recherche précédent de Beosin : «Qu'est-ce que Stacks? Quels défis les Stacks du réseau BTC de la couche 2 peuvent-ils rencontrer?》

L'avantage des side chains est que:

• Les side chains peuvent utiliser différentes technologies et protocoles pour mener diverses expérimentations et innovations sans affecter la stabilité et la sécurité de la chaîne principale.
• Les sidechains peuvent introduire des fonctions que la chaîne principale n'a pas, telles que les contrats intelligents, la protection de la vie privée, l'émission de jetons, etc., pour enrichir les scénarios d'application de l'écosystème blockchain.

Défis auxquels sont confrontées les sidechains:

• La chaîne latérale dispose d'un mécanisme de consensus indépendant, qui peut ne pas être aussi sécurisé que la chaîne principale BTC. Si le mécanisme de consensus de la chaîne latérale est faible ou présente des failles, cela peut entraîner des attaques de 51 % ou d'autres formes d'attaques, affectant la sécurité des actifs des utilisateurs. La sécurité de la chaîne principale BTC repose sur sa puissance de calcul énorme et sa large distribution de nœuds, tandis que les chaînes latérales peuvent ne pas respecter les mêmes normes de sécurité.
• La mise en œuvre du mécanisme d'ancrage bidirectionnel nécessite des algorithmes de chiffrement et des protocoles complexes. S'il y a des failles dans ceux-ci, cela peut causer des problèmes de transfert d'actifs entre la chaîne principale et la chaîne latérale, et peut même entraîner la perte ou le vol d'actifs.
• Pour trouver un équilibre entre vitesse et sécurité, la plupart des sidechains ont un degré de centralisation plus élevé que la chaîne principale.

Layer2 est un système blockchain complet, donc les éléments d'audit généraux de la chaîne publique s'appliquent également à la chaîne secondaire. Pour plus de détails, consultez l'annexe à la fin de cet article.

En raison de sa nature particulière, les sidechains nécessitent également une vérification supplémentaire :

• Sécurité du protocole de consensus : Vérifier si le protocole de consensus de la chaîne latérale (tel que PoW, PoS, DPoS) a été entièrement vérifié et testé, et s'il existe des vulnérabilités potentielles ou des vecteurs d'attaque, tels que des attaques à 51%, des attaques à longue portée, etc.
• Sécurité des nœuds de consensus : Évaluez la sécurité des nœuds de consensus, y compris la gestion des clés, la protection des nœuds et la sauvegarde redondante, afin d'empêcher les nœuds d'être compromis ou abusés.
• Verrouillage et déverrouillage des actifs : Examiner le mécanisme d'ancrage bidirectionnel des actifs entre la chaîne latérale et la chaîne principale pour garantir que les contrats intelligents de verrouillage et de déverrouillage des actifs sont sûrs et fiables, empêchant ainsi les doubles dépenses, les pertes d'actifs ou les échecs de verrouillage.
• Vérification inter-chaîne : Vérifiez l'exactitude et la sécurité de la vérification inter-chaîne, assurez-vous que le processus de vérification est décentralisé et à l'épreuve des manipulations, et empêchez les échecs de vérification ou les vérifications malveillantes.
• Audit du code du contrat : Audit approfondi de tous les contrats intelligents s'exécutant sur la chaîne latérale pour détecter d'éventuelles failles ou portes dérobées, en particulier la logique du contrat lors de la gestion des opérations de chaînes croisées.
• Mécanisme de mise à niveau : Vérifiez si le mécanisme de mise à niveau des contrats intelligents est sûr et s'il existe des processus d'audit et de consensus communautaire appropriés pour prévenir les mises à niveau malveillantes ou la manipulation des contrats.
• Communication entre les nœuds : Vérifiez si le protocole de communication entre les nœuds de la chaîne latérale est sécurisé et si des canaux cryptés sont utilisés pour prévenir les attaques de l'homme du milieu ou les fuites de données.
• Communication inter-chaînes : Vérifiez le canal de communication entre la chaîne latérale et la chaîne principale pour garantir l'intégrité et l'authenticité des données et empêcher toute interception ou altération de la communication.
• Horodatage et temps de bloc : Vérifiez le mécanisme de synchronisation du temps de la chaîne latérale pour garantir la cohérence et la précision du temps de génération de bloc et prévenir les attaques ou les retours en arrière de blocs causés par des différences de temps.
• Sécurité de la gouvernance on-chain : Examinez le mécanisme de gouvernance de la sidechain afin d'assurer la transparence et la sécurité des processus de vote, de proposition et de prise de décision, et de prévenir tout contrôle malveillant ou attaque.
• Audit économique des jetons: Vérifiez le modèle économique des jetons de la side chain, y compris l'allocation des jetons, le mécanisme d'incitation et le modèle d'inflation, afin de garantir que les incitations économiques ne conduiront pas à des comportements malveillants ou à une instabilité du système.
• Mécanisme des frais : Vérifiez le mécanisme des frais de transaction de la sidechain afin de vous assurer qu'il correspond aux besoins des utilisateurs de la chaîne principale et de la sidechain, afin d'éviter toute manipulation des frais ou toute congestion du réseau.
• Sécurité des actifs : Audit du mécanisme de gestion des actifs sur la chaîne pour garantir que le stockage, le transfert et le processus de destruction des actifs sont sûrs et fiables, et qu'il n'y a pas de risque d'accès non autorisé ou de vol.
• Gestion des clés : Vérifiez la politique de gestion des clés de la chaîne latérale pour garantir la sécurité et le contrôle d'accès de la clé privée et empêcher la clé d'être divulguée ou volée.

Rollup

Rollup est une solution de mise à l'échelle de la couche 2 conçue pour améliorer le débit et l'efficacité des transactions de blockchain. Elle réduit considérablement la charge sur la chaîne principale en regroupant un grand nombre de transactions (« Rollup ») et en les traitant hors chaîne, ne soumettant que les résultats finaux à la chaîne principale.

Le Rollup est principalement divisé en zk-Rollup et en op-Rollup. Mais contrairement à ETH, en raison de l'incomplétude de Turing de BTC, il est impossible d'utiliser des contrats sur BTC pour la vérification de preuve de connaissance zéro. Les solutions zk-Rollup traditionnelles ne peuvent pas être mises en œuvre sur BTC. Alors comment mettre en œuvre la couche 2 de BTC en utilisant zk-Rollup ? Ensuite, prenons le projet B² Network comme exemple :

Afin de réaliser une vérification de preuve de connaissance nulle sur BTC, B² Network a créé le script Taproot, qui combine la vérification de preuve de connaissance nulle de zk-Rollup et le défi d'incitation d'op-Rollup. Son mécanisme de fonctionnement est approximativement le suivant :

1. B² Network regroupe d'abord toutes les transactions initiées par les utilisateurs.

2. Après avoir utilisé le trieur pour trier les transactions Rollup, enregistrez les transactions Rollup en utilisant un stockage décentralisé et remettez-les à zkEVM pour traitement en même temps.

3. Après que zkEVM a synchronisé l'état de la chaîne BTC, il traite des transactions telles que l'exécution de contrats, fusionne et emballe les résultats et les envoie à l'agrégateur.

4. Le prouveur génère une preuve à divulgation nulle et l'envoie à l'agrégateur. L'agrégateur agrège les transactions et envoie la preuve aux nœuds B².

5. B² Nodes effectue une vérification de preuve de connaissance nulle et crée des scripts Taproot basés sur les données Rollup dans le stockage décentralisé.

6. Taproot est un UTXO d'une valeur de 1 satoshi. L'inscription B² dans sa structure de données stocke toutes les données Rollup, et Tapleaf stocke toutes les données de vérification. Après avoir passé le mécanisme de défi incitatif, il sera envoyé à BTC en tant qu'engagement vérifié basé sur une preuve zk.

L'avantage de Rollup est que:

• Rollup hérite des fonctionnalités de sécurité et de décentralisation de la chaîne principale. En soumettant régulièrement des données de transaction et de statut à la chaîne principale, l'intégrité et la transparence des données sont assurées.
• Rollup peut être intégré parfaitement aux réseaux blockchain existants tels qu'Ethereum, permettant aux développeurs de profiter facilement de ses avantages sans modifier de manière significative les contrats intelligents et les applications existantes.
• En traitant un grand nombre de transactions hors chaîne et en les regroupant en un seul lot pour les soumettre à la chaîne principale, Rollup améliore considérablement les capacités de traitement des transactions et augmente significativement le nombre de transactions par seconde (TPS).
• Les transactions Rollup ne doivent être traitées que hors chaîne, ce qui réduit considérablement les ressources de calcul et d'espace de stockage nécessaires pour les transactions sur chaîne, réduisant ainsi considérablement les frais de transaction des utilisateurs.

Les défis auxquels est confronté Rollup :

• Si les données hors chaîne ne sont pas disponibles, les utilisateurs peuvent être incapables de vérifier les transactions et de restaurer l'état.
• Les transactions Rollup doivent être traitées par lots et finalement soumises à la chaîne principale, ce qui peut entraîner des délais de règlement plus longs. Surtout dans op-Rollup, il y a une période de litige et les utilisateurs peuvent devoir attendre longtemps avant que la transaction soit finalement confirmée.
• Bien que le ZK Rollup offre une sécurité accrue et une confirmation instantanée, ses exigences en matière de calcul et de stockage sont élevées, et la génération de preuves de connaissance nulle nécessite une grande quantité de ressources informatiques.

Étant donné que la solution adoptée est Rollup, ses principaux éléments d'audit de sécurité sont essentiellement les mêmes que ceux de la couche ETH Layer2.

Autres (Babylone)

En plus du traditionnel BTC Layer2, il existe également quelques nouveaux protocoles tiers conceptuels liés à l'écosystème BTC récemment, tels que Babylon :

L'objectif de Babylone est de convertir 21 millions de BTC en actifs de jalonnement décentralisés. Contrairement à d'autres couches 2 de BTC, Babylone n'élargit pas la chaîne BTC. C'est une chaîne unique en soi, avec un protocole de mise en gage BTC spécial. Le but principal est de se connecter à la chaîne PoS. Mettre en gage des BTC pour fournir une sécurité renforcée à la chaîne PoS et résoudre le risque d'attaques de l'extrémité distante de la chaîne et la question centralisée.

L'architecture est divisée en trois couches :

Couche Bitcoin : Il s'agit de la base solide de Babylon, exploitant la sécurité bien connue de Bitcoin pour garantir que toutes les transactions sont super sécurisées, tout comme sur le réseau Bitcoin.

Couche babylonienne : Au cœur de Babylone se trouve la couche babylonienne, une blockchain personnalisée qui connecte Bitcoin à diverses chaînes Proof-of-Stake (PoS). Elle traite les transactions, exécute les contrats intelligents et garantit le bon fonctionnement de l'ensemble de l'écosystème.

Couche de chaîne PoS : La couche supérieure est composée de plusieurs chaînes PoS, chaque chaîne PoS étant sélectionnée pour ses avantages uniques. Cela confère à BabylonChain une évolutivité et une flexibilité incroyables, permettant aux utilisateurs de profiter des meilleures fonctionnalités des différentes blockchains PoS.

Le fonctionnement consiste à sécuriser la chaîne PoS en utilisant des blocs finaux signés sur la chaîne BTC. Cela étend essentiellement le protocole de base avec des tours de signature supplémentaires. Ces signatures dans le tour final +1 ont une caractéristique unique : ce sont des signatures à usage unique extractibles (EOTS). Le but est d'intégrer des points de contrôle PoS dans BTC pour résoudre les problèmes de période de déconnexion prolongée et d'attaque à distance de PoS.

L'avantage de Babylone est que :

• Accélérer la période de déliaison de PoS
• Puisque BTC est engagé, le prix est lié au BTC, ce qui peut réduire la pression inflationniste sur le réseau PoS correspondant.
• Ouvre de nouvelles perspectives pour les gains en BTC

Défis auxquels Babylon fait face:

• Les conceptions économiques telles que le taux de rendement du jalonnement ont un plus grand impact sur l'enthousiasme pour le jalonnement de BTC
• Absence de dispositions de cohérence des récompenses entre les chaînes de preuve d'enjeu

Les protocoles tiers ont différents points de sécurité en fonction de leur implémentation. Prendre Babylon comme exemple, certains éléments d'audit de sécurité qui nécessitent une attention sont les suivants:：

1. Sécurité des contrats intelligents : Le contrat de mise en gage sur BTC est implémenté via le script UTXO, et sa sécurité doit être prise en compte.

2. Sécurité de l'algorithme de signature : Les signatures sont utilisées dans le contrat pour gérer les engagements des utilisateurs, et la sécurité de son algorithme est liée à la génération et à la vérification des signatures.

3. Conception du modèle économique du protocole: Que le modèle économique du protocole soit raisonnablement établi en termes de récompenses et de sanctions, et qu'il ne conduise pas à la perte des actifs des utilisateurs.

annexe :

Articles d'audit général de la chaîne publique & Layer2

• Débordement entier : Vérifiez le débordement entier et le débordement entier négatif
• Boucle infinie: Vérifiez si les conditions de jugement de la boucle du programme sont raisonnables
• Appel récursif infini : Vérifiez si la condition de sortie de l'appel récursif du programme est raisonnable
• Conditions de course : Vérifier les opérations d'accès aux ressources partagées dans des conditions concurrentes
• Crash anormal : Vérifiez le code d'exception qui permet au programme de quitter activement
• Vulnérabilité de division par 0 : Vérifiez s'il y a division par 0
• Conversion de type: Vérifiez si la conversion de type est correcte et si des informations importantes sont perdues pendant le processus de conversion
• Dépassement de limite de tableau: Vérifiez si un élément en dehors des limites du tableau est accédé
• Vulnérabilité de désérialisation : vérifiez s'il y a des problèmes lors du processus de désérialisation
• Sécurité de mise en œuvre fonctionnelle : Vérifiez s'il existe des risques de sécurité dans chaque mise en œuvre d'interface RPC et si elle est conforme à la fonction d'interface RPC.
• Peut être conçu pour correspondre
• Que les paramètres de permission de l'interface RPC sensible soient raisonnables : vérifiez les paramètres de permission d'accès de l'interface RPC sensible
• Mécanisme de transmission chiffrée : vérifier si un protocole de transmission chiffrée est utilisé, tel que TLS, etc.
• Analyse du formatage des données de demande : Vérifiez le processus d'analyse du formatage des données de demande
• Attaque de déverrouillage de portefeuille : Lorsqu'un nœud déverrouille son portefeuille, il est demandé par RPC de voler des fonds.
• Sécurité Web traditionnelle : vérifiez les vulnérabilités suivantes : Cross-site scripting (XSS) / Injection de modèle
• Vulnérabilités des composants tiers / Pollution des paramètres HTTP / Injection SQL / Injection d'entité XXE désérialisation
• vulnérabilités/vulnérabilités SSRF/injection de code/inclusion de fichier local/inclusion de fichier à distance/injection d'exécution de commande et autres vulnérabilités traditionnelles
• Mécanisme d'authentification et d'identification de l'identité du nœud réseau: Vérifier s'il existe un mécanisme d'identification du nœud et si le mécanisme d'identification du nœud peut être contourné.
• Pollution de la table de routage : Vérifiez si la table de routage peut être insérée ou écrasée de manière aléatoire
• Algorithme de découverte de nœuds: Vérifiez si l'algorithme de découverte de nœuds est équilibré et imprévisible, tel qu'un algorithme de distance déséquilibré et d'autres problèmes.
• Audit d'occupation du nombre de connexions : Vérifiez si la limite et la gestion du nombre de nœuds de connexion réseau p2p sont raisonnables.
• Attaque d'éclipse : évaluez le coût et les dommages d'une attaque d'éclipse et fournissez une analyse quantitative si nécessaire
• Attaque de Sybil : Évaluer le mécanisme de consensus de vote et analyser la stratégie de vérification de la qualification de vote
• Attaque d'écoute : Vérification des protocoles de communication pour les fuites de confidentialité
• Attaque extraterrestre: Évaluez si le nœud peut identifier des nœuds de chaîne similaires
• Piratage de temps : Vérifier le mécanisme de calcul du temps de réseau d'un nœud
• Attaque par épuisement de mémoire : Vérification des emplacements de grande consommation de mémoire
• Attaque d'épuisement du disque dur : vérifiez où sont stockés les fichiers volumineux
• Attaque de pression sur la prise : vérifiez la politique de limite sur le nombre de connexions
• Attaque d'épuisement de la poignée du noyau : Vérifiez les limites de création de poignée du noyau, telles que les poignées de fichiers, etc.
• Fuites de mémoire persistantes: Vérifiez les fuites de mémoire
• Sécurité de l'algorithme de hachage: Vérification de la résistance à la collision d'un algorithme de hachage
• Sécurité de l'algorithme de signature numérique : Vérifiez la sécurité de l'algorithme de signature et la sécurité de la mise en œuvre de l'algorithme
• Sécurité de l'algorithme de chiffrement : Vérifier la sécurité de l'algorithme de chiffrement, la sécurité de l'implémentation de l'algorithme
• Sécurité du générateur de nombres aléatoires : Vérification de la fiabilité des algorithmes critiques de génération de nombres aléatoires
• Sécurité de l'implémentation BFT : Évaluation de la sécurité de l'algorithme BFT
• Règles de choix de la fourchette: Vérifiez les règles de choix de la fourchette pour assurer la sécurité
• Détection de la centralisation: identifier s'il y a une centralisation excessive dans la conception du système
• Audit des incitations: Évaluer l'impact des incitations sur la sécurité
• Attaque de double dépense : Vérifiez si le consensus peut se défendre contre une attaque de double dépense
• Audit de l'attaque MEV : Vérifiez l'impact du MEV des nœuds d'emballage de bloc sur l'équité de la chaîne
• Audit du processus de synchronisation de blocs: Vérifier les problèmes de sécurité pendant le processus de synchronisation
• Audit du processus d'analyse du format de bloc : Vérification des problèmes de sécurité dans le processus d'analyse du format, tels que des erreurs d'analyse entraînant des plantages
• Audit du processus de génération de blocs : Vérifiez les problèmes de sécurité lors du processus de génération de blocs, y compris si la méthode de construction de la racine de l'arbre de Merkle est raisonnable
• Audit du processus de vérification des blocs : Vérifiez si les éléments de contenu de signature de bloc et la logique de vérification sont suffisants
• Audit de la logique de confirmation de bloc : Vérifiez si l'algorithme et l'implémentation de la confirmation de bloc sont raisonnables
• Collision de hachage de bloc : Vérifiez la méthode de construction de la collision de hachage de bloc et si la gestion de la collision est raisonnable.
• Limites de ressources de traitement des blocs : Vérifiez si les limites de ressources telles que le pool de blocs orphelins, le calcul de vérification, l'adressage du disque dur, etc. sont raisonnables.
• Audit du processus de synchronisation des transactions : Vérifier les problèmes de sécurité pendant le processus de synchronisation
• Collision de hachage de transaction : Vérifiez la méthode de construction de la collision de hachage de transaction et le traitement de la collision.
• Analyse du format de transaction : vérifiez les problèmes de sécurité pendant le processus d’analyse du format, tels que les erreurs d’analyse entraînant des blocages
• Vérification de la légalité des transactions : Vérifiez si chaque type d'éléments de contenu de signature de transaction et la logique de vérification sont suffisants
• Limites des ressources de traitement des transactions : Vérifiez si les limites des ressources telles que les pools de transactions, les calculs de vérification, l'adressage du disque dur, etc. sont raisonnables.
• Attaque de malléabilité des transactions: Une transaction peut-elle modifier les champs internes (comme ScriptSig) pour changer le hachage de la transaction sans affecter la validité de la transaction?
• Audit de l'attaque de rejeu de transaction : Vérifiez la détection du système de rejeu de transaction
• Vérification du bytecode du contrat : Vérifiez les problèmes de sécurité du processus de vérification de la machine virtuelle du contrat, tels que le débordement d'entier, la boucle infinie, etc.
• Exécution du bytecode du contrat : Vérifiez les problèmes de sécurité lors du processus d'exécution du bytecode par la machine virtuelle, tels que le débordement d'entier, la boucle infinie, etc.
• Modèle de gaz : Vérifier si les frais de traitement correspondant à chaque opération atomique de traitement des transactions/exécution des contrats sont proportionnels à la consommation de ressources
• Intégrité de la journalisation : Vérifier si les informations clés sont enregistrées
• Sécurité des journaux : Vérifiez s'il y a des problèmes de sécurité causés par une manipulation incorrecte lors du traitement des journaux, tels que le débordement d'entier, etc.
• Le journal contient des informations privées : vérifiez si le journal contient des informations privées telles que des clés
• Stockage des journaux: Vérifiez si les journaux enregistrent trop de contenu, ce qui peut entraîner une consommation excessive des ressources du noeud.
• Sécurité de la chaîne d'approvisionnement du code du nœud : Vérifiez les problèmes connus de toutes les bibliothèques tierces, composants et versions correspondantes du cadre de la chaîne publique

Beosin est l'une des premières entreprises de sécurité blockchain au monde à s'engager dans la vérification formelle. Axée sur les affaires écologiques complètes de "sécurité + conformité", elle a établi des filiales dans plus de 10 pays et régions du monde. Ses activités couvrent les audits de sécurité du code avant le lancement du projet, la surveillance et le blocage des risques de sécurité pendant le fonctionnement du projet, la récupération des vols, les produits de conformité blockchain "One-stop" + services de sécurité tels que le blanchiment d'argent virtuel (AML) et les évaluations de conformité conformes aux exigences réglementaires locales. Les parties prenantes aux besoins d'audit sont invitées à contacter l'équipe de sécurité de Beosin.

Disclaimer:

1. Cet article est repris de [Beosin]. Tous les droits d'auteur appartiennent à l'auteur original [Beosin]. If there are objections to this reprint, please contact the Gate Learnéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.