L'évolutivité de la blockchain et les solutions proposées sont au premier plan des discussions sur les réseaux sociaux depuis une demi-décennie. Par exemple, la société de logiciels israélienne Starkware et le co-fondateur d'Ethereum, Vitalik Buterin, ont récemment évoqué l'idée de la "couche 3" comme l'une de ces solutions. Starkware indique que plusieurs couches 3 chevaucheront la couche 2 et que des solutions de « superposition fractale » pourront être construites au-dessus de la couche 3.
Le projet Opside ont récemment publié leurs plans pour une architecture à trois couches. Cela permettra aux développeurs de créer des applications blockchain qui ont accès à des vitesses plus rapides et à des transactions moins chères. Ceci est rendu possible par la chaîne Opside, qui est surnommée une solution de couche 2 car elle repose sur plusieurs plates-formes de couche 1 (comme Ethereum, Binance Chain, Bitcoin, etc.) et les utilise comme couche de règlement. La fonctionnalité "Layer 3" va encore plus loin, permettant aux développeurs de créer un ensemble de "rollups en tant que service". Cette architecture donne à la couche 2 une gamme plus complète d'actifs à partir de ponts et la possibilité de se développer indéfiniment à partir de cumuls.
Afin de gérer les appels contractuels entre plusieurs chaînes, En face développé un protocole pour gérer tous les appels de contrat. Le vote DAO est également en cours de développement, ce qui permet à la communauté Opside de voter sur les chaînes publiques à utiliser pour le règlement de la couche 1.
Les solutions de couche 2 dépendent de la décentralisation de leur homologue de couche 1 pour fournir des temps de transaction plus rapides et des frais de gaz inférieurs. Il semble acceptable pour la plupart des communautés blockchain d'avoir une couche centralisée au-dessus de leur plate-forme tant que chaque transaction est réglée au niveau de la couche 1. L'efficacité est obtenue en « regroupant » un ensemble de transactions et en les réglant plus tard. La couche 3 amplifie ce modèle, permettant une rentabilité encore plus grande tout en maintenant la vitesse du réseau de couche 2.
La couche 3 a le potentiel d'offrir des coûts si bas que les projets construits même sur des réseaux de couche 2 n'auront pas à déployer leurs propres couches 1 pour réduire les frais de règlement. Ces applications, telles qu'Axie et dYdX Decentralized Exchange devaient le faire, simplement parce que leur modèle dépendait des temps de transaction les plus rapides et des frais les plus bas. S'il est déployé sur un cumul de couche 3, il pourrait éviter d'avoir besoin d'une autre blockchain.
Layer1 : ponts multi-chaînes
Opside prend en charge un Liquidity-Bridge décentralisé plus rapide et moins cher pour réaliser l'interopérabilité des actifs dans plus de chaînes. Liquidity-Bridge se compose de nœuds sans autorisation qui parviennent à un consensus sur les messages inter-chaînes via MPC. Le pool de liquidités apporte une vitesse plus rapide et prend en charge davantage de chaînes publiques et leurs actifs en chaîne.
De plus, Opside établira des connexions avec diverses chaînes publiques de la couche d'actifs via le ZK-Bridge sans confiance. Comparé à d'autres schémas de pont, le schéma ZK-Rollup implique davantage de systèmes résistants au ZK. Dans l'opération inter-chaînes, il est nécessaire de générer des preuves ZK pour garantir l'exactitude du processus d'exécution en plus d'une « exécution » générale. Les opérations de dépôt et de retrait de ZK-Bridge sont "solidifiées" en tant que circuit, et la logique du circuit est complètement exposée.
Layer2 : une chaîne compatible Rollup
La chaîne Opside, ou couche 2, est une chaîne compatible EVM et compatible avec le déploiement. La chaîne Opside effectuera des optimisations profondes pour les rollups.
Le cumul natif est quelque peu similaire à l'architecture de Polkadot. Une fois qu'un cumul enregistre un emplacement, le cumul devient un cumul natif. En revanche, l'architecture Polkadot présente l'inconvénient que le consensus de la parachain dépend de l'ensemble de validateurs attribué. Il y a une corrélation entre la sécurité et le nombre de validateurs. Si quelques validateurs se sont déconnectés, les parachains dont les groupes de validateurs sont trop petits pour valider un bloc ignoreront ces blocs, ou même s'arrêteront jusqu'à ce que la situation soit résolue. Opside n'a pas ce problème car la couche 2 collecte les données de tous les cumuls natifs de la couche 3 et vérifie toutes les épreuves zk. Opside Chain est plus sécurisé et décentralisé avec tous les rollups comme un tout plus serré, partageant la même couche de consensus.
Il existe 64 contrats pré-déployés en tant que « slots de rollup », qui seront appelés directement par des transactions batch & proof à partir de rollups. Ces emplacements appelleront un contrat précompilé pour la vérification de la preuve et mettront à jour les racines d'état locales en cas de succès. Le contrat précompilé peut accélérer la vérification des preuves à connaissance nulle avec des optimisations dans les codes binaires.
Les couches 2 et 3 de l'architecture Opside partagent un mécanisme de consensus avec un hybride de PoS et PoW.
- PoS : Sur la couche 2, n'importe qui peut devenir un validateur en jalonnant, puis avoir la possibilité de produire des blocs de la chaîne Opside. Le PoS est prouvable et les validateurs soumettent périodiquement une preuve PoS à la couche 1. Les validateurs peuvent obtenir la récompense de bloc et la récompense de mise pour cette partie du PoS.
- PoW: Les validateurs de la couche 2 produiront non seulement des blocs Opside Chain, mais généreront également une preuve zk pour chaque cumul natif de la couche 3 selon les règles de PoVP. Les validateurs recevront la récompense IDE pour avoir réussi à générer une preuve zk, ce qui est quelque peu similaire au PoW. Les validateurs peuvent obtenir un bonus supplémentaire pour cette partie de la récompense en jalonnant plus de jetons dans le contrat système.
Plus important encore, dans Opside, après avoir terminé l'enregistrement des slots, les cumuls natifs partagent un arbre d'état mondial entre eux et la même file d'attente de messages globale. Par conséquent, l'interopérabilité cross-rollup native est possible dans Opside. Imaginez que vous vouliez prêter USDC à un contrat de prêt dans le Rollup A, puis aller à DEX dans le Rollup B pour négocier pour acheter du BTC. Sur Opside, vous n'avez plus besoin de retirer des actifs du Rollup A vers L1, puis de les recharger de L1 vers Rollup B. Au lieu de cela, vous pouvez appeler la méthode contractuelle du Rollup B directement dans le Rollup A. Cela rendra l'ensemble du processus beaucoup plus rapide, moins cher et plus sûr.
Layer3 : ZK-Rollups décentralisés
Dans la troisième couche, Opside aide les développeurs à déployer leurs propres rollups, tandis qu'Opside fournit également un solution de rollup décentralisée basé sur RaaS mentionné ci-dessus. Les développeurs peuvent librement choisir lequel adopter. Cette solution est sans confiance et sans autorisation. N'importe qui peut soumettre des lots et des épreuves L2 à L1.
Pour résumer, l'architecture "couche de base <- opside <- rollup" d'Opside présente l'avantage d'une variété d'actifs et d'une évolutivité infinie. Cela pourrait être un autre choix pour résoudre les problèmes d'évolutivité des applications web3. Comparé aux couches 2 coûteuses basées sur le rollup, il est plus adapté aux applications à haut débit comme les jeux.
Avertissement: cet article est fourni à titre informatif uniquement. Il n'est ni proposé ni destiné à être utilisé comme conseil juridique, fiscal, d'investissement, financier ou autre.
Source : https://cryptodaily.co.uk/2023/01/opside-network-introduces-3-layer-architecture-for-blockchain-applications