WEB3DEV

Cover image for NEAR White Paper 6 - Economia
Lorenzo Battistela
Lorenzo Battistela

Posted on

NEAR White Paper 6 - Economia

Esse artigo é uma tradução da equipe da NEAR feita por Rodrigo Faria. Você pode encontrar o artigo original aqui.

O ecossistema que compõe a plataforma NEAR é impulsionado principalmente por forças econômicas. Essa economia cria os incentivos que permitem que os participantes se organizem sem precisar pedir permissão para conduzir as principais funções da plataforma, criando fortes desincentivos para comportamentos indesejáveis, irresponsáveis ​​ou maliciosos. Para que a plataforma seja eficaz, esses incentivos precisam existir tanto no curto quanto no longo prazo.

Fundamentalmente, a plataforma NEAR é um mercado entre participantes voluntários. Do lado da oferta, os operadores dos nós validadores e outras infraestruturas fundamentais precisam ser incentivados a fornecer esses serviços que compõem a “cloud comunitária”. Do lado da demanda, os desenvolvedores e usuários finais da plataforma que estão pagando pelo seu uso precisam ser capazes de fazê-lo de forma simples, clara e consistente de forma a ajudá-los.

Além disso, as forças econômicas também podem ser aplicadas para apoiar o ecossistema como um todo. Elas podem ser usadas ​​em um nível micro para criar novos modelos de negócios, remunerando diretamente os desenvolvedores que criarem os aplicativos mais úteis. Elas também podem ser usadas ​​em um nível macro, coordenando os esforços de um conjunto mais amplo de participantes do ecossistema que participam de tudo, desde educação até governança.

A aplicação específica de cada uma dessas forças é descrita nas seções abaixo. Começaremos comparando como cada um dos principais princípios de design do NEAR se aplicam à sua economia e pesquisando o panorama das abordagens existentes.

Princípios do design econômico do NEAR

Os princípios gerais do design doe sistema do NEAR são usados ​​para informar o seu design econômico de acordo com as seguintes interpretações:

  1. Usabilidade: Usuários finais e desenvolvedores devem ter preços previsíveis e consistentes para o seu uso da rede. Os usuários nunca devem perder dados para sempre.
  2. Escalabilidade: A plataforma deve escalar em limites economicamente justificados.
  3. Simplicidade: O projeto de cada um dos componentes do sistema deve ser o mais simples possível para atingir seu objetivo principal.
  4. Descentralização Sustentável: A barreira para a participação na plataforma como um nó de validação deve ser definida como a mais baixa possível, a fim de trazer uma ampla gama de participantes. Com o tempo, a sua participação não deve levar à riqueza e ao controle para as mãos de um pequeno grupo. As transações individuais feitas no futuro devem ser pelo menos tão seguras quanto as feitas hoje, como forma de proteção ao valor que estão modificando.

Visão geral

A economia do NEAR é otimizada para fornecer aos desenvolvedores e usuários finais a experiência mais fácil possível, ao mesmo tempo em que oferece incentivos adequados para a segurança da rede e o desenvolvimento do ecossistema.

