Les trois attributs fondamentaux de la blockchain sont la décentralisation, la sécurité et la scalabilité. Selon la théorie du trilemme de la blockchain, une architecture de blockchain ne peut mettre en œuvre que deux de ces caractéristiques. Ethereum a été conçu en gardant à l'esprit la décentralisation et la sécurité, et donc présente des performances médiocres en termes de scalabilité. Actuellement, Ethereum traite plus d'un million de transactions par jour, ce qui peut entraîner des frais de transaction élevés et accroître le besoin de solutions de mise à l'échelle d'Ethereum.

Il existe plusieurs types de solutions de mise à l'échelle d'Ethereum, chacune avec ses propres compromis et modèles de sécurité, notamment le sharding de couche 1, les canaux d'état de couche 2, Plasma, les sidechains, les Rollups et le Validium. Parce que la technologie de sharding est lente à évoluer et complexe à mettre en œuvre et que les sidechains et le Validium ne peuvent pas hériter de la sécurité et de la disponibilité des données d'Ethereum. En résumé, l'écosystème Ethereum utilise désormais principalement la solution de mise à l'échelle Rollups.

Jusqu'à présent, Beosin est devenu un partenaire de sécurité d'ETH Layer2, tel que Manta Network et StarkNet. Lors de l'audit précédent, un certain nombre de blockchains bien connues ont réussi l'audit de sécurité de chaîne de Beosin, notamment Ronin Network, Manta Network, Merlin Chain, Clover, Self Chain, Crust Network, etc. Beosin lance maintenant une solution d'audit pour ETH Layer2 afin de fournir des services d'audit de sécurité complets pour l'écosystème ETH Layer2.

ETH Layer2 utilise les Rollups pour regrouper des centaines de transactions en une seule soumission au réseau principal d'Ethereum, ce qui permet de diviser les frais de transaction entre tous les utilisateurs de Rollup, réduisant ainsi les frais par utilisateur. Les données de transaction dans les Rollups sont soumises à la couche 1, mais les exécutions sont effectuées de manière indépendante par les Rollups. En soumettant les données de transaction à la couche 1, les Rollups peuvent hériter de la sécurité d'Ethereum car une fois les données téléchargées sur la couche 1, il est nécessaire de les faire revenir sur la couche 1 pour annuler les transactions des Rollups.

Actuellement, les Rollups peuvent être mis en œuvre de deux manières principales :

Rollups optimistes : Utilisez des incitations économiques et la théorie des jeux pour vérifier les transactions, telles que Arbitrum, Base, OP, Blast, etc.

Zero-Knowledge Rollups : Utilisez des preuves à divulgation nulle pour la sécurité et la confidentialité, telles que Scroll, Linea, zkSync, StarkNet, etc.

Optimistic Rollups

Introduction

Les rollups optimistes sont un moyen de mettre à l'échelle Ethereum en déplaçant le calcul et le stockage de l'état hors chaîne. Il exécute des transactions hors chaîne, mais publie les données de transaction sur le mainnet en tant que calldata ou blob.

Les Rollups optimistes déploient un contrat intelligent sur Ethereum, appelé contrat Rollup, qui gère l'état du Rollup, suit les soldes des utilisateurs et gère les dépôts, retraits et résolutions de litiges. Les transactions sont collectées et résumées hors chaîne par un séquenceur et plusieurs transactions sont regroupées dans un bloc Rollup qui contient un résumé et une preuve cryptographique du nouvel état du compte (racine de Merkle). Le séquenceur engage ensuite le bloc Rollup sur la chaîne principale en fournissant des racines de Merkle et des données d'appel.

