Introducción

“Conocíamos lo más pequeño, más rápido, más barato mejor que nadie en el mundo, y ahora estamos aplicando esos conceptos a la cadena de bloques.” — Greg Fitzgerald, cofundador de Solana

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 miles de transacciones por segundo en una red descentralizada a nivel mundial. Con un tiempo de bloque de 400 milisegundos y tarifas de transacción que son fracciones de un centavo, cumple tanto con la velocidad como con la rentabilidad. Este informe explora las complejidades del diseño y funcionamiento de Solana, investigando los mecanismos clave y la topología de la red que contribuyen a sus capacidades.

Solana adopta un enfoque integrado para el desarrollo de blockchain, aprovechando las décadas de experiencia del equipo fundador en la construcción de sistemas distribuidos. Uno de los principios fundamentales de Solana es que el software nunca debe interponerse en el hardware. Esto significa que el software aprovecha al máximo el hardware en el que se ejecuta y escala con él. Como un ecosistema unificado, todas las aplicaciones construidas sobre esta única cadena de bloques heredan la composabilidad, lo que les permite interactuar y construir unas sobre otras de manera transparente. Esta arquitectura también garantiza una experiencia de usuario sencilla e intuitiva sin necesidad de puentes, identificaciones de cadena separadas o fragmentación de liquidez.

Solana está evolucionando rápidamente, con desarrollos recientes que incluyen rollups de SVM yCompresión ZKcomo soluciones de escalabilidad importantes. Si bien estos proyectos pueden llegar a dar forma a nuestra percepción futura de Solana, actualmente se encuentran en las primeras etapas de desarrollo o adopción y no serán cubiertos en este informe.

Ciclo de vida de la transacción

Nuestra lente principal para comprender Solana a lo largo de este informe será el ciclo de vida de una transacción típica. Para construir un modelo básico para entender las transacciones de Solana, podemos esbozar el proceso de la siguiente manera:

• Los usuarios inician transacciones, todas las cuales se envían al productor de bloque líder actual (conocido como el líder). El líder compila estas transacciones en un bloque, ejecutándolas y actualizando así su estado local.
• Este bloque de transacciones se propaga luego a lo largo de la red para que otros validadores lo ejecuten y confirmen.

Las secciones posteriores de este informe ampliarán este modelo y profundizarán en este proceso con mucho mayor detalle, comenzando con los participantes clave, los usuarios.

Recordar

Cambios sustanciales en el protocolo central de Solana pasan por un proceso formal y transparenteprocesode presentar un Documento de Mejora de Solana (SIMD) que los miembros de la comunidad y los ingenieros principales criticarán públicamente. Luego, los SIMD son votados por la red.

Seis etapas

Haremos referencia a la visual de seis etapas mostrada arriba a lo largo de este informe, ya que nos ofrece un marco consistente para entender las relaciones entre los elementos fundamentales de Solana.

Los capítulos anteriores están organizados según estas seis etapas. Los capítulos finales - Cotilleo, Archivo, Economía y Jito - atan cualquier cabo suelto. Es importante tener en cuenta que algunos capítulos abarcarán varias etapas y algunas etapas aparecerán en varios capítulos.

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

Usuarios

“Solana tiene el potencial de ser el Apple de las criptomonedas” — Raj Gokal, cofundador de Solana

El viaje de un usuario generalmente comienza configurando y financiando una aplicación de billetera. Múltiples aplicaciones de billetera populares están disponibles para Solana, ya sea como aplicaciones móviles nativas o extensiones de navegador.

Las carteras generan criptográficamente pares de claves de usuario, que constan de claves pública y privada. La clave pública actúa como identificador único de su cuenta y es conocida por todos los participantes en la red. La cuenta de un usuario en Solana se puede considerar una estructura de datos que contiene información y estado relacionados con sus interacciones con la cadena de bloques de Solana. De esta manera, una clave pública es similar a un nombre de archivo: al igual que un nombre de archivo 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 cadena de bloques de Solana. Las claves públicas en Solana se representan como cadenas codificadas en Base58 de 32 bytes.

FDKJvWcJNe6wecbgDYDFPCfgs14aJnVsUfWQRYWLn4Tn

Una clave privada, también conocida como clave secreta, puede considerarse como la contraseña o clave de acceso que otorga permiso para acceder y modificar la cuenta. Firmar con claves privadas es la forma en que las blockchains manejan la autorización. El conocimiento de la clave privada otorga autoridad absoluta sobre la cuenta. Las claves privadas de Solana también tienen 32 bytes de longitud. Los pares de claves son las combinaciones de 64 bytes de 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 se pueden derivar de frases mnemónicas, generalmente de 12 o 24 palabras de longitud. Este formato se utiliza con frecuencia en monederos para facilitar la copia de seguridad y la recuperación. Se pueden derivar de forma determinista múltiples claves a partir de una sola frase semilla.

Solana utilizaEd25519, un algoritmo de firma digital de curva elíptica ampliamente utilizado, para sus necesidades de criptografía de clave pública. Ed25519 es favorecido por su pequeño tamaño de clave, pequeño tamaño de firma, computación rápida e inmunidad a muchos ataques comunes. Cada dirección de monedero Solana representa un punto en la curva elíptica Ed25519.

El usuario firma transacciones con su clave privada. Esta firma se incluye con los datos de la transacción y puede ser verificada por otros participantes utilizando la clave pública del remitente. Este proceso asegura que la transacción no ha sido manipulada y está autorizada por el propietario de la clave privada correspondiente. La firma también actúa como un identificador único para la transacción.

Transacciones Solana

Enviar una transacción es la única forma de mutar el estado en Solana. Cualquier operación de escritura se realiza a través de una transacción, y las transacciones son atómicas: o todo lo que intenta hacer la transacción sucede o la transacción falla. Una transacción, más formalmente conocida como un 'mensaje de transacción', consta de cuatro secciones: un encabezado, una lista de direcciones de cuenta, un blockhash reciente e instrucciones.

