Resumen ejecutivo de Solana

Introducción

Solana es una blockchain de alto rendimiento y baja latencia reconocida por su velocidad, eficiencia y enfoque en la experiencia del usuario. Su arquitectura integrada única permite procesar miles de transacciones por segundo en una red descentralizada a escala global. Con un tiempo de bloque de 400 milisegundos y comisiones por transacción de fracciones de centavo, ofrece velocidad y rentabilidad. Este informe profundiza en los detalles del diseño y funcionamiento de Solana. Explora los mecanismos clave y la topología de red que sustentan sus capacidades.

Solana adopta un enfoque integrado para el desarrollo de blockchain y aprovecha las décadas de experiencia de su equipo fundador en la creación de sistemas distribuidos. Uno de los principios fundamentales de Solana es que el software nunca debe limitar al hardware. Esto significa que el software aprovecha al máximo el hardware donde se ejecuta y escala con él. Como ecosistema unificado, todas las aplicaciones creadas sobre esta única blockchain heredan la composabilidad, lo que les permite interactuar e integrarse entre sí sin dificultades. Esta arquitectura también ofrece una experiencia de usuario sencilla e intuitiva, sin necesidad de puentes, identificadores de cadenas independientes ni fragmentación de liquidez.

Solana evoluciona con rapidez. Entre los avances recientes se encuentran los rollups de SVM y ZK Compression como soluciones importantes de escalabilidad. Aunque algún día estos proyectos podrían definir nuestra percepción futura de Solana, actualmente se encuentran en etapas muy tempranas de desarrollo o adopción y no se abordarán en este informe.

Ciclo de vida de una transacción

A lo largo de este informe, analizaremos Solana principalmente mediante el ciclo de vida de una transacción típica. Para construir un modelo básico que permita comprender las transacciones de Solana, podemos resumir el proceso así: 

• Los usuarios inician transacciones que se envían al productor de bloques principal actual, conocido como líder. El líder agrupa estas transacciones en un bloque, las ejecuta y actualiza así su estado local.
• Después, este bloque de transacciones se propaga por toda la red para que otros validadores lo ejecuten y confirmen.‍

Las siguientes secciones de este informe ampliarán este modelo y profundizarán mucho más en el proceso, comenzando por los participantes clave: los usuarios.

Seis etapas

A lo largo de este informe haremos referencia al gráfico de seis etapas anterior, ya que ofrece un marco coherente para comprender las relaciones entre los elementos centrales de Solana.

Los primeros capítulos están organizados según estas seis etapas. Los capítulos finales —Gossip, Archivo, Economía y Jito— cubren los temas restantes. Es importante señalar que algunos capítulos abarcarán varias etapas y que algunas etapas aparecerán en varios capítulos.

Esta superposición es inevitable porque el marco de seis etapas tiene limitaciones. En realidad, Solana es un sistema distribuido complejo con muchos elementos interdependientes.

Usuarios

El recorrido de un usuario suele comenzar con la configuración y el depósito de fondos en una aplicación de billetera. Solana cuenta con varias aplicaciones de billetera populares, disponibles como aplicaciones móviles nativas o extensiones de navegador.

Las billeteras generan criptográficamente pares de claves para los usuarios, formados por claves públicas y privadas. La clave pública funciona como identificador único de su cuenta y todos los participantes de la red la conocen. Una cuenta de usuario en Solana puede considerarse una estructura de datos que almacena información y estado relacionados con sus interacciones con la blockchain de Solana. Así, una clave pública se parece al nombre de un archivo: al igual que este identifica de forma única un archivo dentro de un sistema de archivos, una clave pública de Solana identifica de forma única una cuenta en la blockchain de Solana. Las claves públicas de Solana se representan como cadenas de 32 bytes codificadas en Base58.

FDKJvWcJNe6wecbgDYDFPCfgs14aJnVsUfWQRYWLn4Tn

Una clave privada —también conocida como clave secreta— puede considerarse la contraseña o clave de acceso que concede permiso para acceder a la cuenta y modificarla. Las blockchains gestionan la autorización mediante firmas con claves privadas. Conocer la clave privada otorga autoridad absoluta sobre la cuenta. Las claves privadas de Solana también tienen una longitud de 32 bytes. Los pares de claves son combinaciones de 64 bytes compuestas por claves públicas (primera mitad) y privadas (segunda mitad).

Ejemplos:

3j15jr41S9KmdfughusutvvqBjAeEDbU5sDQp8EbwQ3Hify2pfM1hiEsuFFAVq8bwGywnZpswrbDzPENbBZbd5nj

[63,107,47,255,141,135,58,142,191,245,78,18,90,162,107,197,8,33,211,15,228,235,250,30,185,122,105,23,147,115,115,86,8,155,67,155,110,51,117,0,19,150,143,217,132,205,122,91,167,61,6,246,107,39,51,110,185,81,13,81,16,182,30,71]

Las claves privadas también pueden derivarse de frases semilla mnemónicas, generalmente de 12 o 24 palabras. Las billeteras suelen utilizar este formato para facilitar las copias de seguridad y la recuperación. Es posible derivar de forma determinista varias claves a partir de una sola frase semilla.

Solana utiliza Ed25519, un algoritmo de firma digital de curva elíptica ampliamente usado, para sus necesidades de criptografía de clave pública. Ed25519 destaca por el tamaño reducido de sus claves y firmas, su rapidez de cálculo y su resistencia a muchos ataques comunes. Cada dirección de billetera de Solana representa un punto en la curva elíptica Ed25519.