Les cumuls optimistes sont considérés comme « optimistes » car ils supposent que les transactions hors chaîne sont valides et ne publient pas de preuve de la validité des lots de transactions poussés sur la chaîne. Optimistic Rollups, en revanche, s’appuie sur des systèmes de protection contre la fraude pour détecter les cas où les transactions sont mal calculées. Après avoir soumis un lot de cumul sur Ethereum, il existe une fenêtre de temps (appelée période de défi) pendant laquelle tout le monde peut contester les résultats d’une transaction de cumul en calculant la preuve de fraude. La preuve de fraude contient les détails d’une transaction particulière que le vérificateur considère comme frauduleuse.

Comme le montre la figure ci-dessous, la période de défi de la plupart des Optimistic Rollups actuels est de 7 jours et la plus courte est de 1 jour.

Pendant la période de défi, n'importe qui peut contester les résultats de la transaction en calculant la preuve de fraude. Si la transaction est invalide, le bloc Rollup est révoqué, le challenger est récompensé et le séquenceur est puni.

Si le lot Rollup reste sans contestation après la période de contestation (c'est-à-dire que toutes les transactions ont été exécutées correctement), il est considéré comme valide et accepté sur Ethereum. D'autres peuvent continuer à étendre des blocs Rollup non confirmés, mais notez que les résultats de la transaction seront inversés si la transaction est exécutée sur la base d'une erreur précédemment publiée.

Enfin, l'utilisateur doit soumettre une demande de retrait au contrat Rollup pour retirer des fonds de la couche 2 à la couche 1. Le contrat vérifiera que l'utilisateur dispose de suffisamment de fonds sur le Rollup et mettra à jour son solde sur la chaîne principale en conséquence.

Réseaux de couche 2 leader

1. Arbitrum

Avec la construction écologique et les largages aériens, Arbitrum est rapidement devenu le réseau le plus actif dans la couche 2 ETH, avec un TVL dépassant 2,7 milliards de dollars. Après le grand largage aérien, l'équipe Arbitrum a lancé le programme Arbitrum Orbit : encourageant les développeurs à construire la couche 3 en utilisant les technologies liées à Arbitrum. Beosin a terminé l'audit de sécurité d'ArbSwap, d'Arbipad pour aider au développement de la sécurité de l'écosystème Arbitrum.

1. Optimisme

Bien que Optimism soit moins actif sur le plan écologique qu'Arbitrum, OP Stack, lancé par Optimism en 2023, a été largement reconnu par l'industrie comme une solution complète et viable pour la construction d'une couche 2 modulaire. Plus de 25 réseaux de couche 2 ont été construits en utilisant OP Stack, y compris des projets phares tels que Base, Mantle, Manta, OP BNB et Celo. DIPX Finance et Starnet construits sur Optimism ont passé l'audit de sécurité de Beosin.

1. Base

Base est un réseau de couche 2 basé sur OP Stack, qui est le deuxième seulement après Arbitrum en termes d'activité écologique et de TVL. Auparavant, Beosin a analysé en détail l'architecture de Base et les risques de sécurité, et a audité Surf Protocol et EDA pour aider les propriétaires de projets et les utilisateurs à éviter les risques de sécurité.

1. Explosion

À la fin de son concours de développement “Big Bang”, Blast a vu son TVL grimper à plus de 2 milliards de dollars, se plaçant sur le circuit Layer2. Beosin a analysé la sécurité réseau de Blast avant le lancement de son mainnet. Étant donné que Blast n'implémente pas de preuve de fraude, les actifs sont détenus dans un portefeuille multi-signature, et non dans un pont Rollup, ce qui présente un risque élevé de centralisation. Beosin a audité plusieurs projets écologiques de Blast tels que Wand Protocol, Zest, Kalax.

Analyse d'architecture

OP Stack, un cadre mature pour les Optimistic Rollups, décompose essentiellement le processus complexe de construction de chaînes Optimistic Rollups en un processus simplifié en fournissant un ensemble complet de composants logiciels, d'outils et de cadres. Ici, nous prenons le cadre Op stack comme exemple pour analyser l'architecture typique des Optimism Rollups.

● Le nœud d'exécution : Op-geth est un client d'exécution étendu pour Ethereum qui gère les fonctions spécifiques de la couche 2, telles que la réception de dépôts de jetons de la couche 1. Cette couche définit toutes les fonctions responsables de l'exécution des variations d'état. Ici, les transitions d'état sont déclenchées en fonction des données reçues des nœuds de résumé (séquences et validateurs) via l'API du moteur.

● Nœud Rollup : comprend un séquenceur et un validateur. Le collecteur est responsable de l'envoi groupé des transactions traitées de la couche 2 vers la couche 1. Le séquenceur définit comment les transactions sur la chaîne Layer2 sont collectées et publiées. Le validateur/vérificateur vérifie la validité de la transaction groupée et soumet des preuves en cas de fraude détectée.

● Preuve de fraude : Cannon est une version améliorée de Geth et est responsable de l'exécution de l'EVM pendant la phase de détection et de preuve de fraude. Il s'agit essentiellement d'un moteur de litige on-chain qui coordonne les séquenceurs et les validateurs via des APIs pour prouver les transactions fausses.

● Engagement en lot : Les séquenceurs traitent en lot toutes les transactions traitées en une fois, vérifiées par les vérificateurs, et les séquenceurs soumettent les transactions traitées en lot à la couche 1.

● Contrats de pont : Déployés sur Ethereum et Layer2, permettant aux utilisateurs de transmettre des messages et de transférer des actifs entre Layer1 et Layer2.

Sous l'architecture technique d'Optimistic Rollup, il est essentiel de garantir la sécurité des actifs des utilisateurs lorsqu'ils passent de L1 à L2. Les détails suivants expliquent comment les utilisateurs peuvent accéder aux actifs entre les deux couches et comment le système maintient l'intégrité et la sécurité de ces transactions.

● Pontage d'actifs vers Rollup : les utilisateurs déposent des fonds dans le contrat de pont de chaîne de Rollup sur la couche 1. Le contrat de pont de chaîne relaie la transaction vers la couche 2, où une quantité équivalente d'actifs est créée et envoyée à une adresse sélectionnée par l'utilisateur dans l'Optimistic Rollup.

Les transactions générées par l'utilisateur, telles que les dépôts de la couche 1 à la couche 2, sont généralement mises en file d'attente jusqu'à ce que le séquestre les soumette à nouveau au contrat Rollup. Cependant, afin de maintenir la résistance à la censure, Optimistic Rollup permet aux utilisateurs de soumettre directement des transactions aux contrats Rollup on-chain si les retards de transaction dépassent le temps maximum autorisé.

● Retrait d'actifs de Rollup : en raison du mécanisme de preuve de fraude, le retrait d'argent d'Optimistic Rollup vers Ethereum est plus compliqué. Si un utilisateur initie une transaction de couche 2 vers couche 1 pour retirer des fonds gérés sur la couche 1, il doit attendre la fin de la période de contestation, qui dure généralement environ 7 jours.

Lorsque l'utilisateur lance une demande de retrait sur Rollup, la transaction est incluse dans le lot suivant et les actifs de l'utilisateur sur Rollup sont détruits. Une fois que le lot est publié sur Ethereum, les utilisateurs peuvent calculer une preuve de Merkle pour vérifier que leur transaction de sortie est incluse dans le bloc. La prochaine étape consiste à attendre la fin de la période de délai pour finaliser la transaction sur Layer1 et retirer les fonds sur le mainnet.

Pour éviter d'attendre une semaine avant de retirer de l'argent d'Ethereum, les utilisateurs d'Optimistic Rollup peuvent demander une avance à un fournisseur de liquidité (LP), qui assume la propriété des retraits en attente et paie les fonds de l'utilisateur sur Layer1 en échange d'un frais. Les fournisseurs de liquidité peuvent vérifier la validité des demandes de retrait des utilisateurs en vérifiant eux-mêmes les données on-chain avant de libérer les fonds. De cette manière, ils peuvent s'assurer que la transaction sera finalement confirmée, atteignant la certitude de confiance.

Articles d'audit

Layer2 est un système de blockchain complet, donc l'audit commun des chaînes publiques s'applique également à Optimistic Rollup, comme détaillé dans l'annexe à la fin de cet article.

De plus, en raison de sa nature particulière, Optimistic Rollup nécessite un certain nombre d'audits supplémentaires :

● Preuve de disponibilité des données : Assurez-vous que les données de transaction de la couche 2 sont disponibles sur la couche 1 pour éviter toute perte de données.

● Mécanisme de synchronisation des données : Vérifier si le mécanisme de synchronisation des données entre la couche 1 et la couche 2 est fiable et peut gérer des situations anormales telles que le partitionnement du réseau.

● Contrat de preuve de fraude : Vérifiez que le contrat de preuve de fraude est implémenté correctement.

● Mécanisme de période de défi : Vérifiez si la durée de la période de défi est raisonnable et si la preuve de fraude peut être terminée dans le délai spécifié.

● Processus de soumission de preuve de fraude : Vérifiez que le processus de soumission de preuve de fraude est sécurisé.

● Processus de dépôt et de retrait : Vérifiez le processus de dépôt et de retrait de la couche 1 à la couche 2 et de la couche 2 à la couche 1 pour garantir la sécurité du processus.

● Création et destruction d'actifs : Vérifiez la logique de création et de destruction de l'actif sur Layer2 pour garantir la correspondance correcte avec l'actif sur Layer1.

● Mécanisme de fournisseur de liquidité : s'il existe un mécanisme de fournisseur de liquidité (LP), il est nécessaire d'examiner le processus opérationnel du LP et sa sécurité.

Rollups de preuve zéro

Introduction

Zero-Knowledge (ZK) Rollup est une solution de mise à l'échelle basée sur la couche 2 basée sur une preuve de connaissance nulle. Elle effectue principalement des calculs complexes et la génération de preuves hors chaîne, vérifie les preuves sur la chaîne et stocke une partie des données pour garantir leur disponibilité.

ZK Rollup est une "solution d'échelle hybride" qui est un protocole hors chaîne qui fonctionne indépendamment mais qui bénéficie de la sécurité d'Ethereum. Plus précisément, le réseau Ethereum impose la validité des mises à jour d'état sur les ZK Rollups et garantit la disponibilité des données de fond à chaque mise à jour de l'état du Rollup. L'état du Rollup est géré par des contrats intelligents déployés sur le réseau Ethereum. Pour mettre à jour cet état, le nœud ZK Rollups doit soumettre une preuve de validité pour vérification. Une preuve de validité est une garantie cryptographique qu'un changement proposé dans l'état est bien le résultat de l'exécution d'un lot donné de transactions. Cela signifie que les ZK Rollups n'ont besoin que de fournir une preuve de validité pour finaliser les transactions sur Ethereum, sans avoir à publier toutes les données de transaction.

Il n'y a aucun retard dans le transfert de fonds des ZK Rollups vers Ethereum, car la transaction de sortie est exécutée une fois que le contrat ZK Rollups a vérifié la preuve de validité. En revanche, le retrait de fonds des Optimistic Rollups crée des retards car n'importe qui peut utiliser une preuve de fraude pour contester une transaction de sortie.

Réseaux Layer2 leaders

1. zkSync

zkSync, une solution de couche L2 lancée il y a cinq ans par l'équipe de Matter Labs, utilise la technologie de preuve de connaissance nulle pour permettre une vérification efficace des transactions et a levé plus de 200 millions de dollars. zkSync est l'un des réseaux de couche 2 les plus écologiquement actifs utilisant ZK Rollups, et zkSync est également controversé. Beosin a précédemment effectué un audit de son principal projet DeFi, SyncSwap, couvrant la qualité du code, la logique des contrats et la sécurité, le modèle opérationnel, et plus encore.

1. StarkNet

StarkNet utilise ZK-STARK pour construire une couche 2 afin d'augmenter la vitesse des transactions et réduire les frais de transaction. StarkNet dispose d'une machine virtuelle native (Cairo VM) et d'un langage de développement (Cairo) pour aider les développeurs à écrire des contrats intelligents de manière plus sûre et facile. Beosin est devenu un partenaire de sécurité officiel de StarkNet, réalisant des audits de sécurité pour Option Dance et Reddio. Le 13 août 2024, Reddio a clôturé une levée de fonds de démarrage dirigée par Paradigm pour construire un réseau EVM Layer2 parallèle à haute performance.

1. Faire défiler

Scroll est mis à l'échelle par la technologie de preuve à divulgation nulle, et le matériel accélère la génération et la vérification des preuves à divulgation nulle, dans le but d'atteindre une compatibilité EVM de niveau bytecode. Cela signifie que les développeurs peuvent directement utiliser Solidity et les outils de développement liés à Ethereum pour construire des contrats intelligents.

Analyse de l'architecture

Les frameworks courants pour les ZK Rollups comprennent Rollup et des contrats de pont, des collecteurs, des agrégateurs, des répéteurs et des réseaux Roller qui génèrent des preuves à divulgation nulle. L'architecture spécifique est illustrée dans la figure suivante:

● Contrat Rollup et contrat de pont :

Le contrat Rollup est responsable de fournir la disponibilité des données pour les transactions Rollup, de vérifier la preuve de validité zkEVM et de permettre aux utilisateurs de transférer des actifs entre Ethereum et Rollup. Il reçoit la racine de l'état de la couche 2 et le bloc du validateur, la racine de l'état est stockée dans l'état d'Ethereum et les données de bloc de la couche 2 sont enregistrées en tant que calldata d'Ethereum.

Les contrats de pont sont déployés sur Ethereum et Layer2, permettant aux utilisateurs de transmettre des messages et de transférer des actifs entre Layer1 et Layer2.

● Séquenceur: Le séquenceur fournit l'interface JSON-RPC et accepte les transactions Layer2, récupère périodiquement un lot de transactions depuis le pool mémoire pour les exécuter, générant ainsi de nouveaux blocs Layer2 et des racines d'état. Son implémentation est généralement basée sur Go-Ethereum (Geth), garantissant la meilleure compatibilité et la plus haute sécurité.

● Coordinateur : Le coordinateur est notifié lorsque le collecteur génère un nouveau bloc et reçoit une trace d'exécution de ce bloc du collecteur. La trace d'exécution est ensuite envoyée à un Roller sélectionné au hasard dans le réseau Roller, qui génère une preuve de validité.

● Relayer : Le répéteur surveille les contrats Rollup et les contrats de pont déployés sur Ethereum et Layer2. Les principales responsabilités sont les suivantes : 1) Suivi de la disponibilité des données et validation des blocs Layer2 en surveillant les contrats Rollup ; 2) Surveillance des événements de dépôt et de retrait d'engagement de pont Ethereum et Layer2 et transmission des messages à l'autre extrémité.

