Resumo:· As Pontes ZK implantam contratos inteligentes na Chain A para receberem e verificarem diretamente os cabeçalhos de bloco e as provas de conhecimento zero correspondentes da Chain B, confirmando a validade das mensagens entre cadeias. Este é o esquema de ponte mais seguro.

• As Pontes Optimistas/OP utilizam provas de fraude para contestar mensagens inválidas entre cadeias na cadeia. A presença de apenas um desafiante confiável pode garantir a segurança do pool de fundos da ponte entre cadeias.
• Devido a limitações técnicas, a mainnet do Bitcoin não pode implantar pontes ZK diretamente, mas pode alcançar pontes otimistas através de BitVM e provas de fraude. Equipas como Bitlayer e Citrea adotaram o esquema de ponte BitVM, introduzindo pré-assinatura e incorporando conceitos de canal, permitindo aos utilizadores predefinir o processo de tratamento após a execução do depósito, evitando que a ponte cross-chain aproprie indevidamente os depósitos dos utilizadores.
• A ponte BitVM opera essencialmente num modelo de “pagamento antecipado-reembolso”, com nodos Operadores específicos a disponibilizar fundos aos utilizadores de levantamentos. Os Operadores podem periodicamente solicitar reembolso a partir de um endereço de depósito público. Se um Operador submeter uma aplicação de reembolso falsa, pode ser contestado e reduzido por qualquer pessoa.
• Embora teoricamente segura, a ponte BitVM tem problemas com vivacidade/usabilidade e não atende às necessidades específicas dos usuários para independência de fundos e combate à lavagem de dinheiro (pois usa essencialmente um modelo de pool de fundos). O Bitlayer resolve isso com uma solução de ponte OP-DLC. Esta solução, semelhante à DLC.link, introduz provas de fraude com base em canais e DLCs para evitar má conduta da oracle.
• Dada a dificuldade de implementar o BitVM e as provas de fraude, as pontes DLC serão implementadas primeiro como um substituto temporário. Desde que os riscos de confiança dos oráculos sejam resolvidos e oráculos de terceiros mais confiáveis e maduros sejam integrados, as pontes DLC podem tornar-se um esquema de verificação de retirada mais seguro do que as pontes multi-assinatura na fase atual.

Introdução: Desde a loucura da inscrição no ano passado, o ecossistema Bitcoin entrou num período de crescimento rápido. Em apenas meio ano, o número de projetos sob a bandeira do BTC Camada 2 atingiu quase 100. Simplesmente tornou-se um novo continente repleto de caos, onde as oportunidades e os golpes coexistem. Não é exagero dizer que o atual ecossistema Bitcoin já é um “caldeirão multiétnico” de Ethereum, Cosmos e Celestia, CKB e o ecossistema nativo do Bitcoin. Aliado à falta de vozes autoritárias, o ecossistema Bitcoin é simplesmente como o do século XIX. Assim como os Estados Unidos, tornou-se um novo mundo que atrai forças de todos os setores. Embora isso traga prosperidade e vitalidade a toda a narrativa Web3, também introduz enormes riscos.

Muitos projetos começaram a fazer hype sem mesmo lançar soluções técnicas, usando o nome da camada 2 nativa, alegando que podem herdar completamente a segurança da rede principal do Bitcoin; alguns até usam técnicas de propaganda para criar conceitos, inventando uma série de substantivos e termos estranhos como linhas para promover sua própria superioridade. Embora o exagero já seja o estado atual do ecossistema do Bitcoin, ainda há muitos KOLs de topo que fizeram chamadas objetivas.

Não há muito tempo, Monanaut, o fundador do navegador blockchain Mempool, criticou publicamente os problemas atuais do ecossistema do Bitcoin. Ele apontou de forma incisiva que se uma Camada 2 do Bitcoin simplesmente usa uma ponte de retirada de multi-assinatura e não permite que os usuários retirem ativos a qualquer momento de forma confiável, tal projeto não é uma verdadeira Camada 2. Curiosamente, Vitalik já apontou anteriormente que a Camada 2 deve ser pelo menos mais segura em termos de segurança do que sistemas que dependem exclusivamente de multi-assinaturas.

Pode-se dizer que Monanaut e Vitalik apontaram diretamente os problemas técnicos da Camada 2 do Bitcoin: Muitas pontes de retirada da L2 são essencialmente pontes de multi-assinatura. Ou várias instituições bem conhecidas detêm cada uma uma chave, ou é usada uma assinatura descentralizada baseada em POS, mas, em qualquer caso, o seu modelo de segurança é baseado na suposição de honestidade da maioria, ou seja, pressupõe-se que a maioria dos participantes da multi-assinatura não esteja a conluir para fazer o mal.

