ParallelChain Tokenomics Whitepaper
Roderick McKinley CFA 1, equipo de ParallelChain
Versión 1.1
RESUMEN:
ParallelChain es un nuevo protocolo de capa 1 basado en un mecanismo de consenso de prueba de participación delegada (DPoS) (ParallelBFT) que emplea un diseño innovador de validador de varias clases. Este abordaje ofrece beneficios significativos en cuanto a rendimiento, como un mayor rendimiento y tiempos de finalización más rápidos, mientras se conservan características atractivas de resistencia a la censura que se pierden en otros diseños más centralizados.
La tokenómica de ParallelChain se ha desarrollado para motivar un rendimiento de validador sostenido y de alta calidad dentro de este diseño de consenso único de varias clases. Las buenas acciones del validador ganan recompensas que se financian con la recolección de tarifas de transacción de los usuarios finales y la emisión de nuevos tokens.
• Nuestro mecanismo de tarifa de transacción está modelado estrechamente en el adoptado por Ethereum para su reciente actualización “London Fork”. Hacemos un ajuste modesto en el diseño para asegurar una conexión económica más fuerte entre las recompensas del validador reclamadas y el valor creado para los usuarios finales.
• Nuestro mecanismo de emisión de tokens sigue un horario fijo de tasa decreciente. Este enfoque crea certeza de suministro, reduce la presión inflacionaria con el tiempo y establece el token nativo XPLL en una transición preestablecida y clara hacia fundamentos impulsados por el uso en la madurez de la red.
Las recompensas del validador financiadas por estos dos procesos se distribuyen de acuerdo con un modelo de tope y margen. Los límites de recompensa se han diseñado para crear acciones descentralizadoras que contrarresten la concentración de participación entre nodos de la misma clase. También se ha creado un apoyo adicional de incentivos a nivel de clase para mantener equilibrada la participación entre cada clase de validador en su conjunto. Este documento cubrirá en detalle todos estos mecanismos.
A continuación, realizaremos una revisión de las asignaciones de tokens pre-minted que se están reservando para fines especiales (levantamiento de capital, semillas para los primeros nodos en la red y financiamiento del desarrollo futuro) y cómo los contratos de bloqueo gradualmente se liberan.
Después de eso, examinamos cómo todos estos factores se suman en su totalidad: cómo moldean la economía de ejecutar un nodo validador y cómo afectan dinámicas de suministro de tokens de ParallelChain en general.
UN NUEVO DISEÑO DE CONSENSO MULTICLASE
El conjunto de validadores de tres clases de ParallelChain Mainnet tiene como objetivo un punto medio saludable entre la anonimidad y la participación libre de Bitcoin y el alto rendimiento de los permisos de blockchain como Hyperledger Fabric y ParallelChain Lab propio ParallelChain Privado.
Este logro se logra equilibrando los intereses de seguridad y descentralización utilizando el diseño de tres clases, cada una de las cuales tiene niveles diferentes de senioridad en la red. “Senioridad”, en este contexto, corresponde al poder de voto promedio ejercido por los nodos de cada clase de validador, que se utiliza para confirmar o censurar las transacciones del siguiente bloque que se está comprometiendo a la cadena. Lo más importante es que, a largo plazo, los mecanismos de gobierno democrático incorporados en el protocolo ParallelChain se convertirán en la autoridad final sobre los asuntos de las reglas y la composición de la red, incluyendo el acceso al conjunto de validadores.
La clase de validador más senior es la de los nodos Gobernadores. Esta clase tiene el menor número de nodos de las tres, pero el poder de voto de cada nodo Gobernador está diseñado para ser mayor que el de los nodos de otras clases. Los nodos Gobernadores forman el esqueleto de seguridad confiable de la red.
En el otro extremo de la escala, los validadores más jóvenes son los nodos Beta. Se han diseñado para ejercer el menor poder de voto individual, pero hay muchos más de ellos en la red. La membresía de esta clase de validador es casi anónima, lo que hace que la composición de los validadores sea más democrática.
La tercera clase de validador son los nodos Alpha. Se encuentran entre los nodos Gobernadores y Beta en términos de seguridad y anonimato.
ParallelChain luego utiliza su diseño de distribución de recompensas para regular la distribución del poder de voto entre las clases y dentro de ellas. Las recompensas están diseñadas para apuntar a un estado en el que cada clase en su conjunto tenga una parte igual del poder de voto, y donde el poder de voto de cada clase también sea igualmente compartido entre sus miembros.
Cuando se satisface, esta propiedad permite que un cuórum de dos clases pueda anular al otro restante en caso de desacuerdo.
AGENTES y REQUISITOS DE VALIDACION
En resumen, hay dos tipos de agentes involucrados en el proceso de validación de la red:
Operadores
Delegadores.
Los operadores son los agentes que controlan y operan el hardware y el software que realizan el trabajo computacional para agregar transacciones a los nuevos bloques y votar sobre la inclusión del próximo bloque.
Cada nodo tiene un solo operador.
Los delegadores son titulares de tokens que participan en el proceso de consenso al delegar su participación a un nodo, lo que aumenta la cantidad total de participación y poder de voto ejercido por ese nodo.
No hay límite en el número de delegadores. Además, las personas que actúan como operadores también pueden ser delegadores de otros nodos al mismo tiempo.
Para operar un nodo, el operador debe comprometer un número mínimo determinado de tokens ParallelChain (XPLL) en el nodo que opera. Este requisito mínimo varía según la clase de nodo de la siguiente manera:
Clase Gobernante: 2.5m XPLL tokens.
Clase Alpha: 1m XPLL tokens.
Clase Beta: 0.5m XPLL tokens.
Este diseño ha sido elegido con el fin de:
Sembrar las diferencias relativas en el poder de voto entre las clases de nodo.
Aumentar la cantidad de participación (y valor) que está en riesgo por el mal comportamiento del operador.
Crear un costo que defienda contra la creación de múltiples identidades de nodo por parte de un solo actor.
En este documento, tanto los operadores como los delegadores son considerados “validadores”.
En consecuencia, las “recompensas de validador” se refieren a las recompensas que se distribuyen para compensar a todos los agentes que participan en la validación de la red, ya sea como operadores o delegadores.
Como veremos, sin embargo, los operadores sí obtienen reclamaciones privilegiadas a las recompensas de validador, en comparación con los delegadores. Esto está diseñado para compensar a los operadores por el costo adicional, el riesgo y la responsabilidad de su papel.
Financiamiento de recompensas:
ParallelChain compensa a los validadores por su trabajo mediante una distribución de “recompensas”. Naturalmente, estos fondos tienen que venir de alguna parte. En el diseño de ParallelChain, las recompensas se financian completamente de dos fuentes:
• Tarifas de transacción
• Emisión de tokens
La oferta de tokens creados por estos dos procesos se determina por reglas establecidas que se han elegido para cumplir con los objetivos tokenómicos. Explicamos estas reglas a continuación.
DISEÑO DE TARIFAS DE TRANSACCIÓN
El mecanismo de tarifas de transacción de ParallelChain sigue de cerca el utilizado por Ethereum después de su reciente actualización “London Fork” (que implementó cambios detallados en la propuesta EIP 1599).
El argumento simple para recomendar esta elección es afirmar que ParallelChain se beneficiará del uso de un modelo probado y comprobado. En un espacio nuevo y experimental, la seguridad que esto proporciona no debe ser subestimada.
Sin embargo, también realizamos una revisión más profunda de las propiedades de EIP 1559 y concluimos que eran atractivas y dignas de ser replicadas. En particular, valoramos las capacidades de EIP 1559 para:
• Seleccionar transacciones según su eficiencia económica.
• Generar señales de precios que respondan a la demanda del usuario final.
• Filtrar el ruido errático de estas señales de precios.
• Facilitar expectativas de precios más precisas para los usuarios finales.
• Reducir las instancias de sobrepago por servicios por parte de los usuarios finales.
• Vincular la dinámica de precios a medidas de optimización de la red.
• Integrar los incentivos de los validadores con la creación de valor para el usuario final.
Revisamos las características clave de EIP 1559 que estamos implementando para ParallelChain a continuación:
Las solicitudes de transacción y selección:
Los usuarios que solicitan una transacción deben presentar dos valores numéricos:
i. El precio máximo por unidad de trabajo computacional que están dispuestos a pagar por su transacción solicitada.
ii. Una prima (o “propina”) que están dispuestos a pagar sobre una tarifa “base” calculada por el protocolo que se cobra en todas las transacciones incluidas en el próximo bloque (tanto la prima como la tarifa base también están preciadas en unidades de trabajo computacional).
La tarifa de transacción del usuario se calcula tomando el mínimo de:
i. La tarifa base más la prima.
ii. El precio máximo presentado.
El proceso para determinar qué transacciones se incluyen en el próximo bloque es el siguiente:
i. Si la tarifa de transacción es menor que la tarifa base, la transacción se excluye automáticamente del próximo bloque.
ii. Todas las demás solicitudes de transacción se clasifican por la magnitud de sus tarifas de transacción.
iii. Todas las solicitudes con tarifas que tienen una clasificación mayor o igual al número de posiciones disponibles en el próximo bloque, son seleccionadas (y por lo tanto, ejecutadas).
Cálculo de la tarifa base:
Los cálculos de tarifa de transacción descritos anteriormente incluyen un término de tarifa base que es calculado por sí mismo por el protocolo de la red.
Para determinar cómo se ajusta esta tarifa base, se compara el tamaño del último bloque con un tamaño de bloque objetivo asociado con un rendimiento óptimo de la cadena. Este tamaño de bloque objetivo se ha establecido en la mitad del tamaño máximo de bloque que el sistema puede manejar sin comprometer el rendimiento.
Se establece una magnitud máxima de cambio en esta tarifa base (arriba o abajo) en el 12,5%. Este valor luego se multiplica por la distancia relativa del tamaño actual del bloque por encima (+) o por debajo (-) del tamaño de bloque objetivo.
Este diseño relaciona la tarifa base con una medida objetiva de la capacidad del sistema que se equilibra contra el nivel de demanda atendida por cada bloque. Las actualizaciones de este valor están vinculadas proporcionalmente al estado actual de la red en relación con su nivel de rendimiento óptimo.
Un resultado importante de este diseño es suavizar los movimientos de precios, lo que evita que los usuarios enfrenten aumentos de precios erráticos.
Al mismo tiempo, si la demanda es alta y sostenida, esto finalmente se transmite al proceso de fijación de precios. Cuando esto ocurre, las tarifas base más altas ayudan a los usuarios a evitar pagar de más o ser excluidos de los bloques que resultan arbitrariamente de los movimientos de precios erráticos (lo cual crea una experiencia recurrente para el usuario final).
Burning:
La principal diferencia entre EIP 1559 y el modelo de tarifa de transacción de ParallelChain no se encuentra en la forma en que se calculan las tarifas, sino en cómo se utilizan.
Ethereum ha decidido que la tarifa base debe quemarse incondicionalmente, en cada bloque producido. Puede haber razones para recomendar esta elección específica para su caso, pero no creemos que sea adecuado para nosotros.
Las tarifas base representan una gran cantidad de valor que se ha generado del uso del servicio final. Quemarlas redistribuye este valor de manera difusa, de manera indiferenciada entre todos los titulares de ETH. Alternativamente, se podrían utilizar estos fondos para:
• Motivar a los mejores operadores a unirse a la red.
• Proporcionar fondos que ayuden a los operadores existentes a invertir en mejoras en el equipo.
• Financiar mejoras en ParallelChain en sí mismo.
El costo oportuno de renunciar a estas acciones a favor de una redistribución de valor difusa es demasiado grande para cualquier nueva cadena de bloques emergente. Es por eso que estamos tomando un enfoque diferente.
En las transacciones de ParallelChain, los flujos de tarifas servirán para dos usos generales:
• Financiamiento del Tesoro: el 20% del volumen de tarifas de transacción se recolectará por el Tesoro para financiar mejoras futuras en la red.
• Financiamiento de recompensa: el 80% restante se usa para financiar parte del fondo de recompensas disponible para los validadores.
Creemos que es valioso crear un mecanismo de quema para regular la presión inflacionaria, pero esto opera más abajo en nuestro diseño y, críticamente, está sujeto al rendimiento del operador.
El efecto de este enfoque es que enviamos un mensaje a los operadores diciendo: “Mira, no quemaremos una gran parte de tus tarifas como Ethereum — ¡pero todavía tienes que rendir para ganar la parte completa!”. De esta manera, el mecanismo de quema de nuestro diseño funciona como un instrumento de incentivación y como un mecanismo de redistribución de valor amplio.
El mecanismo de quema se explicará con más detalle más adelante, en la sección que explica cómo se calculan y distribuyen las recompensas.
DISEÑO DE EMISIÓN DE TOKENS:
Financiar incentivos positivos con emisión es una característica común en los protocolos de capa 1. El enfoque suele encontrar justificación teórica al apelar a alguna variación del argumento de la industria infantil o como una forma de internalizar las contribuciones de efecto de red más altas realizadas por los primeros adopteros.
Bitcoin estableció el precedente ejemplar para un sistema de recompensas impulsado por la emisión. Su diseño determinista de emisión crea certeza a largo plazo sobre la oferta de tokens y limita esta oferta en un límite superior terminal.
Estamos de acuerdo con la estructura general de este enfoque, pero diferimos en la opinión de que debería haber una oferta terminal fija.
Creemos que es mejor tener una tasa de emisión baja y fija a largo plazo. Esto ayuda a mantener el flujo de transacciones y evita que los agentes abandonen el sistema. De lo contrario, esos podrían arriesgar un espiral descendente de depreciación del valor.
Otra característica de este diseño que vale la pena mencionar es que es agnóstica a los niveles de estackeo en la red. Eso es dado que Bitcoin utiliza pruebas de trabajo para llegar a un consenso, pero otros protocolos DPoS de capa 1 han elegido vincular sus tasas de emisión a los niveles de estackeo (por ejemplo, Avalanche, Cosmos).
Hemos decidido no seguir ese enfoque y mantener los niveles de estackeo independientes y administrados “por el mercado”.
En resumen, hemos optado por un horario de tasa de emisión determinista y decreciente que se nivela en una tasa baja y fija a largo plazo, que es agnóstica a los niveles de estackeo de la red.
Solana ha propuesto una elegante parametrización para este estilo de diseño de emisión, que hemos elegido seguir. Está definido por:
• Una tasa de emisión inicial del 8,0% anual
• Una tasa anual de reducción del 15,0% anual
• Una tasa de emisión a largo plazo del 1,5% anual
Dado los valores de los parámetros mostrados, la tasa de emisión disminuye para alcanzar la tasa de emisión a largo plazo en poco más de 10 años.
La curva de tasa de emisión programada.
Para determinar la emisión acuñada para cada bloque, el protocolo llama a una función que lee el tiempo transcurrido desde el lanzamiento de Mainnet. Esto devuelve la tasa de emisión que se aplica para ese bloque.
Aunque la tasa es determinista, el volumen real de tokens acuñados no se puede determinar de antemano, ya que la base de tokens utilizada en el cálculo está afectada por los comportamientos no deterministas de los agentes en la red, lo que puede desencadenar quemas de tokens (se discute en la sección de distribución de recompensas a continuación).
Dicho esto, los términos vinculados al rendimiento que especificamos a continuación para la quema de tokens, nos dan confianza de que estos factores no deterministas no provocarán grandes variaciones en los volúmenes de quema. Por lo tanto, las tasas de emisión neta y los cambios en la oferta en circulación deberían ser relativamente previsibles como resultado.
La base utilizada para el cálculo de la nueva emisión será la oferta total actual (TCS).
Este concepto se define como la suma de todos los tokens que existen en la red, ya sean bloqueados por un contrato de aplazamiento o desbloqueados. Por lo tanto, en el lanzamiento de Mainnet, TCS tiene un valor de 250 millones.
Debido al proceso de emisión en sí mismo y a la quema de tokens ejercida por el protocolo, TCS evolucionará dinámicamente con el tiempo. El TCS para el bloque actual se da por el valor de TCS del bloque anterior, más la cantidad de emisión generada para ese bloque, menos la cantidad quemada para ese bloque.
Motivaciones
Los procesos de recolección de tarifas de transacción e emisión descritos anteriormente, generan un suministro de tokens que contribuyen al financiamiento de recompensas que se pagan a los validadores (operadores y delegados) en el Mainnet de ParallelChain.
La siguiente capa de diseño tokenómico a la que nos estamos enfocando, controla cómo se distribuyen estas recompensas a los validadores.
Estos temas necesitan un cuidado y atención considerable.
Tenemos que preservar el vínculo positivo entre la recepción de recompensas con las contribuciones reales que se están haciendo a la red. El diseño también tiene que estar libre de lagunas que permitirían a los operadores “engañar” y recibir la recompensa sin el trabajo correspondiente. Además, necesitamos evitar crear incentivos adversos que hagan más fácil para los operadores ganar recompensas atacando el rendimiento de otros operadores o tomando otras acciones que reducen el rendimiento y la seguridad de la red.
Estas preocupaciones anteriores son de valor esencial. Sin ellas, reducimos la eficiencia con la que este sistema realiza su trabajo o, en el peor de los casos, arriesgamos que se deshaga por completo.
También tenemos otra preocupación importante (aunque contingente) que abordar con nuestro diseño de distribución: ¿cómo regulamos o mantenemos un grado deseable de descentralización en una cadena DPoS?
Este es el problema llamado “concentración de stake”.
Se basa en la observación de que la dinámica de recompensas en algunas cadenas DPoS permite (o incluso crea una tendencia hacia) concentraciones cada vez mayores de stake entre un conjunto más pequeño de operadores.
Estos resultados erosionan la resistencia a ataques de esa red. Si el stake se concentra en menos manos, hace más fácil para estos actores conspirar juntos para controlar las entradas de libro para fines no consensuados.
ParallelChain ha optado por acomodar un grado de centralización en su diseño para mejorar el rendimiento, pero no más de lo necesario. Dentro de nuestro marco de múltiples clases, queremos que nuestro protocolo de consenso sea lo más distribuido posible. Hemos agregado elementos a nuestro modelo de distribución de recompensas diseñados para contrarrestar las concentraciones excesivas de participación.
Habiendo establecido nuestras motivaciones y preocupaciones principales, podemos presentar el esquema de nuestro modelo de distribución de recompensas con seis pasos a gran nivel:
Calcular los fondos de recompensa totales disponibles para el bloque.
Ajustar esta cantidad en función de las puntuaciones de disponibilidad global.
Calcular la recompensa disponible para cada grupo de validación.
Ajustar esta cantidad en función de la puntuación de disponibilidad del operador del grupo.
Calcular la parte de recompensa del operador del grupo.
Calcular la parte de recompensa de los delegadores del grupo.
Ahora analizaremos los detalles involucrados en cada paso, siguiendo los mismos encabezados a continuación.
Calcular los fondos de recompensa totales disponibles para el bloque
Esto se da por:
(1- porcentaje de tarifas de transacción para el tesoro) * tarifas de transacción de bloque + emisión de bloque
Ajustar esta cantidad en función de las puntuaciones de disponibilidad global
Optamos por incluir un incentivo de rendimiento global dentro del mecanismo de recompensa.
El objetivo aquí es crear condiciones en las que la cantidad que ganan los grupos de validación individuales también depende del rendimiento de los otros grupos. Esta característica crea un costo personal para los operadores que atacan a otros.
Actualmente, la disponibilidad del operador es la única medida que no podría ser negativamente manipulada por los operadores con fines de lucro. En la medida en que los operadores tienen control sobre su propia disponibilidad, aumentarla siempre beneficia la red.
Aproximadamente hablando, un operador es “altamente disponible” durante una época en particular si su firma se incluye en una gran proporción de los bloques de esa época. Lo contrario es cierto si su firma no se incluye en una gran proporción de los bloques de esa época.
Al haber seleccionado la disponibilidad como nuestra medida de rendimiento, la medida más simple de rendimiento colectivo que cumple con nuestras necesidades es la disponibilidad promedio de todos los operadores en la red durante un período definido por el protocolo que llamamos “época”. Lo llamaremos disponibilidad global.
En resumen, queremos que una disponibilidad global más baja genere una penalización en forma de recompensas reducidas para cada validador en el sistema (los delegadores también están expuestos a esta marca de descuento).
Podemos dirigir y afinar el desincentivo resultante del mal rendimiento colectivo, estableciendo un intervalo arbitrario que define el valor en el que el desincentivo comienza a aplicarse y el valor en el que las recompensas se han reducido máximamente a cero.
Matemáticamente, este factor de ajuste se calcula como:
= 1 cuando la disponibilidad global >= límite superior
= 0 cuando la disponibilidad global <= límite inferior
= 1- (disponibilidad global del bloque — límite inferior) / (límite superior — límite inferior) en otro caso
Cualquier suma de tokens que no se pase a la siguiente etapa de cálculo de recompensas, se quema.
3.Calcular la recompensa disponible para cada grupo de validadores
Introduciendo el modelo de límite y margen
La forma simple e intuitiva de determinar la parte de las recompensas restantes al final de paso 2, sería dividir estas proporcionalmente a la parte del total de la participación de ese grupo de validadores (de toda la participación en la red para ese bloque).
Sin embargo, esta aproximación no defiende contra la concentración de la participación.
Para lograr este resultado, nos hemos inspirado en el modelo de distribución de recompensas de límite y margen de Cardano.
Afortunadamente, nuestro uso de requisitos mínimos de participación de operadores para cada grupo de validadores elimina una gran cantidad de complejidad de los cálculos que Cardano implementa para su distribución de recompensas.
Eso deja una fórmula simple para calcular la parte de recompensas de un grupo dado. Es solo el mínimo de su porción real de la participación en la red, o un máximo acotado de recompensas que el grupo no puede reclamar más allá, independientemente de cuánta participación tengan.
Entonces, más formalmente:
parte de recompensas del grupo = recompensas después del paso 2 * mínimo de (porción del grupo de la participación en la red, límite del grupo)
El equipo de Cardano estableció el límite del grupo como 1 dividido por el número deseado de grupos de validadores en la red.
Lo que esto significa en la práctica, es que una vez que un grupo tiene más participación que el límite (lo que se llama “estado de sobre saturación”), ya no gana recompensas adicionales cuando más delegadores participan.
Cuando un grupo alcanza este estado, la única forma en que los operadores pueden pasar los mismos resultados a los delegadores y preservar sus ganancias al mismo tiempo que atraen más participación, es reduciendo sus costos (lo cual es difícil de hacer).
En estas circunstancias, las piscinas subutilizadas se vuelven más económicamente atractivas para la participación delegada. Esto induce a un reequilibrio de la participación que tiende hacia los niveles establecidos por el parámetro de límite.
Ajustando el Límite y el Margen a Tres Clases de Validadores:
Nuestro diseño de validadores de varias clases crea alguna complejidad que debe ser atendida.
Si aplicamos la misma estructura de límite a todos los validadores, independientemente de la clase, los nodos Gobernantes no podrán acumular el poder de voto más grande previsto por nuestro diseño.
Para evitar hacer ajustes arbitrarios al poder de voto de la inversión basado en la clase, hemos decidido calcular diferentes niveles de límite para cada clase de validador.
Recuerde que se define un objetivo de descentralización a nivel de clase. Queremos un cuórum de validadores en las otras dos clases que puedan revocar un consenso de todos los validadores pertenecientes a la otra clase restante.
Esto significa que queremos que la participación de la inversión contenida en cada clase sea del 1/3 (~33%).
Para calcular el límite que se aplicará a cada nodo en cada clase, solo necesitamos dividir el 33% por el número de nodos en esa clase.
Lo que este límite representa es la participación de la inversión total que cada nodo tendría si la inversión se distribuyera de manera máxima dentro de esa clase, cuando esa clase se distribuye de manera máxima con respecto a las otras dos clases, manteniendo el 33% de la inversión de la red.
En resumen, la participación en las recompensas reclamable por cualquier piscina de validadores será el mínimo del valor de su participación actual de la inversión de la red, y el valor de su límite que aplica la clase de su piscina.
Este modelo admite una posibilidad teórica donde todas las piscinas de validadores están perfectamente equilibradas, y por lo tanto, no pueden recompensar a la nueva inversión que desea participar en la economía de la validación.
No creemos que esto nunca se obtenga. Los factores subyacentes aleatorios siempre perturbarían este equilibrio (si alguna vez tuvo una oportunidad de llegar!).
Sin embargo, hemos incluido un factor de tolerancia que asegura que un pequeño aumento marginal en la participación siempre tiene un retorno, lo que crea un poco más de espacio para que nueva participación entre en el servicio de validación. En conjunto, esto significa que las capacidades efectivas para cada validador, según su clase son:
• Gobernando: (1 + tolerancia) * 33% / número de nodos Gobernando
• Alpha: (1 + tolerancia) * 33% / número de nodos Alpha
• Beta: (1 + tolerancia) * 33% / número de nodos Beta
El gráfico a continuación visualiza estas relaciones con la suposición de que todos los inversores en la venta de tokens de nodos ejercen su opción para convertirse en operadores de nodos. Esto significaría que en el lanzamiento de Mainnet tendríamos:
• 12 nodos Gobernando
• 30 nodos Alpha
• 65 nodos Beta
Participación en las recompensas totales vs. participación de la piscina en la participación de la red (por clase de nodo)
Un incentivo adicional para apoyar el equilibrio a nivel de clase.
Las cálculas de límite descritas anteriormente se determinan a nivel de validador individual. Se refieren al nivel actual de participación en el grupo de validadores y al nivel objetivo de participación para esa clase, pero no tienen ninguna referencia a la participación actual de la red a nivel de clase.
Por lo tanto, decidimos agregar un incentivo contingente adicional que ayuda a mantener la participación a nivel de clase cerca del valor objetivo del 33%.
Este incentivo solo actúa en las piscinas que ya están sobre saturadas con respecto a sus límites individuales, pero solo si la clase en su conjunto está sobre saturada.
Nuevamente, especificamos alguna tolerancia para la variación por encima del marcado del 33% que estamos dispuestos a permitir que el sistema tenga sin activar este desincentivo.
Al igual que antes, el efecto de este incentivo se concentra en un intervalo numérico específico que reduce máximamente las recompensas a cero si la participación de la clase está por encima de algún umbral designado.
Por lo tanto, formalmente, el factor de ajuste es:
=1 si la participación de la clase <= objetivo de la clase + tolerancia OR participación de la piscina <= límite a nivel de piscina
= 0 si la participación de la clase >= límite superior
=1 — ((participación de la clase — límite inferior)/(límite superior — límite inferior)) de lo contrario.
Cualquier cantidad de tokens que no se transfiera al siguiente paso de cálculo de recompensa, se quema.
Ajuste esta cantidad en función de la puntuación de disponibilidad del operador del pool.
Los cálculos y razonamientos a partir de este punto son más sencillos. En este paso, aplicamos un incentivo que confiere una consecuencia al rendimiento individual. Tenga en cuenta que este ajuste es aditivo sobre los ajustes anteriores realizados para el rendimiento del grupo.
La disponibilidad se eligió nuevamente debido a que otras medidas alternativas del rendimiento del sistema son propensas a la manipulación, mientras que la disponibilidad no lo es.
El cálculo aquí es simple: tome cualquier recompensa pendiente después del paso 3 y multiplique eso por la disponibilidad del pool de validadores. Cualquier cantidad de tokens que no se transfiera al siguiente paso de cálculo de recompensa, se quema.
Calcular la participación de recompensa del operador del pool.
La forma sencilla de determinar la participación del operador en las recompensas de ese pool es proporcionarla en la proporción de tokens que el propio operador ha comprometido en ese mismo pool (incluido el monto mínimo de operación).
El operador de este pool de validadores ha asumido un riesgo y responsabilidad adicional para ejecutar y mantener este nodo, y es justo que reclamen una tarifa por ello.
El diseño de ParallelChain permite a los operadores declarar una tarifa (una “margen”) que se carga sobre el monto total de tokens que tienen en su pool. Los delegadores ven esta tarifa antes de decidir a dónde delegar el stake.
La participación de recompensas que reclaman en proporción a su propia participación, se calcula realmente sobre la suma de recompensas restantes después de que se ha quitado esta tarifa de margen (como se hace para los otros delegadores a continuación).
Matemáticamente, las recompensas del operador se calculan como:
(% de margen * recompensas en 4) + (1 — % de margen) * recompensas en 4 * participación del operador en el stake del pool.
Calcular la participación de recompensas de los delegados del grupo
El cálculo final de la participación de recompensas recibida por los delegados es simple e intuitivo. Es simplemente proporcional a su participación de ese grupo de stake, en la cantidad de recompensas restantes después del paso 4 y la eliminación del margen del operador en el paso 5.
Más formalmente:
(1 — margen%) * recompensas en 4 * participación del delegado del grupo de stake
UNA ILUSTRACIÓN VISUAL DEL MECANISMO DE DISTRIBUCIÓN DE RECOMPENSAS
Para ayudar a resumir los flujos administrados por este proceso de distribución de recompensas, hemos compuesto el diagrama de flujo proporcionado a continuación. Comienza con los procesos de emisión y recolección de tarifas de transacción en la parte superior y termina con las recompensas distribuidas al operador y delegados de un grupo válido específico en la red.
Modelo de recorte:
Además de los mecanismos de financiamiento y distribución de recompensas detallados anteriormente, es necesario crear sanciones específicas que castiguen otras acciones malintencionadas en la red que no se refieren a las incentivas descritas hasta ahora.
Esto se hace mediante un mecanismo de recorte que elimina una parte de los tokens de la piscina de la parte ofensora, quitando así esos tokens del control de sus propietarios anteriores. Es crucial que este recorte también se aplique a los tokens delegados. Esto crea un incentivo para que los delegados no deleguen su poder de voto a actores malintencionados en la red.
Las condiciones de descalificación incluyen:
Firmar un bloque que “conflicta” con una cadena dada.
Que la disponibilidad individual de alguien durante una época caiga por debajo de cierto umbral.
Otras infracciones graves que el mecanismo democrático de gobierno considere castigables, incluyendo la censura de transacciones y los intentos de ataques a larga distancia.
Una pequeña proporción de tokens descalificados debido a la condición 1 se otorga al participante de la red (el “denunciante”) que proporciona la evidencia de que un operador firmó un bloque en conflicto. El resto de los tokens se queman para hacer económicamente inviable el corredor de denunciantes. Los tokens descalificados debido a las condiciones 2 y 3 se queman en su totalidad.
VENTAS DE TOKENS Y ASIGNACIONES
ParallelChain pre-minará 250 millones de tokens XPLL (el suministro total inicial de tokens) que se utilizarán para asignaciones fijas que están reservadas para usos específicos.
Estos usos se dividen en tres categorías generales:
Recaudar capital de inicio
Sembrar operadores de nodos en la red
Financiar operaciones y crecimiento futuro
Siguiendo el enfoque tomado por otras recaudaciones de proyectos DPoS, ParallelChain va a utilizar la venta de derechos de operador de nodos como un instrumento de recaudación de fondos — la Ronda de Nodos.
Más único en la oferta de ParallelChain, la Ronda de Nodos no obliga a los compradores a convertirse en operadores de nodos. Lo que se está vendiendo en cambio, es la opción de convertirse en un operador de nodo, junto con el número mínimo de tokens necesarios para hacerlo.
Si los compradores optan por no ejercer su opción de convertirse en operadores en una fecha de ejercicio establecida (actualmente establecida en 6 semanas antes del lanzamiento de Mainnet), los tokens que han comprado se asignarán a un contrato de vesting típico, que desbloquea los tokens con el tiempo.
Los términos de la Ronda de Nodos proporcionan realmente a los compradores una segunda opción incorporada, que les permite ejercer el derecho a recibir tokens de acuerdo con esos términos de bloqueo predeterminados, en cualquier momento antes de la expiración de la opción de operador. En pocas palabras, los compradores no tendrán que esperar hasta 6 semanas antes del lanzamiento de Mainnet para comenzar a recibir tokens de bloqueo, si eso es lo que desean hacer.
Específicamente, si los compradores eligen ejercer su opción de operador de nodo, asumiendo que hay un período de 6 meses entre TGE y el lanzamiento de Mainnet, esto sujeta los tokens que han comprado a períodos de bloqueo totales de:
• 18 meses para los nodos Gobernadores
• 16 meses para los nodos Alpha
• 14 meses para los nodos Beta
Por otro lado, los términos de vesting predeterminados (ya sea ejercidos temprano o predeterminados después de que expire la opción de operador) son:
• 24 meses de vesting comenzando el día 1 después de TGE, para los nodos Gobernadores
• 21 meses de vesting comenzando el día 1 después de TGE, para los nodos Alpha
• 18 meses de vesting comenzando el día 1 después de TGE, para los nodos Beta
Estas condiciones se resumen, junto con detalles adicionales, en el diagrama de flujo a continuación.
Distribución de las asignaciones como acciones del suministro total inicial.
Sin embargo, tenga en cuenta que la evolución de la oferta mostrada supone que ningún comprador de Node Round elige convertirse en operadores, y por lo tanto representa un caso límite para la oferta de tokens.
Como hemos visto, ejercer la opción de convertirse en un operador somete a los tokens de venta de nodos a términos de bloqueo más largos. Esto tiene el efecto de retrasar el horario de suministro líquido. El gráfico a continuación ilustra el resultado en el caso opuesto límite en el que todos los nodos eligen convertirse en operadores.
Emisiones de los programas de vesting que rigen cada asignación (todos los nodos activados)
Tengan en cuenta que el acantilado mostrado es poco probable que se produzca en la práctica, ya que no tenemos razones para creer que todos los nodos abandonarían sus roles al mismo tiempo, tan pronto como venzan sus períodos de bloqueo.
DINÁMICA DE LA OFERTA TOTAL INCLUYENDO EMISIONES Y QUEMADURAS
Los gráficos de emisiones anteriores solo representan una parte de la dinámica global de la oferta de tokens en la red. Como se discutió anteriormente, también existen procesos de emisión y quema que tienen impactos en la oferta total de tokens.
Estos también son procesos no deterministas, y eso significa que el impacto de la emisión y la quema en la oferta circulante solo se puede generar como una previsión provisiona.
Dado que esperamos un rendimiento de disponibilidad alto de nuestros operadores, las tasas de quema permanecen sistemáticas pero moderadas. En tales circunstancias, podemos esperar que el aumento de la oferta total sea principalmente gobernado por la tasa de emisión programada.
Este resultado de la previsión se ilustra en los gráficos a continuación para los casos de cero nodos y 100% de nodos descritos anteriormente.
La oferta circulante estimada después de la emisión y la quema (sin nodos activados)
Economía de Delegadores
Ahora que hemos descrito la financiación y distribución de incentivos de validación y explicado algunos hechos sobre la venta de tokens, tenemos todos estos hechos que necesitamos para evaluar la economía de convertirse en un validador en la red de ParallelChain. Por supuesto, la propuesta económica es diferente para los delegadores y los operadores de nodos. Entonces, examinaremos cada uno por turno, comenzando aquí con el caso del delegador.
El beneficio económico neto que reciben los delegadores se captura mediante una medida de rendimiento que reciben de sus tokens delegados.
Entonces, ¿cuáles son los principales conductores que determinan este rendimiento?
Los primeros conductores que pueden venir a la mente son los volúmenes de emisión y las tarifas de transacción recolectadas y cómo cambian con el tiempo. Esto es intuitivo de entender, ya que son los flujos de tokens generados por estos procesos los que establecen la suma total de recompensas disponibles para cada bloque.
El siguiente conductor importante para el rendimiento del delegado es el número de delegadores en la red. Cuantos más delegadores hay, menor es la porción de recompensas fijas que cada uno puede recibir.
La medida que elegimos para trabajar con este análisis se ha denominado la tasa de estackeo del delegado. Lo definimos como:
(suma de tokens estackeados — suma de estackeos mínimos de operadores) / suma de tokens desbloqueados en la red 4
En resumen, a mayor tasa de estackeo del delegado, menor es el rendimiento esperado recibido por los delegadores.
El tercer factor que determina las recompensas de los delegadores son el número de nodos en la red. La operación de nodo requiere un compromiso mínimo sustancial de estackeo y, todo lo demás igual, un mayor número de nodos requerirá tasas de delegación más altas para defender la parte de estackeo que se acredita a los delegados.5
Ilustramos los impactos de estos diversos factores en el rendimiento en los gráficos a continuación.
En el primer gráfico consideramos el caso con una tasa de estackeo de delegado del 50% y 6 nodos de Gobierno, 15 nodos Alpha y 33 nodos Beta activos en la red, y un precio de token de US$1 por XPLL.
Manteniendo estos valores constantes, el gráfico muestra los rendimientos de los delegadores a lo largo del tiempo y explora cómo varían en relación a diferentes precios de tarifas de transacción.
Rendimiento de los delegadores (en tokens) a lo largo del tiempo, representado en diferentes niveles de tarifa de transacción.
El caso de tarifa de transacción cero está incluido en este gráfico para mostrar cuál es el rendimiento “base” solo de emisión, y para proporcionar un punto de referencia para cómo los rendimientos cambian significativamente en varios niveles de precios de transacción.
Debido a la mecánica de subasta utilizada para establecer el precio final de la tarifa de transacción, no podemos estar seguros de cuáles serán estos precios. Sin embargo, esta análisis indica que si los costos de transacción están en el rango extremadamente bajo logrado en Solana (~$0.00025 por transacción), entonces la dinámica de rendimiento de los delegadores está principalmente impulsada por los niveles decrecientes de emisión generados en la red.
Alternativamente, en los casos en los que las tarifas de transacción aumentan a niveles moderados (que todavía son muy bajos según los estándares de Ethereum), el crecimiento del volumen de transacciones de la red puede eventualmente llevarlos a convertirse en el contribuyente dominante al rendimiento de los delegadores.
En este momento, examinaremos cómo la tasa de estaqueo de los delegadores afecta a los rendimientos.
Lo haremos para un caso de tarifa de transacción de $0.1, con todas las demás suposiciones permaneciendo iguales.
Rendimiento de los delegadores (en tokens) a lo largo del tiempo, representado en diferentes tasas de estaqueo de los delegadores (tx = $0.1)
Observamos cambios claros y sustanciales en el rendimiento que se ven impulsados por la tasa de participación de los delegados en la red. Sin embargo, encontramos una interacción entre los precios de transacción asumidos y la sensibilidad del rendimiento a la tasa de estaqueo de los delegados.
El gráfico a continuación traza las mismas curvas, pero esta vez para el límite de tarifa de transacción cero. Y vemos que la diferencia en el rendimiento que se ve impulsada por la tasa de estaqueo de los delegados se vuelve mucho más pequeña, con el tiempo.
Rendimiento (en fichas) del delegador en el tiempo, representado en un gráfico para diferentes tasas de staking de delegado (tx = $0)
La sensibilidad final que planeamos examinar es cómo el número de nodos afecta los rendimientos disponibles para los delegadores.
Para hacer esto, ahora representamos los rendimientos de los delegadores en tres escenarios. Uno donde el 100% de los tokens vendidos con privilegios de operador están activados, uno donde el 50% se activa y otro donde solo el 25% se activa. Mantenemos todas nuestras suposiciones anteriores, establecemos la tasa de estaqueo de los delegados en el 50% y las tarifas de transacción en $0.1/txn.
Gráfico de rendimiento (en tokens) de los delegadores a lo largo del tiempo, para diferentes números de operadores.
Observamos que las diferencias comienzan muy grandes, pero se estrechan rápidamente. La explicación detrás de esto se debe a la desbloqueo gradual de los tokens liberados por los contratos de bloqueo. Ya que esta cantidad líquida de tokens comienza pequeña, el estaqueo de operadores adicionales tiene un mayor impacto en la participación de recompensas reclamadas por los delegadores.
Sin embargo, a medida que aumenta el suministro líquido, el mínimo estaqueo de los operadores forma una participación cada vez menor del suministro líquido, por lo que el número de operadores de nodos tiene un menor impacto en la participación de estaqueo reclamable por los delegadores.
ECONOMÍA DE OPERADORES DE NODO
La economía de los operadores de nodo comparte muchos de los mismos fundamentos que impulsan los resultados para los delegadores. Esto se debe simplemente al hecho de que ambos comparten las mismas fuentes de financiamiento.
Sin embargo, la economía de los operadores sí presenta características distintivas.
La diferencia más importante es el requisito de un estaqueo mínimo sustancial para llevar a cabo el papel de operador. Esto cambia naturalmente el análisis del beneficio económico para estar enmarcado en términos de valor del nodo.
Los valores de nodo se calcularon para un horizonte de 3 años, asumiendo costos establecidos por los precios de tokens proporcionados en la Ronda de Nodos.
Luego examinamos cómo este valor se ve afectado por los cambios en otros conductores clave, uno a la vez, independientemente entre sí. Afortunadamente, este enfoque limitado todavía nos genera una rica cuenta de la economía de los operadores.
Algunos análisis preliminares nos mostraron que se puede crear una evaluación económica completa al examinar el impacto de las variaciones de solo seis factores clave:
Tipo de nodo
Precio de XPLL
Número de nodos en la red
Precio promedio de transacción
Tasa de participación de los delegados
Margen del operador
El diagrama de araña a continuación grafica el impacto relativo en el valor del nodo causado por cambios relativos en el valor de cada uno de estos factores seleccionados (alrededor de un valor de caso base elegido).
Traducción al español: Sensibilidad del ROI del operador vs. cambios relativos de factores económicos clave.
Tipo de nodo: Nodo Gobernante
Valores base del caso sensibilizados:
• Precio XPLL = $1.000/XPLL
• 6 nodos G, 15 nodos A, 33 nodos B
• Precio promedio de transacción = $0.1/txn
• Tasa promedio de staking de delegado = 50%
• Margen del operador = 5%
Las conclusiones que podemos extraer de este análisis son:
• El precio del token es el factor más importante. Representa la curva más pronunciada y los aumentos en el precio tienen un impacto positivo en el valor del nodo (como era de esperar).
• La recaudación de transacciones es el siguiente factor más importante, aunque en este gráfico parece mucho menos importante. Análisis más amplios mostraron que esta sensibilidad varía considerablemente en un rango de valores de precio de transacción plausibles. La línea se volvería mucho más pronunciada si hubiéramos asumido un precio más alto para nuestro caso base.
• Los márgenes del operador no crearán un gran impacto. Esta conclusión es robusta en un gran rango de valores base.
• Las tasas de staking de delegado más altas reducen el valor del nodo. Hay algunas suposiciones auxiliares detrás de este resultado. Estamos asumiendo que una mayor cantidad de tokens delegados diluye la participación que el operador tiene en su propia piscina (todo lo demás igual). Esto significa que el operador recibe una porción más pequeña de las recompensas asignadas a su piscina. Esperamos que las tasas de delegación en la red ParallelChain comiencen bastante altas, tal vez alrededor del 70%, y luego caigan a alrededor del 30% una vez que se creen utilidades adicionales de tokens por parte de DApps desarrollados para la cadena.
• La participación de las opciones del operador activadas tiene un impacto relativo similar al de las tasas de staking de delegado. Esto tiene algún sentido, aunque la cercanía de la pendiente de las dos curvas puede ser accidental dada todos los factores en juego.
Tenga en cuenta que el gráfico y su análisis provienen de los datos modelados para un nodo Gobernante. Sin embargo, las inferencias ofrecidas no cambian materialmente por el tipo de nodo, ya que todo el análisis se realiza en una base relativa.
Hay algo importante que agregar con respecto a las implicaciones económicas de la clase de nodo, que de otra manera podría pasar desapercibido.
Las clases de nodos no solo se distinguen por el nivel de rendimiento que ofrecen, sino por su capacidad para generar esos rendimientos en bases de capital más grandes.
Esto se deriva de la estructura de límite de recompensa que ParallelChain utiliza para evitar concentraciones excesivas de capital. Ilustremos esto con el siguiente ejemplo.
Consideremos una situación en la que un nodo Gobernante y un nodo Beta ambos generan un rendimiento anual del 5% en tokens en el capital mínimo operativo que mantienen en sus piscinas, y todos los demás tokens en sus piscinas son contribuidos por delegados. Además, supongamos que ambas piscinas están en el tamaño óptimo objetivo del diseño de incentivos de ParallelChain.
Aunque ambas piscinas estén rendiendo al 5%, la piscina Beta genera menos en términos absolutos, debido a que tiene un capital operativo más pequeño. Además, en este caso, el operador del nodo Beta no puede acumular más tokens para aumentar la base sobre la cual gana ese rendimiento del 5%. Esto se debe a que la piscina ya está en su tamaño objetivo, y el protocolo no asignará más recompensas a ella si crece más.
Esta es una importante diferencia económica entre los nodos que podría pasar desapercibida si se limita su análisis al método % de valor del operador (u otras medidas similares de tasa de valor).
Las exploraciones adicionales más allá de lo presentado aquí indican que los atractivos retornos del operador se pueden mantener para las tres clases de nodos, incluso bajo algunas suposiciones bastante moderadas sobre los precios de los tokens y las transacciones y la tasa de delegación.