La couche 2 n’est plus seulement la couche 2 d’Ethereum.
Écrit par : Haotian
Un nouveau récit de “EVM parallèle” est apparu sur le marché, ce qui est très intéressant dans la couche 2. Il peut réaliser un nouveau paradigme de Rollup “raffiné”. S’il est exagéré, il peut obtenir l’effet magique de Solana devenant la nouvelle couche 2 de Éthereum.
À mon avis, l’EVM parallèle n’est qu’une manifestation hautement « modulaire » du Rollup. Après l’invasion de DA par un tiers, la couche d’exécution de la VM est à nouveau tombée et la couche 2 sera redéfinie à l’avenir. Pourquoi? Ensuite, analysons-le d’un point de vue scientifique populaire :
Pour comprendre ce sujet, vous devez d’abord clarifier le modèle d’exécution monothread de « EVM ».
Ce modèle stipule que les transactions doivent être traitées et confirmées les unes après les autres dans l’ordre, ce qui affecte directement la vitesse de traitement des transactions, le temps de génération des blocs et le débit des transactions, etc., et est la principale raison du gaz élevé et de la congestion du réseau principal d’Ethereum. réseau. De plus, la raison pour laquelle il est conçu pour être monothread présente certaines limites historiques.
Étant donné que les transactions sur Ethereum sont vérifiées et exécutées par des nœuds indépendants distribués, il est nécessaire de garantir que les données de toutes les adresses, telles que les soldes, les codes de contrats intelligents, etc., restent cohérentes entre les différents nœuds. Il est nécessaire de s’assurer qu’il n’y a pas d’actifs identiques, ce qui risque de doubler les dépenses.
Cela provoque la mise en file d’attente des transactions dans l’ordre. Si des transactions parallèles se produisent, cela peut entraîner des erreurs de synchronisation des données entre les nœuds. La clé est que de graves transactions à double dépense peuvent se produire.
Explication populaire : la banque n’a qu’un seul guichet de service et les clients doivent faire la queue pour retirer de l’argent. Qu’il s’agisse de dépôts, de retraits, de prêts et d’autres services, un client ne peut démarrer le suivant qu’après avoir terminé l’activité. L’avantage est que chaque opération du système de compte bancaire sera enregistrée avec précision, mais que le temps d’attente pour les clients sera plus long ;
Si une banque ouvre plusieurs fenêtres de service et que les clients peuvent choisir une fenêtre pour gérer différentes affaires, il y aura deux fenêtres essayant de déduire de l’argent d’un compte en même temps. Si le rapprochement du système de compte entre les fenêtres n’est pas opportun, cela entraînera doubler les dépenses, ce qui évidemment améliorera l’efficacité, mais une logique comptable complexe mettra la pression sur le système comptable.
Dans le scénario de chaîne indépendante de couche 1, si la couche inférieure de la chaîne prend en charge le traitement parallèle, le problème sera facilement résolu. Étant donné que les états de calcul et de stockage de Solana sont séparés, une fois que sa VM a reçu plusieurs transactions des utilisateurs, le nœud triera ces transactions et puis appelez la chaîne indépendante. Les données d’état du système de stockage détectent s’il y a un conflit d’état dans ces transactions. S’il n’y a pas de conflit, la transaction sera regroupée dans un bloc. S’il y a un conflit, la transaction en conflit sera exclue de ce bloc.
En comparaison, le statut de stockage d’Ethereum est calculé en temps réel. Chaque transaction doit attendre la fin de la transaction précédente avant de mettre à jour le statut. Il est donc impossible de filtrer les transactions avant d’attendre le packaging, ce qui limite son traitement parallèle. .
Dans le scénario de chaîne de cumul couche 2, pour réaliser un traitement parallèle, la distance est similaire. Vous pouvez considérer le calcul des transactions et la détection de l’état de stockage de Solana en attendant l’horodatage POH comme le processus de traitement de la chaîne Rollup par les transactions dans le Sequener, puis de les regrouper sur le réseau principal.
Désormais, avant de regrouper les transactions de couche 2, le séquenneur organisera d’abord les noms occasionnels des transactions par ordre chronologique, puis les regroupera dans l’ordre sur le réseau principal. Comment pouvons-nous réaliser le multi-threading ?
-
Sur la base du modèle abstrait du compte AA, il est possible d’initier plusieurs transactions en même temps à partir de l’état du compte. Par exemple, si deux transferts sont exécutés en même temps, le contrat intelligent AA leur donnera un nonce, ce qui doit être exécuté dans l’ordre. S’il s’agit d’un transfert, si une transaction est approuvée, elle peut être traitée de manière plus flexible en parallèle sans être limitée par le nonce. Dans le modèle de compte AA, chaque compte peut personnaliser la logique de traitement des transactions, puis coopérer avec des utilisateurs occasionnels pour obtenir une concurrence élevée.
-
Un traitement “raffiné” des transactions dans Sequencer peut être effectué. Par exemple, lorsque les transactions de couche 2 sont soumises à Sequencer, Sequencer peut détecter rapidement ces logiques de transaction et effectuer un tri et un filtrage affinés. Par exemple, si le même Si un compte initie deux Transferts, ce dernier doit être exclu et attendre le prochain Batch. Si le même compte initie deux opérations de nature différente, elles peuvent être Batchées dans un bloc en même temps.
Cela semble simple ? Mais ce n’est en aucun cas le cas : en prenant comme exemple le scénario DeFi, Sequencer fait face à deux défis majeurs afin de parvenir à une gestion affinée des transactions :
-
Il est nécessaire d’analyser les données de transaction en temps réel et de comprendre les méthodes d’appel de contrats intelligents et les paramètres des données entrantes. Prenons l’exemple du Staking commun dans DeFi. Une opération de Staking implique le transfert de jetons, la mise à jour du statut, la période de gage et calcul des récompenses potentielles, etc. Si un grand nombre d’utilisateurs envoient certaines transactions de gage en même temps, s’il existe également des transactions impliquant un gage puis un transfert, associées à des facteurs de prix Oralce complexes, etc., si Sequener ne peut pas les analyser et les traiter correctement, une erreur dans un Cette étape peut entraîner des accidents graves.
-
Le Séquenceur doit assurer la décentralisation. Actuellement, le Séquenceur de couche 2 n’a que des transactions Batch, et ses droits sont trop importants. Si le problème de décentralisation du Séquenceur ne peut pas être résolu, alors un Rollup “affiné” sera donné au Séquenceur. Si Sequencer effectue de fausses transactions, s’engage de manière flagrante dans des pièges MEV, ou même manipule de manière malveillante la liquidation d’Oracle, etc., il se reproduira.
Récemment, Metis est devenu populaire. En apparence, il ne réalise que la décentralisation de Sequencer. À un niveau plus profond, il construit une prémisse de consensus de base pour que le futur Sequencer puisse effectuer un rollup raffiné.
Bien sûr, s’appuyer sur Sequencer pour obtenir une agrégation et un traitement hautement raffinés des transactions Rollup n’est encore qu’une idée. Heureusement, l’abstraction des comptes AA et l’idée ouverte de combinaison modulaire de l’ensemble de la blockchain fournissent la condition préalable à la mise en œuvre de cette idée. .
c’est tout.
De plus, comme mentionné ci-dessus, la couche 2 dans son ensemble devient de plus en plus modulaire. La technologie ZK est intégrée dans le cadre OP Stack pour permettre l’expansion de la confidentialité ; le DA Ethereum d’origine est converti en un DA tiers tel que Celestia pour réduire les coûts ; ETH est progressivement utilisé comme Gas La tradition des frais a également été modifiée, donnant aux jetons de couche 2 une plus grande praticité : même la couche 2 peut regrouper des transactions par lots et les soumettre à différents environnements d’exécution de VM, et les transactions sont divisées en Solana et Ethereum pour le traitement, etc.
D’ici là, un nouveau paradigme émergera : la couche 2 actuelle n’est plus seulement la couche 2 d’Ethereum. Solana peut aussi être la couche 2 d’Ethereum, et même la définition de la couche 2 sera modifiée comme par magie.
Idée audacieuse, la couche 2 est désormais devenue une « couche 1 » d’entrée de gamme qui intègre des capacités de traitement de transactions à haute concurrence, et l’ancienne couche 1 comme Ethereum et Solana est devenue une nouvelle « couche 2 » qui gère le règlement des actifs et assurance de sécurité.
La couche 2 n’a jamais été un concept rigide. Les plates-formes de couche 2 ont toujours eu pour mission de résoudre le traitement simultané de transactions à grande échelle et d’attirer des groupes de marché d’utilisateurs supplémentaires.
Si la mission est accomplie, dans le cadre de l’idée modulaire, non seulement la légitimité de la couche 1 d’Ethereum sera brisée, mais la disponibilité des données DA, la couche d’exécution de la VM et même l’interaction de communication d’interopérabilité de l’ensemble de la chaîne deviendront l’infrastructure à réaliser par la couche 2. Adoption de masse.
D’ici là, la couche 2 ne sera plus seulement un complément à la couche 1, mais deviendra une puissante plate-forme complète de traitement d’agrégation et de distribution de transactions. Laissez-moi vous demander : à qui appartient la couche 2 ?
