Comisiones de Solana en la teoría y en la práctica

Introducción

La estructura de comisiones de Solana está diseñada para mantener el rendimiento de la red mientras equilibra las variaciones desiguales de la oferta y la demanda. Las comisiones de cualquier blockchain sirven para evitar el spam e incentivar a los validadores. En Solana, algunas de estas comisiones se ajustan dinámicamente según las condiciones de la red, lo que permite calcular con mayor precisión el precio de la demanda en un momento determinado.

Las comisiones de Solana son un tema candente. Sus «mercados locales de comisiones» ofrecen cierta flexibilidad para que Solana determine con mayor precisión el precio del espacio de bloque y de cuentas específicas. La implementación actual está lejos de ser perfecta, pero ofrece garantías flexibles sobre el orden de las transacciones para cada cuenta. Aunque Solana aún se encuentra en sus primeras etapas, el aumento del stake y la actividad en la red exige un análisis y un debate más profundos sobre los efectos directos e indirectos de cualquier cambio en el protocolo, como los cambios en el modelo de comisiones.

En este artículo, analizaremos las comisiones tanto en la teoría como en su comportamiento on-chain. Algunas personas han criticado a Solana por considerarla centralizada y por las fuerzas centralizadoras de su diseño de QoS ponderado por stake y de Turbine. Sin embargo, existe una clara discrepancia entre esas críticas y lo que sucede en la práctica, incluso después de varios años. Del mismo modo, buscamos analizar a fondo cómo se manifiestan las comisiones en el comportamiento on-chain.

Comisiones en la teoría

El sistema de comisiones de Solana consta de dos componentes: la comisión base y la comisión de prioridad. En términos generales, cada componente debería cumplir el siguiente propósito:

• Comisiones base: derecho a utilizar los recursos de la red
• Comisiones de prioridad: determinan el orden en la cola de transacciones de un líder

Comisión base

La comisión base, fijada actualmente en 0.000005 SOL (5000 lamports) por firma, constituye la base del costo de una transacción. Es una comisión que paga una dirección para obtener el derecho a utilizar los recursos de la red. Se trata de un único pago fijo que se abona por adelantado a la red, sin importar la cantidad real de recursos utilizados para ejecutar la transacción ni si esta llega a ejecutarse. Las transacciones de Solana solicitan por adelantado un número específico de unidades de cómputo (CU). Si superan ese número, fallan. Esto significa que, en la actualidad, los desarrolladores tienen pocos o ningún incentivo económico para minimizar las solicitudes de unidades de cómputo.

Comisiones de prioridad

Además, los usuarios pueden pagar una comisión de prioridad para acelerar sus transacciones y aumentar la probabilidad de que se incluyan en un bloque. Esta no es una garantía determinista para quienes pagan por obtener prioridad. Ya se está trabajando para mejorar el determinismo de las transacciones y se espera que la versión 1.18 incluya cambios importantes en el planificador.

Como nota adicional, las transacciones de voto no tienen una comisión de prioridad asociada y reciben un tratamiento distinto al de las transacciones estándar.

El incentivo para que los validadores incluyan transacciones con comisiones de prioridad existe fuera del entorno de ejecución. Los líderes reciben el 50 % de la comisión de prioridad por incluir una transacción en su bloque, mientras que el otro 50 % se quema.

Actualmente, la mayoría de los validadores (más del 80 %) ejecutan versiones sin modificar del cliente de Solana Labs o Jito-Solana. Esto significa que delegan la «producción de bloques» al planificador predeterminado. Algunas personas en Solana llaman «producción de bloques» al «ordenamiento de bloques», aunque en Ethereum son conceptos completamente distintos. Algunos equipos han modificado el código del cliente e implementado un planificador más complejo que permite controlar mejor el flujo de ordenamiento. Esto les permite extraer MEV mediante el reordenamiento de transacciones o ataques sándwich.

Indeterminismo de las comisiones de prioridad

La implementación actual del planificador no garantiza que las transacciones con comisiones de prioridad más altas se incluyan en un bloque determinado. En cambio, ofrece una garantía flexible de que las transacciones con comisiones de prioridad tienen más probabilidades de incluirse en un bloque. La implementación actual del planificador utiliza 4 núcleos de ejecución; otros 2 núcleos están reservados para las transacciones de voto.

