Calidad de servicio ponderada por stake: todo lo que necesitas saber

Introducción

Solana está a la vanguardia de la tecnología blockchain como una red de alto rendimiento y baja latencia que amplía los límites de lo que puede lograr una red descentralizada. Sin embargo, esto plantea desafíos importantes. Un momento decisivo en el desarrollo de Solana fue su interrupción del 30 de abril de 2022, que evidenció la necesidad de mecanismos más sólidos para gestionar grandes volúmenes de transacciones y mantener el rendimiento de la red bajo cargas intensas.

La calidad de servicio ponderada por stake (SWQoS) se creó en respuesta a este evento. Este mecanismo prioriza el tráfico de red según el stake de los validadores, lo que permite que aquellos con más stake envíen transacciones con mayor prioridad. SWQoS se diseñó para evitar que los validadores con poco stake saturen la red, mejorando la resiliencia y la eficiencia de Solana.

Este artículo analiza SWQoS, el modelo de procesamiento de transacciones de Solana y cómo SWQoS influye en él. También examina las conexiones con stake, su configuración y la diferencia entre SWQoS y las comisiones de prioridad. Además, aborda implicaciones futuras, en especial la creciente importancia de los validadores y los tokens de staking líquido (LST), las barreras de entrada y los supuestos de confianza inherentes a este sistema.

Este artículo supone que conoces el modelo de programación de Solana y QUIC. Si no estás familiarizado con estos temas, te recomendamos leer primero los siguientes artículos antes de continuar:

• El modelo de programación de Solana: introducción al desarrollo en Solana
• Cómo mitigar el spam rápidamente: todo lo que necesitas saber sobre Solana y QUIC

Aun así, se proporciona contexto cuando es necesario.

¿Qué es la calidad de servicio ponderada por stake?

La calidad de servicio ponderada por stake (SWQoS) es un mecanismo que prioriza el tráfico de red según el stake de los validadores. Este mecanismo permite que los validadores con más stake envíen transacciones de forma más efectiva, lo que mejora la calidad de su servicio.

Dado que Solana es una red de prueba de participación, es natural extender la ponderación por stake al rendimiento de las transacciones. En pocas palabras, Solana utiliza el stake (es decir, los fondos bloqueados con un validador para proteger la red) para indicar qué tan confiable es un validador. Cuanto más stake tenga, mayor será su interés directo en la seguridad y confiabilidad de la red. Además, la calidad de servicio es un concepto de redes que prioriza ciertos paquetes para que tengan un rendimiento más confiable. Por lo tanto, Solana ofrece a los validadores con stake un rendimiento más confiable al enviar transacciones mediante conexiones priorizadas.

El objetivo principal de SWQoS es impedir que los validadores con poco stake saturen la red con transacciones que desplacen las enviadas por validadores de mayor calidad o con más stake. Por ejemplo, si un validador posee el 5 % del stake total, puede enviar el 5 % de todos los paquetes al líder. SWQoS puede considerarse un mecanismo de resistencia a ataques Sybil, ya que dificulta que los actores maliciosos inunden la red con transacciones de «baja calidad».

Imagina que estás en un evento popular, como un concierto o un parque de diversiones, con una cantidad limitada de boletos. Hay filas normales en las que cualquiera puede esperar para comprar boletos, pero pueden volverse largas y lentas. También hay filas VIP reservadas para los clientes que pagan más. Estas filas son mucho más cortas y rápidas porque el acceso se limita a quienes cumplen ciertos criterios, como tener una membresía específica, y se garantiza la entrada de una cantidad determinada de personas a la vez. En el contexto de Solana, SWQoS funciona como estas filas VIP, donde el acceso depende de cuánto stake tenga un validador. Cuanto más stake tengas, mayor acceso VIP (es decir, más conexiones priorizadas) obtendrás, lo que garantiza un procesamiento de boletos (transacciones) más rápido y confiable.

Entonces, ¿cómo funciona esto en la práctica? Primero, es importante entender cómo Solana procesa las transacciones.

Cómo procesa Solana las transacciones