Este tipo de solução de ponte de retirada que depende fortemente da garantia de crédito, de forma alguma é uma solução a longo prazo. A história nos disse que as pontes de múltiplas assinaturas terão vários problemas mais cedo ou mais tarde. Apenas a confiança é minimizada ou a custódia de ativos tende a ser completamente sem confiança. Apenas desta forma pode resistir ao teste do tempo e dos hackers. Mas a situação atual do ecossistema do Bitcoin é que Muitas partes do projeto nem sequer lançaram um roadmap técnico para a ponte de retirada. Não há uma ideia de design estabelecida de como a ponte deve ser confiável ou minimizada.

Mas isso não é tudo no ecossistema Bitcoin. Ainda há alguns gestores de projeto que expressaram suas opiniões sobre as ideias de otimização da ponte de retirada. no texto, vamos analisar brevemente a Bitlayer e a ponte BitVM da Citrea, e apresentar a ponte OP-DLC proposta pela Bitlayer para resolver as deficiências da ponte BitVM, para que mais pessoas possam compreender os riscos e as ideias de design das pontes entre blockchains. Isso é crucial para a maioria dos participantes do ecossistema Bitcoin.

Ponte otimista: Um esquema de verificação de ponte baseado em prova de fraude

Na verdade, a essência da ponte cruzada é muito simples, que é provar à cadeia B que um certo evento ocorreu na cadeia A. Por exemplo, se você cruzar ativos do ETH para o Polygon, você precisa da ponte cruzada para ajudá-lo a provar que você de fato transferiu ativos para um endereço específico na cadeia ETH, e então você pode receber a mesma quantia de fundos na cadeia Polygon.

As pontes tradicionais de cross-chain geralmente usam testemunhas de multi-assinatura. Eles designarão várias testemunhas sob a cadeia. As testemunhas executarão os nós de cada cadeia pública e monitorizarão se alguém depositou fundos no endereço de pagamento da ponte cross-chain.

O modelo de segurança deste tipo de ponte inter-cadeias é basicamente o mesmo que o das carteiras multi-assinatura. O modelo de confiança deve ser determinado de acordo com o método de configuração multi-assinatura, como M/N, mas no final, basicamente segue a suposição da maioria honesta, o que significa que a maioria dos notários, por padrão, não são maliciosos e a taxa de tolerância a falhas é relativamente limitada. Muitos casos de roubo em pontes inter-cadeias em larga escala que ocorreram antes basicamente ocorreram neste tipo de pontes multi-assinatura, seja por roubo ou por hackers.

Em contraste, a “Ponte Optimista” baseada no protocolo de prova de fraude e a “Ponte ZK” baseada em ZK são muito mais seguras. Tomando a Ponte ZK como exemplo, ela irá estabelecer um contrato validador dedicado na cadeia de destino para verificar diretamente o certificado de retirada na cadeia, eliminando a necessidade de depender de testemunhas off-chain.

Por exemplo, uma ponte ZK que abrange ETH e Polygon irá implantar um contrato verificador na Polygon, vamos chamá-lo de Verificador por enquanto. O nó Relayer da Ponte ZK encaminhará o cabeçalho do bloco Ethereum mais recente e a Prova ZK que prova a validade para o Verificador, que irá verificá-lo. Isso é equivalente a ter o contrato Verificador sincronizado na cadeia Polygon e verificar o cabeçalho do bloco Ethereum mais recente. A raiz de Merkle registrada no cabeçalho do bloco está relacionada ao conjunto de transações contidas no bloco e pode ser usada para verificar se uma determinada transação está incluída no bloco.

Se o bloco Ethereum com altura do bloco 101 contiver 10 declarações de transferência entre cadeias de ETH para Polygon, o Relayer irá gerar a Prova de Merkle relacionada com essas 10 transações e submeter a prova ao contrato Verificador na cadeia Polygon:

O bloco No. 101 do Ethereum contém 10 transações entre cadeias da ETH para a Polygon. Claro, a ponte ZK pode converter a Prova de Merkle em ZK e enviar diretamente a Prova ZK ao contrato Verifier. Durante todo este processo, os utilizadores apenas precisam de confiar que o contrato inteligente da ponte entre cadeias não tem falhas e que a tecnologia de prova de conhecimento zero é segura e fiável. Não é necessário introduzir demasiadas suposições de confiança, como acontece com as pontes tradicionais de multi-assinatura.

e a “Ponteiros otimistas” é ligeiramente diferente. Algumas pontes otimistas mantêm configurações semelhantes às testemunhas, mas introduzem provas de fraude e janelas de desafio., depois que a testemunha gera uma multi-assinatura para a mensagem entre cadeias, embora seja submetida à cadeia de destino, a sua validade não será reconhecida imediatamente. Deve passar por um período de janela e ninguém a questiona antes que possa ser considerada válida. Isto é na verdade algo semelhante à ideia de Rollup Otimista. Claro, a Ponte Otimista tem outros modelos de produtos, mas, em última análise, a segurança é garantida pelo protocolo de prova de fraude.

