Você já passou por uma situação dessas? A logística do envio mostra como “entregue/assinado”, mas você nem sequer viu o pacote. Ao checar as câmeras, o carteiro realmente deixou o pacote na porta — só que depois alguém o roubou. As informações de logística são verdadeiras do começo ao fim, mas o resultado não é o que você queria. Na blockchain também existe esse tipo de momento estranho em que “o registro está certo, mas o desfecho não”: ele está escondido em um componente mencionado de passagem no Capítulo 9 do whitepaper.
O número @BabylonLabs_io no Capítulo 9 fala sobre implantações multi-chain e menciona que, para cada cadeia conectada ao cofre, é necessário rodar um “light client (cliente leve) do Bitcoin” para verificar se o seu BTC realmente foi travado de forma correta e obediente na blockchain do Bitcoin. O light client trabalha de um jeito bem econômico — ele só sincroniza os cabeçalhos dos blocos e, com um proof de Merkle, confirma a existência de uma transação. Parece bem confiável, mas há uma vulnerabilidade raramente discutida: reorganizações de blocos (blockchain reorg).
A cadeia do Bitcoin às vezes passa por reorganizações: se faltar um bloco, historicamente o mais profundo já pode “empurrar fora” dezenas de blocos. O light client só confia nos cabeçalhos; em seus olhos existe apenas uma “cadeia mais longa”. Mas e se a sua transação de depósito no cofre tiver sido embalada exatamente em um bloco que depois foi isolado? Quando a reorganização termina, o light client percebe — o depósito some no nada. Onde está o problema? Durante aqueles minutos em que ocorreu a reorg, o collBTC na cadeia de contratos pode já ter sido cunhado. A logística “trava” que o pacote já chegou; você abre a caixa e está vazia. #baby
Na proposta do Babylon, o mecanismo de governança $BABY é justamente algo que foi colocado para lidar com casos-limite como esse: probabilidade baixíssima a ponto de virar poeira, mas que, se der ruim, explode e estoura tudo. Quantos blocos de confirmação na reorg devem ser considerados? 6 confirmações já bastam, ou é melhor ser conservador e esperar até 12? Durante a reorg, o cofre faz uma parada brusca ou continua rodando normalmente? Esses parâmetros não ficam “cravados” no código do cofre — no fim das contas, não é uma questão técnica, e sim de tolerância ao risco. Quem segura votos do BABY, na essência, está desenhando uma linha de escala para a “tolerância à incerteza” de todo o sistema.
A minimização da confiança tenta eliminar a motivação de maldade humana, mas reorg não é maldade — é lei física. O código consegue barrar pessoas ruins na porta, mas não impede que a probabilidade escorra sorrateiramente para dentro. DYOR.
O número @BabylonLabs_io no Capítulo 9 fala sobre implantações multi-chain e menciona que, para cada cadeia conectada ao cofre, é necessário rodar um “light client (cliente leve) do Bitcoin” para verificar se o seu BTC realmente foi travado de forma correta e obediente na blockchain do Bitcoin. O light client trabalha de um jeito bem econômico — ele só sincroniza os cabeçalhos dos blocos e, com um proof de Merkle, confirma a existência de uma transação. Parece bem confiável, mas há uma vulnerabilidade raramente discutida: reorganizações de blocos (blockchain reorg).
A cadeia do Bitcoin às vezes passa por reorganizações: se faltar um bloco, historicamente o mais profundo já pode “empurrar fora” dezenas de blocos. O light client só confia nos cabeçalhos; em seus olhos existe apenas uma “cadeia mais longa”. Mas e se a sua transação de depósito no cofre tiver sido embalada exatamente em um bloco que depois foi isolado? Quando a reorganização termina, o light client percebe — o depósito some no nada. Onde está o problema? Durante aqueles minutos em que ocorreu a reorg, o collBTC na cadeia de contratos pode já ter sido cunhado. A logística “trava” que o pacote já chegou; você abre a caixa e está vazia. #baby
Na proposta do Babylon, o mecanismo de governança $BABY é justamente algo que foi colocado para lidar com casos-limite como esse: probabilidade baixíssima a ponto de virar poeira, mas que, se der ruim, explode e estoura tudo. Quantos blocos de confirmação na reorg devem ser considerados? 6 confirmações já bastam, ou é melhor ser conservador e esperar até 12? Durante a reorg, o cofre faz uma parada brusca ou continua rodando normalmente? Esses parâmetros não ficam “cravados” no código do cofre — no fim das contas, não é uma questão técnica, e sim de tolerância ao risco. Quem segura votos do BABY, na essência, está desenhando uma linha de escala para a “tolerância à incerteza” de todo o sistema.
A minimização da confiança tenta eliminar a motivação de maldade humana, mas reorg não é maldade — é lei física. O código consegue barrar pessoas ruins na porta, mas não impede que a probabilidade escorra sorrateiramente para dentro. DYOR.