El usuario firma las transacciones con su clave privada. Esta firma se incluye con los datos de la transacción y otros participantes pueden verificarla mediante la clave pública del remitente. Este proceso garantiza que nadie haya manipulado la transacción y que el propietario de la clave privada correspondiente la haya autorizado. La firma también funciona como identificador único de la transacción.

Transacciones de Solana‍

Enviar una transacción es la única forma de modificar el estado en Solana. Todas las operaciones de escritura se realizan mediante una transacción, y las transacciones son atómicas: se ejecuta todo lo que intenta hacer la transacción o esta falla. Una transacción, conocida formalmente como «mensaje de transacción», consta de cuatro secciones: un encabezado, una lista de direcciones de cuentas, un hash de bloque reciente e instrucciones.

Encabezado

El encabezado contiene referencias a la lista de direcciones de cuentas e indica qué cuentas deben firmar la transacción.

Direcciones de cuentas

Esta lista incluye todas las cuentas que se leerán o escribirán durante la transacción. Crear una lista de este tipo para cada transacción es un requisito exclusivo de Solana y puede resultar difícil para los desarrolladores. Sin embargo, saber de antemano con qué partes del estado interactuará una transacción permite optimizaciones que no son posibles en muchas otras blockchains.

Hash de bloque reciente

Se utiliza para evitar transacciones duplicadas y obsoletas. Un hash de bloque reciente vence después de 150 bloques (aproximadamente 1 minuto). De forma predeterminada, los RPC intentan reenviar las transacciones cada 2 segundos hasta que la transacción se finaliza o vence el hash de bloque reciente. En ese momento, la transacción se descarta.

Instrucciones

Estas conforman la parte central de la transacción. Cada instrucción representa una operación específica (p. ej., transferir, acuñar, quemar, crear una cuenta o cerrar una cuenta). Cada instrucción especifica el programa que se ejecutará, las cuentas necesarias y los datos requeridos para ejecutarla.

El número de instrucciones de una transacción está limitado primero por su tamaño, que puede alcanzar los 1232 bytes. También existen límites para el número de cuentas que pueden referenciarse. Por último, hay límites para la complejidad de una transacción, medida en unidades de cómputo (CU). Las CU cuantifican los recursos computacionales consumidos al procesar transacciones.

El costo en SOL de ejecutar una transacción se divide en 2 partes: una comisión base y una comisión de prioridad. La comisión base es un costo fijo de 5000 lamports por firma, independientemente de la complejidad de la transacción. Por lo general, cada transacción tiene 1 firma.

Las comisiones de prioridad son técnicamente opcionales, pero resultan necesarias durante periodos de alta demanda de espacio en los bloques. Estas comisiones se calculan en microlamports (una millonésima parte de un lamport) por unidad de cómputo. Su propósito es funcionar como señal de precio para que incluir las transacciones en sus bloques resulte más atractivo económicamente para los nodos validadores. ‍

total fee = prioritization fee + base fee

prioritization fee = compute unit price (micro-lamports) x compute unit limit

Actualmente, se quema el 50 % de todas las comisiones relacionadas con transacciones. Esto retira permanentemente esos SOL de circulación, mientras que el 50 % restante se entrega al productor del bloque. Pronto se introducirá un cambio nuevo (SIMD 96) que permitirá entregar al productor del bloque el 100 % de las comisiones de prioridad. Las comisiones base no cambiarán.

Envío de transacciones

El usuario conecta su billetera a la aplicación, lo que permite que esta lea su clave pública. La clave privada permanece cifrada y aislada de forma segura en un entorno separado de la aplicación.

La aplicación crea los parámetros del mensaje de transacción a partir de las interacciones del usuario. Por ejemplo, si un usuario quisiera intercambiar dos tokens, especificaría la cantidad de tokens que desea comprar, los tokens correspondientes que desea vender y un deslizamiento aceptable para la transacción.

Cuando el mensaje de transacción está listo, se envía a la billetera para firmarlo con la clave privada del usuario. En ese momento, aparece una ventana emergente que solicita al usuario confirmar que desea realizar la transacción. Esta ventana puede incluir una simulación de los resultados de la transacción. Una vez firmado, el mensaje de transacción y la firma regresan a la aplicación. Esta puede reenviar la transacción al proveedor de RPC que elija, ya sea uno propio o el proveedor de la billetera.

Los proveedores de RPC (llamada a procedimiento remoto) actúan como intermediarios entre las aplicaciones y los validadores que crean bloques. Son un servicio esencial que permite a las aplicaciones enviar o simular transacciones firmadas y recuperar datos on-chain de manera eficiente. Las aplicaciones que desean interactuar con la red lo hacen mediante un endpoint JSON-RPC o WebSocket (documentación).

Gulf Stream

Los RPC (llamadas a procedimientos remotos) hacen referencia a los nodos RPC. Estos nodos pueden considerarse puertas de enlace para interactuar con la red y leer sus datos. Ejecutan el mismo software que los validadores completos, pero con una configuración distinta. Esto les permite simular transacciones con precisión y mantener una vista actualizada del estado actual. Al momento de escribir este informe, hay más de 4000 nodos RPC en la red Solana.

A diferencia de los nodos validadores completos, los nodos RPC no tienen participación en la red. Sin participación, no pueden votar ni crear bloques. Esta configuración difiere de la mayoría de las demás blockchains, donde los nodos validadores y RPC suelen ser los mismos. Como los nodos RPC no reciben recompensas de staking, su modelo económico es distinto al de los validadores. Muchos operan como un servicio de pago para desarrolladores que ejecutan aplicaciones de Solana.

Solana destaca porque fue diseñada desde el principio para funcionar sin mempool. A diferencia de las blockchains tradicionales, que utilizan protocolos de gossip para propagar transacciones de manera aleatoria y amplia por toda la red, Solana reenvía todas las transacciones a un validador principal predeterminado para cada slot, conocido como líder.

