La verdad sobre los mercados de comisiones locales de Solana

Hallazgos prácticos

• Los mercados de comisiones locales (LFM) permiten que Solana establezca comisiones granulares para elementos individuales del estado según su nivel de contención. Las transacciones pagan comisiones según el estado específico en el que escriben, lo que evita que los puntos de congestión localizados eleven las comisiones en toda la blockchain. 
• Los LFM son esenciales para hacer realidad la visión de Solana de una capa base unificada y escalable donde todas las aplicaciones coexistan sin fricciones. Sin los LFM, los picos de comisiones en una parte de la cadena aumentan las comisiones de todas las transacciones. Este problema es común en otras redes que dependen únicamente de mercados globales para fijar el precio del espacio de bloque.
• Cuando la actividad económica de Solana comenzó a acelerarse a finales de 2023, quedaron en evidencia varios defectos críticos de la implementación original de los LFM. El más notable era la priorización no determinista del planificador. Las transacciones se ordenaban principalmente según su hora de llegada al constructor de bloques, y las comisiones de prioridad eran solo un criterio secundario.
• La actualización v1.18 del cliente Agave, lanzada en mayo de 2024, introdujo un nuevo planificador de transacciones y una fórmula refinada para calcular la prioridad. El planificador crea un grafo de dependencias para gestionar mejor el procesamiento y la priorización de transacciones en conflicto entre distintos hilos. Esta importante actualización mejoró significativamente la capacidad del protocolo para ordenar las transacciones de forma determinista.
• Una métrica valiosa para evaluar el funcionamiento eficaz de los LFM es comparar la mediana y el promedio de las comisiones de prioridad de las transacciones. Se espera que las comisiones relacionadas con estados sin contención (la mediana del percentil 50) permanezcan bajas. Las comisiones de los estados con contención deberían dispararse al aumentar la demanda, elevando el promedio. Los datos recientes confirman este patrón. En noviembre de 2024, el promedio de las comisiones de las transacciones sin voto alcanzó un máximo histórico superior a 0.0003 SOL. Sin embargo, la mediana se mantuvo estable en 0.00000861 SOL, aproximadamente 35 veces más baja.
• Hoy, los LFM de Solana funcionan, pero todavía hay mucho por mejorar. Un análisis de las cargas de trabajo de los hilos de la etapa bancaria realizado por ingenieros de Anza indica que un error del planificador impide que el cliente del validador aproveche toda su capacidad. Como resultado, el cliente Agave opera solo a una fracción de su potencial. Además, no existe una especificación formal sobre cómo deben ordenarse las transacciones.
• Las API actuales de comisiones de prioridad no tienen la sofisticación necesaria para ofrecer resultados deterministas a los desarrolladores. Cada proveedor importante de RPC ofrece su propia API personalizada de comisiones de prioridad, lo que podría convertirse en una forma sutil de dependencia del proveedor. La implementación principal de código abierto de la API de RPC no considera dinámicas críticas de la red, como la influencia de Jito, lo que produce estimaciones de comisiones inexactas.
• Sin un método determinista para calcular las comisiones de prioridad, los desarrolladores suelen adoptar un enfoque cauteloso y pagar de más para garantizar que sus transacciones se procesen. Como alternativa, pueden usar en exceso las propinas de Jito, incluso en transacciones que no necesitan asegurar la primera posición del bloque.
• Se han propuesto varias estrategias para mejorar aún más la estructura de comisiones de Solana. Entre ellas se incluyen las comisiones exponenciales por bloqueos de escritura y las comisiones base dinámicas. La red aún debe encontrar formas de aplicar contrapresión económica para desincentivar el spam y mantener comisiones bajas para los usuarios humanos reales.

Introducción

Los mercados de comisiones son mecanismos económicos diseñados para asignar de forma eficiente el escaso espacio de bloque a las transacciones de mayor valor mediante el ajuste dinámico de las comisiones. La disposición de una transacción a pagar comisiones funciona como indicador de su valor. Los LFM refinan este concepto general al establecer comisiones granulares para elementos individuales del estado según su nivel de contención. Dos transacciones se consideran conflictivas cuando acceden al mismo estado, ya sea mediante dos escrituras o mediante una lectura y una escritura en la misma cuenta.

