Preço de Flare Network

Uau, as coisas estão se movendo rápido! Não se passou nem uma semana desde o lançamento, e a conta XRP Flare já ultrapassou US$ 2,4 milhões em TVL. Esse crescimento eleva o TVL total da MoreMarkets para US$ 27,74 milhões. É incrível ver a comunidade XRP entrando no DeFi no @FlareNetworks.

Escolher a configuração errada do nó Flare pode significar a diferença de milhares de dólares se não for escolhida corretamente. Qual é a verdadeira diferença entre nós arquivados e podados? Como descobri da maneira mais difícil, existem três configurações principais que considero. Eles são: Não podada ("histórico de arquivo/completo") - > banco de dados de 5,5 TB (no Flare e crescendo) - Todos os dados para casos de uso especializados - Várias semanas para sincronizar/inicializar - ✅ Blocos de consulta CAN, recibos e logs/eventos desde a gênese - ✅ PODE consultar o estado histórico (isso significa solicitar equilíbrio / função de visualização do contrato / código do contrato / provas merkle / etc em um bloco específico no passado, desde a gênese) - ✅ PODE consultar o estado atual (ou seja, obter o poder de voto atual, saldo da conta, etc.) Podadas - Banco de dados de <1 TB (no Flare e crescendo) - A maioria dos dados para a maioria dos casos de uso - 1-2 semanas para sincronizar/inicializar - ✅ Blocos de consulta CAN, recibos e logs/eventos desde a gênese - ⚠️ O CAN consulta o estado histórico, mas apenas em intervalos de confirmação, o que significa que apenas um pequeno subconjunto do estado histórico pode ser consultado. Configurável com 'intervalo de confirmação', padrão a cada 4096 blocos. Podada + Sincronização de Estado - Banco de dados de < 100 GB (no Flare e crescendo) - Dados essenciais adequados para validadores e uso básico de RPC - Horas para sincronizar/inicializar - ❌NÃO PODE consultar blocos, recibos e logs/eventos desde a gênese. Limitado a bloquear que o nó começou a sincronizar e o parâmetro 'state-sync-min-blocks'. - ⚠️ O CAN consulta o estado histórico, mas apenas em intervalos de confirmação, mas significativamente mais restrito a blocos recentes. - ✅ PODE consultar o estado atual (ou seja, obter o poder de voto atual, saldo da conta, etc.) Portanto, para validadores ou amadores que desejam seu próprio nó RPC, um nó PORADO com STATE SYNC ENABLED é ideal. Permite a validação da rede e o envio de transações (e a leitura do estado atual da rede) com o mínimo de espaço necessário no disco rígido. Para a maioria das indexações analíticas que dependem de recibos, logs de eventos e blocos desde a gênese, um nó PORADO com STATE SYNC DISABLED é adequado. Para depuração avançada e análise profunda, recomenda-se um nó NÃO PORADO com STATE SYNC DISABLED. Agora, se ainda não está claro para você a diferença entre nós de arquivamento e nós podados (como foi para mim), deixe-me explicar ... Os nós podados não têm total liberdade para usar funções como: - eth_getBalance(endereço, bloco) - eth_getStorageAt (contrato, chave, bloco) - eth_call(contractCall, block) (ou seja, contract.getBalance({ blockNumber })) … e uma série de outras funções semelhantes. Observe como eles fornecem um bloco para consulta? Um nó de arquivamento pode fornecer qualquer número de bloco existente e recuperar os respectivos dados, como um saldo de contas, um estado de contratos ou código em um bloco específico. Os outros dois nós têm essas funções disponíveis, mas, como mencionado, o bloco consultável é limitado às tentativas confirmadas, que por padrão são a cada 4096 blocos. Portanto, há uma enorme quantidade de dados ausentes, ainda mais para nós sincronizados com o estado. Se você estiver disposto e os dados forem valiosos para você, você pode consultar os dados nesses intervalos, mas precisará calcular quais estados (blocos) estão disponíveis usando um pouco de matemática e/ou debug_getAccessibleState. Portanto, antes de criar um nó de arquivamento, saiba que a maioria das pessoas nunca precisará dele. Custa mais do que um burro voador para hospedar em servidores em nuvem e é realmente limitado ao uso em exploradores de blockchain, indexação histórica profunda de estado (conforme descrito acima) ou depuração avançada. Por exemplo, um nó removido (sem sincronização de estado) normalmente será suficiente para a maioria dos usuários que usam @SubQueryNetwork SDK do Indexador. Sinto a necessidade de reiterar: esta configuração de nó fornece todos os logs de eventos, transações, etc. Você pode, por exemplo, indexar todas as transferências de um token ERC20 já feitas por qualquer token ou todas as reivindicações de recompensas FTSO já feitas. Espero que isso esclareça a confusão de qualquer pessoa sobre a diferença entre essas configurações de nós. Eu recomendaria evitar nós de arquivamento, a menos que você certamente precise de sua funcionalidade. Sempre tente um nó removido (sem sincronização de estado) antes de um nó de arquivamento para a maioria dos propósitos de desenvolvimento/análise ou um nó removido (sincronizado com estado) para uso básico de RPC ou validadores.