• Encabezado: El encabezado contiene referencias a la lista de direcciones de cuenta, indicando qué cuentas deben firmar la transacción.
• Direcciones de cuenta: Esta lista incluye todas las cuentas que se leerán o escribirán durante la transacción. Construir una lista así para cada transacción es un requisito único de Solana y puede ser un desafío para los desarrolladores. Sin embargo, saber de antemano con qué piezas de estado interactuará una transacción permite optimizaciones que no son posibles en muchas otras blockchains.
• Blockhash reciente: Se utiliza para evitar transacciones duplicadas y obsoletas. Un blockhash reciente caduca después de 150 bloques (aproximadamente 1 minuto). De forma predeterminada, las RPC intentan reenviar transacciones cada 2 segundos hasta que la transacción se finalice o el blockhash reciente caduque, momento en el cual la transacción se descarta.
• Instrucciones: Estas forman la parte central de la transacción. Cada instrucción representa una operación específica (por ejemplo, transferir, acuñar, quemar, crear cuenta, cerrar cuenta). Cada instrucción especifica el programa a ejecutar, las cuentas necesarias y los datos requeridos para la ejecución de la instrucción.

El número de instrucciones en una transacción está limitado primero por su tamaño, que puede ser de hasta 1,232 bytes. También hay limitaciones en cuanto al número de cuentas que pueden ser referenciadas. Por último, existen límites para la complejidad de una transacción medida en unidades de cómputo (CUs). Las CUs cuantifican los recursos computacionales gastados en el procesamiento de transacciones.

Recordar

La unidad más pequeña de SOL se conoce como un "lamport," equivalente a una milmillonésima parte de un SOL, similar a un satoshi en Bitcoin. El lamport recibe su nombreLeslie Lamport, un científico de la computación y matemático cuya investigación estableció muchas bases teóricas de los sistemas distribuidos modernos.

El costo en SOL para ejecutar una transacción se divide en 2 partes: una tarifa base y una tarifa de priorización. La tarifa base es un costo fijo de 5000 lamports por firma, independientemente de la complejidad de la transacción, por lo general, hay 1 firma por transacción.

Las tarifas de priorización son técnicamente opcionales, pero durante períodos de alta demanda de espacio en bloque se vuelven necesarias. Estas tarifas se cotizan en micro-lamports (millonésima parte de un lamport) por unidad de cálculo. Su propósito es actuar como una señal de precio, haciendo que las transacciones sean más económicamente convincentes para los nodos validadores incluirlas en sus bloques.

tarifa total = tarifa de priorización + tarifa base

tarifa de priorización = precio unitario de cálculo (micro-lamports) x límite unitario de cálculo

Actualmente, el 50% de todas las tarifas relacionadas con las transacciones se queman, eliminando permanentemente este SOL de circulación, y el 50% restante va al productor de bloques. Pronto se introducirá un nuevo cambio (SIMD 96) que permitirá que el 100% de las tarifas de priorización vayan al productor de bloques. Las tarifas base permanecen sin cambios.

‍

Enviando transacciones

Un usuario conecta su billetera a la aplicación, lo que permite que la aplicación lea la clave pública del usuario. La clave privada permanece encriptada y seguramente aislada en un entorno separado de la aplicación.

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

Una vez que el mensaje de transacción está listo, se envía a la billetera para ser firmado con la clave privada del usuario. En este punto, al usuario se le solicita con un popup que confirme su voluntad de realizar la transacción. Este popup puede incluir una simulación de los resultados de la transacción. Una vez firmado, el mensaje de transacción y la firma se devuelven a la aplicación, que luego puede reenviar la transacción a un proveedor de RPC de su elección, ya sea el propio o utilizando el proveedor de la billetera.

