Solana dimensiona su nuevo límite de transacción de 4.096 bytes a una página de memoria

Solana está preparada para triplicar la cantidad de datos que una sola transacción puede transportar el 9 de septiembre. Este nuevo techo de 4.096 bytes cabe en una sola página de memoria de 4 KiB del hardware del validador, según la propuesta SIMD-0296 en GitHub.

Las cargas de trabajo que requieren múltiples transacciones ahora toman una llamada atómica para completarse.

QUIC hizo que el límite de 1,232 bytes fuera inútil

El límite original de Solana era una precaución de red. La red operaba con un MTU IPv6 de 1.280 bytes.

Eso dejaba 1.232 bytes para la carga útil de una transacción después de la sobrecarga del protocolo, escriben los autores de SIMD-0296. Eso tiene sentido cuando cada mensaje tenía que pasar a través del MTU sin fragmentación.

Solana cambió a QUIC como su forma estándar de manejar transacciones en 2022. RFC 9000 no establece un tamaño máximo de flujo, por lo que cargas útiles más grandes pueden pasar sin problemas a nivel de red.

El límite de 1.232 bytes se había convertido en una regla sin base técnica.

Los dos documentos fueron redactados por los ingenieros de Anza Jacob Creech y Andrew Fitzgerald. SIMD-0296 aumenta el límite de tamaño.

Un compañero, SIMD-0385, define el formato de mensaje v1, que contiene los bytes adicionales. El par resuelve una restricción que los desarrolladores han estado esquivando desde el lanzamiento de la cadena.

La propuesta prefiere 4.096 bytes sobre el tamaño más grande permitido por QUIC para que una transacción quepa en una sola página estándar de 4 KiB de memoria del validador. Ninguna transacción cruza nunca el límite de una página.

La gestión de memoria por transacción es barata. Cada transacción está restringida a una sola página.

Para llegar al límite de 4.096 bytes, Creech y Fitzgerald analizaron cómo los desarrolladores usaban paquetes Jito para eludir las viejas restricciones:

• El 50% de los paquetes enviados eran de 2,048 bytes o menos.
• El 65% estaba por debajo de 6,144 bytes.
• El 100% permaneció por debajo de 9,216 bytes.

Un techo de 4.096 bytes cubre la gran mayoría de estas cargas de trabajo de múltiples transacciones en una sola llamada mientras se mantiene dentro de los límites de página del hardware del validador.

Las llamadas RPC no preparadas ahora lanzan el error -32015 en Solana

La capacidad adicional permite cargas de trabajo que exceden el límite de 1.232 bytes.

Las pruebas de conocimiento cero, como las utilizadas en las Transferencias Confidenciales de Extensiones de Tokens, generaron cargas útiles que excedían el límite de 1.232 bytes.

Para resolver este problema, los desarrolladores encadenaban múltiples llamadas o renunciaban a transferencias encriptadas atómicas. El nuevo límite de 4.096 bytes acomoda las pruebas de conocimiento cero en una sola transacción.

La agregación de firmas BLS y las configuraciones grandes de multisig también se benefician de este cambio. SIMD-0296 cita la multisig anidada, el tipo de multisig utilizado por tesorerías institucionales y DAOs a través de Squads, como uno de los principales impulsores.

También hace referencia a las firmas de un solo uso Winternitz y a los esquemas BLS en cadena que funcionan sin precompilaciones.

El formato rechaza las Tablas de Búsqueda de Direcciones, que v0 usaba para hacer referencia a hasta 64 cuentas con índices cortos. Las tablas añaden complejidad sin beneficio porque ahora hay 64 direcciones inline de 32 bytes, que solo ocupan 2.048 bytes, muy por debajo del techo.

El límite de 64 cuentas para cada transacción permanece en la red Solana. Las aplicaciones con muchas cuentas aún alcanzarán el límite incluso con el problema del presupuesto de bytes resuelto.

Los paquetes Jito permiten a los desarrolladores fusionar hasta cinco transacciones en una secuencia todo o nada para resolver el problema de la limitación de bytes.

La transacción v1 logra el mismo resultado atómico en una sola transacción. Trae atomicidad nativa directamente a la capa base.

V1 es opcional para los remitentes, por lo que las transacciones heredadas y v0 continúan funcionando. Las notas de migración de la Fundación Solana indican que se trata de un cambio disruptivo para la infraestructura que lee bloques

Si las herramientas de datos y los exploradores de bloques no se actualizan para la nueva versión de Solana, se congelarán por completo o emitirán errores.

Cuando una aplicación intenta leer una transacción o bloque v1 sin el parámetro de nueva versión, los servidores de Solana rechazan la solicitud con un código de error del sistema -32015.

Las herramientas que transmiten continuamente bloques en vivo se encontrarán con una nueva transacción v1, recibirán una respuesta completamente en blanco y se detendrán allí.

Los indexadores, o herramientas que registran datos de transacciones, muestran tarifas de prioridad cero para las nuevas transacciones porque están buscando en el lugar equivocado.

Antes leían estas tarifas de una lista especial dentro de la transacción. En la nueva versión, esa información se mantiene en su propia caja de resumen dedicada.

Anza está requiriendo que los proveedores de RPC actualicen a Agave v4.2. Helius ha emitido una lista de verificación de migración que detalla el trabajo.

La transacción v1 se activó en la testnet de Solana durante el epoch 1025 el 1 de septiembre. Anza programó oficialmente el despliegue en mainnet para el 9 de septiembre.