La Unidad de Procesamiento de Transacciones (TPU) de Solana gestiona y ejecuta transacciones de forma eficiente. El procesamiento pasa por varias etapas diferenciadas para garantizar que las transacciones se validen, ejecuten y propaguen por la red. Estas son la etapa de obtención, la etapa SigVerify, la etapa bancaria, el servicio de prueba de historial (PoH) y la etapa de difusión.

La etapa de obtención

La etapa de obtención recibe de los clientes las transacciones entrantes a través de la red. Agrupa la entrada de un socket UDP en lotes y la clasifica en tres sockets principales:

• tpu: Para transacciones normales, como transferencias de tokens, acuñaciones de NFT e interacciones con programas
• tpu_vote: Para transacciones de voto
• tpu_forwards: Reenvía los paquetes no procesados al siguiente líder si el líder actual no puede procesar todas las transacciones.

Estos sockets se crean en Gossip, se almacenan en la estructura ContactInfo y se etiquetan según su socket correspondiente.

La etapa de obtención utiliza un mecanismo para combinar los paquetes recibidos al mismo tiempo. Así reduce la cantidad de operaciones de procesamiento de paquetes individuales y mejora el rendimiento. Cuando recibe paquetes reenviados, los marca con una bandera FORWARDED para que se reconozcan correctamente en las etapas posteriores. Si el nodo no es el líder actual, estos paquetes reenviados se descartan para evitar un procesamiento innecesario. Sin embargo, si el nodo es el líder, los paquetes se aceptan y procesan.

La etapa de obtención crea canales sin límites (por ejemplo, packet_sender, packet_receiver) para transferir las transacciones a la siguiente etapa, SigVerify. Estos canales desacoplan las etapas de la TPU y permiten que funcionen simultáneamente sin bloquearse entre sí. La función unbounded crea un canal con capacidad ilimitada para garantizar que los paquetes no se descarten por desbordamiento del canal. 

Las transacciones se agrupan en lotes de 128 paquetes antes de enviarse a la etapa SigVerify. Este agrupamiento permite procesarlas con mayor eficiencia y reduce la sobrecarga de gestionar paquetes individuales. 

Ten en cuenta que la etapa de obtención funciona en varios hilos para gestionar un alto rendimiento. Cada hilo se encarga de una tarea específica, como recibir paquetes, procesar lotes y reenviar transacciones. Se crea un hilo para cada tipo de socket (es decir, tpu, tpu_vote, tpu_forwards) mediante la función streamer::receiver. Cada hilo escucha su socket asignado, procesa los paquetes entrantes y los envía por el canal correspondiente.

Al gestionar de forma eficiente la recepción y clasificación de transacciones, la etapa de obtención sienta las bases para todas las etapas posteriores de procesamiento en la TPU de Solana.

La etapa SigVerify

La etapa SigVerify es la segunda etapa del proceso de transacciones de Solana. Es esencial para garantizar la integridad y autenticidad de las transacciones. 

En esta etapa, la TPU recibe lotes de transacciones de la etapa de obtención mediante canales sin límites. La tarea principal consiste en verificar las firmas de las transacciones con el esquema de firma Ed25519. Esta validación criptográfica confirma que el propietario correcto de las cuentas involucradas firmó la transacción.

La etapa SigVerify está diseñada para ofrecer un alto rendimiento. Aprovecha las capacidades de procesamiento paralelo de las CPU y GPU modernas para verificar firmas. De forma predeterminada, la CPU realiza todo el procesamiento. Sin embargo, debido a su naturaleza paralela, la descarga del trabajo en la GPU acelera considerablemente el proceso cuando hay bibliotecas de rendimiento disponibles.

El proceso comienza con la función new, que inicializa la etapa SigVerify y configura los canales receptores necesarios para recibir paquetes de la etapa de obtención. La función verifier se encarga de recibir grupos y verificar firmas. Gestiona la deduplicación, descarta los paquetes excesivos y verifica los restantes. La función utiliza el método ed25519_verify de verificación de firmas. Durante los periodos con un gran volumen de transacciones, se reduce la carga. Para ello, la etapa SigVerify descarta los paquetes excesivos. Lo hace agrupando los paquetes por su dirección IP de origen y asignando una cantidad máxima de paquetes que se procesarán por dirección.

