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

Solana triplicará la cantidad de datos que puede contener una sola transacción a partir del 9 de septiembre. Este nuevo límite de 4096 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 se completan con una sola llamada atómica.

QUIC hizo que el límite de 1232 bytes fuera innecesario

El límite original de Solana era una medida de precaución en la red. La red operaba con una MTU IPv6 de 1280 bytes.

Según los autores de SIMD-0296, esto dejaba 1232 bytes para la carga útil de una transacción tras la sobrecarga del protocolo. Esto tiene sentido, ya que cada mensaje debía pasar por la MTU sin fragmentación.

Solana adoptó QUIC como su método estándar para gestionar transacciones en 2022. El RFC 9000 no establece un tamaño máximo para el flujo de datos, por lo que las cargas útiles más grandes pueden transmitirse sin problemas a nivel de red.

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

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

Un complemento, SIMD-0385, defiel formato de mensaje v1, que contiene los bytes adicionales. Este par resuelve una limitación que los desarrolladores habían estado eludiendo desde el lanzamiento de la cadena.

La propuesta prefiere 4096 bytes al tamaño máximo 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 jamás el límite de una página.

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

Para llegar al límite de 4096 bytes, Creech y Fitzgerald analizaron cómo los desarrolladores utilizaban los paquetes Jito para sortear las antiguas restricciones:

• El 50% de los paquetes enviados tenían un tamaño de 2.048 bytes o menos.
• El 65% tenía menos de 6.144 bytes.
• El 100% se mantuvo por debajo de los 9.216 bytes.

Un límite de 4096 bytes cubre la gran mayoría de estas cargas de trabajo de múltiples transacciones en una sola llamada, sin exceder las limitaciones de páginas del hardware del validador.

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

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

Las pruebas de conocimiento cero, como las utilizadas en las transferenciasdentde Token Extensions, generaron cargas útiles que superaron el límite de 1232 bytes.

Para solucionar este problema, los desarrolladores encadenaron varias llamadas o prescindieron de las transferencias atómicas cifradas. El nuevo límite de 4096 bytes permite incluir pruebas de conocimiento cero en una sola transacción.

La agregación de firmas BLS y las configuraciones multifirma de gran tamaño también se benefician de este cambio. SIMD-0296 cita la multifirma anidada, el tipo de multifirma que utilizan las tesorerías institucionales y las DAO a través de Squads, como uno de los principales impulsores.

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

El formato prescinde de las tablas de búsqueda de direcciones, que la versión 0 utilizaba para referenciar hasta 64 cuentas con índices cortos. Estas tablas añaden complejidad sin ningún beneficio, ya que ahora hay 64 direcciones en línea de 32 bytes, que solo ocupan 2048 bytes, muy por debajo del límite.

En la red por transacción se mantiene Solana . Las aplicaciones con un alto volumen de transacciones seguirán alcanzando este límite incluso después de que se haya solucionado el problema del presupuesto de bytes. el límite de 64 cuentas

Los paquetes de Jito permiten a los desarrolladores fusionar hasta cinco transacciones en una secuencia de 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. Aporta atomicidad nativa directamente a la capa base.

V1 es opcional para los remitentes, por lo que las transacciones heredadas y v0 siguen funcionando. Solana de migración de la Fundación Las notas indican que se trata de un cambio importante 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 bloquearán por completo o mostrarán errores.

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

Las herramientas que transmiten bloques en directo de forma continua llegarán a una nueva transacción v1, recibirán una respuesta completamente en blanco y se quedarán bloqueadas.

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

Antes, estas comisiones se consultaban en una lista especial dentro de la transacción. En la nueva versión, esa información se guarda en un recuadro de resumen específico.

Anza exige a los proveedores de RPC que actualicen a Agave v4.2. Helius ha publicado una lista de verificación de migración que detalla el trabajo a realizar.

La transacción v1 se activó en la red de prueba Solana durante la época 1025, el 1 de septiembre. Anza programó oficialmente el despliegue en la red principal para el 9 de septiembre.