Ontem à noite revolvi a carteira e só então descobri que aquele pouco de BTC que eu tinha feito staking em uma cadeia EVM recebeu, na verdade, incentivos do protocolo. Eu sempre achei que o Bitcoin só podia ficar “deitado” numa cold wallet. Seguindo os registros, encontrei o white paper do projeto Babylon e passei a noite inteira relendo as seções 4.2 “caminho de verificação” e 10.1 “governança de parâmetros”. Só então percebi que minha compreensão anterior era superficial. @BabylonLabs_io
O núcleo técnico do Babylon não é fazer o staking render; é como introduzir um estado de computação externo sem alterar os limites de verificação do Bitcoin. O terceiro capítulo do white paper esclarece: a mainchain do Bitcoin funciona como camada final de liquidação, o protocolo fora da cadeia é responsável por transformar o estado e, por fim, enviar a arbitragem com uma prova criptográfica. Foi no quarto capítulo que eu entendi de verdade o significado da tradução: o resultado da computação do protocolo externo é convertido em condições de gasto que podem ser verificadas de forma independente por um script do Bitcoin. A mainchain só “se importa” se o UTXO daquela transação atende às condições predefinidas — ela nem precisa compreender a lógica do negócio externo. O poder de arbitragem fica o tempo todo com a rede do Bitcoin. Essa é a verdadeira carta na manga da minimização de confiança.
Mas o custo dessa arquitetura está escondido no capítulo 9. Quando há reorganizações (reorgs) no Bitcoin, se as transações de staking em um bloco isolado forem revertidas, os ativos correspondentes já cunhados fora da cadeia entrarão em divergência de estado. Eu simulei na testnet as diferenças entre 6 confirmações e 30 confirmações: a primeira tem maior eficiência, mas expõe mais a reorg; a segunda tem uma margem de segurança maior, porém alonga o ciclo de espera do capital para quase cinco horas. Isso não é um bug de código — é uma extensão das leis físicas do Bitcoin. O Babylon entrega a escolha ao mecanismo de votação dos detentores definidos na governança de parâmetros da 10.1, sob o número $BABY . Em essência, é usar governança social para enfrentar probabilidades matemáticas.
Acho que essa proposta é suficientemente franca: ela não usa tecnologia chamativa para mascarar a incerteza inerente ao Bitcoin; em vez disso, quantifica a aversão a risco em forma de parâmetros para o embate da comunidade. Se no futuro o mecanismo de governança será capturado por grandes detentores, ainda é desconhecido. Mas essa arquitetura em duas camadas — punição do protocolo mais consenso social — talvez seja um caminho viável para o BTC deixar de ser gerido por custodiante e entrar num sistema financeiro mais amplo. Se fosse com você, você escolheria 6 ou 30 para as confirmações de segurança? #baby
O núcleo técnico do Babylon não é fazer o staking render; é como introduzir um estado de computação externo sem alterar os limites de verificação do Bitcoin. O terceiro capítulo do white paper esclarece: a mainchain do Bitcoin funciona como camada final de liquidação, o protocolo fora da cadeia é responsável por transformar o estado e, por fim, enviar a arbitragem com uma prova criptográfica. Foi no quarto capítulo que eu entendi de verdade o significado da tradução: o resultado da computação do protocolo externo é convertido em condições de gasto que podem ser verificadas de forma independente por um script do Bitcoin. A mainchain só “se importa” se o UTXO daquela transação atende às condições predefinidas — ela nem precisa compreender a lógica do negócio externo. O poder de arbitragem fica o tempo todo com a rede do Bitcoin. Essa é a verdadeira carta na manga da minimização de confiança.
Mas o custo dessa arquitetura está escondido no capítulo 9. Quando há reorganizações (reorgs) no Bitcoin, se as transações de staking em um bloco isolado forem revertidas, os ativos correspondentes já cunhados fora da cadeia entrarão em divergência de estado. Eu simulei na testnet as diferenças entre 6 confirmações e 30 confirmações: a primeira tem maior eficiência, mas expõe mais a reorg; a segunda tem uma margem de segurança maior, porém alonga o ciclo de espera do capital para quase cinco horas. Isso não é um bug de código — é uma extensão das leis físicas do Bitcoin. O Babylon entrega a escolha ao mecanismo de votação dos detentores definidos na governança de parâmetros da 10.1, sob o número $BABY . Em essência, é usar governança social para enfrentar probabilidades matemáticas.
Acho que essa proposta é suficientemente franca: ela não usa tecnologia chamativa para mascarar a incerteza inerente ao Bitcoin; em vez disso, quantifica a aversão a risco em forma de parâmetros para o embate da comunidade. Se no futuro o mecanismo de governança será capturado por grandes detentores, ainda é desconhecido. Mas essa arquitetura em duas camadas — punição do protocolo mais consenso social — talvez seja um caminho viável para o BTC deixar de ser gerido por custodiante e entrar num sistema financeiro mais amplo. Se fosse com você, você escolheria 6 ou 30 para as confirmações de segurança? #baby