Desde Sui & Aptos (Move)
Sui y Aptos son ambas cadenas basadas en Move con finalidad de subsegundo y ejecución paralela. TRON ejecuta Solidity en una VM secuencial derivada de la EVM. La transición aquí es principalmente un cambio de lenguaje y modelo de ejecución — el modelo de comisiones y la estructura de cuentas son menos desconcertantes que el paso de tipos de recursos con sabor a Rust a invariantes manuales de Solidity.
Lenguaje y Contratos Inteligentes
Sección titulada «Lenguaje y Contratos Inteligentes»Esta es la diferencia más significativa. Move y Solidity son lenguajes fundamentalmente diferentes con propiedades de seguridad distintas.
| Concepto | Aptos (Move) | Sui (Move) | TRON |
|---|---|---|---|
| Lenguaje | Move | Sui Move | Solidity |
| VM | MoveVM / AptosVM | SuiVM | TVM (derivado de EVM) |
| Seguridad de tipos | Tipos lineales — los recursos no se pueden copiar ni eliminar implícitamente | Igual | Sin aplicación — se requieren verificaciones manuales |
| Unidad de contrato | Módulo publicado en una dirección | Paquete (inmutable o actualizable vía UpgradeCap) | Contrato desplegado en una dirección única |
| Ubicación del estado | Recursos almacenados en el almacenamiento de la cuenta | Objetos con propietarios explícitos | Mapeo de almacenamiento interno al contrato |
| Actualización | Actualizable por defecto (política configurable al publicar) | Actualizable vía UpgradeCap; destruir el cap lo hace inmutable | Inmutable por defecto — patrón proxy para actualizaciones |
| Ejecución paralela | Sí — Block-STM (concurrencia optimista) | Sí — DAG de objetos + consenso Mysticeti | No — ejecución secuencial |
Para desarrolladores de Move: Escribir contratos inteligentes en TRON significa escribir Solidity. El modelo cambia de módulos más recursos (Move) a objetos con mapeos de almacenamiento (Solidity). No existe un equivalente al sistema de tipos lineales de Move — la propiedad, las invariantes y la seguridad de los activos deben aplicarse manualmente, como en el desarrollo estándar de Ethereum.
Direcciones
Sección titulada «Direcciones»| Propiedad | Aptos | Sui | TRON |
|---|---|---|---|
| Formato | 0x + hasta 64 chars hex (32 bytes) | 0x + 64 chars hex (32 bytes) | T + 33 chars Base58Check |
| Ejemplo | 0x1 (framework), 0xabcd...ef12 | 0x02a212...de39 | TJYea...VPCX |
| Derivación | Clave pública ed25519 o secp256k1 | ed25519 o secp256k1 | Hash de clave pública secp256k1 (misma curva que Ethereum) |
| ¿Distingue mayúsculas? | No | No | No |
Billeteras
Sección titulada «Billeteras»| Aptos | Sui | TRON | Notas |
|---|---|---|---|
| Petra | Sui Wallet (Slush) | TronLink | Billeteras principales del ecosistema. Todas disponibles como extensión de navegador + móvil. |
| Martian | Suiet | TronLink | Alternativas de código abierto. |
| OKX Wallet | OKX Wallet | OKX Wallet | OKX soporta las tres cadenas en una sola app. |
| Ledger | Ledger | Ledger | Soporte de billetera hardware en las tres vía Ledger Live. |
Estándares de Tokens
Sección titulada «Estándares de Tokens»| Aptos | Sui | TRON | Notas |
|---|---|---|---|
| Fungible Asset (FA) | Coin<T> | TRC-20 | Todos son el estándar principal de token fungible. Aptos migró del antiguo Coin<T> a Fungible Asset (FA) en 2025. |
| Digital Asset (Token V2) | NFT basado en objetos | TRC-721 | Tokens no fungibles. Los NFTs de Sui son objetos; los de TRON los gestiona el contrato. |
| APT nativo | SUI nativo | TRX nativo | La moneda nativa de la cadena — no es un contrato de token en ninguna de las tres. |
Gas y Comisiones
Sección titulada «Gas y Comisiones»Las tres cadenas usan modelos de comisiones significativamente diferentes.
| Concepto | Aptos | Sui | TRON |
|---|---|---|---|
| Componentes de comisión | Gas de instrucción + gas de almacenamiento + gas de payload | Gas de cómputo + gas de almacenamiento | Energía (cómputo) + Ancho de banda (datos) |
| Pago | APT — todo se quema permanentemente | SUI — el cómputo se quema; las comisiones de almacenamiento se reembolsan al 99% al eliminar el objeto | Quema de TRX, o TRX pre-stakeado con renovación diaria |
| Costo de almacenamiento | Sí — pagado por byte por transacción | Sí — pagado por adelantado, mayormente reembolsado al borrar el objeto | Ninguno — el almacenamiento es gratuito en TRON |
| ¿Pueden ser las comisiones cero? | No | No | Sí — el TRX stakeado provee Energía y Ancho de banda renovables |
| Previsibilidad de comisiones | Moderada — el precio unitario de gas varía con la carga | Moderada | Alta — las tasas de quema las fija la gobernanza, no el mercado |
Diferencia en costo de almacenamiento: Tanto Aptos como Sui cobran comisiones proporcionales al estado on-chain que crean tus transacciones. TRON no tiene comisiones de almacenamiento. Esto hace que TRON sea comparativamente mejor para contratos que acumulan grandes cantidades de estado con el tiempo (p. ej., una colección de NFTs, un registro).
Modelo de Objetos de Sui vs Modelo de Cuentas de TRON
Sección titulada «Modelo de Objetos de Sui vs Modelo de Cuentas de TRON»El modelo centrado en objetos de Sui es arquitectónicamente diferente al modelo de cuentas de TRON. Este es el mayor cambio conceptual para los desarrolladores de Sui.
| Concepto | Sui | TRON |
|---|---|---|
| Unidad de estado | Objeto — tiene un ID único, versión y propietario tipado | Almacenamiento del contrato — mapeo clave-valor dentro de una dirección de contrato |
| Propiedad | Owned (una dirección), Shared (cualquier llamador) o Immutable | Controlado por el contrato — el contrato decide quién puede hacer qué |
| Entradas de transacción | Los objetos deben listarse explícitamente como entradas de transacción | Solo se especifica la dirección del contrato llamado |
| Paralelismo | Las transacciones de objetos owned se ejecutan en paralelo por defecto | Todas las transacciones se ejecutan de forma secuencial |
| Transferencia | Los objetos se mueven entre direcciones de propietario | Los saldos son entradas actualizadas en el mapeo de almacenamiento del contrato |
Al portar un contrato de Sui a TRON, el patrón de propiedad de objetos suele convertirse en un mapping(address => ...) en Solidity. En lugar de transfer(nft_object, recipient), se actualiza owners[tokenId] = recipient.
Actualización de Contratos Inteligentes
Sección titulada «Actualización de Contratos Inteligentes»| Característica | Aptos | Sui | TRON |
|---|---|---|---|
| Estado por defecto | Actualizable (política fijada al publicar) | Actualizable vía UpgradeCap | Inmutable |
| Mecanismo de actualización | Publica el mismo módulo con cambios compatibles | Llama a upgrade con el objeto UpgradeCap en mano | Despliega un nuevo contrato de implementación; actualiza el puntero del proxy |
| Para hacerlo inmutable | Publica con política de upgrade immutable | Destruye el objeto UpgradeCap | No es necesario — inmutable por defecto |
Los contratos de TRON no se pueden modificar después del despliegue. Si necesitas actualización, despliega un contrato proxy desde el inicio. El patrón estándar es el proxy transparente EIP-1967 — la dirección del proxy es permanente; la dirección de implementación almacenada en él puede actualizarla un administrador autorizado.
Equivalentes de Protocolos DeFi
Sección titulada «Equivalentes de Protocolos DeFi»| Protocolo de Aptos / Sui | Equivalente en TRON | Notas |
|---|---|---|
| Liquidswap (Aptos) / Cetus (Sui) | SunSwap | DEX AMM. SunSwap V3 usa liquidez concentrada comparable a los Whirlpools de Cetus. |
| Aries / Echelon (Aptos) | JustLend | Préstamos y créditos con factores de salud basados en colateral. |
| Scallop / Suilend (Sui) | JustLend | Mismo modelo de préstamos sobrecolateralizados. |
| Bluefin / Typus (Sui) | SunX | Trading de futuros perpetuos. |
| Topaz / Souffl3 | aiNFT | Marketplace de NFTs. Menor volumen que los mercados de Aptos y Sui. |
Velocidad y Finalidad
Sección titulada «Velocidad y Finalidad»| Métrica | Aptos | Sui | TRON |
|---|---|---|---|
| Tiempo de bloque | ~94 ms | ~100 ms | 3 segundos |
| Finalidad | ~650 ms | ~480 ms (objetos owned) | 1 bloque (~3 segundos) |
| TPS (teórico) | 160.000+ | Muy alto (paralelo por objetos) | 2.000+ |
TRON es significativamente más lento que ambas cadenas Move. La finalidad de 3 segundos es adecuada para DeFi, transferencias y la mayoría de los casos de uso de DApps. Las aplicaciones que requieren respuesta de sub-segundo — bots de trading de alta frecuencia, juegos sensibles a la latencia — no son adecuadas para TRON.
Errores Frecuentes para Desarrolladores de Move
Sección titulada «Errores Frecuentes para Desarrolladores de Move»| Error | Impacto | Solución |
|---|---|---|
| Sin seguridad de tipos lineales | Son posibles bugs de reentrancy y duplicación de activos | Sigue Checks-Effects-Interactions; usa ReentrancyGuard |
| Sin comisiones de almacenamiento | TRON no cobra por el crecimiento de estado, pero el almacenamiento ilimitado sigue siendo mala práctica | Diseña para un estado acotado; evita arrays de solo-adición sin limpieza |
| Ejecución secuencial | Los patrones de ejecución paralela no aplican | Diseña para ejecución mono-hilo — también es la práctica estándar de Ethereum |
| Los contratos son inmutables | No se puede parchear la lógica en el lugar | Despliega un proxy desde el inicio si se requiere actualización |
| Timestamps de la API en milisegundos | Las APIs de TRON devuelven ms; block.timestamp en TVM devuelve segundos | Divide los timestamps de la API por 1.000 antes de pasarlos al contrato |
| Frase semilla no portable | Las rutas HD de Aptos/Sui difieren de TRON — mismo mnemónico, clave diferente | Crea una billetera TronLink nueva; no importes un mnemónico de billetera Move |
Para una tabla completa de conceptos entre cadenas incluyendo Ethereum, Solana y Move, consulta Mapeo de Conceptos. Para equivalentes de herramientas para desarrolladores, consulta Equivalencias de Herramientas.