Introducción: ¿por qué no se incluyen mis transacciones?

Una transacción de SolanaviajeDesde la presentación del usuario hasta la inclusión en bloque puede ser arduo. Incluso una vez que la transacción llega al líder actual, debe competir con otras transacciones por un espacio limitado en el bloque. Incluir transacciones de manera puramente por orden de llegada fomenta el spam y puede bloquear transacciones de alto valor de usuarios comunes. Para resolver este problema, necesitamos un mecanismo de tarifas.

¿Tarifas prioritarias al rescate?​

Las tarifas prioritarias resuelven este problema, ¿verdad? Desafortunadamente, no para la mayoría de los usuarios.

Imagina este escenario. Quieres ir al cine de tu ciudad, que tiene 100 asientos, pero el cine tiene un sistema de venta de entradas anormal: no publican el precio de las entradas. En su lugar, debes decirles cuánto estás dispuesto a pagar. (Digamos que son $50). Si la demanda es alta y al menos otras 100 personas han presentado un precio más alto, mala suerte. ¡Si la demanda es baja, estás adentro! La trampa: estás pagando $50 incluso si el cine está vacío. Pero la experiencia de comprar las entradas no termina ahí. Este sistema tiene otra peculiaridad: debes decirle al cine cuánto estás dispuesto a pagar antes de salir de tu casa. Obviamente, obtener una entrada de cine en este sistema es una experiencia potencialmente tensa para la persona promedio. Los individuos ricos y sofisticados, por otro lado, pueden estimar con precisión el precio de la entrada. Pueden instalar cámaras al lado del cine para monitorear el tráfico en tiempo real. Pueden usar este tráfico y los datos históricos recopilados para estimar la demanda en un día determinado. E incluso pueden comprar un helicóptero para viajar al cine más rápido después de decirle al cine cuánto están dispuestos a pagar. Aunque es posible utilizar este sistema de venta de entradas de manera efectiva, la experiencia es horrible para la mayoría de las personas que quieren ir al cine. Cuando el cine está lleno, muchas de estas personas pueden no molestarse en intentar ir en absoluto.

De manera similar, la tarifa de prioridad "verdadera" necesaria para una transacción de Solana es difícil de estimar.Fluctúa muchoDurante períodos de alta congestión, las billeteras que utilizan promedios recientes probablemente sobreestimarán la tarifa requerida, lo que hará que los usuarios paguen de más por la inclusión de la transacción. (E incluso con una tarifa de prioridad alta, una transacción todavía puede que no esté incluidodebido a la naturaleza de la producción continua de bloques multinúcleo). En teoría, las tarifas de prioridad pueden asignar de forma óptima el espacio del bloque. En la práctica, fallan completamente. Afortunadamente, existen formas de resolver estos problemas, lo que resulta en transacciones más baratas con una mejor probabilidad de inclusión para la mayoría de los usuarios. Antes de profundizar en la solución, examinemos algunas propiedades del recurso que estamos tratando de asignar: espacio de bloque.

Blockspace: oferta fija, demanda salvajemente fluctuante​

Las transacciones en Solana son verificadas y ejecutadas de forma independiente por una red descentralizada de validadores. Debido a que estos validadores tienen recursos computacionales limitados, Solana limita los recursos computacionales totales, medidos en unidades de cómputo (CUs), que pueden ser utilizados por bloque. Cuando la demanda de espacio de bloque aumenta más allá de la oferta limitada, este recurso fijo debe asignarse entre transacciones competidoras.

De alguna manera, el mercado puede manejar la asignación de espacio de bloque a través de precios; las transacciones con mayor utilidad para el remitente están dispuestas a pagar un precio más alto. Sin embargo, este mecanismo no funciona cuando los usuarios no saben cuál es el precio del espacio de bloque. Como se discutió anteriormente, una tarifa de prioridad por sí sola conduce a precios de transacción difíciles de estimar para la mayoría de los usuarios y tiene garantías de inclusión de transacción pobres. Otras blockchains han abordado este problema implementando un mecanismo de tarifa de transacción (por ejemplo,EIP-1559 en Ethereum, y tarifas multidimensionales en AvalancheyPenumbra). Estos mecanismos de tarifas implementan una tarifa base fácil de estimar que proporciona una 'tarifa de entrada' predecible para la red; esta tarifa base aproxima el precio real para la inclusión de transacciones.

Revisión: Tarifas de Solana hoy​