Cuando un RPC recibe un mensaje de transacción que debe incluirse en un bloque, tiene que reenviarlo al líder. Antes de cada época (aproximadamente cada dos días) se crea una programación de líderes. La siguiente época se divide en slots de 400 milisegundos cada uno y se elige un líder para cada slot. Los validadores con mayor participación tienen más probabilidades de ser elegidos como líderes dentro de cada época. Durante cada slot, los mensajes de transacción se reenvían al líder, quien tiene la oportunidad de producir un bloque. Cuando llega el turno de un validador, este cambia al «modo líder» y comienza a procesar transacciones y transmitir bloques de forma activa al resto de la red.

Calidad de servicio ponderada por participación: SWQoS

A principios de 2024, Solana presentó un nuevo mecanismo para evitar el spam y reforzar la resistencia a ataques Sybil, conocido como calidad de servicio ponderada por participación (SWQoS). Este sistema permite que los líderes prioricen los mensajes de transacción que pasan por otros validadores con participación. Los validadores con mayor participación reciben una capacidad proporcionalmente superior para transmitir paquetes de mensajes de transacción al líder. Este enfoque mitiga eficazmente los ataques Sybil de nodos sin participación en toda la red.

‍Con este modelo, los validadores también pueden celebrar acuerdos para alquilar a los nodos RPC su capacidad ponderada por participación. A cambio, los nodos RPC obtienen más ancho de banda, lo que les permite alcanzar mayores tasas de inclusión de transacciones en los bloques. Cabe destacar que el 80 % de la capacidad de un líder (2000 conexiones) está reservado para SWQoS. El 20 % restante (500 conexiones) se destina a mensajes de transacción provenientes de nodos sin participación. Esta estrategia de asignación se asemeja a los carriles prioritarios de las autopistas, donde los conductores pagan un peaje para evitar el tráfico.

SWQoS ha repercutido en el ecosistema de Solana al elevar los requisitos para reenviar transacciones al líder y reducir la eficacia de los ataques de spam. Este cambio ha incentivado a las aplicaciones con mucho tráfico a integrar verticalmente sus operaciones. Al ejecutar sus propios nodos validadores o acceder a conexiones con participación, las aplicaciones pueden garantizar un acceso privilegiado al líder y mejorar así su capacidad de procesamiento de transacciones.

Una nota sobre QUIC

A finales de 2022, Solana adoptó el protocolo de red QUIC para gestionar la transmisión de mensajes de transacción al líder. La transición respondió a las interrupciones de la red provocadas por bots que saturaban las acuñaciones de NFT on-chain. QUIC facilita una comunicación rápida y asíncrona.

‍Desarrollado inicialmente por Google en 2012, QUIC intenta ofrecer lo mejor de ambos mundos. Facilita una comunicación rápida y asíncrona similar a UDP, pero con las sesiones seguras y las estrategias avanzadas de control de flujo de TCP. Esto permite imponer límites a fuentes individuales de tráfico para que la red pueda concentrarse en procesar transacciones legítimas. También incorpora el concepto de streams independientes; así, si se descarta una transacción, no es necesario bloquear las restantes. En resumen, QUIC intenta combinar las mejores características de TCP y UDP.

Creación de bloques

Muchas redes blockchain construyen bloques completos antes de transmitirlos, un proceso conocido como creación discreta de bloques. En cambio, Solana utiliza la creación continua de bloques, que consiste en ensamblar y transmitir bloques dinámicamente a medida que se crean durante un slot asignado. Esto reduce considerablemente la latencia.

Cada slot dura 400 milisegundos y a cada líder se le asignan cuatro slots consecutivos (1,6 segundos) antes de rotar al siguiente líder. Para que un bloque sea aceptado, todas sus transacciones deben ser válidas y reproducibles por otros nodos.

Dos slots antes de asumir el liderazgo, el validador deja de reenviar transacciones para prepararse para la carga de trabajo que recibirá. Durante este intervalo, el tráfico entrante se dispara y supera un gigabyte por segundo, ya que toda la red dirige sus paquetes al próximo líder.

Al recibirse, los mensajes de transacción ingresan a la Unidad de Procesamiento de Transacciones (TPU), la lógica central del validador responsable de producir bloques. La secuencia de procesamiento comienza en la etapa de recepción, donde las transacciones llegan mediante QUIC. Después, avanzan a la etapa SigVerify, donde se someten a rigurosas comprobaciones de validación. El validador comprueba que las firmas sean válidas, verifica que su número sea correcto y elimina las transacciones duplicadas.

‍Etapa bancaria

La etapa bancaria puede describirse como la etapa de creación de bloques. Es la etapa más importante de la TPU y recibe su nombre del «banco». Un banco es simplemente el estado de un bloque determinado. Para cada bloque, Solana tiene un banco que permite acceder al estado de ese bloque. Cuando un bloque se finaliza después de que suficientes validadores votan por él, estos transfieren al disco las actualizaciones de las cuentas del banco para hacerlas permanentes. El estado final de la cadena es el resultado de todas las transacciones confirmadas. Este estado siempre puede recrearse de forma determinista a partir del historial de la blockchain.‍

Las transacciones se procesan en paralelo y se agrupan en «entradas» del ledger, que son lotes de 64 transacciones sin conflictos. El procesamiento paralelo de transacciones en Solana resulta sencillo porque cada transacción debe incluir una lista completa de todas las cuentas que leerá y escribirá. Esta decisión de diseño supone una carga para los desarrolladores, pero permite que el validador evite condiciones de carrera al seleccionar fácilmente para cada entrada solo transacciones sin conflictos. Dos transacciones entran en conflicto si ambas intentan escribir en la misma cuenta (dos escrituras) o si una intenta leerla y la otra escribir en ella (lectura + escritura). Por lo tanto, las transacciones en conflicto se incluyen en entradas distintas y se ejecutan de forma secuencial, mientras que las transacciones sin conflictos se ejecutan en paralelo.