Aqui está um resumo das principais ideias que impulsionam o sistema:

  1. Prova de participação limitada (Thresholded Proof of Stake): os operadores de nós de validação fornecem recursos de computação escassos e valiosos para a rede. Para garantir que os cálculos executados estejam corretos, eles são obrigados a "participar" (stake) com tokens NEAR, o que garante seus resultados. Se esses resultados forem imprecisos, o participante do stake _perderá seus _tokens. Este é um mecanismo fundamental para proteger a rede. O limite de participação no sistema é definido algoritmicamente no nível mais baixo possível para permitir a participação mais ampla possível de nós de validação em um determinado período de “época” (epoch) (½ de um dia).
  2. Recompensas da Época (epoch): Os operadores de nós recebem por seus serviços uma porcentagem fixa da oferta total, como uma taxa de “segurança”, de aproximadamente 4,5% ao ano. Essa taxa visa manter níveis de participação suficientes entre os stakers para proteger a rede enquanto se equilibra com outros usos do token NEAR no ecossistema.
  3. Tesouraria do protocolo: Além dos validadores, a tesouraria do protocolo recebe anualmente 0,5% da oferta total para reinvestir continuamente no desenvolvimento do ecossistema.
  4. Custos de Transação: O uso da rede consome dois tipos distintos de recursos — instantâneos e de longo prazo. Custos instantâneos são gerados por cada transação porque cada transação requer o uso tanto da própria rede quanto de alguns de seus recursos computacionais. Estes são precificados juntos como um custo "mais previsível" por transação, que é pagao em tokens NEAR.
  5. Custos de armazenamento: O armazenamento é um custo de longo prazo porque o armazenamento de dados representa um ônus contínuo para os nós da rede. Os custos de armazenamento são cobertos pela manutenção do saldo mínimo de tokens NEAR na conta ou contrato. Isso fornece um mecanismo indireto de pagamento via inflação aos validadores para manter o contrato e o estado da conta em seus nós.
  6. Inflação: a inflação é a combinação dos pagamentos aos validadores e ao tesouro do protocolo menos as taxas de transação coletadas (e algumas outras mecânicas de queima de NEAR). No geral, a inflação máxima é de 5%, que pode diminuir com o tempo, à medida que o uso da rede aumenta e mais taxas de transações são queimadas. É possível que a inflação se torne negativa (a oferta total diminui) se houver taxas suficientes sendo queimadas.
  7. Limites de escalabilidade: Em uma rede que escala sua capacidade em relação à quantidade de uso que recebe, os limites que direcionam a inclusão de capacidade adicional na rede são de natureza econômica.
  8. Limites de Segurança: Alguns limites que visam proporcionar um bom comportamento entre os participantes são definidos usando incentivos econômicos. Por exemplo, "Fisherman" (“Pescadores”) (descritos separadamente).

As justificativas para cada um desses princípios são descritas em mais detalhes nas seções a seguir.

Recursos fornecidos

Uma nuvem baseada em blockchain fornece vários recursos específicos para os aplicativos que são executados nela:

  • Computação (CPU): Este é o processamento real do computador (e a RAM imediatamente disponível) que executa o código em um contrato.
  • Largura de banda (“Rede”): é o tráfego de rede entre participantes e usuários, incluindo mensagens que enviam transações e aquelas que propagam blocos.
  • Armazenamento: Armazenamento de dados permanente na blockchain, normalmente expresso em função do espaço de armazenamento (por exemplo, kilobytes).

Blockchains existentes, como o Ethereum, consideram tudo isso em uma única taxa de transação inicial que representa uma conta separada para cada um dos recursos, mas, em última instância, cobra dos desenvolvedores ou usuários apenas uma vez em uma única taxa. Esta é uma taxa de alta volatilidade comumente denominada “gas”.

Os desenvolvedores preferem preços previsíveis para que possam orçar e fornecer preços para seus usuários finais. No NEAR, o preço dos recursos mencionados acima é um valor que é ajustado lentamente com base no uso do sistema (e sujeito ao efeito de suavização pelo particionamento, ou resharding, quando o uso cresce de forma sustentável), em vez de ser totalmente baseado em leilão. Isso significa que um desenvolvedor pode saber de forma mais previsível o custo de execução de transações ou manutenção de seu armazenamento.

Inicialmente, todos esses recursos serão precificados e pagos em termos de tokens NEAR. No futuro, eles também podem ser precificados em termos de uma denominação de moeda estável (por exemplo, um token atrelado ao dólar - $USD).

Computação e largura de banda (“gas”)

