Orígenes: prueba de la historia

Curiosidad

1. ¿Cómo pueden los nodos distribuidos acordar el orden de los eventos sin una sincronización constante?
2. ¿Por qué un planificador de líder determinista permite la ejecución paralela de transacciones?
3. ¿Cuál es la relación entre los tiempos de bloque de subsegundos y los requisitos de hardware del validador?

Explorar

1. Anatoly Yakovenko publicó el white paper de Solana en noviembre de 2017, presentando Proof of History (PoH). PoH genera una secuencia de hashes SHA-256, cada uno derivado del anterior. Este proceso criptográfico funciona como un reloj verificable. Los validadores lo utilizan para establecer el orden temporal sin necesidad de comunicarse entre sí por cada transacción. El mecanismo reduce la carga de comunicación en comparación con los protocolos de consenso que dependen de la latencia de ida y vuelta para la sincronización global.
2. Solana combina PoH con votación por prueba de participación a través de Tower BFT. La beta de la red principal se lanzó el 16 de marzo de 2020. Los bloques se generan en intervalos de aproximadamente 400 milisegundos por un líder designado. El horario determinista permite a los validadores saber exactamente cuándo generarán un bloque. Las transacciones pueden ser enviadas con antelación a los próximos líderes, evitando así el mempool global. La finalidad total se logra en aproximadamente 32 intervalos, o unos 13 segundos.
3. Turbine gestiona la propagación de bloques al fragmentarlos en pequeños trozos distribuidos en paralelo por toda la red, mediante una estructura en forma de árbol. Si la propagación se retrasa, el rendimiento disminuye significativamente. Gulf Stream soluciona la congestión del mempool enviando las transacciones directamente a los líderes futuros antes de que sean incluidas en un bloque. Esto asegura que los validadores reciban los datos de las transacciones lo antes posible, reduciendo la latencia y evitando cuellos de botella durante períodos de alto volumen.
4. Sealevel permite la ejecución paralela de contratos inteligentes porque las transacciones declaran sus dependencias de cuentas con antelación. Si dos transacciones no comparten dependencias de cuentas, Sealevel las ejecuta simultáneamente en múltiples núcleos de CPU. Esto contrasta con los modelos de ejecución secuencial, donde cada transacción espera a que la anterior se complete, independientemente de su independencia lógica. La arquitectura busca procesar miles de transacciones por segundo al maximizar el uso del hardware.
5. La contrapartida es que se requiere hardware de validación potente. Un alto rendimiento exige una gran capacidad de procesamiento y ancho de banda de red para mantener los tiempos de procesamiento. Un segundo cliente independiente, Firedancer de Jump Crypto, se ejecutó primero en la red principal en forma híbrida (‘Frankendancer’) a partir de septiembre de 2024, y como cliente completamente independiente a partir de diciembre de 2025. Esto añade diversidad de clientes a la red, reduciendo la dependencia de una única base de código para la lógica de consenso y ejecución.
6. Para verificar esta arquitectura, abra un explorador de bloques de Solana. Seleccione cualquier ranura reciente. Observe la lista de transacciones incluidas. Tenga en cuenta que el bloque fue generado por un validador específico identificado en los metadatos de dicha ranura. Verifique cuántas transacciones contiene y el tiempo entre ranuras consecutivas, que suele ser de unos 400 milisegundos; sin embargo, algunas ranuras se omiten cuando un líder no logra generar un bloque.

Datos clave

Ejercicio nueve, seis, tres, uno

Verificación de hechos

Fechas, cifras y afirmaciones verificadas con las fuentes publicadas que se enumeran a continuación.

• A. Yakovenko, 'Solana: A new architecture for a high performance blockchain' (2017)
• Solana Foundation, Solana Documentation: Proof of History
• Solana Foundation, Solana Documentation: Turbine and Gulf Stream
• Jump Crypto, Firedancer Technical Overview