Seguridad de contratos inteligentes en TRON: mejores prácticas para desarrolladores

La implementación en TVM (máquina virtual TRON) de TRON resulta familiar para los desarrolladores de Ethereum: solidez, patrones ABI similares, primitivas DeFi comparables. Las fallas de seguridad son igualmente familiares: drenajes de reentrada, falta de control de acceso, mentas ilimitadas y manipulación de Oracle ocurrieron en TRON.

Esta guía cubre consideraciones específicas de TRON y prácticas universales de seguridad de contratos inteligentes para tokens TRC-20, protocolos DeFi y contratos de pago.

Modelo de amenaza

Supongamos que los atacantes:

• Llame a su contrato directamente, sin pasar por su interfaz
• Explotación transferFrom después de engañar a los usuarios para que obtengan aprobaciones ilimitadas
• Las transacciones iniciales fueron rentables (menos infraestructura MEV que Ethereum, aún relevante en DEX)
• Sondear código de bytes no verificado con ingeniería inversa
• Abuso de las claves de administrador si están centralizadas.

El riesgo del usuario se superpone con estafas de aprobación ilimitada y tokens de Honeypot.

Control de acceso

Cada función privilegiada (mint, pause, setFee, withdraw) necesita una restricción explícita.

import "@openzeppelin/contracts/access/Ownable.sol";

contract SecureToken is Ownable {
    function mint(address to, uint256 amount) external onlyOwner {
        _mint(to, amount);
    }
}

Cheques:

• No hay selfdestruct o delegatecall desprotegidos para la entrada del usuario
• Multi-sig o timelock para administrador en producción TVL
• Renunciar a la propiedad sólo cuando sea verdaderamente inmutable.

TRON multifirma: permisos de cuenta.

Reentrada

TRC-20 transfer y transferFrom llaman a contratos externos cuando el destinatario es un contrato. Patrón de drenaje clásico:

// Vulnerable pattern
function withdraw() external {
    uint amount = balances[msg.sender];
    (bool ok,) = msg.sender.call{value: amount}("");
    balances[msg.sender] = 0; // too late
}

Solución: Comprobaciones-efectos-interacciones + ReentrancyGuard de OpenZeppelin.

TRC-20 no usa call para TRX, pero transfer para un contrato malicioso puede volver a ingresar.

Desbordamiento de enteros

Solidity 0.8+ tiene comprobaciones de desbordamiento integradas. Es posible que los contratos anteriores 0.5.x TRON necesiten SafeMath.

Audite las [plantillasTRC-20] heredadas(/es/articles/deploy-trc20-tronweb/) antes de la implementación de la red principal.

Errores del contrato de tokens

Publicar fuente verificada en TronScan — verificar contrato inteligente.

Oráculo y manipulación de precios

Los precios al contado de DEX en cadena son manipulables en ataques de un solo bloque. No utilice las reservas del pool SunSwap como único oráculo de precios para las liquidaciones de préstamos.

Utilice TWAP, múltiples fuentes u oráculos fuera de cadena con comprobaciones de latidos.

Proxy y contratos actualizables

Los patrones actualizables (proxy transparente, UUPS) ocultan los cambios de direcciones lógicas.

Riesgos:

• Actualizaciones de administrador comprometidas a implementación maliciosa
• Colisión de almacenamiento entre versiones.
• Los usuarios interactúan con el proxy: verifique la implementación en TronScan

Documentar la política de actualización públicamente.

Notas específicas de TVM

Consulte TVM explicado y Solidity on TRON.

• Los costos de energía difieren del gas Ethereum: optimice los circuitos para que sean asequibles para el usuario
• Formato de dirección: los tipos address se compilan de manera similar; la integración externa utiliza direcciones Base58 T
• Los patrones trx.call.value difieren; prefiera TRC-20 para los tokens
• prueba en Shasta/Nile antes de la red principal — guía de testnet

Estrategia de prueba

1. Pruebas unitarias — TronBox / Hardhat con adaptador TRON
2. Pruebas de integración: implementación en Shasta, flujos de usuarios completos
3. Fuzzing — Echidna, Foundry cuando sea compatible
4. Análisis estático — Slither on Solidity AST
5. Auditoría externa: requerida para TVL significativo

Contratos inteligentes de TronBox configuración de prueba.

Higiene de implementación

• Implementación desde una billetera de hardware o una clave fría para el propietario
• Verifique el contrato inmediatamente en TronScan
• Transferir propiedad a multisig en una transacción separada
• Documentar las direcciones de los contratos en README y eventos en cadena.
• Sin claves privadas en el frontend o GitHub

Seguridad de frontend y API

La seguridad de los contratos inteligentes se extiende a la forma en que interactúan los usuarios:

• Nunca solicite frases iniciales en sitios web de dApp
• Mostrar cantidades aprobadas legibles por humanos
• Mostrar direcciones de contrato contra las que los usuarios firman
• riesgos de conexión de dApp educación para los usuarios

Sistemas de pago backend: aceptar pagos USDT.

