Blockchains modulaires : suivre l'exécution, les données et le règlement
Une blockchain modulaire répartit les responsabilités entre les composants plutôt que de demander à un seul système d'effectuer chaque tâche. Cela peut donner l’impression qu’une description du réseau est simple : l’exécution a lieu ici, les données vont là et le règlement a lieu ailleurs. La question importante est de savoir ce que chaque composant garantit réellement.
Cet article compare les rôles architecturaux, et non les prix symboliques ou un classement des projets. Une conception modulaire n’implique pas automatiquement un risque plus faible, des retours sur investissement plus élevés ou une sécurité identique dans toutes les implémentations.
Séparez les tâches avant de comparer les systèmes
L'exécution applique les règles de transaction et calcule un changement d'état proposé. La disponibilité des données concerne la question de savoir si les informations nécessaires à la vérification du système ont été mises à disposition. Le règlement détermine comment le protocole accepte les engagements cryptographiques sur l’état de la chaîne (state commitments), les preuves ou les contestations. Le consensus détermine l'ordre convenu ou l'historique accepté au sein d'un système.
Ces rôles peuvent se chevaucher ou être répartis de différentes manières. Les étiquettes de projet ne suffisent pas : un réseau peut se dire modulaire tout en conservant un contrôle important sur un séquenceur, une clé de mise à niveau ou un comité de données. Dessinez la carte des dépendances réelle plutôt que de supposer que tous les réseaux modulaires partagent un seul modèle de confiance.
Documentation sur la disponibilité des données d'Ethereum explique pourquoi la vérification dépend de l'accès aux données de transaction et pourquoi les clients légers et les rollups ont besoin d'assurances appropriées. L'accès aux données est une question différente de celle de savoir si un calcul exécuté est correct.
Suivre une transaction hypothétique
Imaginez qu'un utilisateur envoie une transaction à un réseau d'exécution. Un séquenceur l'inclut dans un batch. Le système met à disposition les données requises à l'aide de la couche de données choisie et soumet un engagement cryptographique sur l’état de la chaîne (state commitment), avec le mécanisme de vérification requis par sa conception, à une couche de règlement.
L'utilisateur peut voir une confirmation anticipée avant que chaque étape n'atteigne son statut final. Enregistrez la signification de chaque statut : reçu, ordonné dans la séquence, exécuté, données publiées, preuve acceptée ou fenêtre de contestation terminée. Ne qualifiez pas le premier accusé de réception de règlement final à moins que le protocole ne soutienne cette interprétation.
Cet exemple décrit les rôles plutôt que de prescrire une séquence universelle. Différents cumuls et systèmes modulaires peuvent combiner des étapes ou utiliser différents arrangements de preuve et de finalité.
Demandez ce qui se passe lorsqu'un composant tombe en panne
Si un séquenceur s’arrête, les utilisateurs peuvent-ils soumettre des transactions d’une autre manière, et dans quelles conditions ? Si un service de données retient des informations, qui les détecte et que peuvent vérifier les utilisateurs ? Si une couche de règlement est encombrée, comment les engagements ou les retraits sont-ils affectés ?
Répondez à ces questions à partir de la documentation actuelle, y compris les procédures d’urgence et les contrôles administratifs. Un repli décrit dans une roadmap n’est pas forcément opérationnel. Un réseau qui continue d’afficher les soldes peut encore avoir une capacité réduite à accepter des transactions ou à effectuer des retraits.
Examinez les dépendances du pont séparément. Un jeton apparaissant sur deux réseaux ne signifie pas que la route de transfert hérite de toutes les propriétés de sécurité des deux chaînes.
Comparez le coût complet et l'expérience utilisateur
Les faibles frais d’exécution ne représentent qu’une partie du coût de la transaction. Les opérations de publication de données, de règlement, de pontage et de retrait peuvent ajouter des frais ou des retards. Comparez des actions équivalentes sur la même période et expliquez qui paie quel coût.
Mesurez le parcours complet pertinent pour l'utilisateur : entrée, exécution, confirmation, retrait et retour à l'actif ou au réseau souhaité. Un benchmark portant sur une seule étape ne doit pas être présenté comme le prix d’un aller-retour complet. Les économies de coûts peuvent également varier en fonction de la demande et des conditions de la couche de données.
Utilisez une liste de contrôle des dépendances
Pour chaque système, enregistrez les règles d'exécution, l'autorité de commande, l'emplacement des données, le mécanisme de vérification, la destination du règlement, les contrôles de mise à niveau et la procédure de sortie. Marquez quelles réclamations sont en cours et lesquelles sont planifiées. Incluez les sources et la date vérifiée, car les paramètres architecturaux peuvent changer.
Pour un problème connexe mais distinct, lisez la comparaison des messages inter-chaînes : elle suit les instructions entre les chaînes, tandis que ce guide suit la division du travail au sein d'une architecture.
La conception technique d’un protocole et les droits économiques de son jeton sont des questions de recherche distinctes. Vérifiez l'utilité du jeton et la disponibilité réelle du marché de manière indépendante via la documentation officielle et la page des marchés OrangeX, plutôt que de traiter une réclamation de mise à l'échelle comme une conclusion commerciale.