Las transacciones con firmas no válidas se marcan y descartan. Este proceso garantiza que solo avancen las transacciones válidas e impide que las fraudulentas o incorrectas lleguen a la siguiente etapa.

Después de verificar las firmas, las transacciones válidas pasan a la siguiente etapa (es decir, la etapa bancaria) mediante otro conjunto de canales sin límites. Así, las etapas permanecen desacopladas y pueden funcionar simultáneamente. Ten en cuenta que esta etapa opera en varios hilos. Cada hilo procesa un subconjunto de transacciones, verifica firmas y realiza la deduplicación y reducción de carga.

La etapa bancaria

La etapa bancaria es la tercera etapa del proceso de transacciones de Solana. Es fundamental porque aquí se ejecutan las transacciones y se aplican al estado actual del libro mayor. La etapa bancaria aprovecha el entorno de ejecución Sealevel exclusivo de Solana para permitir el procesamiento paralelo de transacciones con alto rendimiento.

La etapa bancaria tiene seis hilos: dos dedicados a procesar transacciones de voto provenientes de la TPU o Gossip y cuatro dedicados a transacciones que no son de voto. Cada hilo funciona de forma independiente y recibe paquetes de un canal compartido (esto cambiará después de la versión 1.18), al cual SigVerify envía los paquetes en lotes. Cada hilo toma transacciones de este canal compartido y las almacena en un búfer local. El búfer local funciona como una cola de prioridad que se actualiza dinámicamente para reflejar los cambios en tiempo real del estado de las transacciones y las demandas de la red. 

La gestión de estas transacciones depende de si el validador aparece en el calendario de líderes. Si no está cerca de convertirse en líder, reenvía los paquetes al próximo líder y los descarta. A medida que se acerca su turno (a unos ~20 slots), sigue reenviando los paquetes, pero los conserva por si los próximos líderes no logran procesarlos. Cuando faltan dos slots para que se convierta en líder, retiene los paquetes para asegurarse de procesarlos cuando asuma ese rol.

Cada hilo procesa transacciones durante la producción de bloques tomando las primeras 128 transacciones de su cola local. El proceso incluye pasos como bloquear, comprobar, cargar, ejecutar, registrar, confirmar y desbloquear. 

La etapa bancaria utiliza un enfoque de múltiples iteradores para agrupar transacciones en lotes. Este enfoque permite recorrer simultáneamente un conjunto de datos y agrupar las transacciones en lotes sin conflictos. Primero, las transacciones se serializan en un vector basado en prioridades. Después, el iterador múltiple coloca iteradores en puntos donde las transacciones no entran en conflicto y crea lotes de 128 transacciones. Las transacciones con conflictos se omiten y se incluyen en lotes posteriores una vez resueltos. Tras formar un lote, se ejecutan las transacciones. Las transacciones correctas se registran en el servicio de prueba de historial y se difunden por la red mediante Turbine.

Servicio de prueba de historial (PoH)

El servicio de prueba de historial (PoH) es un componente fundamental del proceso de transacciones de Solana. Ofrece una forma verificable de registrar el tiempo y ordenar los eventos dentro de la red, lo que garantiza una secuenciación eficiente y segura de las transacciones. Mediante una cadena de hashes, genera una secuencia criptográfica que funciona como marca de tiempo para las transacciones. Esta cadena continua de hashes crea un registro histórico que demuestra el paso del tiempo entre eventos.

El servicio PoH permite que todos los participantes de la red acuerden el orden de las transacciones sin necesidad de una autoridad central que controle el tiempo. También ayuda a sincronizar los validadores de toda la red. Además, respalda el proceso de elección de líderes de Solana al proporcionar una marca de tiempo confiable para determinar cuándo un validador debe convertirse en líder y producir el siguiente bloque.

El servicio PoH comienza inicializando un valor semilla que genera una secuencia de hashes. A medida que se reciben las transacciones, se etiquetan con el hash actual de la secuencia PoH, lo que les proporciona una marca de tiempo única. Después, los validadores verifican la secuencia de hashes para confirmar el orden y el momento de las transacciones.

Para obtener más información sobre la prueba de historial, lee nuestro artículo Prueba de historial, prueba de participación y prueba de trabajo: explicación. Si la criptografía te parece un idioma desconocido, también te recomendamos nuestro artículo Introducción a las herramientas criptográficas: explicación de las funciones hash y los árboles de Merkle.