Respuesta al incidente {#incidente}Si el exploit está activo:

1. Pausar el contrato si se puede pausar
2. Comunicarse de forma transparente
3. Comuníquese con los intercambios si los fondos robados llegan a direcciones etiquetadas
4. Reportar direcciones fraudulentas

La prevención supera a la recuperación en cadenas inmutables.

Lista de verificación de seguridad

• [] Solidez 0.8+ o SafeMath
• [] ReentrancyGuard en llamadas externas
• [] solo propietario/acceso basado en roles
• [ ] No arbitrario delegatecall
• [ ] Tapa nueva o suministro fijo documentado
• [] Verificado en TronScan
• [] Implementación de Testnet probada
• [] Auditoría de terceros para fondos de usuarios
• [] Correo electrónico de divulgación o recompensa por errores

Lista de verificación para solucionar problemas

Si algo sale mal en TRON, trátelo como un problema de depuración estructurado: confirme el txid exacto en la cadena, verifique la dirección del contrato de destino y solo entonces decida si la falla es recuperable. En TRON, muchos problemas "misteriosos" son simplemente uno de: red incorrecta (mainnet vs testnet), contrato de token incorrecto (falso USDT/tokens con nombres similares), recursos insuficientes (OUT_OF_ENERGY/ancho de banda) o retraso en la interfaz de usuario/indexador entre la billetera y el explorador.

Comience con estas comprobaciones en cadena:

• Copie siempre el txid/hash completo de su billetera o explorador.
• Confirme el estado del resultado del tx en TronScan (SUCCESS, REVERT, OUT_OF_ENERGY o aún pendiente).
• Compruebe si la dirección del destinatario/contrato coincide con la que desea enviar.
• Si se trata de una llamada de contrato, confirme que el selector de función y los parámetros coincidan con el estándar de token que cree que está utilizando (TRC-20 vs TRC-10 vs BEP-20 en BSC).

Luego aplique la ruta de corrección para su categoría:

• Confirmar el estado y los parámetros de la transacción.
• Verificar direcciones (contrato de token, destinatario, enrutador/gastador).
• Agregar o delegar recursos (Energía/Ancho de banda) cuando el fallo esté basado en recursos.

Errores comunes

Estos patrones causan la mayoría de los errores a nivel de usuario:

• Usar direcciones de mainnet en testnet (o al revés).
• Copiar un símbolo de token en lugar de la dirección del contrato TRC-20 real.
• Firmar la dirección de aprobación/gastador incorrecta porque el enlace de la interfaz de usuario es malicioso o está desactualizado.
• Reintentar sin cambiar la entrada fallida (por ejemplo, REVERT sigue revirtiéndose hasta que corrija el parámetro).

Si no está seguro, no “simplemente envíe de nuevo”. Realice un cambio controlado, verifique en TronScan y luego continúe.

Preguntas frecuentes

¿Cómo sé si una transacción está realmente confirmada?

Utilice TronScan y verifique el estado del resultado del tx. Las etiquetas "pendientes" de la billetera pueden retrasarse; El estado de la cadena es la fuente de la verdad. Copie txid y verifique SUCCESS/REVERT/OUT_OF_ENERGY, no solo el texto de la interfaz de usuario.

¿Por qué la interfaz de usuario difiere de TronScan?

Algunas billeteras y dApps utilizan diferentes indexadores o capas de caché. Es normal que haya un breve retraso entre la transmisión y la indexación; compare txid y espere a que la cadena se estabilice antes de concluir que hay una falla.

¿Qué debo hacer después de un REVERT?

Detenga y decodifique la llamada fallida. La mayoría de los REVERT se deben a parámetros no válidos, dirección de contrato incorrecta, aprobaciones faltantes o una falta de coincidencia entre el estándar del token y el método. Solucione la causa y luego vuelva a firmar.

¿Es seguro firmar una aprobación ilimitada?

Las aprobaciones ilimitadas son seguras solo para direcciones de gastadores confiables que usted haya verificado (fuente verificada, enrutador correcto y contrato de token esperado). Para las pruebas, prefiera aprobaciones limitadas y revoque una vez que haya terminado.

¿Qué recursos requiere TRON para las llamadas de contrato?

La ejecución de contratos inteligentes consume principalmente energía, mientras que los bytes de transacciones consumen ancho de banda. Si recibe OUT_OF_ENERGY, agregue/congela/delegue energía. Si se agota el ancho de banda, concéntrese en mantener suficiente líquido TRX para bytes y asignación de recursos.

¿Cómo puedo reducir los tickets de soporte?

Muestre a los usuarios un mensaje claro de "qué sucedió" basado en el estado de la cadena y vincule directamente a la guía relevante (pendiente, fallida, sin energía o verificación). Guarda txid para que puedas conciliar rápidamente.

Guías relacionadas

• Solididad en TRON
• Implementar TRC-20 con TronWeb
• Verificar contrato inteligente en TRON
• TRC-20 riesgos de aprobación de tokens

Preguntas frecuentes

¿La seguridad de los contratos inteligentes TRON es diferente de Ethereum?

Los patrones de solidez se superponen en gran medida, pero TVM difiere en los costos de código de operación y formatos de dirección. Las clases de vulnerabilidad principales son las mismas.

¿Debo auditar mi TRC-20 antes de implementarlo en la red principal?

Sí para cualquier contrato que tenga fondos de usuario. Los experimentos de bajo riesgo aún se benefician del escaneo automatizado.

¿Pueden los usuarios agotar mi contrato sin que se produzca un error?Si los usuarios otorgaron aprobaciones de tokens ilimitadas a su contrato, una clave de administrador o una actualización comprometida podrían agotar a esos usuarios: diseñe aprobaciones mínimas.

¿Son seguros los contratos de OpenZeppelin en TRON?

Generalmente sí cuando se utilizan versiones actuales en Solidity 0.8+. Verifique la versión del compilador e importe las rutas en TronBox.

¿Cuál es la estafa de tokens TRON más común?

Los contratos Honeypot permiten compras pero bloquean ventas: no son una vulnerabilidad en su protocolo, sino un riesgo para el ecosistema para sus usuarios.