A suposição de confiança da ponte multiassinatura M/N é N-(M-1)/N. Você tem que assumir que o número de pessoas mal-intencionadas na rede é no máximo M-1, e o número de pessoas honestas é pelo menos N-(M-1). A suposição de confiança da ponte ZK é insignificante, enquanto a suposição de confiança da ponte otimista baseada na prova de fraude é de 1/N, apenas uma das testemunhas N precisa ser honesta e disposta a desafiar mensagens inválidas de cadeia cruzada enviadas à cadeia de destino para garantir a segurança da ponte.

Neste momento, devido a limitações técnicas, apenas a ponte ZK na direção do depósito de Bitcoin para a Camada 2 pode ser implementada. Se a direção for revertida e forem fevos levantamentos da Camada 2 para a cadeia Bitcoin, apenas pontes multi-assinatura ou pontes otimistas, ou modelos semelhantes a canais são suportados. (A ponte OP-DLC a ser descrita abaixo é mais semelhante a um canal). Para implementar uma ponte otimista na cadeia Bitcoin, a prova de fraude deve ser introduzida, e o bitVM criou boas condições para a implementação dessa tecnologia.

em artigos anterioresUma interpretação minimalista do BitVM: Como verificar provas de fraude na cadeia BTC, brevemente introduzimos, A essência da prova de fraude do BitVM é decompor as tarefas de cálculo complexas realizadas fora da cadeia em um grande número de passos simples, e depois selecionar um determinado passo para ser verificado diretamente na cadeia Bitcoin.. Essa ideia é semelhante aos rollups otimistas do Ethereum, como Arbitrum e Optimism.

(A documentação do BitVM2 menciona que uma tarefa de computação será dividida em um grande número de etapas intermediárias através de assinaturas de Lamport e depois qualquer pessoa pode desafiar uma etapa intermediária)

Claro, a declaração acima ainda é relativamente obscura, mas acredito que a maioria das pessoas já entendeu o significado do certificado de fraude. No artigo de hoje, devido às limitações gerais de espaço, não pretendemos explicar os detalhes técnicos de implementação do BitVM e do protocolo de prova de fraude, pois isso envolve uma série de processos de interação complexos.

Vamos apresentar brevemente a BitLayer, Citrea, BOB e até a ponte nativa BitVM oficialmente projetada pela BitVM do ponto de vista do design de produto e mecanismo, e como a BitLayer alivia o gargalo da ponte BitVM através da ponte OP-DLC., para mostrar como projetar uma solução de ponte de retirada superior na cadeia Bitcoin.

(Diagrama esquemático da solução de ponte da Bitlayer)

Uma breve análise do princípio da ponte BitVM entre a camada Bit e Citrea

abaixo, usamos a solução de ponte BitVM anunciada pela Bitlayer, Citrea e Bob como material para ilustrar o processo de operação geral da ponte BitVM.

Nos seus documentos oficiais e blogs técnicos, a parte do projeto acima mencionada explicou claramente as ideias de design do produto da Ponte de Levantamento BitVM (atualmente na fase teórica). Primeiro, quando um utilizador levanta dinheiro através da ponte BitVM, ele ou ela precisa de usar o contrato da Ponte na Camada 2 para gerar um extrato de levantamento. Os seguintes parâmetros chave são especificados no extrato de levantamento:

O número de BTC mapeados que o retirante precisa destruir na Camada 2 (como 1 BTC);

A taxa de manuseamento entre cadeias que o retirante pretende pagar (assumida como sendo 0,01 BTC);

O endereço de retirada do retirante em L1: L1_receipt;

O montante de levantamento do sacador (ou seja, 1 - 0,01 = 0,99BTC)

Posteriormente, a declaração de levantamento acima será incluída no bloco Camada 2. A ponte BitVMO nó Relayer irá sincronizar o bloco Camada 2, monitorizar a declaração de levantamento nele contida e encaminhá-la para o nó Operador, que pagará ao utilizador que fez o levantamento.

O que precisa de ser notado aqui é que o Operador primeiro paga aos utilizadores na cadeia do Bitcoin do seu próprio bolso, ou seja, "adianta" fundos para a Ponte BitVM e depois solicita compensação ao fundo da Ponte BitVM.

Ao solicitar o reembolso, o Operador precisa fornecer prova do pagamento antecipado na cadeia Bitcoin (ou seja, provar que transferiu dinheiro para o endereço especificado pelo usuário de retirada na L1 e extrair o registro de transferência específico contido no bloco Bitcoin). Ao mesmo tempo, o Operador também deve emitir uma declaração de retirada gerada pelo retirante na L2 (através de Prova de Merkle, é provado que a declaração de retirada emitida vem do bloco L2 e não é fabricada do nada). Depois, o Operador precisa provar o seguinte:

Os fundos avançados pelo Operador ao sacado em nome da Ponte BitVM são iguais ao montante solicitado pelo sacado no extrato;