● Roller Network: Roller dans le réseau Roller agit en tant que prouveur et est responsable de la génération de la preuve de validité pour ZK Rollup. Une trace d'exécution de bloc est d'abord reçue du coordinateur, convertie en un témoin de circuit, puis une preuve est générée pour chaque zkevm en utilisant l'accélération matérielle, et enfin une agrégation de preuves est utilisée pour agréger plusieurs preuves en une seule preuve.

Dans le cadre de l’architecture technique de ZK Rollups, il est essentiel d’assurer la sécurité des actifs des utilisateurs lors du transfert entre L1 et L2. Ce qui suit détaille comment les utilisateurs peuvent accéder aux ressources entre les deux couches et comment le système maintient l’intégrité et la sécurité de ces transactions.

● Le pontage d'actifs vers Rollup : les utilisateurs entrent dans le Rollup en déposant des jetons dans un contrat ZK Rollups déployé sur une couche de chaîne réseau. Cette transaction doit être soumise au contrat Rollup par le côté du projet.

Si la file d'attente des dépôts en attente commence à se remplir, l'opérateur ZK Rollups acceptera ces transactions de dépôt et les soumettra au contrat Rollup. Une fois que les fonds sont déposés dans Rollup, l'utilisateur peut commencer le traitement des transactions.

