Interprétation de SCP : paradigme de l’infrastructure sans confiance en dehors de la formule de cumul

Auteur : Wuyue, Geek Web3

**Introduction :**Cet article introduira de manière prospective un paradigme de conception d’infrastructure Web3 qui semble un peu non-conformiste - Storage Consensus Paradigm SCP (Storage-based Consensus Paradigm), bien que ce modèle de conception de produit soit théoriquement assez différent des solutions Blockchain modulaires grand public telles que Ethereum Rollup, mais dans la simplicité d’atterrissage et la difficulté de se connecter à la plate-forme Web2, la faisabilité est très élevée Parce qu’il n’avait pas l’intention de se limiter à un chemin de mise en œuvre étroit comme Rollup dès le début, il voulait utiliser un cadre plus large et plus ouvert pour fusionner la plate-forme Web2 avec l’infrastructure Web3, ce qui peut être considéré comme une approche d’ouverture de cerveau et d’imagination. Introduction : Cet article présentera de manière prospective un paradigme de conception d’infrastructure Web3 quelque peu non-conformiste - Storage Consensus Paradigm (SCP) Bien que ce modèle de conception de produit soit théoriquement assez différent des solutions modulaires Blockchain traditionnelles telles que Ethereum Rollup, il est tout à fait réalisable en termes de simplicité de mise en œuvre et de difficulté à se connecter aux plateformes Web2, car il n’a pas l’intention de se limiter à un chemin de mise en œuvre étroit comme Rollup dès le début, et souhaite intégrer la plate-forme Web2 et les installations Web3 avec un cadre plus large et plus ouvert, ce qui peut être considéré comme une approche d’ouverture de cerveau et d’imagination.

Corps : Imaginons un schéma de mise à l’échelle de la chaîne publique avec les caractéristiques suivantes :

• Il a une vitesse comparable aux applications ou échanges Web2 traditionnels, dépassant de loin toute chaîne publique, L2, rollup, sidechain, etc.
• Il n’y a pas de frais de gaz et le coût d’utilisation est presque nul.
• Haute sécurité des fonds, bien au-delà des installations centralisées telles que les échanges, inférieure à Rollup mais supérieure ou égale à Sidechain.
• Même expérience utilisateur que le Web2, sans aucune connaissance des clés publiques et privées de la Blockchain, des portefeuilles, de l’infrastructure, etc.

Cette solution est en effet très intéressante : d’une part, elle a atteint le summum de la mise à l’échelle et, d’autre part, elle a jeté des bases solides sur l’adoption massive du Web3, éliminant essentiellement l’écart entre le Web2 et l’expérience Web3.

Cependant, nous ne semblons pas pouvoir penser à beaucoup de solutions qui peuvent être aussi complètes, parce qu’il y a vraiment trop peu de discussions et de pratiques traditionnelles.

Nous avons utilisé le sujet très familier de la mise à l’échelle comme introduction ci-dessus, en fait, **SCP ne se limite pas à la mise à l’échelle, **son inspiration de conception vient de Bitcoin, Ethereum et d’autres solutions de mise à l’échelle de chaînes publiques et de discussions communautaires. Sa vision et son application pratique sont de construire une nouvelle génération d’infrastructure Trustless et même une plate-forme informatique avec une structure non-Blockchain. **

Les composants de base SCP et leur fonctionnement

D’une manière générale, SCP s’apparente également à ce que les communautés Ethereum et Celestia appellent une « Blockchain modulaire », avec une couche de disponibilité des données, une couche d’exécution, une couche de consensus, une couche de règlement et d’autres modules.