Los proveedores de RPC (llamadas a procedimientos remotos) actúan como intermediarios entre las aplicaciones y los validadores que construyen bloques. Son un servicio esencial que permite a las aplicacionesenviaro simular transacciones firmadas y recuperar de manera eficiente datos en cadena. Las aplicaciones que deseen interactuar con la red lo hacen a través de un punto de conexión JSON-RPC o WebSocket ( docs.

Recordar

El término "transacción fallida" en Solana es engañoso y ha causado una considerable confusión. Estas transacciones incurren en tarifas y se ejecutan con éxito por el tiempo de ejecución exactamente según lo pretendido por el firmante. "Fallan" debido a la lógica de la transacción que requiere que así sea. El +80% de las transacciones "fallidas" provienen del código de error 0x1771, el código para exceder la cantidad de deslizamiento.datos. Es notable que el 95% de estas transacciones son enviadas solo por el 0.1% de las direcciones activas de Solana, principalmente por bots automatizados que intentan aprovechar oportunidades de arbitraje de precios sensibles al tiempo.

Corriente del Golfo

“Literalmente, el objetivo de Solana es llevar a cabo transacciones tan rápido como las noticias viajan por el mundo, es decir, a la velocidad de la luz a través de fibra. Con quienes estamos compitiendo es con NASDAQ y la Bolsa de Nueva York.” — Anatoly Yakovenko, cofundador de Solana

Las RPC (Llamadas a Procedimientos Remotos) se refieren a los nodos RPC. Estos nodos pueden ser considerados como puertas de enlace para interactuar y leer datos de la red. Ejecutan el mismo software que los validadores completos pero con configuraciones diferentes, lo que les permite simular con precisión transacciones y mantener una vista actualizada del estado actual. A la fecha de esta escritura, hay más de 4,000 nodos RPC en la red Solana.

A diferencia de los nodos validadores completos, los nodos RPC no tienen ninguna participación en la red. Sin participación, no pueden votar ni construir bloques. Esta configuración difiere de la mayoría de otras blockchains, donde los nodos validadores y RPC suelen ser los mismos. Dado que los nodos RPC no reciben recompensas por participación, la economía de ejecutar nodos RPC es distinta de la de los validadores, y muchos operan como un servicio de pago para desarrolladores que ejecutan aplicaciones Solana.

Solana se 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 forma aleatoria y amplia en toda la red, Solana envía todas las transacciones a un validador líder predeterminado, conocido como el líder, para cada slot.

Llamada

Solana opera cuatro clusters: Localnet, Testnet, Devnet y Mainnet-Beta. Cuando la gente se refiere a Solana o la red Solana, casi siempre se refieren a Mainnet-Beta. Mainnet-Beta es el único cluster donde los tokens tienen un valor real, mientras que los otros clusters se utilizan únicamente con fines de prueba.

Una vez que un RPC recibe un mensaje de transacción para incluirlo en un bloque, debe reenviarse al líder. Antes de cada época (aproximadamente cada dos días) se elabora un cronograma de líderes. La próxima época se divide en ranuras, cada una fijada en 400 milisegundos, y se elige un líder para cada ranura. Los validadores con una participación más alta serán elegidos con más frecuencia para convertirse en líderes dentro de cada época. Durante cada ranura, los mensajes de transacción se reenvían al líder, quien tiene la oportunidad de producir un bloque. Cuando es el turno de un validador, cambia al "modo líder", comienza a procesar activamente las transacciones y a transmitir bloques al resto de la red.

Servicio de Calidad Ponderado por la Participación - SWQoS

A principios de 2024, Solana introdujo un nuevo mecanismo destinado a prevenir el spam y mejorar la resistencia a Sybil, conocido como 'Calidad de Servicio Ponderada por Apuesta' (SWQoS). Este sistema permite a los líderes priorizar los mensajes de transacción que son enviados a través de otros validadores con apuestas. Aquí, a los validadores con una mayor apuesta se les otorga una capacidad proporcionalmente mayor para transmitir paquetes de mensajes de transacción al líder. Este enfoque mitiga de manera efectiva los ataques de Sybil de nodos no apostados en toda la red.

Bajo este modelo, los validadores también pueden participar en acuerdos para arrendar su capacidad ponderada por la participación a nodos RPC. A cambio, los nodos RPC obtienen un ancho de banda aumentado, lo que les permite alcanzar mayores tasas de inclusión de transacciones en bloques. Es importante destacar que el 80% de la capacidad de un líder (2,000 conexiones) está reservado para SWQoS. El 20% restante (500 conexiones) se asigna para mensajes de transacción de nodos no apostados. Esta estrategia de asignación refleja los carriles prioritarios en las autopistas, donde los conductores pagan un peaje para evitar el tráfico.

SWQoS ha impactado en el ecosistema de Solana al elevar los requisitos para reenviar transacciones al líder y reducir la efectividad de los ataques de spam. El cambio ha incentivado a las aplicaciones de alto tráfico a integrar verticalmente sus operaciones. Al ejecutar sus propios nodos validadores, o al tener acceso a conexiones con participación, las aplicaciones pueden garantizar un acceso privilegiado al líder, mejorando así sus capacidades de procesamiento de transacciones.

Una Nota RÁPIDA

A finales de 2022, Solana adoptó elprotocolo de red QUICpara gestionar la transmisión de mensajes de transacción al líder. Esta transición fue provocada por interrupciones en la red causadas por bots que generaban spam en las creaciones de NFT en cadena. QUIC facilita la comunicación rápida y asincrónica.

Inicialmente desarrollado porGoogleEn 2012, QUIC intenta ofrecer lo mejor de ambos mundos. Facilita una comunicación rápida y asincrónica similar a UDP, pero con sesiones seguras y estrategias avanzadas de control de flujo de TCP. Esto permite establecer límites a fuentes individuales de tráfico para que la red pueda centrarse en procesar transacciones genuinas. También tiene un concepto de flujos separados; por lo que si una transacción se cae, no necesita bloquear las restantes. En resumen, QUIC puede considerarse como un intento de combinar las mejores características de TCP y UDP.

Recuadro de llamada

La ponderación de la participación es un principio recurrente que se encuentra en todo el sistema de Solana, que abarca recompensas por votación, árboles de turbinas, programaciones de líderes, Gulf Stream y la red de chismes. Los validadores con una participación mayor reciben una mayor confianza y roles prioritarios en la red.

Construcción de bloques

“Consideramos SVM (Solana Virtual Machine) como el mejor en cuanto a tecnología de máquina virtual actualmente.” — Andre Cronje, Fundación Fantom

Muchas redes blockchain construyen bloques completos antes de difundirlos, conocido como construcción de bloques discretos. Solana, en cambio, emplea la construcción continua de bloques que implica ensamblar y transmitir bloques dinámicamente a medida que se crean durante un intervalo de tiempo asignado, lo que reduce significativamente la latencia.

Cada ranura dura 400 milisegundos, y a cada líder se le asignan cuatro ranuras consecutivas (1.6 segundos) antes de rotar al siguiente líder. Para que un bloque sea aceptado, todas las transacciones dentro de él deben ser válidas y reproducibles por otros nodos.

Dos ranuras antes de asumir el liderazgo, un validador detiene el reenvío de transacciones para prepararse para su próxima carga de trabajo. Durante este intervalo, el tráfico entrante aumenta bruscamente, alcanzando más de un gigabyte por segundo mientras toda la red dirige paquetes al líder entrante.

Una vez recibidos, los mensajes de transacción ingresan a la Unidad de Procesamiento de Transacciones (TPU), la lógica central del validador responsable de la producción de bloques. Aquí, la secuencia de procesamiento de transacciones comienza con la Etapa de Extracción, donde las transacciones se reciben a través de QUIC. Posteriormente, las transacciones avanzan a la Etapa de Verificación de Firma, sometiéndose a rigurosas comprobaciones de validación. Aquí, el validador verifica la validez de las firmas, comprueba el número correcto de firmas y elimina transacciones duplicadas.

Etapa bancaria

La etapa bancaria se puede describir como la etapa de construcción de bloques. Es la etapa más importante del TPU, que obtiene su nombre del "banco". Un banco es simplemente el estado en un bloque dado. Para cada bloque, Solana tiene un banco que se utiliza para acceder al estado en ese bloque. Cuando un bloque se finaliza después de que suficientes validadores voten sobre él, se almacenarán las actualizaciones de la cuenta desde el banco al disco, haciéndolas permanentes. El estado final de la cadena es el resultado de todas las transacciones confirmadas. Este estado siempre se puede recrear a partir de la historia de la cadena de bloques de manera determinista.

Las transacciones se procesan en paralelo y se empaquetan en "entradas" de libro mayor, que son lotes de 64 transacciones no conflictivas. El procesamiento de transacciones en paralelo en Solana es sencillo porque cada transacción debe incluir una lista completa de todas las cuentas a las que leerá y escribirá. Esta elección de diseño impone una carga a los desarrolladores pero permite al validador evitar condiciones de carrera seleccionando fácilmente solo transacciones no conflictivas para la ejecución dentro de cada entrada. Las transacciones entran en conflicto si ambas intentan escribir en la misma cuenta (dos escrituras) o si una intenta leer y la otra escribir en la misma cuenta (lectura + escritura). Por lo tanto, las transacciones en conflicto van a entradas diferentes y se ejecutan de forma secuencial, mientras que las transacciones no conflictivas se ejecutan en paralelo.

Hay seis hilos procesando transacciones en paralelo, con cuatro dedicados a transacciones normales y dos exclusivamente manejando transacciones de voto que son fundamentales para el mecanismo de consenso de Solana. Toda la paralelización del procesamiento se logra a través de múltiples núcleos de CPU; los validadores no tienen requisitos de GPU.docs).