Les utilisateurs peuvent vérifier le solde sur Rollup en hachant leur compte, en envoyant la valeur de hachage au contrat Rollup et en fournissant une preuve de Merkle qui vérifie par rapport à la racine de l'état actuel.

● Retrait des actifs de Rollup : L'utilisateur initie une transaction de sortie, envoyant les actifs de leur Rollup vers le compte spécifié pour destruction. Si l'opérateur ajoute la transaction au prochain lot, l'utilisateur peut soumettre une demande de retrait au contrat on-chain. Les demandes de retrait incluent :

1. Preuve de Merkle, qui prouve que la transaction de l'utilisateur est ajoutée au compte détruit dans le lot de transactions

2. Données de transaction

3. Lotir la racine

4. Adresse du réseau Layer1 pour recevoir les fonds déposés

Le contrat Rollup hache les données de transaction, vérifie si la racine du lot existe, et utilise la preuve de Merkle pour vérifier si le hachage de transaction fait partie de la racine du lot. Le contrat exécute la transaction de sortie et envoie des fonds à une adresse sur le réseau Layer1 sélectionnée par l'utilisateur.

Éléments d'audit

La couche 2 est un système de blockchain complet, donc les éléments d'audit courants pour les blockchains s'appliquent également à ZK Rollup, comme détaillé dans l'annexe à la fin de cet article.