Quando o Operador solicita o reembolso, o valor do reembolso não deve ser superior ao montante de BTC mapeado destruído pelo sacador na Camada 2;

O Operador processou de fato todas as declarações de levantamento L2-L1 num determinado período de tempo e cada declaração de levantamento pode ser correspondida ao registo de transferência de levantamento na cadeia Bitcoin;

Esta é essencialmente uma punição para o Operador por mentir sobre o valor antecipado ou recusar-se a processar o extrato de retirada (o que pode resolver o problema de resistência à censura da ponte de retirada). O Operador precisa comparar e verificar os campos-chave do certificado de pagamento antecipado e do extrato de retirada off-chain para provar que a quantidade de BTC envolvida em ambos é igual.

Se o Operador da Ponte de Levantamento relatar falsamente o montante adiantado, significa que o Operador alega que a prova de pagamento na L1 corresponde à Declaração de Levantamento emitida pelo retirador da L2, mas a situação real é que os dois não correspondem.

Desta forma, prova-se que a ZKP do Comprovativo de Pagamento = Declaração de Levantamento deve estar errada. Assim que esta ZKP for lançada, o Desafiante pode apontar qual é o passo errado e desafiá-lo através do protocolo de prova de fraude do BitVM2.

O que precisa de ser enfatizado é que Bitlayer, Citrea, BOB, ZKBase, etc. adotaram todos a mais recente rota BitVM2, que é a nova versão da solução BitVM. Esta solução irá ZKizar as tarefas de computação off-chain, ou seja, gerar ZK Proof para o processo de cálculo off-chain, verificar a Prova e, em seguida, converter o processo de verificação ZKP em Adaptado para a forma de BitVM para facilitar desafios subsequentes.

Ao mesmo tempo, utilizando Lamport e pré-assinatura, o desafio interativo de várias rodadas do BitVM original pode ser otimizado num desafio não-interativo de uma única rodada, reduzindo significativamente a dificuldade do desafio.

O processo de desafio do BitVM requer o uso de algo chamado "comprometimento", ou seja, Comprometimento. Vamos explicar o que é "comprometimento". Em termos gerais, alguém que publica um "comprometimento" na cadeia de Bitcoin afirmará que certos dados armazenados fora da cadeia/tarefas de computação ocorridas fora da cadeia são precisos, e a declaração relevante publicada na cadeia é um "comprometimento".

Podemos entender aproximadamente o Compromisso como um hash de uma grande quantidade de dados off-chain. O tamanho do Compromisso em si é frequentemente comprimido muito pequeno, mas pode estar ligado a uma grande quantidade de dados off-chain através de métodos como a Árvore de Merkle, e estes dados off-chain associados não precisam de ser carregados para a cadeia.

Na solução de ponte BitVM do BitVM2 e Citrea e BitLayer, se alguém considerar que há um problema com o compromisso emitido pelo Operador de Ponte de Retirada na cadeia, e que o compromisso está associado a um processo de verificação ZKP inválido, ele ou ela pode iniciar um desafio, e a autoridade de desafio é sem permissão.. (O processo de interação interno é relativamente complicado e não será explicado aqui)

Uma vez que o Operador avança fundos para o pool de fundos BitVM para pagar o saque e depois solicita reembolso ao pool de fundos, ao solicitar, o Operador deve emitir um Compromisso para provar que o dinheiro que transfere para o saque em L1 é igual ao saque. O pagador declara em L2 que deseja receber o dinheiro. Se o Compromisso tiver passado a janela de prova de fraude e não tiver sido contestado, o Operador pode sacar o valor do reembolso de que precisa.

Aqui queremos explicar como é mantida a pool de fundos públicos da ponte BitVM, e esta é precisamente a parte mais crítica da ponte de cadeia cruzada. Como todos sabemos, os fundos que a ponte de cadeia cruzada pode pagar ao sacador vêm dos ativos contribuídos pelos depositantes ou outros LPs, e o dinheiro adiantado pelo Operador será eventualmente retirado da pool de fundos públicos, então depende exclusivamente dos fundos. Como resultado da transferência, o valor do depósito do depositante absorvido pela ponte BitVM deve ser igual ao valor do saque do sacador. Portanto, como manter os fundos de depósito é uma questão muito importante.

Na maioria das soluções de ponte da Camada 2 do Bitcoin, os ativos públicos são frequentemente geridos através de multi-assinatura. Os depósitos dos utilizadores são agregados numa conta de multi-assinatura. Quando é necessário fazer um levantamento, esta conta de multi-assinatura é responsável pelo pagamento. Obviamente, existe um enorme risco de confiança nesta solução.

A ponte BitVM da Bitlayer e da Citrea adota ideias semelhantes à Lightning Network e canais. Antes de efetuar um depósito, o usuário comunicar-se-á primeiro com a BitVM Alliance e pedir-lhe-á para pré-assinar para alcançar os seguintes efeitos:

