Eu queria saber o que acontece na lacuna entre quando o lastro real de um provedor de finalidade muda e quando o protocolo admite que mudou. Então eu rastreei como o módulo de x/epoching da Babylon realmente processa uma nova delegação.
As mensagens de staking e de unstaking não são executadas imediatamente. Elas ficam em fila pelo tempo de um epoch inteiro e depois são processadas em um único lote na fronteira. Até essa fronteira ser atingida, o poder de votação de finalidade da cadeia reflete o snapshot antigo, não o atual. Um provedor de finalidade pode estar perdendo delegações em tempo real, pode estar esvaziando economicamente no meio do epoch e ainda votar com o peso que tinha antes de qualquer pessoa retirar.
Isso não é um bug. É o tradeoff de fazer a agregação de milhares de delegações lastreadas em BTC em um único settlement, em vez de processar cada uma individualmente. Mas isso significa que a segurança criptoeconômica que dá suporte a um bloco não é a que existe agora. É a segurança que existia no último checkpoint, carregada adiante com a confiança de que nada material mudou nesse intervalo.
Eu continuei comparando isso com como uma linha de crédito funciona de verdade. Seu limite não é atualizado instantaneamente quando sua renda muda. Ele é atualizado em um ciclo, e nesse meio tempo o banco está estendendo confiança com base em um número que já está um pouco errado. A Babylon faz algo semelhante com o peso do Bitcoin, só que com uma criptografia melhor envolvendo o erro.
Eu não acho que isso quebre o modelo. O unbonding rápido, aproximadamente dois dias, mantém essa janela curta em comparação com cadeias PoS típicas. Mas curto não é zero, e a parte que vale observar não é o preço do token. É o quanto essa janela de epoch aumenta conforme o conjunto de validadores escala.
$BABY @BabylonLabs_io #baby $ON $BTC
As mensagens de staking e de unstaking não são executadas imediatamente. Elas ficam em fila pelo tempo de um epoch inteiro e depois são processadas em um único lote na fronteira. Até essa fronteira ser atingida, o poder de votação de finalidade da cadeia reflete o snapshot antigo, não o atual. Um provedor de finalidade pode estar perdendo delegações em tempo real, pode estar esvaziando economicamente no meio do epoch e ainda votar com o peso que tinha antes de qualquer pessoa retirar.
Isso não é um bug. É o tradeoff de fazer a agregação de milhares de delegações lastreadas em BTC em um único settlement, em vez de processar cada uma individualmente. Mas isso significa que a segurança criptoeconômica que dá suporte a um bloco não é a que existe agora. É a segurança que existia no último checkpoint, carregada adiante com a confiança de que nada material mudou nesse intervalo.
Eu continuei comparando isso com como uma linha de crédito funciona de verdade. Seu limite não é atualizado instantaneamente quando sua renda muda. Ele é atualizado em um ciclo, e nesse meio tempo o banco está estendendo confiança com base em um número que já está um pouco errado. A Babylon faz algo semelhante com o peso do Bitcoin, só que com uma criptografia melhor envolvendo o erro.
Eu não acho que isso quebre o modelo. O unbonding rápido, aproximadamente dois dias, mantém essa janela curta em comparação com cadeias PoS típicas. Mas curto não é zero, e a parte que vale observar não é o preço do token. É o quanto essa janela de epoch aumenta conforme o conjunto de validadores escala.
$BABY @BabylonLabs_io #baby $ON $BTC