De plus, en raison de sa nature spéciale, ZK Rollup doit effectuer des audits supplémentaires :

● Preuve de sécurité du système : Vérifier la sécurité et la correction des schémas de preuve à divulgation nulle utilisés (par exemple, Groth16, Plonk, Halo2, zk-STARK, etc.).

● Sécurité des circuits : vérifiez les vulnérabilités possibles dans la conception et la mise en œuvre des circuits, notamment les suivantes :

1. Circuits sous-contraints

2. Circuits sur-contraints

3. Circuits non déterministes

4. Débordements arithmétiques supérieurs/inferieurs Débordements arithmétiques supérieurs/inferieurs

5. Longueurs de bits incompatibles

6. Entrées publiques inutilisées optimisées

7. Cœur Gelé: Forgeage de Preuves de Connaissance Zéro

8. Fuite de configuration de confiance

9. Assigné mais non contraint

10. Utilisation non sécurisée des composants

11. Précision variable

● Génération et validation de la preuve : Examinez le processus de génération et de validation de la preuve pour vous assurer qu'il est efficace et sécurisé.

● Preuve de la disponibilité des données : assurez-vous que les données de transaction de la couche 2 sont disponibles sur la couche 1 pour éviter toute perte de données.

● Mécanisme de synchronisation des données : Vérifiez si le mécanisme de synchronisation des données entre la couche 1 et la couche 2 est solide et peut gérer des situations anormales telles que le partitionnement du réseau.