La etapa de difusión

La etapa de difusión es el último paso del proceso de transacciones de Solana. Se encarga de distribuir las transacciones validadas y confirmadas al resto de la red.

Una vez que las transacciones se procesan y confirman durante la etapa bancaria, se convierten en entradas. Luego, estas entradas se empaquetan en estructuras de datos llamadas shreds. La etapa de difusión serializa estos shreds, los firma y genera códigos de corrección de errores para mejorar la integridad y recuperación de los datos. Los shreds se envían a los pares mediante un proceso estructurado de difusión en forma de árbol llamado Turbine. Es un proceso de distribución eficiente y redundante, y la codificación de corrección de errores permite que los validadores reconstruyan datos perdidos o dañados.

Para consultar un análisis más completo de Turbine, lee nuestro artículo Turbine: propagación de bloques en Solana.

El ciclo de vida de una transacción con SWQoS

A diferencia de otras blockchains, Solana no tiene un mempool donde las transacciones esperan antes de procesarse. En su lugar, se enrutan directamente al líder actual y su TPU las procesa. Los usuarios crean transacciones de forma directa o indirecta con una cartera o aplicación y las envían a nodos RPC mediante la API JSON RPC. Estos nodos actúan como intermediarios entre los usuarios y los validadores de Solana. Es importante destacar que no deben tener ningún stake en la red. Es decir, los nodos RPC no tienen stake ni derecho a voto y, por lo tanto, no participan en el consenso.

Ahora, las conexiones con un líder se establecen mediante QUIC. QUIC se incorporó a los puertos que reciben transacciones de usuarios para reemplazar UDP en la TPU de Solana. Como QUIC requiere un protocolo de enlace, es posible limitar el tráfico de un actor para que la red se concentre en procesar transacciones auténticas y filtre el spam. Por supuesto, esa era la intención al implementar QUIC, y este artículo no debatirá su eficacia actual. Lo importante es que las conexiones con un líder se establecen mediante QUIC.

Existen dos tipos de conexiones:

• 500 conexiones abiertas disponibles para cualquier nodo RPC
• 2000 conexiones ponderadas por stake disponibles únicamente para validadores con stake. Los validadores reciben una proporción de estas conexiones según su stake

Para que un RPC retransmita una transacción de forma efectiva, debe vincularse con un validador con stake. Como los RPC no tienen stake en la red, los validadores deben extenderles virtualmente su stake. Los validadores pueden usar la bandera --staked-nodes-overrides para asignar una parte de sus conexiones con stake a nodos RPC específicos. 

Un validador debe especificar la ruta de un archivo YAML mediante --staked-nodes-overrides flag para configurar sus conexiones ponderadas por stake. El archivo YAML contiene asignaciones con el siguiente formato:

staked_map_id:
	<pubkey_of_RPC>: 80000000000000000

Cada clave pública de una identidad RPC determinada requiere un valor en lamports. Este valor especifica la ponderación de stake que quieres asignar a la identidad RPC. Por ejemplo, si especificas un millón de SOL, le asignas un millón de SOL dividido entre el stake activo total. En esencia, proporcionas conexiones con stake al nodo RPC como si fuera un validador con esa cantidad de stake en la red. Estás diciendo: «Desde mi perspectiva local, trata esta identidad RPC como si tuviera x cantidad de stake al comunicarse con mi validador». Ten en cuenta que esta configuración no exige reiniciar el validador: puedes modificar el archivo y volver a cargarlo sobre la marcha.

Además, el relayer de Jito admite la bandera de anulación para nodos con stake. Para optimizar el rendimiento, se recomienda ejecutar el relayer en la misma máquina que el nodo con stake.

Para utilizar estas conexiones con stake, los operadores RPC deben usar la bandera --rpc-send-transaction-tpu-peer, que requiere la IP y el puerto de la TPU del validador con stake. El puerto de la TPU suele corresponder al inicio del rango de puertos dinámicos más tres, según aparece en Gossip. En el caso de Jito, el tráfico se enviará al relayer ejecutado por el operador, ya que no se pueden utilizar los relayers públicos de Jito. Los operadores RPC deben buscar en sus registros entradas como solana_quic_client y warm para verificar su conexión. Ten en cuenta que esta configuración exige que el nodo RPC ejecute un cliente Agave v1.17.28 o posterior para admitir la bandera necesaria.

