Introdução

À medida que 2022 chega ao fim, gostaria de compartilhar alguns pensamentos sobre onde estamos e para onde acho que podemos ir no ano novo. Em primeiro lugar, acho que estamos em uma posição muito mais independente e estável do que há alguns meses. Anteriormente, eu sentia como se estivéssemos nos recuperando da beira de um penhasco, e qualquer rajada de vento poderia ter nos levado. Agora, sinto o chão abaixo de nós, e é sólido... sim, nossos bolsos ainda podem estar vazios e ainda estamos falidos, mas as marés estão mudando. Propostas recentes trazem diretamente mais fundos para o pool da comunidade, enquanto outras têm o objetivo de trazer valor de volta para a cadeia. E, claro, temos o pool Oracle. Um ganho inesperado dos swaps do mercado de depeg que acabou sendo um salva-vidas para a recuperação.

Mas não temos um problema? O tempo não está se esgotando na distribuição do pool Oracle? Bem, mais ou menos... mas talvez não .

Vamos começar observando como os delegadores e validadores ganham recompensas.

Neste momento, estamos literalmente ganhando 99% de todas as recompensas de apostas da distribuição da Oracle, 1% das taxas de gás e 0% da inflação. Vamos agora nos aprofundar na mecânica por trás de cada uma dessas variáveis ​​(Oráculo, Gás e Inflação) e ver que podemos ter realmente mais dinheiro e opções do que imaginamos.

Conjunto Oracle

A urgência em inovação, desenvolvimento e progresso é inerente a este campo. A natureza de desenvolvimento de código aberto permite a verificação da exatidão do código e força os desenvolvedores a inovar para se manterem competitivos. Foi isso que me atraiu nesta tecnologia e é por isso que continuo desenvolvendo neste espaço. Para o pool da Oracle, um senso diferente de urgência estimulou a discussão e o desenvolvimento; no entanto, a situação do pool Oracle pode não ser tão terrível quanto pensamos. Uma declaração comum que ouço na comunidade LUNC é que a cadeia morrerá assim que os fundos do pool do oráculo acabarem e que isso acabará nos próximos 2 anos. Essa ideia vem dos parâmetros do Oracle mostrados aqui.

# 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

onde dist_t1 é a primeira etapa de tempo, pool é o tamanho do pool Oracle e r é a distribuição percentual calculada por,

Basicamente, a cada 5 blocos (~a cada 30 segundos), 0,000531% do Oracle é disperso. Agora, a única coisa a perceber é que a distribuição não é constante . O tamanho do pool continua a diminuir a cada período de votação. Assim, a distribuição na próxima etapa de tempo está computando uma dispersão de 0,000531% de um tamanho de pool menor . A distribuição 5 blocos depois (em t=2) será um pool decrescente efetuado pela distribuição anterior no tempo, t=1….

ou mais precisamente por substituição e alguma álgebra,

E podemos continuar essa expansão para a próxima etapa de tempo, t=3.

E se simplificarmos isso,

Distribua a variável pool ,

E mais uma vez até t=4 para reconhecer o padrão.

Mergulhe fundo em suas memórias agora…. você pode reconhecer o padrão de coeficientes da matemática do ensino médio. É o padrão do triângulo de Pascal , (1,-2,1) (1,-3,3,-1), com uma série alternada… cujos coeficientes podem ser resolvidos no caso geral de t=n pelo teorema Binomial .

Essa expansão da soma dos coeficientes binomiais é equivalente à solução de forma fechada de uma expressão polinomial mais simples,

Tudo isso para dizer que podemos calcular a quantidade de distribuição do pool Oracle em qualquer intervalo de tempo/ponto no tempo no futuro, denotado por n .

Vamos tornar isso concreto e colocar alguns números concretos. Em 13 de dezembro, tínhamos cerca de 272B LUNC e 935M USTC no pool Oracle. Por enquanto, estamos ignorando todas as outras poeiras (outros estábulos minúsculos). Se você quiser ver o estado atual do oracle pool, você pode olhar aquihttps://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

Se você quiser verificar esta solução, consulte o código usado para calcular esta distribuição.

# 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, mas o que isso significa em termos de recompensas e retornos de apostas? Isso é suficiente para manter as porcentagens de rendimento competitivas? Para fins desses cálculos, precisamos assumir que vários fatores permanecem os mesmos, incluindo o valor apostado, o preço de swap de LUNC/USTC, nenhum aumento no valor do pool Oracle e nenhuma composição.

