Introducción

A medida que 2022 llega a su fin, me gustaría compartir algunos pensamientos sobre dónde estamos y hacia dónde creo que podemos ir en el nuevo año. En primer lugar, creo que estamos en una posición mucho más independiente y estable que hace unos meses. Anteriormente, me sentía como si estuviéramos retirándonos del borde de un acantilado, y cualquier ráfaga de viento podría habernos alcanzado. Ahora, siento el suelo debajo de nosotros, y es sólido... sí, nuestros bolsillos aún pueden estar vacíos y todavía estamos arruinados, pero las mareas están cambiando. Las propuestas recientes aportan directamente más fondos al fondo comunitario, mientras que otras tienen el objetivo de devolver valor a la cadena. Y, por supuesto, tenemos el grupo de Oracle. Una ganancia inesperada de los swaps del mercado de depeg que resultó ser un salvavidas para la recuperación.

¿Pero no tenemos un problema? ¿No se está acabando el tiempo en la distribución del grupo de Oracle? Bueno, algo así... pero tal vez no .

Comencemos observando cómo obtienen recompensas los delegantes y validadores.

En este momento, estamos ganando literalmente el 99 % de todas las recompensas de participación de la distribución de Oracle, el 1 % de las tarifas de gas y el 0 % de la inflación. Profundicemos ahora en la mecánica detrás de cada una de estas variables (Oracle, Gas e Inflación) y veamos que es posible que tengamos más dinero y opciones de lo que creemos.

Piscina de oráculo

La urgencia en la innovación, el desarrollo y el progreso es inherente a este campo. La naturaleza de código abierto del desarrollo permite la verificación de la corrección del código y obliga a los desarrolladores a innovar para seguir siendo competitivos. Eso es lo que me atrajo de esta tecnología, y por eso sigo desarrollándome en este espacio. Para el grupo de Oracle, un sentido diferente de urgencia ha estimulado la discusión y el desarrollo; sin embargo, la situación del grupo de Oracle puede no ser tan grave como pensamos. Una declaración común que escucho en la comunidad de LUNC es que la cadena morirá una vez que se agoten los fondos en el grupo de Oracle, y que esto se agotará en los próximos 2 años. Esta idea proviene de los parámetros del Oráculo que se muestran aquí.

# Oracle Distribution Algorithm
# totalPeriodRewards = RewardPool x (votePeriod / rewardDistributionWindow)
votePeriod = 5                       ## Every 5 blocks, distribute oracle rewards
rewardDistributionWindow = 9400000   ## 9.4M blocks, or 652 days (~1.7 years)
r = votePeriod/rewardDistributionWindow
numVotesPerDay = 14400/votePeriod

donde dist_t1 es el primer paso de tiempo, pool es el tamaño del pool de Oracle y r es la distribución porcentual calculada por,

Básicamente, cada 5 bloques (~ cada 30 segundos), se dispersa el 0,000531% del Oracle. Ahora, lo que hay que darse cuenta es que la distribución no es constante . El tamaño del grupo continúa disminuyendo cada período de votación. Por lo tanto, la distribución en el siguiente paso de tiempo calcula una dispersión de 0.000531% de un tamaño de grupo más pequeño . La distribución 5 bloques después (en t=2) será un grupo reducido efectuado por la distribución anterior en el tiempo, t=1….

o más precisamente por sustitución y algo de álgebra,

Y podemos continuar esta expansión al siguiente paso de tiempo, t=3.

Y si simplificamos esto,

Distribuya la variable del grupo ,

Y una vez más a t=4 para reconocer el patrón.

Profundiza en tus recuerdos ahora... es posible que reconozca el patrón de coeficientes de las matemáticas de la escuela secundaria. Es el patrón del triángulo de Pascal , (1,-2,1) (1,-3,3,-1), con una serie alterna… cuyos coeficientes se pueden resolver en el caso general de t=n por el teorema del Binomio .

Esta expansión de la suma de coeficientes binomiales es equivalente a la solución de forma cerrada de una expresión polinomial más simple,

Todo esto para decir que podemos calcular el monto de la distribución del grupo de Oracle en cualquier paso de tiempo/punto en el tiempo en el futuro, indicado por n .

Hagamos esto concreto y pongamos algunos números concretos. A partir del 13 de diciembre, tenemos alrededor de 272B LUNC y 935M USTC en el grupo de Oracle. Por el momento, ignoramos todo el resto del polvo (otros establos minúsculos). Si desea ver el estado actual del grupo de Oracle, puede consultar aquíhttps://finder.terra.money/classic/address/terra1jgp27m8fykex4e4jtt0l7ze8q528ux2lh4zh0f

# Starting point, Dec 13,2022
lunc = 272764796913         ## 272 B lunc, around $45M USD
ust = 935235498             ## 935 M ustc, around $23M USD
staked = 894076663267       ## 894 B lunc
totalSupply = 6872832823412 ## 6.87 T lunc

Si desea verificar esta solución, consulte el código utilizado para calcular esta distribución.

# Solve binomial equation and the analytical solution

def solveReward(t,r):
    sum1 = 0
    for i in range(t+1):
        sum1 = sum1 + ((-1)**(i))*comb(t,i)*Decimal((r**(i+1)))
    return sum1

def solveRewardAna(t,r):
    return r*(1-r)**t
# Verification of Distribution via 3 methods, numerical, binomial expansion, and closed form

r = votePeriod/rewardDistributionWindow
n = 1000
binom = lunc*solveReward(n,r)
analytic = lunc*solveRewardAna(n,r)

print(totalLuncRewards[n])    # Numerical solution
print(binom)                  # Binomial expansion
print(analytic)               # Analytic closed form solution

145010.50414723594
145010.5041472357588397052805
145010.50414724177

Ok, pero ¿qué significa esto en términos de recompensas y retornos de participación? ¿Es esto suficiente para mantener competitivos los porcentajes de rendimiento? A los efectos de estos cálculos, debemos suponer que varios factores permanecen iguales, incluido el monto apostado, el precio de intercambio de LUNC/USTC, ningún aumento en el monto del grupo de Oracle y la ausencia de capitalización.

# Assuming everything stays the same (amount staked, no increase oracle, no compound, swap LUNC UST rate, etc.)

oneYear = int(numVotesPerDay * 365)
oneYearLunc = sum(totalLuncRewards[0:oneYear])
oneYearUst = sum(totalUstRewards[0:oneYear])

###  Swap Rates
pLunc = 0.000165
pUst = 0.025
swapRate = pUst/pLunc

oneYearStake = oneYearLunc/staked
oneYearStakeUst = (oneYearLunc + (oneYearUst*swapRate))/staked
print(oneYearStake)
print(oneYearStakeUst)

0.13066713800791213
0.1985492125845048

En el año 2024–2025 , podemos esperar aproximadamente un 7,47 % de rendimientos LUNC , y en 2025–2026 las tasas caen al 4,27 % de rendimientos LUNC nuevamente debido a la disminución del grupo de Oracle y todos los demás factores permanecen iguales. ( Los intercambios de USTC no están incluidos porque serían increíblemente difíciles de predecir tan lejos). Siempre que podamos distribuir las delegaciones de manera más uniforme en el conjunto de validadores activos, esto indica que no habrá un evento de agotamiento de Oracle apocalíptico que ocurrirá dentro de dos años.

Tarifas de gas

Por lo tanto, los rendimientos se mantienen bastante competitivos años después, pero definitivamente pierden su atractivo a medida que pasa el tiempo. Podemos combatir esto abordando las otras variables en los rendimientos totales de las apuestas. Una solución es abordar las tarifas de gas en las transacciones.

Actualmente estamos promediando alrededor de 2,09 transacciones (votos que no son de Oracle) por bloque durante la semana pasada. Antes de la desvinculación en abril de 2022, la cadena de bloques promediaba entre 40 y 50 transacciones por bloque; consulte los datos aquí . El historial del gráfico indica que tampoco están contando las transacciones de Oracle. Esto nos da la sensación de que un 20x–25x en el número de transacciones sería el límite superior que cabría esperar.