● Processus de dépôt et de retrait : Vérifiez le processus de dépôt et de retrait de la couche 1 à la couche 2 et de la couche 2 à la couche 1 pour vous assurer que le processus est sûr.

● Création et destruction d'actifs : Vérifiez la logique de création et de destruction de l'actif sur la couche 2 pour garantir la correspondance correcte avec l'actif de la couche 1.

● Recherche de dépendances externes et de vulnérabilités connues : ZK Rollup s’appuie souvent fortement sur des référentiels ou des outils cryptographiques et mathématiques de tiers et doit vérifier minutieusement la sécurité de leurs dépendances pour l’analyse et la validation des vulnérabilités connues.

Annexe

Audit général des éléments de la blockchain & Layer2 :

● Débordement entier : Vérifiez les débordements et les sous-débordements entiers

● Boucle : Vérifiez la boucle du programme pour voir si la condition est raisonnable

● Appel récursif infini : Vérifiez si la condition de sortie de l'appel récursif du programme est raisonnable

● Condition de concurrence : vérifie l’accès aux ressources partagées à l’état simultané

● Plantage d’exception : recherchez le code de levée d’exception qui entraîne la fermeture active du programme

● Vulnérabilité de division par 0 : Vérifiez s'il y a un cas de division par 0

● Conversion de type : Vérifiez si la conversion de type est correcte et si des informations importantes sont perdues pendant la conversion