Após o utilizador transferir o depósito para o endereço de recarga, o dinheiro será diretamente bloqueado num endereço Taproot e só poderá ser recolhido pelo Operador da ponte. Além disso, o Operador só pode reclamar os fundos do endereço Taproot do depósito acima, solicitando reembolso após avançar os fundos de retirada para o utilizador. Após o término do período de desafio, o Operador pode retirar uma certa quantidade de depósitos de utilizadores.

Na solução de ponte BitVM, existe uma Federação BitVM (Federação BitVM) formada por N membros, que agendam os depósitos do usuário. No entanto, esses N membros não podem apropriar-se indevidamente dos depósitos dos usuários em privado, porque os usuários exigirão que a Aliança BitVM pré-assine antes de transferir dinheiro para o endereço designado para garantir que esses depósitos só possam ser legalmente reclamados pelo Operador.

(Diagrama da solução de ponte otimista do BitVM2)

Para resumir em um alto nível, o BitVM Bridge adota ideias semelhantes a canais e redes relâmpago, permitindo que os usuários "verifiquem por si mesmos" e impedindo que a BitVM Alliance manipule o pool de depósitos sem autorização através de pré-assinatura. O dinheiro no pool de depósitos só pode ser usado para reembolsar o Operador. Se um operador deturpar o montante adiantado, qualquer pessoa pode emitir provas de fraude e contestá-las.

Se a solução acima puder ser implementada, a ponte BitVM se tornará uma das pontes de retirada de Bitcoin mais seguras: Não há problemas de segurança com essa ponte, apenas problemas de disponibilidade/vivacidade. Quando os usuários tentam depositar fundos no BitVM, eles podem ser censurados ou recusados a cooperar pela Aliança BitVM, resultando na incapacidade de depositar fundos com sucesso. No entanto, isso não tem nada a ver com segurança, mas sim com um problema de vivacidade/disponibilidade.

No entanto, a implementação da ponte BitVM é relativamente difícil. Além disso, não pode satisfazer as necessidades de alguns grandes investidores que têm requisitos relativamente elevados de transparência de fundos: essas pessoas podem estar envolvidas em questões de lavagem de dinheiro e não querem misturar seus próprios fundos com os fundos de outras pessoas, mas a ponte BitVM aceitará uniformemente o dinheiro dos depositantes, de certa forma, é um pool onde muito dinheiro é misturado.

Para resolver o problema de atividade da ponte BitVM mencionado acima e fornecer um canal de entrada e saída de fundos independente e limpo para pessoas com necessidades específicas, a equipe BitLayer adicionou uma solução adicional de ponte cross-chain chamada OP-DLC. Além da ponte otimista BitVM2, é usada uma ponte DLC semelhante ao DLC.link. Fornecer aos utilizadores duas entradas e saídas, a ponte BitVM e a ponte OP-DLC, para reduzir a dependência da ponte BitVM e até mesmo da Aliança BitVM.

(Diagrama esquemático do DLC)

DLC: Contrato de Registo Cauteloso

DLC (Discreet Log Contracts) é chamado de contrato de log discreto. Foi proposto pela Iniciativa de Moeda Digital do MIT. Esta tecnologia foi usada pela primeira vez para implementar um contrato inteligente leve no Bitcoin. Não é necessário que o conteúdo do contrato seja carregado na cadeia. Através de métodos como comunicação interativa off-chain e pré-assinatura, funções de contrato inteligente que protegem a privacidade são implementadas na cadeia do Bitcoin. Abaixo, usamos um caso de jogo para ilustrar o princípio de funcionamento do DLC.

Suponhamos que Alice e Bob queiram apostar no resultado do jogo entre o Real Madrid e o Barcelona a realizar-se daqui a três dias, e cada um deles paga 1 btc. Se o Real Madrid ganhar, Alice pode obter 1,5 BTC, e Bob só pode recuperar 0,5 BTC, o que equivale a Alice ganhar 0,5 BTC e Bob perder 0,5 BTC; se o Barcelona ganhar, Alice só pode recuperar 0,5 BTC, e Bob pode levar 1,5 BTC. Se houver um empate, ambos os jogadores receberão de volta 1 BTC cada um.

Se quisermos tornar o processo de jogo acima sem confiança, devemos encontrar maneiras de evitar que qualquer parte trapaceie. Se simplesmente usarmos assinatura múltipla 2/2 ou assinatura múltipla 2/3, claramente não é suficientemente confiável. DLC fornece sua própria solução para este problema (dependendo de oráculos de terceiros). O fluxo de trabalho inteiro pode ser grosseiramente dividido em quatro partes.

Tomando o exemplo anterior de Alice e Bob, Primeiro, ambas as partes criam uma transação de fundo fora da cadeia, que pode bloquear 1 BTC um do outro no endereço de multi-assinatura 2/2., se essa transação de fundo entrar em vigor, os 2 BTC no endereço de multi-assinatura precisam ser autorizados por ambas as partes antes de poderem ser gastos.