# 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

No ano de 2024–2025 , podemos esperar aproximadamente 7,47% de retornos LUNC e , em 2025–2026 , as taxas caem para 4,27% de retornos LUNC novamente, dado um pool Oracle decrescente e todos os outros fatores permanecem os mesmos. ( Swaps USTC não estão incluídos porque seriam incrivelmente difíceis de prever tão longe). Contanto que possamos distribuir as delegações de maneira mais uniforme no conjunto de validadores ativos, isso indica que não há nenhum evento de esgotamento do Oracle apocalíptico que acontecerá daqui a dois anos.

Taxas de gás

Portanto, os rendimentos permanecem bastante competitivos anos depois, mas definitivamente perdem sua atratividade com o passar do tempo. Podemos combater isso abordando as outras variáveis ​​nos retornos totais da aposta. Uma solução é lidar com as taxas de gás nas transações.

Atualmente, estamos com uma média de 2,09 transações (votos não oraculares) por bloco na semana passada. Antes do depeg em abril de 2022, o blockchain tinha uma média entre 40 e 50 transações por bloco, veja os dados aqui . O histórico do gráfico indica que eles também não estão contando as transações do oráculo. Isso nos dá a sensação de que 20x–25x no número de transações seria o limite superior que se poderia esperar.

Dados adicionais descartados da rede na semana passada mostram cerca de 567.000 em taxas LUNC coletadas, com um multiplicador de gás de 5,665. Isso calcula aproximadamente 3,2 milhões de LUNC coletados em taxas de gás por semana, onde metade está sendo enviada para recompensas de apostas e metade está sendo enviada para o pool da comunidade. Curiosamente, o cálculo da distribuição da taxa de gás não corresponde ao valor real que vai para o pool comunitário. Parece que a estimativa é quase 13x muito baixa . Se você observar o feeCollectorModule , ele recebe muito mais do que as taxas reais de gás em depósitos adicionais de contratos inteligentes como o TerraSwap, e também existem validadores (como o Luna Station 88) que também enviam parte de suas recompensas para o pool da comunidade.

Assim, os cálculos a seguir são essencialmente um limite inferior e, na realidade, os retornos podem ser muito maiores. No momento, nossas taxas de gás são uma das mais baixas de qualquer blockchain; este é um subproduto da hiperinflação de LUNC. Aumentar a taxa de gás para algo mais alinhado com outras grandes cadeias (Luna v2, Juno, LTC, etc.) pode ajudar a combater o esgotamento do pool da Oracle. Na verdade, as taxas são tão baixas que poderíamos 60x nossas taxas de gás e ainda assim ficar com menos de um centavo (~$0,009) para uma transação básica de envio.

Analisando nosso volume atual, aproximadamente cada centavo de taxas de gás forneceria um aumento de 0,47% na APR (na verdade, é de 0,94%, mas lembre-se de que metade disso vai para o pool da comunidade). Dado que antes do crash, o volume era 20–25x maior do que é agora, acho que uma meta razoável seria um modesto 5x no volume até o final do próximo ano, especialmente após a paridade tecnológica com o Luna v2. Basicamente, o que os dados mostram é que, se conseguirmos 5x o número de transações e a comunidade decidir aumentar as taxas de gás para 0,009 por transação, o rendimento da aposta após o primeiro ano seria de 16%, contra 13% do Somente distribuição da Oracle, com 50% indo para o pool da comunidade. Se o pool for suficientemente capitalizado por meio de senhoriagem, poderíamos desviar todas as taxas de gás para recompensas de apostaslevando a um rendimento LUNC de 19% no próximo ano.

Inflação

Finalmente, o último termo no cálculo das recompensas de apostas é a inflação. A inflação está em 0% agora e não fornece nenhuma contribuição para as recompensas de apostas atuais. Isso significa que não há porcentagem de cunhagem de cada bloco, como se vê no Luna v2 (a inflação anual é definida como 7%) . Essa inflação de zero por cento ajuda na narrativa da queima, mas é uma opção que a comunidade pode revisitar no futuro. Por exemplo, se as recompensas de aposta se tornarem muito baixas ou se a utilidade de integração se tornar mais importante do que a narrativa de queima , uma inflação modesta pode ser aplicada para que a cadeia se torne mais atraente para construir, em vez de taxar ainda mais os usuários e projetos para arcar com o ônus do custo.

Plano de Capitalização - Desenvolvimento L1