Seis hilos procesan transacciones en paralelo: cuatro están dedicados a transacciones normales y dos gestionan exclusivamente transacciones de voto, que son esenciales para el mecanismo de consenso de Solana. Todo el procesamiento paralelo se logra mediante varios núcleos de CPU; los validadores no necesitan GPU (documentación).‍

Una vez agrupadas en entradas, las transacciones están listas para que las ejecute la máquina virtual de Solana (SVM). Se bloquean las cuentas necesarias para la transacción y se realizan comprobaciones para confirmar que la transacción sea reciente, pero que no se haya procesado antes. Se cargan las cuentas y se ejecuta la lógica de la transacción, lo que actualiza sus estados. Se envía un hash de la entrada al servicio de prueba de historial para registrarlo (la siguiente sección explica esto con más detalle). Si el proceso de registro se completa correctamente, todos los cambios se confirman en el banco y se liberan los bloqueos impuestos a cada cuenta durante el primer paso. La ejecución corre a cargo de SVM, una máquina virtual creada con el fork de Solana de rBPF, una biblioteca para trabajar con compilación JIT y máquinas virtuales para programas eBPF. Ten en cuenta que Solana no impone cómo deben ordenar los validadores las transacciones dentro de un bloque. Esta flexibilidad es un punto crucial que retomaremos más adelante en la sección Economía + Jito de este informe.‍

Clientes

Solana es una red formada por miles de nodos operados de manera independiente que colaboran para mantener un único ledger unificado. Cada nodo es una máquina de alto rendimiento que ejecuta el mismo software de código abierto, conocido como «cliente».

Solana se lanzó con un único software cliente para validadores: originalmente el cliente de Solana Labs y ahora conocido como cliente Agave , escrito en Rust. Desde entonces, ampliar la diversidad de clientes ha sido una prioridad que finalmente se materializará con el lanzamiento del cliente Firedancer. Firedancer es una reescritura completa desde cero del cliente original en el lenguaje de programación C. Creado por un equipo experimentado de la firma de trading de alta frecuencia Jump, promete ser el cliente validador de mayor rendimiento de cualquier blockchain.

Prueba de historia

La Prueba de historia (PoH) es el ingrediente secreto de Solana. Funciona como un reloj especial en cada validador que facilita la sincronización en toda la red. PoH establece una fuente de verdad confiable para el orden de los eventos y el paso del tiempo. Lo más importante es que garantiza el cumplimiento del cronograma de líderes. A pesar de sus nombres similares, la Prueba de historia no es un algoritmo de consenso como la Prueba de trabajo.

‍La sobrecarga de comunicación entre nodos suele aumentar a medida que las redes crecen, y la coordinación se vuelve cada vez más compleja. Solana mitiga esto al reemplazar la comunicación entre nodos por un cálculo local de PoH. Esto permite que los validadores confirmen un bloque con una sola ronda de votación. Las marcas de tiempo confiables en los mensajes garantizan que los validadores no se adelanten entre sí ni comiencen sus bloques antes de tiempo.

PoH se basa en las propiedades únicas de los algoritmos hash, específicamente SHA256:

• Determinista: La misma entrada siempre produce el mismo hash.
• Tamaño fijo: Sin importar el tamaño de la entrada, el hash de salida siempre tiene 256 bits.
• Eficiente: Es rápido calcular el hash de cualquier entrada determinada.
• Resistencia a preimágenes: Es computacionalmente inviable encontrar la entrada original a partir del hash de salida.
• Efecto avalancha: Un pequeño cambio en la entrada, incluso de un solo bit, produce un hash muy diferente. Esta propiedad se conoce como efecto avalancha.
• Resistencia a colisiones: Es inviable encontrar dos entradas diferentes que produzcan el mismo hash de salida.

En cada cliente validador, un "servicio de Prueba de historia" dedicado ejecuta continuamente el algoritmo hash SHA256 para crear una cadena de hashes. La entrada de cada hash es la salida del hash anterior. Esta cadena funciona como una función de demora verificable, ya que el trabajo de hashing debe realizarse en secuencia y los resultados de los hashes futuros no pueden conocerse de antemano. Si el servicio de PoH crea una cadena de mil hashes, sabemos que transcurrió el tiempo necesario para calcular cada hash secuencialmente. Esto puede considerarse una “microprueba de trabajo”. Sin embargo, otros validadores pueden verificar en paralelo que los mil hashes sean correctos a una velocidad mucho mayor que aquella a la que se produjeron, porque la entrada y la salida de cada hash se transmitieron a la red. Por lo tanto, PoH es difícil de producir, pero fácil de verificar.

El rango de rendimiento al calcular SHA-256 en distintas CPU es sorprendentemente estrecho, con solo pequeñas diferencias entre las máquinas más rápidas. Ya se alcanzó un límite superior común, a pesar del considerable tiempo y esfuerzo invertidos en optimizar esta función, en gran parte debido a la dependencia de Bitcoin de ella.

‍Durante el slot de un líder, el servicio de PoH recibe las entradas recién procesadas de la etapa bancaria. El hash de PoH actual y un hash de todas las transacciones de la entrada se combinan para formar el siguiente hash de PoH. Este actúa como una marca de tiempo que inserta la entrada en la cadena de hashes y demuestra la secuencia en la que se procesaron las transacciones. Este proceso no solo confirma el paso del tiempo, sino que también sirve como registro criptográfico de las transacciones.

