Conclusiones clave

1. Solana utiliza un protocolo de chismes peer-to-peer basado en el algoritmo Plumtree, que permite la comunicación descentralizada entre nodos para propagar los cambios de estado de manera eficiente a través de la red sin depender de una fuente central.
2. Cada 0,1 segundos, los nodos de Solana intercambian mensajes "push" y "pull", lo que garantiza un intercambio de información continuo y actualizado para mantener una rápida difusión y sincronización de datos en toda la red.
3. El protocolo de chismes consta de cuatro tipos de mensajes principales (Push, Pull, Prune y Ping/Pong) que ayudan a distribuir datos, solicitar información faltante, administrar las conexiones de los nodos y verificar la vitalidad de los nodos.
4. Los datos de chismes se almacenan en un almacén de datos replicado en clúster (CrdsTable), que se actualiza continuamente con actualizaciones incrementales del estado de la red, lo que garantiza la disponibilidad de los datos y la sincronización entre los nodos.
5. El sistema de archivo de Solana utiliza "nodos de almacén" para almacenar el historial de transacciones, con datos recientes (1-2 épocas) retenidos por los validadores, mientras que el historial de transacciones completo se almacena en Ledger Archives o instancias de Google Bigtable para fácil acceso por parte de RPC y otros participantes.

Chisme

El protocolo Gossip es un método de comunicación entre pares en sistemas distribuidos, donde los nodos de la red intercambian información de estado periódicamente, tanto sobre sí mismos como sobre otros nodos a los que cada uno está conectado, de forma descentralizada. Esto es similar a cómo se propagan los rumores en las redes sociales. Esto implica que cualquier pequeño cambio de estado se propagará eventualmente por la red, y todos los nodos tendrán información completa sobre dicho cambio.

En Solana, la implementación del protocolo Gossip utiliza un método de comunicación informal con un enfoque de difusión de árbol, basado en gran medida en el algoritmo Plumtree. Esto permite la propagación de cambios de estado sin depender de una fuente principal. Actúa como un panel de control para Solana, ya que ayuda a los validadores y nodos RPC a identificar las direcciones y puertos abiertos para la comunicación. Solana Gossip funciona con otros componentes principales, como validadores, protocolo Turbine, nodos de archivo, prueba de historial, etc. Los validadores y las RPC intercambian objetos de datos firmados cada 0,1 segundos a través de UDP mediante Gossip, lo que garantiza la disponibilidad de la información en toda la red. Cada mensaje de Gossip debe tener un tamaño igual o inferior a la unidad máxima de transmisión (MTU) de 1280 bytes, conocida como "estructura de paquete" en el código base.

El protocolo Gossip funciona como un mecanismo central para que los nodos gestionen eficientemente la comunicación del clúster mediante el intercambio continuo de datos firmados, como información de contacto, la altura del libro mayor y los votos. Cada 0,1 segundos, los nodos intercambian mensajes "push" y "pull" (los mensajes push pueden reenviarse y ambos tipos pueden generar respuestas), lo que facilita la rápida difusión de datos por la red. Al operar sobre un puerto o rango de puertos UDP/IP conocido, el protocolo Gossip permite a los nodos anunciar sus puntos finales de Gossip (direcciones de socket) entre sí tras el arranque del clúster. Este gráfico de comunicación descentralizado y de alta frecuencia garantiza la sincronización y la resiliencia de los nodos de Solana, lo que respalda la escalabilidad y el rendimiento de la blockchain.

En el protocolo de chismes de Solana, cuatro tipos de mensajes facilitan la comunicación del clúster: los mensajes push, los más frecuentes, distribuyen datos a un grupo selecto de "pares push". Los mensajes pull, junto con sus respuestas pull, se envían periódicamente para recuperar la información faltante mediante la solicitud y entrega de datos no compartidos. Los mensajes de poda permiten a los nodos reducir sus conexiones activas según sea necesario. Por último, los mensajes ping y pong sirven como comprobaciones de vitalidad, donde un ping genera una respuesta pong para confirmar el estado operativo de un nodo par.

Los datos de Gossip se almacenan en un almacén de datos replicado en clúster (CrdsTable). Esta estructura de datos se actualiza continuamente con mensajes del protocolo Gossip. Estos mensajes contienen registros de Gossip, que son esencialmente actualizaciones incrementales de CrdsTable.

Archivo

Solana se diferencia de otras cadenas de bloques al no requerir el historial completo de transacciones para determinar el estado actual de una cuenta. Su modelo de cuenta garantiza que se conozca el estado en cualquier ranura, lo que permite a los validadores almacenar el estado actual sin necesidad de procesar todos los bloques históricos. Las RPC y los validadores no suelen conservar todo el historial del libro mayor; en su lugar, almacenan solo una o dos épocas (de 2 a 4 días) de datos de transacciones, suficientes para validar el último bloque.

Los datos de archivo se gestionan mediante nodos de almacén, gestionados por proveedores profesionales de servicios RPC, la Fundación Solana y otros participantes del ecosistema, para garantizar el acceso al historial de transacciones. Estos nodos de almacén suelen mantener un archivo de libro mayor, que almacena instantáneas del libro mayor y de AccountsDB para su reproducción desde cero, o una instancia de Google Bigtable, que almacena datos de bloque desde el bloque génesis en adelante en un formato compatible con las solicitudes RPC.

Conclusión

En conclusión, el protocolo de chismes y el sistema de archivo de Solana permiten una comunicación eficiente y la sincronización de datos en toda la red. El protocolo de chismes garantiza una rápida propagación del estado, mientras que el sistema de archivo almacena el historial de transacciones para facilitar el acceso a validadores y RPC. En conjunto, estas características respaldan la escalabilidad, el rendimiento y la descentralización de Solana.