Cada hilo gestiona su propia cola y prioriza los paquetes de forma independiente, sin conocer los paquetes que procesan los demás hilos. Cada hilo recorre continuamente su cola de principio a fin e intenta bloquear y ejecutar transacciones. Cuando un hilo completa su ciclo actual, recopila más paquetes y vuelve a iniciar el ciclo.

Como resultado, un hilo podría estar procesando una transacción de alta prioridad situada al principio de su cola mientras otro hilo termina de procesar su propia cola con una transacción que involucra la misma cuenta.

Los detalles específicos de la implementación actual y futura del planificador se analizarán en otro artículo. Basta con entender que las comisiones de prioridad solo funcionan de forma intra-thread (dentro de su propio carril), no inter-thread (entre carriles), para comprender que el planificador está lejos de ser perfecto y presenta «fluctuaciones».

Comisiones en la práctica

Confirmación de transacciones

Aunque las comisiones influyen mucho en la confirmación de una transacción, no son el único factor determinante. Por ejemplo, una transacción podría no confirmarse simplemente por la pérdida de un paquete de red UDP. Durante periodos de alta actividad en la red, los validadores pueden recibir más transacciones de las que pueden gestionar. Aunque pueden reenviar el exceso de transacciones mediante el mecanismo tpu_forwards, solo pueden manejar un volumen limitado de datos. Además, cada transacción solo puede retransmitirse un número limitado de veces, hasta que venza el blockhash. La calidad de servicio ponderada por stake mitiga algunos de estos problemas para las direcciones con mayor stake, ya que les ofrece ancho de banda reservado y aumenta la probabilidad de que sus transacciones se incluyan.

También existen dos motivos menos conocidos por los que se descartan transacciones. El primero implica discrepancias dentro de un pool de RPC. Un segmento del pool de RPC puede adelantarse a los demás y generar problemas de coordinación. Por ejemplo, si el recentBlockhash de una transacción se obtiene de un segmento más actualizado y luego se envía a uno más lento, este último podría no reconocer el blockhash actualizado y descartar la transacción. Los desarrolladores pueden detectar estos problemas al momento del envío si tienen activadas las comprobaciones preliminares en la función sendTransaction.

Otro problema surge con las bifurcaciones temporales de la red. Si un validador se retrasa al procesar sus bloques, las transacciones podrían terminar en una bifurcación minoritaria que no llega a convertirse en canónica. Si un cliente referencia en su transacción un recentBlockhash que solo existe en esa bifurcación minoritaria y la red abandona la bifurcación antes de procesar la transacción, esta se descarta porque el blockhash ya no puede encontrarse.

Comisiones de prioridad

En la práctica, vemos pruebas de que las comisiones de prioridad funcionan a gran escala, aunque están lejos de ser perfectas. Las transacciones que incluyen comisiones de prioridad tienen más probabilidades de incluirse en bloques. Además, cuanto mayor sea la comisión de prioridad, mayor será la probabilidad de inclusión.

Según los datos de Helius RPC, las transacciones con comisiones de prioridad tienen más probabilidades de confirmarse y, cuando lo hacen, se confirman más rápido en todos los casos:

El 21 de enero, el promedio de las comisiones de prioridad aumentó considerablemente debido al airdrop de mockJUP, que servía como preparación para el airdrop real de JUP de la semana siguiente. Aunque la demanda de espacio de bloque cambió de forma significativa, los usuarios reales percibieron relativamente pocos cambios en la tasa y el tiempo de confirmación de las transacciones.

Esta UX se basa principalmente en el método RPC de Solana getRecentPrioritizationFees, que permite a los desarrolladores determinar con precisión la comisión de prioridad que deben agregar a una transacción. El endpoint devuelve una lista de las comisiones de prioridad de los últimos 150 bloques que se utilizaron para confirmar correctamente al menos una transacción con la dirección y los parámetros de entrada correspondientes. Esto ofrece una instantánea del valor mínimo necesario para establecer las comisiones de prioridad, pero su utilidad es relativamente limitada. Como alternativa, Helius ofrece una API de comisiones de prioridad que realiza cálculos adicionales para proporcionar una mejor estimación.

Aunque las comisiones de prioridad funcionan hasta cierto punto como se esperaba en la teoría, los próximos cambios del planificador en la versión 1.18 aumentarán el determinismo de la inclusión de transacciones. Esto debería reducir la cantidad de spam que llega on-chain, ya que la estrategia dominante dejará de requerir el envío masivo de transacciones para lograr su inclusión.

Comisión base