Una vez que las transacciones se han agrupado en entradas, están listas para ser ejecutadas por la Máquina Virtual Solana (SVM). Las cuentas necesarias para la transacción están bloqueadas; se realizan comprobaciones para confirmar que la transacción es reciente pero aún no ha sido procesada. Las cuentas se cargan y se ejecuta la lógica de la transacción, actualizando los estados de las cuentas. Se enviará un hash de la entrada al servicio de Prueba de Historia para ser registrado (más sobre esto en la próxima sección). Si el proceso de grabación es exitoso, todos los cambios se registrarán en el banco y los bloqueos en cada cuenta colocados en el primer paso se levantarán. La ejecución la realiza la SVM, una máquina virtual construida utilizando la bifurcación de SolanarBPF, una biblioteca para trabajar con la compilación JIT y máquinas virtuales para programas eBPF. Tenga en cuenta que Solana no obliga a los validadores a elegir el orden de las transacciones dentro de un bloque. Esta flexibilidad es un punto crucial al que volveremos más adelante en la sección de Economía + Jito de este informe.

Recordar

El término SVM puede ser ambiguo, ya que puede referirse tanto a la "Máquina Virtual Solana" como a la "Máquina Virtual Sealevel". Ambos términos describen el mismo concepto, siendo Sealevel el nombre del entorno de ejecución de Solana. El término SVM sigue siendo utilizado de forma laxa a pesar de los esfuerzos recientes para precisardefinir sus límites.

Clientes

Solana es una red que consta de miles de nodos operados de forma independiente que colaboran para mantener un único libro mayor unificado. Cada nodo constituye una máquina de alto rendimiento que ejecuta el mismo software de código abierto conocido como un "cliente".

Solana se lanzó con un único software de cliente validador, originalmente el cliente de Solana Labs, ahora conocido como elcliente de Agave— escrita en Rust. La diversidad de clientes en expansión ha sido una prioridad desde entonces y una que realmente se materializará con el lanzamiento de laCliente FiredancerFiredancer es una reescritura completa desde cero del cliente original en el lenguaje de programación C. Construido por un equipo experimentado de la firma de trading de alta frecuencia Jump, promete ser el cliente validador más eficiente en cualquier blockchain.

Prueba de Historia

“Tomé dos cafés y una cerveza, y estuve despierto hasta las 4:00 AM. Tuve este momento de revelación que el rompecabezas similar a la prueba de trabajo usando la misma función hash resistente a la preimagen SHA-256... Sabía que tenía esta flecha del tiempo.” — Anatoly Yakovenko, co-fundador de Solana

La Prueba de Historia (PoH) es la salsa secreta de Solana, funcionando como un reloj especial en cada validador que facilita la sincronización en toda la red. PoH establece una fuente confiable de verdad para el orden de los eventos y el paso del tiempo. Lo más crítico es asegurar la adhesión al programa del líder. A pesar de los 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 se expanden, y la coordinación se vuelve cada vez más complicada. Solana mitiga esto sustituyendo la comunicación de nodo a nodo por una computación local de PoH. Esto significa que los validadores pueden comprometerse con un bloque con solo una ronda de votación. Los sellos de tiempo confiables en los mensajes aseguran que los validadores no puedan pisarse mutuamente y empezar sus bloques prematuramente.

Los PoH subyacentes son las propiedades únicas de los algoritmos de hash, específicamenteSHA256:

• Determinista: La misma entrada siempre producirá el mismo hash.
• Tamaño fijo: Independientemente del tamaño de entrada, el hash de salida siempre es de 256 bits.
• Eficiente: Es rápido calcular el hash para cualquier entrada dada.
• Resistencia a la preimagenEncontrar la entrada original a partir de la salida del hash es computacionalmente inviable.
• Efecto Avalancha: Un pequeño cambio en la entrada (incluso un solo bit) resulta en un hash significativamente diferente, una propiedad conocida como el efecto avalancha.
• Resistencia a colisionesEs inadmisible encontrar dos entradas diferentes que produzcan la misma salida de hash.

Dentro de cada cliente validador, un dedicado servicio de "Prueba de Historia" corre continuamente el algoritmo hash SHA256 creando una cadena de hashes. La entrada de cada hash es la salida del hash anterior. Esta cadena actúa de la misma manera que una función de retardo verificable, dado que el trabajo de hash 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 ha pasado tiempo para que calcule cada hash secuencialmente, esto se puede considerar como una "micro prueba de trabajo". Sin embargo, otros validadores pueden verificar la corrección de los mil hashes en paralelo a una velocidad mucho más rápida de la que fueron producidos, ya que la entrada y salida de cada hash han sido difundidas a la red. Por lo tanto, la PoH es difícil de producir pero fácil de verificar.

El rango de rendimiento en el cálculo de SHA-256 en diferentes CPUs es sorprendentemente estrecho, con solo pequeñas diferencias entre las máquinas más rápidas. Ya se ha alcanzado un límite superior común, a pesar del tiempo y esfuerzo significativos invertidos en optimizar esta función, en gran parte debido a la dependencia de Bitcoin en ella.

