La inversión de la verificación
En este punto, ser un establecido solo implica una carga heredada más engorrosa que te puede hacer tropezar.
Para la pregunta P ≠ NP y el problema de NP-completitud, es más fácil verificar una solución en forma cerrada que generarla.
Sin embargo, ahora ocurre lo contrario en tareas de generación de código de larga duración: es mucho más fácil generar código/contratos que verificarlos. Imagina que tienes un conjunto de archivos de código que controlan 1 millón de botones para mostrar ROJO y AZUL. Si la tarea es tener 1.000.001 botones, con el botón adicional recién agregado mostrando ROJO, la lógica del código existente no funcionará. Según la teoría de la información, el valor informativo de un botón es condicional. El nuevo botón lleva información solo dado los demás: H(nuevo | resto). Si su estado se fija a ROJO por el nuevo requisito, su entropía condicional es cero. No aporta ninguna información, pero aún así es casi imposible volver a conectar la lógica del código existente.
Por lo tanto, en realidad es más fácil volver a generar el código que actualizar la base de código existente. Este es otro nuevo aspecto del Dilema del Innovador.
El disruptor enfrenta la situación inversa. No tiene conocimiento tácito ni herencia, por lo que comienza desde una especificación y genera algo fresco, y sus costos permanecen bajos mientras la especificación se mantenga limpia.
La conclusión estratégica es que el activo escaso ha cambiado. En el antiguo régimen, el código era el activo escaso, caro de escribir y por lo tanto digno de proteger. En el nuevo régimen, el código es barato, y la especificación, las pruebas y el comportamiento registrado son escasos.
Imagina por un momento ser CZ.
Eres el establecido. Tu exchange es una base de código masiva y rígida construida para el mundo de hace cinco años: libros de órdenes centralizados, suposiciones fijas sobre liquidez, cumplimiento y flujos de usuario. Funcionaba. Comprimió los requisitos antiguos en algo breve y rentable.
Ahora la especificación ha cambiado. Perps onchain, transparencia 24/7, vías amigables con la CFTC, un equipo más joven que entrega desde un punto de partida más limpio. Hyperliquid no lleva tu codificación heredada.
Agregar una restricción más —o un competidor más— no solo requiere un parche. Requiere volver a conectar todo el grafo de control. El nuevo bit de información puede tener entropía condicional casi cero dado el sistema antiguo, pero el programa antiguo no puede absorberlo sin romperse.
Por lo tanto, la cuota de mercado se filtra. La atención se filtra. El movimiento racional para el establecido no es una adaptación elegante; es forzar al entorno a volver al modelo para el cual el código antiguo fue optimizado.
Liquidar, culpar a un “hack”, congelar lo que puedas, restaurar la distribución anterior. Parece un incidente de seguridad. Informacionalmente es un intento de evitar el costo de la regeneración.
El Dilema del Innovador en los mercados es el mismo que en el código: una vez que tu compresión del mundo ya no coincide con el mundo, parchear es más caro que empezar desde cero. Y las personas que ya empezaron desde cero no tienen que explicar la historia de la diarrea.