● Dépassement de tableau : Vérifie l'accès aux éléments en dehors des limites du tableau

● Vulnérabilité de désérialisation : Vérifiez les problèmes lors de la désérialisation

● Sécurité de mise en œuvre des fonctions : Vérifiez si la mise en œuvre des interfaces RPC comporte des risques de sécurité et est conforme à la conception fonctionnelle des interfaces RPC

● Que les paramètres de permission de l'interface RPC sensible soient raisonnables : Vérifiez les paramètres d'accès de permission de l'interface RPC sensible

● Mécanisme de transmission crypté : vérifiez si un protocole de transmission crypté, tel que TLS, est utilisé

● Analyse du formatage des données de demande : Vérifie le processus de 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é de composant tiers/contamination de paramètre HTTP/injection SQL/injection d'entité XXE/vulnérabilité de désérialisation/vulnérabilité SSRF/injection de code/inclusion de fichier local/inclusion de fichier distant/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 du réseau : vérifier s'il existe un mécanisme d'identification de l'identité du nœud, le mécanisme d'identification de l'identité du nœud peut être contourné

● Contamination de la table de routage : Vérifiez si la table de routage peut être insérée ou écrasée arbitrairement

● Algorithme de découverte de nœuds : Vérifiez si l'algorithme de découverte de nœuds est équilibré et imprévisible, par exemple, si l'algorithme de distance est déséquilibré

● Audit de l'utilisation de la connexion : Vérifiez si la limite et la gestion du nombre de nœuds connectés au réseau p2p sont raisonnables

Attaques d'éclipse solaire : évaluer les coûts et les dangers des attaques d'éclipse solaire, en fournissant une analyse quantitative si nécessaire

● Attaque Sybil : Évaluation des mécanismes de consensus de vote et analyse des stratégies de vérification de l'éligibilité au vote

● Attaque d’écoute clandestine : vérifiez si le protocole de communication divulgue la confidentialité

● Attaque extraterrestre: Évalue si le nœud peut reconnaître le même type de nœud de chaîne

● Détournement temporel : Vérifier le mécanisme de calcul du temps réseau d'un nœud

● Attaque d’épuisement de la mémoire : vérifiez si la consommation de mémoire est importante

● Attaque d'épuisement du disque dur : Vérifiez où sont stockés les gros fichiers

● attaque de pression sur la socket : Vérifiez la politique de limite sur le nombre de connexions

● Attaque d'épuisement des poignées du noyau: Vérifier les limitations de création des poignées du noyau, telles que les poignées de fichiers

● Fuites de mémoire persistantes: Vérifiez les fuites de mémoire

● Sécurité de l'algorithme de hachage : Vérifiez la résistance aux collisions de l'algorithme de hachage

● Sécurité de l'algorithme de signature numérique : Vérifiez la sécurité de l'algorithme de signature et de sa mise en œuvre.

● Sécurité de l'algorithme de chiffrement : Vérifiez la sécurité de l'algorithme de chiffrement et de sa mise en œuvre

● Sécurité du générateur de nombres aléatoires : vérifiez si l’algorithme de génération de nombres aléatoires clés est raisonnable

● Sécurité de l'implémentation BFT: évaluer la sécurité de l'implémentation des algorithmes BFT