Con los LFM, las transacciones pagan comisiones según el estado específico en el que escriben, lo que evita que los puntos de congestión localizados eleven las comisiones en toda la blockchain. Las transacciones que acceden a estados con alta demanda o contención pagan comisiones más altas, mientras que las que interactúan con estados de menor demanda pagan menos. Esto es importante porque Solana gestiona mejor las transacciones sin contención gracias a la ejecución en paralelo.

En comparación, los mercados de comisiones globales aplican un costo universal para acceder al estado de la red. Esto significa que todas las transacciones compiten por igual para ser incluidas, sin importar con qué cuentas interactúen. El modelo de comisiones de Ethereum, implementado en EIP-1559, es un ejemplo relevante de mercado global de comisiones. EIP-1559 ajusta una comisión base dinámica según la demanda de la red para mantener un uso óptimo de cómputo (gas) por bloque. A medida que se llena la capacidad del bloque, aumentan las comisiones de todas las transacciones. Las wallets calculan las comisiones según la comisión base actual y el límite de gas de la transacción. Este enfoque se aplica en el protocolo y permite calcular las comisiones de forma predecible. Sin embargo, no logra aislar del resto de la red los puntos de alta demanda. Cuando las comisiones se disparan, lo hacen para todas las transacciones.

La alta demanda de elementos específicos del estado no es un problema exclusivo de las blockchains. Este desafío refleja el problema de las claves de alta demanda, conocido a menudo como el "problema de las celebridades", que suele presentarse en aplicaciones sociales Web2.

Con este artículo, buscamos ofrecer un análisis accesible de los LFM de Solana. El trabajo se divide en las siguientes secciones:

• Conceptos básicos de las comisiones de Solana: Brinda a los lectores una base para comprender cómo se procesan actualmente las transacciones en Solana.
• Problemas iniciales de los mercados de comisiones locales: Explora los problemas y las deficiencias de las primeras implementaciones de los LFM.
• Actualización v1.18 del planificador central: Destaca una actualización clave de 2024 que mejoró significativamente el funcionamiento de los LFM.
• Medición de la eficacia de los mercados de comisiones locales: Presenta datos relevantes para comprender el estado actual de los LFM en Solana.
• Problemas pendientes y áreas de mejora: Analiza los problemas sin resolver y las áreas que requieren atención para que los LFM alcancen todo su potencial.
• Soluciones propuestas: Revisa las soluciones propuestas para perfeccionar los LFM e introducir mejores incentivos económicos que permitan fijar precios más matizados para el espacio de bloque.

Si ya conoces las estructuras de comisiones de las transacciones de Solana, puedes omitir la siguiente sección sobre los conceptos básicos.

Conceptos básicos de las comisiones de Solana

Las transacciones de Solana incluyen dos comisiones: la comisión base y la comisión de prioridad. Actualmente, la comisión base está fijada en 5,000 lamports por firma. La mayoría de las transacciones de Solana tienen una sola firma. La comisión de prioridad se expresa en microlamports (es decir, una millonésima parte de un lamport) por unidad de cómputo (CU) solicitada. Las comisiones se debitan de la cuenta que las paga (el firmante). La transacción se descarta si quien paga no tiene suficientes lamports para cubrirla. Al momento de escribir este artículo, el constructor del bloque conserva el 50% tanto de la comisión base como de la comisión de prioridad como incentivo para incluir la transacción en el bloque. El otro 50% se quema. Tras la aprobación de la propuesta SIMD-096 en mayo del año pasado, esto cambiará para que el constructor del bloque conserve el 100% de las comisiones de prioridad. Por ejemplo: 

Una transacción tiene una firma y solicita 500,000 CU. El remitente establece una comisión de prioridad de 50,000 microlamports por CU solicitada. La comisión total de la transacción es de 5,000 lamports + (500,000 CU solicitadas * 50,000 microlamports por CU solicitada) = 25,000 lamports, o 0.000025 SOL.