Durante el espacio de un líder, el servicio PoH recibirá nuevas entradas procesadas de la etapa bancaria. El hash PoH actual más un hash de todas las transacciones en la entrada se combinan en el siguiente hash PoH. Esto sirve como una marca de tiempo que inserta la entrada en la cadena de hashes, demostrando la secuencia en la que se procesaron las transacciones. Este proceso no solo confirma el paso del tiempo, sino que también sirve como un registro criptográfico de las transacciones.

En un solo bloque, hay 800,000 hashes. El flujo de PoH también incluye "ticks", que son entradas vacías que indican la vivacidad del líder y el paso del tiempo aproximando una pequeña fracción de segundo. Un tick ocurre cada 6.25 milisegundos, lo que resulta en 64 ticks por bloque y un tiempo total de bloque de 400 milisegundos.

Los validadores siguen ejecutando el reloj de PoH incluso cuando no son los líderes, ya que desempeña un papel fundamental en el proceso de sincronización entre nodos.

Recordar

El principal beneficio de PoH es que garantiza que se debe cumplir el horario correcto del líder, incluso si un productor de bloques está desconectado, un estado conocido como estar "delincuente". PoH evita que un validador malicioso produzca bloques antes de su turno.

Modelo de Cuentas

“Separar el código y el estado en SVM fue la mejor decisión de diseño. Benditos sean los desarrolladores de sistemas integrados que religiosamente inculcaron este concepto en mi cerebro.” — Anatoly Yakovenko, cofundador de Solana

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 es responsable de almacenar todas las cuentas, tanto en la memoria como en el disco. La estructura de datos principal en el índice de cuentas es un hashmap, lo que hace que AccountsDB sea esencialmente un vastoalmacén de clave-valorAquí, la clave es la dirección de la cuenta y el valor es los datos de la cuenta.

Con el tiempo, el número de cuentas de Solana ha aumentado hasta llegar a cientos de millones. Este gran número se debe en parte a que, como les gusta decir a los desarrolladores de Solana, "¡Todo en Solana es una cuenta!"

Cuentas Solana

Una cuenta es un contenedor que mantiene persistentemente datos, similar a un archivo en una computadora. Vienen en varias formas:

• Cuentas de usuario: Estas cuentas tienen una clave privada y suelen ser generadas por un software de monedero para un usuario.
• Cuentas de datos: Estas cuentas almacenan información de estado, como la cantidad de un token específico que un usuario posee.
• Cuentas de programa: Estas son cuentas más grandes que contienen código de bytes ejecutables, algo equivalente a un archivo .exe en Windows o un archivo .app en Mac.
• Cuentas de programa nativas: Estas son cuentas de programa pre-implementadas especiales que realizan varias funcionalidades principales de la red.Ejemplosincluye el Programa de Votación y el Cargador BPF.

Todas las cuentas tienen los siguientes campos:

Programas

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

Muchas funcionalidades comunes son proporcionadas de forma predeterminada por programas nativos. 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 pre-implementado que configurará una cuenta para almacenar los metadatos del token, creando efectivamente un nuevo token.

Alquiler

El alquiler es un mecanismo diseñado para incentivar a los usuarios a cerrar cuentas y reducir la hinchazón del estado. Para crear una nueva cuenta, se debe mantener un saldo mínimo de SOL, conocido como el monto “exento de alquiler”, en la cuenta. Esto puede considerarse como un costo de almacenamiento incurrido para mantener viva la cuenta en la memoria de un validador. Si el tamaño de los datos de la cuenta aumenta, el requisito de alquiler de saldo mínimo aumenta proporcionalmente. Cuando una cuenta ya no es necesaria, se puede cerrar y el alquiler se devuelve al propietario de la cuenta.

Por ejemplo, si un usuario tiene un stablecoin denominado en dólares, este estado se almacena en una cuenta de tokens. Actualmente, la cantidad exenta de alquiler para una cuenta de tokens es de 0.002 SOL. Si el usuario transfiere todo su saldo de stablecoin a un amigo, la cuenta de tokens se puede cerrar y el usuario recuperará sus 0.002 SOL. Los programas a menudo manejan los cierres de cuentas automáticamente para los usuarios. Hay varias aplicaciones disponibles para ayudar a los usuarios a limpiar cuentas antiguas y sin usar y reclamar las pequeñas cantidades de SOL almacenadas en ellas.

Propiedad

Si bien la lectura de datos de cuenta está permitida de forma universal, el modelo de propiedad de Solana mejora la seguridad al restringir exactamente quién puede modificar (escribir) los datos de una cuenta. Este concepto es crucial para hacer cumplir reglas y permisos en la cadena de bloques de Solana. Cada cuenta tiene un "propietario" de programa. El propietario de una cuenta es responsable de gobernarla, asegurando que solo los programas autorizados puedan cambiar los datos de la cuenta. Una excepción notable a esta regla es la transferencia de lamports (la unidad más pequeña de SOL): aumentar el saldo de lamports de una cuenta está permitido de forma universal, independientemente de la propiedad.

Almacenamiento de Estado

Los programas de Solana, al ser archivos ejecutables de solo lectura, deben almacenar el estado utilizando "Direcciones Derivadas del Programa" (PDAs). Las PDAs son tipos especiales de cuentas asociadas y propiedad de un programa en lugar de un usuario específico. Mientras que las direcciones de usuario normales de Solana se derivan de la clave pública de un par de claves Ed25519, las PDAs no tienen una clave privada. En su lugar, su clave pública se deriva de una combinación de parámetros, a menudo palabras clave u otras direcciones de cuenta, junto con la ID del programa propietario (dirección).

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 que posee el PDA puede generar programáticamente firmas para él, asegurando que es el único que puede modificar el estado del PDA.

Arriba: Las cuentas de tokens de Solana son ejemplos específicos de Direcciones Derivadas de Programas (PDAs). Se utilizan para almacenar tokens y viven 'fuera de la curva'. El programa de Cuenta de Token Asociada (ATA) asegura que cada billetera solo pueda tener una cuenta de token asociada para cada tipo de token, proporcionando una forma estandarizada de gestionar las cuentas de tokens.

Turbina

