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

• As Pontes Otimistas/OP utilizam provas de fraude para desafiar mensagens inválidas de cadeia cruzada na cadeia. A presença de apenas um desafiante confiável pode garantir a segurança do pool de fundos da ponte de cadeia cruzada.
• 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. Equipes como Bitlayer e Citrea adotaram o esquema de ponte BitVM, introduzindo pré-assinaturas e incorporando conceitos de canal, permitindo que os usuários pré-definam o processo de manipulação após a execução do depósito, evitando que a ponte entre cadeias desvie os depósitos dos usuários.
• A ponte BitVM opera essencialmente com um modelo de "pré-pagamento-reembolso", com nós Operadores específicos fornecendo fundos aos usuários de saque. Os Operadores podem periodicamente solicitar reembolso de um endereço de depósito público. Se um Operador enviar uma aplicação de reembolso falsa, pode ser contestado e reduzido por qualquer um.
• Embora teoricamente seguro, a ponte BitVM tem problemas de vivacidade/usabilidade e não atende às necessidades específicas dos usuários para independência de fundos e contra lavagem de dinheiro (pois essencialmente usa um modelo de pool de fundos). A Bitlayer aborda isso com uma solução de ponte OP-DLC. Essa solução, semelhante ao DLC.link, introduz provas de fraude com base em canais e DLCs para evitar a má conduta do oráculo.
• Dada a dificuldade de implementar BitVM e provas de fraude, pontes DLC serão implantadas 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 se tornar um esquema de verificação de saque mais seguro do que as pontes de multiassinatura na fase atual.

Introdução: Desde a febre da inscrição no ano passado, o ecossistema do Bitcoin entrou em um período de crescimento rápido. Em apenas meio ano, o número de projetos sob a bandeira do BTC Camada 2 alcançou quase 100. Simplesmente se tornou um novo continente cheio de caos, onde oportunidades e golpes coexistem. Não é exagero dizer que o atual ecossistema do 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 do Bitcoin é simplesmente como o do século 19. Assim como os Estados Unidos, tornou-se um novo mundo que atrai forças de todos os setores. Embora isso traga prosperidade e vitalidade para toda a narrativa Web3, também introduz enormes riscos.

Muitos projetos começaram a fazer hype sem sequer 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 um monte de substantivos e termos estranhos como linhas para promover sua própria superioridade. Embora o exagero já seja o status atual do ecossistema do Bitcoin, ainda existem muitos dos principais KOLs que fizeram chamadas objetivas.

Não muito tempo atrás, Monanaut, o fundador do navegador blockchain Mempool, criticou publicamente os problemas atuais do ecossistema do Bitcoin. Ele apontou categoricamente que se uma Camada 2 do Bitcoin simplesmente usa uma ponte de retirada de múltiplas assinaturas e não permite que os usuários retirem ativos a qualquer momento de forma segura, tal projeto não é uma Camada 2 real. 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 múltiplas assinaturas. Ou várias instituições conhecidas detêm cada uma uma chave, ou é usada uma assinatura descentralizada com base em POS, mas, em qualquer caso, seu modelo de segurança baseia-se na suposição de maioria honesta, ou seja, presume-se que a maioria dos participantes de múltiplas assinaturas não esteja coludindo para fazer o mal.

Esse tipo de solução de ponte de retirada que depende muito da garantia de crédito não é de forma alguma uma solução de longo prazo. A história nos diz que as pontes de multi-assinatura terão vários problemas mais cedo ou mais tarde. Somente a confiança é minimizada ou a custódia de ativos tende a ser completamente sem confiança. Somente 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 mesmo lançaram um roteiro técnico para a ponte de retirada. Não há ideia de design estabelecida de como a ponte deve ser confiável ou minimizada.