En general, el ciclo de vida de una transacción con SWQoS sigue siendo prácticamente igual al de una transacción normal. Los usuarios crean y envían transacciones mediante nodos RPC, que luego las envían al líder. Sin embargo, las transacciones se envían mediante conexiones con stake cuando un nodo RPC está vinculado con un validador con stake y utiliza la bandera --rpc-send-transaction-tpu-peer. En resumen:

• Creación de la transacción: Un usuario crea una transacción mediante su cartera, una aplicación o código 
• Envío a un nodo RPC: La transacción se envía a un nodo RPC mediante la API JSON RPC
• Conexión QUIC: El nodo RPC establece una conexión QUIC con el líder y utiliza conexiones abiertas o ponderadas por stake según su configuración
• QoS ponderada por stake: Si el nodo RPC está vinculado con un validador con stake, utiliza las conexiones con stake del validador, lo que mejora el rendimiento de la transacción
• Reenvío al líder: La transacción se envía al líder mediante estas conexiones con stake, con una menor probabilidad de retrasarse o descartarse
• Procesamiento de la transacción: La transacción atraviesa la TPU, como se explicó antes, y el líder la procesa

SWQoS mejora el ciclo de vida de las transacciones al garantizar que los validadores con stake y sus nodos RPC vinculados tengan un mejor acceso al líder. Esto reduce la probabilidad de retrasos por congestión de la red. Este mecanismo funciona junto con las comisiones de prioridad para mejorar el rendimiento de las transacciones.

SWQoS frente a comisiones de prioridad: una distinción clara

Cuando la red está congestionada, SWQoS reduce la probabilidad de que las transacciones de validadores con mucho stake se retrasen o descarten. Este sistema puede compararse, y suele compararse, con una carretera de peaje donde los validadores con más stake acceden a rutas menos congestionadas, como si tuvieran más carriles en una autopista. Observa, por ejemplo, la imagen anterior. En Colorado, los conductores pueden esperar en el tráfico o pagar unos dólares adicionales para conducir por un carril de peaje. Los carriles exprés son la red de carriles prémium de Colorado, cuyos precios se ajustan constantemente para mantener el tráfico fluido. Por lo tanto, podemos comparar las conexiones con stake de Solana con los carriles exprés de Colorado, ya que ambos son rutas priorizadas cuyo objetivo es reducir la congestión para los usuarios prémium.

Sin embargo, es esencial distinguir entre SWQoS y las comisiones de prioridad, ya que la analogía habitual con una carretera de peaje puede difuminar la diferencia entre ambos conceptos:

• Las comisiones de prioridad entran en juego durante la etapa bancaria, cuando los líderes priorizan las transacciones según las comisiones pagadas. La idea es que las transacciones que pagan comisiones más altas se procesen primero, lo que garantiza una ejecución más rápida para los usuarios dispuestos a pagar más.
• SWQoS mejora el acceso a las conexiones y no afecta la prioridad de las transacciones dentro de la cola del líder. SWQoS garantiza que los validadores con stake tengan un mejor acceso a la red, lo que reduce la probabilidad de que las transacciones se retrasen o descarten por la congestión

Mientras que las comisiones de prioridad influyen en cómo se ordenan y procesan las transacciones una vez dentro de la cola del líder, SWQoS garantiza que las transacciones enviadas por validadores con stake tengan una ruta priorizada para llegar al líder. Ambos mecanismos buscan mejorar el rendimiento de la red, pero operan en etapas distintas del ciclo de vida de la transacción.

Las guerras de SWQoS

SWQoS está destinado a convertirse en un aspecto fundamental de la infraestructura de red de Solana. Influirá considerablemente en el ecosistema al optimizar el procesamiento de transacciones y priorizar las conexiones de los validadores con stake al líder. No puedo enfatizarlo lo suficiente.

