Modulaire est actuellement un terme populaire dans le web3 qu'un certain nombre de protocoles et de projets utilisent pour se décrire. Celestia a popularisé le terme en introduisant le concept de blockchains modulaires. Notre objectif est de limiter l'accent et l'utilisation du terme à une définition très spécifique de l'interopérabilité modulaire. Nous présenterons également un cadre de réflexion et d'évaluation des blockchains modulaires et des protocoles d'interopérabilité.

Décomposer les protocoles de blockchain

Il existe quelques couches composables dans la pile de blockchain modulaire :

• Disponibilité des données (DA)
• Séquençage ou commande de transaction (TO)
• Exécution
  - Règlement

Notez que le consensus n'est pas inclus ici car il peut être regroupé dans l'une des couches ci-dessus pour permettre de vérifier une preuve de consensus au lieu de vérifier directement les règles de la couche fonctionnelle.

Par exemple, on pourrait déployer un cumul de nœud unique au-dessus de Celestia sans consensus qui s'appuie sur des preuves de fraude pour convaincre un tiers de l'exactitude. Cela s'appellerait un cumul optimiste. Si nous échangeons la preuve de fraude contre une preuve de connaissance nulle (zk), nous obtiendrons un cumul zk. Si nous ajoutons le consensus, nous pouvons à la place utiliser la preuve du consensus pour convaincre un tiers de l'exactitude. Cela s'appellerait un cumul pessimiste.

Décomposer les protocoles d'interopérabilité

Un protocole d'interopérabilité complet comporte trois couches bien définies avec une séparation claire entre les deux.

Une définition simple de chaque couche d'interopérabilité :

• Application : que signifient les paquets de données ?
• Transport : comment traduire l'état de l'autre chaîne en conversations app <> app et en paquets de données ?
• État : comment les blockchains prennent-elles conscience de l'état de l'autre ?

Définir l'interopérabilité modulaire

Étant donné que modulaire est un terme souvent utilisé et pertinent dans de nombreux contextes, nous essaierons de relier notre définition d'un protocole d'interopérabilité modulaire aux couches définies ci-dessus ainsi qu'à la définition de Celestia d'une blockchain modulaire. Celestia définit une blockchain modulaire comme une blockchain qui sous-traite entièrement au moins une couche fonctionnelle à une chaîne externe. Nous définissons un protocole d'interopérabilité modulaire comme un protocole qui externalise entièrement la couche transport.

La principale différence entre les deux est que la couche de définition des protocoles d'interopérabilité est la couche de transport . L'analogie ici, en utilisant le modèle OSI comme exemple, est que si vous remplacez TCP/UDP par un autre protocole de transport, vous obtenez un protocole réseau entièrement différent. En outre, la couche d'état peut être établie par divers moyens et ne définit pas de manière unique un protocole d'interopérabilité (par exemple, clients légers, preuves à connaissance nulle, preuves de fraude optimistes, etc.). La logique de la couche application peut également être généralisée et ne rend pas un protocole d'interopérabilité compatible avec un autre. Par exemple, le remplacement du transport IBC par une autre couche de transport rend le nouveau protocole incompatible avec les chaînes compatibles IBC .

La couche d'état peut également être partiellement externalisée, mais l'externalisation seule ne rend pas le protocole modulaire car ce n'est pas la couche de définition des protocoles d'interopérabilité. Il est considéré comme entièrement en chaîne lorsque chaque chaîne exécute directement la logique client léger de son homologue. La couche d'état est considérée comme partiellement en chaîne lorsque la logique du client léger est exécutée hors chaîne et vérifiée en chaîne à l'aide de preuves à connaissance nulle (zk) ou lorsqu'un tiers de confiance est utilisé.

De plus, la modularisation des chaînes monolithiques a des implications sur la couche d'état des protocoles d'interopérabilité. Par exemple, une seule chaîne logique ne peut plus être représentée par un seul client léger car la preuve de différentes couches fonctionnelles provient désormais de plusieurs chaînes.

Polymère le hub de transport IBC

Polymer construit le premier protocole d'interopérabilité véritablement modulaire qui externalise entièrement la couche de transport et partiellement la couche d'état. Comme le montre le diagramme ci-dessous, la couche de transport IBC s'exécute sur Polymer tandis que la couche d'application IBC s'exécute sur la chaîne activée IBC. Avec cette conception, activer IBC sur une nouvelle chaîne utilisant Polymer est aussi simple que de déployer un roll up sur Celestia . Polymer sous-traite en partie la couche d'état en utilisant des connexions zk-IBC pour se connecter aux chaînes nouvellement activées IBC tandis que le vérificateur zk se trouve sur la chaîne (non illustré dans le diagramme ci-dessus pour plus de simplicité).

Construisons ensemble

Bâtissons un avenir où IBC est le protocole d'interopérabilité standard pour toutes les chaînes. Les idées d'amélioration de l'IBC sont toujours les bienvenues. Venez discuter avec nous sur discord . Nous recrutons également . L'innovation s'accélère lorsque nous travaillons tous ensemble !

Merci pour les conversations Jim (Catalyst) et Josh (Astria) !

À propos du polymère

Polymer croit en un avenir multichaîne connecté principalement par une norme industrielle open source, développée et maintenue par la communauté, IBC x Polymer. Polymer est le premier centre de transport IBC axé sur l'expansion d'IBC à toutes les chaînes. Le hub en polymère intègre la couche de transport IBC avec des chaînes connectées. Au niveau de la couche d'état, il ouvre les connexions zk-IBC à toutes les chaînes intégrées. Il s'agit d'une architecture à confiance réduite basée sur la vérification de l'état du client léger.

Suivez notre Twitter , visitez notre site Web et rejoignez notre communauté sur Discord !