Couche de disponibilité des données : Entreprise par une chaîne publique largement reconnue et éprouvée, ou par des installations de stockage en tant que couche de disponibilité des données, telles qu’Ethereum, Arweave, Celestia, etc. Couche d’exécution : serveur qui reçoit et exécute les transactions des utilisateurs et soumet les données de transaction signées par les utilisateurs à la couche DA par lots, similaire au séquenceur de Rollup. Cependant, la couche d’exécution n’a pas besoin d’avoir une structure de liste chaînée de type Blockchain, elle peut être complètement Web2 base de données + système informatique, mais l’ensemble du système informatique doit être open source et transparent. Couche de consensus : il s’agit d’un groupe de nœuds qui extraient 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 calculer les données afin de confirmer si la sortie de résultat de la couche d’exécution est correcte et peut être utilisée comme redondance de prévention des sinistres de la couche d’exécution. Les utilisateurs peuvent également lire les données renvoyées par chaque nœud de la couche Consensus pour s’assurer qu’il n’y a pas de fraude dans la couche d’exécution. Couche de règlement : se compose d’un groupe de nœuds et d’autres contrats ou adresses sur la chaîne, qui est utilisé pour traiter le comportement des utilisateurs qui déposent dans SCP ou se retirent de SCP, un peu similaire au mode de fonctionnement des ponts d’interaction inter-chaînes. Le nœud de la couche de règlement contrôle la fonction de retrait de l’adresse de dépôt par le biais du contrat multi-signature ou de l’adresse basée sur TSS. Lors du dépôt, l’utilisateur dépose des actifs à l’adresse spécifiée de la chaîne, envoie une demande lors du retrait et le nœud de la couche de règlement lit les données et libère les actifs via multisig ou TSS. Le degré de sécurité de la couche de règlement dépend du mécanisme d’interaction inter-chaînes adopté.

Cadre de pratique de SCP

Le paradigme SCP peut être compris à travers le cadre suivant. Un produit qui satisfait au cadre SCP peut avoir des fonctions majeures telles que des dépôts, des transferts, des retraits, des swaps, etc., et peut être étendu sur cette base. Le schéma suivant est un schéma d’un tel produit :

• La couche DA du projet utilise l’installation de stockage permanente Arweave, qui est le grand cercle du diagramme. Coordinateur, c’est-à-dire la couche d’exécution. **L’utilisateur soumet la transaction au coordinateur, qui effectue le calcul et présente le résultat, puis soumet les données d’entrée d’origine de l’utilisateur à la couche DA par lots. Detector, qui extrait les données brutes de transaction soumises par le coordinateur à partir d’Arweave et valide les données et les résultats à l’aide d’un algorithme cohérent avec le coordinateur. Le client du détecteur est également open source et peut être exécuté par n’importe qui.
• **Watchmen, un groupe de détecteurs qui sont en charge de la multi-signature du système de retrait. **Les demandes de retrait sont validées et validées en fonction des données de transaction. De plus, le gardien est également responsable de la signature de la proposition.

Nous pouvons voir l’ensemble du système, et le consensus qu’ils atteignent est entièrement hors chaîne, ce qui est le cœur du paradigme du consensus de stockage - il abandonne le système NodeConsensus de style Blockchain, et permet à la couche d’exécution de se débarrasser du lourd processus de communication et de confirmation du consensus, et n’a besoin que de faire le travail d’un serveur, afin d’obtenir un TPS et une économie presque illimités. C’est très similaire à Rollup, mais SCP a pris un chemin différent de Rollup, en essayant de passer d’un cas d’utilisation spécifique à l’échelle à un nouveau modèle de transition du Web2 vers le Web3. **

Le coordinateur mentionné ci-dessus est un serveur, mais cela ne signifie pas qu’il peut faire ce qu’il veut. Semblable au séquenceur de Rollup, après avoir soumis des données brutes soumises par l’utilisateur à Arweave par lots, n’importe qui peut exécuter un programme de test pour les vérifier et les comparer à l’état renvoyé par le coordinateur. Dans une certaine mesure, c’est la même idée que l’application d’inscriptions. **

Dans cette architecture, un serveur ou une base de données centralisée ne pose pas de problème fondamental. C’est un autre point du paradigme SCP, qui lie et dissocie les deux concepts de « centralisation » et d’"entité unique » - ** dans un système sans confiance, il peut y avoir des composants centralisés, ** même un composant de base, mais cela n’affecte pas l’ensemble des systèmes sans confiance.

