Reenviar el título original:Mecanismos de tarifas de transacción de Solana y Ethereum: propuestas para mejorar el TFM de Solana

Gracias a Andrew Fitzgerald, Harsh Patel, Jon Charbonneau, Kevin Galler, Lanre Ige, Mert Mumtaz, Pranav Garimidi, Ryan Chern, Tao Zhu y Tarun Chitra por sus comentarios y reseñas.

Introducción

Eclipse es la primera SVM L2 de Ethereum. Estamos increíblemente emocionados de llevar el poder de la SVM existente a más usuarios, pero también estamos dedicados a impulsar la investigación y el desarrollo continuos en torno a la SVM en sí. Estamos enfocados en garantizar que el desarrollo de Eclipse devuelva valor innegablemente a todas las cadenas de SVM, especialmente a Solana.

Como precursor de futuros artículos sobre nuestro pensamiento en torno a los mercados de comisiones, este artículo analizará el mercado de comisiones existente de Solana y las propuestas asociadas para mejorarlo. Enmarcamos estas propuestas junto con los objetivos teóricos principales para cualquier Mecanismo de Tarifas de Transacción (TFM), tomando prestado en gran medida el trabajo de Tim Roughgarden, Maryam Bahrani, Pranav Garimidi, Hao Chung, Elaine Shi y otros. Indicaremos las definiciones básicas con **.

En general, un TFM determina:

1. Qué transacciones se incluyen en un bloque determinado,
2. Las comisiones que paga una transacción determinada, y
3. Cómo (y a quién) se distribuyen las tarifas de transacción acumuladas.

En última instancia, este artículo tiene como objetivo combinar la riqueza de la investigación TFM centrada en Ethereum con la ingeniería innovadora de Solana.

Descripción general de los TFM actuales de Solana y Ethereum

Conceptos básicos de Solana vs. Ethereum

Comenzaremos con una descripción general del TFM de Solana y lo contrastaremos con el de Ethereum. De este modo, se contextualizarán mejor las propuestas relevantes para que podamos trabajar en la modificación y mejora del TFM. Para empezar:

La tarifa base de Solana es de 5.000 lamports (0,000005 SOL) por firma, y la mayoría de las transacciones tienen una firma. No tiene en cuenta los recursos computacionales más amplios de una transacción (medidos por CU).

