Aller au contenu
Financial Context Wiki

Architecture de blockchain modulaire

Guide fondé sur les dépendances pour séparer exécution, séquençage, disponibilité des données, consensus, règlement, preuves, bridges, gouvernance et archivage.

Mis à jour

À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.

Réponse directe

L’architecture de blockchain modulaire est une méthode d’analyse de la répartition des responsabilités d’un système, pas une catégorie de produit normalisée. Exécution, ordre des transactions, engagements d’état, preuves ou litiges, publication des données et son consensus, règlement, bridges, gouvernance et archivage à long terme peuvent être réunis dans un protocole, répartis entre plusieurs systèmes ou dupliqués entre fournisseurs. Une couche peut exercer plusieurs fonctions et une fonction peut dépendre de plusieurs couches.

La question utile n’est donc pas de savoir si un projet est « modulaire », mais quel composant valide quel objet, qui le contrôle, ce qui se passe s’il s’arrête et comment les utilisateurs récupèrent indépendamment état ou actifs. Un reçu du séquenceur ne prouve ni disponibilité des données ni finalité ; une preuve de validité ne fournit pas les données ; un engagement sur la chaîne de règlement ne prouve pas la récupération permanente ; et un règlement partagé ne crée pas de composabilité synchrone entre rollups.

Fonctionnement

  1. Identifiez le système déployé : ID des chaînes d’exécution et de règlement, version du protocole, machine virtuelle, contrats, adresses du bridge et des actifs, mode de disponibilité des données, opérateurs, administrateurs et bloc ou instant observé. La taxonomie commerciale ne remplace pas la configuration déployée.
  2. Construisez une matrice des responsabilités. Séparez entrée et séquençage des transactions, exécution déterministe, engagement d’état et preuve ou litige de faute, publication DA et son consensus, acceptation et finalité du règlement, bridge et messagerie cross-domain, mises à niveau et pauses, et stockage historique. Consignez les chevauchements sans forcer une fonction dans une seule couche.
  3. Suivez une transaction et son batch de bout en bout : entrée signée, reçu local ou du séquenceur, exécution ordonnée, batch encodé et compressé, publication par calldata, blob ou DA externe, revendication d’état et preuve ou litige, finalité du règlement, puis exécution du message ou du retrait. Conservez hash, versions, reçus et horloges à chaque frontière.
  4. Identifiez chaque objet vérifié et hypothèse de confiance. Distinguez l’engagement de données des octets, la disponibilité pendant la fenêtre du protocole de la récupération ultérieure, la validité d’exécution de la finalité du consensus et la comptabilité du bridge de la liquidité de l’actif. Indiquez qui peut reproduire, prouver, contester, censurer, mettre à niveau, suspendre ou retenir chaque objet.
  5. Reconstituez le registre de capacité et de coûts. Mesurez octets bruts et compressés, occupation du batch, prix DA, coûts de preuve et de règlement, frais d’exécution et d’opérateur, gas du bridge et frais de liquidité. L’allocation moyenne du batch ne correspond ni aux frais réels d’un utilisateur ni au coût marginal d’une transaction supplémentaire.
  6. Testez les défaillances plutôt que le seul débit normal. Arrêtez séquenceur, batch poster, prover, challenger, service DA, RPC de règlement et relayer du bridge ; testez inclusion forcée, dérivation indépendante, reconstruction des données, preuve ou contestation, nouvel essai, sortie et récupération d’archive sous congestion et limites de mise à niveau.
  7. Rapprochez les résultats des preuves canoniques. Reliez reçus d’exécution et racines d’état aux engagements du batch, à l’inclusion DA, à l’état de la preuve ou du game, à la finalité du règlement, aux messages du bridge et aux soldes finaux. Reprenez l’étude après une réorganisation, une modification de paramètre, une mise à niveau de contrat ou une migration DA.