Nous pouvons crier un tel slogan : « La prochaine génération d’infrastructures sans confiance n’a pas besoin de s’appuyer sur des protocoles de consensus, mais devrait être constituée de systèmes open source et de réseaux de nœuds P2P ».

L’intention initiale des gens d’inventer et d’utiliser la blockchain est de faire confiance, le grand livre est cohérent, infalsifiable, traçable et d’autres fondamentaux clichés, qui sont clairement énoncés dans le livre blanc Bitcoin. Mais après Ethereum, qu’il s’agisse du schéma de mise à l’échelle de l’ancienne chaîne publique, ou du Rollup ou de la Blockchain modulaire, tout le monde s’est formé un état d’esprit : ce que nous faisons doit être une Blockchain (composée du protocole de consensus du nœud), ou un Rollup, qui semble être une solution en chaîne (sauf qu’il existe une structure de données Blockchain, mais le nœud n’a pas d’échange direct de messages de consensus).

Mais maintenant, sur la base du cadre de SCP, même s’il ne s’agit pas d’une Blockchain, une série d’exigences telles que le registre cohérent et sans confiance, la non-falsification, la traçabilité, etc. peuvent être réalisées, bien sûr, la prémisse est qu’il y a des détails de mise en œuvre plus clairs.

Couche d’exécution

La couche d’exécution est cruciale dans l’ensemble du système, elle entreprend le processus de calcul de l’ensemble du système et détermine également le type d’applications qui peuvent être exécutées sur le système.

Environnement d’exécution infini possible

Théoriquement, l’environnement d’exécution dans la couche d’exécution peut être créé sous n’importe quelle forme, et les possibilités sont infinies, en fonction de la façon dont l’équipe de projet positionne son projet :

*Échange. Sur la base de SCP, un échange ouvert, transparent et à haut TPS peut être construit, qui peut avoir les caractéristiques d’une vitesse CEX et d’un coût nul, tout en maintenant la décentralisation du DEX. La distinction entre les CEX et les DEX s’estompe ici.

• Réseau de paiement. Similaire à Alipay, PayPal, etc.
• Prise en charge des machines virtuelles/chargeurs Blockchain/contrats. N’importe quel développeur peut y déployer n’importe quelle application, partager toutes les données utilisateur avec d’autres programmes et fonctionner selon les instructions de l’utilisateur.

SCP, un modèle de conception qui prend en charge des environnements d’exécution arbitraires, a ses propres avantages uniques : il n’a plus besoin de s’appuyer sur certains composants avec un bagage historique, en particulier le concept d’« abstraction de compte » créé par la communauté Ethereum, ce qui est intrinsèquement indésirable pour SCP.

Dans l’architecture SCP, il n’y a pas de concept d’abstraction de compte - vous pouvez librement adopter les comptes standard Web2 et les comptes Blockchain. De ce point de vue, de nombreux cas d’utilisation matures du Web2 n’ont pas besoin d’être repensés et construits pour fonctionner directement sur SCP. C’est peut-être l’avantage des SCP par rapport aux cumuls. **

Transparence et asymétrie

Le système de compte mentionné ci-dessus, et les lecteurs sensibles auraient dû remarquer que bien que SCP puisse tirer parti du système de compte de Web2, il semble être problématique de l’utiliser tel quel.

Étant donné que l’ensemble du système est totalement transparent, l’utilisation directe du modèle d’interaction utilisateur-serveur causera de graves problèmes, ce qui n’entraînera aucune sécurité. Passons en revue le fonctionnement du modèle traditionnel serveur-utilisateur :**

1. Enregistrement du compte : L’utilisateur saisit le nom d’utilisateur et le mot de passe sur la page d’inscription de l’application. Afin de protéger le mot de passe de l’utilisateur, le serveur traitera le mot de passe via une fonction de hachage après l’avoir reçu. Pour augmenter la complexité du hachage et se défendre contre les attaques de table arc-en-ciel, le mot de passe de chaque utilisateur est généralement connecté à une chaîne de chaînes générée de manière aléatoire (appelée « sels ») et haché ensemble. **Les noms d’utilisateur, les sels, les hachages sont stockés en clair dans la base de données du fournisseur de services et ne sont pas accessibles au public. Mais même ainsi, il est nécessaire d’ajouter du sel et un traitement sûr, l’un pour prévenir les fantômes internes et l’autre pour prévenir les attaques.

