Solana podría recibir un impulso turbo mientras Firedancer apunta a las restricciones de bloques

El impulso de rendimiento de Solana ganó nuevo momentum esta semana cuando los ingenieros detrás de Firedancer, el cliente validador alternativo de alto rendimiento liderado por Jump, presentaron un nuevo Documento de Mejora de Solana (SIMD-0370) para eliminar el límite de unidad de cómputo (CU) a nivel de bloque de la red—un cambio que argumentan es ahora redundante después de Alpenglow y que se traduciría inmediatamente en mayor rendimiento y menor latencia cuando la demanda aumenta.

Próximo Turbo Boost Para Solana

La solicitud de extracción, escrita por el "Equipo Firedancer" y abierta el 24 de septiembre de 2025, está explícitamente enmarcada como una propuesta "post-Alpenglow". En Alpenglow, los nodos votantes transmiten un SkipVote si no pueden ejecutar un bloque propuesto dentro del tiempo asignado. Debido a que los bloques lentos se omiten automáticamente, los autores sostienen que un límite de CU por bloque impuesto por protocolo separado es innecesario.

"En Alpenglow, los nodos votantes transmiten un SkipVote si no logran ejecutar un bloque a tiempo... Este SIMD por lo tanto elimina la aplicación del límite de unidad de cómputo de bloque", afirma el documento, describiendo el límite como superfluo bajo las reglas de programación actualizadas.

Más allá de la limpieza técnica, los autores proponen una alineación económica más precisa. El actual límite de CU a nivel de bloque, argumentan, rompe los incentivos al limitar la capacidad mediante protocolo en lugar de mejoras de hardware y software. Eliminarlo permitiría a los productores llenar bloques hasta lo que sus máquinas pueden procesar y propagar de manera segura, llevando la competencia de clientes y hardware al primer plano.

"La capacidad de la red está determinada no por las capacidades del hardware sino por el límite arbitrario de unidad de cómputo de bloque", escriben, antes de explicar por qué levantar ese límite realinearía los incentivos tanto para los clientes validadores como para los desarrolladores de programas.

Los primeros comentarios de revisión de código de los contribuyentes principales y equipos de clientes subrayan tanto el impacto a corto plazo para el usuario como los límites del cambio. Un revisor resumió la ventaja práctica: "Eliminar el límite hoy tiene beneficios tangibles para el ecosistema y los usuarios finales... sin esperar a que se desarrolle la arquitectura futura de la red". Otro enfatizó que algunas restricciones de bloque permanecerían, citando un "límite máximo de fragmentos", mientras que otros sugirieron que la red probablemente debería mantener los límites de CU por transacción por ahora y tratar cualquier cambio allí como una discusión separada y de mayor alcance.

Las consideraciones de seguridad y actividad destacan prominentemente. Los revisores pidieron que la propuesta explicara explícitamente por qué se preserva la seguridad incluso si un bloque es demasiado pesado para propagarse a tiempo; la respuesta de Alpenglow es que tales bloques simplemente no reciben votos, es decir, se omiten—manteniendo el progreso sin penalizar la red. Los autores de Firedancer coinciden en que la barrera decisiva es el reloj y el presupuesto de propagación, no un límite estático de CU.

La propuesta también aborda una preocupación frecuente en los debates sobre rendimiento: la coordinación. Si un productor de bloques actualiza el hardware agresivamente mientras otros se retrasan, ¿corre la red el riesgo de rotación por bloques omitidos? Un revisor señala que los productores demasiado ambiciosos ya se autocalibran porque los bloques perdidos significan recompensas perdidas, limitando naturalmente el tamaño del bloque a lo que los pares pueden aceptar a tiempo. El documento argumenta además que, con el límite de CU eliminado, las fuerzas del mercado gobiernan la capacidad: los productores y equipos de clientes que optimizan la ejecución, la red y la programación ganarán más bloques y comisiones, empujando la frontera hacia afuera según lo justifique la demanda.

Crucialmente, SIMD-0370 es compatible con el futuro. Los diseños en curso para múltiples proponentes concurrentes—un elemento de hoja de ruta a largo plazo para Solana—a veces asumen un límite de bloque y a veces no. Los revisores enfatizan que eliminar el límite actual no impide arquitecturas de proponentes concurrentes más adelante; simplemente desbloquea mejoras que "pueden realizarse hoy".

Mientras que la discusión de GitHub proporciona la parte técnica, Anza—el equipo cliente de Solana detrás de Agave—también ha amplificado la propuesta en canales sociales, señalando una amplia atención del equipo cliente al cambio y sus implicaciones orientadas al usuario.

¿Qué cambiaría para los usuarios y desarrolladores si se implementa SIMD-0370? En períodos pico—airdrops, acuñaciones, volatilidad del mercado—los bloques podrían llevar más cómputo siempre que puedan ser ejecutados y propagados dentro del tiempo de ranura, potencialmente aumentando el rendimiento sostenido y suavizando los picos de comisiones.

Para los desarrolladores de Solana, un mayor margen y incentivos más fuertes para la optimización de cliente/hardware podrían reducir la latencia de cola para cargas de trabajo exigentes, aunque con la necesidad continua de optimizar programas para paralelismo y localidad. Para los validadores, la ventaja competitiva se inclinaría aún más hacia la eficiencia de ejecución, el rendimiento de la red y las políticas inteligentes de construcción de bloques que equilibran los ingresos por comisiones contra el riesgo de producir un bloque tan pesado que se omita.

Como con todos los SIMD, el cambio está sujeto a revisión comunitaria, implementación y coordinación de despliegue entre clientes validadores. Pero la dirección es clara. Post-Alpenglow, los diseñadores de Solana creen que el presupuesto de tiempo de ranura es el verdadero limitador.

Al momento de la publicación, Solana cotizaba a $205.38.