Exemples détaillés

  • Coût et compression d’un batch. Un batch contient 5,000 transactions, 2,400 KB d’entrées brutes et 300 KB après compression. Le taux de compression est 2,400 / 300 = 8.0x et le nombre d’octets diminue de 87.5%. Si DA coûte 0.020 ETH et que la preuve partagée plus le règlement coûtent 0.005 ETH, le coût partagé moyen est (0.020 + 0.005) / 5,000 = 0.000005 ETH/tx. L’ajout de 0.000020 ETH/tx pour l’exécution et l’opérateur donne 0.000025 ETH/tx. C’est une allocation, pas une facturation garantie.
  • Limite d’un modèle d’échantillonnage. Dans un modèle pédagogique, un adversaire retient 25% des fragments et un client réalise 20 tirages uniformes indépendants avec remise. La probabilité de manquer tous les fragments retenus est 0.75^20 = 0.003171211939 = 0.3171211939% ; la probabilité de détection est 99.6828788061%. Peers corrélés, service adaptatif, codage d’effacement et règle d’échantillonnage réelle peuvent invalider ce modèle simple.
  • Sécurité et disponibilité d’un comité. Un comité DA 5-of-7 peut former une nouvelle attestation à seuil avec au plus 2 membres indisponibles ; si 3 sont absents, il n’en reste que 4 < 5. Selon une règle pédagogique fondée uniquement sur les signatures, le contrôle de 5 signataires autorisés satisfait le seuil. Un certificat ne prouve toujours pas l’existence de cinq copies durables, la récupération actuelle des octets par un utilisateur, ni la validité de l’exécution et du règlement.
  • Plusieurs horloges et sortie rapide. Une soft confirmation pédagogique arrive en 2 seconds, le batch est publié après 8 minutes et la finalité du règlement arrive 13 minutes plus tard : le délai exact est 21 minutes 2 seconds. Si un retrait optimiste ajoute une durée hypothétique de 7 days, le total atteint 10,101 minutes 2 seconds. Un bridge rapide facturant 0.15% sur 10,000 USDC retient 15 USDC et livre 9,985 USDC ; la rapidité ajoute des hypothèses concernant bridge, fournisseur de liquidité et réorganisation au lieu de raccourcir l’horloge du protocole.

Risques

  • Mauvaise identification des responsabilités ou des frontières réelles.
  • Censure, réordonnancement ou panne du séquenceur.
  • Inclusion forcée indisponible, permissionnée ou trop lente.
  • Panne du batch poster ou du state proposer.
  • Panne du prover centralisé ou accumulation de preuves.
  • Absence de fault challenger actif, éligible ou financé.
  • Défaillance de l’horloge, du bond, de l’oracle ou du vérificateur du fault game.
  • Erreur du circuit de validité, du système de preuve ou de la clé de vérification.
  • Rétention de données pendant la fenêtre de disponibilité requise.
  • Échantillonnage corrélé, attaque eclipse ou défaut de vue réseau.
  • Collusion de seuil ou compromission des clés du comité DA.
  • Données disponibles pour le protocole sans archives indépendantes durables.
  • Réorganisation du règlement ou mauvaise classification de la finalité.
  • Défaillance du bridge, du messenger, de la protection anti-replay ou de l’exécution cible.
  • Insolvabilité, manque d’inventaire ou tarification défavorable du bridge rapide.
  • Compromission d’un administrateur, d’un multisig ou du conseil de sécurité.
  • Mise à niveau immédiate, version incompatible ou délai de sortie insuffisant.
  • Hausse des frais DA, congestion des blobs, batches plus petits ou fin de subvention.
  • Incompatibilité de version entre état, données, preuve, contrat ou client.
  • Ordre cross-domain asynchrone, exécution partielle ou échec de composabilité.

Idées reçues courantes

  • Une architecture modulaire est automatiquement plus décentralisée qu’une conception monolithique.
  • Une preuve de validité remplace la disponibilité et la récupération historique des données.
  • Le règlement sur Ethereum transmet chaque propriété de sécurité d’Ethereum à chaque composant.
  • Un message de réussite du séquenceur signifie règlement final et retrait exécutable.
  • Des TPS supérieurs, une DA partagée ou un règlement partagé garantissent des coûts inférieurs et une composabilité synchrone.

Sujets associés

Sources

Navigation

Rechercher dans le wiki...