Los validadores tienen recursos computacionales limitados, y el protocolo limita a 48 millones de CU los recursos computacionales totales por bloque. Esta cifra se eligió de forma empírica según la cantidad que los validadores pueden procesar razonablemente para alcanzar tiempos de bloque de 400 milisegundos. El máximo de CU por cuenta y por bloque está limitado a 12 millones, y el cómputo máximo por transacción se fija en 1.4 millones de CU. Los mensajes de transacción también tienen un tamaño máximo de 1,232 bytes, que corresponde a la unidad mínima de transmisión de IPv6 (1280 bytes) menos los encabezados.

Para evitar el uso indebido de los recursos computacionales, cada transacción de Solana recibe un presupuesto de cómputo. De forma predeterminada, la red establece un límite máximo de 200,000 unidades de cómputo (CU) por instrucción. Sin embargo, las transacciones pueden especificar un límite personalizado de unidades de cómputo mediante una instrucción `SetComputeUnitLimit`, lo que permite asignar los recursos con mayor eficiencia. El código base del cliente Agave enumera los costos en CU de varias operaciones.

Solana exige que todas las transacciones especifiquen una lista completa de las direcciones de cuentas que se leerán o escribirán durante la transacción. El tamaño máximo de esta lista es de 35 direcciones y puede ampliarse mediante tablas de búsqueda de direcciones on-chain. Crear listas de direcciones genera trabajo adicional para los desarrolladores, pero es clave para habilitar muchas de las optimizaciones de Solana, como la ejecución de transacciones en paralelo y los mercados de comisiones locales.

Problemas iniciales de los mercados de comisiones locales de Solana

Cuando la actividad económica de Solana comenzó a acelerarse a finales de 2023, quedaron en evidencia varios defectos críticos de la implementación original de los LFM. Por esa época, Eugene Chen, de Ellipsis Labs, presentó un análisis completo de estos desafíos en el artículo de Umbra Research, Comisiones de Solana, Parte 1. A continuación se resumen los puntos principales planteados por Chen.

Falta de incentivos para solicitar CU con precisión

La estructura de comisiones de Solana cobra comisiones base por firma sin considerar las unidades de cómputo (CU) utilizadas o solicitadas. A su vez, las comisiones de prioridad ofrecen solo un incentivo limitado para reducir el uso de CU durante periodos de congestión. Este diseño da a los remitentes pocos motivos para optimizar el uso de cómputo o ajustar sus solicitudes de CU a sus necesidades reales. Por eso, las transacciones suelen solicitar CU en exceso, lo que genera ineficiencias en el proceso de planificación de la red.

Incentivos para usar mecanismos de prioridad externos al protocolo

Quemar el 50% de las comisiones de prioridad incentiva a los remitentes a eludir el protocolo mediante acuerdos con los constructores de bloques y pagos off-chain para obtener acceso prioritario. Este comportamiento es evidente en el creciente uso de las subastas de Jito. Los validadores que ejecutan el cliente Jito-Agave obtienen mayores ingresos por comisiones y pueden distribuir estas ganancias de forma eficiente entre los participantes delegados mediante recompensas de comisión de Jito MEV. A medida que ha crecido la adopción de los clientes Jito-Agave, los bundles de Jito han demostrado ser un servicio superior de entrega de transacciones en muchos escenarios. 

Priorización no determinista del planificador

Ni el consenso de Solana ni el planificador imponen un orden estricto de las transacciones según las comisiones de prioridad. Las transacciones se ordenan principalmente por su hora de llegada al constructor de bloques, y las comisiones de prioridad son solo un criterio secundario. Las comisiones de prioridad más altas pueden aumentar la probabilidad de inclusión cuando existen estados con contención, pero el proceso de ordenamiento sigue siendo no determinista. Las variaciones de la red antes de llegar a la unidad de procesamiento de transacciones (TPU) y las variaciones internas del planificador añaden más imprevisibilidad.