La comisión base de Solana es definitivamente demasiado baja. Los bloques se saturan y la comisión no es dinámica, lo que impide que alcance un precio de equilibrio de mercado para el espacio de bloque. En Ethereum, la comisión base dinámica se obtiene mediante el mecanismo de control de EIP-1559, que examina los bloques recientes y busca una tasa de utilización del 50 %.

Solana fija un precio estático de 5000 lamports por firma, normalmente una firma por transacción. Esto la convierte en una comisión ineficaz, ya que la comisión base no refleja ningún cambio en la demanda de espacio de bloque ni en el uso de los recursos de los validadores. En la práctica, esto traslada la comisión de prioridad a una alternativa basada en el mercado, lo que congestiona aún más la red porque los validadores procesan transacciones adicionales que probablemente nunca se incluirían. Además, la estrategia dominante consiste en enviar una gran cantidad de transacciones con comisiones de prioridad mínimas para lograr su inclusión. Esto genera importantes externalidades negativas en la UX de todos los participantes de la red.

Incentivos

Los RPC tienen incentivos para transmitir la información correcta a los siguientes participantes y ofrecer la mayor tasa de inclusión de transacciones con el menor costo posible. La integración con los validadores que tienen más stake permite que los RPC obtengan una visión más precisa del estado actual de la red, ya que muchos de los mecanismos de Solana están ponderados por stake. Surge así una relación simbiótica en la que los validadores con mucho stake y RPC integrados pueden mejorar la eficiencia y la fiabilidad del procesamiento de transacciones. Esto podría crear un ciclo de retroalimentación que consolide aún más la posición de los validadores con mayor stake.

Además, los RPC, que actualmente se tratan como validadores sin stake, también pasarán a ponderarse por stake. Los RPC pueden intentar atraer stake sin asociarse con un validador. No es raro que las propias aplicaciones ejecuten sus propios validadores para lograr una mayor integración vertical. Esto les permite tener más control sobre la experiencia del usuario final y la cadena de suministro de transacciones y MEV.

A pesar de que los incentivos económicos sugieren una tendencia hacia la centralización del stake, Solana no ha experimentado una concentración de capital a gran escala para obtener beneficios ponderados por stake. Esto podría deberse a varios motivos:

• Las personas pueden considerar que maximizar la descentralización a nivel local es la estrategia dominante para obtener beneficios a largo plazo para la red, impulsadas principalmente por la cultura y la capa social de Solana.
• Los participantes de Solana han sido, en gran medida, usuarios minoristas y prosumidores, y son menos sensibles a los rendimientos que las empresas profesionales. A medida que aumenten el nivel de actividad y los rendimientos absolutos, podrían surgir incentivos para cambiar la composición demográfica de los participantes y su sensibilidad a las tasas.
• Las personas no coordinan bien la promoción de sus productos diferenciados.

Conclusión

En este artículo, describimos en detalle la teoría general del mecanismo de comisiones de Solana y cómo afecta a la red on-chain. Las comisiones determinan los incentivos, que generan importantes externalidades y afectan el comportamiento de todos los participantes de Solana.

Los mecanismos de Solana, como la comisión base y la comisión de prioridad, no son perfectos en su implementación actual. La comisión base no puede ajustarse y no refleja el equilibrio actual entre la oferta y la demanda. Esto provoca problemas como la congestión de la red y una asignación ineficiente de los recursos. Las comisiones de prioridad presentan cierto grado de indeterminismo debido a la implementación actual del planificador. Las próximas actualizaciones, como los cambios previstos en el planificador, prometen aportar más determinismo y eficiencia al procesamiento de transacciones, lo que podría transformar el comportamiento on-chain que observamos hoy.

Se aproximan nuevas propuestas, como las comisiones exponenciales para cuentas con bloqueo de escritura, que buscan calcular con mayor precisión el costo de las transacciones cuando estas bloquean arbitrariamente el acceso a las cuentas. También se debate la creación de un mecanismo dinámico de comisión base que determine con mayor precisión el precio del acceso al estado.

La interacción entre las comisiones, los validadores y los RPC forma una compleja red de incentivos. En teoría, los validadores y los RPC tienen incentivos para integrarse y aumentar su ponderación por stake, lo que podría generar preocupaciones sobre la centralización. Sin embargo, en la práctica, Solana ha logrado mantener un conjunto descentralizado de operadores y stake. Esto probablemente se debe a su gobernanza impulsada por la comunidad, las barreras técnicas, los contraincentivos económicos y las funciones de optimización que actualmente no se rigen principalmente por los rendimientos.