Claro, esta transação do Fundo ainda não foi carregada na cadeia, mas permanece local para os clientes Alice e Bob fora da cadeia. Todos sabem quais serão as consequências depois que esta transação entrar em vigor. Atualmente, os dois lados estão apenas realizando deduções teóricas e depois chegando a uma série de acordos com base nos resultados das deduções.

Na primeira fase da criação do DLC, o que podemos determinar é que ambas as partes irão bloquear os seus 1 Bitcoin numa morada multi-assinatura no futuro.

Na segunda etapa, ambas as partes continuam a deduzir possíveis eventos e resultados futuros: Por exemplo, quando os resultados do jogo de futebol são anunciados, pode haver múltiplas possibilidades, como Alice ganhar e Bob perder, Alice perder e Bob ganhar, um empate, etc. Isso levará a diferentes resultados de distribuição dos Bitcoins no endereço de multimarca 2/2 mencionado anteriormente.

Diferentes resultados precisam ser acionados por diferentes instruções de negociação. Estas "Instruções de transação que podem ser carregadas para a cadeia no futuro" são chamadas de CET, ou seja, Transação de Execução de Contrato. Alice e Bob devem deduzir todos os CET antecipadamente e gerar um conjunto de dados de transação contendo todos os CET.

Por exemplo, com base nos possíveis resultados da aposta entre Alice e Bob mencionada acima, Alice cria os seguintes CETs:

CET1: Alice pode obter 1,5 BTC do endereço multi-assinatura e Bob pode obter 0,5 BTC;

CET2: Alice pode obter 0.5 BTC do endereço multi-assinatura, e Bob pode obter 1.5 BTC;

CET3: Ambas as partes podem receber 1 Bitcoin cada uma.

Vamos tomar o CET1 como exemplo (Alice recebe 1,5 BTC, Bob recebe 0,5 BTC):

O significado desta transação é transferir 1,5 BTC para o endereço de multi-assinatura para um endereço Taproot que é acionado pelos resultados de saída de Alice e da máquina oráculo, e transferir os outros 0,5 BTC para o endereço de Bob. Os eventos correspondentes neste momento são: Real Madrid ganha, Alice ganha 0,5 BTC e Bob perde 0,5 BTC.

Certamente, Para gastar estes 1.5 BTC, a Alice deve obter a assinatura do resultado “Real Madrid ganha” enviada pelo oráculo. Em outras palavras, somente quando o oráculo emite a mensagem “Real Madrid ganha” é que a Alice pode transferir os 1.5 BTC. Quanto aos conteúdos de CET2 e CET3, podemos deduzi-los da mesma forma e não entraremos em detalhes aqui.

Deve ser notado que CET é essencialmente uma transação que precisa ser carregada para a cadeia para ter efeito. O que acontecerá se Alice transmitir CET1 antecipadamente, ou no caso de "Barcelona vencer", ainda colocar CET1 na cadeia que só pode ser acionado com sucesso depois de "Real Madrid vencer"?

No diagrama anterior, mencionamos que após CET1 ser colocado na cadeia, os 2 BTC bloqueados no endereço multi-assinatura original serão transferidos, 0.5 BTC serão transferidos para Bob e 1.5 BTC serão transferidos para um endereço Taproot. A máquina oráculo produz "Somente depois que o Real Madrid vencer" Alice pode desbloquear o BTC bloqueado no endereço Taproot. Resultados como mostrado abaixo.

Ao mesmo tempo, Este endereço Taproot está sujeito a um bloqueio de tempo. Se Alice não puder retirar com sucesso 1,5 BTC dentro do período de tempo especificado pelo bloqueio de tempo, Bob tem o direito de pegar o dinheiro diretamente.

Portanto, desde que o oráculo seja honesto, Alice não pode retirar os 1,5 BTC. Quando o período de bloqueio de tempo expirar, Bob pode retirar os 1,5 BTC. Além dos 0,5 BTC transferidos diretamente para Bob quando o CET1 foi carregado na cadeia, todo o dinheiro acabará por pertencer a Bob.

Para Alice, não importa se ela ganha ou perde no final, a coisa mais benéfica a fazer é colocar o CET correto na cadeia. Colocar o CET inválido na cadeia fará com que ela perca mais dinheiro.

Na verdade, quando o CET acima mencionado foi construído, a assinatura schnorr do Taproot foi melhorada, o que pode ser entendido como usando a chave pública do oráculo + resultados do evento para construir endereços independentes para diferentes resultados. Depois disso, somente quando a máquina do oráculo anunciar a assinatura correspondente a um determinado resultado, o BTC bloqueado no endereço correspondente ao resultado poderá ser gasto.

