Varios recursos en una red de blockchain son limitados, por ejemplo, el almacenamiento y la computación. Las tarifas por transacción evitan que los usuarios individuales consuman demasiados recursos. Polkadot utiliza un modelo de tarifas basado en el peso, en lugar de un modelo de medición de gas. Así, las tarifas se cobran antes de la ejecución de la transacción; una vez pagada la tarifa, los nodos ejecutan la transacción.
Web3 Foundation Research diseñó el sistema de tarifas de Polkadot con los siguientes objetivos:
- Cada bloque de la Relay Chain debe ser procesado eficientemente para evitar retrasos en la producción de bloques.
- La tasa de crecimiento de la Relay Chain debe estar vinculada.
- Cada bloque debe tener espacio para transacciones especiales de alta prioridad, como los informes de mala conducta.
- El sistema debe ser capaz de manejar los picos de demanda.
- Las tarifas deben cambiar lentamente para que los remitentes puedan predecir con exactitud la tarifa de una determinada transacción.
Cálculo de Tarifas #
Las tarifas de la Relay Chain de Polkadot se calculan en función de tres parámetros:
- A Peso de la tarifa
- Peso base
- Peso de la (s) llamada (s)
- Una tarifa de longitud
- Una propina (opcional).
Los pesos son un conjunto fijo de números que se utilizan en las cadenas basadas en Substrate para gestionar el tiempo que se tarda en validar un bloque. Cada transacción tiene un peso base que da cuenta de los gastos generales de inclusión (por ejemplo, la verificación de la firma) y un peso de envío que da cuenta del tiempo de ejecución de la transacción. Todos los pesos, incluso el peso base, son una medida del tiempo de ejecución en algún hardware estándar.
El tiempo de ejecución convierte las unidades de peso en unidades de balance como parte del cálculo de la tarifa.
La tarifa de peso es la suma del peso base y la suma del peso total consumido por la(s) llamada(s).
- Una transacción puede incluir varias llamadas. Por ejemplo, un
batchpuede contenerbondynominate, y el peso sería un peso base y luego la suma de los pesos debondynominate.
Para saber más sobre la motivación de una tarifa de peso, consulta este documento de Substrate sobre los pesos.
La tarifa de longitud es un multiplicador de tarifa por byte para el tamaño de la transacción en bytes.
También hay un ajuste de la tarifa por objetivo que sirve como multiplicador que afina la tarifa final en función de la congestión de la red. Esto puede constituir una tarifa de peso ajustada que se calcula como el ajuste de la tarifa específica multiplicado por la tarifa de peso.
El conjunto de estas tarifas constituye la tarifa de inclusión. La tarifa de inclusión es la tarifa base más la tarifa de longitud más la tarifa de peso ajustada.
La tarifa de inclusión se deduce de la cuenta del remitente antes de la ejecución de la transacción. Una parte de la tarifa se destina al autor del bloque y el resto al Tesoro. Son el 20% y el 80%, respectivamente.
Las propinas (tips) son una tarifa de transacción opcional que los usuarios pueden añadir. Las propinas no forman parte de la tarifa de inclusión y son un incentivo para los autores de bloques por dar prioridad a una transacción, y la totalidad de la propina va directamente al autor del bloque.
Límites de los Bloques y Prioridad de las Transacciones #
Los bloques en Polkadot tienen una longitud máxima (en bytes) y un peso máximo. Los productores de bloques llenarán los bloques con transacciones hasta estos límites. Una parte de cada bloque -actualmente el 25%- se reserva para transacciones críticas relacionadas con el funcionamiento de la cadena. Los productores de bloques sólo llenarán hasta el 75% de un bloque con transacciones normales. Algunos ejemplos de transacciones operativas:
- Informes de mala conducta
- Operaciones del consejo
- Operaciones de los miembros en una elección (por ejemplo, renuncia a la candidatura)
Los productores de bloques priorizan las transacciones en función de la tarifa total de cada transacción. Dado que una parte de la tarifa irá a parar al productor del bloque, los productores incluirán las transacciones con las tarifas más altas para maximizar su recompensa.
Ajuste de Tarifas #
El volumen de transacciones en las blockchains es muy irregular, por lo que las tarifas de transacción necesitan un mecanismo de ajuste. Sin embargo, los usuarios deben ser capaces de predecir las tarifas de las transacciones.
Polkadot utiliza un mecanismo de tarifas de ajuste lento con propinas para equilibrar estas dos consideraciones. Además de los límites de los bloques, Polkadot también tiene un objetivo de llenado de bloques. Las tarifas aumentan o disminuyen para el siguiente bloque en función del llenado del bloque actual en relación con el objetivo. La tarifa por peso puede variar hasta un 30% en un periodo de 24 horas. Esta tasa capta las tendencias a largo plazo de la demanda, pero no los picos a corto plazo. Para tener en cuenta los picos a corto plazo, Polkadot utiliza propinas además de las tarifas por longitud y peso. Los usuarios pueden añadir opcionalmente una propina a la tarifa para dar mayor prioridad a la transacción.
Transacciones de Shards #
Las transacciones que tienen lugar dentro de las shards (fragmentos) de Polkadot – parachains y parathreads – no incurren en tarifas de transacción de la Relay Chain. Los usuarios de las aplicaciones de las shards ni siquiera necesitan tener tokens DOT, ya que cada shard tiene su propio modelo económico y puede o no tener un token. Sin embargo, hay situaciones en las que las propias shards realizan transacciones en la Relay Chain.
Las parachains tienen un slot (ranura) dedicado en la Relay Chain para su ejecución, por lo que sus collators (recolectores) no necesitan poseer DOT para incluir bloques. La parachain hará algunas transacciones por sí misma, por ejemplo, abrir o cerrar un canal XCM, participar en una subasta para renovar su ranura, o actualizar su tiempo de ejecución. Las parachains tienen sus propias cuentas en la Relay Chain y tendrán que usar esos fondos para emitir transacciones en nombre de la parachain.
Las parathreads también realizarán las mismas transacciones que podría hacer una parachain. Además, los collators necesitan participar en una subasta cada bloque para hacer progresar su cadena. Los collators necesitarán tener DOT para participar en estas subastas.
Otras Estrategias de Limitación de Recursos #
El peso de las transacciones debe ser computable antes de la ejecución, y por tanto sólo puede representar una lógica fija. Algunas transacciones justifican la limitación de recursos con otras estrategias. Por ejemplo:
- Vinculaciones: Algunas transacciones, como la votación, pueden requerir una vinculación que será devuelta o recortada (slashed) después de un evento en la cadena. En el ejemplo de la votación, se devuelve al final de la elección o se corta si el votante intenta algo malicioso.
- Depósitos: Algunas transacciones, como establecer una identidad o reclamar un índice, utilizan espacio de almacenamiento indefinidamente. Estas requieren un depósito que será devuelto si el usuario decide liberar el almacenamiento (por ejemplo, borrar su IDE).
- Quemas: Una transacción puede quemar fondos internamente basándose en su lógica. Por ejemplo, una transacción puede quemar fondos del emisor si crea nuevas entradas de almacenamiento, aumentando así el tamaño del estado.
- Límites: Algunos límites forman parte del protocolo. Por ejemplo, los nominadores sólo pueden nominar a 16 validadores. Esto limita la complejidad de Phragmén.
Avanzado #
Esta página sólo cubre las transacciones que provienen de usuarios normales. Sin embargo, si miras los bloques en un explorador de bloques, puedes ver algunos “extrínsecos” que parecen diferentes a estas transacciones. En Polkadot (y en cualquier cadena construida sobre Substrate), un extrínseco es una pieza de información que viene de fuera de la cadena. Los extrínsecos se dividen en tres categorías:
- Transacciones firmadas
- Transacciones sin firma
- Extrínsecos
Esta página sólo cubre las transacciones firmadas, que es la forma en que la mayoría de los usuarios interactúan con Polkadot. Las transacciones firmadas provienen de una cuenta que tiene fondos, y por lo tanto Polkadot puede cobrar una tarifa de transacción como una forma de evitar el spam.
Las transacciones no firmadas son para casos especiales en los que un usuario necesita enviar un extrínseco desde un par de claves que no controla fondos. Por ejemplo, cuando los usuarios reclaman sus tokens DOT después de la génesis, su dirección DOT no tiene fondos todavía, por lo que se utiliza una transacción sin firmar. Los validadores también envían transacciones sin firmar en forma de mensajes “heartbeat” para indicar que están en línea. Estos heartbeat (latidos) deben estar firmados por una de las claves de sesión del validador. Las claves de sesión nunca controlan los fondos. Las transacciones no firmadas sólo se utilizan en casos especiales porque, como Polkadot no puede cobrar una tarifa por ellas, cada una necesita su propia lógica de validación personalizada.
Por último, los inherentes son piezas de información que no están firmadas ni incluidas en la cola de transacciones. Como tal, sólo el autor del bloque puede añadir inherentes a un bloque. Se asume que los inherentes son “verdaderos” simplemente porque un número suficientemente grande de validadores han acordado que son razonables. Por ejemplo, los bloques de Polkadot incluyen una marca de tiempo inherente. No hay forma de demostrar que una marca de tiempo es verdadera de la misma manera que se demuestra el deseo de enviar fondos con una firma. Más bien, los validadores aceptan o rechazan el bloque en función de cuán razonable encuentran la marca de tiempo. En Polkadot, debe estar dentro de un rango aceptable de sus propios relojes del sistema.