Guía sobre la Calidad de Servicio Ponderada por Stake en Solana

¿Qué es la Calidad de Servicio Ponderada por Stake (QoS)?

La QoS (Calidad de Servicio) ponderada por stake es una característica de implementación que, cuando está habilitada, permite a los líderes (productores de bloques) identificar y priorizar las transacciones enviadas a través de un validator con stake como mecanismo adicional de resistencia sybil. Dado que Solana es una red de prueba de participación, es natural extender la utilidad de la ponderación por stake a la calidad de servicio de las transacciones. Bajo este modelo, un validator con un 0,5% de stake tendría el derecho de transmitir hasta el 0,5% de los paquetes al líder y sería capaz de resistir ataques sybil del resto de la red.

Los operadores que habiliten esta función mejorarán la seguridad y el rendimiento de la red al reducir la probabilidad de que los validators con poco o ningún stake (de menor calidad) puedan "ahogar" las transacciones provenientes de validators de mayor calidad (mayor stake) (es decir, mayor Resistencia Sybil).

Un beneficio potencial de implementar la QoS ponderada por stake podría materializarse si existen ciertos acuerdos entre los Validators y los nodos RPC. Los nodos RPC pueden lograr que más transacciones sean incluidas en bloques al acordar asociarse con Validators, y los Validators pueden vender más capacidad a los nodos RPC. Estos acuerdos deben establecerse directamente entre los operadores de RPC y los Validators, e incluyen la implementación de los pasos descritos más adelante en este documento para completar el emparejamiento.

¿A quién beneficia la QoS ponderada por stake?

Los operadores de infraestructura RPC comercial y los exchanges probablemente se encuentren entre los principales beneficiarios de la QoS ponderada por stake. Los operadores de RPC estarán en una posición ideal para adquirir o negociar acuerdos con validators con stake, lo que les permitirá lograr un mayor porcentaje de transacciones incluidas en bloques en general. Los exchanges (u otras entidades) que alojen sus propios nodos validator y nodos RPC en la misma infraestructura podrán habilitar la función internamente, con la confianza de que los nodos RPC que operan en su propia infraestructura son de confianza.

¿Por qué es importante la QoS ponderada por stake?

Con la QoS ponderada por stake habilitada, un validator que posee el 1% del stake tendrá el derecho de transmitir hasta el 1% de los paquetes al líder. De esta manera, los validators con mayor stake tienen garantizada una mayor calidad de servicio, lo que impide que validators de menor calidad (con menos stake) inunden maliciosamente estas transacciones, aumentando la Resistencia Sybil general.

Dicho de otra manera, imagina cómo sería el mundo si los coches con un solo pasajero pudieran circular libremente por el carril de alta ocupación. Pronto, ese carril, diseñado para transportar a más personas utilizando el mismo tramo de autopista, quedaría inutilizado. La funcionalidad general de la autopista se vería deteriorada y menos conductores podrían llegar a sus destinos. Este efecto es similar a lo que ocurre cuando se permite a los validators con poco stake enviar transacciones al Líder con la misma prioridad que los validators con mucho stake.

¿Quién debería habilitar la QoS ponderada por stake?

La QoS ponderada por stake debe ser habilitada por nodos Validator emparejados con nodos RPC de alta confianza. Esto es útil en situaciones como ejecutar un RPC y un Validator en la misma infraestructura, donde el nivel de confianza ya es alto. La QoS ponderada por stake funciona mejor en configuraciones de alta confianza y requiere que el Validator y el RPC lleguen a un acuerdo previo antes de habilitar la función. Se recomienda encarecidamente que los Validators no intenten habilitar la QoS ponderada por stake con RPCs de dudosa confianza.

El stake debe aplicarse a los validators productores de bloques. No es necesario, recomendable ni efectivo delegar stake a servidores RPC.

¿Cómo funciona la QoS ponderada por stake?

Con la QoS ponderada por stake habilitada, los nodos RPC emparejados con un validator obtienen un stake "virtual" en cuanto a cómo ese líder gestiona el tráfico TPU (Unidad de Procesamiento de Transacciones) entrante desde ese nodo RPC, algo que normalmente no es posible. Por definición, los nodos RPC son "sin stake" y "sin voto", también conocidos como "sin consenso", y no pueden acceder a los beneficios de las transacciones priorizadas mediante staking de la misma manera que los nodos de consenso. ¿Cómo se utiliza la QoS ponderada por stake para procesar transacciones? Habilitar la QoS ponderada por stake requiere configurar un nodo validator y un nodo RPC para formar una relación de par de confianza. Esto implica pasos de configuración separados tanto para el nodo validator como para el nodo RPC, que se detallan a continuación. Los operadores que deseen habilitar la QoS ponderada por stake necesitarán lo siguiente antes de comenzar:

Un validator con stake ejecutándose en la red Y un RPC emparejado con el validator

La QoS ponderada por stake no funcionará a menos que AMBOS lados estén correctamente configurados.

Configuración del nodo Validator

En el validator, deberás habilitar --staked-nodes-overrides /path/to/overrides.yml. El indicador --staked-nodes-overrides ayuda al validator a priorizar las transacciones que provienen de fuentes conocidas para aplicar stake a sus transacciones. Esto puede ayudar a un validator a priorizar ciertas transacciones sobre hosts conocidos por encima de otros, permitiendo el uso de la QoS ponderada por stake con RPCs. Los RPCs no deben tener stake en ningún caso.

Actualmente, la QoS ponderada por stake otorga una prioridad ponderada por stake al 80% de la capacidad TPU de un líder. Sin embargo, existen opciones de configuración que pueden utilizarse para asignar virtualmente diferentes pesos de stake a los pares TPU, incluyendo la asignación de stake virtual a pares sin stake.

El archivo de configuración para --staked-nodes-overrides tiene el siguiente aspecto:

staked_map_id:
  pubkey1: 1000000000000000
  pubkey2: 4000000000000000

staked_map_id contiene un mapa de la clave pública de identidad a la cantidad de stake en lamports que se aplicará a cada RPC. Cuando se establece, el validator priorizará las conexiones QUIC con el RPC encontrado en ese pubkey de identidad, asignando una cantidad de stake a sus transacciones. El 80% de la capacidad TPU del líder se distribuirá proporcionalmente en función de las cantidades en lamports especificadas en el archivo staked-nodes-overrides y el stake existente del clúster.

Configuración del nodo RPC

En el RPC deberás usar --rpc-send-transaction-tpu-peer para reenviar transacciones a un líder específico. El uso exacto sería --rpc-send-transaction-tpu-peer HOST:PORT. El Host es la dirección IP del líder en el que tienes habilitado staked-nodes-overrides y el Puerto es el puerto QUIC TPU de ese host. El puerto QUIC TPU de un líder puede identificarse realizando una llamada RPC a getClusterNodes.

El emparejamiento tendría el siguiente aspecto:

Diagrama de RPCs emparejados con Validator para QoS ponderada por stake

Conclusión

La QoS ponderada por stake es una función opcional que llegó en la v1.14 del cliente de Solana, ahora conocido como Agave. Agave es una versión bifurcada del cliente de Solana Labs que se ha convertido en la rama activa utilizada por el equipo de Anza, una organización derivada compuesta por el antiguo equipo de ingeniería de Solana Labs.

La función de QoS ponderada por stake será muy probablemente útil para los operadores de infraestructura RPC que estén en posición de establecer relaciones de confianza con operadores de nodos con stake. También será útil para los exchanges, que operan tanto nodos RPC como nodos validator y son capaces de establecer conexiones de alta confianza internamente.