“La parte más interesante sobre Solana no es la paralelización, la SVM o los tweets de Toly. Es algo que probablemente no hayas oído hablar: Turbine.” — Mert Mumtaz, Helius

Durante la etapa bancaria, las transacciones se organizan en entradas y se envían al flujo de Prueba de Historia para su marca de tiempo. El banco del bloque se actualiza y las entradas están listas para la siguiente fase: Turbina.

La turbina es el proceso a través del cual el líder propaga su bloque al resto de la red. Inspirado porBitTorrent, está diseñado para ser rápido y eficiente, reduciendo la sobrecarga de comunicación y minimizando la cantidad de datos que un líder necesita enviar.

Turbine logra esto descomponiendo los datos de transacción en 'fragmentos' a través de un proceso llamado 'fragmentación'. Los fragmentos son pequeños paquetes de datos, de hasta 1280 bytes, similares a fotogramas individuales en un flujo de video. Cuando se reensamblan, estos fragmentos permiten a los validadores reproducir todo el bloque. Los fragmentos se envían por Internet entre validadores utilizando UDP y utilizan codificación de borrado para manejar la pérdida de paquetes o la eliminación maliciosa de paquetes.Codificación de borrado, apolinomioEsquema de detección y corrección de errores basado, garantiza la integridad de los datos. Incluso si se pierden algunos fragmentos, el bloque aún puede ser reconstruido.

Los fragmentos se agrupan en lotes conocidos como lotes de corrección de errores hacia adelante (FEC). De forma predeterminada, estos lotes consisten en 64 fragmentos (32 fragmentos de datos + 32 fragmentos de recuperación). La recuperación de datos ocurre por lote FEC, lo que significa que hasta la mitad de los paquetes en un lote pueden perderse o corromperse, y aún así se puede recuperar todos los datos. Cada lote de 64 fragmentos se merkeliza con la raíz firmada por el líder y encadenada al lote anterior. Este proceso garantiza que los fragmentos se puedan obtener de forma segura desde cualquier nodo en la red que los posea, ya que la cadena de raíces de Merkle proporciona un camino verificable de autenticidad e integridad.

El líder inicialmente transmite a un único nodo raíz, que disemina los fragmentos a todos los demás nodos validadores. Este nodo raíz cambia con cada fragmento. Los validadores están organizados en capas, formando el “Árbol de Turbina.” Los validadores con una cantidad de participación más grande suelen estar posicionados hacia la parte superior del árbol, mientras que aquellos con participaciones más bajas se colocan hacia la parte inferior.

El árbol generalmente abarca dos o tres saltos, dependiendo del número de validadores activos. Para mayor simplicidad visual, se representa un fanout de 3 arriba, pero el valor actual del fanout de Solana está actualmente establecido en 200. Por razones de seguridad, el orden del árbol se rota para cada nuevo lote de fragmentos.

El objetivo principal de un sistema así es aliviar la presión de salida de datos en los nodos líder y raíz. Al utilizar un sistema de transmisión y retransmisión, la carga se distribuye entre el líder y los retransmisores, reduciendo la tensión en cualquier nodo individual.

Consenso

"Algunas personas inteligentes me dicen que hay una comunidad de desarrolladores inteligentes en Solana... Espero que la comunidad tenga una oportunidad justa de prosperar" — Vitalik Buterin, cofundador de Ethereum

Una vez que un validador recibe un nuevo bloque del líder a través de Turbine, debe validar todas las transacciones dentro de cada entrada. Esto implica volver a 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 es manejado por la Unidad de Validación de Transacciones (TVU), que es análoga a la Unidad de Procesamiento de Transacciones (TPU) del líder, sirviendo como la lógica central responsable del procesamiento de fragmentos y validación de bloques. Al igual que la TPU, el flujo de TVU se descompone en varias etapas, comenzando con la Etapa de Obtención de Fragmentos donde se reciben los fragmentos a través de Turbine. En la etapa posterior de Verificación de Firma Líder de Fragmentos, los fragmentos pasan por múltiples comprobaciones de cordura, siendo la verificación de la firma del líder la más notable, lo que asegura que los fragmentos recibidos se originaron del líder.

En la Etapa de Retransmisión, el validador, basado en su ubicación en el árbol de Turbine, reenvía los fragmentos a los validadores aguas abajo apropiados. En la Etapa de Reproducción, el validador recrea cada transacción exactamente y en el orden correcto mientras actualiza su versión local del banco.

La Etapa de Reproducción es análoga a la etapa bancaria en el TPU; es la etapa más importante y se puede describir de manera más directa como la etapa de validación de bloques. Replay es un bucle de proceso de un solo hilo que orquesta muchas operaciones clave, incluyendo votación, restablecimiento del reloj PoH y cambio de bancos.

Arriba: la etapa de repetición es responsable de cambiar el validador al modo líder y comenzar la producción de bloques. Visual original: Justin Starry, Anza

Consenso

Para lograr consenso, Solana utiliza Tower BFT (TBFT), una implementación personalizada del conocido PracticalFallo bizantinoEl algoritmo de tolerancia a fallos bizantinos (PBFT), comúnmente utilizado por la mayoría de las blockchains para ponerse de acuerdo sobre el estado de la cadena. Al igual que todas las blockchains, Solana asume la presencia de nodos maliciosos en la red, por lo que el sistema debe resistir no solo fallos de nodos, sino también ciertos niveles de ataques.

Tower BFT se diferencia de otras cadenas al aprovechar el reloj sincronizado proporcionado por la Prueba de Historia. Mientras que el PBFT tradicional requiere múltiples rondas de comunicación para ponerse de acuerdo sobre el orden de las transacciones, los nodos de Solana utilizan el orden preestablecido de los eventos, reduciendo significativamente la sobrecarga de mensajería.

Votación

Para participar en el consenso y ganar recompensas, los validadores envían votos por los bloques que consideran válidos (es decir, libres de problemas como gastos dobles o firmas incorrectas) y que deben ser considerados canónicos. Los validadores pagan una tarifa de transacción por estos votos, que son procesados por el líder e incluidos en un bloque junto con las transacciones regulares de los usuarios. Por eso las transacciones en Solana suelen clasificarse en transacciones de votos y no votos. Cuando los validadores envían un voto correcto y exitoso, ganan un crédito. Este mecanismo incentiva a los validadores a votar por la bifurcación que creen que tiene la mejor posibilidad de ser incluida, es decir, la bifurcación más “pesada”.

