Introducción

Los mecanismos de tarifas son una característica importante de las cadenas de bloques. Los mantenedores de redes, como los validadores, tienen recursos finitos, por lo que es importante cobrar por los recursos escasos de una manera que refleje el costo para la red. Las tarifas también crean incentivos para los participantes de la red, como usuarios, desarrolladores de aplicaciones y validadores.

En esta serie, exploraremos el mecanismo de tarifas actual de Solana, formalizaremos el espacio de diseño para un mecanismo de tarifas y analizaremos algunos cambios propuestos al mecanismo de tarifas de Solana.

Esta pieza es la primera de la serie. Aquí explicamos cómo funcionan las tarifas de Solana en la actualidad, centrándonos en las tarifas basadas en transacciones.

Definiciones

Estas son definiciones específicas de Solana necesarias para comprender el mecanismo de tarifas.

Firma: al menos una, y normalmente exactamente una incluida por transacción.

Lamport: la unidad atómica más pequeña de SOL. 1 SOL equivale a mil millones (10^9) lamports.

Unidad de cómputo (CU): una unidad de cómputo, por instrucción Solana-BPF, destinada a aproximar el costo de ejecutar la instrucción. Similar a las unidades de gas en Ethereum.

CU utilizada: la cantidad de unidades informáticas utilizadas para ejecutar una transacción. Sólo se conoce después de la ejecución.

CU solicitada: especificada por la transacción; si la transacción excede este presupuesto de cálculo durante la ejecución, la ejecución se detiene y la transacción falla. La CU máxima solicitada (y utilizada) por transacción es de 1.400.000 CU.

Cuenta: una única pieza de estado en la cadena de bloques de Solana.

Programador: el mecanismo de construcción continua de bloques, incluido de forma predeterminada en el cliente Solana creado por Solana Labs.

Los honorarios de Solana

Tarifas de transacción

Hoy en día, una transacción de Solana incluye dos tarifas: una tarifa base y una tarifa de prioridad.

La tarifa base se fija por firma en 5.000 lamports (0,000005 SOL, 0,0003 dólares a 60 dólares/SOL) por firma; la gran mayoría de las transacciones de Solana tienen una firma.

La tarifa de prioridad opcional se especifica en la transacción y está denominada en microlamportes por CU solicitada. Tenga en cuenta que esto no es por CU utilizada, porque las CU utilizadas no se conocen hasta que se ejecuta una transacción. El programador prioriza de forma no determinista las transacciones con una tarifa de prioridad más alta. El mecanismo específico se describe en Ciclo de vida de una transacción de Solana.

Las tarifas se cargan al pagador de la tarifa al comienzo de la ejecución de la transacción. Si el pagador no puede pagar la tarifa requerida, se omite la ejecución, la transacción se considera inválida y no se incluye.

Tanto para la tarifa base como para la tarifa de prioridad, el líder se queda con el 50% como incentivo para incluir transacciones en bloques, y el 50% se quema.

En esta transacción de ejemplo, la transacción solicita 600 000 unidades informáticas y establece una tarifa de prioridad de 2500 microlamports por CU solicitada. Debido a que la transacción tiene una firma, la tarifa total de la transacción es 5000 lamports + 600,000 CU solicitadas * 2500 microlamports / CU solicitadas = 6500 lamports, o 0,0000065 SOL.

Tasas estatales

Solana cobra además una tarifa para crear un nuevo estado llamado exención de alquiler (término heredado). El coste actual de la exención del alquiler es estático de 6,96 SOL por MB. Cuando se crea una cuenta nueva, la tarifa se asigna a la cuenta; cuando se elimina la cuenta, se puede recuperar la tarifa de exención de alquiler.

Comentario

Incentivos para la eficiencia

Debido a que la tarifa base no depende de las CU utilizadas o solicitadas, no hay ningún incentivo en la tarifa base para optimizar el uso de la computación, ni para solicitar CU que se acerquen a cuántas se usan realmente. En la práctica, muchas transacciones en Solana solicitan muchas más CU de las que acaban utilizándose. Esto crea ineficiencias en el planificador.

En la transacción de ejemplo anterior, la transacción solicita 600 000 CU pero utiliza menos de 250 000.

Si bien la tarifa de prioridad incluye un incentivo para reducir las CU solicitadas y, por tanto, las CU utilizadas, este incentivo es débil la mayor parte del tiempo y sólo entra en vigor en momentos de congestión. Una modificación simple sería ampliar la tarifa base para exigir también una tarifa por CU solicitada. Esto incentivaría a los desarrolladores y remitentes de transacciones a reducir su uso de computación y solicitar solo los recursos necesarios.

Compatibilidad de incentivos

Un mecanismo es compatible con incentivos si todos los participantes en él logran el mejor resultado actuando de acuerdo con sus verdaderas preferencias. En el contexto de un mecanismo de tarifas, esto significa aproximadamente que el validador maximiza las tarifas ejecutando el algoritmo de construcción de bloques predeterminado, y que los remitentes de transacciones maximizan el bienestar al enviar transacciones con tarifas prioritarias de acuerdo con su verdadera disposición a pagar.