Computação (CPU) é um recurso momentâneo gasto na execução de uma transação. O custo de cada instrução de CPU é denominado em unidades “gas” e seu preço é determinado com base no preço ajustado lentamente do gas (denominado em tokens NEAR). A largura de banda geralmente é medida em bytes, mas na plataforma NEAR, ela é convertida em unidades de gas usando um coeficiente simples de sobrecarga (overhead), estimado em hardware de referência.

Cada chunk (pedaço de um bloco) recebe um limite máximo específico de gas que é determinado com base em quanto um único bloco pode “caber” quando executado no hardware de referência. O limite de bloco também pode ser ajustado pelos participantes da rede para levar em conta melhorias de desempenho ou pela decisão dos participantes em executarem em um hardware melhor. Isso é feito por meio dos processos normais de governança do sistema.

O preço atual do gas é previsível, mas não fixo. Cada bloco é ajustado da seguinte forma:

  • Se o bloco anterior estiver mais da metade cheio, o preço do gas do bloco anterior será acrescido de um valor dado pelo parâmetro chamado alpha.
  • Se o bloco anterior estiver menos da metade cheio, o preço do gas do bloco anterior será diminuído por um valor também fornecido pelo parâmetro chamado alpha.

O uso de gas pode acionar o particionamento (resharding), conforme explicado abaixo.

Armazenamento

O armazenamento é um ativo escasso de longo prazo. Para que um aplicativo ou usuários o usem, eles devem manter um saldo mínimo em sua conta que seja dimensionado linearmente com a quantidade de armazenamento que essa conta ocupa. A quantidade necessária de tokens NEAR por byte é fixa e está sujeita a alterações apenas por grandes decisões de governança (e, dadas as tendências no hardware de armazenamento e na capacidade do sistema, provavelmente será ajustado para baixo no futuro).

Por exemplo, se algum contrato consumir 10 kilobytes de armazenamento devido aos dados armazenados nele, este contrato deverá manter um saldo mínimo de 1 NEAR. Um contrato como o USDT em Ethereum precisaria manter um saldo de ~10k NEAR para cobrir o seu armazenamento atual. Isso também significa que as contas de usuários regulares precisam manter uma fração do saldo mínimo de NEAR.

Usar um saldo mínimo de NEAR na conta faz com que esse valor não seja usado para staking ou em outros aplicativos. Os validadores estão sendo pagos indiretamente por manter esse armazenamento sem ajuste de inflação e do fato de que o _staking total _é menor.

O sistema NEAR manterá o tamanho do shard balanceado, permitindo que cada nó mantenha aproximadamente a mesma quantidade de estado (que será aproximadamente o tamanho total do estado dividido pelo número de shards). À medida que o tamanho do estado do shard individual muda, a atribuição de contas e contratos aos shards pode mudar para manter esse equilíbrio.

Particionamento (Resharding)

Contas e contratos são atribuídos a um shard. Como o uso de tais contratos não é igual, o uso ou o tamanho de alguns shards pode superar em muito o uso ou o tamanho de outros shards. Para evitar isso, o NEAR usa o reparticionamento, que reequilibra os shards periodicamente com base em condições específicas. O resultado final será um conjunto de shards que devem ter uma quantidade razoável e equilibrada de transações e uso de armazenamento.

Durante cada época (½ dia), as estatísticas são acumuladas sobre como os blocos estão cheios durante essa época e outras condições relevantes. Cada contrato é examinado com base em seu uso durante a época anterior e seu armazenamento atual. Os contratos são então “agrupados” em grupos de modo que cada bucket tenha aproximadamente as mesmas características agregadas esperadas.

O sistema conhece os limites aproximados de uso de transações por shard (o "limite de gas"), bem como o armazenamento esperado por nó. Se o número de recursos usados ​​na época anterior excedeu um limite específico (por exemplo, se um grande número de blocos estiver mais da metade cheio), vários novos shards serão alocados, aumentando o número de buckets e diminuindo a média de cada um de seus esperados usos.

