Los desarrolladores de Solana proponen una revisión importante para abordar un riesgo oculto que podría interrumpir su red

Los desarrolladores de Solana están considerando un nuevo libro de reglas del protocolo diseñado para hacer que el software de validadores desarrollado de forma independiente sea más confiable y más fácil de mantener.

La propuesta, publicada el 30 de octubre, proviene de Brennan Watt, CEO de Anza, la empresa de ingeniería blockchain detrás de Agave, uno de los principales programas de software utilizados para operar la red de Solana.

Watt quiere que Solana establezca una especificación única y autoritaria que defina cómo su blockchain procesa transacciones, valida bloques y alcanza consenso, en lugar de depender de reglas dispersas en el software existente y propuestas técnicas separadas.

El cambio podría abordar un desafío creciente a medida que Solana se expande más allá de su software de validadores original para incluir alternativas desarrolladas de forma independiente, como Firedancer, creada por la firma de trading Jump Crypto.

Los validadores son computadoras que verifican transacciones y ayudan a asegurar la blockchain. Aunque diferentes desarrolladores pueden crear el software que ejecuta estas computadoras, cada implementación debe seguir las mismas reglas subyacentes para mantener el acuerdo en toda la red.

Los desacuerdos sobre esas reglas podrían hacer que los validadores procesen transacciones idénticas de manera diferente, creando potencialmente visiones conflictivas de la blockchain y amenazando la confiabilidad de la red.

Watt argumenta que el proceso de desarrollo existente de Solana hace que sea innecesariamente difícil para los equipos independientes determinar exactamente cómo se supone que debe comportarse la red.

Bajo el sistema actual, los cambios en el protocolo se proponen a través de Documentos de Mejora de Solana, conocidos como SIMDs. Estos documentos describen actualizaciones individuales, pero las reglas operativas completas de la red no están consolidadas en una referencia autoritaria.

Como resultado, los desarrolladores a veces tienen que examinar el código de los validadores existentes o reconstruir decisiones de actualización anteriores para entender qué reglas están activas.

Watt dijo que este enfoque puede producir descripciones repetidas o inconsistentes del comportamiento existente, mientras que dificulta identificar cada parte del protocolo afectada por una actualización propuesta.

Un nuevo libro de reglas podría remodelar el proceso de actualización de Solana

Bajo la propuesta, los desarrolladores continuarían discutiendo posibles actualizaciones a través del proceso SIMD existente, pero los cambios técnicos formales se presentarían como ediciones a una especificación de protocolo compartida.

Cada enmienda describiría con precisión cómo la actualización afecta las transacciones, las comunicaciones de la red, el consenso y otras funciones relevantes.

Los cambios pasarían por una revisión técnica y cualquier aprobación de gobernanza requerida antes de convertirse en parte de la especificación oficial cuando se activara en la Mainnet de Solana.

Esto permitiría a los equipos que desarrollan Agave, Firedancer y el futuro software de validadores trabajar a partir de los mismos requisitos documentados en lugar de depender del código de otra implementación como su referencia principal.

Dónde comienza y termina el borrador del libro de reglas de Solana

La conformidad hacia adelante comienza desde un estado confiable y se mantiene dentro de la época de referencia 1072.
ENTRADA DE CONFIANZA BORRADOR EPOCA DE REFERENCIA 1072 Estado confiable
Instantánea, o estado autenticado hacia adelante.
Conformidad hacia adelante Aplicar las reglas especificadas dentro de E
Primer banco de E+1 Fuera de esta versión
Las reglas retiradas anteriormente no necesitan ser reproducidas.
Límite de alcance esquemático; el espaciado no representa tiempo.
epoch-E raíz
BORRADOR EPOCA DE REFERENCIA 1072 Entrada de confianza Estado confiable
Instantánea, o estado autenticado hacia adelante.
Conformidad hacia adelante Aplicar las reglas especificadas dentro de E
Solo Primer banco de E+1 Fuera de esta versión
Las reglas retiradas anteriormente no necesitan ser reproducidas.
Esquemático; el espaciado no representa tiempo.
hacia la raíz epoch-E

¿Dónde comienza el cliente?

