Introduction :

Cet article fournit une introduction prospective à un paradigme de conception d'infrastructure Web3 quelque peu non conventionnel : le paradigme de consensus basé sur le stockage (SCP). Ce modèle de conception diverge significativement des solutions de blockchain modulaire mainstream comme les Rollups Ethereum en théorie. Cependant, il démontre une grande faisabilité en termes de simplicité dans la mise en œuvre et l'intégration avec les plateformes Web2. SCP n'a pas l'intention de se limiter à un chemin étroit de réalisation comme les Rollups. Au lieu de cela, il vise à adopter un cadre plus large et plus ouvert pour fusionner les plateformes Web2 avec l'infrastructure Web3. Cette approche peut être considérée comme hautement imaginative et innovante.

Envisageons une solution de mise à l'échelle de la blockchain publique avec les caractéristiques suivantes :

• Il a des vitesses comparables aux applications ou échanges Web2 traditionnels, dépassant largement toute blockchain publique, Layer 2 (L2), rollups, sidechains, etc.

• Il n'y a pas de frais de gaz, et le coût d'utilisation est presque nul.

• Une sécurité financière élevée, dépassant les installations centralisées telles que les échanges, inférieure aux Rollups mais supérieure ou égale aux sidechains.

• Une expérience utilisateur identique à Web2, sans nécessiter de connaissance des clés publiques et privées de la blockchain, des portefeuilles, de l'infrastructure, etc.

Une telle solution est en effet très excitante : d'une part, elle a essentiellement atteint le sommet en termes de mise à l'échelle ; d'autre part, elle pose des bases solides pour l'adoption de masse de Web3, comblant essentiellement le fossé entre les expériences utilisateur de Web2 et Web3. Cependant, il semble que nous ayons peu de solutions complètes comme celle-ci, car les discussions et pratiques dominantes sont effectivement trop rares.

Nous utilisons le sujet bien connu de l'escalabilité comme introduction ci-dessus, mais SCP n'est pas limité aux cas d'utilisation de l'escalabilité. Son inspiration de conception provient en effet des solutions d'escalabilité et des discussions communautaires des blockchains publiques telles que Bitcoin et Ethereum. Sa vision et son application pratique consistent à construire une nouvelle génération d'infrastructure sans confiance, voire des plateformes computationnelles non basées sur des structures de blockchain.

Composants de base et principes de fonctionnement de SCP

D’une manière générale, SCP, comme la « blockchain modulaire » mentionnée par les communautés Ethereum et Celestia, dispose de divers modules tels qu’une couche de disponibilité des données, une couche d’exécution, une couche de consensus et une couche de règlement.

• Couche de disponibilité des données: Gérée par une blockchain publique largement reconnue et bien testée, ou par des installations de stockage servant de couche de disponibilité des données, comme Ethereum, Arweave, Celestia, etc.

• Couche d'exécution: Un serveur, utilisé pour recevoir les transactions des utilisateurs et les exécuter, tout en soumettant également en lot les données de transaction signées à la couche DA, similaire aux séquenceurs dans les Rollups. Cependant, la couche d'exécution n'a pas nécessairement besoin d'une structure de chaîne de type blockchain; elle peut être entièrement un système de base de données Web2 + de calcul, mais l'ensemble du système de calcul doit être open source, avec transparence.

• Couche de consensus : Composée d'un groupe de nœuds qui récupèrent les données soumises à la couche DA par la couche d'exécution et utilisent le même algorithme que la couche d'exécution pour traiter ces données, confirmant si la sortie de la couche d'exécution est correcte et peut servir de redondance de récupération après sinistre pour la couche d'exécution. Les utilisateurs peuvent également lire les données renvoyées par les nœuds de la couche de consensus pour s'assurer qu'il n'y a pas de comportement frauduleux dans la couche d'exécution.