2. Connexion de l’utilisateur : Les utilisateurs saisissent leur nom d’utilisateur et leur mot de passe sur le formulaire de connexion. Le système compare le hachage du mot de passe traité avec la valeur de hachage stockée dans la base de données. Si les deux hachages correspondent, ce qui indique que l’utilisateur a fourni le mot de passe correct, le processus de connexion se poursuit.

3. Authentification de l’opération : Une fois la vérification de la connexion réussie, le système créera une session pour l’utilisateur. En règle générale, les informations de session sont stockées sur un serveur et le serveur envoie un identifiant (par exemple, ou un jeton) au navigateur ou à l’application de l’utilisateur. L’utilisateur n’a plus besoin de saisir à nouveau le nom d’utilisateur et le mot de passe pour l’étape suivante : le navigateur ou l’application enregistre l’identifiant et joint un identifiant à chaque requête, indiquant qu’il dispose de l’autorisation du serveur associé.

Passons en revue le système typique d’interaction Web3 Blockchain-utilisateur :

1. Enregistrement du compte : Il n’y a pratiquement aucun processus d’enregistrement de compte et il n’y a pas de système de nom d’utilisateur et de mot de passe. Le compte (adresse) ne nécessite pas d’enregistrement, il existe naturellement, et celui qui détient sa clé privée contrôle le compte. La clé privée est générée localement de manière aléatoire par le portefeuille et n’implique pas le processus de mise en réseau.

2. Connexion de l’utilisateur : L’utilisation de la Blockchain ne nécessite pas de connexion, et la plupart des dApps n’ont pas le processus de connexion, mais se connectent au Wallet. Certaines dApps demanderont aux utilisateurs de signer et de vérifier après s’être connectés au portefeuille pour s’assurer que l’utilisateur détient vraiment la clé privée, plutôt que de simplement transmettre une adresse de portefeuille au frontend.

3. Authentification de l’opération : L’utilisateur soumet directement les données signées au nœud, et le nœud diffusera la transaction à l’ensemble du réseau Blockchain après vérification, et l’opération de l’utilisateur sera confirmée après avoir rencontré le consensus du réseau Blockchain.

La différence entre les deux modes est causée par la symétrie et l’asymétrie. Dans une architecture serveur-utilisateur, les deux parties détiennent les mêmes secrets. Dans l’architecture Blockchain-User, seul l’utilisateur détient les secrets.

Bien que la couche d’exécution de SCP ne puisse pas être une Blockchain, toutes les données doivent être synchronisées avec la couche DA visible publiquement, de sorte que la méthode d’authentification de connexion et d’opération utilisée par SCP doit être asymétrique. Cependant, étant donné que nous ne voulons pas avoir d’actions fastidieuses et une mauvaise expérience qui affectent l’adoption de masse, comme permettre aux utilisateurs de conserver des clés privées et d’utiliser des portefeuilles, les applications basées sur SCP ont également un fort besoin d’utiliser des mots de passe d’identification traditionnels ou des connexions d’authentification à trois doigts OAuth, alors comment combiner les deux ?

En raison de la nature asymétrique de la cryptographie asymétrique et des paires de preuves à divulgation nulle de connaissance, j’envisage deux scénarios possibles :

• Si vous souhaitez utiliser le système ID-mot de passe, vous pouvez laisser ce module de stockage de mot de passe en dehors du SCP, afin que personne d’autre ne puisse le voir. La couche d’exécution SCP utilise toujours les comptes à clés publiques et privées et la logique d’opération de la Blockchain, sans inscription, connexion, etc. L’identifiant de l’utilisateur correspond en fait à une clé privée. **Bien sûr, cette clé privée ne peut pas être conservée côté projet, et la solution la plus réalisable est d’utiliser 2-3 MPC pour résoudre le problème du stockage centralisé, tout en ne permettant pas aux utilisateurs d’utiliser la clé privée. Lorsque vous vous appuyez sur la connexion OAuth, JWT (Json Web Token) peut être utilisé comme moyen d’authentification. **Cette méthode sera légèrement plus centralisée que la précédente, car elle doit essentiellement s’appuyer sur le service de connexion tiers fourni par les fabricants Web2 comme authentification d’identité.