Esta falta de determinismo reduce la previsibilidad y la confiabilidad de la ejecución de transacciones, lo que lleva a los usuarios a inundar la red con spam de transacciones para aumentar sus posibilidades de inclusión rápida. Sin embargo, elevar las comisiones de prioridad produce rendimientos decrecientes después de cierto umbral, lo que reduce su eficacia como mecanismo para obtener una mejor posición. El espacio de bloque compartido de Solana terminó siendo víctima de una clásica "tragedia de los comunes". Los actores individuales, al perseguir sus propios intereses, contribuyeron al uso excesivo y a la ineficiencia de este recurso público.

Actualización v1.18 del planificador central

La implementación inicial del planificador del cliente Agave solo ofrecía una garantía imprecisa de que las transacciones con comisiones de prioridad altas tendrían mayores posibilidades de entrar en un bloque determinado. La unidad de procesamiento de transacciones (TPU) del líder opera con seis hilos paralelos: cuatro procesan transacciones sin voto y dos están reservados para transacciones de voto. Cada uno de los cuatro hilos de transacciones sin voto mantiene su propia cola, donde las transacciones entrantes esperan a agruparse en entradas para su ejecución. Antes, las transacciones se asignaban aleatoriamente a estos hilos y las colas priorizaban los paquetes de manera independiente, sin saber qué paquetes procesaban los otros hilos.

Dentro de este sistema, cada hilo recorre su cola e intenta bloquear y ejecutar transacciones. Cuando un hilo completa su ciclo actual, recopila paquetes adicionales y vuelve a iniciar el proceso. Esta estructura dificulta el uso eficaz de las comisiones de prioridad. Por ejemplo, aunque una transacción de alta prioridad estuviera al principio de la cola de un hilo, otro hilo podría procesar al mismo tiempo una transacción con una comisión de prioridad menor que involucre la misma cuenta y esté al final de su cola. Las comisiones de prioridad solo influían en el orden de las transacciones dentro de cada hilo, no entre todos los hilos. Como resultado, cada cola aplicaba un mecanismo híbrido de ordenamiento que combinaba el procesamiento por orden de llegada (FIFO) con las comisiones de prioridad. Sin embargo, no se imponía un orden global entre los hilos.

Cuando un hilo se prepara para ejecutar una transacción, primero debe obtener los bloqueos de cuenta necesarios. Si los bloqueos de escritura requeridos no están disponibles, la transacción vuelve a la cola. La asignación aleatoria de transacciones a los hilos agrava este problema, ya que un mismo tipo de transacción puede ocupar distintas posiciones dentro del sistema de planificación multihilo. Esta naturaleza estocástica del planificador introduce variaciones que cambian la posición que una transacción puede ocupar dentro de un bloque.

La actualización v1.18 del cliente Agave, lanzada en mayo de 2024, incorporó un nuevo planificador de transacciones, también conocido como planificador central. En esta estructura revisada, el planificador central crea un grafo de dependencias denominado prio-graph para gestionar mejor el procesamiento y la priorización de transacciones en conflicto entre todos los hilos. Esta importante actualización mejoró significativamente la capacidad de Solana para ordenar transacciones de forma determinista. Ahora, las transacciones con comisiones de prioridad más altas tienen más probabilidades de incluirse en los bloques.

El prio-graph es un grafo acíclico dirigido (DAG) que se actualiza dinámicamente a medida que se añaden nuevas transacciones. Las transacciones se organizan dentro del grafo para formar cadenas de ejecución que se procesan por orden temporal y de prioridad. En las transacciones en conflicto, la comisión de prioridad determina el orden de inserción. Este enfoque minimiza la contención de bloqueos, permite ejecutar lotes de transacciones con fluidez y reduce los retrasos provocados por conflictos de recursos. La verificación de precompilación de las transacciones se trasladó a hilos de trabajo para mejorar el rendimiento y permitir un procesamiento más eficiente. 