Solana actualmente implementa dos mecanismos de tarifas: una tarifa base y una tarifa de prioridad. Podemos pensar en la tarifa base como una "tarifa de entrada" para usar la red y en la tarifa de prioridad como una propina adicional para incentivar a los validadores a incluir una transacción sobre otra. La tarifa base de Solana es de 5000 lamports fijos por firma (generalmente una por transacción). Como resultado, los usuarios que envían transferencias simples pagan la misma tarifa base que los usuarios que juegan juegos pesados en computación on-chain y que los buscadores que intentan capturar oportunidades de MEV complicadas. Por lo tanto, la tarifa base actualmente cobrada no captura con precisión el uso de recursos de una transacción (y la "externalidad," en términos económicos), lo que resulta potencialmente enmal usado blockspace.

En nuestro ejemplo de teatro, una tarifa base fija similar cobraría el mismo precio a un cinéfilo que compra 1 asiento y a otro que compra todos los 100 asientos.

¿Por qué un mecanismo de tarifa base?​

Las tarifas base deben ser en cambio una función de los recursos utilizados. Este consumo se mide actualmente en unidades de cómputo (CUs), pero también podría incluir otros recursos como el acceso a la cuenta. Queremos que el usuario tenga un costo de participación más predecible, dado por una tarifa base dinámica. Estas tarifas son difíciles de establecer correctamente. (Hay mucha investigación académica, incluyendo el nuestro, ¡intentando abordar esto!) Sin embargo, cualquiera que haya sufrido transacciones fallidas debido a la congestión de la red sabe que las tarifas también son importantes para hacerlas bien si queremos que una red crezca.

En última instancia, muchos usuarios que desean enviar transacciones no están seguros de cuánto pagar por las tarifas de prioridad. Si sobreestiman estas tarifas, pagarán demasiado. Si las subestiman, la transacción no se incluirá. Por otro lado, en cuanto a las tarifas base, los usuarios pagan exactamente la tarifa publicada actual. Nos gustaría que la tarifa base capture con precisión el verdadero costo de la inclusión de las transacciones. Aquí asumimos que todas las transacciones llegan al programador, pero compiten por un espacio limitado en el bloque, incluido el acceso informático y de cuentas. Durante períodos de alta demanda, no todas las transacciones pueden incluirse. En esta publicación, delineamos pasos hacia un mecanismo de tarifas base dinámicas que pueden ayudar a descongestionar la red y proporcionar una inclusión de transacciones más predecible.

Aparte: Tarifas prioritarias y MEV​

Las tarifas prioritarias pueden ser vistas alternativamente como pagos por oportunidades particulares que están limitadas por algo que no sea el consumo de recursos. Por ejemplo, si dos buscadores envían simultáneamente una transacción para liquidar un préstamo en particular, solo una de estas transacciones puede ejecutarse con éxito; solo la primera transacción en el bloque liquida con éxito el préstamo. Por lo tanto, las tarifas prioritarias a menudo pagan por el ordenamiento de transacciones más que por la inclusión solamente. Este uso de las tarifas prioritarias para capturar oportunidades de MEV es algo ortogonal a esta publicación—ver MEV en Solanapara más discusión. En esta publicación, nos concentramos en las tarifas base y la inclusión de transacciones.

Bloques óptimos

Antes de discutir cómo establecer las tarifas base, consideraremos un mecanismo ficticio para la inclusión de bloques: un diseñador de red omnisciente elige transacciones para cada bloque que maximizan el bienestar de los usuarios (la utilidad total o 'felicidad' de una transacción incluida), menos el costo de consumo de recursos de la red, sujeto a restricciones de transacción (por ejemplo, restricciones de contrato inteligente, límites de cómputo, etc.). Por supuesto, el bienestar del usuario es desconocido e imposible de medir para el diseñador de red en la práctica, y el diseñador de red no construye los bloques. Sin embargo, podemos usar este problema como referencia mental para un bloque 'óptimo' construido a partir de las transacciones que llegan al programador. Nuestro objetivo es diseñar un mecanismo de tarifas que se acerque a esta referencia.

Aunque este mecanismo ficticio de construcción de bloques es intratable, resulta que podemos idear un mecanismo equivalente que sea factible en la práctica. Este mecanismo equivalente busca encontrar los precios de los recursos que minimicen la brecha entre el bienestar de la red y el de sus usuarios. Establecer correctamente los precios de los recursos alinea los incentivos de manera que los costos de los recursos para la red estén exactamente equilibrados por la utilidad obtenida por los usuarios y validadores, incluso si la red no tiene idea de cuál es esta utilidad y los usuarios nunca la especifican explícitamente. Estos precios conducen entonces a bloques que son “óptimos” en promedio. Así que podemos concentrarnos solo en establecer estos precios. (Para obtener más detalles técnicos, consultaeste documento.)