• Lorsque vous vous connectez avec un tiers pour la première fois, enregistrez les champs dans le JWT qui représentent l’identité de l’utilisateur et l’identité du fournisseur de services dans le système. Dans les opérations ultérieures de l’utilisateur, l’instruction d’opération est utilisée comme entrée publique, et le JWT dans son ensemble est utilisé comme témoin secret pour vérifier la transaction de chaque utilisateur avec ZKP.

Chaque JWT a une date d’expiration, et les utilisateurs demanderont un nouveau JWT la prochaine fois qu’ils se connecteront, il n’est donc pas nécessaire de le conserver pour toujours. De plus, ce système doit également s’appuyer sur JWK, qui peut être compris comme la clé publique fournie par la grande usine pour vérifier JWK. Ainsi, comment introduire la décentralisation JWK dans le système, et comment gérer la rotation des clés privées à l’avenir, valent également la peine d’être explorés.

Quoi qu’il en soit, elle est plus coûteuse à développer et à calculer que les méthodes traditionnelles, mais c’est aussi un prix nécessaire à payer pour la décentralisation. Bien sûr, si l’équipe de projet ne croit pas que la décentralisation ultime est nécessaire, ou s’il y a différents jalons à différents stades de développement, il n’y a pas de mal à avoir ces conceptions, car la décentralisation n’est pas noire ou blanche, mais il y a une zone grise au milieu.

Confidentialité

Les problèmes de transparence évoqués ci-dessus ont un impact non seulement sur le paradigme d’interaction de l’utilisateur, mais aussi sur les données de l’utilisateur. Les données de l’utilisateur sont directement exposées. Bien que ce ne soit pas un problème dans la Blockchain, ce n’est pas très acceptable dans certaines applications, de sorte que les développeurs peuvent également construire des systèmes de transaction privés.

Charge

La façon dont la couche d’exécution se charge est un autre point de préoccupation. En effet, il existe également des coûts associés à la soumission de données à la couche DA, y compris le fonctionnement de ses propres serveurs. Le premier objectif principal de la blockchain traditionnelle pour facturer aux utilisateurs des frais de gaz est d’éviter que les utilisateurs ne glissent un grand nombre de transactions répétitives pour perturber le réseau de transactions, et le second est de trier les transactions en fonction du gaz. Le Web2 n’a pas de préoccupations similaires, il n’y a donc que des concepts de base comme les inondations et les attaques DDoS.

La couche d’exécution peut personnaliser diverses stratégies de charge, telles que la charge entièrement gratuite ou partielle, et peut également monétiser d’autres comportements tels que le MEV (qui est très mature dans le séquenceur), les activités marketing, etc.

Résistance à la censure

La couche d’exécution n’est pas résistante à la censure et peut théoriquement rejeter indéfiniment les transactions des utilisateurs. Dans Rollup, la résistance à la censure peut être garantie par la fonction d’agrégation forcée du contrat L1, tandis que la Sidechain ou la chaîne publique est un réseau Blockchain distribué complet, ce qui est également difficile à examiner.

**Il n’y a actuellement pas de solution claire au problème de la résistance à la censure, qui est un problème avec le paradigme SCP. **

Couche de consensus

Cette couche est composée de nœuds lâches, et ces nœuds ne forment pas activement le réseau, il ne s’agit donc pas strictement d’une couche de consensus, mais uniquement utilisée pour confirmer l’état actuel de la couche d’exécution au monde extérieur (comme les utilisateurs).

Par exemple, si vous avez des doutes sur l’état de santé 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. **

Toutefois, cela est similaire au cumul, car les données sont soumises par lots, la couche d’exécution renvoie toujours un état plus récent à l’utilisateur que la couche DA. Il s’agit d’un problème de pré-confirmation :

