 a implémenté avec succès NCRC sur le testnet. Tout le monde peut désormais en faire l'expérience sur le site officiel à l'adresse  Opside https://pre-alpha-assetshub.opside.network/.  Pourquoi avons-nous besoin d’une communication croisée sans confiance ?  Les rollups ont suscité une attention et une adoption considérables en raison de leur capacité à améliorer l'évolutivité de la blockchain, à réduire les coûts de transaction et à améliorer l'efficacité globale. Opside fournit des services ZK-RaaS pour les applications Web3, permettant aux développeurs de créer leurs propres Rollups via la base de lancement Opside Rollup. À l’ère des Rollups multiples, nous prévoyons une coexistence croissante de différents Rollups, ce qui rend cruciale une interopérabilité transparente entre les différentes solutions de couche 2.  Actuellement, les interactions entre les Rollups restent relativement isolées, manquant de communication inter-chaînes en temps réel et d'interopérabilité des actifs. Cet isolement a conduit à un paysage fragmenté, où les actifs sont confinés dans des Rollups spécifiques, limitant leur libre circulation et leur utilisation sur différents réseaux.  L'absence de communication efficace entre les Rollups limite non seulement le potentiel des Rollups individuels, mais a également un impact sur l'expérience utilisateur globale. Les utilisateurs qui tentent de transférer des actifs ou d'exécuter des transactions inter-chaînes entre Rollups sont confrontés à des processus fastidieux et chronophages. Cette expérience sous-optimale affaiblit l’attrait des Rollups et entrave dans une certaine mesure l’adoption généralisée des solutions de mise à l’échelle de couche 2.  Les solutions de pontage cross-rollup existantes impliquent souvent le déploiement de nouveaux ensembles de contrats inter-chaînes sur les chaînes Rollup et l'utilisation d'incitations à la liquidité multi-chaînes pour obtenir une fonctionnalité inter-chaînes d'actifs. Cependant, ces solutions ne sont pas universellement applicables aux interactions inter-chaînes basées sur des messages et comportent des risques de centralisation et de confiance.  Pour libérer pleinement le potentiel de l’ère multi-Rollup, il existe un besoin urgent d’un protocole de communication cross-Rollup universel et sans confiance.  La solution Opside : Native Cross Rollup Communication  En fait, chaque ZK-Rollup est livré avec un pont L1<>L2 intrinsèquement, que nous appelons le pont natif. Contrairement aux ponts tiers qui utilisent des systèmes basés sur la liquidité, le pont Native fonctionne comme un mécanisme inter-chaînes unique « à la menthe ». Il garantit la sécurité grâce à des preuves sans connaissance tout en maintenant le manque de confiance. Tous les actifs d'un Rollup proviennent de transactions de dépôt via le pont natif et reçoivent de celui-ci l'approbation de sécurité ultime.  Nous croyons fermement au principe du rasoir d'Occam : « Les entités ne doivent pas être multipliées au-delà de la nécessité ». Les ponts tiers peuvent offrir des expériences inter-chaînes moins chères et plus rapides, mais ils introduisent des coûts de confiance et des risques de sécurité supplémentaires. Le récent incident Multichain en est un bon exemple. Par conséquent, dès le départ, l'inspiration d'Opside pour la communication cross-Rollup était simple : exploiter directement le pont natif pour obtenir une interopérabilité multi-Rollup, plutôt que d'introduire un pont tiers supplémentaire. Ce concept a donné naissance au protocole NCRC (Native Cross Rollup Communication).  Conditions préalables au NCRC  Pour activer le NCRC parmi plusieurs cumuls, les deux conditions préalables suivantes doivent être remplies :  Ces Rollups doivent appartenir au type ZK-Rollup.  Ces Rollups doivent résider sur le même L1.  Les rollups satisfaisant ces deux conditions possèdent théoriquement le même niveau de sécurité que le L1 sous-jacent. De même, le niveau de sécurité du pont natif parmi ces Rollups est identique et ne nécessite aucune confiance entre eux. Toutes les transactions NCRC sont vérifiées par des preuves de validité, servant de source fondamentale d'assurance de sécurité pour NCRC.  Contrat de reconnaissance cumulatif (RRC)  Depuis août 2023, plusieurs ZK-Rollups ont été mis en ligne sur le réseau principal, notamment Polygon zkEVM, zkSync era, Linea, etc. Cependant, ces ZK-Rollups sont indépendants et sans rapport, ce qui conduit à la fragmentation des actifs des utilisateurs. La raison fondamentale de ce problème réside dans le fait que leurs contrats sur L1 (Ethereum Mainnet) ne sont pas liés. Ils ignorent l’existence de chacun et sont incapables de communiquer directement via des ponts Rollup natifs.  Par conséquent, la première étape que nous devons franchir consiste à déployer un contrat spécialisé sur L1 pour permettre aux Rollups de se découvrir et de se reconnaître. C’est ce qu’on appelle le RRC (Rollup Recognition Contract). Le RRC est responsable de la gestion de tous les ZK-Rollups participants dans le NCRC, y compris les ajouts, les pauses et les sorties de Rollups. Chaque Rollup au sein du RRC se voit attribuer un ID de Rollup dédié, tandis que l'ID de L1 reste fixé à 0.  Lors du lancement de transactions cross-Rollup via le pont natif sur un Rollup, les adresses peuvent spécifier l'ID de Rollup cible :  Si l'ID Rollup est 0, cela signifie transmettre le message à L1, comme un retrait.  Si l'ID du Rollup n'est pas 0, cela indique l'envoi du message à un autre Rollup.  Opside déploiera un contrat RRC sur chaque couche L1 et permettra aux ZK-Rollups correspondants de rejoindre ou de quitter sans autorisation. Ce contrat RRC sera utilisé pour conserver les informations pour chaque ID de cumul, y compris l'adresse du contrat de pont sur L1. Il est important de noter que le contrat RRC fournit uniquement des services de récupération de données et n'interagit pas directement avec les actifs inter-chaînes.  Compatibilité avec les contrats et services intelligents Native Bridge  Généralement, le pont natif de Rollup est divisé en trois composants : le contrat de pont sur L1, le contrat de pont sur L2 et un service de pont chargé du relais des messages. Le protocole NCRC exploite ces composants au niveau sous-jacent et ajoute une encapsulation de niveau supérieur. Les principales modifications sont les suivantes :  Contrat pont sur L2 : Tout en conservant les méthodes d'origine, une nouvelle méthode nommée bridgeAsset est ajoutée. Cette méthode permet aux utilisateurs de spécifier l'ID du Rollup cible dans le paramètre destinationNetwork.  Contrat de pont sur L1 : une nouvelle méthode est encapsulée pour gérer les messages inter-chaînes de la nouvelle méthode bridgeAsset. Le contrat relais, basé sur l'ID Rollup trouvé dans le contrat RRC, localise les informations du Rollup cible et transfère les actifs inter-chaînes vers le contrat relais du Rollup cible. Les actifs inter-chaînes y sont déposés dans le Rollup cible.  Service Bridge : responsable du relais des messages et facture des frais aux utilisateurs pour les transactions cross-Rollup.  Une fois qu'un Rollup a terminé l'adaptation de compatibilité liée au NCRC mentionnée ci-dessus, il peut s'enregistrer auprès du RRC pour rejoindre le réseau de communication natif cross-Rollup.  Processus des transactions natives de cumul croisé  Pour les utilisateurs, le fonctionnement de NCRC est tout à fait cohérent avec celui du pont natif de Rollup. Le lancement d'une transaction cross-Rollup de Rollup1 vers Rollup2 est un processus automatisé, comprenant les étapes suivantes :  L'initiateur, User1, sur Rollup1, appelle la méthode bridgeAsset du pont natif pour lancer la transaction inter-chaînes. Le paramètre destinationNetwork dans cette transaction est défini sur l'ID de cumul de Rollup2. Cet ID de cumul sera utilisé pour récupérer l'adresse du contrat de pont L1 correspondant. Si l'ID de cumul est 0, cela signifie que le réseau cible est L1.  Par la suite, cette transaction est packagée par Sequencer1 de Rollup1. L'initiateur, User1, supporte le coût de la transaction cross-Rollup, en le payant à Sequencer1 sur Rollup1. Le service Bridge de Rollup1 transfère ensuite l'actif inter-chaînes vers le contrat de pont Rollup1 sur L1. À ce stade, Rollup1 et L1 terminent les opérations de gravure et de libération de l'actif.  Pour terminer le transfert d'actifs cross-Rollup, le service Bridge de Rollup1 interroge le contrat RRC pour récupérer des informations sur le Rollup2 cible correspondant au paramètre destinationNetwork. Ces informations fournissent l’adresse du contrat de pont L1 de Rollup2. Ensuite, le contrat relais de Rollup2 prend le contrôle de ces actifs et les mappe à Rollup2 via la méthode bridgeAsset.  Enfin, une fois la transaction emballée avec succès et la preuve générée, le service Bridge de Rollup2 exécute l'opération ClaimAsset. Par conséquent, les actifs inter-chaînes initiés par Rollup1 arrivent en toute sécurité à l'adresse désignée sur Rollup2.  Il convient de mentionner que tout au long du processus inter-chaînes, les actifs de l'utilisateur suivent le chemin suivant : Rollup1 -> Contrat relais L1 de Rollup1 -> Contrat relais L1 de Rollup2 -> Rollup2. En d’autres termes, les actifs de l’utilisateur ne passent par aucun protocole tiers ; ils exploitent le pont natif de Rollup. L’ensemble du processus est sécurisé et sans confiance.   Lorsque les utilisateurs exécutent des opérations inter-chaînes sur Rollup1, en sélectionnant Rollup2 comme destination, le processus technique implique en fait trois entités : Rollup1, L1 et Rollup2. Cependant, les utilisateurs n'ont pas besoin d'être conscients de l'existence de L1 dans ce processus ; leur expérience est simplement un croisement direct de Rollup1 à Rollup2. La réalité sous-jacente est que les actifs inter-chaînes subissent deux opérations de pontage sur L1, créant une connexion transparente de Rollup1 à Rollup2 dans la perception de l'utilisateur. Au cours de ce processus, les opérations sur L1 sont gérées automatiquement et les utilisateurs n'ont pas besoin d'effectuer d'actions supplémentaires. Du point de vue de l'utilisateur, son Rollup actuel peut effectuer des opérations inter-chaînes vers L1 et tout autre Rollup. Cette conception améliore la fluidité de l’expérience utilisateur tout en masquant les complexités sous-jacentes.  NCRC est désormais en ligne sur le testnet Opside !  Opside a implémenté avec succès la communication native cross-rollup sur Testnet. Tout le monde peut désormais en faire l'expérience sur le site officiel à l'adresse  .Nous invitons également les utilisateurs et les développeurs à nous aider à identifier les bogues potentiels et les risques de sécurité et à nous fournir des suggestions utiles.   https://pre-alpha-assetshub.opside.network/  Nous pensons que la communication cross-rollup native sans confiance partagera non seulement en toute sécurité la liquidité entre tous les Rollups, mais fournira également une interopérabilité multi-Rollup robuste, ouvrant de nouvelles possibilités pour les applications décentralisées et   . les protocoles DeFi

This writer has a vested interest be it monetary, business, or otherwise, with 1 or more of the products or companies mentioned within.

This is a PR written by or for the company mentioned within it. The writer has a vested interest in the company and products mentioned within.

Cet audio est produit dans la langue originale de l'histoire !

Trop long; Pour lire

CTA: Download the FREE AI Productivity Shift report

Focus sur le protocole natif sans confiance NCRC d'Opside

About Author

COMMENTAIRES

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS

Related Stories

Nomades numériques, écoutez : ce que vous devez savoir sur le nouveau visa DTV de la Thaïlande

Les couches invisibles : pourquoi les entretiens avec les utilisateurs sont un atout irremplaçable

Valhalla de Floki se joint en tant que sponsor associé de la tournée indienne au Sri Lanka

La fuite de l'invite du système Claude Sonnet 3.5 : une analyse médico-légale

Nomades numériques, écoutez : ce que vous devez savoir sur le nouveau visa DTV de la Thaïlande

Les couches invisibles : pourquoi les entretiens avec les utilisateurs sont un atout irremplaçable

Valhalla de Floki se joint en tant que sponsor associé de la tournée indienne au Sri Lanka

La fuite de l'invite du système Claude Sonnet 3.5 : une analyse médico-légale

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps