O BitVM foi recentemente submetido a algum escrutínio depois que os Taproot Wizards, Tyler e Rijndael, postaram suas críticas aos requisitos de liquidez impostos ao operador de uma indexação bidirecional baseada no BitVM. Em todas as discussões recentes sobre soluções de camada dois baseadas em BitVM, eu tinha como certo que as pessoas que as discutiam e interessadas no espaço de design entendiam os requisitos de garantia/liquidez impostos pela arquitetura ao(s) operador(es). A recente discussão em torno da questão da “crise de liquidez” me mostra que eu estava incorreto sobre essa suposição e que muitas pessoas fora daquelas ativamente envolvidas no desenvolvimento do BitVM não estavam cientes dessa questão.
Antes de entrar na questão da crise de liquidez, acho importante esclarecer uma das propriedades exclusivas de uma indexação BitVM (chamada de pontes pelos desenvolvedores de altcoin). Nas pontes construídas em outras redes, os fundos retidos no próprio contrato-ponte que controla a movimentação de fundos entre redes são os usados para realmente processar os saques. No caso de uma indexação BitVM, esses fundos não estão acessíveis para realizar saques. O operador do sistema (rollup, sidechain, etc.) deve realmente administrar sua própria liquidez para processar as solicitações de saque dos usuários.
À medida que as solicitações de saque do usuário chegam, o operador que realmente move o estado de rollup analisa cada solicitação e processa essas retiradas usando seus próprios fundos pessoais. Após um período, o sistema verifica seu estado em um ponto de corte comprometendo-se com todas as retiradas pendentes. Depois do operador cumpriu todos os saques pendentes do último estado eles podem então se envolver em um processo de reivindicação dos fundos garantidos do BitVM para se tornarem inteiros por todo o capital que investiram. O contrato BitVM é estabelecido para que as operadoras possam ter sua capacidade de reivindicar esses fundos revogada caso não tenham honrado todos os saques pendentes do último estado.
Portanto, o fluxo geral do usuário é um depósito que entra em um contrato garantido pelo BitVM, a operadora fornece seu próprio capital para processar saques e, periodicamente, a operadora se compensa pelo dinheiro que gastou do próprio bolso com o contrato BitVM. Isso diferencia uma indexação BitVM de qualquer outro tipo de indexação bidirecional, introduzindo um requisito de liquidez semelhante ao da Lightning Network.
A crise de liquidez
O problema que a Taproot Wizards identificou em seu artigo é resultado da combinação dos requisitos iniciais de liquidez impostos à operadora e do esquema à prova de fraude que permite aos verificadores do BitVM revogar o acesso da operadora aos fundos caso não o tenham feito. cumpriu todas as retiradas em uma determinada época de rollup. Isto cria um grande problema potencial para o sistema e particularmente para o operador.
Por enquanto, vamos ignorar completamente o cenário potencial de um operador se recusar intencionalmente a processar um saque devido a censura maliciosa. Isso não é uma preocupação por enquanto ao olhar para os problemas potenciais, como se um operador fizesse tal coisa, eles deve terão seu acesso revogado e incorrerão na perda de todos os fundos que já gastaram no processamento de saques.
É absolutamente possível que um operador honesto se depare com uma situação em que, sem qualquer intenção maliciosa da sua parte, não tenha acesso a liquidez suficiente para processar os levantamentos pendentes numa única época de rollup. Se isso acontecer, então um operador honesto não poderá mais se compensar com o contrato BitVM pelo que ter processados sem se abrirem a um único verificador que os conteste, resultando na perda permanente do acesso aos fundos. Tudo o que gastaram processando retiradas naquela época seriam fundos perdidos que não poderiam recuperar.
Isso cria um grande risco para um operador de peg. Sem qualquer acção maliciosa, simplesmente através de limitações dos seus próprios fundos, aumento das taxas de juro nos empréstimos de fundos, apenas factores de tempo necessários para aceder aos fundos, eles podem perder uma enorme quantidade de dinheiro. Isto introduz uma grande instabilidade potencial na paridade e também levanta a questão para onde vai o dinheiro dos utilizadores no caso de um operador ser atingido por uma prova de fraude?
As opções
O importante a notar é que o destino final dos fundos depende de escolhas específicas de design feitas pelos implementadores de qualquer indexação. Há um bom grau de liberdade disponível nas escolhas de design, o destino final dos fundos após um desafio ejetar um operador tem múltiplas opções, o período após o final de uma época que um operador tem para cumprir todos os saques é configurável, nenhuma dessas coisas é definida em pedra como única forma possível de configurá-los.
Agora que entendemos o problema, vejamos algumas soluções potenciais.
Estrangulamento
Você poderia resolver o problema limitando as retiradas. Isto implicaria a criação de um limite máximo de fundos que um operador poderia ser obrigado pelo contrato a cumprir em qualquer época de rollup. Isto permitiria ao operador garantir que tinha capital suficiente para processar o montante máximo necessário. A cada período, a operadora poderia processar esse número de retiradas, passar pelo processo de reivindicação para se compensar do contrato BitVM e, na época seguinte, reciclar esse valor para cumprir a próxima onda de retiradas.
O problema com isso é que você não sabe quando ocorrerá um grande aumento nos fundos atrelados ao sistema e também não sabe quando a atividade do mercado se alinhará para incentivar uma enorme quantidade de dinheiro a querer sair do sistema. . À medida que mais fundos são atrelados, aumenta a possibilidade de um grande aumento no volume desejado para atrelar de uma só vez. Esta dinâmica leva essencialmente a uma fila cada vez maior para sair do sistema, a menos que você aumente o valor máximo de retirada por época, o que também aumenta os requisitos de liquidez para o operador.
Isto agrava a necessidade de liquidez que essas indexações têm e, essencialmente, cria um enorme atrito nas retiradas. Os swaps não resolvem o problema, pois, em última análise, prendem a liquidez das contrapartes nesta fila cada vez maior, ao contrário de outras paridades bidirecionais, onde poderiam sair praticamente imediatamente após facilitarem o swap.
Vários operadores
Tanto o BitVM 1 quanto o BitVM 2 suportam múltiplos verificadores de diferentes maneiras, permitindo que mais de um participe e seja capaz de revogar o acesso de uma operadora aos fundos. Também é possível no BitVM 2 (e em alguns pegs baseados em BitVM, como o rollup Citrea) ter vários operadores trabalhando em paralelo. Mais de uma entidade pode ajudar a processar retiradas da indexação, portanto, vários pools de liquidez estão disponíveis para facilitar a indexação.
Isto tornaria, em princípio, toda a dinâmica de liquidez muito mais escalável, uma vez que já não estaria limitada a uma única entidade que teria de enfrentar a liquidez para facilitar levantamentos atempados do sistema, mas introduziria questões de complexidade. Cada UTXO depositado na indexação BitVM e vinculado ao contrato precisa ter os termos de reivindicação definidos. Esse contrato precisa agora de ser capaz de distinguir entre vários operadores e garantir um meio de distinguir quais os levantamentos que estão associados a cada operador, e garantir que estes só podem reivindicar o que facilitaram, em vez de fundos destinados a um operador diferente.
Também precisa de ter em conta como lidar com a procura global de retiradas que todos os operadores existem para facilitar. E se cada operador tiver utilizado todo o capital que possui, mas ainda houver procura não satisfeita? Todos eles têm acesso aos fundos do BitVM revogados? Nenhum deles? Existe algum período de carência de rollover semelhante a uma limitação de fila? Se houver, quem será o responsável se essas retiradas ainda não forem facilitadas na próxima época? Todas estas são coisas que precisam de ser concretamente trabalhadas.
Vários operadores lineares
Além de ter vários operadores paralelos, você poderia ter uma cadeia de operadores lineares. Um único operador poderia funcionar por vez, facilitando saques, e se algum dia eles enfrentassem um problema de liquidez e tivessem seu acesso revogado dos fundos BitVM, os fundos após um processo de contestação/revogação poderiam ser imediatamente enviados para um novo BitVM com um novo operador. Isto não resolveria de forma alguma o risco de um único operador sofrer uma crise de liquidez, e eles perceberiam a perda de quaisquer levantamentos que já tenham depositado, mas garantiriam que outra pessoa pudesse intervir e ter a oportunidade de continuar a facilitar os levantamentos com a capacidade para reivindicar compensação do BitVM.
No entanto, isso adiciona muitos custos ao processo de fixação. Gerar uma instância BitVM não é barato em termos de dados e interatividade, o que significa que para encadear operadores BitVM lineares dessa forma, você deve gerar para peg-ins esse número de BitVMs.
A barreira
Em todos os casos de qualquer indexação usando BitVM, há uma questão final: para onde vão os fundos no pior caso de falha? Em última análise, existem duas opções. Ou você realmente queima os fundos ou os coloca sob o controle de um verificador. O primeiro significa que os fundos dos utilizadores estão agora destruídos e todos os que detêm fundos indexados estão agora em situação difícil. A segunda significa que o modelo de confiança mudou completamente para confiar num verificador individual ou num grupo de verificadores numa federação que controla unilateralmente os fundos.
Queimar os fundos é um fracasso em um modelo sem limite de retirada, pois isso validaria as preocupações do pior cenário expressadas pela Taproot Wizards. Um caso de falha consistente dos operadores, independentemente de ser paralelo ou linear, resultaria na destruição efectiva dos fundos dos utilizadores. O único modelo em que isso seria remotamente seguro seria com acelerador de retirada; mas mesmo assim, se o(s) operador(es) definido(s) no contrato desaparecessem ou tivessem o seu acesso revogado, o risco de perda permanente de fundos continuaria a existir.
Isso deixa os fundos de volta sob o controle de um único verificador ou de um grupo deles. No caso de falha total de todos os operadores, isso permitiria ao(s) verificador(es) envolvido(s) no sistema recuperar os fundos dos utilizadores e restaurá-los. Eu não acho que isso seja tão ruim.
Cada instância BitVM é configurada com um multisig n-de-n que cuida da assinatura de todas as transações pré-assinadas envolvidas no contrato BitVM. O modelo final de segurança de raiz de todo o esquema é que um único desses detentores de chaves deve permanecer honesto e recusar-se a assinar uma dispersão desonesta de fundos, para que o sistema seja seguro.
Esse mesmo modelo de segurança pode ser aplicado ao destino dos fundos (menos o(s) operador(es)) no caso de falha total do operador. Isso introduz o risco de uma única chave ser perdida ou de não cooperar, queimando fundos, então você também pode torná-la uma multisig m-of-n convencional.
Não vejo nenhum problema neste tipo de configuração, pois ela cumpre o objetivo de garantir que os fundos dos usuários não sejam irrevogavelmente queimados sem criar uma alteração selvagem no modelo de confiança. Em última análise, se você não é um participante direto do contrato BitVM, ou seja, possui uma dessas n-de-n chaves, você ainda está confiando em algum tipo de federação. Só precisar confiar em um único membro para ser honesto para manter as coisas seguras é obviamente superior a ter que confiar em 3 pessoas em um multisig 5 de 7, mas ainda é uma forma de confiança delegada.
Empacotando
No final das contas, acho que o problema da crise de liquidez identificado pela Taproot Wizards é um problema muito legítimo. Dependendo da arquitetura específica da indexação em questão, isso pode introduzir problemas desde a queima completa dos fundos dos usuários, até a perda de fundos dos operadores, mesmo sem ação maliciosa, até a simples criação de uma fila cada vez maior para sair sem interromper os depósitos ou recorrer ao grupo n-de-n para ignorar a fila.
No entanto, na minha opinião, não é algo que signifique que a ideia de usar o BitVM para garantir uma ligação bidirecional seja uma ideia fundamentalmente quebrada. Acho que expus um bom número de maneiras pelas quais implementações específicas poderiam apoiar ou mitigar o problema e, em última análise, a realidade do grupo n-de-n existente e o potencial de transferir fundos em um caso de falha para um grupo delegado para lidar com retiradas pode resolver o risco de perda permanente de fundos.
Como última observação, o ritmo de desenvolvimento neste espaço atingiu um ritmo no último ano ou mais que nunca vi no meu tempo aqui, penso que é importante, ao discutir estes desenvolvimentos, dar um passo atrás e manter a cabeça calma enquanto olhando para as discussões que ocorrem sobre trade-offs e riscos. Sim, a percepção pública é um aspecto destas conversas que acontecem em público, mas estas discussões devem estar enraizadas no objectivo de chegar a uma compreensão precisa das questões em questão. Isso não deve ser colocado em segundo plano, em vez de tentar primeiro ilícitar ou defender qualquer percepção pública específica.
Fonte: bitcoinmagazine.com
