4.096 bytes activos en Solana desde hoy tras triplicar límite de transacción
Patricia López · Criptomonedas · 2026-09-15
El mainnet activó a las 01:00 UTC el formato v1 que multiplica por 3.3 la capacidad. ZK proofs, multifirmas grandes y esquemas criptográficos complejos ya caben en una sola operación atómica.
Solana activó este martes a las ~01:20 UTC su formato de transacciones v1 en el mainnet, elevando el límite máximo de tamaño de 1.232 bytes a 4.096 bytes. El salto —exactamente 3.3 veces más capacidad— desbloquea cargas de trabajo que antes no cabían en una sola operación: pruebas de conocimiento cero, multifirmas institucionales y esquemas de firmas criptográficas ahora se ejecutan de forma atómica.
Qué puede construirse ahora y antes no
El nuevo límite habilita <abbr title="Pruebas criptográficas que permiten demostrar la veracidad de una afirmación sin revelar la información subyacente">ZK proofs</abbr> dentro de transacciones individuales, algo crítico para privacidad on-chain. Las Confidential Transfers de Solana, que ocultan montos en transferencias de tokens, dependen de estas pruebas. También entran firmas Winternitz de un solo uso, <abbr title="Esquema de firmas múltiples donde varias claves privadas deben autorizar una transacción">multifirmas</abbr> anidadas usadas por instituciones y esquemas como BLS que requieren payloads densos.
Una confirmación en lugar de varias: menos costo y latencia
El impacto más directo está en eficiencia operativa. Cuando una operación cabe en una transacción atómica, el usuario paga una sola firma y espera una sola confirmación en lugar de encadenar varias. Eso reduce tanto el costo —menos fees de prioridad acumulados— como la latencia, un factor crítico en <abbr title="Finanzas descentralizadas, aplicaciones financieras que operan sin intermediarios sobre blockchain">DeFi</abbr> donde milisegundos definen front-running o arbitrajes exitosos.
Desarrolladores que antes fragmentaban operaciones complejas en dos o tres transacciones con dependencias ahora pueden diseñar flujos más simples. La reducción de superficie de ataque —menos puntos de fallo en cadenas de transacciones— también mejora la seguridad en contratos que manejan fondos grandes.
Por qué 4.096 y no otro número
El límite de 4.096 bytes (4 KiB) coincide con el tamaño estándar de página de memoria en hardware de validadores. Esa alineación permite que el protocolo gestione transacciones usando bloques de memoria completos sin overhead adicional. El límite anterior de 1.232 bytes provenía de la arquitectura conservadora inicial de Solana, que usaba una unidad de transmisión máxima (MTU) de 1.280 bytes, dejando 1.232 para el payload tras descontar overhead de red.
Desde la adopción de QUIC en 2022, Solana puede manejar paquetes de red mayores, pero el límite de transacción seguía atado al diseño original. Las propuestas SIMD-0296 y SIMD-0385, co-autorizadas por Jacob Creech y Andrew Fitzgerald del equipo Anza, formalizaron el salto.
Ethereum no tiene límite de tamaño: la brecha se estrecha
Ethereum no impone restricción de tamaño de transacción a nivel de protocolo. Un desarrollador puede empaquetar operaciones arbitrariamente grandes simplemente pagando fees más altos por el gas consumido. Solana, con su modelo de arquitectura diferente, sí tenía ese techo estructural. El upgrade reduce esa brecha técnica, aunque sin cambiar la velocidad de procesamiento —el throughput de bloques sigue igual—.
- Límite nuevo: 4.096 bytes por transacción (3.3x el anterior)
- Límites v1: máximo 64 cuentas y 64 instrucciones por tx
- Testnet: activado martes 1 de septiembre (época 1025)
- Mainnet: activado martes 15 de septiembre a ~01:00 UTC (época 1035)
Riesgo operacional para RPC providers e indexers
La activación trae un requisito crítico de infraestructura. <abbr title="Proveedores de nodos RPC que permiten a aplicaciones leer y escribir datos en la blockchain sin operar un nodo completo">RPC providers</abbr> e <abbr title="Servicios que procesan y organizan datos de blockchain para consultas rápidas">indexers</abbr> deben actualizar a Agave v4.2 o superior para procesar transacciones v1. Sin la actualización, cualquier llamada a <code>getTransaction</code>, <code>getBlock</code> o <code>blockSubscribe</code> que devuelva una tx v1 desencadena el código de error -32015.
Consumidores de RPC necesitan pasar el parámetro <code>maxSupportedTransactionVersion: 1</code> en esas llamadas. Los equipos de infraestructura que no ajusten configuración verán datos de fees incompletos y errores en indexación. Solana Foundation publicó guías técnicas, pero el riesgo recae en cada operador: aplicaciones que dependan de RPC no actualizado verán fallos silenciosos.
Anatoly Yakovenko, co-fundador de Solana, mencionó que el formato mayor podría permitir que una transacción mueva datos atómicamente a través de dos raíces de conocimiento cero, un caso de uso aún por explorar pero que apunta a aplicaciones de privacidad más sofisticadas. La activación llega dos semanas después del testnet —época 1025, martes 1 de septiembre— sin incidencias reportadas en la transición.