En un solo bloque hay 800,000 hashes. El stream de PoH también incluye "ticks", que son entradas vacías que indican que el líder está activo y marcan el paso de una pequeña fracción de segundo. Se produce un tick cada 6.25 milisegundos, lo que da como resultado 64 ticks por bloque y un tiempo total de bloque de 400 milisegundos.

Los validadores ejecutan continuamente el reloj de PoH, incluso cuando no son líderes, porque desempeña un papel fundamental en la sincronización entre nodos.

Modelo de cuentas

Dentro de un validador de Solana, el estado global se mantiene en la base de datos de cuentas conocida como AccountsDB. Esta base de datos almacena todas las cuentas, tanto en memoria como en disco. La estructura de datos principal del índice de cuentas es un hashmap, por lo que AccountsDB es, en esencia, un enorme almacén de clave-valor. Aquí, la clave es la dirección de la cuenta y el valor son los datos de la cuenta.

Con el tiempo, la cantidad de cuentas de Solana aumentó hasta alcanzar cientos de millones. Esta enorme cifra se debe en parte a que, como suelen decir los desarrolladores de Solana, "¡Todo en Solana es una cuenta!"

Cuentas de Solana

Una cuenta es un contenedor que almacena datos de forma persistente, similar a un archivo en una computadora. Existen varios tipos:

• Cuentas de usuario: Estas cuentas tienen una clave privada y normalmente las genera un software de wallet para un usuario.
• Cuentas de datos: Estas cuentas almacenan información de estado, como la cantidad de un token específico que posee un usuario.
• Cuentas de programa: Son cuentas más grandes que contienen bytecode ejecutable, similares a un archivo .exe en Windows o .app en Mac.
• Cuentas de programas nativos: Son cuentas especiales de programas preimplementados que realizan distintas funciones esenciales de la red. Algunos ejemplos son Vote Program y BPF Loader.

Todas las cuentas tienen los siguientes campos:

Programas‍

Las cuentas de programa de Solana solo contienen lógica ejecutable. Esto significa que, cuando se ejecuta un programa, modifica el estado de otras cuentas, pero permanece sin cambios. Esta separación entre código y estado distingue a Solana de otras blockchains y permite muchas de sus optimizaciones. Los desarrolladores escriben estos programas principalmente en Rust, un lenguaje de programación de propósito general conocido por su fuerte enfoque en la seguridad y el rendimiento. Además, hay varios SDK disponibles en TypeScript y Python para facilitar la creación de interfaces de aplicaciones y permitir la interacción programática con la red.

Los programas nativos incluyen muchas funciones comunes listas para usar. Por ejemplo, Solana no requiere que los desarrolladores implementen código para crear un token. En su lugar, se envían instrucciones a un programa nativo preimplementado que configura una cuenta para almacenar los metadatos del token, lo que crea un token nuevo.

Renta

La renta es un mecanismo diseñado para incentivar a los usuarios a cerrar cuentas y reducir el crecimiento excesivo del estado. Para crear una cuenta nueva, esta debe mantener un saldo mínimo de SOL, conocido como monto "exento de renta". Puede considerarse un costo de almacenamiento necesario para mantener activa la cuenta en la memoria de un validador. Si aumenta el tamaño de los datos de la cuenta, el saldo mínimo requerido para la renta aumenta proporcionalmente. Cuando una cuenta deja de ser necesaria, puede cerrarse y la renta se devuelve al propietario. 

Por ejemplo, si un usuario posee una stablecoin denominada en dólares, este estado se almacena en una cuenta de tokens. Actualmente, el monto exento de renta para una cuenta de tokens es de 0.002 SOL. Si el usuario transfiere todo su saldo de stablecoins a un amigo, puede cerrar la cuenta de tokens y recuperar sus 0.002 SOL. Los programas suelen gestionar automáticamente el cierre de cuentas para los usuarios. Hay varias aplicaciones disponibles que ayudan a limpiar cuentas antiguas sin uso y recuperar las pequeñas cantidades de SOL almacenadas en ellas.

Propiedad

Aunque cualquiera puede leer los datos de una cuenta, el modelo de propiedad de Solana mejora la seguridad al restringir exactamente quién puede modificar o escribir los datos de una cuenta. Este concepto es crucial para aplicar reglas y permisos en la blockchain de Solana. Cada cuenta tiene un programa "propietario". El propietario de una cuenta se encarga de administrarla y garantiza que solo los programas autorizados puedan modificar sus datos. Una excepción importante a esta regla es la transferencia de lamports, la unidad más pequeña de SOL: cualquiera puede aumentar el saldo de lamports de una cuenta, sin importar quién sea su propietario.

Almacenamiento del estado

Los programas de Solana, al ser archivos ejecutables de solo lectura, deben almacenar el estado mediante “Program Derived Addresses” (PDA). Las PDA son tipos especiales de cuentas asociadas a un programa y propiedad de este, en lugar de pertenecer a un usuario específico. Mientras que las direcciones normales de usuarios de Solana se derivan de la clave pública de un par de claves Ed25519, las PDA no tienen una clave privada. En cambio, su clave pública se deriva de una combinación de parámetros —a menudo palabras clave u otras direcciones de cuentas— junto con el ID o dirección del programa propietario.

Las direcciones PDA existen "fuera de la curva", lo que significa que no están en la curva Ed25519 como las direcciones normales. Solo el programa propietario de la PDA puede generar firmas para ella de forma programática, lo que garantiza que sea el único que pueda modificar su estado.

Turbine