● Règles de sélection des forks : Vérifiez les règles de sélection des forks pour garantir la sécurité

● Test du degré de centralisation : Identifier s'il existe une conception trop centralisée dans la conception du système

● Audit des incitations : Évaluez l’impact des incitations sur la sécurité

● Attaques à double dépense : vérifiez si le consensus peut se défendre contre les attaques à double dépense.

● Audit d’attaque MEV : examinez l’impact du MEV du nœud de package de bloc sur l’équité de la chaîne

● Audit du processus de synchronisation des blocs: Vérifie les problèmes de sécurité lors de la synchronisation

● Audit du processus d'analyse du format de bloc: Vérifie les problèmes de sécurité lors de l'analyse du format, tels que les erreurs d'analyse qui provoquent des plantages

● Audit du processus de génération de blocs : Vérifier les problèmes de sécurité dans le processus de génération de blocs, y compris si la racine de l'arbre de Merkle est construite de manière raisonnable

● Audit du processus de vérification de bloc : Vérifier si les éléments de signature de bloc et la logique de vérification sont suffisants

● Audit de la logique de validation des blocs: Vérifier si l'algorithme et l'implémentation de validation des blocs sont raisonnables

● Collision de hachage de bloc : Vérifiez comment la collision de hachage de bloc est construite et si la collision est gérée de manière raisonnable

● Limites des ressources de traitement des blocs : Vérifiez si les pools de blocs orphelins, le calcul de vérification, l'adressage du disque dur et autres limites de ressources sont raisonnables

● Audit du processus de synchronisation des transactions : vérifie les problèmes de sécurité dans le processus de synchronisation

● Collisions de hachage de transaction : Examinez comment les collisions de hachage de transaction sont construites et comment elles sont gérées

● Analyse du format de transaction : Vérifier les problèmes de sécurité lors de l'analyse du format, tels que les erreurs d'analyse qui provoquent des plantages

● Vérification de la validité de la transaction : Vérifiez si les éléments de signature de chaque type 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, le calcul de vérification et l'adressage du disque dur sont raisonnables

● Attaque de malléabilité de transaction : Il s'agit de la capacité à modifier des champs internes d'une transaction (tels que ScriptSig) pour changer le hachage de transaction sans affecter la validité de la transaction.

● Audit de l’attaque par relecture des transactions : vérifie la détection par le système de la relecture des transactions

● Vérification du bytecode du contrat : Vérifier la sécurité du processus de vérification du contrat de la machine virtuelle, tels que le débordement d'entiers et les boucles mortes

● Exécution du bytecode du contrat : Vérifiez la sécurité du processus d'exécution du bytecode de la machine virtuelle, tel que le débordement d'entier, les boucles infinies, et ainsi de suite

● Modèle de gaz : Vérifier que les frais pour chaque opération atomique du traitement de la transaction/exécution du contrat sont proportionnels à la consommation de ressources

● Intégrité du journal : vérifiez si les informations clés sont enregistrées

● Sécurité des journaux: Vérifiez si la manipulation incorrecte des journaux cause des problèmes de sécurité, tels que le débordement d'entiers.

● Les journaux contiennent des informations sur la confidentialité : vérifiez si les journaux contiennent des informations sur la confidentialité, telles que des clés.

● Stockage des journaux : Vérifiez si des contenus excessifs sont enregistrés dans les journaux, ce qui consomme des ressources du nœud

● Code de noeud Sécurité de la chaîne d'approvisionnement: Vérifiez tous les bibliothèques, composants et versions de frameworks de chaîne publique pour les problèmes connus

Démenti:

1. Cet article est reproduit à partir de [beosin]. Tous les droits d'auteur appartiennent à l'auteur original [beosin]. S’il y a des objections à cette réimpression, veuillez contacter le Porte d’apprentissageéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les vues et opinions exprimées dans cet article sont uniquement celles de l'auteur et ne constituent pas un 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.