Adicionar novos shards também significa que haverá mais "assentos" disponíveis para validação, o que, por sua vez, traz mais validadores exclusivos para a mesa à medida que o preço por assento (em tokens NEAR) diminui. Esse cálculo é realizado uma época antes de usar esses novos shards para que os validadores tenham o tempo necessário para ressincronizar o estado necessário e outras informações de sharding.

Inflação

A inflação geral do sistema (gerada pela cunhagem/"minting" de novos tokens) é determinada pelo tamanho da recompensa da época para a execução de um nó de validação. A taxa de cunhagem de novos tokens é limitada a 5% ao ano. A taxa efetiva é calculada por época (½ dia). É calculada a partir da taxa de inflação esperada por época menos as taxas cobradas durante a época. Cada parcela das taxas capturadas pela plataforma é retirada da inflação, reduzindo assim a inflação geral do sistema à medida que seu uso aumenta. Se as taxas de uso do sistema excederem de forma confiável os tokens gerados pela inflação, ela se tornará deflacionária em geral.

Como o sistema é particionado e possui validadores ocultos cuja atribuição é desconhecida para o sistema, ele deve socializar todas as recompensas. Isso significa que a taxa de “segurança” é alocada uniformemente a todos os validadores, independentemente de quantas transações ou armazenamento seus shards processaram.

Economia dos Stakeholders

  • Validadores: Fornecem o recurso computacional e a segurança para a rede com a execução de nós de validação.
  • Desenvolvedores: Criam os aplicativos que rodam sobre a rede
  • Detentores de Tokens: Contas ou aplicativos que mantêm saldos de tokens
  • NEAR Foundation: Uma entidade independente que coordena os esforços de governança e evolução técnica dos participantes da rede.
  • Observadores Terceiros: Os observadores da blockchain que fornecem proteção extra contra fraude e mau comportamento.
  • Usuários: Usuários de aplicativos na rede que não mantêm saldos de token.

O impacto das políticas econômicas em cada um desses atores é examinado a seguir.

Recompensas dos Validadores

Como um sistema “Proof of Stake”, a plataforma NEAR é segura porque os validadores que executam os nós colocam alguns de seus tokens em jogo como uma espécie de depósito para garantir o bom comportamento e para a seleção do validador (prevenir o ataque Sybil). Caso esses validadores produzam um bloco inválido ou criem uma cadeia alternativa (por exemplo, com o objetivo de criar um gasto duplo), eles serão “cortados”, eliminando esse depósito.

Os validadores são escolhidos com base no modelo “Thresholded Proof of Stake” (Prova de participação Limitada) que usa um leilão para determinar quantos “assentos” serão alocados a cada potencial validador (determinando o número mínimo de tokens para um único assento). Este leilão foi projetado para fornecer alocação justa (oportunidades iguais) e permitir que o maior número possível de pessoas participe do processo de validação da rede para que possa alcançar uma descentralização significativa.

Um validador pode deterministicamente esperar participar do processo de validação em uma proporção que corresponda à sua proporção de participação total na rede. Um determinado validador pode se tornar um dos vários papéis possíveis:

  1. Produtor de bloco (Block Producer)
  2. Produtor de parcela de bloco (Chunk Producer)
  3. Validador oculto (Hidden validator)

Independentemente do papel atribuído ao validador, sua recompensa será proporcional à porcentagem do valor total em participação (staked) pelo validador. Isso significa que não há necessidade de agrupar a participação abaixo do mínimo necessário para se tornar um validador.

Em troca de atender à rede produzindo blocos e chunks, e fornecendo segurança e disponibilidade de dados, os validadores são recompensados a cada época ​​com um número alvo de NEAR. O valor-alvo é calculado de forma que, em base anualizada, será de 4,5% da oferta total.

Como os validadores são selecionados por época e cada um precisa fazer uma quantidade igual de trabalho para validar partes, fornecer disponibilidade de dados e produzir blocos, a recompensa é alocada a cada época e dividida proporcionalmente à participação de cada participante.