Durante la etapa bancaria, las transacciones se organizan en entradas y se envían al stream de Prueba de historia para asignarles marcas de tiempo. Se actualiza el banco del bloque y las entradas quedan listas para la siguiente fase: Turbine.

Turbine es el proceso mediante el cual el líder propaga su bloque al resto de la red. Está inspirado en BitTorrent y diseñado para ser rápido y eficiente, reducir la sobrecarga de comunicación y minimizar la cantidad de datos que el líder debe enviar.

‍Turbine logra esto al dividir los datos de las transacciones en "shreds" mediante un proceso llamado "shredding". Los shreds son pequeños paquetes de datos de hasta 1280 bytes, similares a los fotogramas individuales de un stream de video. Cuando se vuelven a ensamblar, permiten que los validadores reproduzcan todo el bloque. Los shreds se envían por internet entre validadores mediante UDP y utilizan códigos de borrado para gestionar la pérdida o eliminación maliciosa de paquetes. Los códigos de borrado, un esquema de detección y corrección de errores basado en polinomios, garantizan la integridad de los datos. Aunque se pierdan algunos shreds, el bloque puede reconstruirse.

Los shreds se agrupan en lotes conocidos como lotes de corrección de errores hacia adelante (FEC). De forma predeterminada, estos lotes contienen 64 shreds: 32 de datos y 32 de recuperación. La recuperación de datos ocurre por lote FEC, lo que significa que puede perderse o dañarse hasta la mitad de los paquetes de un lote y aun así recuperar todos los datos. Cada lote de 64 shreds se organiza en un árbol de Merkle cuya raíz firma el líder y se encadena al lote anterior. Este proceso garantiza que los shreds puedan obtenerse de forma segura desde cualquier nodo de la red que los posea, ya que la cadena de raíces de Merkle ofrece una ruta verificable de autenticidad e integridad.

Al principio, el líder transmite a un único nodo raíz, que distribuye los shreds a todos los demás nodos validadores. Este nodo raíz cambia con cada shred. Los validadores se organizan en capas que forman el "árbol de Turbine". Los validadores con más stake suelen ubicarse cerca de la parte superior del árbol, mientras que aquellos con menos stake se colocan hacia la parte inferior.

‍El árbol suele abarcar dos o tres saltos, según la cantidad de validadores activos. Para simplificar la visualización, arriba se muestra un fanout de 3, pero el valor real de fanout de Solana está configurado actualmente en 200. Por motivos de seguridad, el orden del árbol rota con cada nuevo lote de shreds.

El objetivo principal de este sistema es aliviar la presión del tráfico de datos saliente sobre el líder y los nodos raíz. Mediante un sistema de transmisión y retransmisión, la carga se distribuye entre el líder y los retransmisores, lo que reduce la presión sobre cada nodo individual.

Consenso

Cuando un validador recibe un nuevo bloque del líder mediante Turbine, debe validar todas las transacciones de cada entrada. Esto implica reproducir todo el bloque, validar los hashes de PoH en paralelo, recrear las transacciones en la secuencia dictada por PoH y actualizar su banco local. 

‍Este proceso está a cargo de la Transaction Validation Unit (TVU), análoga a la Transaction Processing Unit (TPU) del líder. Es la lógica central responsable de procesar los shreds y validar los bloques. Al igual que el flujo de la TPU, el de la TVU se divide en varias etapas. Comienza con la Shred Fetch Stage, donde se reciben los shreds mediante Turbine. En la siguiente Shred Verify Leader Signature Stage, los shreds pasan por varias comprobaciones básicas, principalmente la verificación de la firma del líder, que garantiza que los shreds recibidos provengan de él. ‍

En la Retransmit Stage, el validador reenvía los shreds a los validadores posteriores correspondientes según su ubicación en el árbol de Turbine. En la Replay Stage, el validador recrea cada transacción con exactitud y en el orden correcto mientras actualiza su versión local del banco.

La Replay Stage es análoga a la etapa bancaria de la TPU. Es la etapa más importante y puede describirse de forma más directa como la etapa de validación del bloque. Replay es un ciclo de proceso de un solo hilo que coordina muchas operaciones clave, como votar, reiniciar el reloj de PoH y cambiar de banco. 

Consenso

Para alcanzar el consenso, Solana usa Tower BFT (TBFT), una implementación personalizada del conocido algoritmo de Tolerancia Práctica a Fallas Bizantinas (PBFT), que la mayoría de las blockchains utiliza para acordar el estado de la cadena. Como todas las blockchains, Solana presupone la presencia de nodos maliciosos en la red, por lo que el sistema debe soportar tanto fallas de nodos como ciertos niveles de ataques.

Tower BFT se diferencia de otras cadenas porque aprovecha el reloj sincronizado que proporciona la Prueba de historia. Mientras que PBFT tradicional requiere varias rondas de comunicación para acordar el orden de las transacciones, los nodos de Solana utilizan el orden de eventos ya establecido, lo que reduce significativamente la sobrecarga de mensajes.

Votación

‍Para participar en el consenso y obtener recompensas, los validadores envían votos por los bloques que consideran válidos, es decir, sin problemas como gastos dobles o firmas incorrectas, y que deberían considerarse canónicos. Los validadores pagan una comisión de transacción por estos votos, que el líder procesa e incluye en un bloque junto con las transacciones normales de los usuarios. Por eso, las transacciones de Solana suelen clasificarse como transacciones de voto y sin voto. Cuando los validadores envían un voto correcto y exitoso, obtienen un crédito. Este mecanismo los incentiva a votar por la bifurcación que consideran con más probabilidades de incluirse, es decir, la bifurcación “más pesada”.

Bifurcaciones