• Couche de règlement : Composée d'un groupe de nœuds et de contrats ou d'adresses sur d'autres chaînes, chargée de gérer les dépôts des utilisateurs dans SCP, ou les retraits de SCP, quelque peu similaire au fonctionnement des ponts inter-chaînes. Les nœuds de la couche de règlement contrôlent la fonction de retrait de l'adresse de dépôt via des contrats multisig ou des adresses basées sur la TSS. Pour les dépôts, les utilisateurs transfèrent des actifs à une adresse désignée sur leur chaîne ; pour les retraits, ils envoient une demande, et après que les nœuds de la couche de règlement aient lu les données, ils libèrent les actifs via des contrats multisig ou la TSS. Le niveau de sécurité de la couche de règlement dépend du mécanisme inter-chaînes utilisé.

Cadre de pratique SCP

Nous pouvons comprendre le paradigme SC à travers le cadre suivant. Un produit qui répond au cadre SC peut avoir des fonctionnalités principales telles que le dépôt, le transfert, le retrait, l'échange, etc., et peut être encore étendu. Voici un diagramme schématique d'un tel produit :

• La couche DA de ce projet utilise l'installation de stockage permanente Arweave, représentée par le grand cercle dans le diagramme.
• Le Coordinateur, ou la couche d'exécution, est l'endroit où les utilisateurs soumettent leurs transactions. Le Coordinateur effectue des calculs, affiche les résultats, puis regroupe les données d'entrée d'origine des utilisateurs et les soumet à la couche DA.
• Le Détecteur extrait les données de transaction originales soumises par le Coordinateur à partir d'Arweave, et en utilisant le même algorithme que le Coordinateur, valide les données et les résultats. Le client du Détecteur est également open source, permettant à quiconque de l'exécuter.
• Les Gardiens, un groupe de Détecteurs, gèrent le système multi-signature du système de retrait. Ils valident et autorisent les demandes de retrait en fonction des données de transaction. De plus, les Gardiens sont responsables de la signature des propositions.

Nous pouvons voir que le consensus atteint par l'ensemble du système est entièrement hors chaîne, ce qui est au cœur du paradigme de consensus de stockage. Il abandonne le système de consensus des nœuds typique des blockchains, libérant la couche d'exécution du processus de consensus et de confirmation fastidieux. Cela lui permet de fonctionner efficacement comme un seul serveur, permettant ainsi d'atteindre un TPS pratiquement illimité et une rentabilité. Cet aspect est très similaire aux Rollups, mais le SCP (Paradigme de Consensus de Stockage) prend un chemin différent des Rollups. Le SCP tente de passer d'un cas d'utilisation spécifique à l'échelle à un nouveau mode de transition de Web2 à Web3. Le Coordinateur mentionné précédemment est un serveur, mais cela ne signifie pas que le Coordinateur peut agir arbitrairement. Tout comme le séquenceur dans les Rollups, après avoir soumis par lots les données d'origine des utilisateurs sur Arweave, n'importe qui peut exécuter le programme Detector pour le vérifier et le comparer à l'état renvoyé par le Coordinateur. À certains égards, cela ressemble à l'approche des applications de type inscription. Dans cette architecture, un serveur centralisé ou une base de données ne pose pas de défi fondamental. C'est un autre point du paradigme SCP : il découple les concepts de “centralisation” et “entité unique” — dans un système sans confiance, il peut y avoir des composants centralisés, même un composant central, sans affecter le caractère sans confiance global du système.

Nous pouvons crier ce slogan : “La prochaine génération d'infrastructure sans confiance ne doit pas nécessairement reposer sur des protocoles de consensus, mais elle doit être un système open-source avec un réseau de nœuds Peer-to-Peer (P2P). L'intention initiale d'inventer et d'utiliser la blockchain était d'atteindre la décentralisation, la cohérence du grand livre, l'immutabilité et la traçabilité, comme explicitement indiqué dans le livre blanc de Bitcoin. Cependant, post-Éthereum, que ce soit les solutions d'expansion des anciennes chaînes publiques, les Rollups ou les blockchains modulaires, il y a eu un état d'esprit fixe : ce que nous créons doit soit être une blockchain (composée de protocoles de consensus des nœuds) soit quelque chose comme Rollup (qui semble être une chaîne avec des structures de données de blockchain, mais sans échanges de messages de consensus directs entre les nœuds). Maintenant, dans le cadre basé sur SCP (Stellar Consensus Protocol), il est évident que même sans être une blockchain, il est possible d'atteindre la décentralisation, la cohérence du grand livre, l'immutabilité et la traçabilité, à condition qu'il y ait plus de détails d'implémentation explicites.