Todas as taxas de transação (menos a parte que é alocada como desconto para contratos) que são coletadas em cada época são queimadas pelo sistema. A recompensa inflacionária é paga aos validadores na mesma proporção, independentemente do número de taxas cobradas ou queimadas. Em conjunto, isso significa que a inflação de todo o sistema é reduzida em um valor proporcional ao valor das taxas pagas ao sistema e, caso as taxas de uso da rede excedam a taxa de inflação de todo o sistema, o sistema se tornará deflacionário.

Os requisitos computacionais para executar um nó de validação são projetados para serem mínimos. A maioria das operadoras deve ser capaz de fazer isso facilmente com uma máquina virtual padrão hospedada na nuvem, por exemplo, com a instância de US$ 100/mês da Amazon AWS ou uma instância n1-highcpu-4 do Google Cloud (e provavelmente com hardware ainda menos robusto). Para validadores que preveem realizar staking de grandes saldos e, portanto, que esperam participar de muitos shards simultaneamente, podem querer utilizar mais hardware (e redundância) para compensar o armazenamento extra, a largura de banda e a carga de computação de que precisarão.

Observadores Terceiros (“Validadores Ocultos” e “Fishermen”)

Uma desvantagem importante de um sistema não sofisticado de blockchain sharded é que a segurança geral do sistema é dividida, porque apenas uma parte dos validadores da rede está validando as transações de um shard específico. O NEAR emprega duas maneiras de combater esse problema: “Validadores Ocultos” e “Fishermen”.

“Validadores ocultos” são validadores selecionados no conjunto geral de validadores e designados para validar fragmentos desconhecidos de qualquer outra parte, exceto deles mesmos. Esse processo, descrito com mais detalhes em outras seções, garante que seja extremamente difícil corromper com êxito um número suficiente de nós para executar comportamentos maliciosos em um shard.

Os validadores ocultos são compensados ​​por validar e assinar a validade de chunks e blocos (blocks) como parte normal do processo de compensação do validador.

“Fishermen” são nós de observação que, sem qualquer tipo de permissão específica, detectam e relatam mau comportamento. Esses nós são sincronizados com a rede, mas não necessariamente participam do consenso e não são pagos por nenhuma atividade específica em andamento. Eles podem incluir operadores de carteiras, desenvolvedores de aplicativos ou infraestrutura de "corretoras" (exchanges). Esses nós validam partes da cadeia que são importantes para eles e, se detectarem problemas, podem sinalizar esses problemas por meio de desafios. Para evitar o “sofrimento” desses desafios, um pequeno compromisso de 10 NEAR deve ser postado com antecedência.

O sistema não oferece nenhuma recompensa por operar um nó como "Fisherman" (não há recompensa por enviar um desafio bem-sucedido). Em vez disso, os participantes que executam um nó "Fisherman" geralmente têm motivações externas para manter a segurança da rede.

Recompensas do contrato

Uma parte das taxas geradas por uma transação específica é fornecida de volta aos contratos executados durante essa transação. Esta “Recompensa do Contrato” pode ser distribuída de acordo com as regras especificadas no contrato, por exemplo, pode ser alocada a uma conta controlada pelo desenvolvedor do contrato, por investidores, por uma DAO etc.

A porcentagem de taxas que são alocadas para esta recompensa é definida como um valor mínimo em um parâmetro global do sistema, inicialmente de 30%. Os desenvolvedores sempre podem cobrar um extra fora desse mecanismo, exigindo que o usuário adicione fundos à chamada.

Isso cria um modelo de negócios para desenvolvedores que, de outra forma, não teriam uma maneira significativa de cobrar por seus aplicativos. Ter uma taxa mínima definida em nível de sistema evita uma “corrida para o fundo” (race to the bottom) que resulta em zero recompensas devido à concorrência (ou simplesmente o pagamento/“forking out” da taxa por outro desenvolvedor).

