L'inversion de la vérification
À ce stade, être un acteur établi ne fait que cumuler un fardeau hérité encombrant qui vous entrave.
Pour la question P ≠ NP et le problème de la NP-complétude, il est plus facile de vérifier une solution sous forme close que de la générer.
Mais aujourd'hui, c'est l'inverse pour les tâches longues de génération de code. Il est bien plus facile de générer du code / des contrats que de les vérifier. Imaginez que vous ayez un ensemble de fichiers code contrôlant 1 million de boutons affichant ROUGE et BLEU. Si la tâche consiste à avoir 1 000 001 boutons, avec le bouton additionnel nouvellement ajouté affichant ROUGE, la logique du code existant ne fonctionnera pas. Selon la théorie de l'information, la valeur informationnelle d'un bouton est conditionnelle. Le nouveau bouton transporte de l'information uniquement relativement aux autres : H(nouveau | reste). Si son état est fixé à ROUGE par la nouvelle exigence, son entropie conditionnelle est nulle. Il ne contribue aucune information, mais il est presque impossible de réécrire la logique du code existant.
Il est donc en réalité plus facile de régénérer le code que de mettre à jour la base de code existante. C'est un autre nouvel aspect du dilemme de l'innovateur.
Le disrupteur se trouve dans une situation inverse. Il n'a aucune connaissance implicite ni héritage, il commence donc à partir d'une spécification et génère du code frais, et ses coûts restent faibles tant que la spécification reste claire.
La conclusion stratégique est que l'actif rare a changé. Dans l'ancien régime, le code était l'actif rare, coûteux à écrire et donc digne d'être protégé. Dans le nouveau régime, le code est bon marché, et la spécification, les tests et le comportement enregistré sont rares.
Imaginez un instant être CZ.
Vous êtes l'acteur établi. Votre plateforme d'échange est une base de code massive et rigide conçue pour le monde d'il y a cinq ans — carnets d'ordres centralisés, hypothèses fixes sur la liquidité, la conformité et les flux utilisateurs. Cela fonctionnait. Il avait compressé les anciennes exigences en quelque chose de court et rentable.
Maintenant, la spécification a changé. Des Perp onchain, une transparence 24/7, des infrastructures compatibles avec la CFTC, une équipe plus jeune qui délivre à partir d'un point de départ plus propre. Hyperliquid ne porte pas votre encodage hérité.
Ajouter une contrainte supplémentaire — ou un concurrent supplémentaire — ne nécessite pas simplement un correctif. Cela exige de rebrancher tout le graphe de contrôle. Le nouvel élément d'information peut avoir une entropie conditionnelle quasi nulle par rapport au système ancien, mais le programme ancien ne peut pas l'absorber sans se briser.
Ainsi, la part de marché s'érode. L'attention s'érode. Le mouvement rationnel pour l'acteur établi n'est pas une adaptation élégante ; c'est forcer l'environnement à revenir à la mesure pour laquelle le code ancien avait été optimisé.
Liquidation, blâme sur un « piratage », gel de ce qui peut l'être, restauration de la distribution précédente. Cela ressemble à un incident de sécurité. Informationnellement, c'est une tentative d'éviter le coût de la régénération.
Le dilemme de l'innovateur sur les marchés est le même qu'en programmation : une fois que votre compression du monde ne correspond plus au monde, les correctifs deviennent plus coûteux qu'un démarrage à zéro. Et les personnes qui ont déjà commencé à zéro n'ont pas à expliquer l'histoire de la diarrhée.