Hacia un mecanismo

Entonces, ¿cómo establecemos los precios para incentivar bloques óptimos, como se discutió anteriormente? Un primer enfoque podría ser cobrar una cantidad fija por unidad de cálculo utilizada por una transacción. Desafortunadamente, este enfoque no funcionará. Si la demanda es baja, entonces este precio fijo por CU hará que los usuarios no envíen transacciones, y los bloques pueden estar cerca de vacíos. Si la demanda es alta, entonces este precio fijo puede ser demasiado bajo y, como resultado, no hará nada para aliviar la congestión de la red o aproximar el verdadero costo de la inclusión de transacciones (¡nuestro objetivo original!). Por lo tanto, necesitamos tener alguna forma de aumentar y disminuir la tarifa base según la demanda de la red, y también alguna forma de estimar esta demanda.

Tarifas base dinámicas

El siguiente paso es agregar un controlador que ajuste la tarifa por unidad de cálculo en función del uso pasado. Por ejemplo, si hay un objetivo de uso por bloque (es decir, un uso ideal en estado estable para la cadena), podemos aumentar o disminuir la tarifa base en función de la utilización o la desviación de este objetivo. Muchos mecanismos, incluidos los tales como EIP-1559Implementa esta idea. Podríamos sentirnos tentados a actualizar dinámicamente la tarifa base dentro de un solo bloque utilizando la demanda en tiempo real, o a animar a cada líder a elegir sus propias reglas de actualización de tarifas. Sin embargo, estos cambios reducirían la previsibilidad de la tarifa base, lo que va en contra del propósito original de este mecanismo de tarifas. La elección del mecanismo finalmente determina la experiencia del usuario.

Afortunadamente, los tiempos de bloque rápido de Solana permiten algoritmos agresivos para establecer la tarifa base. Por ejemplo, podemos aumentar rápidamente el precio durante períodos de alta demanda (por ejemplo, duplicar el precio por cada bloque completo) y luego bajar el precio más lentamente a medida que la demanda disminuye. El precio seguirá cayendo razonablemente rápido debido a los cortos tiempos de bloque de Solana. Intuitivamente, cuando un recurso específico está al límite, la red está cobrando significativamente menos y obteniendo menos información sobre cuál debería ser el precio óptimo. Tipos similares de algoritmos se utilizan en la práctica en Control de congestión TCP, la capa de enlace de datos de las comunicaciones inalámbricas, y optimización del mercado.

Tarifas multidimensionales: mercados locales de tarifas

La discusión anterior consideraba un recurso conjunto compartido por todas las transacciones: las unidades de cálculo (globales). Sin embargo, el acceso al estado en Solana también afecta significativamente el uso de recursos de transacción. Si muchas transacciones acceden a la misma parte del estado, no pueden ejecutarse en paralelo y, por lo tanto, reducen el rendimiento de la red. Naturalmente, nos gustaría que estas transacciones paguen una tarifa base más alta, motivando mercados de tarifas por cuenta (locales). (La cuestión de quién recibe estas tarifas está más allá del alcance de esta publicación; más sobre eso en el futuro).

Como ejemplo concreto, consideremos una popular caída de NFT. Sin mercados de tarifas por cuenta, esta caída aumentaría significativamente la tarifa base para todas las demás transacciones. Con tarifas por cuenta, el costo de enviar transacciones para reclamar un NFT (y acceder a esa parte del estado) puede aumentar, mientras que las tarifas para otras transacciones (como reponer colateral en un préstamo) permanecen en gran medida sin cambios. Este tipo de diseño de mercado de tarifas local por cuenta está siendo considerado en un Documento de Mejora de Solana en Borrador.

Estas tarifas multidimensionales también pueden tener en cuenta las correlaciones entre contratos. Por ejemplo, si dos intercambios de cNFT comercian muchas de las mismas colecciones, sus contratos requieren acceso a muchas de las mismas cuentas. Si el volumen de negociación aumenta drásticamente para una colección particular en uno de estos intercambios, entonces la tarifa base aumentará para esa colección en el otro, ya que la tarifa para la cuenta subyacente ha aumentado para ambos. De esta manera, las tarifas por cuenta "locales" se correlacionan adecuadamente de una manera "global", y las tarifas multidimensionales evitan el aprovechamiento del sistema al liberar múltiples contratos para la misma aplicación.