El diseño actualizado del planificador mejora significativamente la escalabilidad y la flexibilidad, lo que permite aumentar potencialmente la cantidad de hilos sin elevar el riesgo de conflictos de bloqueo. Además, el enfoque de planificación centralizada mejoró la generación de recompensas y aumentó los ingresos de muchos operadores de validadores.

Para ver un análisis más detallado del planificador central, consulta nuestra publicación anterior del blog de Helius sobre la actualización Agave 1.18.

Cálculo de prioridad más eficaz

Junto con la actualización del planificador, se refinó la fórmula de prioridad de las transacciones para favorecer a aquellas con menores requisitos de cómputo. Esto beneficia a los desarrolladores y a las transacciones que consumen pocos recursos. 

La fórmula revisada es:

Prioridad = (Comisión de prioridad * Unidades de cómputo solicitadas) + Comisión base / 

(1 + CU de ejecución solicitadas + CU de firmas + CU de bloqueos de escritura)

Este nuevo cálculo considera todos los costos de cómputo y operación vinculados a una transacción, lo que garantiza que los niveles de prioridad representen con precisión el consumo real de recursos. Por eso, las transferencias simples de tokens o las transacciones nativas de SOL sin comisiones de prioridad adicionales tienen garantizado un nivel mínimo de prioridad dentro de la cola. En las transacciones más complejas, los desarrolladores que no especifican un límite personalizado de CU mediante la instrucción `SetComputeUnitLimit` quedan en desventaja frente a quienes sí lo hacen al priorizar sus transacciones.

Medición de la eficacia de los mercados de comisiones locales

Esta sección examina datos relevantes sobre los LFM de Solana. 

Mediana frente al promedio de las comisiones de transacción

Cuando los LFM funcionan de forma eficaz, se espera que las comisiones de las transacciones relacionadas con estados sin contención, como las transferencias simples de stablecoins, permanezcan bajas. Mientras tanto, las comisiones de las transacciones que acceden a estados con contención, como tokens especulativos de baja liquidez, deberían dispararse junto con la demanda. Una métrica valiosa para evaluar esta dinámica es comparar la mediana y el promedio de las comisiones de prioridad. La mediana de las comisiones representa la comisión que paga el usuario del percentil 50 y refleja los costos habituales. El promedio de las comisiones considera todas las comisiones divididas entre el número total de transacciones y destaca las tendencias generales.

Los datos recientes confirman este patrón esperado. Noviembre de 2024 marcó el nivel más alto de actividad económica de Solana hasta la fecha, y el promedio de las comisiones de las transacciones sin voto alcanzó un máximo histórico superior a 0.0003 SOL. A pesar de esto, la mediana se mantuvo estable en 0.00000861 SOL, aproximadamente 35 veces más baja. Esto contrasta con abril de 2024, cuando un aumento similar de la actividad económica elevó el promedio por encima de 0.0002 SOL y la mediana aumentó en paralelo hasta 0.00001862 SOL, una cifra aproximadamente 10 veces menor. Esta divergencia demuestra que el aislamiento de comisiones protege a los usuarios habituales frente a los picos de costos durante periodos de alta demanda y preserva la experiencia de usuario en casos de uso no impulsados por la especulación.

Al analizar datos similares de una red basada en EVM, como Base, la L2 de Ethereum operada por Coinbase que carece de LFM, observamos una fuerte correlación entre la mediana y el promedio de las comisiones de transacción. Ambos valores se mueven de forma relativamente sincronizada debido al aumento de las comisiones base globales cuando crece la demanda. Además, la diferencia entre ambos es mucho menor. Por ejemplo, el 5 de diciembre de 2024, el promedio de las comisiones de transacción en Base se disparó a $0.1115, mientras que la mediana también aumentó hasta $0.0228, una cifra aproximadamente cinco veces menor.

Tasas de transacciones revertidas

Otra tendencia útil para examinar es la tasa de transacciones revertidas. Durante los periodos de alta actividad económica de abril y mayo de 2024, los usuarios de Solana informaron ampliamente de un deterioro de la experiencia de usuario mientras la cadena soportaba una gran cantidad de spam. La falta de determinismo redujo la previsibilidad y la confiabilidad de la ejecución, lo que llevó a los usuarios a inundar la red con spam de transacciones para aumentar sus posibilidades de inclusión rápida. 

