A Inversão da Verificação
Neste ponto, ser um incumbente só traz uma carga legada mais onerosa que o atrapalha.
Para a questão P != NP e o problema da NP-completude, é mais fácil verificar uma solução em forma fechada do que gerá-la.
Contudo, agora é o oposto para tarefas de geração de código de longa data. É muito mais fácil gerar código/contratos do que verificá-los. Imagine que você tenha um conjunto de arquivos de código controlando 1 milhão de botões para exibir VERMELHO e AZUL. Se a tarefa for ter 1.000.001 botões, com o botão adicionado recentemente exibindo VERMELHO, a lógica do código existente não funcionará. Pela teoria da informação, o valor informativo de um botão é condicional. O novo botão carrega informação apenas dado os demais: H(novo | restante). Se seu estado for fixado como VERMELHO pela nova exigência, sua entropia condicional é zero. Ele não contribui com nenhuma informação, mas ainda assim é quase impossível reconfigurar a lógica do código existente.
Portanto, na verdade, é mais fácil regenerar o código do que atualizar a base de código existente. Este é outro novo aspecto do Dilema do Inovador.
O disruptor enfrenta a situação inversa. Ele não possui conhecimento tácito nem legado, então começa a partir de uma especificação e gera algo novo, e seus custos permanecem baixos enquanto a especificação permanecer limpa.
A conclusão estratégica é que o ativo escasso mudou. No regime antigo, o código era o ativo escasso, caro de escrever e, portanto, digno de proteção. No novo regime, o código é barato, e a especificação, os testes e o comportamento registrado são escassos.
Imagine por um momento ser CZ.
Você é o incumbente. Seu exchange é uma base de código massiva e rígida construída para o mundo de cinco anos atrás—livros de ordens centralizados, suposições fixas sobre liquidez, conformidade e fluxos de usuários. Funcionava. Ele comprimiu as antigas exigências em algo curto e lucrativo.
Agora a especificação mudou. Perps onchain, transparência 24/7, infraestruturas amigáveis à CFTC, uma equipe mais jovem desenvolvendo a partir de um ponto mais limpo. O Hyperliquid não carrega sua codificação legada.
Adicionar uma restrição a mais—ou um concorrente a mais—não exige apenas um patch. Exige reconfigurar todo o gráfico de controle. O novo bit de informação pode ter entropia condicional quase zero dado o sistema antigo, mas o programa antigo não pode absorvê-lo sem quebrar.
Assim, a participação de mercado escapa. A atenção escapa. O movimento racional para o incumbente não é uma adaptação elegante; é forçar o ambiente de volta à medida para a qual o código antigo foi otimizado.
Liquidar, culpar um “hacker”, congelar o que puder, restaurar a distribuição anterior. Parece um incidente de segurança. Information-theoreticamente, é uma tentativa de evitar o custo da regeneração.
O Dilema do Inovador nos mercados é o mesmo que no código: uma vez que sua compressão do mundo não corresponde mais ao mundo, corrigir é mais caro do que começar do zero. E as pessoas que já começaram do zero não precisam explicar a história da diarreia.