Le 10 octobre, à 14 heures, le mainnet de la solution Ethereum Layer 2 Scroll a généré son premier bloc, marquant ainsi le lancement réussi du mainnet de Scroll. Depuis le 25 octobre, plus de 7600 ETH ont été intégrés au réseau Scroll par le biais de ponts inter-chaînes, et 24 plateformes d'échange décentralisées ont été mises en service sur le réseau principal de Scroll, avec un TVL total d'environ 10 millions de dollars.
Le 17 octobre, Scroll a officiellement annoncé le lancement de son réseau principal, tout en continuant à défendre son engagement en faveur de l'open source et de la décentralisation. Dans la phase suivante, Scroll se concentrera sur la construction d'un réseau décentralisé de preuve d'enjeu et d'une trieuse. Dans cet article, nous fournirons une analyse détaillée de l'architecture et de la technologie de Scroll afin d'aider tout le monde à comprendre l'état actuel du réseau et l'orientation future du développement de Scroll. Nous expliquerons également le circuit zkEVM de Scroll et les connaissances en matière d'audit afin de renforcer les mesures de sécurité pour les projets zk.
Scroll est une solution de mise à l'échelle de la couche 2 d'Ethereum basée sur la technologie de preuve à connaissance nulle, visant à améliorer le débit et la vitesse des transactions du réseau Ethereum. Par rapport au Rollup optimiste, Scroll atteint l'évolutivité grâce aux preuves à connaissance nulle et accélère la génération et la vérification des preuves à connaissance nulle grâce à l'accélération matérielle. Elle s'est engagée à réaliser une compatibilité EVM au niveau du bytecode. Cela signifie que les développeurs peuvent utiliser directement Solidity et les outils de développement liés à Ethereum pour construire des contrats intelligents et les déployer sur Scroll sans aucune modification.
Selon le site officiel de Scroll, l'équipe de Scroll compte actuellement 10 membres principaux, répartis entre l'Asie, l'Amérique et l'Europe. Les membres de l'équipe ont une grande expérience du développement de zkRollup et des opérations industrielles, la plupart d'entre eux étant diplômés d'universités prestigieuses et titulaires d'un doctorat.
Actuellement, l'écosystème Scroll est très riche, avec des projets d'infrastructure comprenant des portefeuilles, des outils de développement, des dispositifs de sécurité, etc. L'objectif est de fournir un soutien complet aux projets tout au long de leur cycle de vie, depuis la conception, le développement, l'exploitation jusqu'à l'audit de sécurité. Il existe actuellement plus de 180 projets d'écosystèmes sur le réseau principal Scroll.
Portefeuille
Scroll prend actuellement en charge presque tous les portefeuilles courants : Metamask, TrustWallet, MathWallet, TokenPocket, WalletConnect, Binance Chain Wallet, SafePal Wallet. En outre, l'écosystème de portefeuilles Scroll comprend également OKX Wallet, Versa Wallet, etc.
Pont inter-chaînes
L'infrastructure officielle de la chaîne croisée de Scroll comprend Celer Network, Stargate, Orbiter Finance, Hop Protocol, LI.FI, Connext, etc. En outre, il comprend également le protocole de liquidité cross-chain Synapse Protocol, Owlto Finance qui se concentre sur les ponts cross-chain de couche 2, le pont cross-chain Ethereum de couche 1 et de couche 2 Pheasant Network, Symbiosis, Catalyst, etc.
DeFi
Dans l'écosystème Scroll, il existe plusieurs projets DeFi bien établis, notamment le protocole de prêt Aave, l'agrégateur DEX multi-chaînes DODO, DEX SushiSwap, l'agrégateur DEX OpenOcean, le protocole DeFi multi-chaînes iZUMi Finance, DEX Syncswap, le protocole de rendement Pendle Finance, le protocole de prêt dForce, et l'agrégateur d'opérations à effet de levier MUX Protocol. Il existe également des projets innovants, comme le GMX, qui n'ont pas été largement adoptés.
Autres projets
En termes de NFT, de jeux et d'aspects sociaux, les autres projets de l'écosystème Scroll comprennent NFTScan, la plateforme de tâches Web3 QuestN, TaskOn, la plateforme de signature de protocole électronique EthSign, Galaxy Blitz, OmniKingdoms et d'autres jeux blockchain en ligne.
Qu'est-ce qui distingue la technologie Scroll des autres ?
L'architecture de Scroll se compose de trois éléments :
Le nœud Scroll : Il génère des blocs sur le réseau Scroll en fonction des transactions des utilisateurs, soumet ces transactions à la couche de base Ethereum et gère la transmission des messages entre Ethereum et Scroll.
Roller : Le Roller est chargé de convertir les contrats intelligents en circuits zkEVM, puis de générer des preuves pour prouver l'exactitude des transactions. Le réseau Scroll comporte plusieurs rouleaux qui traitent les transactions en parallèle et accélèrent la production de preuves par le biais du matériel. Scroll assure la compatibilité au niveau du bytecode avec EVM en prouvant directement l'exactitude du traitement du bytecode d'EVM.
Rollup and Bridge Contract : Ces contrats assurent la disponibilité des données pour les transactions Scroll et vérifient les preuves de validité générées par zkEVM. On peut dire que Scroll est connecté à la couche de base Ethereum par le biais des contrats Rollup et Bridge. Grâce à ces contrats, les utilisateurs peuvent échanger des messages arbitraires entre Ethereum et Scroll, et transférer des actifs ERC-20 dans les deux sens à l'aide de contrats passerelles.
source : https://scroll.mirror.xyz/nDAbJbSIJdQIWqp9kn8J0MVS4s6pYBwHmK7keidQs-k
Scroll est le contrat principal déployé sur la blockchain Ethereum:.
Contrat de proxy de routage de passerelle (garantissant le mappage correct des jetons dans les opérations entre chaînes):0xF8B1378579659D8F7EE5f3C929c2f3E332E41Fd6
Contrat de proxy de messages (transmission de messages entre L1 et L2):0x6774Bcbd5ceCeF1336b5300fb5186a12DDD8b367
Il convient de noter que ces contrats peuvent être modifiés par l'administrateur et le propriétaire du proxy. En outre, Scroll a intégré une fonction de liste blanche qui permet d'ajuster les frais de gaz pour des adresses spécifiques au sein de Scroll. Actuellement, le séquenceur Scroll fonctionne de manière centralisée, ce qui permet d'examiner les messages et les transactions sur le réseau Scroll. En outre, il est possible d'ignorer n'importe quel message dans la file d'attente et de confirmer directement un message spécifique.
Une fois que Scroll a généré un bloc, celui-ci passe par un coordinateur et plusieurs prouveurs (Rollers) pour générer des preuves agrégées. Ces preuves sont ensuite soumises au contrat Ethereum Rollup pour vérification. La procédure détaillée est la suivante :
1、Le séquenceur reçoit de nouvelles transactions. La machine virtuelle lit le bytecode associé à chaque transaction, génère une trace d'exécution et l'envoie au coordinateur. Simultanément, le séquenceur soumet les données de la transaction au contrat de reconduction.
2、Rollers convertissent les traces d'exécution reçues du coordinateur en circuits zkEVM. Chaque étape de la trace d'exécution correspond à un circuit zkEVM. Pour les fonctions qui ne sont pas compatibles avec zk (telles que hash et Keccak), Scroll construit des tables de recherche pour faire correspondre les entrées et les sorties de ces fonctions dans la trace d'exécution à la table de recherche. Des circuits supplémentaires sont utilisés pour vérifier l'exactitude de la table de conversion. Les rouleaux génèrent ensuite des preuves pour ces circuits zkEVM.
3、Après avoir produit les épreuves, les rouleurs les renvoient au coordinateur. Tous les quelques blocs, le coordinateur attribue au hasard des tâches d'agrégation à un Roller. Le Roller assigné regroupe ensuite les preuves de plusieurs blocs en une seule preuve.
4、La dernière étape consiste pour le coordinateur à soumettre la preuve agrégée au contrat de reconduction. Le contrat de rollup utilise cette preuve pour vérifier l'exactitude des données d'état et de transaction soumises précédemment, confirmant ainsi l'exactitude du bloc.
zkEVM se compose de plusieurs circuits, chacun chargé de vérifier un aspect spécifique de l'EVM (Ethereum Virtual Machine). Ces circuits sont finalement combinés ou agrégés pour générer une preuve d'exécution de la transaction. Le diagramme ci-dessous illustre la relation entre ces circuits et les tableaux.
Il existe des sous-circuits plus petits, tels que le circuit ECDSA et les sous-circuits liés aux opcodes, qui n'interagissent pas avec d'autres tables et circuits d'une manière qui affecte la combinaison du circuit. Ces sous-circuits sont omis dans le diagramme par souci de clarté.
Circuit EVM
La machine virtuelle Ethereum (EVM) est une machine d'état qui établit les règles pour les transitions d'état valides au sein du protocole Ethereum. Il exécute des instructions (opcodes) pour réaliser ces transitions et génère une trace d'exécution. L'objectif du circuit EVM est de créer un système de contraintes qui représente la trace d'exécution et peut être vérifié à l'aide d'un système de preuve à connaissance nulle.
La conception de haut niveau du circuit de l'EVM est quelque peu similaire à la conception de l'EVM lui-même, comme go-ethereum. Dans go-ethereum, l'interpréteur parcourt tous les opcodes d'instruction sur la trace d'exécution. Pour chaque instruction, l'interprète vérifie les informations contextuelles pertinentes telles que le gaz, la pile et la mémoire, puis envoie l'opcode à la JumpTable, qui fournit des instructions détaillées pour l'exécution de l'opcode.
De même, dans les circuits EVM, Scroll construit des étapes d'exécution sur la base de la trace d'exécution et fournit des preuves pour les opcodes et les contextes d'exécution. Pour chaque étape d'exécution, un ensemble de contraintes est appliqué pour vérifier les informations contextuelles. Pour chaque opcode, un ensemble de contraintes est appliqué pour vérifier son comportement. Dans la trace d'exécution, le même opcode doit avoir les mêmes contraintes. Scroll utilise des sélecteurs pour "ouvrir" toutes les étapes avec le même opcode dans la trace d'exécution et utilise le système de preuve en arrière-plan pour prouver leur comportement.
Circuit de l'État
Pendant l'exécution, toutes les opérations de lecture et d'écriture de l'EVM sont enregistrées dans la table rw et ordonnées par la variable rw_counter. L'objectif du circuit d'état est de démontrer la précision de la génération de la table rw_.
Circuit MPT
L'arbre Merkle Patricia (MPT) est une structure de données clé utilisée dans la couche de stockage d'Ethereum. Dans les circuits zkevm de Scroll, le MPT est modifié en zkTrie, qui est essentiellement un Merkle Patricia Trie binaire clairsemé. Dans zkevm-Circuits, Scroll utilise la table MPT pour suivre pas à pas les transitions d'état des opérations MPT. Le tableau MPT se présente comme suit :
L'objectif du circuit MPT est de vérifier l'exactitude du tableau MPT mentionné ci-dessus. Il garantit que chaque mise à jour enregistrée dans la table MPT entraîne une modification correcte. Cela signifie que pour chaque mise à jour, le circuit MPT garantit qu'il n'y a qu'une seule façon possible d'effectuer les changements. Cela permet d'éviter les modifications accidentelles ou non autorisées et de garantir l'intégrité et l'exactitude du TPM. En particulier, lorsque le TPM subit des modifications dues à des mises à jour des comptes ou du stockage, le circuit du TPM doit prouver que ces mises à jour sont effectuées selon les règles spécifiées. En outre, il doit démontrer que le hachage de la racine reflète fidèlement les résultats de toutes les modifications.
Circuit de Keccak
Scroll a mis en œuvre sa propre version de Keccak256, conformément à la spécification Keccak du NIST et à la spécification de l'équipe Keccak.
Le circuit Keccak est utilisé pour prouver l'exactitude de l'opération Keccak256. La mise en œuvre de ce circuit est complexe, principalement parce que l'algorithme keccak256 lui-même n'est pas compatible avec le zk.
Circuit Tx
Le circuit Tx fournit des contraintes pour valider l'exactitude d'une transaction. Il vérifie principalement les aspects suivants de la transaction :
L'exactitude de CallDataLength et du coût cumulatif de CallDataGasCost : Déterminez la porte personnalisée et trouvez la dernière ligne d'octets de données d'appel dans la table tx ;
L'exactitude des données relatives à TxSign et TxHash : Recherche dans la table RLP et la table Keccak ;
Prouvez l'exactitude de "if tx_type is L1Msg, then msg_hash" : Vérifiez en consultant la table RLP ;
Exécutez correctement la signature tx à l'aide de l'ECDSA et récupérez correctement l'adresse de l'appelant à partir de la signature ECDSA : Vérifiez en consultant la table des signatures ;
Le comportement transitoire correct de tx id, cum_num_txs, et call_data_length ;
Quelques contraintes de base, telles que les valeurs booléennes de certaines variables indicatrices.
Circuit bytecode
Les circuits EVM doivent rechercher une table de bytecode contenant les informations de bytecode correctes. Cela permet de s'assurer que les octets stockés dans le contrat correspondent aux octets chargés à partir du tableau. L'objectif du circuit de bytecode est d'assurer l'exactitude de la table de bytecode. Il s'agit notamment de
Contraintes liées au comportement de la frontière avec les balises (tag) : Contraintes sur la première et la dernière ligne, conversion de balise == octet en en-tête et vice versa, conversion d'en-tête en en-tête ;
Contraintes sur la taille du code : Y compris le calcul de la longueur du bytecode par la contrainte de l'index du dernier octet du bytecode ;
Contraintes sur le hachage du code : Contrainte correcte du comportement RLC des octets dans le hachage du code et vérification du hachage du code en consultant la table de Keccak ;
Vérification de l'exactitude du comportement de PUSH : is_code = push_data_left == 0 (doit être une valeur booléenne) et vérification de la taille des données poussées pour PUSH1-PUSH32 en consultant la table des données poussées (push_table) ;
Assurer une propagation correcte dans chaque ligne d'un bytecode.
Les différentes chaînes ont leurs propres fonctions de modules commerciaux personnalisés, qui modifient généralement les contrats et opcodes précompilés dans l'EVM. Parmi eux, Scroll zkEVM est une solution de mise à l'échelle de seconde couche basée sur des preuves à connaissance nulle. Cette solution reconstruit les codes optiques pertinents à l'aide de circuits et génère des preuves basées sur les traces d'exécution. Cette mise en œuvre complexe accroît considérablement la difficulté de l'audit. Après évaluation par les experts en sécurité de Beosin, l'audit de sécurité de zkEVM se concentre principalement sur les aspects suivants :
GAS:Lors de la génération de preuves pour la trace d'exécution du circuit zkEVM, il vérifie également l'exactitude de la consommation de gaz pour les transactions. Si des variables libres non contraintes sont fréquemment utilisées dans le circuit d'implémentation des opcodes, il peut en résulter un échec de la génération de preuves ou d'autres erreurs inconnues.
Sécurité de la mémoire : Certains circuits zkEVM sont basés sur des engagements polynomiaux, tels que l'engagement KZG utilisé par Scroll. Cependant, les calculs polynomiaux ne s'alignent pas automatiquement, de sorte que si le circuit manque de contraintes, il peut en résulter une plage de valeurs incompatible avec la plage d'octets dans les programmes informatiques. Dans certains cas, lorsque les développeurs de contrats activent l'optimisation des gaz, la disposition compacte des données peut entraîner des problèmes de sécurité de la mémoire, comme le polynôme constant BYTE_C4096 dans Polygon zkEVM. Les polynômes permettent aux valeurs des paramètres de dépasser la plage maximale de 255 octets, ce qui peut potentiellement permettre à des séquenceurs malveillants de manipuler les paramètres à des fins lucratives dans certaines plateformes d'échange qui adoptent le modèle AMM. Essentiellement, ces types de vulnérabilités résultent d'incohérences entre la plage de validité numérique représentée par le circuit et la plage de valeurs variables du programme. La vulnérabilité CVE-2023-33252 découverte par les chercheurs en sécurité de Beosin dans la bibliothèque Snarkjs en est un exemple.
Sécurité des opcodes : Lors de l'implémentation des opcodes de zkEVM, il existe des problèmes de sécurité courants, en particulier en ce qui concerne la précision. Par exemple, lors de la comparaison de deux nombres dans le circuit sous-jacent, si la précision de l'opération de comparaison dans le programme est de 1 octet, les contraintes du circuit doivent spécifier la plage de valeurs. Dans le cas contraire, la précision des opérations dans le circuit dépassera la précision du programme, ce qui entraînera des résultats incorrects.
Soutien aux EIP sécurisés : Prise en charge des EIP axés sur la sécurité, tels que EIP-2 et EIP-155.
Problème de centralisation dans Sequencer : Actuellement, toutes les preuves générées par Scroll dépendent de la trace d'exécution générée par Sequencer. Si le Séquenceur se comporte de manière malveillante, zkEVM ne peut pas garantir la sécurité des biens de l'utilisateur.
Problème de compatibilité : zkEVM génère des preuves de circuit basées sur la trace d'exécution et les vérifie dans le contrat. Même des mises à jour mineures du séquenceur peuvent entraîner des différences significatives dans la trace d'exécution générée au niveau du langage sous-jacent.
Scroll adopte actuellement une version KZG à deux couches du système de preuve Halo2, en utilisant l'accélération matérielle du GPU pour accélérer la génération de preuves. Le goulot d'étranglement s'est déplacé vers la génération de témoins et la réplication des données. En outre, le niveau de centralisation et les coûts d'exploitation du matériel de Roller sont également des aspects que Scroll doit prendre en compte pour le développement futur des systèmes de preuve à plusieurs niveaux.
La trace d'exécution de l'EVM évoluant de manière dynamique, il existe diverses contraintes et échelles de circuit. Actuellement, pour tenir compte de l'évolution dynamique de la trace d'exécution, chaque étape de la trace d'exécution doit satisfaire la plus grande échelle de circuit, ce qui entraîne une perte de mémoire supplémentaire.
Il est actuellement prévu que Scroll's Roller profite des frais de transaction du réseau. Cependant, le nombre actuel d'utilisateurs et les frais de transaction du réseau Scroll ne permettent pas de couvrir les coûts de fonctionnement de Roller et du séquenceur. À l'avenir, la question de savoir comment le réseau Scroll fournit des incitations économiques pour attirer les utilisateurs et maintenir un fonctionnement stable du réseau doit être examinée.
Actuellement, Beosin soutient également l'audit du projet zk. Pour une recherche approfondie sur la sécurité de zk, vous pouvez lire les articles suivants : 1. Transaction Malleability Attack of Groth16 Proof; 2. Exploring Tornado Cash In-Depth to Reveal Malleability Attacks in ZKP Projects(en anglais).
Beosin, en tant que société de sécurité blockchain de premier plan à l'échelle mondiale, a établi des succursales dans plus de 10 pays et régions du monde. Nos services couvrent les audits de sécurité du code avant le lancement du projet, la surveillance des risques de sécurité, l'alerte précoce et la prévention pendant le fonctionnement du projet, la récupération d'actifs pour les monnaies virtuelles volées et les services de conformité sécurisés tels que KYT/AML. Nous fournissons une solution unique pour les produits et services de sécurité de la blockchain. Actuellement, nous avons fourni des services de technologie de sécurité à plus de 3 000 entreprises de blockchain dans le monde et vérifié plus de 3 000 contrats intelligents. N'hésitez pas à nous contacter.
Le 10 octobre, à 14 heures, le mainnet de la solution Ethereum Layer 2 Scroll a généré son premier bloc, marquant ainsi le lancement réussi du mainnet de Scroll. Depuis le 25 octobre, plus de 7600 ETH ont été intégrés au réseau Scroll par le biais de ponts inter-chaînes, et 24 plateformes d'échange décentralisées ont été mises en service sur le réseau principal de Scroll, avec un TVL total d'environ 10 millions de dollars.
Le 17 octobre, Scroll a officiellement annoncé le lancement de son réseau principal, tout en continuant à défendre son engagement en faveur de l'open source et de la décentralisation. Dans la phase suivante, Scroll se concentrera sur la construction d'un réseau décentralisé de preuve d'enjeu et d'une trieuse. Dans cet article, nous fournirons une analyse détaillée de l'architecture et de la technologie de Scroll afin d'aider tout le monde à comprendre l'état actuel du réseau et l'orientation future du développement de Scroll. Nous expliquerons également le circuit zkEVM de Scroll et les connaissances en matière d'audit afin de renforcer les mesures de sécurité pour les projets zk.
Scroll est une solution de mise à l'échelle de la couche 2 d'Ethereum basée sur la technologie de preuve à connaissance nulle, visant à améliorer le débit et la vitesse des transactions du réseau Ethereum. Par rapport au Rollup optimiste, Scroll atteint l'évolutivité grâce aux preuves à connaissance nulle et accélère la génération et la vérification des preuves à connaissance nulle grâce à l'accélération matérielle. Elle s'est engagée à réaliser une compatibilité EVM au niveau du bytecode. Cela signifie que les développeurs peuvent utiliser directement Solidity et les outils de développement liés à Ethereum pour construire des contrats intelligents et les déployer sur Scroll sans aucune modification.
Selon le site officiel de Scroll, l'équipe de Scroll compte actuellement 10 membres principaux, répartis entre l'Asie, l'Amérique et l'Europe. Les membres de l'équipe ont une grande expérience du développement de zkRollup et des opérations industrielles, la plupart d'entre eux étant diplômés d'universités prestigieuses et titulaires d'un doctorat.
Actuellement, l'écosystème Scroll est très riche, avec des projets d'infrastructure comprenant des portefeuilles, des outils de développement, des dispositifs de sécurité, etc. L'objectif est de fournir un soutien complet aux projets tout au long de leur cycle de vie, depuis la conception, le développement, l'exploitation jusqu'à l'audit de sécurité. Il existe actuellement plus de 180 projets d'écosystèmes sur le réseau principal Scroll.
Portefeuille
Scroll prend actuellement en charge presque tous les portefeuilles courants : Metamask, TrustWallet, MathWallet, TokenPocket, WalletConnect, Binance Chain Wallet, SafePal Wallet. En outre, l'écosystème de portefeuilles Scroll comprend également OKX Wallet, Versa Wallet, etc.
Pont inter-chaînes
L'infrastructure officielle de la chaîne croisée de Scroll comprend Celer Network, Stargate, Orbiter Finance, Hop Protocol, LI.FI, Connext, etc. En outre, il comprend également le protocole de liquidité cross-chain Synapse Protocol, Owlto Finance qui se concentre sur les ponts cross-chain de couche 2, le pont cross-chain Ethereum de couche 1 et de couche 2 Pheasant Network, Symbiosis, Catalyst, etc.
DeFi
Dans l'écosystème Scroll, il existe plusieurs projets DeFi bien établis, notamment le protocole de prêt Aave, l'agrégateur DEX multi-chaînes DODO, DEX SushiSwap, l'agrégateur DEX OpenOcean, le protocole DeFi multi-chaînes iZUMi Finance, DEX Syncswap, le protocole de rendement Pendle Finance, le protocole de prêt dForce, et l'agrégateur d'opérations à effet de levier MUX Protocol. Il existe également des projets innovants, comme le GMX, qui n'ont pas été largement adoptés.
Autres projets
En termes de NFT, de jeux et d'aspects sociaux, les autres projets de l'écosystème Scroll comprennent NFTScan, la plateforme de tâches Web3 QuestN, TaskOn, la plateforme de signature de protocole électronique EthSign, Galaxy Blitz, OmniKingdoms et d'autres jeux blockchain en ligne.
Qu'est-ce qui distingue la technologie Scroll des autres ?
L'architecture de Scroll se compose de trois éléments :
Le nœud Scroll : Il génère des blocs sur le réseau Scroll en fonction des transactions des utilisateurs, soumet ces transactions à la couche de base Ethereum et gère la transmission des messages entre Ethereum et Scroll.
Roller : Le Roller est chargé de convertir les contrats intelligents en circuits zkEVM, puis de générer des preuves pour prouver l'exactitude des transactions. Le réseau Scroll comporte plusieurs rouleaux qui traitent les transactions en parallèle et accélèrent la production de preuves par le biais du matériel. Scroll assure la compatibilité au niveau du bytecode avec EVM en prouvant directement l'exactitude du traitement du bytecode d'EVM.
Rollup and Bridge Contract : Ces contrats assurent la disponibilité des données pour les transactions Scroll et vérifient les preuves de validité générées par zkEVM. On peut dire que Scroll est connecté à la couche de base Ethereum par le biais des contrats Rollup et Bridge. Grâce à ces contrats, les utilisateurs peuvent échanger des messages arbitraires entre Ethereum et Scroll, et transférer des actifs ERC-20 dans les deux sens à l'aide de contrats passerelles.
source : https://scroll.mirror.xyz/nDAbJbSIJdQIWqp9kn8J0MVS4s6pYBwHmK7keidQs-k
Scroll est le contrat principal déployé sur la blockchain Ethereum:.
Contrat de proxy de routage de passerelle (garantissant le mappage correct des jetons dans les opérations entre chaînes):0xF8B1378579659D8F7EE5f3C929c2f3E332E41Fd6
Contrat de proxy de messages (transmission de messages entre L1 et L2):0x6774Bcbd5ceCeF1336b5300fb5186a12DDD8b367
Il convient de noter que ces contrats peuvent être modifiés par l'administrateur et le propriétaire du proxy. En outre, Scroll a intégré une fonction de liste blanche qui permet d'ajuster les frais de gaz pour des adresses spécifiques au sein de Scroll. Actuellement, le séquenceur Scroll fonctionne de manière centralisée, ce qui permet d'examiner les messages et les transactions sur le réseau Scroll. En outre, il est possible d'ignorer n'importe quel message dans la file d'attente et de confirmer directement un message spécifique.
Une fois que Scroll a généré un bloc, celui-ci passe par un coordinateur et plusieurs prouveurs (Rollers) pour générer des preuves agrégées. Ces preuves sont ensuite soumises au contrat Ethereum Rollup pour vérification. La procédure détaillée est la suivante :
1、Le séquenceur reçoit de nouvelles transactions. La machine virtuelle lit le bytecode associé à chaque transaction, génère une trace d'exécution et l'envoie au coordinateur. Simultanément, le séquenceur soumet les données de la transaction au contrat de reconduction.
2、Rollers convertissent les traces d'exécution reçues du coordinateur en circuits zkEVM. Chaque étape de la trace d'exécution correspond à un circuit zkEVM. Pour les fonctions qui ne sont pas compatibles avec zk (telles que hash et Keccak), Scroll construit des tables de recherche pour faire correspondre les entrées et les sorties de ces fonctions dans la trace d'exécution à la table de recherche. Des circuits supplémentaires sont utilisés pour vérifier l'exactitude de la table de conversion. Les rouleaux génèrent ensuite des preuves pour ces circuits zkEVM.
3、Après avoir produit les épreuves, les rouleurs les renvoient au coordinateur. Tous les quelques blocs, le coordinateur attribue au hasard des tâches d'agrégation à un Roller. Le Roller assigné regroupe ensuite les preuves de plusieurs blocs en une seule preuve.
4、La dernière étape consiste pour le coordinateur à soumettre la preuve agrégée au contrat de reconduction. Le contrat de rollup utilise cette preuve pour vérifier l'exactitude des données d'état et de transaction soumises précédemment, confirmant ainsi l'exactitude du bloc.
zkEVM se compose de plusieurs circuits, chacun chargé de vérifier un aspect spécifique de l'EVM (Ethereum Virtual Machine). Ces circuits sont finalement combinés ou agrégés pour générer une preuve d'exécution de la transaction. Le diagramme ci-dessous illustre la relation entre ces circuits et les tableaux.
Il existe des sous-circuits plus petits, tels que le circuit ECDSA et les sous-circuits liés aux opcodes, qui n'interagissent pas avec d'autres tables et circuits d'une manière qui affecte la combinaison du circuit. Ces sous-circuits sont omis dans le diagramme par souci de clarté.
Circuit EVM
La machine virtuelle Ethereum (EVM) est une machine d'état qui établit les règles pour les transitions d'état valides au sein du protocole Ethereum. Il exécute des instructions (opcodes) pour réaliser ces transitions et génère une trace d'exécution. L'objectif du circuit EVM est de créer un système de contraintes qui représente la trace d'exécution et peut être vérifié à l'aide d'un système de preuve à connaissance nulle.
La conception de haut niveau du circuit de l'EVM est quelque peu similaire à la conception de l'EVM lui-même, comme go-ethereum. Dans go-ethereum, l'interpréteur parcourt tous les opcodes d'instruction sur la trace d'exécution. Pour chaque instruction, l'interprète vérifie les informations contextuelles pertinentes telles que le gaz, la pile et la mémoire, puis envoie l'opcode à la JumpTable, qui fournit des instructions détaillées pour l'exécution de l'opcode.
De même, dans les circuits EVM, Scroll construit des étapes d'exécution sur la base de la trace d'exécution et fournit des preuves pour les opcodes et les contextes d'exécution. Pour chaque étape d'exécution, un ensemble de contraintes est appliqué pour vérifier les informations contextuelles. Pour chaque opcode, un ensemble de contraintes est appliqué pour vérifier son comportement. Dans la trace d'exécution, le même opcode doit avoir les mêmes contraintes. Scroll utilise des sélecteurs pour "ouvrir" toutes les étapes avec le même opcode dans la trace d'exécution et utilise le système de preuve en arrière-plan pour prouver leur comportement.
Circuit de l'État
Pendant l'exécution, toutes les opérations de lecture et d'écriture de l'EVM sont enregistrées dans la table rw et ordonnées par la variable rw_counter. L'objectif du circuit d'état est de démontrer la précision de la génération de la table rw_.
Circuit MPT
L'arbre Merkle Patricia (MPT) est une structure de données clé utilisée dans la couche de stockage d'Ethereum. Dans les circuits zkevm de Scroll, le MPT est modifié en zkTrie, qui est essentiellement un Merkle Patricia Trie binaire clairsemé. Dans zkevm-Circuits, Scroll utilise la table MPT pour suivre pas à pas les transitions d'état des opérations MPT. Le tableau MPT se présente comme suit :
L'objectif du circuit MPT est de vérifier l'exactitude du tableau MPT mentionné ci-dessus. Il garantit que chaque mise à jour enregistrée dans la table MPT entraîne une modification correcte. Cela signifie que pour chaque mise à jour, le circuit MPT garantit qu'il n'y a qu'une seule façon possible d'effectuer les changements. Cela permet d'éviter les modifications accidentelles ou non autorisées et de garantir l'intégrité et l'exactitude du TPM. En particulier, lorsque le TPM subit des modifications dues à des mises à jour des comptes ou du stockage, le circuit du TPM doit prouver que ces mises à jour sont effectuées selon les règles spécifiées. En outre, il doit démontrer que le hachage de la racine reflète fidèlement les résultats de toutes les modifications.
Circuit de Keccak
Scroll a mis en œuvre sa propre version de Keccak256, conformément à la spécification Keccak du NIST et à la spécification de l'équipe Keccak.
Le circuit Keccak est utilisé pour prouver l'exactitude de l'opération Keccak256. La mise en œuvre de ce circuit est complexe, principalement parce que l'algorithme keccak256 lui-même n'est pas compatible avec le zk.
Circuit Tx
Le circuit Tx fournit des contraintes pour valider l'exactitude d'une transaction. Il vérifie principalement les aspects suivants de la transaction :
L'exactitude de CallDataLength et du coût cumulatif de CallDataGasCost : Déterminez la porte personnalisée et trouvez la dernière ligne d'octets de données d'appel dans la table tx ;
L'exactitude des données relatives à TxSign et TxHash : Recherche dans la table RLP et la table Keccak ;
Prouvez l'exactitude de "if tx_type is L1Msg, then msg_hash" : Vérifiez en consultant la table RLP ;
Exécutez correctement la signature tx à l'aide de l'ECDSA et récupérez correctement l'adresse de l'appelant à partir de la signature ECDSA : Vérifiez en consultant la table des signatures ;
Le comportement transitoire correct de tx id, cum_num_txs, et call_data_length ;
Quelques contraintes de base, telles que les valeurs booléennes de certaines variables indicatrices.
Circuit bytecode
Les circuits EVM doivent rechercher une table de bytecode contenant les informations de bytecode correctes. Cela permet de s'assurer que les octets stockés dans le contrat correspondent aux octets chargés à partir du tableau. L'objectif du circuit de bytecode est d'assurer l'exactitude de la table de bytecode. Il s'agit notamment de
Contraintes liées au comportement de la frontière avec les balises (tag) : Contraintes sur la première et la dernière ligne, conversion de balise == octet en en-tête et vice versa, conversion d'en-tête en en-tête ;
Contraintes sur la taille du code : Y compris le calcul de la longueur du bytecode par la contrainte de l'index du dernier octet du bytecode ;
Contraintes sur le hachage du code : Contrainte correcte du comportement RLC des octets dans le hachage du code et vérification du hachage du code en consultant la table de Keccak ;
Vérification de l'exactitude du comportement de PUSH : is_code = push_data_left == 0 (doit être une valeur booléenne) et vérification de la taille des données poussées pour PUSH1-PUSH32 en consultant la table des données poussées (push_table) ;
Assurer une propagation correcte dans chaque ligne d'un bytecode.
Les différentes chaînes ont leurs propres fonctions de modules commerciaux personnalisés, qui modifient généralement les contrats et opcodes précompilés dans l'EVM. Parmi eux, Scroll zkEVM est une solution de mise à l'échelle de seconde couche basée sur des preuves à connaissance nulle. Cette solution reconstruit les codes optiques pertinents à l'aide de circuits et génère des preuves basées sur les traces d'exécution. Cette mise en œuvre complexe accroît considérablement la difficulté de l'audit. Après évaluation par les experts en sécurité de Beosin, l'audit de sécurité de zkEVM se concentre principalement sur les aspects suivants :
GAS:Lors de la génération de preuves pour la trace d'exécution du circuit zkEVM, il vérifie également l'exactitude de la consommation de gaz pour les transactions. Si des variables libres non contraintes sont fréquemment utilisées dans le circuit d'implémentation des opcodes, il peut en résulter un échec de la génération de preuves ou d'autres erreurs inconnues.
Sécurité de la mémoire : Certains circuits zkEVM sont basés sur des engagements polynomiaux, tels que l'engagement KZG utilisé par Scroll. Cependant, les calculs polynomiaux ne s'alignent pas automatiquement, de sorte que si le circuit manque de contraintes, il peut en résulter une plage de valeurs incompatible avec la plage d'octets dans les programmes informatiques. Dans certains cas, lorsque les développeurs de contrats activent l'optimisation des gaz, la disposition compacte des données peut entraîner des problèmes de sécurité de la mémoire, comme le polynôme constant BYTE_C4096 dans Polygon zkEVM. Les polynômes permettent aux valeurs des paramètres de dépasser la plage maximale de 255 octets, ce qui peut potentiellement permettre à des séquenceurs malveillants de manipuler les paramètres à des fins lucratives dans certaines plateformes d'échange qui adoptent le modèle AMM. Essentiellement, ces types de vulnérabilités résultent d'incohérences entre la plage de validité numérique représentée par le circuit et la plage de valeurs variables du programme. La vulnérabilité CVE-2023-33252 découverte par les chercheurs en sécurité de Beosin dans la bibliothèque Snarkjs en est un exemple.
Sécurité des opcodes : Lors de l'implémentation des opcodes de zkEVM, il existe des problèmes de sécurité courants, en particulier en ce qui concerne la précision. Par exemple, lors de la comparaison de deux nombres dans le circuit sous-jacent, si la précision de l'opération de comparaison dans le programme est de 1 octet, les contraintes du circuit doivent spécifier la plage de valeurs. Dans le cas contraire, la précision des opérations dans le circuit dépassera la précision du programme, ce qui entraînera des résultats incorrects.
Soutien aux EIP sécurisés : Prise en charge des EIP axés sur la sécurité, tels que EIP-2 et EIP-155.
Problème de centralisation dans Sequencer : Actuellement, toutes les preuves générées par Scroll dépendent de la trace d'exécution générée par Sequencer. Si le Séquenceur se comporte de manière malveillante, zkEVM ne peut pas garantir la sécurité des biens de l'utilisateur.
Problème de compatibilité : zkEVM génère des preuves de circuit basées sur la trace d'exécution et les vérifie dans le contrat. Même des mises à jour mineures du séquenceur peuvent entraîner des différences significatives dans la trace d'exécution générée au niveau du langage sous-jacent.
Scroll adopte actuellement une version KZG à deux couches du système de preuve Halo2, en utilisant l'accélération matérielle du GPU pour accélérer la génération de preuves. Le goulot d'étranglement s'est déplacé vers la génération de témoins et la réplication des données. En outre, le niveau de centralisation et les coûts d'exploitation du matériel de Roller sont également des aspects que Scroll doit prendre en compte pour le développement futur des systèmes de preuve à plusieurs niveaux.
La trace d'exécution de l'EVM évoluant de manière dynamique, il existe diverses contraintes et échelles de circuit. Actuellement, pour tenir compte de l'évolution dynamique de la trace d'exécution, chaque étape de la trace d'exécution doit satisfaire la plus grande échelle de circuit, ce qui entraîne une perte de mémoire supplémentaire.
Il est actuellement prévu que Scroll's Roller profite des frais de transaction du réseau. Cependant, le nombre actuel d'utilisateurs et les frais de transaction du réseau Scroll ne permettent pas de couvrir les coûts de fonctionnement de Roller et du séquenceur. À l'avenir, la question de savoir comment le réseau Scroll fournit des incitations économiques pour attirer les utilisateurs et maintenir un fonctionnement stable du réseau doit être examinée.
Actuellement, Beosin soutient également l'audit du projet zk. Pour une recherche approfondie sur la sécurité de zk, vous pouvez lire les articles suivants : 1. Transaction Malleability Attack of Groth16 Proof; 2. Exploring Tornado Cash In-Depth to Reveal Malleability Attacks in ZKP Projects(en anglais).
Beosin, en tant que société de sécurité blockchain de premier plan à l'échelle mondiale, a établi des succursales dans plus de 10 pays et régions du monde. Nos services couvrent les audits de sécurité du code avant le lancement du projet, la surveillance des risques de sécurité, l'alerte précoce et la prévention pendant le fonctionnement du projet, la récupération d'actifs pour les monnaies virtuelles volées et les services de conformité sécurisés tels que KYT/AML. Nous fournissons une solution unique pour les produits et services de sécurité de la blockchain. Actuellement, nous avons fourni des services de technologie de sécurité à plus de 3 000 entreprises de blockchain dans le monde et vérifié plus de 3 000 contrats intelligents. N'hésitez pas à nous contacter.