Couche d'exécution

La couche d'exécution est cruciale dans l'ensemble du système car elle prend en charge les processus de calcul du système et détermine les types d'applications pouvant s'exécuter sur le système.

Infinies possibilités dans l'environnement d'exécution

Théoriquement, l'environnement d'exécution dans la couche d'exécution peut prendre n'importe quelle forme, avec des possibilités infinies, en fonction de la manière dont les développeurs du projet positionnent leur projet :

1. Échanges. En utilisant SCP, on peut construire un échange public et transparent avec des taux élevés de transactions par seconde (TPS), combinant les caractéristiques rapides et sans frais d'un échange centralisé (CEX) et la décentralisation d'un échange décentralisé (DEX). Ici, la distinction entre CEX et DEX devient floue.

2. Réseaux de paiement. Similaire à Alipay, PayPal, etc.

3. Machines virtuelles/Blockchains supportant des programmes/contrats chargeables. Tout développeur peut déployer n'importe quelle application dessus, partageant toutes les données utilisateur avec d'autres programmes et fonctionnant selon les instructions de l'utilisateur.

Le motif de conception de SCP, qui prend en charge n'importe quel environnement d'exécution, présente des avantages uniques : il n'est pas nécessaire de se fier à des composants avec des bagages historiques, en particulier des concepts comme l'abstraction de compte unique à la communauté Ethereum. Pour SCP, le concept d'abstraction de compte est intrinsèquement inutile. Dans l'architecture de SCP, il n'y a pas de concept d'abstraction de compte - vous pouvez librement adopter des comptes standard Web2 et des comptes de blockchain, etc. De ce point de vue, de nombreux cas d'utilisation Web2 matures n'ont pas besoin d'être repensés et reconstruits pour être directement applicables à SCP. Cet aspect pourrait être là où SCP a un avantage sur les Rollups.

Transparence et Asymétrie

Le système de compte a été mentionné ci-dessus, et les lecteurs perspicaces ont peut-être remarqué que, bien que le SCP (Stellar Consensus Protocol) puisse utiliser le système de compte Web2, l'utiliser tel quel semble problématique. Cela est dû au fait que tout le système est complètement transparent ! L'emploi direct du modèle d'interaction utilisateur-serveur de Web2 entraîne de graves problèmes de sécurité, rendant le système totalement insécurisé. Examinons comment fonctionne le modèle traditionnel serveur-utilisateur :

1. Inscription au compte : Les utilisateurs saisissent un nom d'utilisateur et un mot de passe sur la page d'inscription de l'application. Pour protéger le mot de passe de l'utilisateur, le serveur le traite à travers une fonction de hachage lors de sa réception. Pour augmenter la complexité du hachage et se défendre contre les attaques de tables arc-en-ciel, une chaîne générée de manière aléatoire (appelée "sel") est généralement ajoutée à chaque mot de passe de l'utilisateur avant le hachage. Le nom d'utilisateur, le sel et le hachage sont stockés en texte clair dans la base de données du fournisseur de services et ne sont pas rendus publics. Cependant, même ainsi, le salage et le traitement sécurisé sont nécessaires pour prévenir les menaces internes et les attaques.

1. Connexion de l'utilisateur : Les utilisateurs saisissent leur nom d'utilisateur et leur mot de passe dans le formulaire de connexion. Le système compare le hachage du mot de passe traité avec le hachage stocké dans la base de données. Si les deux hachages correspondent, cela indique que l'utilisateur a fourni le bon mot de passe et le processus de connexion se poursuit.