¿Dónde comienza el cliente? Último banco antes de E Ya dentro de E La construcción del banco hijo aplica la transición de frontera de época-E una vez antes de sus transacciones. ÚLTIMO BANCO ANTES DE E Estado confiable Aplicar una vez Transición de frontera de época DENTRO DE E Transacciones Antes de las transacciones del banco hijo Último banco antes de E Aplicar una vez Transición de frontera de época Transacciones dentro de E La transición precede a estas transacciones El estado confiable ya incluye la transición de frontera de época, por lo que no debe aplicarse nuevamente. DENTRO DE E DENTRO DE E Estado confiable Transacciones La transición de frontera ya incluida en el estado inicial Ya dentro de E Estado confiable La transición de frontera ya incluida en el estado inicial Transacciones en E Continuar sin repetir la transición.

Un libro de reglas común hace que el objetivo sea explícito. La confianza en el estado inicial y la próxima época siguen siendo requisitos separados.

Esta es una especificación preliminar, no un cambio de protocolo adoptado. No establece la corrección del estado inicial, la reproducción histórica o la operación continua en E+1. No se cuantifica ninguna ganancia de confiabilidad del cliente. Fuentes y evidencia

Fuentes

1. Alcance y conformidad
2. Borrador de época de referencia

Hechos de apoyo

• La página de aterrizaje del borrador identifica su época de referencia de Mainnet como E=1072; el alcance comienza una implementación desde un instantáneo confiable para esa época u otro estado autenticado a una raíz de época-1072. [2] [1]
• El borrador requiere conformidad hacia adelante dentro de su época de referencia y no requiere reproducir codificaciones o ramas de reglas que dejaron de ser aceptadas antes de esa época. [1]
• El borrador se aplica solo a bancos en la época de referencia E y explícitamente no define el primer banco de E+1, por lo que la conformidad a esta versión por sí sola no establece la operación continua a través de esa frontera. [1]
• Bajo el borrador, una implementación que comienza en el último banco antes de E aplica la transición de frontera de época una vez; un estado inicial ya dentro de E no debe aplicarla nuevamente. [1]
• La conformidad hacia adelante deja el instantáneo inicial o la raíz autenticada como una entrada de confianza: el borrador comienza después de que esa entrada ha sido aceptada en lugar de requerir que un nuevo cliente pruebe toda la cadena anterior mediante reproducción. [1]

Método

Esquema basado en la página de aterrizaje del borrador y el capítulo de alcance capturado el 4 de noviembre de 2026. Dos estados de inicialización seleccionables reproducen la regla de frontera del borrador; la geometría es cualitativa, sin escala de duración o rendimiento.

Alcance

Esta es una especificación preliminar, no un cambio de protocolo adoptado. No establece la corrección del estado inicial, la reproducción histórica o la operación continua en E+1. No se cuantifica ninguna ganancia de confiabilidad del cliente. Infografía por CryptoSlate

También podría hacer que las pruebas de software sean más efectivas. Cuando los validadores independientes producen resultados diferentes, los desarrolladores tendrían un estándar común contra el cual examinar el desacuerdo e identificar qué implementación necesita corrección.

Watt ya ha publicado una especificación preliminar que cubre 18 áreas de las operaciones de Solana, incluyendo el procesamiento de transacciones, comunicaciones de red, consenso, tarifas y recompensas para validadores.

Sin embargo, el borrador sigue limitado a un período definido de la historia de la cadena de bloques de Solana y asume que los desarrolladores comienzan desde un estado de red ya confiable. Se necesitaría más trabajo para cubrir actualizaciones posteriores y establecer que las implementaciones sigan siendo compatibles con el tiempo.

Este contenido se ofrece únicamente con fines informativos generales y no constituye asesoramiento financiero, de inversión, legal ni fiscal. Cualquier evento, recompensa, promoción en línea o información relacionada que se mencione en el presente documento no debe considerarse como una recomendación, solicitud o invitación a comprar, vender, tradear o de negociar de otra manera con cualquier criptoactivo. Los criptoactivos son sumamente volátiles y pueden provocar pérdidas. La disponibilidad de los servicios, productos y eventos relacionados de WEEX puede variar según la región. Tienes la responsabilidad de asegurarte de que tu participación esté de acuerdo con las leyes y regulaciones locales vigentes.