Se podría argumentar que la ventaja de utilizar validadores con mucho stake comienza a reducirse cuando la red no está congestionada y las transacciones no dependen del tiempo. Esto se debe a que la red tiene capacidad suficiente para procesar transacciones rápidamente, sin importar la ponderación de stake que las respalde. Sin embargo, a medida que crezca la demanda de Solana con la adopción masiva en el horizonte, es posible que la red no siempre tenga capacidad suficiente para procesar todas las transacciones sin retrasos ni descartes ocasionales. Esto no significa que Solana no pueda escalar, ya que podría ser una de las mejores opciones, si no la mejor, para lograr una blockchain escalable. El punto es que, conforme aumente la demanda, SWQoS seguirá siendo importante para ofrecer una UX excelente.

A su vez, el papel de los validadores se vuelve aún más crucial, lo que genera más competencia e innovación para ofrecer el mejor servicio posible. Naturalmente, ¿no significaría esto que todos querrían poner en marcha su propio validador?   

Validadores y tokens de staking líquido (LST)

La tendencia es clara: todos los protocolos serios de Solana ejecutarán un validador. Esto se debe a que será necesario para respaldar sus aplicaciones. Si te interesa ejecutar tu propio validador, tenemos la siguiente guía en el blog de Helius para ayudarte a comenzar.

Estamos al borde de una enorme explosión cámbrica de LST en Solana, intensificada por SWQoS. Solo este mes, el stake total (es decir, nativo + LST) aumentó aproximadamente 3,2 millones. El valor de mercado de los LST por sí solos se encuentra actualmente entre 6000 y 9000 millones de dólares este mes. Protocolos como Sanctum se perfilan como actores importantes, ya que su plataforma permite que validadores y aplicaciones creen sus propios LST. Además, Picasso Network permite el restaking en Solana y funciona como un centro para que los LST tengan más utilidad y rendimiento. Por lo tanto, la capacidad de crear un LST con utilidad adicional ya está disponible y en pleno auge.

Sin embargo, deben considerarse algunas posibles barreras de entrada.

Barreras de entrada

A pesar de sus posibles beneficios, SWQoS introduce varias barreras de entrada. En concreto, se incorporó un requisito mínimo de stake en la versión v1.17.31 del cliente Agave para tratar a los validadores con poco stake como pares sin stake. El problema era que los nodos con poco stake podían abusar de las conexiones con stake al recibir un ancho de banda desproporcionado. Ahora, los nodos con una proporción de stake inferior a la siguiente fórmula se tratan como nodos sin stake:

stake / total_stake < 1 / (max packet per 100ms)

Esto significa que los clientes con menos de unos 15 000 SOL en stake ahora se clasifican como validadores sin stake. Este requisito podría sumarse a las ya elevadas exigencias financieras y técnicas de operar un validador de Solana. También podría excluir de la red a los participantes más pequeños y a los validadores independientes. El requisito equivale aproximadamente a 3 millones de dólares estadounidenses, una suma que parece considerable a primera vista. 

Sin embargo, como señala Austin Federa, el umbral es solo 1/25 000 del stake total, lo que podría considerarse bajo. Además, si la mayoría de los validadores que compiten por stake mejoran continuamente su rendimiento para ofrecer el mejor servicio posible y maximizar sus propios retornos, toda la red se beneficiará. Esto es exactamente lo que Toly describe como el objetivo general de SWQoS.

En Helius, estamos reduciendo la barrera de entrada para todos los planes de pago que envían transacciones con la comisión recomendada por Helius. Es decir, cualquier usuario que envíe transacciones mediante un plan compartido de pago ahora utilizará nuestras conexiones con stake si envía una comisión igual o superior al valor recomendado por nuestra API de comisiones de prioridad. También simplificamos este proceso con nuestra nueva funcionalidad de transacciones inteligentes, agregada a nuestros SDK de Node.js y Rust. En el nivel más básico, sin importar el SDK utilizado, los usuarios proporcionan su par de claves y las instrucciones que desean ejecutar, y nosotros nos encargamos del resto. Ahora, los usuarios pueden acceder a conexiones con stake compartidas por tan solo 50 USD al mes con un plan Developer. Ten en cuenta que también ofrecemos conexiones con stake dedicadas, que garantizan el ancho de banda y se recomiendan para empresas, analistas cuantitativos y firmas de trading. Si te interesan las conexiones con stake dedicadas, contacta a nuestro equipo de ventas.