Isso tem um efeito poderoso de incentivar os desenvolvedores a criar aplicativos e contratos principais para a rede, pois eles serão ​​diretamente compensados de forma proporcional ao uso desses contratos.

Titulares de Tokens

Os detentores de tokens podem optar por não participar do processo de staking, por exemplo, porque são apenas detentores temporários, estão fornecendo liquidez em mercados de negociação (trading markets) ou simplesmente optaram por não participar. Os detentores de_ tokens_ que não participam do processo de staking e validação não recebem benefícios adicionais da operação da própria rede, embora seus tokens tenham utilidade ao suportar o armazenamento dos dados e o uso de aplicativos executados na rede.

Tesouraria do Protocolo

Para permitir o crescimento contínuo da comunidade e a evolução do protocolo, parte da inflação (10% da inflação, ou um total de 0,5% ao ano, conforme parâmetro inicial) é destinada à Tesouraria do Protocolo. No futuro, espera-se que eles sejam gerenciados pela comunidade com o objetivo de coordenar o desenvolvimento de longo prazo do ecossistema NEAR, particularmente os esforços que não se sustentarão como o desenvolvimento de protocolos futuros.

Dado o estado atual da governança descentralizada, inicialmente a tesouraria será supervisionada pela NEAR_ Foundation_. O mandato da NEAR Foundation é permitir a inovação com foco na comunidade de forma a beneficiar pessoas em todo o mundo. Embora a fundação não seja essencial para a operação da rede, que é totalmente descentralizada, ela já é capaz de suportar a evolução contínua do projeto de maneiras que outras entidades achariam difícil. Por exemplo, ela está financiando educação, eventos ou projetos de infraestrutura que beneficiam os bens comuns, mas que não têm um modelo de negócios específico e que de outra forma não seriam financiados.

A quantidade de inflação que é alocada ao Tesouro do Protocolo também atua como uma força econômica descentralizadora, uma vez que permite a redistribuição de capital de volta ao ecossistema para desenvolvedores e outros participantes que apoiam os bens comuns que, de outra forma, não teriam participação (stake) a oferecer.

Condições especiais

Condição de Slashing (corte) e Slashing progressivo

Existem dois tipos principais de comportamento malicioso possíveis na plataforma NEAR:

  1. Assinatura dupla (double signing): Assinar dois ou mais blocos diferentes na mesma "altura".
  2. Chunks inválidos (invalid chunks): Assinar um chunk com dados ou resultado computacional inválidos.

Validadores maliciosos podem assinar duas vezes porque estão tentando executar uma reorganização da cadeia com o objetivo de reverter certas transações (o que permitiria que eles realizassem um “gasto duplo”).

A assinatura dupla não maliciosa em um sistema de Proof of Stake também pode ocorrer devido a uma configuração incorreta ou a um problema no software.

Para equilibrar o risco de slashing acidental, o NEAR usa “Slashing progressivo”. É aqui que a parte do stake que é cortado é um múltiplo da quantidade de stake que exibiu o comportamento de dupla assinatura durante a época em questão. Esse múltiplo é 3, então cada participante malicioso é cortado em 3 * stake_malicioso / stake_total.

Para exemplificar uma assinatura dupla que leva ao slashing, suponha que um validador tenha 1% do total de tokens que foram colocados em stake em uma época específica. Supondo que a quantidade total de tokens em stake na época seja de 50.000.000 NEAR, esse validador tem 500.000 NEAR em jogo. Se esse validador realizar uma assinatura dupla e não houver nenhuma outra assinatura dupla, o validador perderá 3% de sua participação naquela época, então eles terão 485.000 de NEAR devolvidos a eles e 15.000 NEAR serão queimados. Se a quantidade total de stake com dupla assinatura em uma época atingir 33% (o que se torna perigoso para a rede), toda a participação de todas as partes envolvidas será reduzida.

Top comments (0)