Los buscadores suelen enviar transacciones para realizar operaciones oportunistas sin considerar la probabilidad de éxito. Las transacciones de arbitraje con comisiones de prioridad inadecuadamente bajas siguen siendo válidas. El protocolo las procesa después de otras transacciones con comisiones de prioridad más altas, y es probable que se reviertan debido a la lógica de deslizamiento. 

Las transacciones revertidas alcanzaron su máximo en abril de 2024 y representaron el 75.7% de todas las transacciones sin voto. Este porcentaje cayó significativamente tras el lanzamiento de actualizaciones clave, incluido el planificador central de Agave 1.18.

Un análisis de cohortes de Blockworks Research que cubre los últimos siete días (del 6 al 13 de enero de 2024) muestra distintas tasas de reversión según el nivel de actividad. Las direcciones que realizan entre 1 y 5 transacciones diarias, principalmente usuarios minoristas, registran una tasa de reversión del 1.4%. Esta aumenta al 4.6% para las que realizan entre 6 y 50 transacciones al día. En particular, las direcciones que ejecutan más de 10,000 transacciones diarias alcanzan tasas de reversión del 66.7%. Además, las direcciones con más de 100,000 transacciones diarias, es decir, bots, son responsables del 95.2% de todas las transacciones revertidas. En diciembre de 2024, la tasa general de reversión de todas las transacciones sin voto fue del 41.2%. Esto indica que una gran parte de los recursos de cómputo de la red se consume procesando arbitrajes fallidos.

Problemas pendientes y áreas de mejora

A pesar de los avances significativos, el planificador del cliente validador Agave sigue afrontando desafíos. El siguiente análisis de las cargas de trabajo de los hilos de la etapa bancaria, realizado por el ingeniero de Anza Alessandro Decina, destaca las ineficiencias existentes y las áreas de mejora.

Hilo del planificador: Es el hilo más importante para producir bloques. El planificador recibe todas las transacciones entrantes y luego las ordena y programa para su ejecución. 

Hilos de transacciones de voto: Dos hilos dedicados gestionan las transacciones de voto y garantizan que se procesen por separado de las transacciones de los usuarios.

Hilos de transacciones sin voto: Cuatro hilos reciben las transacciones según lo programado por el planificador y procesan las transacciones de los usuarios.

Hilos de ingesta QUIC: Los hilos de Tokio gestionan la ingesta de transacciones mediante el protocolo QUIC cuando el validador es el líder. Durante el periodo de congestión de principios de 2024, estos hilos fueron un cuello de botella importante.

La visualización anterior muestra que, aunque todos los hilos de trabajo ejecutan transacciones en paralelo al inicio del primer bloque del líder, este paralelismo se degrada rápidamente hasta convertirse en ejecución secuencial. En concreto, solo un hilo de transacciones sin voto, el hilo tres, continúa procesando transacciones, mientras los demás permanecen inactivos.

Este comportamiento sugiere que un error del planificador impide que el cliente del validador aproveche toda su capacidad. Como resultado, el sistema opera solo a una fracción de su potencial. Si se resolviera el problema, el validador podría procesar hasta cuatro veces la carga actual.

Observabilidad

Las API actuales de comisiones para estimar el aterrizaje predecible de transacciones no tienen la sofisticación necesaria para ofrecer resultados deterministas. Cada proveedor importante de RPC ofrece su propia API personalizada de comisiones de prioridad, mientras que la implementación principal de código abierto de la API de RPC sigue sin ser óptima. No considera dinámicas críticas de la red, como la influencia de Jito, lo que genera estimaciones de comisiones menos precisas. 

Helius ofrece el método RPC `getPriorityFeeEstimate`, que recomienda comisiones a partir de datos históricos de los mercados globales y los LFM. Los desarrolladores pueden introducir una transacción serializada y firmada o una lista de claves de las cuentas involucradas. El método admite niveles personalizados de comisiones de prioridad, clasificados en seis percentiles: mínimo, bajo, medio, alto, muy alto y máximo no seguro. El nivel medio (percentil 50) es la recomendación predeterminada. Las comisiones se calculan con datos de los 50 slots más recientes.