Es importante señalar que el stake probablemente comenzará a concentrarse entre validadores operados por grandes protocolos y proveedores RPC que pueden cobrar una comisión del 0 %. Tomemos a Helius como ejemplo: podemos generar ingresos de otras fuentes para subsidiar los costos de operar un validador. Lo hacemos para mejorar la descentralización de la red mediante un validador líder operado por un equipo nativo de Solana y, al mismo tiempo, obtener más acceso a conexiones con stake para mejorar la experiencia de nuestros usuarios.

Supuestos de confianza

Si es probable que el stake se concentre entre validadores operados por grandes protocolos y proveedores RPC, es importante delegarlo a un validador que tenga en cuenta los intereses de Solana. SWQoS introduce varios supuestos de confianza.

Uno de los principales supuestos de confianza es la necesidad de un alto grado de confianza entre validadores y nodos RPC. Como se explicó antes, SWQoS permite que los líderes identifiquen y prioricen las transacciones de validadores con stake. Como los nodos RPC no tienen stake ni derecho a voto y no participan en el consenso, no pueden beneficiarse directamente de las transacciones priorizadas del mismo modo que los validadores con stake. Por lo tanto, debe establecerse una relación de confianza entre los validadores y los nodos RPC para aprovechar los beneficios de SWQoS.

Esta relación de confianza es crucial porque habilitar SWQoS implica compartir configuraciones de red sensibles y permite que los nodos RPC influyan en la priorización de transacciones. Los validadores deben asegurarse de que los nodos RPC con los que se vinculan actúen en beneficio de la red y no abusen del stake extendido con fines maliciosos. Los validadores y nodos RPC deben acordar y comprender previamente cómo se utilizarán las conexiones con stake. Idealmente, esta configuración debe establecerse entre entidades con un alto grado de confianza, como socios de larga trayectoria o miembros de una misma organización.

En la actualidad, estas relaciones suelen permanecer ocultas. De cara al futuro, no imagino un escenario en el que los operadores RPC no negocien con los validadores para obtener asignaciones de stake. Se necesita mayor transparencia para que el usuario promedio sepa qué RPC y validadores respalda. La demanda de esta transparencia solo aumentará con el tiempo.

Conclusión

SWQoS está preparado para revolucionar la infraestructura de red de Solana. Aunque ofrece muchos beneficios, como un mejor rendimiento de las transacciones y una mayor resistencia a ataques Sybil, también introduce nuevos desafíos y supuestos de confianza que deben gestionarse con cuidado. Aunque SWQoS está diseñado para priorizar las transacciones enviadas por validadores con stake, actualmente nada obliga a cumplir esta prioridad. Los validadores profesionales suelen sobrescribir la configuración predeterminada e incluso pueden bloquear a ciertos actores. Esto destaca la necesidad de confianza y transparencia en las relaciones entre validadores y nodos RPC para garantizar un uso justo y eficaz de SWQoS. En cualquier caso, su implementación representa un avance importante en la evolución de Solana como una red eficiente y resiliente.

A lo largo de este artículo analizamos SWQoS y cómo influye en el procesamiento de transacciones. También abordamos distinciones importantes, como la diferencia entre SWQoS y las comisiones de prioridad. Además, hablamos del auge de los validadores y los LST, las posibles barreras de entrada y los supuestos de confianza involucrados, lo que ofrece un punto de partida crítico para futuros debates. Comprender todos estos elementos es esencial para aprovechar SWQoS de forma eficaz y mejorar Solana en su conjunto.

Si llegaste hasta aquí, ¡gracias, anon! Ingresa tu dirección de correo electrónico a continuación para no perderte ninguna novedad sobre Solana. ¿Quieres profundizar más? Explora los artículos más recientes del blog de Helius y continúa hoy mismo tu recorrido por Solana.

Recursos adicionales

• Informe y medidas de mitigación de la interrupción de Solana Mainnet Beta del 30 de abril de 2022
• Guía sobre la calidad de servicio ponderada por stake en Solana
• Cómo configurar un validador de Solana
• Envío de transacciones inteligentes
• Formación para validadores de Solana: QoS ponderada por stake