Tarifa base de Solana Tx = (5,000 Lamports) x (# de firmas en Tx)

El mecanismo de tarifas base de Ethereum difiere en dos aspectos principales:

1. Dinámico: la tarifa base de Ethereum (medida por gwei por unidad de gas) flota en función de la demanda del mercado posterior.
2. Cargo más granular por unidad de cómputo: la tarifa base por transacción de Ethereum es lineal en la cantidad de gas consumido.

Por lo tanto, la tarifa base por transacción de Ethereum es:

Tarifa base de Ethereum Tx = (Precio del gas prevaleciente en gwei) x (gas utilizado en tx)

Los usuarios de Solana también pueden agregar tarifas prioritarias opcionales para mejorar su probabilidad de inclusión. A diferencia de la tarifa base, la tarifa de prioridad tiene un precio por CU solicitada para una transacción. Las transacciones de Solana pueden incluir las siguientes instrucciones de cálculo del presupuesto :

1. SetComputeUnitLimit: las transacciones pueden establecer una cantidad máxima de CU que pueden consumir (con un máximo de 1,4 millones de CU por transacción). Cuando se ejecuta, la transacción puede usar hasta ese límite de CU solicitado. Si no se proporciona ninguna instrucción SetComputeUnitLimit, el límite de CU de la transacción se calcula como (# de instrucciones en la transacción) x (200k CU).
2. SetComputeUnitPrice: # de micro-lamports por CU solicitada que la transacción ofrece pagar en su tarifa de prioridad.

Poniéndolos juntos:

Tarifa de prioridad de Tx = (Límite de Tx CU) x (Precio de CU)

Tenga en cuenta que esta tarifa de prioridad se paga contra las CU completas solicitadas (independientemente de si la transacción utiliza la cantidad total solicitada), a diferencia de Ethereum, donde la tarifa es una función de la cantidad de gas que realmente usa la transacción.

Quema de tarifas vs. recompensas de validador

Si bien el incentivo para que los validadores prioricen las transacciones de tarifas altas se encuentra fuera del consenso, se aplica en consenso que tanto la tarifa base como la tarifa de prioridad se queman / envían al 50/50 al líder (productor de bloques actual) en Solana:

1. Tarifa base: obligatoria para la inclusión en bloque. Las transacciones que carezcan de la tarifa base requerida serán rechazadas.
2. Tarifa de prioridad: no es obligatoria para la inclusión en bloque. Se utiliza para priorizar opcionalmente las transacciones que desean aumentar su probabilidad de inclusión rápida.

Un usuario no puede evitar pagar la tarifa base, pero puede evitar la tarifa de prioridad y señalar su deseo de ser priorizado de otra manera. Ya lo vemos en la práctica: las subastas de Jito-Solana pagan el 100% (menos una comisión) al líder fuera de banda. SIMD-0096 ofrece una solución simple a este problema, recompensando con el 100% de la tarifa de prioridad al validador.

Transferencia directa*: Coordinada a través de subastas MEV-Boost / Jito-Solana

Es importante destacar que los validadores de Solana emiten votos por cada bloque con transacciones en cadena. Pagan la tarifa base por cada una de estas transacciones.

Solana ha estado generando últimamente sus máximos históricos para las tarifas de red, impulsadas por un fuerte aumento en las tarifas prioritarias. A continuación se muestran las divisiones de tarifas recientes:

Fuente: Solana Compass

Ethereum Block Builder vs. Solana Scheduler

La producción de bloques de Ethereum es generalmente más fácil de entender, así que empezaremos por ahí. Casi todos los validadores (también conocidos como proponentes subcontratan la producción de bloques a constructores fuera de protocolo a través de MEV-Boost. Los constructores crean bloques cada 12 segundos (el tiempo de ranura de Ethereum) y pasan estos bloques completos al proponente (a través de un relevo), quien selecciona el bloque de mayor valor.

Tanto en Ethereum como en Solana, los productores de bloques tienen el poder de ordenar transacciones arbitrariamente dentro de un bloque. Se les incentiva a hacerlo de una manera que maximice sus ganancias. Por ejemplo, diferentes constructores de Ethereum pueden competir ejecutando algoritmos patentados que maximizan las ganancias de manera más efectiva frente a los competidores.

Esto significa que incluso en Ethereum, el envío de una tarifa de alta prioridad no logra ninguna garantía determinista en el protocolo de inclusión u orden de bloques. Sin embargo, es muy probable que logre el resultado esperado debido a la naturaleza del proceso actual de construcción de bloques de Ethereum, en el que el constructor construye un bloque completo que maximiza las ganancias al final de cada ranura discreta.

Por ejemplo, un buscador puede enviar una transacción de arbitraje con una tarifa de prioridad increíblemente alta (por ejemplo, más alta que todas las demás transacciones elegibles combinadas) al creador, solicitando su inclusión en la parte superior del bloque y excluir la transacción del bloque por completo si no obtiene la posición superior del bloque. En este caso, un constructor racional que maximice las ganancias incluirá esta transacción en la parte superior del bloque, incluso si solo la recibió justo hacia el final de su espacio de 12 segundos.

Notarás que hay dos garantías diferentes que las tarifas están tratando de lograr aquí:

1. Inclusión: un usuario quiere que su transacción se incluya en este bloque, pero no le importa dónde se encuentra en el bloque.
2. Ordenamiento: un usuario no solo quiere ser incluido en el bloque en cualquier lugar; Quieren acceso prioritario a un estado específico en un momento dado.

El mecanismo EIP-1559 de Ethereum ha demostrado ser bastante eficaz para permitir a los usuarios pujar fácilmente por la inclusión en bloque con una alta probabilidad de éxito. Hay un precio de reserva global que todo el mundo sabe que hay que pagar, y pagarlo (normalmente junto con una comisión de prioridad nominal) debería incluir de forma fiable la transacción de un usuario con prontitud. Sin embargo, el mecanismo no busca proporcionar ninguna garantía en torno a los pedidos (es decir, el acceso prioritario al estado), mientras que los mecanismos fuera del protocolo son confiables para los usuarios que buscan tales garantías (directamente de los constructores, por ejemplo).

El proceso de construcción de bloques de Solana funciona de manera muy diferente. Los validadores no subcontratan la producción de bloques completos en franjas horarias discretas a constructores fuera de protocolo. El "programador" es el algoritmo predeterminado incluido en el cliente validador de Solana Labs, que programa las transacciones para su ejecución y construye bloques continuamente.

Además, las transacciones de Solana especifican qué cuentas deben estar bloqueadas por lectura y escritura para su ejecución. Esto permite que el programador ordene de forma iterativa qué transacciones se pueden ejecutar simultáneamente, ya que las transacciones que no tocan el mismo estado se pueden ejecutar en paralelo.

Dentro de un bloque, se puede usar un máximo de 12 000 000 de CU para escrituras secuenciales en una sola cuenta ("parte del estado"). Esta es aproximadamente la cantidad de CU que puede procesar un solo subproceso por ranura de 400 ms en requisitos de nodo razonables. El límite por bloque de Solana es entonces de 48.000.000 de CU. La implementación actual del programador utiliza cuatro subprocesos para las transacciones que no son de votación, y 12M x 4 = 48M. En teoría, esto significa usar más núcleos = aumentar los límites de CU. Escalado con hardware.

El programador prioriza de forma no determinista las transacciones con tarifas de mayor prioridad. Sin embargo, esto generalmente proporciona garantías de priorización menos confiables que mecanismos como los descritos en el caso de Ethereum en la actualidad.

En Solana, los validadores que ejecutan el programador predeterminado construyen bloques continuamente, por lo que las transacciones pueden agregarse a un bloque en curso y ejecutarse antes de esperar hasta el final de la ranura para organizarlas únicamente por tarifa de prioridad. La intención es que el programador maximice los beneficios priorizando las transacciones en función de su precio total de CU.

El programador multihilo predeterminado de Solana también introduce una "fluctuación" adicional. Las transacciones se asignan aleatoriamente a uno de los cuatro subprocesos, y cada subproceso mantiene su propia cola de transacciones en espera de ejecución. A continuación, las comisiones de prioridad se utilizan para priorizar las transacciones dentro del subproceso. Sin embargo, no ayudan a priorizar las transacciones entre subprocesos.

Por ejemplo, dos buscadores pueden enviar una transacción simultáneamente para capturar la misma oportunidad de arbitraje, y el que envía una tarifa de menor prioridad puede incluso ganar porque aterriza en una cola menos obstruida por casualidad. Esto reduce la eficacia de las tarifas de prioridad y aumenta el incentivo para el spam en relación con Ethereum, especialmente porque la inclusión de las transacciones también depende de cuándo, dentro de un espacio determinado, una transacción llega al productor de bloques actual.

Tenga en cuenta que hay cambios planificados en el programador predeterminado de Solana, que tienen como objetivo abordar algunos de los problemas con la implementación actual confiando en un gráfico de dependencias de transacciones y programando las transacciones desbloqueadas (no bloqueadas por escritura) de mayor prioridad en el gráfico, lo que cubrimos más adelante en el artículo.

Aunque en su mayoría está fuera del alcance de este artículo, el cliente Jito-Solana permite a los buscadores capturar el valor minero/máximo extraíble (MEV) de manera más eficiente de manera que se minimicen las externalidades negativas en Solana. Jito-Solana se desvía del programador predeterminado de Solana al introducir subastas de paquetes discretos de 200 milisegundos fuera de protocolo al estilo de Flashbots, que se ejecutan en paralelo a la producción continua de bloques predeterminada y un mempool privado (que nuevamente se desvía del TFM predeterminado de Solana). La adopción del cliente Jito-Solana por parte de los validadores de Solana (>50% de los validadores lo ejecutan hoy en día) ha ayudado a abordar algunos de los problemas con el TFM existente de Solana, a saber, la prevalencia del spam impulsado por MEV.

Deficiencias del TFM actual de Solana

Si bien el TFM de Solana es muy prometedor, también tiene algunas deficiencias potenciales por ahora:

Incentivo al spam

Como se mencionó anteriormente, las transacciones se ordenan de una manera similar a la de primero en entrar, primero en salir (FIFO) tan pronto como llegan al productor de bloques. Además, están sujetos a la falta de determinismo tanto de la fluctuación de red como de la asignación aleatoria de subprocesos del programador predeterminado. Aunque las tarifas de prioridad pueden ayudar a la probabilidad de inclusión en ciertas circunstancias, todavía existe un incentivo sustancial para enviar spam a las transacciones para maximizar la probabilidad de inclusión más rápida (por ejemplo, un buscador que se apresura a liquidar una posición en incumplimiento en un mercado de préstamos). La siguiente imagen de Jito Labs ayuda a demostrar la naturaleza subóptima de las transacciones de spam.

Fuente: Fundación Jito

Subasta de primer precio

En una ingenua subasta de primer precio (FPA), los usuarios simplemente envían ofertas, y las más altas se incluyen en el bloque. Un problema con los FPA es que no son muy fáciles de usar. Los usuarios deben adivinar lo que otros usuarios están ofertando, pensando en lo que están dispuestos a ofertar, potencialmente sombreando su oferta más baja para no pagar de más en función de lo que creen que otros están ofertando, por ejemplo.

Más formalmente, el modelo FPA no es DSIC:

** Compatibilidad con incentivos de estrategia dominante (DSIC): Suponiendo que el productor de bloques implemente el TFM de manera honesta, entonces la estrategia de oferta prescrita debe ser la estrategia dominante para los usuarios. Esto significa que los usuarios pujarán (en comisiones por transacción) al valor exacto que atribuyan a la inclusión de la transacción [Chu22].

DSIC es una de las propiedades clave que los creadores de EIP-1559 pretendían introducir en el TFM de Ethereum con su implementación, y como describimos anteriormente, puede considerarse un éxito. Los usuarios conocen más fácilmente el precio de reserva público que se incluirá en el bloque en un momento dado (a través de la tarifa base dinámica), por lo que pagarlo (más cualquier tarifa de prioridad nominal) casi siempre hará que su transacción se incluya rápidamente.

Por el contrario, el TFM de Solana es un FPA ingenuo. Carece de un mecanismo confiable para que los usuarios expresen con precisión su preferencia por la inclusión de bloques y no es DSIC. En la práctica, tratar de establecer exactamente la tarifa de prioridad correcta en el momento adecuado es increíblemente desafiante. Esto favorece desproporcionadamente a los participantes sofisticados que son más capaces de eludir la fluctuación de la red y del programador (por ejemplo, a través de transacciones de coubicación o spam).

Pago 50/50 Burn/Validator

Como se señaló anteriormente, Ethereum quema el 100% de la tarifa base mientras envía el 100% de la tarifa de prioridad al productor del bloque, mientras que para Solana, tanto la tarifa base como la tarifa de prioridad son 50/50 quemadas/pagadas al productor del bloque. Como resultado de esto, el TFM de Solana no es a prueba de OCA:

**Prueba de acuerdo fuera de la cadena (prueba de OCA o SCP): Ningún acuerdo fuera de la cadena entre los usuarios y el productor del bloque puede mejorar el resultado del TFM para un bloque determinado [Rou21]. Un protocolo c-SCP es resistente a una coalición entre el productor de bloques y hasta los usuarios c que pueden beneficiarse desviándose de informar con veracidad.

Vemos un claro ejemplo de esto con las subastas fuera del protocolo de Jito-Solana que pagan el 100% de las ofertas (menos el recorte de Jito) a los productores de bloques, en lugar de quemar el 50%: Jito-Solana es un ejemplo de un acuerdo fuera de la cadena utilizado por los productores de bloques. Sin embargo, observamos que las propinas de Jito-Solana no son equivalentes a las tarifas de prioridad, ya que las primeras solo se pagan si la transacción asociada (y el paquete) se ejecuta con éxito.

El SIMD-0109 recientemente propuesto introduciría un mecanismo de propina (similar al utilizado por la subasta fuera de protocolo de Jito-Solana) en el protocolo como una instrucción nativa.

Falta de tipos de transacciones privilegiadas

Las transacciones de votos de Solana se publican en la cadena y deben incluirse en bloques, pero cada validador debe pagar los costos de dichas transacciones. Esto representa un costo fijo significativo (pagado de forma privada por los validadores) a pesar de la externalidad positiva de la inclusión de las transacciones de votos. Este costo se ve exacerbado por el hecho de que las transacciones de voto se cobran de más en relación con las CU consumidas (es decir, usan relativamente pocas CU en comparación con la transacción promedio). La economía crea un efecto centralizador aquí, ya que el costo total de votación es aproximadamente constante para cualquier validador, mientras que las recompensas obtenidas son proporcionales al peso de la apuesta.

Fuente: Ceteris, Solana el Monolito

Por otro lado, una lógica similar podría ampliarse para incluir actualizaciones fiables de los oráculos, por las que las redes suelen cobrar a pesar de la externalidad positiva de las fuentes precisas de precios en cadena. Una cadena más obstinada que deriva un alto valor de un oráculo robusto en particular puede optar por consagrar un mecanismo que subsidie su costo.

Mercado de tarifas locales de Solana

La aproximación de Solana de un mecanismo de tarifas locales existe porque ninguna cuenta puede escribir más de 12 millones de CU por cada límite de bloque de 48 millones. Esto, junto con la naturaleza multihilo del programador predeterminado de Solana, significa que un máximo del 25% de las transacciones en un bloque pueden corresponder a una sola pieza de estado en demanda. En teoría, los usuarios de un estado con menos demanda no deberían tener que aumentar sus tarifas de prioridad para obtener fuertes garantías de inclusión en comparación con los usuarios de un estado con menor demanda.

Podría decirse que no se trata de un verdadero mecanismo de tarifas locales. El mecanismo no se aplica por consenso (es solo a nivel de programador), y la relación entre las tarifas de prioridad y la inclusión de bloques es bastante no determinista (como se mencionó anteriormente). También carece de una noción de "elasticidad" en la que existen límites de recursos tanto objetivo como máximos.

Uso y solicitudes ineficientes de CU

Debido a que la tarifa base de Solana no tiene en cuenta las CU, no incentiva las transacciones para:

1. Use las CU de manera eficiente: una transacción con 1,4 millones de CU conlleva la misma tarifa base que una con 100 mil CU, en igualdad de condiciones.
2. Solicitar CU de manera eficiente: incluso si una transacción usa 50 mil CU, tiene la misma tarifa base ya sea que solicite 100 mil CU o 1 millón de CU.

Esto puede llevar a una sobreestimación del proceso necesario dentro de un bloque determinado por parte del programador y a una pérdida de eficiencia en comparación con los recursos requeridos por el productor de bloques en una ranura determinada. Un TFM de DSIC solucionaría este problema, ya que la estrategia dominante de un usuario sería la de la estrategia de puja prescrita, en este caso, representar con precisión el uso esperado de las CU.

Escribir cuentas de bloqueo sin costo

Como se mencionó anteriormente, las transacciones de Solana especifican por adelantado todas las cuentas en las que leerán o escribirán durante la ejecución. Sin embargo, hoy en día se puede abusar de este mecanismo para bloquear globalmente cualquier cuenta sin costo alguno. Por ejemplo:

1. Envío Tx_A que especifica que escribirá en la Cuenta_A.
2. El líder recibe Tx_A, lo programa y comienza a ejecutarlo. La cuenta_A ahora está bloqueada: no se puede ejecutar ninguna otra transacción que toque la cuenta_A hasta que Tx_A haya terminado de ejecutarse.

El problema se deriva del hecho de que cualquiera puede enviar transacciones que bloquean por escritura las cuentas que desee. El bloqueo de cuentas no tiene ningún costo, y las transacciones pueden incluso bloquear cuentas que no usan, lo cual es un claro vector de ataque de spam. Además, los propietarios de cuentas no tienen control sobre quién puede bloquear su propia cuenta.

Propuestas y marcos del TFM

Cada cadena de bloques debe decidir en última instancia cómo asignar el escaso recurso de su espacio de bloques finito entre los usuarios, lo que hace a través de su TFM. A continuación, discutiremos varias propuestas y marcos relevantes de TFM que pueden ser valiosos para Solana.

Mercados multidimensionales de tarifas de blockchain

La mayoría de los mercados de tarifas existentes son unidimensionales, construidos en torno a una única unidad de cuenta fungible (por ejemplo, gas en Ethereum). Sin embargo, este único recurso comprado es un proxy de muchos recursos no fungibles subyacentes (por ejemplo, ancho de banda, computación y almacenamiento).

Por ejemplo, cada código de operación de Ethereum lleva una cierta cantidad fija de gas que consume (por ejemplo, ADD usa 3 gas, mientras que MUL usa 5). El precio del gas para cada código de operación se estableció como una aproximación aproximada de los recursos subyacentes que utilizan y lo caros que se consideran para los nodos de la red. Por ejemplo, esta medida implícita del costo de una operación se puede determinar mediante la ejecución de pruebas comparativas en hardware del mundo real.

Sin embargo, también es posible construir mercados de tarifas multidimensionales que fijen individualmente el precio de estos diferentes recursos no fungibles en lugar de combinarlos en una sola unidad. EIP-4844 es un mercado de tarifas bidimensional sencillo, ya que los blobs de datos tienen su propio mercado de tarifas independiente del gas de ejecución de Ethereum.

Este artículo de 2022 de Diamandis, Evans, Chitra y Angeris analiza cómo construir mercados de tarifas multidimensionales como este. Su trabajo enmarca el problema de la construcción del TFM desde la perspectiva de un diseñador de redes con el objetivo de maximizar el bienestar (o la utilidad total) de los usuarios de la cadena de bloques menos el consumo de recursos de dichos usuarios, sujeto a las restricciones de transacción y bloque de la cadena (por ejemplo, límites de contratos inteligentes o límites de CU/gas). El principal resultado del trabajo es que, a pesar de que se desconoce el bienestar, diseñan un mecanismo que lo maximiza y muestran cómo construir explícitamente dicho mecanismo.

**Maximización del bienestar: Las reglas de asignación y pago previstas implican que la suma del excedente del consumidor y del minero se maximiza (aproximadamente).

Su hallazgo clave es que se puede implementar un TFM equivalente, que es aquel en el que el precio del recurso se establece para minimizar la diferencia entre el bienestar de los validadores y sus usuarios: dicho precio debería conducir a bloques que, en teoría, son óptimos desde el punto de vista de maximizar el bienestar. Si bien este trabajo puede verse más como un marco académico para diseñar TFM óptimos, ayuda a mostrar que fijar el precio de los recursos por separado puede hacer que una cadena de bloques sea más eficiente y más resistente a períodos de alta congestión o spam. Los mecanismos de tarifas base basados en controladores, como EIP-1559, se destacan como un enfoque potencial que podría funcionar excepcionalmente bien en cadenas Solana y SVM, dados los cortos tiempos de bloque, lo que permite que la tarifa base se ajuste rápidamente a los cambios en la demanda de los usuarios y la disponibilidad de recursos.

Como se mencionó anteriormente, una de las conclusiones del documento es que es posible diseñar formas sistemáticas y computacionalmente eficientes para ayudar a definir y actualizar el precio de los recursos multidimensionales para blockchains. Sin embargo, una pregunta natural debería ser: ¿qué recursos tendría sentido fijar un precio distinto? Se ha realizado algún trabajo práctico dentro de otros contextos de blockchain para tomar tales decisiones. Por ejemplo, Penumbra ha implementado una forma de fijación de precios de recursos multidimensional para fijar el precio de los recursos utilizados por los nodos completos y los dispositivos de los usuarios finales por separado en su cadena de bloques centrada en la privacidad.

Si bien el documento de 2022 analiza en general la fijación de precios multidimensionales de los recursos base (por ejemplo, computación, ancho de banda, almacenamiento), también es posible implementar la fijación de precios multidimensionales de los recursos por cuenta (es decir, por "parte del estado"). Cada cuenta se trata como un recurso diferente. Esto se discute en este artículo reciente, que se basa en el documento original. Fijar precios individualmente en las cuentas (en lugar de computación, almacenamiento, ancho de banda, etc.) como recurso subyacente también puede ser más sencillo de implementar con un riesgo reducido de ataques de agotamiento de recursos.

Tarifa exponencial para cuentas de bloqueo de escritura

A raíz de la reciente publicación de Anatoly sobre SVM Execution Economics, Tao Zhu, en colaboración con Anatoly, propuso SIMD-0110. Su motivación principal es disuadir el spam con una contrapresión económica (es decir, aumentar las tarifas de manera específica a lo largo del tiempo para reducir el incentivo al spam), lo que resulta en una utilización más eficiente de los recursos de la red. Las transacciones de arbitraje fallidas siguen llenando aproximadamente la mitad (o más) del espacio de bloques de Solana porque es racional e increíblemente barato enviar spam.

La propuesta recomienda realizar un seguimiento de la media móvil exponencial (EMA) de la utilización de CU de cada cuenta por bloque para lograr esto. El costo de bloqueo de escritura de una cuenta aumentaría exponencialmente en función de su respectiva utilización de CU final, lo que evitaría el correo no deseado. La lógica central es similar a la forma en que EIP-1559 establece la tarifa base global de Ethereum en función del uso de gas en los bloques finales. Sin embargo, este SIMD es mucho más granular a la hora de establecer los mercados de tarifas base locales por cuenta.

La idea básica de implementación de la tarifa variable de bloqueo de escritura basada en cuentas sería la siguiente:

1. Realice un seguimiento de la utilización de la unidad de cómputo de EMA final de cada cuenta contenciosa en las últimas 150 ranuras.
2. El número máximo de cuentas de las que se realizará un seguimiento es 2048, donde solo se realiza un seguimiento de las cuentas más polémicas con la tasa de costo de bloqueo de escritura más alta.
3. Si la utilización de la unidad de cómputo de EMA de una cuenta es del >50 % de su límite máximo de CU, su tasa de costo de bloqueo de escritura aumentará en un X%. Si está al <50% de su límite, la tasa de coste disminuirá en un X%.
4. V0 recomienda una tasa de coste inicial de bloqueo de escritura de 1000 micro-lamports/CU y una tasa de ajuste de la tasa de coste del 1% por ranura (tenga en cuenta que los porcentajes exactos aquí están sujetos a cambios dada la naturaleza temprana de la propuesta).
5. La tarifa de bloqueo de escritura para una cuenta en un bloque determinado se calcula multiplicando la tasa de costo de bloqueo de escritura por las CU solicitadas de la transacción.
6. Las transacciones siguen pagando comisiones de firma, y también se mantienen las comisiones de prioridad opcionales.
7. Las tarifas de bloqueo de escritura cobradas se queman al 100%.
8. Las tarifas prioritarias cobradas son recompensadas al 100%.
9. Las tarifas de firma cobradas se queman en un 50% y se recompensan en un 50%.

Esta propuesta haría que la función de bloqueo de escritura de Solana (generalmente) DSIC fuera similar a la forma en que EIP-1559 hizo que el TFM de Ethereum (generalmente) DSIC y MMIC [Rou23] fueran similares, excepto en presencia de picos repentinos de tarifas.

Podemos definir la propiedad MMIC de la siguiente manera:

**Compatibilidad de incentivos para mineros miopes (MMIC): El productor de bloques maximiza su utilidad al no crear transacciones falsas y seguir las reglas establecidas del TFM. Miopía significa que este objetivo solo se refiere al bloque actual cuando se juzga la maximización de la utilidad [Rou21].

Cualquier mecanismo de arrastre es imperfecto en el sentido de que puede no representar con precisión el estado actual exacto de la demanda. Por ejemplo, la demanda puede ser baja durante un período prolongado de tiempo (y, por lo tanto, la tarifa base dinámica es baja), y luego aumentar repentinamente para una acuñación de NFT. Este puede ser el caso a nivel global (como en el TFM de Ethereum) y puede ser aún más volátil a nivel local por cuenta (como se considera en SIMD-0110).

Sin embargo, Solana también se beneficia de sus tiempos de bloque increíblemente bajos aquí. Esto puede permitir que la tarifa base se ajuste más rápidamente a un shock repentino de demanda, dependiendo de la agresividad con la que se mueva la curva. La forma del controlador de tarifas aquí es increíblemente importante.

El hecho de que esta tarifa de bloqueo de escritura se cobre en las CU solicitadas también incentiva adecuadamente a los usuarios y desarrolladores a estimar con precisión el uso de CU de una transacción. Esto evita el problema que discutimos anteriormente en el que la base de firma plana actual no tiene penalización por solicitar muchas más CU de las requeridas (incluso hasta el máximo de CU de 1,4 mm). De lo contrario, solo la tarifa de prioridad conlleva este incentivo hoy en día (ya que también lo cobran las CU solicitadas).

Una posible crítica aquí es que los mercados de tarifas locales basados en cuentas (especialmente esta propuesta, que requiere que se calcule una EMA continua para cada cuenta) podrían ser costosos desde el punto de vista computacional. Este tipo de comisión multidimensional no está acotada, dado que cualquier cuenta puede estar congestionada, lo que probablemente presentaría dificultades para un TFM de este tipo. Sin embargo, en el caso de SIMD-0110, esto se evita estableciendo un límite superior en el número de cuentas cuya EMA de uso de CU se puede rastrear en un momento dado.

** Computable de manera eficiente: El mecanismo de subasta de bloques debe diseñarse de manera que se pueda calcular de manera eficiente para un productor (o constructor) de bloques determinado: las ranuras de Eclipse y Solana son inferiores a 400 ms, lo que impone una restricción estricta al tiempo máximo de cómputo para un bloque determinado.

Dado que la inclusión de bloques de Solana seguiría siendo no determinista incluso con esta propuesta implementada, aún puede haber problemas con los usuarios que actualizan con precisión sus ofertas en tiempo real para garantizar que sus transacciones se incluyan en bloques. Para abordar esto aún más, es necesario realizar cambios en el programador, como se explica en la siguiente sección.

Cambios en el programador predeterminado de Solana

Como se ha comentado anteriormente, el "programador" es el algoritmo por defecto incluido en el cliente validador de Solana Labs, que programa las transacciones para su ejecución y construye bloques de forma continua. Desempeña un papel increíblemente importante en el mercado de tarifas de Solana, aunque su comportamiento predeterminado no se aplica en el protocolo, ya que los validadores pueden optar por ejecutar otros algoritmos. Nos centraremos aquí en el programador actual y los próximos cambios propuestos, en los que está trabajando Andrew Fitzgerald.

El programador actual de Solana introduce "fluctuación" en su manejo de las transacciones de los usuarios asignándolas aleatoriamente a uno de los cuatro hilos de transacciones que no son de votos (se reservan dos hilos adicionales para procesar transacciones de votos) antes de intentar clasificar las transacciones pendientes por tarifa de prioridad y verificar los bloqueos relevantes ('captura de bloqueos'), como muestra el diagrama a continuación . Se extraen múltiples lotes de transacciones para asignarlas a hilos durante la "Etapa bancaria", el proceso ejecutado por un validador de Solana en el que se procesan las transacciones y en el que se produce el proceso de programación.

Fuente: Andrew Fitzgerald, Solana Banking Stage and Scheduler

Un problema importante con el programador predeterminado ha sido que durante los períodos de intensa actividad de la red, la cola de cada hilo a menudo se llena de transacciones conflictivas (por ejemplo, antes de una acuñación de NFT o un evento de generación de tokens ampliamente esperado). Cada subproceso puede contener transacciones con los mismos bloqueos de lectura o escritura o superpuestos, lo que significa que esas transacciones deben reprogramarse para su ejecución posterior. El resultado de esto, sin embargo, es que en el peor de los casos, solo uno de los cuatro subprocesos predeterminados del programador podría estar ejecutando transacciones en un momento dado.

El quid de la actualización al programador predeterminado de Solana radica en la transición del enfoque heredado (denominado modo ThreadLocalMultiIterator) al nuevo enfoque de programación, denominado modo CentralScheduler. Este artículo solo proporcionará una descripción general y un análisis de los cambios. Sin embargo, se puede encontrar más información en el artículo de Andrew Fitzgerald y en el <a href="https://medium.com/@harshpatel_36138/whats-new-with-solana-s-transaction-scheduler-bcf79a7d33f7">summary de Harsh Patel del equipo de Tiny Dancer . A continuación se muestra una descripción general del nuevo proceso de programación.

Fuente: Andrew Fitzgerald, Solana Banking Stage and Scheduler

El nuevo programador implica un único programador central que recibe transacciones del canal antes de comprobar los bloqueos relevantes. Después de este punto, las transacciones se asignan a subprocesos de trabajo paralelos concretos para su ejecución. El programador central tiene una vista de los distintos bloqueos de lectura y escritura utilizados por un subproceso de trabajo determinado, lo que le permite determinar el mejor subproceso para una nueva transacción. A medida que las transacciones son ejecutadas y procesadas por un subproceso de trabajo determinado, se envía un mensaje al programador central para que pueda reevaluar qué partes del estado de Solana se consideran bloqueadas.

El programador utiliza un algoritmo denominado "prio-graph", que es un gráfico acrílico directo que comienza con las transacciones de mayor prioridad (tarifa) y las líneas (o, más exactamente, los bordes) entre una determinada transacción de mayor prioridad y las siguientes transacciones de mayor prioridad que entran en conflicto con ella debido a bloqueos superpuestos. Esto se hace (tentativamente) para una ventana de "anticipación" de un tamaño preconfigurado de 2.048 transacciones (sujetas a cambios), que se puede agregar al gráfico: los siguientes gráficos muestran que el prio-gráfico funciona para un conjunto dado de transacciones donde los bordes entre ellos representan bloqueos en conflicto.

Además de adoptar el programador prio-graph, esta versión introduce eficiencias adicionales para ayudar a reducir la sobrecarga de procesamiento, como la eliminación de los elementos redundantes de la etapa bancaria. El nuevo programador debería mejorar al reducir significativamente la probabilidad de escrituras fallidas y bloqueo de lectura durante períodos de alta actividad en Solana. Podríamos esperar una reducción en el jitter debido al nuevo programador predeterminado. Sin embargo, dada la naturaleza continua del proceso de construcción de bloques, seguirá habiendo no determinismo en la inclusión de bloques.

Cargos por escritura de cuenta reembolsable del programa (PRAW)

Escrito por Godmode Galactus y Max Schneider, SIMD-0016 propone tarifas de escritura de cuenta rebatible del programa (PRAW). Otorgarían un control significativo a los desarrolladores de aplicaciones, ya que podrían establecer los criterios para el pago y las rebajas de estas tarifas, lo que les permitiría incentivar y desincentivar el comportamiento de los usuarios como mejor les parezca.

Actualmente, los programas de Solana no tienen la capacidad de penalizar las transacciones por adquirir bloqueos de escritura en su estado. Las tarifas de PRAW permitirían a los propietarios de cuentas de Solana cobrar por transacciones fallidas que bloqueen su estado por escritura. Estas tarifas se transferirían a la cuenta de escritura que están bloqueando. Sin embargo, los propietarios de cuentas pueden establecer estas tarifas de modo que luego se devuelvan al usuario al final de la transacción si cumple con los criterios especificados.

En particular, esto puede disuadir a los usuarios de bloquear cuentas de escritura que en realidad no usan en la ejecución de la transacción. Esto es posible actualmente dado que Solana actualmente no tiene comprobaciones para ver si una cuenta determinada sería utilizada, a priori, por una transacción determinada que la ha bloqueado por escritura. Los PRAW ofrecen a los programas una forma de desincentivar las transacciones que bloquean el estado del programa en un intento de identificar una oportunidad con la intención de revertirla si la oportunidad ya no es válida en el momento de la ejecución. Estas tarifas se aplicarían incluso si la transacción fallara durante la ejecución.

Por el contrario, los usuarios pueden especificar la cantidad máxima de tarifas PRAW que están dispuestos a pagar en una transacción. Cualquier tarifa especificada en la transacción por encima de la tarifa actual de PRAW para una cuenta bloqueada por escritura determinada será reembolsada.

Los miembros de la comunidad de Solana señalaron problemas con esta propuesta: la capacidad de los diferentes programas para operar de forma totalmente autónoma parece subóptima, y la capacidad de estimar las tarifas con precisión resultaría difícil. Además, existen formas potencialmente más sencillas y uniformes de tratar estos problemas de duelo en torno a las cuentas bloqueadas por escritura, como SIMD-0110.

** Griefing Resistance: Un subconjunto de DSIC en el que los usuarios no están incentivados a tergiversar sus listas de acceso, tergiversando los recursos necesarios para su transacción [Gar23].

La propuesta de PRAW podría fracasar en la prevención del spam, ya que depende lo suficiente de los desarrolladores de aplicaciones: 1) ser capaces de distinguir el spam del "comportamiento normal" y 2) elegir voluntariamente cobrar más por una externalidad negativa de la que son parcialmente responsables cuando puede que no sea lo mejor para ellos hacerlo, y simplemente pueden optar por no hacerlo.

Por el contrario, aunque los miembros de la comunidad de investigación de Solana están innegablemente divididos sobre la introducción de las tarifas base de la EMA, en general existe un acuerdo sobre la adición de algún componente de la tarifa base que se escala con las CU. Esto puede incentivar una estimación precisa de las CU y un uso eficiente de las CU por parte de los desarrolladores.

Pensamientos de despedida

Los objetivos únicos de ingeniería y rendimiento de Solana requieren consideraciones únicas de TFM. Por supuesto, la simple migración del mercado de tarifas existente de Ethereum a Solana no es la solución aquí, pero hay lecciones valiosas que aprender de ello. Esto es muy relevante para los mecanismos que son:

1. En protocolo: TFM aplicados por consenso (p. ej., EIP-1559 y SIMD-0110)
2. Fuera de protocolo: PBS a través de MEV-Boost, mejoras en el programador de Solana y subastas de Jito

Tanto para Solana como para Ethereum, parece probable que los mecanismos dentro y fuera del protocolo coexistan y evolucionen juntos en el futuro. El equilibrio entre ellos es una de las cuestiones fundamentales en el diseño de estos sistemas. El debate en torno a SIMD-0110 a menudo se centra en dos puntos de vista opuestos:

1. Las mejoras del programador y de las redes para reducir la fluctuación abordarán suficientemente los problemas descritos aquí, por lo que no son necesarios cambios importantes en el TFM en el protocolo.
2. Si bien las mejoras en el programador y las redes fuera de protocolo son necesarias, son inherentemente insuficientes. Se requiere una contrapresión económica dentro del protocolo.

La fijación de precios de los recursos multidimensionales, de alguna forma, también es claramente valiosa en ambos casos. Ethereum está empezando a perseguir un TFM de este tipo a nivel de recursos básicos, con EIP-4844 dividiendo los datos de blob del mercado de ejecución. Por el contrario, Solana está impulsando la fijación de precios de recursos multidimensionales a nivel de cuenta individual para ser pionera en los "mercados de tarifas locales".

La investigación de TFM aquí es de vanguardia, y los investigadores están constantemente encontrando formas nuevas e innovadoras de mejorar el funcionamiento de las tarifas en Solana y otras cadenas. Somos optimistas de que las propuestas discutidas aquí continuarán haciendo que Solana sea aún más eficiente, escalable, fácil de usar y económicamente sostenible.

A medida que Eclipse se acerca al lanzamiento de nuestra red principal, también nos complace compartir más sobre cómo aplicaremos este trabajo existente a nuestro propio TFM, que sin duda continuará evolucionando en los próximos años. Tenemos la intención de experimentar e impulsar mecanismos en esta área. Un beneficio esencial del paradigma modular es que permite una polinización cruzada más fácil de la investigación y la ingeniería de diferentes ecosistemas. Este ritmo de experimentación ahora solo seguirá aumentando, beneficiando a todos los que construyen aquí a largo plazo.

Renuncia:

1. Este artículo es una reimpresión de [Eclipse], Reenvía el título original 'Solana & Ethereum Transaction Fee Mechanisms: Proposals to Improve Solana's TFM', Todos los derechos de autor pertenecen al autor original [Eclipse]. Si hay objeciones a esta reimpresión, comuníquese con el equipo de Gate Learn y ellos lo manejarán de inmediato.
2. Descargo de responsabilidad: Los puntos de vista y opiniones expresados en este artículo son únicamente los 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.