Claro, há aqui uma possibilidade adicional. E se a Alice souber que perdeu e simplesmente não colocar o CET1 que construiu na cadeia? Isto é fácil de resolver, porque o Bob pode construir um CET personalizado para a situação de 'Alice perde, Bob ganha'. O efeito alcançado por este CET é basicamente o mesmo que o CET construído pela Alice, mas os detalhes específicos são diferentes, mas o resultado é o mesmo.

O que está descrito acima é o processo de construção do CET mais crítico. O terceiro passo do DLC é para Alice e Bob comunicarem, verificarem a transação CET construída pela outra parte e trazerem sua própria assinatura no CET. Após a verificação estar correta, podem confiar um no outro e investir cada um 1 BTC, bloqueando nos endereços de multi-assinatura 2/2 mencionados inicialmente de Alice e Bob, e depois esperar que um CET específico seja enviado para a cadeia para desencadear o processo subsequente.

Finalmente, depois de o oráculo anunciar os resultados e obter a assinatura do oráculo nos resultados, qualquer das partes pode colocar o CET correto na cadeia e permitir que os 2 BTC bloqueados no endereço de multi-assinatura sejam redistribuídos. Se o perdedor colocar o CET errado na cadeia primeiro, se você colocar o CET correto na cadeia, perderá todo o seu dinheiro. Se colocar o CET correto na cadeia, o perdedor pode recuperar 0.5 BTC.

Alguém pode perguntar, Como é que o DLC difere da multi-assinatura regular 2/3? Em primeiro lugar, se mais de 2/3 estiver assinado, qualquer duas partes podem conspirar para roubar todos os ativos, e o DLC permite que os oponentes limitem todos os cenários construindo um conjunto CET antecipadamente. Mesmo que o oráculo participe na conspiração, O dano causado é frequentemente limitado.

Em segundo lugar, a multi-assinatura requer que todas as partes assinem transações específicas a serem carregadas na cadeia, enquanto sob a configuração de DLC, o oráculo só precisa assinar os resultados de eventos específicos. Não precisa saber o conteúdo de CET/transações a serem carregadas na cadeia. Nem precisa saber que existem duas pessoas, Alice e Bob. Apenas precisa agir como um oráculo comum. Interagir com o usuário normalmente como uma máquina.

Podemos pensar que a essência do DLC é transformar a confiança dos participantes em multi-assinaturas em confiança em oráculos. Desde que a máquina do oráculo não participe de ações malignas, pode-se garantir que o design do protocolo DLC seja confiável o suficiente. Teoricamente, o DLC pode utilizar um oráculo de terceiros relativamente maduro e completo para evitar ações malignas. O DLC.link e o BitLayer aproveitam essa característica do DLC para transferir a questão da confiança da ponte para o oráculo de terceiros.

Além disso, a ponte DLC da Bitlayer também suporta nós oráculo autoconstruídos, adicionando uma camada de prova de fraude por cima disso. Quando o oráculo autoconstruído coloca CET inválidos na cadeia, qualquer um pode desafiá-lo. Em relação ao princípio da sua ponte OP-DLC, iremos descrevê-lo brevemente abaixo.

Ponte OP-DLC: Canal DLC + Prova de Fraude

Explicamos o princípio operacional da ponte OP-DLC a partir de todo o processo de depósito e levantamento. Suponha que Alice deposite agora 1 Bitcoin na L2 através da ponte OP-DLC, De acordo com o mecanismo de transação de dois passos, o Sr. Alice gera uma transação prévia de fundos, conforme mostrado abaixo:

Na verdade, transfira primeiro 1 BTC para o endereço Taproot controlado em conjunto por Alice e membros da Aliança BitVM e, em seguida, inicie uma série de processos para criar CET. Se um membro da Aliança BitVM Bridge se recusar a cooperar com o pedido de depósito de Alice, Alice poderá retirar o dinheiro imediatamente após o vencimento do bloqueio de tempo.

Se os membros da Aliança BitVM estiverem dispostos a cooperar com a Alice, ambas as partes podem usar comunicação off-chain para primeiro gerar uma transação formal de depósito de Fundo (ainda não na cadeia), bem como todos os CET no cenário de saque. Após a geração e verificação do CET estarem concluídas, ambas as partes podem submeter a transação de Fundo à cadeia.

Nos dados de testemunha/assinatura da transação do Fundo, Alice especificará o seu endereço de pagamento na Camada 2; Após a transação do Fundo ser carregada para a cadeia, Alice pode submeter os dados da transação do fundo acima ao contrato de ponte na Camada 2 para provar que completou a ação de depósito na cadeia do Bitcoin e é elegível para o contrato de ponte L2 libertar o Token para o endereço de pagamento designado.

Após a transação do Fundo ser acionada, o depósito é realmente bloqueado no endereço de multi-assinatura Taproot controlado em conjunto por Alice e membros da aliança BitVM. No entanto, deve ser notado que a multi-assinatura só pode desbloquear o BTC bloqueado pelo endereço através do CET, e a Aliança BitVM não pode transferir o dinheiro sem motivo.

