Ao contrário dos ataques de vulnerabilidade de contrato, este tipo de ataque requer uma certa quantidade de capital para quebrar o equilíbrio de preço do Oracle, e há uma certa possibilidade de falha. A equipe do projeto geralmente ajusta os parâmetros do protocolo e outras medidas de prevenção e controle para aumentar o custo de implementação do ataque, juntamente com uma estratégia detalhada de controle de risco, multas e confisco de fundos, etc., e, claro, também pode recorrer a medidas legais. De qualquer forma, não resolve o problema fundamental.

A questão é que ainda há controvérsia sobre a natureza de tais ataques, e muitas pessoas pensarão que os atacantes só usaram o modelo AMM e defeitos de liquidez para aproveitar oportunidades de arbitragem, o que é um comportamento especulativo e não deve ser identificado como "ataques de hackers". Este é um problema que não é resolvido há muito tempo.

Recentemente, vimos muitas soluções de exploração para o modelo de negociação de carteira de ordens em L2, com taxas baixas, sem derrapagem e desgaste, e podemos alcançar uma proteção de privacidade semelhante à CEX, o que atrairá os criadores de mercado de MM para migrar. Só que o modelo de livro de ordens terá problemas espinhosos como correspondência centralizada, baixa profundidade de liquidez e baixa eficiência de correspondência por um longo tempo, e não é invulnerável.

Teoricamente, o modelo AMM+Order, juntamente com estratégias rigorosas de controle de risco, como monitoramento anormal de transações, stop loss automático, reservas de risco, etc., a combinação dos dois modelos de negociação e o uso eficiente da profundidade de negociação pode ser uma boa direção de otimização.

Pessoalmente, acho que com a popularização e maturidade da infraestrutura como L2 + L3, a negociação inevitavelmente mudará gradualmente para o mercado de aplicativos, e algumas aplicações de negociação independentes da cadeia de negociação independente surgirão gradualmente.