Constantemente, alguns grandes esforços e agora sair da posição 750 para o top 100 não foi uma tarefa fácil. Foi compromisso e consistência com conteúdo de qualidade. Quando eu estava na posição 750, minha mente ficou presa e eu cometi algumas entradas erradas em $BANK & $SKYAI , mas depois disso minha mente se converteu totalmente para @BabylonLabs_io .
Hoje eu estava lendo sobre o backend de staking da Babylon e encontrei algo que eu realmente não esperava.
Quanto do que parece ser um estado on-chain na verdade passa primeiro por uma infraestrutura off-chain, antes de você sequer vê-lo.
O indexer de staking, um serviço específico no conjunto de backends da Babylon, sincroniza eventos de delegação, status de provider de finalidade e parâmetros globais de staking do Bitcoin e da Babylon Genesis para o seu próprio banco de dados. A interface (frontend) e o serviço de API de staking também leem desse indexer, e não diretamente de nenhuma das cadeias, o que eu honestamente não tinha imaginado até ver isso disposto de forma clara.
Minha primeira leitura foi: ok, isso é só uma camada de cache para velocidade. Conveniente, não algo que suporte a carga.
Não exatamente. Se o indexer ficar para trás na sincronização, o que um usuário vê sobre o próprio stake começa a divergir do que é realmente verdadeiro on-chain, não importa que nada tenha se movido em nenhuma das cadeias.
Ainda assim, me incomoda um pouco como é fácil deixar isso passar.
As cadeias permanecem precisas o tempo todo. É a camada de tradução, no meio do caminho, que pode se desviar silenciosamente.
Eu não sei quantas instâncias do indexer rodam em paralelo agora, nem o quão centralizado isso está de fato hoje. Isso não é algo que a documentação geral da arquitetura detalha, e eu não vou fingir que tenho um número que eu não tenho.
A primeira vez que um staker vê um status errado porque o indexer ficou em atraso, e não porque o stake dele realmente mudou—isso muda a forma como as pessoas pensam sobre o que "on-chain" realmente significa no dia a dia?
Em quem você deveria confiar mais nos dados?
@BabylonLabs_io #baby $BABY
Hoje eu estava lendo sobre o backend de staking da Babylon e encontrei algo que eu realmente não esperava.
Quanto do que parece ser um estado on-chain na verdade passa primeiro por uma infraestrutura off-chain, antes de você sequer vê-lo.
O indexer de staking, um serviço específico no conjunto de backends da Babylon, sincroniza eventos de delegação, status de provider de finalidade e parâmetros globais de staking do Bitcoin e da Babylon Genesis para o seu próprio banco de dados. A interface (frontend) e o serviço de API de staking também leem desse indexer, e não diretamente de nenhuma das cadeias, o que eu honestamente não tinha imaginado até ver isso disposto de forma clara.
Minha primeira leitura foi: ok, isso é só uma camada de cache para velocidade. Conveniente, não algo que suporte a carga.
Não exatamente. Se o indexer ficar para trás na sincronização, o que um usuário vê sobre o próprio stake começa a divergir do que é realmente verdadeiro on-chain, não importa que nada tenha se movido em nenhuma das cadeias.
Ainda assim, me incomoda um pouco como é fácil deixar isso passar.
As cadeias permanecem precisas o tempo todo. É a camada de tradução, no meio do caminho, que pode se desviar silenciosamente.
Eu não sei quantas instâncias do indexer rodam em paralelo agora, nem o quão centralizado isso está de fato hoje. Isso não é algo que a documentação geral da arquitetura detalha, e eu não vou fingir que tenho um número que eu não tenho.
A primeira vez que um staker vê um status errado porque o indexer ficou em atraso, e não porque o stake dele realmente mudou—isso muda a forma como as pessoas pensam sobre o que "on-chain" realmente significa no dia a dia?
Em quem você deveria confiar mais nos dados?
@BabylonLabs_io #baby $BABY
Direct chain query
50%
Indexer/dashboard
25%
Both, equally
25%
Depends on timing
0%
4 Votos • Votação encerrada