Enquanto lia os materiais do “Babylon” até tarde da noite, eu só queria confirmar os limites de permissões do liquidante. No fim, fiquei cada vez mais sonolento… mas um fato acabou me deixando alerta: depósito e saque não seguem a mesma lógica de confiança.
No começo eu achava que todo o modelo de confiança do sistema do cofre era unificado. Só depois percebi que, na etapa de depósito, você precisa que muitas pessoas acenem com a cabeça; já na lógica de saque e liquidação é completamente diferente.
No lado dos depósitos, você tem que pedir. Ao construir o cofre, você precisa enviar uma solicitação de Peg-In na rede Ethereum, anexando um segredo de hash lock que só você conhece. Em seguida, você transmite na rede Bitcoin uma transação Pre-PegIn, travando o BTC em um endereço Taproot associado ao hash lock. A parte realmente chata começa agora: você precisa construir em conjunto, off-chain, o grafo de transações pré-assinadas com o Vault Provider e o AVK. Cada participante precisa assinar. Somente depois que o depositante revela o segredo do hash lock é que o cofre é ativado oficialmente.
Já saque e liquidação são outra história, com lógica totalmente diferente. O saque segue o caminho pré-assinado — quando o cofre é criado, todos os caminhos de gasto legal já são pré-assinados; uma vez gerado o cofre, ninguém consegue falsificar um novo gasto. No momento do saque, o depositante usa diretamente a chave criada na hora para transmitir a transação, sem precisar de mais ninguém.
Na liquidação, a condição de gatilho é o fator de saúde do tomador cair abaixo de 1.0. Existem caminhos com permissão e sem permissão, mas independentemente de qual você escolha, as regras já ficam “gravadas” quando o cofre é criado — não há necessidade de o liquidante pedir aprovação a ninguém.
Uma frase no documento me fez parar por um instante: “Trust is optional and removable”. Depósitos exigem participação de múltiplas partes porque o cofre ainda não foi construído, então a relação de confiança ainda está sendo construída — é necessário que o Vault Provider dirija a configuração, que o AVK assine junto, e que os Universal Challengers testemunhem. Mas assim que o cofre é estabelecido, com o grafo de transações pré-assinadas congelado, você não precisa mais depender de terceiros.
Passei a noite toda olhando as permissões do liquidante, mas acabei me envolvendo na contradição de confiança entre depósito e saque. Ainda assim, depois que entendi, achei razoável: pedir para tratar do depósito é porque a confiança ainda não foi estabelecida; não pedir para sacar/liquidar é porque a confiança já foi “travada” dentro do código. Você acha que esse design — depender de pessoas durante a fase de construção e depois depender apenas de código — é genial ou desnecessário? Conversem na seção de comentários.
#BABY $BABY @BabylonLabs_io
No começo eu achava que todo o modelo de confiança do sistema do cofre era unificado. Só depois percebi que, na etapa de depósito, você precisa que muitas pessoas acenem com a cabeça; já na lógica de saque e liquidação é completamente diferente.
No lado dos depósitos, você tem que pedir. Ao construir o cofre, você precisa enviar uma solicitação de Peg-In na rede Ethereum, anexando um segredo de hash lock que só você conhece. Em seguida, você transmite na rede Bitcoin uma transação Pre-PegIn, travando o BTC em um endereço Taproot associado ao hash lock. A parte realmente chata começa agora: você precisa construir em conjunto, off-chain, o grafo de transações pré-assinadas com o Vault Provider e o AVK. Cada participante precisa assinar. Somente depois que o depositante revela o segredo do hash lock é que o cofre é ativado oficialmente.
Já saque e liquidação são outra história, com lógica totalmente diferente. O saque segue o caminho pré-assinado — quando o cofre é criado, todos os caminhos de gasto legal já são pré-assinados; uma vez gerado o cofre, ninguém consegue falsificar um novo gasto. No momento do saque, o depositante usa diretamente a chave criada na hora para transmitir a transação, sem precisar de mais ninguém.
Na liquidação, a condição de gatilho é o fator de saúde do tomador cair abaixo de 1.0. Existem caminhos com permissão e sem permissão, mas independentemente de qual você escolha, as regras já ficam “gravadas” quando o cofre é criado — não há necessidade de o liquidante pedir aprovação a ninguém.
Uma frase no documento me fez parar por um instante: “Trust is optional and removable”. Depósitos exigem participação de múltiplas partes porque o cofre ainda não foi construído, então a relação de confiança ainda está sendo construída — é necessário que o Vault Provider dirija a configuração, que o AVK assine junto, e que os Universal Challengers testemunhem. Mas assim que o cofre é estabelecido, com o grafo de transações pré-assinadas congelado, você não precisa mais depender de terceiros.
Passei a noite toda olhando as permissões do liquidante, mas acabei me envolvendo na contradição de confiança entre depósito e saque. Ainda assim, depois que entendi, achei razoável: pedir para tratar do depósito é porque a confiança ainda não foi estabelecida; não pedir para sacar/liquidar é porque a confiança já foi “travada” dentro do código. Você acha que esse design — depender de pessoas durante a fase de construção e depois depender apenas de código — é genial ou desnecessário? Conversem na seção de comentários.
#BABY $BABY @BabylonLabs_io