Otros datos descartados de la cadena durante la semana pasada muestran alrededor de 567,000 en tarifas LUNC recaudadas, con un multiplicador de gas de 5,665. Esto calcula que aproximadamente 3,2 millones de LUNC se recaudan en tarifas de gasolina por semana, donde la mitad se envía a recompensas de participación y la otra mitad se envía al fondo comunitario. Curiosamente, el cálculo de la distribución de la tarifa de gas no coincide con la cantidad real que se destina a la piscina comunitaria. Parece que la estimación es casi 13 veces demasiado baja . Si observa feeCollectorModule , recibe mucho más que las tarifas de gas reales en depósitos adicionales de contratos inteligentes como TerraSwap, y también hay validadores (como Luna Station 88) que también envían parte de sus recompensas al fondo comunitario.

Por lo tanto, los cálculos que siguen son esencialmente un límite inferior y, en realidad, los rendimientos podrían ser mucho mayores. En este momento, nuestras tarifas de gas son unas de las más bajas de cualquier cadena de bloques; esto es un subproducto de la hiperinflación de LUNC. Elevar la tarifa del gas a algo más en línea con otras cadenas importantes (Luna v2, Juno, LTC, etc.) podría ayudar a combatir el agotamiento del grupo de Oracle. De hecho, las tarifas son tan bajas que podríamos multiplicar por 60 nuestras tarifas de gas y seguir estando por debajo de un centavo (~$0.009) para una transacción de envío básica.

Al analizar nuestro volumen actual, aproximadamente cada centavo de las tarifas de gas proporcionaría un aumento del 0,47 % en la APR (en realidad es del 0,94 %, pero recuerde que la mitad de esto se destina a la piscina comunitaria). Dado que antes del colapso, el volumen era entre 20 y 25 veces mayor de lo que es ahora, creo que un objetivo razonable sería un volumen modesto de 5 veces para fines del próximo año, especialmente después de la paridad tecnológica con Luna v2. Básicamente, lo que muestran los datos es que si somos capaces de multiplicar por cinco el número de transacciones y la comunidad decide aumentar las tarifas del gas a 0,009 por transacción, el rendimiento de las apuestas después del primer año sería del 16 % en comparación con el 13 % del Solo la distribución de Oracle, con el 50% yendo al fondo comunitario. Si el grupo está suficientemente capitalizado a través del señoreaje, podríamos desviar todas las tarifas de gas a recompensas de participación.lo que lleva a un rendimiento LUNC del 19% en el próximo año.

Inflación

Finalmente, el último término en el cálculo de las recompensas por apostar es la inflación. La inflación está en 0% en este momento y no proporciona ninguna contribución a las recompensas de participación actuales. Esto significa que no hay un porcentaje de acuñación de cada bloque como se ve en Luna v2 (la inflación anual se establece en 7%) . Esta inflación del cero por ciento ayuda a la narrativa de la quema, pero es una opción que la comunidad puede revisar en el futuro. Por ejemplo, si las recompensas de las apuestas son demasiado bajas, o si la utilidad de incorporación se vuelve más importante que la narrativa de quemar , se podría implementar una inflación modesta para que la cadena se vuelva más atractiva para construir, en lugar de gravar aún más a los usuarios y proyectos para asumir la carga de los costos.

Plan de Capitalización — Desarrollo L1

En este momento, muchas personas están abordando directamente la capitalización del grupo de Oracle, que es necesario y extremadamente importante; sin embargo, uno de los propósitos principales de este artículo es resaltar que también podemos enfocarnos en las tarifas del gas, la inflación y la descentralización del poder de voto para incentivar la delegación y atraer validadores de alta calidad. También podemos contrarrestar la disminución de las recompensas enfocándonos en aumentar la cantidad de transacciones procesadas en cada bloque y atraer la utilidad.

Y... probablemente la mejor manera de aumentar las transacciones y atraer la utilidad es lograr la paridad tecnológica con Luna v2 y el ecosistema cosmos más amplio. Aquí me gustaría esbozar dónde nos encontramos actualmente en términos del estado de la Capa 1 y ofrecer algunos pasos necesarios para la paridad.