2. Authentification de l'opération : Après une vérification de connexion réussie, le système crée une session pour l'utilisateur. En général, les informations de session sont stockées sur le serveur, et le serveur envoie un identifiant (tel qu'un cookie ou un jeton) au navigateur ou à l'application de l'utilisateur. Lors des opérations ultérieures, les utilisateurs n'ont plus besoin de saisir à plusieurs reprises leur nom d'utilisateur et leur mot de passe : le navigateur ou l'application enregistre l'identifiant du cookie et l'inclut dans chaque requête, indiquant qu'ils ont l'autorisation du serveur associée au cookie.

Passons en revue le système d'interaction typique entre l'utilisateur de la blockchain Web3 :

1. Enregistrement du compte : En réalité, il n'y a pas de processus d'enregistrement de compte, ni de système de nom d'utilisateur et de mot de passe. Les comptes (adresses) n'ont pas besoin d'être enregistrés ; ils existent de manière inhérente, et celui qui contrôle la clé privée contrôle le compte. La clé privée est générée de manière aléatoire localement par le portefeuille et ne nécessite pas de processus en ligne.

2. Connexion de l'utilisateur : Utiliser la blockchain ne nécessite pas de se connecter. La plupart des dApps n'ont pas de processus de connexion mais se connectent plutôt à un portefeuille. Certaines dApps, après s'être connectées à un portefeuille, peuvent exiger que les utilisateurs signent une vérification pour s'assurer qu'ils détiennent effectivement la clé privée, plutôt que d'avoir simplement soumis une adresse de portefeuille à l'interface utilisateur.

3. Authentification de l'opération : Les utilisateurs soumettent directement des données signées aux nœuds. Après validation, les nœuds diffusent la transaction à l'ensemble du réseau blockchain. Une fois que l'opération est confirmée par le consensus du réseau blockchain, elle est finalisée.

La différence entre ces deux modes est causée par des facteurs symétriques et asymétriques. Dans une architecture serveur-utilisateur, les deux parties détiennent le même secret. Dans une architecture blockchain-utilisateur, seul l'utilisateur détient le secret. Bien que la couche d'exécution de la SCP (Plateforme de Contrat Intelligent) puisse ne pas être une blockchain, toutes les données doivent être synchronisées vers une couche DA (Disponibilité des Données) publiquement visible. Par conséquent, les méthodes de connexion et de vérification des opérations de la SCP doivent être asymétriques. Cependant, pour éviter des actions complexes telles que la gestion des clés privées et l'utilisation de portefeuilles, qui pourraient entraver l'adoption généralisée en raison d'une mauvaise expérience utilisateur, il existe une forte demande pour des connexions d'authentification tierces traditionnelles ID-mot de passe ou OAuth dans les applications construites sur la SCP. Alors, comment combinons-nous les deux? En raison de la nature asymétrique de la cryptographie et des preuves à divulgation nulle, j'envisage deux solutions possibles :

• Si un système d'identification par mot de passe est souhaité, le module de sauvegarde de mot de passe pourrait être exclu de SCP, le rendant invisible aux autres. En interne, la couche d'exécution SCP utilise toujours les comptes clés publics-privés de la blockchain et la logique opérationnelle, sans inscription ni connexion. L'identifiant de l'utilisateur correspondrait en fait à une clé privée. Cette clé privée, bien sûr, ne devrait pas être stockée par le projet. Une solution réalisable consiste à utiliser 2-3 MPC (Calcul multipartite) pour résoudre le problème de stockage centralisé sans alourdir l'utilisateur avec l'utilisation d'une clé privée.
• Lorsqu'il s'agit de s'appuyer sur la connexion OAuth, JWT (JSON Web Token) peut être utilisé comme moyen d'authentification de l'identité. Cette méthode est légèrement plus centralisée que la précédente, car elle repose essentiellement sur les services de connexion de tiers fournis par les géants du Web2 pour la vérification de l'identité.
• La première fois qu'une connexion de tierce partie est utilisée, les champs JWT représentant les identités de l'utilisateur et du fournisseur de services sont enregistrés dans le système. Lors des opérations ultérieures de l'utilisateur, la commande d'opération est traitée comme une entrée publique, tandis que le JWT dans son ensemble est un témoin secret, utilisant ZKP (preuve de connaissance nulle) pour vérifier chacune des transactions de l'utilisateur.
• Chaque JWT a une limite d'expiration, et les utilisateurs demanderont un nouveau JWT la prochaine fois qu'ils se connecteront, donc il n'est pas nécessaire de stocker de manière permanente. De plus, ce système repose sur JWK (JSON Web Key), qui peut être compris comme la clé publique fournie par les géants pour la vérification JWK. Comment JWK est entré de manière décentralisée dans le système et les méthodes pour la rotation future de la clé privée valent également la peine d'être explorées.

Peu importe la méthode utilisée, les deux sont plus coûteux en termes de développement et d'exploitation que les méthodes traditionnelles, mais c'est un prix nécessaire à payer pour la décentralisation. Bien sûr, si le projet ne considère pas l'extrême décentralisation comme nécessaire, ou s'il a des jalons différents à différentes étapes de développement, il est possible de procéder sans ces conceptions, car la décentralisation n'est pas une question de noir ou blanc mais existe dans une zone grise.

Problèmes de confidentialité

Les problèmes de transparence mentionnés ci-dessus n'affectent pas seulement le paradigme d'interaction utilisateur, mais ont également un impact sur les données utilisateur. Les données utilisateur sont directement exposées. Même si cela ne pose pas de problème dans la blockchain, cela est inacceptable dans certaines applications. Par conséquent, les développeurs peuvent également construire des systèmes de transaction privée.

Frais

Comment la couche d'exécution facture les frais est un autre point d'intérêt. Soumettre des données à la couche de disponibilité des données (DA) entraîne également des coûts, y compris le fonctionnement de ses propres serveurs. Le but principal de facturer des frais de gaz dans les blockchains traditionnelles est d'empêcher les utilisateurs de saturer le réseau avec de nombreuses transactions redondantes, la commande des transactions en fonction des frais de gaz étant secondaire. En Web2, des préoccupations similaires n'existent pas, seuls des concepts de base tels que les inondations et les attaques DDoS. La couche d'exécution peut personnaliser diverses stratégies de facturation, telles que être totalement gratuite ou partiellement facturée, ou tirer profit d'autres activités telles que la Valeur Maximale Extractible (MEV), qui est déjà très mature dans les séquenceurs, et les activités de marché.

Résistance à la censure

La couche d'exécution ne possède pas de résistance à la censure et peut théoriquement rejeter indéfiniment les transactions des utilisateurs. Dans les Rollups, la résistance à la censure peut être assurée par la fonction d'agrégation obligatoire du contrat L1, tandis que les sidechains ou les chaînes publiques sont des réseaux blockchain distribués complets, rendant la censure difficile. Actuellement, il n'existe pas de solution claire pour résoudre le problème de la résistance à la censure, qui est un problème dans le paradigme SCP.

Couche de consensus

Cette couche se compose de nœuds vaguement connectés qui ne forment pas activement un réseau, il ne s’agit donc pas strictement d’une couche de consensus, mais confirme simplement l’état actuel de la couche d’exécution au monde extérieur (comme les utilisateurs). Par exemple, si vous doutez de l’état de fonctionnement de ces nœuds, vous pouvez télécharger leur client détecteur, qui exécute le même code de programme que le coordinateur. Cependant, comme pour les cumuls, étant donné que les données sont soumises par lots, l’état renvoyé par la couche d’exécution aux utilisateurs est toujours plus à jour que celui de la couche DA. Cela implique la question de la pré-confirmation : la couche d’exécution fournit aux utilisateurs des résultats de pré-confirmation, de finalité douce, car ils n’ont pas encore été soumis à la couche DA ; tandis que la couche de consensus fournit une finalité dure. Les utilisateurs ne sont peut-être pas particulièrement préoccupés par cela, mais pour des applications telles que les ponts inter-chaînes, la finalité stricte doit être respectée. Par exemple, le système de dépôt et de retrait des exchanges ne fait pas confiance aux données diffusées hors chaîne par les séquenceurs Rollup ; ils attendent que ces données soient sur Ethereum avant de les accepter. En plus de confirmer les résultats, la couche de consensus joue également un rôle crucial en tant que redondance après sinistre pour la couche d’exécution. Si la couche d’exécution cesse définitivement de fonctionner ou agit de manière malveillante, théoriquement, n’importe quelle couche de consensus peut prendre en charge le travail de la couche d’exécution et accepter les demandes des utilisateurs. Si une situation aussi grave se produit, la communauté doit choisir des nœuds stables et fiables comme serveurs de la couche d’exécution.

Couche de règlement

Étant donné que SCP n'est pas un Rollup, il ne peut pas réaliser des retraits sans confiance comme la couche de règlement des retraits de Rollup, qui est entièrement basée sur la cryptographie et le code de contrat intelligent sans intervention manuelle. Le niveau de sécurité des ponts inter-chaînes de SCP est le même que celui des ponts inter-chaînes de sidechain ou de témoin tiers, qui reposent sur des gestionnaires multi-signatures autorisés pour libérer des actifs, connus sous le nom de mode témoin.

Rendre le pont témoin aussi décentralisé que possible est un sujet de recherche pour de nombreux ponts inter-chaînes. En raison de limitations d'espace, cela ne sera pas élaboré ici. Une plateforme SCP bien conçue en pratique doit également avoir des partenaires réputés de signatures multiples de pont décentralisé. Certains pourraient demander pourquoi SCP n'utilise pas une chaîne avec des contrats intelligents comme couche DA ? Cela permettrait des couches de règlement sans confiance basées sur des contrats. À long terme, en surmontant certaines difficultés techniques, si la couche DA est placée sur Ethereum ou d'autres couches DA activées par des contrats et que des contrats de vérification correspondants peuvent être construits, SCP peut également atteindre la même sécurité de règlement que Rollup, sans avoir besoin de signatures multiples.

En pratique, ce n'est peut-être pas le meilleur choix :

1. Ethereum n'est pas spécifiquement conçu pour le stockage de données, et par rapport aux blockchains dédiées uniquement au stockage de données, il est assez cher. Pour le paradigme SCP, un coût de stockage suffisamment faible ou fixe est crucial. Seulement ainsi peut-il soutenir un débit de niveau Web2.

2. Le développement de systèmes de preuve est extrêmement difficile car, dans SCP, on peut simuler non seulement l'EVM (Ethereum Virtual Machine) mais aussi implémenter toute logique. En considérant l'état actuel de projets comme Optimism, où leurs preuves de fraude ne sont toujours pas lancées, et la complexité du développement de zkEVM (Ethereum Virtual Machine à connaissance nulle), on peut imaginer l'immense difficulté à implémenter divers systèmes de preuve sur Ethereum.

Par conséquent, la solution Rollup n'est pratiquement viable que dans des circonstances spécifiques. Si vous prévoyez de mettre en œuvre un système plus large et plus ouvert, en vous éloignant du cadre EVM pour intégrer davantage de fonctionnalités Web2, alors l'approche d'Ethereum Rollup n'est pas adaptée. SCP n'est pas seulement un plan d'expansion pour une certaine blockchain publique, mais une architecture de plateforme informatique Web3 plus large. Par conséquent, il n'a clairement pas besoin de suivre l'approche de la couche 2 d'Ethereum.

Une illustration compare SCP avec d'autres paradigmes

Avertissement：

1. Cet article est repris de [ Web3 Geek]. Tous les droits d'auteur appartiennent à l'auteur original [Misty, geek Web3]. Si des objections sont faites à cette réimpression, veuillez contacter le Porte Apprendreéquipe et ils s'en occuperont rapidement.
2. Clause de non-responsabilité: Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent pas un conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.