Si nous pouvions remonter le temps aux premières discussions sur #Plasma ces années-là, il y avait en elle un sentiment très fort de "survie post-apocalyptique". Ce n'était pas la rugosité due à une technologie immature, mais une sorte de pessimisme conscient sur le plan de la philosophie de conception : nous partons du principe que les problèmes surviendront hors chaîne, que les opérateurs pourraient agir de manière malveillante, et que les données pourraient disparaître un jour. Ainsi, Plasma, depuis sa naissance, ne cherche pas à offrir une "expérience fluide" comme le fait Rollup, mais ressemble plutôt à un avertissement pour les utilisateurs - je ne peux pas garantir que tout fonctionnera normalement, mais je vous garantis que vous pouvez vous en échapper.
C'est aussi pourquoi j'ai toujours pensé que le Plasma des débuts ressemblait davantage à un "contrat de sauvetage". Vous confiez vos actifs à la chaîne Plasma, non pas parce que vous lui faites confiance pour fonctionner correctement indéfiniment, mais parce que vous croyez : même si tout s'effondre, vous avez une issue. Période de sortie, fenêtre de contestation, retraits forcés, nœuds de surveillance, ces mécanismes n'ont jamais été conçus pour être pratiques, mais pour sauver des vies. Ils ne servent pas l'efficacité, mais l'hypothèse du pire scénario.
Le problème est que ce type de conception semble décalé dans le récit actuel.
Blockchain modulaire, ordonnanceur partagé, couche de disponibilité des données, environnement d'exécution composé, les prémisses implicites derrière ces mots sont en fait : le système fonctionne à long terme, est fiable et peut être appelé de manière répétée. Il est difficile d'imaginer un module central qui rappelle aux utilisateurs chaque jour « n'oubliez pas d'être prêt à fuir à tout moment ». Dans ce contexte, Plasma semble à la fois démodé et inadapté.
Mais l'apparition du protocole #LEAP m'a fait sentir pour la première fois que Plasma n'est peut-être pas obsolète, mais qu'il a simplement été mal placé auparavant.
LEAP n'a pas essayé de transformer Plasma en Rollup. Il n'a pas réduit la période de sortie à quelques heures, ni forcé tous les états à entrer dans la couche de données du réseau principal. Au contraire, il reconnaît la nature de Plasma : exécution hors chaîne, arbitrage du réseau principal, en cas extrême, correction d'état via la sortie. Mais le changement clé est que LEAP ne considère plus Plasma comme un « système indépendant nécessitant une surveillance constante par les utilisateurs », mais l'intègre dans une structure de protocole plus grande et vérifiable.
Le changement ici n'est pas un ajustement technique mineur, mais un changement de rôle.
Dans LEAP, Plasma n'est plus une chaîne de deuxième niveau dans un récit complet, mais ressemble davantage à un module d'exécution. Il est responsable des opérations fréquentes, à faible coût et intensive en état, mais son existence est continuellement contrainte, engagée périodiquement et vérifiée de manière structurée par des protocoles externes. Vous pouvez l'imaginer comme un moteur placé dans un coffre-fort : le moteur peut encore s'arrêter, mais le coffre-fort lui-même est fiable.
Cela a directement changé la relation entre Plasma et les utilisateurs.
Auparavant, les utilisateurs faisaient face à #Plasma dans une relation de « je dois te comprendre ». Vous devez comprendre UTXO, comprendre l'arbre de Merkle, comprendre le processus de défi, sinon, en cas de problème, vous ne saurez même pas quand il faut fuir. Dans le contexte de LEAP, la plupart des utilisateurs ne font plus face directement à Plasma, mais à une interface abstraite fournie par le protocole supérieur. La sécurité de Plasma ne dépend plus principalement de la participation active des utilisateurs, mais plutôt des contraintes de composition entre les protocoles.
C'est très crucial.
Cela signifie que la « logique d'auto-sauvetage » de Plasma est passée d'un comportement explicite à une garantie implicite.
Vous pouvez toujours sortir, mais vous n'avez pas besoin de penser à sortir tous les jours. Sortir est passé d'une expérience utilisateur à un mécanisme d'assurance au niveau du système. Cela ne contredit pas l'esprit du Plasma précoce, mais y reste fidèle en ce qui concerne son hypothèse de sécurité initiale : le pire scénario se produira, mais vous n'avez pas besoin de vivre dans le pire scénario chaque jour.
Sous cet angle, « du contrat d'auto-sauvetage au module de confiance » n'est pas une trahison de Plasma, mais une forme de maturité.
C'est précisément ici que j'ai commencé à redéfinir la position de Plasma dans le récit modulaire. Ce n'est ni une couche de données, ni une couche de consensus, et encore moins adaptée à porter un récit d'exécution complet. Sa position la plus naturelle est en fait une unité d'exécution à haut débit et à faible hypothèse de confiance, intégrée dans un domaine de sécurité plus fort.
Ce que fait LEAP, c'est essentiellement externaliser le sentiment d'insécurité de Plasma.
L'insécurité existe toujours, mais elle est digérée par le protocole, et non perçue directement par les utilisateurs.
Bien sûr, cela ne signifie pas que Plasma est devenu une « technologie élégante » du jour au lendemain. La longue période de sortie existe toujours objectivement, et le risque de données non disponibles n'a pas disparu. Ces problèmes ne déterminent plus directement l'expérience produit, mais sont plutôt relégués aux coins inférieurs de la conception du protocole. Pour la plupart des cas d'utilisation, ils ne sont plus des facteurs de considération prioritaires.
Il est intéressant de noter que ce chemin d'évolution ressemble en fait beaucoup à la trajectoire de maturité de nombreux systèmes traditionnels. La sécurité informatique des premiers temps consistait également à enseigner aux utilisateurs comment sauvegarder, comment restaurer et comment réparer manuellement ; aujourd'hui, la tolérance aux pannes, le retour en arrière et les instantanés sont devenus des capacités par défaut du système, les utilisateurs ne savent même pas quand ils sont déclenchés.
Le changement de Plasma dans LEAP est un processus similaire.
Lorsque « l'auto-sauvetage » n'est plus un argument de vente, mais simplement une partie des capacités sous-jacentes, la technologie commence réellement à devenir utilisable.
Donc, si aujourd'hui on me demandait à nouveau : Plasma vaut-il encore la peine d'être discuté ?
Ma réponse est en fait plus certaine qu'il y a quelques années.
Non pas parce que Plasma est devenu plus fort, mais parce qu'il a enfin été placé dans une structure qui ne demande pas aux utilisateurs de supporter tous les coûts de méfiance. Dans un protocole comme LEAP, Plasma n'a plus besoin de prouver qu'il est l'avenir, il doit simplement jouer honnêtement un rôle — un module d'exécution qui peut encore être corrigé par le réseau principal dans des cas extrêmes, tout en étant suffisamment bon marché et efficace dans des situations quotidiennes.
Peut-être que c'est la forme ultime de Plasma.
Ne se tenant plus au centre de la scène, et ne portant plus de grands récits, mais comme toutes les infrastructures matures, calme, retenue, mais indispensable.