A seguir, vamos analisar o CET construído antecipadamente por Alice e pela Aliança BitVM. Estes CET são usados para enfrentar cenários potenciais para futuros levantamentos. Por exemplo, Alice pode ter depositado 1 BTC, mas apenas levantou 0,3 BTC durante o seu primeiro levantamento, e os restantes 0,7 BTC foram entregues ao pool de fundos públicos da Aliança BitVM. Para controlar, mas se quiser levantar dinheiro, só pode fazê-lo através da ponte BitVM mencionada acima;

Ou simplesmente use estes 0.7 BTC para iniciar um novo depósito de pré-financiamento. Como um ativo recém-adicionado à ponte DLC, pode repetir o processo de transação de fundos e construção de CET mencionado acima.

O processo acima não é difícil de entender. Na verdade, o depositante Alice e a aliança bitVM atuam como partes contrapartes uma da outra, criam CET para eventos de levantamento de diferentes quantias e depois deixam o oráculo ler a declaração de levantamento iniciada por Alice na Camada 2 para determinar qual transação Alice deseja acionar. Um CET (quanto dinheiro você deseja sacar).

O risco aqui é que a máquina oráculo possa coludir com a Aliança BitVM. Por exemplo, Alice declara que quer retirar 0.5 BTC, mas a máquina oráculo forja a declaração de retirada, o que leva, em última análise, a “Alice retira 0.1 BTC e a Aliança BitVM recebe 0.9 BTC.” Erro CET na cadeia.

Existem várias soluções para este problema. A primeira é usar um oráculo de terceiros com um design relativamente completo. Evitar tal conluio (é extremamente difícil para a Aliança BitVM conluir com oráculos neste momento), Ou deixar o oráculo realizar apostas, O oráculo precisa publicar Compromisso na cadeia do Bitcoin regularmente, afirmando que tratou honestamente o pedido de saque do sacador. Qualquer um pode desafiar o Compromisso através do protocolo de prova de fraude do BitVM. Se o desafio for bem-sucedido, o oráculo malicioso será penalizado.

Sob o design da ponte OP-DLC, os utilizadores podem sempre "participar" nos seus próprios ativos para evitar que os ativos sejam desviados pela Aliança BitVM. Além disso, este design tipo canal traz mais autonomia aos utilizadores e também não há necessidade de misturar os seus próprios fundos com os fundos de outras pessoas. É mais como uma solução de depósito e levantamento ponto a ponto (P2P).

Além disso, Considerando que levará algum tempo para a solução BitVM ser implementada, antes disso, a ponte DLC será um modelo de processamento de ponte mais confiável em comparação com a simples solução de multi-assinatura. Esta solução também pode ser usada como duas grandes entradas de depósito e levantamento usadas em paralelo com a ponte BitVM. Se uma delas falhar, o usuário pode usar a outra entrada, que também é um bom método de tolerância a falhas.

Resumir

A solução de ponte BitLayer e BitVM da Citrea é essencialmente um modelo de "pagamento-ressarcimento antecipado", há um nó Operador dedicado para transferir dinheiro aos utilizadores de levantamento, e o Operador pode regularmente solicitar o reembolso para o endereço de depósito público. Se um operador fizer uma aplicação de reembolso falsa, pode ser desafiado e reduzido por qualquer pessoa.

A solução do BitVM2 introduz a pré-assinatura e combina a ideia de um canal para permitir aos utilizadores limitar o processo de processamento pós-depósito antes de efetuarem um depósito formal, e não dá aos oficiais da ponte entre cadeias a oportunidade de apropriar-se indevidamente dos depósitos dos utilizadores.

Em teoria, não existem problemas de segurança com esta ponte, mas existem problemas de vivacidade/disponibilidade, e não pode satisfazer as necessidades de utilizadores específicos de independência financeira e anti-lavagem de dinheiro (é essencialmente um modelo de pool de fundos), e também é muito difícil de implementar.

Nesse sentido, a Bitlayer adicionou uma solução de ponte chamada OP-DLC, que é semelhante ao DLC.link e introduz prova de fraude com base em canais e DLC para evitar que a máquina do oráculo da ponte DLC faça maldades.

Mas, uma vez que a implementação do BitVM é demasiado complicada, a ponte DLC será implementada primeiro e tornar-se-á um substituto temporário, desde que o risco de confiança da máquina do oráculo seja resolvido e uma máquina do oráculo de terceiros mais confiável e madura seja integrada, a ponte DLC pode tornar-se uma solução de verificação de retirada mais segura do que a ponte de multi-assinaturas nesta fase.

Aviso Legal：

1. Este artigo é reproduzido a partir de [极客web3]. Todos os direitos de autor pertencem ao autor original [Faust & Nickqiao]. Se houver objeções a esta reimpressão, por favor entre em contato com o Gate Learnequipa e eles resolverão rapidamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente as do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. Salvo indicação em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.