Forks

Parte del diseño de Solana, que lo hace tan rápido, es que la red no espera a que todos los validadores estén de acuerdo en un bloque recién producido antes de producir el siguiente. Como resultado, no es raro que dos bloques diferentes estén vinculados al mismo bloque padre, creando bifurcaciones.

Los validadores de Solana deben votar en estas bifurcaciones y utilizar un algoritmo de consenso para determinar cuál adoptar. Cuando existen bifurcaciones competidoras, solo una bifurcación será finalizada por la red, mientras que los bloques en las bifurcaciones descartadas son abandonados.

Cada ranura tiene un líder predeterminado para el que solo se aceptará el bloqueo de ese líder; No puede haber dos bloques propuestos para una sola ranura. Por lo tanto, el número de bifurcaciones potenciales se limita a una lista de omisión de bifurcaciones "allí/no allí" que pueden surgir en los límites de las ranuras de rotación de líderes. Una vez que un validador elige una bifurcación, se compromete con esta bifurcación hasta que expire el tiempo de bloqueo, lo que significa que debe seguir con su elección durante un período mínimo.

La tasa de “omitir” de Solana —el porcentaje de intervalos en los que no se produjo un bloque— varía del 2% al 10%, siendo las bifurcaciones la razón principal de estos intervalos omitidos. Otras posibles razones para los intervalos omitidos incluyen el inicio de una nueva época, un líder fuera de línea o la producción de un bloque inválido.

Recordar

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

• Procesado: La transacción ha sido incluida en un bloque.

• Confirmado: El bloque de la transacción ha sido votado por una supermayoría de dos tercios.

• Finalizado: Se han construido más de 31 bloques sobre el bloque de la transacción.

Hasta la fecha, nunca ha habido una instancia en la historia de Solana donde un bloque confirmado (optimistamente) no se haya finalizado.

Por cada bloque, Solana utiliza un banco para acceder al estado en ese bloque. Cuando un banco se finaliza, las actualizaciones de cuentas de ese banco y sus ancestros se escriben en disco. Además, se eliminan las actualizaciones de cuentas de bancos anteriores que no son ancestros del banco finalizado. Este proceso permite a Solana mantener múltiples estados potenciales de manera eficiente.

Chismes + Archivo

“Un blockchain requiere una combinación inteligente de criptografía, sistemas distribuidos, sistemas operativos y lenguajes de programación. El superpoder de Solana fue la disposición a huir gritando de los problemas más interesantes en cada disciplina.” — Greg Fitzgerald, cofundador de Solana

Chismes

La red de chismes se puede pensar comoplano de controlpara la red Solana. A diferencia del plano de datos, que maneja flujos de transacciones, el plano de control difunde metadatos cruciales sobre el estado del blockchain, como información de contacto, altura del libro mayor 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 varios servicios. Los nodos nuevos también dependen del gossip para unirse a la red.

El protocolo de chismes de Solana utiliza comunicación informal de igual a igual con un enfoque de difusión de árbol inspirado en un algoritmo PlumTree modificado. Este método propaga información de manera eficiente sin depender de ninguna fuente central.

Los chismes funcionan de alguna manera como un sistema aislado, independiente de la mayoría de otros componentes validadores. Los validadores y los RPC comparten objetos de datos firmados cada 0,1 segundos a través de UDP a través de chismes, garantizando la disponibilidad de información en toda la red. Todos los mensajes de chismes deben ser menores o iguales a la unidad máxima de transmisión (MTU) de 1280 bytes, referida como la “estructura de paquete” en el código base.

Los registros de chismes son los objetos de datos reales compartidos entre nodos. Hay aproximadamente 10 tipos diferentes de registros, cada uno sirviendo para diferentes propósitos. Los registros de chismes están firmados, versionados y con marca de tiempo para garantizar integridad y actualidad.

Hay cuatro tipos de mensajes de chismes:

• Push: Los mensajes más comunes, compartiendo información con un subconjunto de "push peers".
• Pull & Pull Response: Comprueba periódicamente los mensajes perdidos, con las respuestas de pull enviando la información que los nodos no tienen.
• Recorte: Permite a los nodos reducir selectivamente el número de conexiones que mantienen.
• Ping & Pong: Verificaciones de salud para nodos - si se envía un ping, se espera recibir un pong, lo que indica que el nodo par está todavía activo.

Los datos de chismes se almacenan en una Tienda de Datos Replicada en Clúster (CrdsTable). Esta estructura de datos puede crecer mucho y necesita ser podada periódicamente.

Archivo

Solana se destaca de otras blockchains al no requerir toda la historia para determinar el estado actual de una cuenta. El modelo de cuenta de Solana garantiza que el estado en cualquier slot dado sea conocido, lo que permite a los validadores almacenar el estado actual de cada cuenta sin procesar todos los bloques históricos. Los RPC y los validadores, por diseño, no retienen el libro mayor histórico completo. En cambio, suelen almacenar solo el equivalente a 1 o 2 épocas (2-4 días) de datos de transacciones, lo que es suficiente para validar la punta de la cadena.

Los archivos son actualmente gestionados por los “nodos de almacén,” operados por proveedores de servicios RPC profesionales, la Fundación Solana y otros participantes del ecosistema interesados en garantizar que el historial de transacciones esté disponible. Los nodos de almacén generalmente mantienen uno o ambos de los siguientes:

1. Archivo de registro: Carga instantáneas de registro en bruto y de cuentas adecuadas para la reproducción desde cero.

2. Instancia de Google Bigtable: Almacena datos en bloque desde el bloque génesis en adelante, formateados para atender solicitudes RPC.

Economía + Jito

“La gente se está dando cuenta de que Solana es la única cadena disponible hoy en día que admitirá aplicaciones de consumo masivo.” — Ted Livingston, fundador Code