Neste momento, muitas pessoas estão abordando diretamente a capitalização do pool da Oracle, o que é necessário e extremamente importante; no entanto, um dos principais objetivos deste artigo é destacar que também podemos focar nas taxas de gás, inflação e descentralização do poder de voto para incentivar a delegação e atrair validadores de alta qualidade. Também podemos neutralizar as recompensas decrescentes concentrando-nos no aumento do número de transações processadas a cada bloco e atraindo utilidade.

E... provavelmente a melhor maneira de aumentar as transações e atrair utilidade é alcançar a paridade tecnológica com o Luna v2 e o ecossistema cosmos mais amplo. Aqui, gostaria de descrever onde estamos atualmente em termos de status da Camada 1 e oferecer algumas etapas necessárias para a paridade.

Resumo do estado atual

Este é um resumo do estado atual da cadeia em relação ao status L1. Esses itens eram o que restava da antiga cadeia, bem como algumas das melhorias feitas na camada L1 desde o depeg. Muitas atualizações principais são necessárias com atenção especial necessária para oferecer suporte às várias partes afetadas pelas atualizações.

• SDK v0.44.5-patch + lunc patches para suportar oracle
• Tendermint v0.34.14 + patches do Oracle
• Tamanho de nó de arquivo enorme e inestimável (> 8 TB, eu acho)
• Numerosas transições de estado desconhecido anteriores conhecidas com alterações de quebra
• Atualizações de segurança do contrato
• Atualizações especiais do tipo SDK
• Desconhecido se um novo nó de arquivo pode ser produzido
• Wasmd v0.16.6
• Correção sha256 do alimentador Oracle
• Ferramentas de encaixe atualizadas
• Patch ICS
• Canais IBC reabertos
• Guarda ABS (beta)
• Constituição do TC (beta)

• SDK v0.45.11 (+) com lunc patches para suportar oracle
• Tendermint v0.34.21 (idealmente 0.37) com patches Oracle (observe a mudança de tx de prioridade no tendermint)
• Cosmowasmo v1.0.0 (+)
• Substituição LocalTerra para Clássico
• Avaliar e desenvolver manipuladores de atualização do cosmos sdk (mapeamento de versão UpgradeHandlers)
• Criar e documentar o procedimento de atualização (proposta gov de atualização de software)
• Avalie e relate o efeito nos contratos L2 wasm em 0.16.6
• Avalie e relate a criação de um novo genesis (atualmente não é possível gerar um novo genesis com arquivo json > 4 GB)
• Recurso de lista branca da incubadora para isenção de impostos on-chain (idealmente proposta de governança)

• Cadeia de atualização com atualizações acima do nível 1 (seja colisão ou nova gênese)
• Coordenar com validadores, coordenar com CEXs
• Utilizar a proposta de atualização de software (se possível, ou pelo menos construí-la para usar no futuro)
• Identifique e entre em contato com contratos inteligentes L2 na cadeia
• Fornecer instruções/documentação de migração para dApps L2

• Criar canal IBC para Luna v2
• Avalie a compatibilidade LCD/FCD com v0.45.1 (+) (Observe que o mantlemint pode não funcionar)
• Forneça acesso comunitário/público aos terminais LCD e FCD (incentive as pessoas a executarem seus próprios nós)
• Forneça genesis.json público e addrbook.json atualizado
• Estabelecer e manter a retransmissão entre a cadeia LUNC e a cadeia LUNA

Para que o LUNC seja compatível com a nova carteira TFL Interchain, todos os itens acima precisam acontecer, além de uma atualização do prefixo bech32 de “terra” para “terrac”. Infelizmente, esta é uma solução L1 muito complicada e de quebra que provavelmente não acontecerá nos próximos meses (ou anos).

Dito isto, o TFL investigará e tentará resolver o problema no nível da carteira, em vez de confiar na mudança no nível do blockchain. Como o software da TFL é todo de código aberto, eu proporia que a cadeia Classic também direcionasse alguns recursos de desenvolvimento para a carteira Interchain, desenvolvendo nossa própria solução para o problema bech32 no nível da carteira e apresentando várias soluções para a TFL. Poderíamos adotar uma abordagem ativa para a interoperabilidade em vez de esperar passivamente por suporte externo.

Quanto ao cronograma, a resposta curta é que “depende” de muitas coisas. No entanto, o que posso dizer é que descobrir como/quando/e quem pode fazer isso é a prioridade número um do programa Terra Grants Foundation que estou administrando atualmente, e estamos trabalhando para tornar isso uma realidade.

Boas festas!