{
 "jsonrpc": "2.0",
 "id": "helius-example",
 "method": "getPriorityFeeEstimate",
 "params": [
   {
     "transaction": "LxzhDW7T...", // Base58 encoded serialized transaction
     "options": {
       "recommended": true
     }
   }
 ]
}

Arriba: Ejemplo de payload para getPriorityFeeEstimate con una transacción serializada codificada en base58.

Sin un método determinista para calcular las comisiones de prioridad, los desarrolladores suelen adoptar un enfoque cauteloso y pagar de más para garantizar que sus transacciones se procesen. Como alternativa, pueden usar en exceso las propinas de Jito, incluso en transacciones que no necesitan asegurar la primera posición del bloque. Estas propinas suelen sustituir a las comisiones de prioridad. Cabe destacar que la mayoría de las propinas observadas en 2024 no están vinculadas a actividades tradicionales de MEV, como el arbitraje o los ataques sándwich, sino que buscan acelerar la inclusión de transacciones. Los validadores se benefician de esta ineficiencia al cobrar mayores recompensas de bloque y comisiones de MEV.

Otro desafío surge cuando los desarrolladores no implementan una lógica para ajustar dinámicamente sus comisiones de prioridad en respuesta a las condiciones cambiantes on-chain. Durante eventos importantes, como movimientos significativos del mercado, las comisiones por acceder a cuentas de estado específicas pueden dispararse. Las aplicaciones que carecen de mecanismos dinámicos de comisiones tendrán dificultades en estos escenarios, ya que su configuración estática no basta para garantizar una ejecución oportuna.

Soluciones propuestas

Se han propuesto varias estrategias para seguir mejorando la estructura de comisiones de Solana. Estas propuestas buscan optimizar la asignación de recursos de la red y reducir los incentivos para enviar spam.

Comisiones exponenciales por bloqueos de escritura

Propuesta en enero de 2023 por Tao Zhu (Anza) y Anatoly Yakavenko, SIMD-0110 plantea un mecanismo novedoso para gestionar la congestión mediante comisiones dinámicas sobre las cuentas con contención. Este mecanismo registra la media móvil exponencial (EMA) del uso de unidades de cómputo (CU) en las cuentas con bloqueo de escritura y aumenta el costo de bloquear para escritura las cuentas que mantienen un uso elevado.

Para implementar este sistema, el runtime de Solana mantiene una caché LRU (menos usada recientemente) de las claves públicas de las cuentas con contención y sus correspondientes fijadores de precios de unidades de cómputo (CUP). Los CUP supervisan el uso de CU de la EMA de una cuenta y proporcionan una tarifa actualizada cuando se consultan.

El mecanismo ajusta dinámicamente las comisiones por bloqueos de escritura. La tarifa de bloqueo de escritura aumenta si el uso de CU de la EMA de una cuenta supera un umbral objetivo. Por el contrario, si el uso cae por debajo del objetivo, la tarifa disminuye. Los parámetros iniciales incluyen:

• Un uso objetivo del 25% del límite máximo de CU de la cuenta.
• Una tarifa inicial de bloqueo de escritura de 1,000 microlamports por CU.
• Una tasa de ajuste del costo del 1% por bloque.

La comisión por bloqueo de escritura de una cuenta se calcula multiplicando su tarifa por las CU solicitadas por la transacción. En este sistema, las comisiones totales de la transacción son la suma de tres componentes: la comisión base por firma, la comisión de prioridad y la comisión por bloqueo de escritura. El 100% de las comisiones por bloqueos de escritura se quema.

Cuando se publicó, SIMD-0110 generó un intenso debate en la comunidad. Sin embargo, la propuesta está inactiva y desde entonces se marcó como cerrada.

Comisiones base dinámicas

