Solana desarrolladores están considerando un nuevo conjunto de reglas de protocolo diseñado para hacer que el software de validador 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 de cadena de bloques detrás de Agave, uno de los principales programas de software utilizados para operar la red Solana.
Watt desea que Solana establezca una única especificación autoritativa que defina cómo su cadena de bloques procesa transacciones, valida bloques y alcanza consenso, en lugar de depender de reglas dispersas en software existente y propuestas técnicas separadas.
La variación podría abordar un desafío creciente a medida que Solana se expande más allá de su software original de validador para incluir alternativas desarrolladas independientemente, como Firedancer, construido por la firma de comercio Jump Crypto.
Los validadores son computadoras que verifican transacciones y ayudan a asegurar la cadena de bloques. 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.
Las discrepancias sobre esas reglas podrían hacer que los validadores procesen transacciones idénticas de manera diferente, creando potencialmente visiones contradictorias de la cadena de bloques y amenazando la confiabilidad de la red.
Watt argumenta que el proceso de desarrollo actual 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 Solana Improvement Documents, conocidos como SIMDs. Estos documentos describen actualizaciones individuales, pero las reglas completas de funcionamiento de la red no están consolidadas en una referencia autorizada.
Como resultado, los desarrolladores a veces deben examinar el código de validador existente o reconstruir decisiones de actualización anteriores para comprender qué reglas están activas.
Watt dijo que este enfoque puede producir descripciones repetidas o inconsistentes del comportamiento existente, al tiempo que dificulta identificar cada parte del protocolo afectada por una actualización propuesta.
Un nuevo reglamento podría redefinir 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 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 activen en el mainnet de Solana.
Esto permitiría a los equipos que desarrollan Agave, Firedancer y software de validador futuro trabajar a partir de los mismos requisitos documentados en lugar de depender del código de otra implementación como referencia principal.
¿Dónde comienza el cliente?
La construcción de child-bank aplica la transición de límite de epoch-E una vez antes de sus transacciones.
Un reglamento común hace explícito el objetivo. La confianza en el estado inicial y el siguiente epoch 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 ni el funcionamiento continuo en E+1. No se cuantifica ningún aumento en la confiabilidad del cliente.
También podría hacer que las pruebas de software sean más efectivas. Cuando validadores independientes producen resultados diferentes, los desarrolladores tendrían un estándar común contra el cual examinar la discrepancia 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 procesamiento de transacciones, comunicaciones de red, consenso, tarifas y recompensas para validadores.
Sin embargo, el borrador se limita 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 permanecen compatibles con el tiempo.