¿Por qué los chains no EVM tienen tantas vulnerabilidades en sus principales protocolos DeFi? Tengo miedo de depositar grandes cantidades en DeFi de chains no EVM. De hecho, en chains como Sui, Aptos, Stacks, etc., que no son EVM, ha habido muchos casos de hackeos en los principales protocolos DeFi. Por eso, aunque sé que los rendimientos de depósito de @MMTFinance serán atractivos por el airdrop, no puedo enviar muchos activos. ¿Por qué los chains no EVM son más propensos a ser hackeados? Hackear una blockchain es muy difícil. (Casi imposible, lo iba a escribir pero lo corregí.) Sin embargo, programar para DeFi (smart contracts) es tarea de humanos, y los humanos siempre cometen errores. Por lo tanto, DeFi siempre debe asumir el peor riesgo de hackeo de protocolo. Las chains EVM también han experimentado enormes incidentes de hackeo en DeFi a lo largo de la historia. A través de este proceso, Ethereum y el ecosistema EVM han reutilizado innumerables open source representados por OpenZeppelin, Uniswap, Curve, etc., que han sido atacados y verificados. Es decir, ahora hay muchas open source que son seguras para usar. La experiencia de las empresas de auditoría también es abrumadoramente mayor en el código de smart contracts de EVM. De hecho, creo que Move, que se utiliza en Sui o Aptos, es un lenguaje y VM más avanzado para blockchain en muchos aspectos que EVM/Solidity. Sin embargo, el código de las chains no EVM aún no ha sido suficientemente atacado ni verificado. La historia es corta y hay poco código abierto, por lo que incluso las empresas de auditoría carecen de experiencia. Los protocolos DeFi temen ser atacados y no pueden ni siquiera abrir su código. Es como no poder hacer un kimchi por miedo a los gusanos... Creo que este es un problema muy importante que las chains no EVM deben resolver. Stacks, que es el DeFi central del ecosistema, ha sido hackeado dos veces consecutivas, y ya no puede recuperarse. Si la falta de historia y experiencia no puede ser resuelta por la comunidad y el tiempo, se debe fomentar y suministrar código estandarizado bajo la dirección de la fundación. Además, se deben establecer medidas para alentar la apertura del código de los protocolos y la fundación debe ayudar activamente con las auditorías. Espero que surjan grandes protocolos DeFi en chains no EVM que brinden estabilidad frente al riesgo de hackeo.

De hecho, el 80% de los hackeos que ocurren son obra de insiders, pero realmente ya no hay muchos casos de hackeos por "escribir mal el código" en EVM o Solana. Y en el caso de los insiders... creo que es correcto programar los contratos de manera que no se puedan actualizar, en lugar de "No ser malvado", sería "No se puede ser malvado".