Mas isso não é tudo do ecossistema Bitcoin. Ainda existem alguns gerentes de projeto que expressaram suas opiniões sobre as ideias de otimização da ponte de retirada. no texto, Vamos analisar brevemente a ponte Bitlayer e BitVM da Citrea, e apresentar a ponte OP-DLC proposta pela Bitlayer para abordar as deficiências da ponte BitVM, para que mais pessoas possam entender os riscos e ideias de design das pontes interligadas. 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 entre cadeias é muito simples, que é provar à cadeia B que um certo evento ocorreu na cadeia A. Por exemplo, se você atravessar ativos de ETH para Polygon, você precisa da ponte entre cadeias para ajudá-lo a provar que você 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 entre cadeias geralmente usam testemunhas de assinatura múltipla. Eles designarão várias testemunhas sob a cadeia. As testemunhas executarão os nós de cada cadeia pública e monitorarão se alguém depositou fundos no endereço de pagamento da ponte entre cadeias.

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

Por outro lado, a “Ponte Otimista” 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á configurar um contrato validador dedicado na cadeia de destino para verificar diretamente o certificado de retirada na cadeia, eliminando a necessidade de dependência de testemunhas off-chain.

Por exemplo, uma ponte ZK abrangendo ETH e Polygon implantará um contrato de verificador no Polygon, vamos chamá-lo de Verificador por enquanto. O nó Relayer da Ponte ZK encaminhará o cabeçalho de bloco Ethereum mais recente e a Prova ZK que comprova a validade para o Verificador, que irá verificá-la. Isso equivale a ter o contrato do Verificador sincronizado na cadeia Polygon e verificar o cabeçalho de bloco Ethereum mais recente. A raiz merkle registrada no cabeçalho do bloco está relacionada ao conjunto de transações contido 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 contém 10 declarações de transferência cross-chain de ETH para Polygon, o Relayer irá gerar a Prova de Merkle relacionada a essas 10 transações e submeter a prova ao contrato Verificador na cadeia Polygon:

O bloco Ethereum No. 101 contém 10 transações cross-chain de ETH para Polygon. Claro, a ponte ZK pode converter a Prova de Merkle em ZK e enviar diretamente a Prova ZK ao contrato Verificador. Durante todo esse processo, os usuários só precisam confiar que o contrato inteligente da ponte cross-chain não tem brechas e que a tecnologia de prova de conhecimento zero em si é segura e confiável. Não há necessidade de introduzir muitas suposições de confiança como pontes tradicionais de multi-assinatura.

E a “Ponte Otimista” é ligeiramente diferente. Algumas pontes otimistas mantêm configurações semelhantes às de testemunhas, mas introduzem provas de fraude e janelas de desafio., após a testemunha gerar uma assinatura múltipla para a mensagem entre cadeias, embora seja enviada para a cadeia de destino, sua validade não será reconhecida imediatamente. Deve passar por um período de janela e ninguém questioná-la antes que possa ser considerada válida. Isso é na verdade algo um pouco similar à 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 de assinatura múltipla 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 é 1/N,Apenas uma das N testemunhas precisa ser honesta e disposta a desafiar mensagens inválidas de cadeia cruzada enviadas à cadeia de destino para garantir a segurança da ponte.

Atualmente, 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 invertida e as retiradas forem feitas da Camada 2 para a cadeia de Bitcoin, apenas pontes de multissig ou pontes otimistas, ou modelos semelhantes a canais, são suportados. (A ponte OP-DLC a ser descrita abaixo é mais como um canal). Para implementar uma ponte otimista na cadeia de Bitcoin, a prova de fraude deve ser introduzida, e 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, nós brevemente introduzimos, A essência da prova de fraude do BitVM é decompor as tarefas de cálculo complexas realizadas off-chain em um grande número de passos simples, e então selecionar um certo passo para ser verificado diretamente na cadeia do Bitcoin.. Esta 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 então 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 de implementação técnica do BitVM e do protocolo de prova de fraude, pois isso envolve uma série de processos de interação complexos.