La couche d’exécution donne à l’utilisateur le résultat de la pré-confirmation et de la finalité douce, car elle n’a pas encore été soumise à la couche DA ;

** La couche Consensus fournit aux utilisateurs une finalité stricte. Les utilisateurs ne s’en soucient peut-être pas particulièrement, mais pour des applications telles que les ponts d’interaction inter-chaînes, la finalité stricte doit être respectée. Par exemple, le système de dépôt et de retrait de la plateforme d’échange ne fera pas confiance aux données diffusées par le sérialiseur Rollup hors chaîne, et devra attendre que ces données soient téléchargées sur Ethereum avant d’être reconnues.

En plus d’être utilisée pour confirmer les résultats, la couche Consensus joue également un rôle important, à savoir la redondance après sinistre en tant que couche d’exécution. **Si la couche d’exécution frappe de façon permanente et fait de graves dégâts, à ce moment-là, théoriquement, n’importe quelle couche de consensus peut prendre en charge le travail de la couche d’exécution et recevoir les demandes des utilisateurs. Si une situation aussi grave se produit, la communauté doit choisir un nœud stable et fiable comme serveur pour la couche d’exécution.

Couche de peuplement

Étant donné que SCP n’est pas un Rollup, il ne peut pas réaliser de retraits Trustless basés entièrement sur la cryptographie et le code des contrats intelligents sans intervention humaine comme la couche de règlement des retraits de Rollup. Les ponts d’interaction inter-chaînes SCP sont les mêmes que les ponts d’interaction inter-chaînes de témoins tiers ou side-chain, et doivent s’appuyer sur des gestionnaires multi-signatures autorisés pour libérer les ressources, ce que nous appelons le modèle témoin.

La décentralisation du pont témoin autant que possible fait l’objet de nombreuses études d’interaction inter-chaînes. En raison du manque de place, je ne m’étendrai pas là-dessus ici. Une plate-forme SCP bien conçue doit également avoir des partenaires multisig de Decentralization Bridge réputés dans la pratique.

On pourrait se demander pourquoi SCP n’utilise pas de chaînes avec des contrats intelligents comme couche DA ? Cela peut créer une couche de règlement qui donne des contrats et qui est complètement sans confiance.

À long terme, tant que certaines difficultés techniques sont surmontées, si la couche DA est placée sur une couche DA avec des contrats tels qu’Ethereum, et que le contrat de vérification correspondant peut être construit, SCP peut également obtenir la même sécurité de règlement que Rollup, sans avoir besoin d’utiliser la multi-signature.

Mais dans la pratique, ce n’est pas forcément optimal :**

1. Ethereum n’est pas spécifiquement utilisé pour la préservation des données, et le prix est trop élevé par rapport à la chaîne publique de stockage de données pure. Pour le paradigme SCP, un coût de stockage suffisamment faible ou fixe est crucial. Ce n’est qu’ainsi que le débit au niveau du Web2 peut être pris en charge.

2. Prouvez que le système est très difficile à développer, car SCP peut non seulement simuler l’EVM, mais aussi implémenter n’importe quelle logique. ** En regardant le fait que des équipes comme Optimism ne sont toujours pas en ligne pour les preuves de fraude, et la difficulté du développement de zkEVM, nous pouvons imaginer qu’il est extrêmement difficile d’implémenter les preuves de divers systèmes sur Ethereum.

Par conséquent, la solution Rollup n’est plus pratique que dans des situations spécifiques, et si vous envisagez de mettre en œuvre une approche plus large et plus ouverte qui s’éloigne du système EVM et se tourne vers davantage de fonctionnalités Web2, l’idée d’Ethereum Rollup n’est pas appropriée.

**SCP n’est pas un schéma de mise à l’échelle de la chaîne publique, mais une architecture de plate-forme informatique Web3 plus large, il n’est donc évidemment pas nécessaire de suivre l’idée de la couche 2 d’Ethereum. **

Un diagramme comparant SCP à d’autres paradigmes