Parte del diseño que hace que Solana sea tan rápida consiste en que la red no espera a que todos los validadores acuerden un bloque recién producido antes de producir el siguiente. Como resultado, no es inusual que dos bloques diferentes estén vinculados al mismo bloque principal, lo que crea bifurcaciones.

Los validadores de Solana deben votar sobre estas bifurcaciones y usar un algoritmo de consenso para determinar cuál adoptar. Cuando existen bifurcaciones rivales, la red termina finalizando solo una, mientras que abandona los bloques de las bifurcaciones descartadas.

Cada slot tiene un líder predeterminado y solo se acepta el bloque de ese líder. No puede haber dos bloques propuestos para un mismo slot. Por lo tanto, la cantidad de bifurcaciones posibles se limita a una lista de omisiones de tipo "está/no está" que puede surgir en los límites de los slots de rotación de líderes. Cuando un validador elige una bifurcación, queda comprometido con ella hasta que vence un período de bloqueo. Esto significa que debe mantener su elección durante un tiempo mínimo.

‍La "tasa de omisión" de Solana —el porcentaje de slots en los que no se produjo un bloque— varía entre el 2% y el 10%. Las bifurcaciones son el motivo principal de estas omisiones. Otras razones posibles incluyen el inicio de una nueva época, que un líder esté fuera de línea o la producción de un bloque no válido.

Recuerda:

El estado de una transacción en Solana varía según su etapa actual dentro del proceso de consenso:

• Procesada: La transacción se incluyó en un bloque.
• Confirmada: Una supermayoría de dos tercios votó por el bloque de la transacción.
• Finalizada: Se construyeron más de 31 bloques sobre el bloque de la transacción.

Hasta la fecha, nunca hubo un caso en la historia de Solana en el que un bloque confirmado de forma optimista no llegara a finalizarse.‍

Para cada bloque, Solana usa un banco para acceder al estado de ese bloque. Cuando un banco se finaliza, las actualizaciones de cuentas de ese banco y de sus antecesores se escriben en el disco. Además, se eliminan las actualizaciones de cuentas de bancos anteriores que no sean antecesores del banco finalizado. Este proceso permite que Solana mantenga varios estados potenciales de manera eficiente.

Gossip + Archivo

Gossip

La red gossip puede considerarse el plano de control de la red Solana. A diferencia del plano de datos, que gestiona los flujos de transacciones, el plano de control distribuye metadatos cruciales sobre el estado de la blockchain, como información de contacto, altura del ledger e información de votación. Sin gossip, los validadores y los RPC no sabrían qué direcciones y puertos están abiertos para la comunicación entre los distintos servicios. Los nodos nuevos también dependen de gossip para unirse a la red.

El protocolo gossip de Solana utiliza comunicación informal entre pares con un enfoque de difusión en árbol inspirado en un algoritmo PlumTree modificado. Este método propaga la información de forma eficiente sin depender de una fuente central.

Gossip funciona, en cierta medida, como un sistema aislado e independiente de la mayoría de los demás componentes del validador. Los validadores y los RPC comparten objetos de datos firmados cada 0.1 segundos mediante UDP a través de gossip, lo que garantiza la disponibilidad de la información en toda la red. Todos los mensajes de gossip deben ser menores o iguales que la unidad máxima de transmisión (MTU) de 1280 bytes, denominada "packet struct" en el código base.

Los registros de gossip son los objetos de datos reales que se comparten entre nodos. Existen aproximadamente 10 tipos de registros, cada uno con un propósito diferente. Los registros de gossip están firmados, versionados y marcados con una marca de tiempo para garantizar su integridad y vigencia.

Existen cuatro tipos de mensajes de gossip:‍

1. Push: Los mensajes más comunes, que comparten información con un subconjunto de "push peers".
2. Pull y Pull Response: Comprueban periódicamente si faltan mensajes. Las respuestas pull devuelven la información que los nodos no tienen.
3. Prune: Permite que los nodos reduzcan de forma selectiva la cantidad de conexiones que mantienen.
4. Ping y Pong: Comprobaciones del estado de los nodos. Si se envía un ping, se espera recibir un pong, lo que indica que el nodo par sigue activo.

Los datos de gossip se almacenan en un Cluster Replicated Data Store (CrdsTable). Esta estructura de datos puede crecer mucho y debe depurarse periódicamente.

Archivo

Solana se diferencia de otras blockchains porque no requiere todo el historial para determinar el estado actual de una cuenta. El modelo de cuentas de Solana garantiza que se conozca el estado en cualquier slot, lo que permite que los validadores almacenen el estado actual de cada cuenta sin procesar todos los bloques históricos. Por diseño, los RPC y los validadores no conservan todo el ledger histórico. En cambio, suelen almacenar datos de transacciones de solo 1 o 2 épocas, es decir, de 2 a 4 días, lo suficiente para validar la punta de la cadena.

Actualmente, los archivos son administrados por "nodos de almacén", operados por proveedores profesionales de servicios RPC, Solana Foundation y otros participantes del ecosistema interesados en garantizar que el historial de transacciones esté disponible. Los nodos de almacén suelen mantener uno o ambos de los siguientes recursos:

1. Archivo del ledger: Carga el ledger sin procesar y snapshots de AccountsDB adecuados para reproducir todo desde cero.
2. Instancia de Google Bigtable: Almacena los datos de bloques desde el bloque génesis en adelante, con un formato apto para atender solicitudes RPC.

Economía + Jito

Solana utiliza la inflación para distribuir recompensas de staking mediante la generación de nuevos tokens SOL en cada época. Este proceso hace que la participación en la red de quienes no hacen staking disminuya en relación con la de quienes sí lo hacen, lo que transfiere riqueza de los primeros a los segundos. La inflación comenzó a principios de 2021 con una tasa inicial del 8%, que disminuye un 15% cada año hasta estabilizarse en una tasa a largo plazo del 1.5%.