Vamos apresentar brevemente o BitLayer, Citrea, BOB e até mesmo a ponte nativa BitVM oficialmente projetada pela BitVM, do ponto de vista do design de produto e mecanismo, e como o 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 Bitlayer e Citrea

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

Em seus documentos oficiais e blogs técnicos, a parte do projeto mencionada acima explicou claramente as ideias de design do produto da Ponte de Retirada BitVM (atualmente na fase teórica). Primeiramente, quando um usuário retira dinheiro através da ponte BitVM, ele precisa usar o contrato da Ponte na Camada 2 para gerar uma declaração de retirada. Os seguintes parâmetros principais são especificados na declaração de retirada:

O número de BTC mapeado que o retirante precisa destruir em L2 (como 1 BTC);

A taxa de manipulação entre cadeias que o retirante pretende pagar (assumida como 0,01 BTC);

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

O montante de retirada do retirante (ou seja, 1 - 0.01 = 0.99BTC)

Depois, A declaração de saque acima será incluída no bloco Camada 2. A ponte BitVM O nó Relayer sincronizará o bloco Camada 2, monitorará a declaração de saque contida nele e a encaminhará para o nó Operador, que pagará ao usuário que fez o saque.

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

Ao solicitar o reembolso, o Operador precisa fornecer uma prova de pagamento antecipado na cadeia do Bitcoin (ou seja, provar que transferiu dinheiro para o endereço especificado pelo usuário de saque na L1 e deve extrair o registro de transferência específico contido no bloco do Bitcoin). Ao mesmo tempo, o Operador também deve emitir uma declaração de saque gerada pelo sacador na L2 (por meio de Prova de Merkle, é provado que a declaração de saque 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 valor solicitado pelo sacado na declaração;

Quando o Operador solicita reembolso, o valor do reembolso não pode ser superior ao valor do BTC mapeado destruído pelo retirante na Camada 2;

O Operador de fato processou todas as declarações de saque L2-L1 dentro de um período de tempo, e cada declaração de saque pode ser correspondida ao registro de transferência de saque na cadeia do Bitcoin;

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

Se o Operador da Ponte de Retirada relatar falsamente o valor antecipado, significa que o Operador afirma que a prova de pagamento na L1 corresponde à Declaração de Retirada emitida pelo retirante da L2, mas a situação real é que os dois não correspondem.

Dessa forma, prova que o ZKP de Payment Proof = Withdrawal Statement deve estar errado. Assim que este ZKP for liberado, o Desafiante pode apontar qual etapa está errada e desafiá-la através do protocolo de prova de fraude do BitVM2.

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

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

O processo de desafio do BitVM requer o uso de algo chamado “compromisso”, isto é, Compromisso. Vamos explicar o que é um “compromisso”. Em termos gerais, alguém que publica um “compromisso” na cadeia de Bitcoin afirmará que certos dados armazenados off-chain/tarefas de computação ocorrendo off-chain são precisos, e a declaração relevante publicada na cadeia é um “compromisso”.

Podemos entender aproximadamente o Compromisso como um hash de uma grande quantidade de dados off-chain. O tamanho do Compromisso em si muitas vezes é comprimido muito pequeno, mas pode ser vinculado a uma grande quantidade de dados off-chain por meio de métodos como a Árvore de Merkle, e esses dados off-chain associados não precisam ser carregados para a cadeia.

Na solução de ponte BitVM do BitVM2 e Citrea e BitLayer, se alguém achar 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 do desafio é sem permissão. (O processo de interação interno é relativamente complicado e não será explicado aqui)

Uma vez que o Operador adianta 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 na L1 é igual ao saque. O pagador declara na L2 que deseja receber o dinheiro. Se o Compromisso tiver passado pela janela de prova de fraude e não tiver sido contestado, o Operador poderá sacar o valor de reembolso de que precisa.

Aqui queremos explicar como o pool de fundos públicos da ponte BitVM é mantido, e esta é precisamente a parte mais crítica da ponte de interligação. Como todos sabemos, os fundos que a ponte de interligação pode pagar ao sacador vêm dos ativos contribuídos pelos depositantes ou outros LPs, e o dinheiro avançado pelo Operador será eventualmente retirado do pool de fundos públicos, dependendo 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 gerenciados por meio de multi-assinatura. Os depósitos dos usuários são agregados em uma conta de multi-assinatura. Quando um saque precisa ser feito, essa conta de multi-assinatura é responsável por efetuar o pagamento. Obviamente, há um grande risco de confiança nessa solução.

A ponte BitVM Bitlayer e Citrea adota ideias semelhantes à Lightning Network e canais. Antes de fazer um depósito, o usuário primeiro se comunicará com a Aliança BitVM e pedirá a esta última que pré-assine para alcançar os seguintes efeitos:

Após o usuário transferir o depósito para o endereço de recarga, o dinheiro será diretamente bloqueado em um endereço Taproot e só poderá ser coletado pelo Operador da ponte. Além disso, o Operador só pode reivindicar os fundos do endereço Taproot do depósito acima, solicitando reembolso após avançar os fundos de retirada para o usuário. Após o término do período de desafio, o Operador pode retirar uma certa quantia dos depósitos do usuário.

Na solução de ponte BitVM, existe uma Federação BitVM (BitVM Federation) formada por N membros, que agendam depósitos de usuários. No entanto, esses N membros não podem apropriar-se indevidamente dos depósitos dos usuários em particular, pois 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 reivindicados pelo Operador.

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

Para resumir em um nível mais alto, a Ponte BitVM adota ideias semelhantes aos canais e redes lightning, permitindo aos usuários “verificar por si mesmos” e impedir a Aliança BitVM de manipular 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 representar de forma inadequada o valor adiantado, qualquer pessoa pode apresentar prova de fraude e desafiá-la.

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 esta ponte, apenas problemas de disponibilidade/atividade. Quando os usuários tentam depositar fundos no BitVM, eles podem ser censurados ou recusados em 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 é uma questão de disponibilidade/atividade.

No entanto, a implementação da ponte BitVM é relativamente difícil. Além disso, não pode atender às necessidades de alguns grandes investidores que têm requisitos relativamente altos 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 de ponte BitVM acima mencionado 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 inter-cadeia chamada OP-DLC. Além da ponte otimista BitVM2, é usada uma ponte DLC semelhante à DLC.link. Fornecer aos usuários duas entradas e saídas, a ponte BitVM e a ponte OP-DLC, para reduzir a dependência da ponte BitVM e até da Aliança BitVM.

(Diagrama esquemático de DLC)

DLC: Contrato de Registro 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 requer 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 de proteção de privacidade são implementadas na cadeia Bitcoin. Abaixo, usamos um caso de jogo para ilustrar o princípio de funcionamento do DLC.

Suponha que Alice e Bob queiram apostar no resultado da partida entre Real Madrid e Barcelona, que será realizada daqui a três dias, e cada um deles paga 1 btc. Se o Real Madrid vencer, Alice pode receber 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 vencer, 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.

Se quisermos tornar o processo de jogo acima sem confiança, devemos encontrar maneiras de evitar que qualquer parte trapaceie. Se simplesmente usarmos multi-assinatura 2/2 ou multi-assinatura 2/3, obviamente não é confiável o suficiente. A DLC fornece sua própria solução para este problema (dependendo de oráculos de terceiros). Todo o fluxo de trabalho 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 off-chain, que pode bloquear 1 BTC de cada um no endereço de multi-assinatura 2/2., se esta transação de fundos entrar em vigor, os 2 BTC no endereço de multi-assinatura precisam ser autorizados por ambas as partes antes que possam ser gastos.

É claro, esta transação do Fundo ainda não foi enviada para a 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. No momento, os dois lados estão apenas conduzindo 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 bloquearão seus 1 BTC em um endereço multi-assinatura no futuro.

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

Resultados diferentes precisam ser acionados por instruções comerciais diferentes. Essas 'Instruções de transação que podem ser enviadas 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 de múltiplas assinaturas, e Bob pode obter 0,5 BTC;

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

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

Vamos pegar o CET1 como exemplo (Alice recebe 1.5 BTC, Bob recebe 0.5 BTC):

O significado desta transação é transferir 1,5 BTC no 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 esses 1,5 BTC, Alice deve obter a assinatura do resultado "Real Madrid vence" enviada pelo oráculo. Em outras palavras, somente quando o oráculo emite a mensagem "Real Madrid vence", 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-se notar que o CET é essencialmente uma transação que precisa ser carregada na cadeia para ter efeito. O que acontecerá se Alice transmitir o CET1 antecipadamente, ou no caso de "Barcelona vencer", ainda colocar o CET1 na cadeia que só pode ser acionado com sucesso após "Real Madrid vencer"?

No diagrama anterior, mencionamos que depois que o CET1 é colocado na cadeia, os 2 BTC bloqueados no endereço original de multi-assinatura serão transferidos, 0,5 BTC serão transferidos para Bob e 1,5 BTC serão transferidos para um endereço de Taproot. A máquina do oráculo emite “Somente depois que o Real Madrid vencer” Alice pode desbloquear os BTC bloqueados no endereço de Taproot. Resultados conforme mostrado abaixo.

Ao mesmo tempo, Este endereço Taproot está sujeito a um bloqueio de tempo. Se Alice não puder sacar com sucesso 1,5 BTC dentro do período 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 tirar os 1,5 BTC. Quando o período de bloqueio de tempo expirar, Bob pode levar os 1,5 BTC. Além dos 0,5 BTC transferidos diretamente para Bob quando o CET1 foi carregado na cadeia, todo o dinheiro eventualmente pertencerá a Bob.

Para Alice, independentemente de ganhar ou perder 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 compreendido como o uso da chave pública do oráculo + resultados do evento para construir endereços independentes para resultados diferentes. Depois disso, somente quando a máquina do oráculo anuncia a assinatura correspondente a um certo resultado, os BTC bloqueados no endereço correspondente ao resultado podem ser gastos.

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

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

Finalmente, depois que a máquina oracle anuncia os resultados e obtém a assinatura da máquina oracle nos resultados, qualquer parte 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 você colocar o CET correto na cadeia, o perdedor poderá recuperar 0,5 BTC.

Alguém pode perguntar, Como o DLC é diferente de uma assinatura múltipla 2/3 regular? Primeiro, se mais de 2/3 for assinado, duas partes podem conspirar para roubar todos os ativos, e o DLC permite que os oponentes limitem todos os cenários, construindo um CET previamente. Mesmo que o oráculo participe da 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 do 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. Só precisa agir como um oráculo comum. Basta interagir com o usuário normalmente como uma máquina.

Podemos pensar que a essência do DLC é transformar a confiança dos participantes de multiassinatura em confiança nos oráculos. Desde que a máquina do oráculo não participe de atos malignos, pode-se garantir que o design do protocolo DLC é confiável o suficiente. Teoricamente, o DLC pode usar um oráculo de terceiros relativamente maduro e completo para evitar fazer o mal. A DLC.link e a 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 do Bitlayer também suporta nós oráculo autoconstruídos, adicionando uma camada de prova de fraude sobre isso. Quando o oráculo autoconstruído coloca CET inválidos na cadeia, qualquer um pode desafiá-lo. Em relação ao princípio de sua ponte OP-DLC, descreveremos brevemente abaixo.

OP-DLC Bridge: Canal DLC + Prova de Fraude

Explicamos o princípio operacional da ponte OP-DLC a partir de todo o processo de depósito e saque. Suponha que Alice deposite agora 1 BTC para L2 através da ponte OP-DLC, De acordo com o mecanismo de transação de duas etapas, o Sr. Alice gera uma transação de pré-financiamento, conforme mostrado abaixo:

Na verdade, transfira 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 pode retirar o dinheiro imediatamente após o vencimento do bloqueio de tempo.

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

Nos dados de Testemunha/Assinatura da transação do Fundo, Alice especificará seu endereço de pagamento na Camada 2; Após a transação do Fundo ser enviada para a cadeia, Alice pode enviar os dados da transação do fundo acima para o contrato da ponte na Camada 2 para provar que ela completou a ação de depósito na cadeia do Bitcoin e é elegível para o contrato da ponte L2 liberar Tokens para o endereço de pagamento designado.

Após a transação do Fundo ser desencadeada, 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-se notar 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 os CET construídos antecipadamente por Alice e pela Aliança BitVM. Esses CET são usados para atender cenários potenciais para futuros saques. Por exemplo, Alice pode ter depositado 1 BTC, mas ela só sacou 0,3 BTC durante seu primeiro saque, e os 0,7 BTC restantes foram entregues ao pool de fundos público da Aliança BitVM. Para controlar, mas se você quiser sacar dinheiro, só pode passar pela ponte BitVM mencionada acima;

Ou simplesmente use estes 0.7 BTC para iniciar um novo depósito prévio. Como um novo ativo na ponte de DLC, você 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 contrapartes um do outro, criam CET para eventos de retirada de diferentes valores e, em seguida, permitem que o oráculo leia a declaração de retirada iniciada por Alice na Camada 2 para determinar qual transação Alice deseja acionar. Um CET (quanto dinheiro você quer retirar).

O risco aqui é que a máquina do oráculo pode conspirar com a Aliança BitVM. Por exemplo, Alice declara que deseja sacar 0.5 BTC, mas a máquina do oráculo forja a declaração de saque, o que leva, no final, a “Alice saca 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. Impedir tal colusão (é extremamente difícil para a Aliança BitVM fazer colusão com oráculos neste momento), ou permitir que o oráculo realize staking. 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á punido.

Sob o design da ponte OP-DLC, os usuários podem sempre “participar” de seus próprios ativos para evitar que os ativos sejam apropriados indevidamente pela Aliança BitVM. Além disso, esse design semelhante a um canal traz mais autonomia aos usuários e também não há necessidade de misturar seus próprios fundos com os fundos de outras pessoas. É mais parecido com uma solução de depósito e saque peer-to-peer (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 solução simples de multi-assinatura. Esta solução também pode ser usada como duas principais entradas de depósito e saque 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 BitVM da BitLayer e Citrea é essencialmente um modelo de "pagamento antecipado-reembolso", existe um nó Operador dedicado para transferir dinheiro para os usuários de saque, e o Operador pode solicitar regularmente o reembolso ao endereço de depósito público. Se um operador fizer uma solicitação de reembolso falsa, ela pode ser contestada e cortada por qualquer pessoa.

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

Não há problemas de segurança com esta ponte na teoria, mas há problemas de vivacidade/disponibilidade, e não pode atender às necessidades de usuários específicos para independência de fundos e combate à lavagem de dinheiro (essencialmente, é um modelo de pool de fundos), e também é muito difícil de implementar.

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

No entanto, como o BitVM é muito difícil de implementar, a ponte DLC será implementada primeiro e se tornará um substituto temporário, desde que o risco de confiança da máquina oráculo seja resolvido e uma máquina oráculo de terceiros mais confiável e madura seja integrada, a ponte DLC pode se tornar uma solução de verificação de retirada mais segura do que a ponte de multi-assinatura neste estágio.

Aviso Legal:

1. Este artigo é reproduzido a partir de [ 极客web3]. Todos os direitos autorais pertencem ao autor original [Faust & Nickqiao]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipe, e eles vão lidar com isso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.