Por otro lado, si el estado de la aplicación en sí mismo está paralelizado, las tarifas serán más bajas. Esta propiedad es deseada; la paralelización aumenta el rendimiento, ya que permite que las diferentes transacciones que acceden a la misma aplicación se coloquen en diferentes hilos cuando las cuentas subyacentes no se superponen (ver Ciclo de una Transacción Solana.

El controlador de precios para estos mercados locales de tarifas por cuenta puede ser diferente al utilizado para las unidades de cálculo. Tal vez para las cuentas no cobramos ninguna tarifa hasta que el estado esté significativamente disputado, momento en el que la tarifa aumenta rápidamente. El análisis de períodos pasados de congestión puede ayudar a informar estas decisiones de diseño.

Mecanismos alternativos​

Las opciones discutidas anteriormente no son las únicas formas de establecer tarifas. La mayoría de los mecanismos de tarifas base siguen aproximadamente el mismo procedimiento iterativo: en cada bloque...

1. observa el consumo de recursos de los bloques más recientes (resultado de las transacciones incluidas);
2. calcular una función de este consumo (por ejemplo, desviación de un objetivo);
3. y luego actualizar los precios de los recursos utilizando la salida del paso 2 y una regla simple.

En los ejemplos discutidos anteriormente, utilizamos diferentes opciones para los recursos en el paso 1 y el mecanismo de actualización en los pasos 2 y 3. Se discute un método para convertir las preferencias de utilización de recursos en una regla de actualización de tarifas concretas en este documento.

¿Funciona esta cosa multidimensional?

Si bien nuestro trabajo académico es principalmente teórico, ejemplos simples de juguetes muestran que fijar precios de recursos, como cuentas, por separado puede aumentar la eficiencia de la red y hacer que la red sea más resistente a los ataques de denegación de servicio o cambios en los tipos de transacciones enviadas. En esta sección, destacamos la diferencia entre un mecanismo de tarifas unidimensional y multidimensional simple (ver sección 4 de nuestro papel para más detalles).

Comportamiento en estado estacionario​

Primero simulamos el comportamiento en estado estable de un mecanismo de tarifas multidimensional con transacciones que requieren cantidades aproximadamente iguales de recurso 1 y recurso 2. Bajo un comportamiento en estado estable, la fijación de precios uniforme causa una mayor desviación de los objetivos de uso de recursos (izquierda). El uso menos eficiente también conduce a una menor capacidad de procesamiento (derecha).

Cambios en la distribución​

También probamos el comportamiento del mecanismo bajo un cambio en la distribución: agregamos 150 transacciones en el bloque 10 que requieren una cantidad significativa de recursos 2. Este escenario puede aparecer en una acuñación de NFT, por ejemplo. La fijación de precios multidimensional conduce a un rendimiento significativamente mayor cuando la distribución se desplaza (a la izquierda) ajustando los precios de los recursos en consecuencia (a la derecha).

Al observar el uso individual de recursos, vemos que la fijación de precios multidimensional (izquierda) facilita la capacidad de ráfagas cortas, mientras que la fijación de precios uniforme (derecha) no lo hace.

Conclusión

Las blockchains tienen recursos computacionales finitos. Cuando la demanda de usuarios es alta, esto requiere asignar estos recursos finitos entre transacciones de usuarios competidores de forma predecible. Esta asignación debería hacerse implícitamente a través de una tarifa base de transacción dinámica.

Proponemos un mecanismo teóricamente fundamentado para establecer esta tarifa, que no solo puede aumentar el rendimiento de la red durante períodos de alta demanda, sino también mejorar la experiencia del usuario al desacoplar transacciones no relacionadas y proporcionar un costo predecible de inclusión de transacciones. Para obtener más detalles sobre el mecanismo, consulte La charla de Tarun en Breakpointynuestro papel!

Descargo de responsabilidad:

1. Este artículo ha sido reimpreso de [ umbraresearch], Reenviar el Título Original 'Hacia las Tarifas Multidimensionales de Solana', Todos los derechos de autor pertenecen al autor original [@theo_diamandis、@tarunchitra、@0xShitTrader]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo, y lo resolverán rápidamente.

2. Responsabilidad por deslindes: Las opiniones y puntos de vista 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 indique lo contrario, está prohibido copiar, distribuir o plagiar los artículos traducidos.