‍Cualquier titular de tokens SOL puede obtener recompensas y ayudar a proteger la red al hacer staking de sus tokens con uno o más validadores. Asignar tokens a un validador se conoce como delegación. Delegar tokens a un validador indica confianza en él, pero no le otorga la propiedad ni el control de los tokens. Todas las acciones de staking, retiro de staking y delegación se ejecutan al comienzo de la siguiente época nueva.

Recompensas por votación

‍Cuando un validador envía un voto, obtiene un crédito si este es preciso y exitoso. Las transacciones de votación cuestan 0.000005 SOL y están exentas de comisiones de prioridad. Los gastos de votación ascienden aproximadamente a 1 SOL diario por validador, por lo que representan el principal costo operativo de ejecutar uno. Durante una época, los validadores acumulan créditos por votar y pueden canjearlos por una parte de la inflación al final de la época.

Los validadores con mejor rendimiento votan correctamente en aproximadamente el 90% de los slots. Ten en cuenta que el porcentaje de slots sin bloques, o tasa de slots omitidos, oscila entre el 2% y más del 10%, y no es posible votar por ellos. El validador promedio vota correctamente en cerca del 80% de los slots y obtiene 345,600 créditos en una época de 432,000 slots.

El fondo total de inflación se divide primero según los créditos obtenidos durante la época. La proporción de los créditos totales que corresponde a un validador —sus créditos divididos entre la suma de los créditos de todos los validadores— determina su recompensa proporcional. Después, esta se pondera según el stake.

Por lo tanto, un validador con el 1% del stake total debería obtener cerca del 1% de la inflación total si tiene una cantidad promedio de créditos. Si tiene más o menos créditos que el promedio, sus recompensas fluctuarán en consecuencia.‍

Las diferencias en el rendimiento de votación son una razón por la que varían los retornos, medidos en APY, que los validadores ofrecen a quienes hacen staking. Otro factor es la tasa de comisión que cobran los validadores, un porcentaje de las recompensas totales por inflación dirigido a su validador. Además, que un validador esté fuera de línea o desincronizado con la blockchain, un estado conocido como delinquency, afecta considerablemente los retornos.

Recompensas de bloque

Los validadores designados como líderes de un bloque específico reciben recompensas de bloque adicionales. Estas recompensas incluyen el 50% de las comisiones base y el 50% de las comisiones de prioridad de todas las transacciones del bloque. Las comisiones restantes se queman. Solo el validador que produjo el bloque recibe estas recompensas. A diferencia de las recompensas de staking, que se distribuyen por época, las recompensas de bloque se acreditan de inmediato en la cuenta de identidad del validador cuando se produce el bloque.

Staking líquido

El staking líquido se convirtió en una alternativa popular al staking nativo. Los participantes reciben un token, conocido como Liquid Staking Token (LST) o Liquid Staking Derivative (LSD), a cambio de hacer staking de sus SOL, normalmente en un pool de staking que delega sus tokens entre varios validadores. Los nuevos tokens LST representan la participación del usuario en los SOL en staking. Estos tokens pueden negociarse, usarse en distintas aplicaciones o transferirse a otras personas sin dejar de generar recompensas de staking. La principal ventaja de este sistema es que mejora considerablemente la eficiencia del capital.

Price of LST = (total staked SOL in pool * price of SOL) / total LST minted

Con el staking nativo tradicional, quien hace staking acumula directamente más SOL con el tiempo. En cambio, con el staking líquido, las recompensas se reinvierten en el pool, lo que aumenta el valor razonable del LST. Mientras exista un mecanismo para canjear los LST por los SOL en staking subyacentes, los operadores de arbitraje garantizarán que el precio del token se mantenga racional.

Jito

Al momento de escribir este artículo, más del 80% (fuente) del stake en Solana utiliza el software de cliente validador Jito. Este cliente, un fork del cliente Agave original, introduce una subasta de espacio de bloque fuera del protocolo que ofrece incentivos económicos adicionales a los validadores mediante propinas. Este incentivo adicional es un factor importante en la adopción generalizada del cliente Jito entre los validadores.

Cuando los líderes usan el cliente validador Jito, sus transacciones se dirigen primero al Jito-Relayer. Este software de código abierto funciona como un router proxy de transacciones. Los demás nodos de la red no saben que Jito-Relayer existe, ya que simplemente envían las transacciones a la dirección y la configuración de puerto que el líder anunció mediante la red gossip como su ingress_socket, suponiendo que pertenece al líder.

‍El relayer retiene todas las transacciones durante 200 milisegundos antes de reenviarlas al líder. Este mecanismo de "reductor de velocidad" retrasa los mensajes de transacciones entrantes y ofrece un breve período para realizar subastas. Después de 200 milisegundos, el relayer libera las transacciones de manera optimista, sin importar los resultados de la subasta.

Las subastas de espacio de bloque ocurren fuera de la cadena mediante Jito Block Engine y permiten que los buscadores y las aplicaciones envíen grupos de transacciones ejecutadas atómicamente, conocidos como bundles. Estos bundles suelen contener transacciones sensibles al tiempo, como arbitrajes o liquidaciones. Jito cobra una comisión del 5% sobre todas las propinas, con una propina mínima de 10,000 lamports. Las propinas funcionan completamente fuera del protocolo y están separadas de las comisiones base y de prioridad integradas en el protocolo. Anteriormente, Jito operaba un servicio canónico de mem-pool fuera del protocolo, que ahora está obsoleto.