TL;DR

1) Étant donné que les couches 2 et 3 reposent théoriquement sur le mainnet pour le règlement, une hypothèse courante est que la couche 3 compresse d'abord les données puis les soumet à la couche 2 pour une compression secondaire, superposant essentiellement un Rollup sur un autre Rollup. Cette approche a été critiquée et remise en question car si l'on imagine que les couches 4 et 5 utilisent une architecture similaire, cela aboutirait à une impasse, car les données ne peuvent pas être compressées indéfiniment.

2) En réalité, l'interaction entre la couche 3 et la couche 2 pourrait ne pas nécessairement impliquer la compression puis la recompression. Dans les stratégies de couche 3 planifiées par plusieurs piles de couche 2 telles que Arbitrum et zkSync, la couche 3 est définie comme une chaîne d'application spécifique. Elle aura un degré élevé d'autonomie dans des aspects tels que les mécanismes de consensus, les choix de frais de gaz et les modèles économiques. Cependant, l'autonomie ne signifie pas une indépendance complète, car l'architecture sous-jacente est probablement contrainte par l'infrastructure fondamentale construite pour la couche 2, telle que le partage de composants clés comme les Séquenceurs et les Prouvers avec la chaîne de couche 2.

Cela signifie que les transactions sur la couche 3 sont directement traitées par le séquenceur de la couche 2 et soumises au mainnet pour confirmation de l'état final. La couche 2 assume davantage un rôle dans la mise en œuvre de fonctions d'interopérabilité entre plusieurs chaînes de la couche 3, où la soi-disant “couche de règlement” ne sert qu'à l'emballage des données et non au règlement final au sens strict. Les transactions sur la couche 3 doivent également être mises en file d'attente sur la couche 2 pour l'emballage, ce qui rend sensé de traiter la chaîne d'application de la couche 3 comme un type spécial de canal de séquenceur.

3) En supposant que la couche 3 fonctionne uniquement comme un emboîtement de chaînes au sein de chaînes limite naturellement la scalabilité, mais cette pratique n'est qu'une hypothèse théorique. Si la couche 2 et la couche 3 partagent des composants critiques tels que les Séquenceurs et les Prouveurs, il existe de nombreuses façons de permettre la scalabilité horizontale des chaînes de couche 3, en particulier lorsque l'interopérabilité entre chaînes est améliorée.

1. Comme mentionné par le fondateur de zkSync, @gluk64, utiliser la technologie ZK comme base pour l'interopérabilité entre plusieurs blockchains est réalisable car la technologie ZK permet à deux contreparties de vérifier l'authenticité des informations sans révéler les détails. Lorsque les actifs sont transférés de la couche 3 à la couche 2, cela peut être réalisé de manière transparente via un pont ZK, permettant des transferts d'actifs atomiques entre les chaînes sans avoir besoin d'un consensus inter-chaînes supplémentaire ou d'autres processus.

La technologie de pontage améliorée par ZK permet un support fondamental pour l'expansion multi-chaîne de la couche 3 car, peu importe le nombre de couches 3 déployées, elles se règlent directement avec la couche 2 via des preuves ZK, ce qui n'affecte pas la relation entre la couche 2 et le réseau principal;

1. Tel que décrit par le fondateur d'Eigenlayer, @sreeramkannan, avoir les nœuds actifs AVS de la couche Eigenlayer coordonnent le consensus à travers différents blockchains implique essentiellement le même ensemble de nœuds participant à la construction du consensus à travers plusieurs chaînes. En mettant en œuvre un mécanisme de récompense et de pénalité (Slash) pour AVS, il est théoriquement possible de réduire la probabilité que les nœuds agissent de manière malveillante. Si les nœuds approuvent le transfert d'actifs de la couche 3 à la couche 2 et qu'il y a des inconduites, ils seront sujets à des sanctions.

Ce type de mécanisme économique de récompense et de punition peut également être appliqué aux problèmes de confiance dans un environnement multi-chaînes. Bien qu'il ne puisse pas atteindre le même niveau de confiance que la technologie ZK, il peut créer grossièrement un environnement de confiance basé sur un modèle économique.

4) @VitalikButerin, en réponse aux discussions qui portent souvent des biais inhérents, a réitéré son point de vue selon lequel la Couche 3 ne devrait pas être vue de manière simpliste comme simplement une pile ou une extension de la Couche 2, car cela ne conduit pas nécessairement à une évolutivité efficace. Comme la Couche 3 dépend de la Couche 2 en tant qu'infrastructure et que la Couche 2 elle-même ne peut pas s'étendre indéfiniment, il en va de même pour la Couche 3. Cependant, dans certains scénarios spécifiques, tels que la confidentialité, des applications spécifiques orientées vers la confidentialité au niveau de la Couche 3 peuvent répondre à certaines des préférences transactionnelles en matière de confidentialité.

En conclusion, la couche 3 représente une fonctionnalité hautement personnalisable avec un potentiel d'expansion sur mesure. De mon point de vue, l'expansion de la couche 3 devrait être basée sur les besoins spécifiques de l'application et développée de manière personnalisée, contrairement à un paradigme de développement universel, qui n'est pas réalisable dans une direction multi-chaînes pour les applications de la couche 3.

Avertissement：

1. Cet article est repris de [GateTwitter], Tous les droits d'auteur appartiennent à l'auteur original [@tmel0211]. Si des objections sont soulevées à cette réimpression, veuillez contacter le Formation Gateé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 matière d'investissement.
3. Les traductions de l'article dans d'autres langues sont réalisées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits sont interdits.