Analyse du SCP : un paradigme d'infrastructure décentralisée sortant des conventions établies des Rollups
TechFlow SélectionTechFlow Sélection
Analyse du SCP : un paradigme d'infrastructure décentralisée sortant des conventions établies des Rollups
La vision de SCP et ses applications pratiques consistent à construire une nouvelle génération d'infrastructures décentralisées sans besoin de confiance, voire une plateforme de calcul non basée sur la structure blockchain.
Dédié à des analyses Web3 approfondiesRédaction : Wuyue, Geek Web3
Introduction : Cet article présente de manière prospective un paradigme de conception d'infrastructure Web3 apparemment atypique — le paradigme du consensus basé sur le stockage (SCP - Storage-based Consensus Paradigm). Bien que ce modèle de produit diverge fortement en théorie des solutions modulaires dominantes telles que les rollups Ethereum, sa facilité de mise en œuvre et son intégration aisée avec les plateformes Web2 en font une approche très réalisable. Contrairement aux rollups, il ne se restreint pas à un chemin technique étroit dès le départ, mais cherche plutôt à créer un cadre plus large et ouvert afin de fusionner les plateformes Web2 et les infrastructures Web3. Il s'agit donc d'une idée audacieuse et pleine d'imagination.
Imaginons une solution de mise à l'échelle pour blockchain publique possédant les caractéristiques suivantes :
-
Une vitesse comparable à celle des applications Web2 traditionnelles ou des bourses, largement supérieure à toute blockchain publique, L2, rollup ou sidechain.
-
Aucun frais de gaz, un coût d'utilisation quasi nul.
-
Un haut niveau de sécurité des fonds, bien supérieur aux infrastructures centralisées comme les bourses, inférieur aux rollups mais au moins équivalent aux sidechains.
-
Une expérience utilisateur identique à celle du Web2, sans nécessiter aucune connaissance des clés publiques/privées, portefeuilles ou infrastructures blockchain.
Une telle solution est particulièrement enthousiasmante : d’un côté, elle atteint presque la limite maximale en matière de mise à l’échelle ; d’un autre côté, elle jette des bases solides pour l’adoption massive du Web3, réduisant pratiquement à néant l’écart d’expérience entre Web2 et Web3.
Toutefois, peu de solutions semblent capables d’atteindre un tel niveau de complétude, car les discussions et expérimentations dominantes sont encore trop rares.
Nous avons utilisé la mise à l’échelle, sujet familier, comme point d’entrée. En réalité, le SCP ne se limite pas à la mise à l’échelle : son inspiration provient des débats communautaires et des solutions de mise à l’échelle des blockchains comme Bitcoin ou Ethereum. Son ambition réelle est de construire une nouvelle génération d’infrastructures désintermédiées, voire des plateformes de calcul non basées sur la structure blockchain.
Composants fondamentaux et principe de fonctionnement du SCP
En général, le SCP, tout comme les « blockchains modulaires » discutées dans les communautés Ethereum et Celestia, divise ses composants en couches distinctes : disponibilité des données, exécution, consensus et règlement.
-
Couche de disponibilité des données (DA) : Assurée par une blockchain reconnue et éprouvée, ou par une infrastructure de stockage dédiée comme Ethereum, Arweave ou Celestia.
-
Couche d’exécution : Un serveur qui reçoit les transactions des utilisateurs, les exécute, puis soumet par lots les données signées vers la couche DA. Similaire à l’ordonnanceur d’un rollup, cette couche n’a pas besoin d’une structure en chaîne typique de blockchain. Elle peut être entièrement constituée d’une base de données Web2 et d’un système de calcul, à condition que ce dernier soit open source et transparent.
-
Couche de consensus : Composée d’un ensemble de nœuds qui récupèrent les données soumises par la couche d’exécution à la couche DA, puis recalculent ces données avec le même algorithme pour vérifier la justesse des résultats. Cette couche agit aussi comme redondance de secours en cas de panne de la couche d’exécution. Les utilisateurs peuvent lire les données renvoyées par les nœuds du consensus pour s’assurer qu’il n’y a pas de fraude.
-
Couche de règlement : Constituée de nœuds et de contrats ou adresses sur d'autres blockchains, gérant les dépôts dans le SCP et les retraits. Son fonctionnement ressemble à celui d’un pont cross-chain. Les nœuds de règlement contrôlent l’adresse de dépôt via un contrat multisignature ou une adresse basée sur TSS. À l’entrée, l’utilisateur envoie ses actifs vers une adresse désignée ; au retrait, une requête est envoyée, et les nœuds libèrent les fonds après validation multisignature ou TSS. La sécurité dépend du mécanisme cross-chain utilisé.
Cadre pratique du SCP
Voici comment comprendre le paradigme SCP. Un produit conforme au cadre SCP peut offrir des fonctions principales telles que dépôt, transfert, retrait, swap, etc., et permettre des extensions futures. Le schéma ci-dessous illustre le principe d’un tel produit :
-
La couche DA utilise Arweave, une infrastructure de stockage permanent, représentée par le grand cercle sur l’image.
-
Le Coordinateur (Coordinator), c’est-à-dire la couche d’exécution. Les utilisateurs soumettent leurs transactions au coordinateur, qui les exécute, affiche les résultats, puis soumet par lots les données brutes vers la couche DA.
-
Les Détecteurs (Detector) récupèrent depuis Arweave les données brutes soumises par le coordinateur, puis les vérifient en utilisant le même algorithme. Le client détecteur est également open source, et n'importe qui peut l'exécuter.
-
Les Gardiens (Watchmen), un groupe de détecteurs détenant les clés de signature multisignature du système de retrait. Ils valident et autorisent les demandes de retrait selon les données de transaction, et sont également chargés de signer les propositions.
On observe que tout le système repose sur un consensus entièrement hors chaîne. C’est là le cœur du paradigme du consensus basé sur le stockage — il abandonne le système de consensus entre nœuds typique de la blockchain, libérant ainsi la couche d’exécution des processus coûteux de communication et de confirmation, lui permettant d’atteindre un TPS quasi illimité et une grande efficacité économique. Ce point est similaire aux rollups, mais le SCP emprunte une voie différente, cherchant à transformer ce cas d’usage dédié à la mise à l’échelle en un nouveau modèle de transition entre Web2 et Web3.
Le coordinateur mentionné ci-dessus est un serveur centralisé, mais cela ne signifie pas qu’il puisse agir arbitrairement. Comme pour l’ordonnanceur d’un rollup, une fois que les données brutes des utilisateurs sont soumises par lots sur Arweave, n’importe qui peut exécuter un programme de détecteur pour les vérifier et comparer les états retournés par le coordinateur. D’un certain point de vue, cette logique rappelle celle des applications basées sur des inscriptions (inscriptions).
Dans cette architecture, un serveur ou une base de données centralisée ne constitue pas un obstacle fondamental. Une autre particularité du SCP est de dissocier les concepts de « centralisation » et de « contrôle par une seule entité » — dans un système désintermédié, on peut avoir des composants centralisés, voire un composant central, sans compromettre la nature désintermédiée du système global.
Nous pouvons alors formuler ce slogan : « Les infrastructures désintermédiées de prochaine génération n’ont pas besoin de s’appuyer sur un protocole de consensus, mais doivent être des systèmes open source soutenus par un réseau P2P de nœuds. »
L’objectif initial de la blockchain était la désintermédiation, la cohérence du registre, l’impossibilité de falsification, la traçabilité, etc., comme clairement exposé dans le whitepaper de Bitcoin. Mais depuis Ethereum, que ce soient les solutions de mise à l’échelle des anciennes blockchains, les rollups ou les blockchains modulaires, une pensée unique s’est installée : tout ce que nous créons doit être une blockchain (basée sur un protocole de consensus entre nœuds), ou du moins une solution ayant l’apparence d’une chaîne (structure de données blockchain sans échange direct de messages de consensus entre nœuds).
Or, avec le cadre SCP, même sans être une blockchain, il devient possible de remplir toutes ces exigences — désintermédiation, cohérence du registre, impossibilité de falsification, traçabilité — à condition de définir précisément les détails techniques.
Couche d’exécution
La couche d’exécution joue un rôle crucial dans l’ensemble du système : elle gère tous les calculs et détermine les types d’applications pouvant y être exécutées.
Un environnement d’exécution aux possibilités infinies
Théoriquement, l’environnement d’exécution peut prendre n’importe quelle forme. Les possibilités sont illimitées, selon la vision du projet :
-
Une bourse. Le SCP permettrait de construire une plateforme d’échange publique, transparente, à haut TPS, combinant la rapidité et le zéro coût des CEX avec la décentralisation des DEX. La frontière entre CEX et DEX s’efface ici.
-
Un réseau de paiement, similaire à Alipay ou PayPal.
-
Une machine virtuelle ou blockchain supportant le déploiement de programmes/contrats. Tout développeur pourrait déployer des applications, partageant les données des utilisateurs et agissant selon leurs instructions.
Ce modèle de conception du SCP, compatible avec tout environnement d’exécution, présente un avantage unique : il n’a pas à dépendre de composants historiquement contraignants, notamment la notion d’« abstraction de compte » inventée par la communauté Ethereum, qui est intrinsèquement inutile pour le SCP.
Dans l’architecture SCP, le concept d’abstraction de compte n’existe tout simplement pas — vous pouvez librement adopter des comptes standards Web2 ou des comptes blockchain. De ce fait, de nombreux cas d’usage mûrs du Web2 peuvent être directement réutilisés sur SCP sans avoir besoin d’être repensés. C’est peut-être là l’un des principaux avantages du SCP par rapport au rollup.
Transparence et asymétrie
Concernant les systèmes de comptes, les lecteurs attentifs auront remarqué que si le SCP peut tirer parti des systèmes de comptes Web2, leur utilisation directe pose problème.
Car l’ensemble du système est totalement transparent ! Utiliser directement le modèle d’interaction serveur-utilisateur entraînerait de graves failles de sécurité. Rappelons d’abord comment fonctionne le modèle classique serveur-utilisateur :
1. Inscription : L'utilisateur saisit un nom d'utilisateur et un mot de passe. Pour protéger le mot de passe, le serveur l'applique à une fonction de hachage. Pour renforcer la sécurité contre les attaques par tables arc-en-ciel, une chaîne aléatoire (« sel ») est ajoutée à chaque mot de passe avant hachage. Le nom d'utilisateur, le sel et le hachage sont stockés en clair dans la base de données du fournisseur, sans être rendus publics. Même ainsi, des mesures de sécurité supplémentaires sont nécessaires pour prévenir les fuites internes ou externes.
2. Connexion : L'utilisateur saisit son nom d'utilisateur et mot de passe. Le système compare le hachage généré avec celui stocké. Si les deux correspondent, la connexion est validée.
3. Authentification des opérations : Après authentification, un jeton de session (cookie ou token) est créé côté serveur et envoyé au navigateur. Lors des requêtes ultérieures, le navigateur inclut automatiquement ce cookie pour prouver son autorisation.
Passons maintenant au modèle typique d’interaction Web3 blockchain-utilisateur :
1. Création de compte : Aucune inscription n’est nécessaire, ni système nom d’utilisateur/mot de passe. Les comptes (adresses) existent naturellement ; seul le détenteur de la clé privée contrôle le compte. La clé privée est générée localement par le portefeuille, sans connexion réseau.
2. Connexion : Pas de connexion au sens traditionnel. La plupart des dApps se connectent via un portefeuille. Certaines demandent une signature pour confirmer la possession réelle de la clé privée.
3. Authentification des opérations : L'utilisateur signe directement les données et les soumet aux nœuds, qui les diffusent sur le réseau. Une fois validées selon le consensus, les opérations sont confirmées.
Ces différences proviennent de la symétrie vs asymétrie. Dans le modèle serveur-utilisateur, les deux parties partagent un secret. Dans le modèle blockchain-utilisateur, seul l’utilisateur détient le secret.
Bien que la couche d’exécution du SCP ne soit pas une blockchain, toutes les données doivent être synchronisées vers la couche DA publiquement visible. Par conséquent, les méthodes d’authentification utilisées dans le SCP doivent être asymétriques. Mais pour éviter les fardeaux liés à la gestion des clés privées ou à l’utilisation de portefeuilles, nuisibles à l’adoption massive, il reste un fort besoin d’intégrer des systèmes d’authentification Web2 comme les identifiants/mots de passe ou OAuth. Comment concilier les deux ?
Grâce à la cryptographie asymétrique et aux preuves à divulgation nulle, je propose deux solutions envisageables :
-
Pour utiliser un système ID-mot de passe, le module de stockage des mots de passe peut être externalisé, invisible aux autres. La couche d’exécution continue d’utiliser les comptes et logiques blockchain (sans inscription ni connexion). L’ID utilisateur correspond en réalité à une clé privée. Cette clé ne doit pas être conservée par le projet. Une solution viable consiste à utiliser un MPC 2-sur-3 pour éviter le stockage centralisé tout en préservant une bonne expérience utilisateur.
-
Avec OAuth, le JWT (Json Web Token) peut servir de méthode d’authentification. Cette approche est légèrement plus centralisée, car elle dépend des services d’authentification tiers fournis par les géants du Web2.
-
Lors de la première connexion via OAuth, les champs du JWT identifiant l’utilisateur et le fournisseur sont enregistrés dans le système. Pour chaque opération ultérieure, l’instruction est traitée comme input public, tandis que le JWT complet sert de witness secret, et chaque transaction est vérifiée via ZKP.
-
Chaque JWT a une durée limitée. Lors de la prochaine connexion, un nouveau JWT est généré, donc aucun stockage permanent n’est requis. Le système dépend aussi de JWK (clés publiques fournies par les grands acteurs pour vérifier les JWT). La manière de les intégrer de façon décentralisée et de gérer leur rotation mérite une discussion approfondie.
Quelle que soit la méthode choisie, les coûts de développement et de calcul seront plus élevés que dans les méthodes traditionnelles, mais c’est le prix nécessaire de la décentralisation. Naturellement, si le projet ne juge pas utile d’aller jusqu’au bout de la décentralisation, ou s’il a des jalons différents selon les phases, ces conceptions ne sont pas obligatoires. La décentralisation n’est pas binaire, mais existe sur un spectre.
Vie privée
La transparence mentionnée plus haut affecte non seulement l’interaction utilisateur, mais aussi la confidentialité des données. Toutes les données sont exposées. Bien que cela ne pose pas de problème dans une blockchain classique, certaines applications ne peuvent l’accepter. Les développeurs peuvent donc concevoir des systèmes de transactions privées.
Frais
La tarification de la couche d’exécution est un autre point important. Soumettre des données à la couche DA a un coût, de même que le fonctionnement du serveur. Dans les blockchains traditionnelles, les frais de gaz visent d’abord à empêcher les attaques par spam, puis à ordonner les transactions. Le Web2 n’a pas ce souci, hormis les attaques DDoS classiques.
La couche d’exécution peut définir diverses stratégies tarifaires, gratuites ou partiellement payantes, ou générer des revenus via d’autres moyens comme le MEV (déjà mature chez les ordonnanceurs), des activités commerciales, etc.
Résistance à la censure
La couche d’exécution n’est pas résistante à la censure : elle peut refuser arbitrairement les transactions. Dans les rollups, cette résistance est garantie par le contrat L1 via la fonction de collecte forcée. Les sidechains ou blockchains complètes, étant des réseaux distribués, sont difficiles à censurer.
Pour l’instant, aucune solution claire n’existe pour résoudre ce problème, ce qui constitue une faiblesse du paradigme SCP.
Couche de consensus
Cette couche est composée de nœuds indépendants, qui ne forment pas activement un réseau. Elle n’est donc pas une couche de consensus stricte, mais sert uniquement à confirmer l’état courant de la couche d’exécution aux utilisateurs ou au monde extérieur.
Par exemple, si vous doutez de l’état de ces nœuds, vous pouvez télécharger le client détecteur, qui exécute le même code que le coordinateur.
Cependant, comme pour les rollups, les données étant soumises par lots, l’état retourné par la couche d’exécution est toujours plus récent que celui sur la couche DA. On parle alors de pré-confirmation :
La couche d’exécution fournit une confirmation préliminaire, une finalité douce, car les données ne sont pas encore sur la couche DA ;
La couche de consensus fournit une finalité forte. Les utilisateurs peuvent s’en moquer, mais pour des applications comme les ponts cross-chain, seule la finalité forte est acceptable. Par exemple, un système de dépôt/retrait d’une bourse n’accordera pas de crédit aux données diffusées hors chaîne par un ordonnanceur de rollup ; il attendra qu’elles soient confirmées sur Ethereum.
Outre la confirmation des résultats, la couche de consensus joue un rôle crucial de redondance de secours pour la couche d’exécution. Si cette dernière venait à cesser définitivement ou à commettre des actes malveillants, n’importe quel nœud du consensus pourrait théoriquement reprendre ses fonctions et traiter les requêtes. Dans un tel scénario, la communauté choisirait probablement des nœuds fiables pour assumer ce rôle.
Couche de règlement
Le SCP n’étant pas un rollup, il ne peut offrir un retrait désintermédié, entièrement basé sur la cryptographie et les contrats intelligents, comme c’est le cas pour les rollups. La sécurité du pont cross-chain du SCP est équivalente à celle des sidechains ou des ponts basés sur des témoins tiers, dépendant de gestionnaires multisignatures autorisés — ce que nous appelons le modèle « témoin ».
Rendre le pont témoin aussi décentralisé que possible est un sujet de recherche actif. Faute de place, nous ne développerons pas ici. Un bon projet SCP devra collaborer avec des partenaires de pont décentralisé et de confiance.
On pourrait se demander pourquoi le SCP n’utilise pas une chaîne avec contrats intelligents comme couche DA ? Cela permettrait de créer une couche de règlement entièrement désintermédiée via des contrats.
À long terme, en surmontant certains obstacles techniques, si la couche DA est placée sur Ethereum ou une chaîne similaire, et qu’on peut y déployer des contrats de vérification, le SCP pourrait atteindre la même sécurité de règlement qu’un rollup, sans multisignature.
Mais en pratique, ce n’est pas nécessairement optimal :
1. Ethereum n’est pas spécialisé dans le stockage de données, et son coût est élevé comparé aux blockchains dédiées. Pour le paradigme SCP, un coût de stockage suffisamment bas ou fixe est essentiel pour supporter un débit comparable au Web2.
2. Les systèmes de preuve sont extrêmement complexes à développer, car le SCP peut implémenter n’importe quelle logique, pas seulement simuler l’EVM. En voyant que même des équipes comme Optimism n’ont pas encore lancé leurs preuves de fraude, ou la difficulté du zkEVM, on imagine combien il serait ardu de créer des preuves pour des systèmes variés sur Ethereum.
Ainsi, le modèle rollup n’est pratiquement pertinent que dans des cas spécifiques. Si vous souhaitez une architecture plus large, ouverte, sortant du cadre EVM pour intégrer davantage de fonctionnalités Web2, la logique du rollup Ethereum n’est pas adaptée.
Le SCP n’est pas une simple solution de mise à l’échelle d’une blockchain, mais une architecture plus vaste de plateforme de calcul Web3. Il n’a donc aucune raison de suivre la voie du Layer2 Ethereum.
Un schéma comparatif du SCP avec d'autres paradigmes
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@godrealmx