Otra solución a más largo plazo para mejorar los LFM de Solana sería introducir comisiones base dinámicas (DBF) globales y por cuenta. Jarry Xiao y Eugene Chen, de Ellipsis Labs, son defensores destacados de este enfoque.

Aunque las comisiones de prioridad son opcionales, las comisiones base son obligatorias. Actualmente, la comisión base de Solana está fijada en 5000 lamports por firma. Los usuarios que envían transferencias simples de tokens pagan la misma comisión base que quienes realizan swaps complejos en varias plataformas o que los buscadores que intentan ejecutar arbitrajes de MEV complicados. Las comisiones base no reflejan con precisión el uso de cómputo de una transacción.

Con comisiones base dinámicas, una transacción de arbitraje con comisiones base inadecuadas puede considerarse inválida y descartarse antes de llegar al planificador. Aumentar las comisiones base incentiva a los spammers a enviar menos transacciones.

Las comisiones base terminarán alcanzando un equilibrio, y el precio de las transacciones se basará en el valor del mercado de espacio de bloque. Como la comisión base aumenta, acabará alcanzando un costo marginal en el que enviar la transacción ya no compensará el costo de oportunidad de la operación. Las comisiones no pueden subir demasiado porque afectarían la actividad de los usuarios. Lo ideal es un máximo demasiado alto para los bots, pero aceptable en general para los usuarios. En este sistema, las cuentas que envíen spam de transacciones para lograr su inclusión quemarán todo su SOL.

Los rápidos tiempos de bloque de Solana permiten usar algoritmos agresivos para establecer las comisiones base. Durante periodos de alta demanda, las comisiones pueden ajustarse rápidamente, incluso duplicarse con cada bloque, para reflejar la congestión de la red. Por el contrario, cuando disminuye la demanda, las comisiones pueden reducirse de forma más gradual. Gracias a los breves tiempos de bloque de Solana, estas reducciones siguen ocurriendo con relativa rapidez, lo que permite que la red se adapte pronto a los cambios.

Un ejemplo de una forma similar de contrapresión económica es el programa Metaplex Candy Machine, que en 2022 introdujo un impuesto para bots como mecanismo contra el spam. Este impuesto es un cargo opcional para las transacciones inválidas. Normalmente sería una cantidad razonablemente pequeña para evitar afectar a los usuarios reales que cometieron un error genuino. El impuesto demostró ser eficaz: los bots dedicados a adelantarse en los mints agotaron rápidamente sus fondos y el spam se detuvo.

Conclusión

Los LFM de Solana funcionan, pero todavía hay mucho por mejorar:

• Mejorar los mecanismos de comisiones de prioridad: Las llamadas RPC para las comisiones de prioridad deben mejorar. Lo ideal es que los desarrolladores tengan una forma sencilla y determinista de establecer comisiones que garanticen la inclusión de la transacción en alguno de los siguientes bloques.
• Desincentivar económicamente el spam: La red debe encontrar formas de aplicar contrapresión económica contra los bots durante periodos de alta actividad económica y, al mismo tiempo, mantener comisiones bajas para los usuarios humanos reales.
• Educar a los desarrolladores: Los desarrolladores deben dejar de establecer comisiones de transacción estáticas en sus aplicaciones y depender menos de mecanismos externos al protocolo, como Jito, para las transacciones rutinarias.
• Seguir optimizando el planificador: El planificador de transacciones necesita más optimizaciones para garantizar que todos los hilos de trabajo se utilicen durante periodos de alta demanda.

Como señala Anatoly Yakovenko, cofundador de Solana, estos desafíos son principalmente “solo problemas de ingeniería” y pueden resolverse con el enfoque técnico adecuado.

Recursos adicionales

• Comisiones de Solana, Parte 1 - Umbra Research
• Hacia unas comisiones multidimensionales en Solana - Umbra Research
• Los mercados de comisiones locales son necesarios para escalar Ethereum - Eclipse Labs
• Los mercados de comisiones locales de Solana no son reales | Eugene Chen - Lightspeed Podcast
• Etapa bancaria y planificador de Solana - A.Fitzgerald