Resumen del estado actual

Este es un resumen del estado actual de la cadena con respecto al estado L1. Estos elementos son lo que quedó de la cadena anterior, así como algunas de las mejoras realizadas en la capa L1 desde la depeg. Muchas actualizaciones principales son necesarias con una atención particular necesaria para respaldar a las diversas partes afectadas por las actualizaciones.

• SDK v0.44.5-parche + parches lunc para admitir Oracle
• Tendermint v0.34.14 + parches de Oracle
• Tamaño de nodo de archivo enorme e inestimable (> 8 tb, supongo)
• Numerosas transiciones de estado desconocidas anteriores conocidas con cambios importantes
• Actualizaciones de seguridad del contrato
• Actualizaciones especiales de tipos de SDK
• Se desconoce si se puede producir un nuevo nodo de archivo
• Wasmd v0.16.6
• Corrección del alimentador de Oracle sha256
• Herramientas acoplables mejoradas
• Parche ICS
• Canales IBC reabiertos
• Guardián de ABS (beta)
• Constitución de TC (beta)

• SDK v0.45.11 (+) con parches lunc para admitir Oracle
• Tendermint v0.34.21 (idealmente 0.37) con parches de Oracle (tenga en cuenta el cambio de prioridad tx en tendermint)
• Cosmwasm v1.0.0 (+)
• Reemplazo de LocalTerra para Classic
• Evaluar y desarrollar controladores de actualización de cosmos sdk (mapeo de versiones UpgradeHandlers)
• Crear y documentar el procedimiento de actualización (propuesta gubernamental de actualización de software)
• Evaluar e informar el efecto sobre los contratos wasm L2 en 0.16.6
• Evaluar e informar sobre la creación de un nuevo génesis (actualmente no se puede generar un nuevo génesis con un archivo json > 4 GB)
• Función de lista blanca de incubadora para exención de impuestos en cadena (idealmente propuesta de gobernanza)

• Cadena de actualización con actualizaciones de L1 anteriores (ya sea de golpe o nueva génesis)
• Coordinar con validadores, coordinar con CEX
• Utilice la propuesta de actualización de software (si es posible, o al menos constrúyalo para usarlo en el futuro)
• Identifique y contacte contratos inteligentes L2 en cadena
• Proporcionar instrucciones/documentación de migración a L2 dApps

• Crear canal IBC a Luna v2
• Evalúe la compatibilidad de LCD/FCD con v0.45.1 (+) (tenga en cuenta que mantlemint puede no funcionar)
• Proporcione acceso comunitario/público a terminales LCD y FCD (aliente a las personas a ejecutar sus propios nodos)
• Proporcione genesis.json público y addrbook.json actualizado
• Establecer y mantener el relevo entre la cadena LUNC y la cadena LUNA

Para que LUNC sea compatible con la nueva billetera TFL Interchain, todo lo anterior debe suceder más una actualización del prefijo bech32 de "terra" a "terrac". Desafortunadamente, esta es una solución de L1 muy complicada que es poco probable que suceda en los próximos meses (o años).

Dicho esto, TFL investigará e intentará resolver el problema a nivel de billetera, en lugar de confiar en el cambio a nivel de cadena de bloques. Dado que el software de TFL es de código abierto, propondría que la cadena Classic también dirija algunos recursos de desarrollo hacia la bifurcación de la billetera Interchain, desarrollando nuestra propia solución al problema bech32 a nivel de billetera y presentando múltiples soluciones a TFL. Podríamos adoptar un enfoque activo de la interoperabilidad en lugar de esperar pasivamente el apoyo externo.

En cuanto a la línea de tiempo, la respuesta corta es que "depende" de muchas cosas. Sin embargo, lo que puedo decir es que averiguar cómo/cuándo/y quién puede hacer esto es la prioridad número uno del programa de la Fundación Terra Grants que estoy ejecutando actualmente, y estamos trabajando para que esto sea una realidad.

¡Felices vacaciones!