Solana emplea la inflación para distribuir las recompensas de participación generando nuevos tokens SOL en cada época. Este proceso provoca que la participación en la red de los no participantes disminuya en relación con la de los participantes, lo que lleva a una transferencia de riqueza de los no participantes a los participantes. La inflación comenzó a principios de 2021 a una tasa inicial del 8%, que disminuye un 15% anualmente hasta estabilizarse en una tasa a largo plazo del 1.5%.

Cualquier titular de tokens SOL puede ganar recompensas y ayudar a asegurar la red apostando tokens a uno o más validadores. Asignar tokens a un validador se conoce como delegación. Delegar tokens a un validador indica confianza en el validador. Sin embargo, no le otorga al validador la propiedad ni el control sobre los tokens. Todas las acciones de apuesta, desapuesta y delegación se ejecutan al comienzo del próximo nuevo época.

‍

Recompensas de Votación

Cuando un validador envía un voto, obtienen un crédito si el voto es preciso y exitoso. Las transacciones de voto cuestan 0.000005 SOL y están exentas de tarifas prioritarias. Los gastos de votación ascienden a aproximadamente 1 SOL por día por validador, lo que lo convierte en el principal costo operativo de ejecutar un validador. A lo largo de una época, los validadores acumulan créditos de votación, que pueden intercambiar por una parte de la inflación al final de la época.

Los validadores de mejor rendimiento votan con éxito en aproximadamente el 90% de las ranuras. Tenga en cuenta que el porcentaje de ranuras sin bloques (tasa de ranura omitida) oscila entre el 2% y más del 10%, y estas ranuras no pueden ser votadas. El validador promedio vota con éxito en aproximadamente el 80% de las ranuras, ganando 345,600 créditos en un período de 432,000 ranuras.

La olla total de inflación se divide primero en función de los créditos ganados para la época. La parte de un validador de los créditos totales (sus créditos divididos por la suma de todos los créditos de los validadores) determina su recompensa proporcional. Esto se pondera aún más por la participación.

Por lo tanto, un validador con el 1% del total de participación debería ganar aproximadamente el 1% de la inflación total si tienen un número promedio de créditos. Si tienen más o menos del número promedio de créditos, sus recompensas fluctuarán en consecuencia.

Las diferencias en el rendimiento de votación es una de las razones por las que los retornos (medidos en APY) que los validadores ofrecen a los apostadores varían. Otro factor es la tasa de comisión cobrada por los validadores, que es un porcentaje de las recompensas totales por inflación dirigidas a su validador. Además, el hecho de que un validador esté desconectado o fuera de sincronización con la cadena de bloques (conocido como negligencia) impacta significativamente en los retornos.

Recompensas de bloque

Los validadores designados como líderes para un bloque específico reciben recompensas adicionales por el bloque. Estas recompensas comprenden el 50% de las tarifas base y el 50% de las tarifas prioritarias de todas las transacciones dentro del bloque, mientras que las tarifas restantes se queman. Solo el validador que produjo el bloque recibe estas recompensas. A diferencia de las recompensas de participación, que se distribuyen por época, las recompensas por bloque se acreditan instantáneamente en la cuenta de identidad del validador cuando se produce el bloque.

Participación líquida

El staking líquido se ha convertido en una alternativa popular al staking nativo. Los participantes reciben un token, conocido como Token de Staking Líquido (LST) o Derivado de Staking Líquido (LSD), a cambio de apostar sus SOL, generalmente en un pool de staking que delega sus tokens en varios validadores. Los tokens LST recién recibidos representan la participación del usuario en los SOL apostados. Estos tokens pueden ser intercambiados, utilizados en aplicaciones o transferidos a otros mientras siguen generando recompensas de staking. La principal ventaja de este sistema es que mejora significativamente la eficiencia de capital.

Precio de LST = (SOL total apostado en el pool * precio de SOL) / LST total acuñado

Con el staking nativo tradicional, con el tiempo, el staker acumulará directamente más SOL. Mientras que con el staking líquido, las recompensas se reinvierten en el pool aumentando el valor justo del LST. Siempre que haya un mecanismo para canjear LSTs por el SOL subyacente apostado, los traders de arbitraje se asegurarán de que el precio del token siga siendo racional.

Jito

Hasta el momento de escribir, más del 80% ( fuente) de la participación en Solana utiliza el software validador de clientes Jito. Este cliente, un fork del cliente original Agave, introduce una subasta de espacio de bloque fuera del protocolo que proporciona a los validadores incentivos económicos adicionales a través de propinas. Este incentivo adicional es un factor importante en la amplia adopción del cliente Jito entre los validadores.

Cuando los líderes utilizan el cliente validador Jito, sus transacciones son dirigidas inicialmente al Jito-Relayer. Este software de código abierto funciona como un enrutador proxy de transacciones. Otros nodos de la red permanecen inconscientes de la existencia del Jito-Relayer, ya que simplemente envían transacciones a la dirección y configuración de puerto que el líder ha anunciado a través de la red de gossip como su ingreso_socket, asumiendo que es el líder.

El relayer retiene todas las transacciones durante 200 milisegundos antes de reenviarlas al líder. Este mecanismo de "tope de velocidad" retrasa los mensajes de transacciones entrantes, proporcionando una breve ventana para realizar subastas. Después de 200 milisegundos, el relayer libera optimistamente las transacciones independientemente de los resultados de la subasta.

Las subastas de espacio de bloque ocurren fuera de la cadena a través del Motor de Bloque Jito, lo que permite a los buscadores y aplicaciones enviar grupos de transacciones ejecutadas atómicamente conocidas como paquetes. Estos paquetes suelen contener transacciones sensibles al tiempo, como arbitrajes o liquidaciones. Jito cobra una comisión del 5% en todas las propinas, con una propina mínima de 10,000 lamports. Las propinas funcionan completamente fuera del protocolo, independientemente de las tarifas de prioridad y base del protocolo. Anteriormente, Jito operaba un servicio canónico de mem-pool fuera del protocolo, que ahora ha sido desaprobado.

Descargo de responsabilidad：

1. Este artículo es reproducido de [ helius]. Todos los derechos de autor pertenecen al autor original [Lostin]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo, y lo resolverán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.