El mecanismo de tarifas de Solana no es compatible con incentivos para los validadores y remitentes de transacciones en la actualidad. Como se describió anteriormente, el líder se queda con el 50% de la tarifa de transacción y el 50% se quema. Debido a que no toda la tarifa va al líder, esto crea un incentivo para que el remitente de la transacción se confabule con el líder: en lugar de especificar una tarifa de prioridad para obtener la inclusión prioritaria, el remitente puede crear un acuerdo paralelo con el líder para pagar el tarifa de prioridad fuera de la red, lo que elimina la quema y sigue recibiendo prioridad.

En teoría, los validadores que ejecutan un mecanismo de este tipo reciben más tarifas y, por lo tanto, pueden ofrecer recompensas más altas a sus participantes delegados, creando una fuerza centralizadora.

Además de la integración vertical directa, la forma principal en que vemos este acuerdo paralelo en el mercado actual es a través de las subastas Jito. Los validadores que ejecutan Jito-Solana (una modificación del cliente de Solana Labs) rompen el mecanismo de construcción continua de bloques y ejecutan una subasta de espacio de bloques en la primera mitad de sus espacios.

No hemos observado otros acuerdos paralelos similares en el mercado hoy. Esto es porque:

• El cliente validador y su programador son difíciles de modificar, por lo que el costo de crear dicho acuerdo requiere un costo fijo alto. El software fuera de protocolo como Jito-Solana y los acuerdos de creación de bloques delegados como PBS en Ethereum amortizan el costo fijo en todos los validadores participantes.
• La gran mayoría de los ingresos de los validadores provienen de recompensas inflacionarias, no de tarifas de transacción, por lo que el beneficio es relativamente bajo.

Mercados de tarifas locales

A diferencia de la mayoría de las otras cadenas de bloques, Solana requiere que los remitentes de las transacciones especifiquen qué partes del estado son necesarias para ejecutar la transacción. Esto desbloquea la ejecución de transacciones paralelas y mercados de tarifas localizados, donde diferentes partes del estado tienen diferentes tarifas según cuán polémico sea un estado en particular. Un punto de acceso estatal localizado no necesita aumentar la contención o las tarifas en toda la cadena de bloques.

Un error común sobre Solana es que hoy cuenta con mercados de tarifas locales. Si bien es cierto que una transacción que paga una tarifa de prioridad más alta tiene más probabilidades de ser incluida más arriba en el bloque, y es probable que el estado en disputa requiera una prioridad más alta, este comportamiento no es determinista y es el resultado de la implementación del incumplimiento de Solana. algoritmo de programación. Exploramos esto más en Ciclo de vida de una transacción de Solana.

En particular, este comportamiento no se aplica por consenso y el orden determinista por tarifa de prioridad no está garantizado, ni por consenso ni por la implementación del programador. La construcción continua de bloques y la propagación de bloques de Solana evitan el orden determinista, a menos que se realicen grandes cambios (por ejemplo, Se implementan ordenamiento determinista y ejecución asincrónica).

Una tarifa base predecible y aplicada por consenso para el acceso estatal, basada en una disputa histórica, podría mejorar la eficiencia y la experiencia de usuario para acceder a un estado altamente disputado. Esto aumentaría el costo del spam y, al mismo tiempo, incentivaría a los remitentes de transacciones a bloquear la cantidad mínima de estado que realmente necesitan. No abordaría la causa raíz del spam, que proviene de la creación continua de bloques (por lo que la latencia es importante) y la fluctuación. Exploraremos este diseño más adelante en esta serie.

Externalidades

Debido a que las transacciones se ordenan principalmente según el momento en que llegan al líder (programador), y este orden está sujeto tanto a la inestabilidad de la red como a la inestabilidad debido a la implementación del planificador paralelizado, existe un incentivo para enviar spam a las transacciones cuando el remitente quiere que una se incluya lo más rápido posible. posible. Estas transacciones traen una externalidad negativa a la red en forma de spam que llega a la cadena (a partir de enero de 2023, el 58 % del cómputo en cadena de Solana se utiliza para revertir transacciones) y spam que llega al líder.

De los laboratorios Jito

Conclusión

En este artículo, describimos cómo funciona hoy el mecanismo de tarifas de Solana y sus implicaciones en la red. Hemos insinuado algunas propiedades que un mecanismo de tarifas ideal satisfaría, como sugerencias precisas para el programador (solicitada por CU), compatibilidad de incentivos y mercados de tarifas verdaderamente localizados. En el siguiente artículo, definiremos un formalismo para los objetivos para los que debe optimizarse el mecanismo de tarifas. Esto se utilizará para analizar el mecanismo de tarifas actual, así como las modificaciones propuestas al mecanismo, con más rigor del aquí expresado.

Descargo de responsabilidad:

1. Este artículo está reimpreso de [Umbra Research]. Todos los derechos de autor pertenecen al autor original [@0xShitTrader]. 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 están a cargo del equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.