1. Introdução

O Contrato de Log Discreto (DLC) é um framework de execução de contratos baseado num Oracle, proposto por Tadge Dryja do Instituto de Tecnologia de Massachusetts em 2018. O DLC permite que duas partes executem pagamentos condicionais com base em condições predefinidas. As partes determinam resultados possíveis, pré-assinam-nos e usam essas pré-assinaturas para executar pagamentos quando o Oracle aprova o resultado. Portanto, o DLC permite novas aplicações financeiras descentralizadas, garantindo a segurança dos depósitos de Bitcoin.

Comparado com a Lightning Network, DLC tem as seguintes vantagens significativas:

• Privacidade: O DLC oferece uma melhor proteção da privacidade do que a Lightning Network. Os detalhes do contrato são partilhados apenas entre as partes envolvidas e não são armazenados na blockchain. Em contraste, as transações da Lightning Network são encaminhadas através de canais e nós públicos, tornando as suas informações públicas e transparentes.
• Complexidade e Flexibilidade dos Contratos Financeiros: DLC pode criar e executar diretamente contratos financeiros complexos na rede Bitcoin, como derivativos, seguros e apostas, enquanto a Lightning Network é usada principalmente para pagamentos rápidos de pequeno valor e não pode suportar aplicações complexas.
• Risco Contraparte Reduzido: Os fundos da DLC são bloqueados em contratos de multi-assinatura e são apenas libertados quando o resultado de um evento predefinido ocorre, reduzindo o risco de qualquer parte não cumprir o contrato. Embora a Lightning Network reduza a necessidade de confiança, ela ainda carrega certos riscos de contraparte na gestão de canais e na provisão de liquidez.
• Não é necessário gerir canais de pagamento: as operações de DLC não requerem a criação ou manutenção de canais de pagamento, que são centrais para a Lightning Network e envolvem uma gestão complexa e intensiva em recursos.
• Escalabilidade para Casos de Uso Específicos: Embora a Lightning Network aumente um pouco a taxa de transações do Bitcoin, o DLC oferece uma melhor escalabilidade para contratos complexos na Bitcoin.

Embora os DLCs tenham vantagens significativas no ecossistema do Bitcoin, ainda existem alguns riscos e questões, tais como:

• Risco-chave: Existe o risco de vazamento ou perda das chaves privadas da Oracle e dos nonces comprometidos, o que pode levar à perda dos ativos do usuário.
• Risco de Confiança Centralizada: A centralização nos Oracles pode facilmente levar a ataques de negação de serviço.
• Problema de Derivação de Chave Descentralizada: Se o Oráculo for descentralizado, os nós do Oráculo apenas possuem partes da chave privada. No entanto, os nós descentralizados do Oráculo não podem usar diretamente o BIP32 para a derivação de chaves com base nessas partes da chave privada.
• Risco de Colusão: Se os nós do Oracle conspirarem entre si ou com uma parte, a questão da confiança nos Oracles permanece por resolver. É necessário um mecanismo de monitorização fiável para minimizar a confiança nos Oracles.
• Problema de Mudança de Denominação Fixa: As assinaturas condicionais exigem um conjunto determinístico e enumerável de eventos antes de construir o contrato para construir a transação. Assim, usar DLC para realocação de ativos tem uma restrição mínima de quantidade, levando ao problema da mudança de denominação fixa.

Para resolver estes problemas, este artigo propõe várias soluções e ideias de otimização para mitigar os riscos e questões associadas aos DLCs, melhorando assim a segurança do ecossistema do Bitcoin.

2. Princípio do DLC

Alice e Bob celebram um acordo de apostas sobre se o valor de hash do (n+k)-ésimo bloco é ímpar ou par. Se for ímpar, Alice ganha o jogo e pode retirar os ativos dentro do tempo t; se for par, Bob ganha o jogo e pode retirar os ativos dentro do tempo t. Usando DLC, as informações do bloco (n+k)-ésimo são transmitidas por um Oracle para construir uma assinatura condicional, garantindo que o vencedor correto receba todos os ativos.

Inicialização: O gerador da curva elíptica é G e a sua ordem é q.

Geração de chaves: O Oracle, Alice e Bob geram independentemente as suas próprias chaves privadas e públicas.

• A chave privada do Oráculo é z, e a sua chave pública é Z, satisfazendo Z=z⋅G;
• A chave privada de Alice é x, e a chave pública dela é X, satisfazendo X=x⋅G;
• A chave privada de Bob é y, e a chave pública dele é Y, satisfazendo Y=y⋅G.

Transação de financiamento: Alice e Bob criam juntos uma transação de financiamento, bloqueando 1 BTC cada em uma saída multi-assinatura 2-de-2 (uma chave pública X pertence a Alice e a outra Y a Bob).

Transações de Execução de Contrato (CET): Alice e Bob criam dois CETs para gastar a transação de financiamento.

O Oráculo calcula o compromisso

e depois calcula S e S′

e transmite (R, S, S′).

Alice e Bob calculam cada um a nova chave pública correspondente

Liquidação: Após o aparecimento do (n+k)-ésimo bloco, o Oráculo gera o s ou s′ correspondente com base no valor de hash desse bloco.

• Se o valor de hash do bloco (n+k)-ésimo for ímpar, o Oracle calcula e transmite

• Se o valor hash do bloco (n+k) for par, o Oracle calcula e transmite

Levantamento: Tanto Alice como Bob podem levantar os ativos com base na transmissão de s ou s′ feita pelo Oráculo.

• Se o Oracle transmitir s, Alice pode calcular a nova chave privada sk^{Alice} e retirar os 2 BTC bloqueados

• Se o Oracle transmitir s′, Bob pode calcular a nova chave privada sk^{Bob} e retirar os 2 BTC bloqueados

Análise: A nova chave privada sk^{Alice} calculada por Alice e a nova chave pública PK^{Alice} satisfazem a relação do logaritmo discreto

Assim, o levantamento de Alice será bem-sucedido.

Da mesma forma, a nova chave privada sk^{Bob} calculada por Bob e a nova chave pública PK^{Bob} satisfazem a relação do logaritmo discreto

Assim, o levantamento de Bob será bem-sucedido.

Além disso, se o Oráculo transmitir s, é útil para Alice, mas não para Bob porque Bob não consegue calcular a nova chave privada correspondente sk^{Bob}. Da mesma forma, se o Oráculo transmitir s′, é útil para Bob, mas não para Alice, porque Alice não consegue calcular a nova chave privada correspondente sk^{Alice}. Por fim, a descrição acima omite o bloqueio temporal. Um bloqueio temporal deve ser adicionado para permitir que uma das partes calcule a nova chave privada e faça o levantamento dentro do tempo t. Caso contrário, se exceder o tempo t, a outra parte pode usar a chave privada original para levantar os ativos.

3. Otimizações DLC

3.1 Gestão de Chaves

No protocolo DLC, a chave privada do Oráculo e o nonce comprometido são cruciais. A divulgação ou perda da chave privada do Oráculo e do nonce comprometido pode levar aos seguintes quatro problemas de segurança:

(1) Oracle Perde Chave Privada z

Se o Oracle perder a sua chave privada, o DLC não pode ser resolvido, tornando necessária a execução de um contrato de reembolso de DLC. Portanto, o protocolo DLC inclui uma transação de reembolso para prevenir as consequências da perda da chave privada do Oracle.

(2) Vazamento da Chave Privada z da Oracle

Se a chave privada do Oracle for divulgada, todos os DLCs baseados nessa chave privada enfrentam o risco de liquidação fraudulenta. Um atacante que rouba a chave privada pode assinar qualquer mensagem desejada, ganhando controle completo sobre os resultados de todos os contratos futuros. Além disso, o atacante não está limitado a emitir uma única mensagem assinada, mas também pode publicar mensagens conflitantes, como assinar que o valor de hash do bloco (n+k)-ésimo é tanto ímpar quanto par.

(3) Vazamento ou Reutilização do Nounce k da Oracle

Se o Oráculo divulgar o nonce k, então na fase de liquidação, independentemente de o Oráculo transmitir s ou s′, um atacante pode calcular a chave privada z do Oráculo da seguinte forma:

Se o Oracle reutilizar o nonce k, então após dois acordos, um atacante pode resolver o sistema de equações com base nas assinaturas de transmissão do Oracle para deduzir a chave privada z do Oracle em um dos quatro cenários possíveis.

caso 1:

caso 2:

caso 3:

caso 4:

(4) Oracle Perde Nonce k

Se o Oráculo perder o nonce k, o DLC correspondente não pode liquidar, sendo necessária a execução de um contrato de reembolso do DLC.

Portanto, para aumentar a segurança da chave privada do Oracle, é aconselhável usar BIP32 para derivar chaves filhas ou netas para assinar. Além disso, para aumentar a segurança do nonce, o valor de hash k:=hash(z, counter) deve ser usado como o nonce k, para evitar repetição ou perda do nonce.

3.2 Oráculo Descentralizado

No DLC, o papel do Oracle é crucial, pois fornece dados externos essenciais que determinam o resultado do contrato. Para aumentar a segurança desses contratos, Oracles descentralizados são necessários. Ao contrário dos Oracles centralizados, os Oracles descentralizados distribuem a responsabilidade de fornecer dados precisos e à prova de adulteração por vários nós independentes, reduzindo o risco associado a um único ponto de falha e diminuindo a probabilidade de manipulação ou ataques direcionados. Com um Oracle descentralizado, os DLCs podem alcançar um grau mais elevado de descentralização e confiabilidade, garantindo que a execução do contrato dependa inteiramente da objetividade das condições predeterminadas.

Assinaturas de limiar de Schnorr podem ser usadas para implementar Oráculos descentralizados. As assinaturas de limiar de Schnorr oferecem as seguintes vantagens:

• Segurança Reforçada: Ao distribuir a gestão das chaves, as assinaturas de limiar reduzem o risco de pontos únicos de falha. Mesmo que as chaves de alguns participantes sejam comprometidas ou atacadas, todo o sistema permanece seguro desde que a violação não exceda um limiar predefinido.
• Controlo Distribuído: As assinaturas de limiar permitem o controlo distribuído sobre a gestão de chaves, eliminando uma entidade única detentora de todos os poderes de assinatura, reduzindo assim os riscos associados à concentração de poder.
• Disponibilidade melhorada: As assinaturas podem ser concluídas contanto que um certo número de nós do Oracle concorde, aumentando a flexibilidade e disponibilidade do sistema. Mesmo que alguns nós não estejam disponíveis, a confiabilidade geral do sistema não é afetada.
• Flexibilidade e escalabilidade: O protocolo de assinatura de limiar pode definir diferentes limiares conforme necessário para atender a vários requisitos de segurança e cenários. Além disso, é adequado para redes em grande escala, oferecendo boa escalabilidade.
• Responsabilidade: Cada nó do Oracle gera uma parte da assinatura com base na sua parte da chave privada, e outros participantes podem verificar a correção desta parte da assinatura usando a parte correspondente da chave pública, permitindo a responsabilização. Se estiver correta, estas partes da assinatura são acumuladas para produzir uma assinatura completa.

Portanto, o protocolo de assinatura de limiar de Schnorr tem vantagens significativas em Oráculos descentralizados em termos de melhorar a segurança, confiabilidade, flexibilidade, escalabilidade e responsabilidade.

3.3 Acoplamento da Descentralização e Gestão de Chaves

Na tecnologia de gestão de chaves, um Oráculo possui uma chave completa z e, usando BIP32 juntamente com incrementos ω, pode derivar uma multidão de chaves filhas z+ω^{(1)} e chaves netas z+ω^{(1)}+ω^{(2)}. Para diferentes eventos, o Oráculo pode usar várias chaves privadas netas z+ω^{(1)}+ω^{(2)} para gerar assinaturas correspondentes σ para as mensagens dos eventos respetivos.

No cenário do Oráculo descentralizado, existem n participantes, e uma assinatura de limiar requer t+1 participantes, onde t

No entanto, num cenário de Oracle descentralizado, a chave privada completa z não aparece e, portanto, a derivação direta da chave usando BIP32 não é possível. Em outras palavras, a tecnologia Oracle descentralizada e a tecnologia de gestão de chaves não podem ser integradas diretamente.

O artigo “Derivação de Chave Distribuída para Gestão Multi-Partes de Ativos Digitais de BlockchainPropõe um esquema de derivação de chave distribuída em cenários de assinatura de limite. A ideia central baseia-se em polinómios de interpolação de Lagrange, onde a chave privada partilhada z_i e a chave privada completa z satisfazem a seguinte relação de interpolação:

Adicionar o incremento ω a ambos os lados da equação resulta em:

Esta equação mostra que a parte da chave privada z_i mais o incremento ω ainda satisfaz a relação de interpolação com a chave privada completa z mais ω. Em outras palavras, a parte da chave privada da criança z_i+ω e a chave da criança z+ω satisfazem a relação de interpolação. Portanto, cada participante pode usar a sua parte da chave privada z_i mais o incremento ω para derivar a parte da chave privada da criança z_i+ω, usada para gerar partes da assinatura da criança e validá-las usando a chave pública correspondente da criança Z+ω⋅G.

No entanto, deve-se considerar a BIP32 endurecida e não endurecida. A BIP32 endurecida leva a chave privada, o código de cadeia e o caminho como entrada, realiza SHA512 e produz o incremento e o código de cadeia filho. A BIP32 não endurecida, por outro lado, leva a chave pública, o código de cadeia e o caminho como entrada, realiza SHA512 e produz o incremento e o código de cadeia filho. Em um cenário de assinatura de limiar, a chave privada não existe, então apenas a BIP32 não endurecida pode ser usada. Ou, usando uma função de hash homomórfica, a BIP32 endurecida pode ser aplicada. No entanto, uma função de hash homomórfica difere do SHA512 e não é compatível com o BIP32 original.

3.4 OP-DLC: Oracle Trust-minimized

No DLC, o contrato entre Alice e Bob é executado com base no resultado assinado do Oracle, exigindo assim um certo nível de confiança no Oracle. Portanto, o comportamento correto do Oracle é uma premissa importante para o funcionamento do DLC.

Para reduzir a confiança no Oracle, foi realizada uma pesquisa sobre a execução do DLC com base nos resultados de n Oracles, diminuindo a dependência de um único Oracle.

• O modelo “n-of-n” envolve o uso de n Oráculos para assinar o contrato e executar o contrato com base nos resultados de todos os Oráculos. Este modelo requer que todos os Oráculos estejam online para assinar. Se algum Oráculo ficar offline ou houver um desacordo sobre os resultados, isso afeta a execução do contrato DLC. A suposição de confiança aqui é que todos os Oráculos são honestos.
• O modelo "k-of-n" envolve o uso de n Oráculos para assinar o contrato, executando o contrato com base nos resultados de quaisquer k Oráculos. Se mais do que k Oráculos conspirarem, isso afeta a execução justa do contrato. Além disso, o número de CETs necessários no modelo "k-of-n" é C_n^k vezes o de um único Oráculo ou do modelo "n-of-n". A suposição de confiança neste modelo é que pelo menos k dos n Oráculos são honestos.

A simples aumento do número de Oracles não alcança a desconfiança dos Oracles porque, após ações maliciosas por parte de um Oracle, a parte lesada no contrato não tem recurso on-chain.

Portanto, propomos OP-DLC, que incorpora um mecanismo de desafio otimista no DLC. Antes de participarem na configuração do DLC, n Oráculos precisam fazer uma promessa e construir um jogo OP sem permissão on-chain antecipadamente, comprometendo-se a não agir maliciosamente. Se algum Oráculo agir maliciosamente, então Alice, Bob, qualquer outro Oráculo honesto, ou qualquer outro observador honesto de terceiros pode iniciar um desafio. Se o desafiante vencer o jogo, o sistema on-chain penaliza o Oráculo malicioso ao confiscar seu depósito. Além disso, o OP-DLC também pode adotar o modelo "k-de-n" para assinaturas, onde o valor de k pode ser até 1. Portanto, a suposição de confiança é reduzida apenas necessitando de um participante honesto na rede para iniciar um desafio OP e penalizar um nó Oráculo malicioso.

Ao liquidar OP-DLC com base nos resultados da computação da Camada 2:

• Se um Oráculo assinar com resultados incorretos, causando a Alice uma perda, a Alice pode usar os resultados corretos do cálculo da Camada 2 para desafiar o jogo OP sem permissão prévia do Oráculo. Vencendo o jogo, a Alice pode penalizar o Oráculo malicioso e compensar sua perda.
• Da mesma forma, Bob, outros nós oráculo honestos e observadores honestos de terceiros também podem iniciar desafios. No entanto, para prevenir desafios maliciosos, o desafiante também deve fazer uma promessa.

Assim, o OP-DLC facilita a supervisão mútua entre os nós oráculo, minimizando a confiança depositada nos oráculos. Este mecanismo apenas requer um participante honesto e tem uma tolerância a falhas de 99%, abordando eficazmente o risco de colusão de Oráculos.

3.5 OP-DLC + BitVM Dual Bridge

Quando o DLC é usado para pontes entre cadeias, a distribuição de fundos deve ocorrer no momento do acerto do contrato de DLC:

• Isso implica a pré-configuração através dos CETs, significando que a granularidade de liquidação de fundos do DLC é limitada, como 0.1 BTC na rede Bison. Isso levanta um problema: as interações de ativos da Camada 2 para os usuários não devem ser restritas pela granularidade de fundos dos CETs do DLC.
• Quando Alice deseja liquidar seus ativos da Camada 2, força a liquidação dos ativos da Camada 2 do usuário Bob para a Camada 1 também. Isso levanta um problema: cada usuário da Camada 2 deve ter a liberdade de escolher seus depósitos e levantamentos independentemente das ações de outros usuários.
• Alice e Bob negociam gastos. O problema aqui é que requer que ambas as partes estejam dispostas a cooperar.

Portanto, para resolver o problema mencionado anteriormente, propomos a ponte dupla OP-DLC + BitVM. Esta solução permite aos utilizadores depositar e levantar através da ponte sem permissão do BitVM, bem como através do mecanismo OP-DLC, possibilitando alterações em qualquer granularidade e aumentando a liquidez.

No OP-DLC, o Oracle é a federação BitVM, com Alice como utilizadora regular e Bob como a federação BitVM. Ao configurar o OP-DLC, os CETs construídos permitem o gasto imediato da saída de Alice na Camada 1, enquanto a saída de Bob inclui um “jogo DLC que Alice pode desafiar” com um período de timelock. Quando Alice deseja retirar:

• Se a federação BitVM, atuando como o Oráculo, assinar corretamente, Alice pode retirar na Camada 1. No entanto, Bob pode retirar na Camada 1 após o período de bloqueio temporal.
• Se a federação BitVM, atuando como o Oracle, trapacear, causando uma perda para Alice, ela pode desafiar o UTXO de Bob. Se o desafio for bem-sucedido, o montante de Bob pode ser confiscado. Nota: outro membro da federação BitVM também pode iniciar o desafio, mas Alice, sendo a parte prejudicada, é a mais motivada a fazê-lo.
• Se a federação BitVM, atuando como o Oráculo, trapacear, causando uma perda a Bob, um membro honesto da federação BitVM pode desafiar o “jogo BitVM” para penalizar o nó do Oráculo trapaceiro.

Além disso, se o usuário Alice deseja sacar da Camada 2, mas os CETs pré-definidos no contrato OP-DLC não correspondem ao montante, Alice pode escolher os seguintes métodos:

• Retirar através do BitVM, com o operador BitVM a antecipar o montante na Camada 1. A ponte BitVM assume que existe pelo menos um participante honesto na federação BitVM.
• Levante-se através de um CET específico em OP-DLC, com a mudança restante antecipada pelo operador BitVM na Camada 1. Levantar através do OP-DLC irá fechar o canal DLC, mas os fundos restantes no canal DLC irão mover-se para o pool da Camada 1 do BitVM, sem obrigar outros utilizadores da Camada 2 a levantar. A ponte OP-DLC pressupõe que existe pelo menos um participante honesto no canal.
• Alice e Bob negociam despesas sem o envolvimento de um Oracle, exigindo cooperação de Bob.

Assim, a ponte dupla OP-DLC + BitVM oferece as seguintes vantagens:

• O BitVM resolve o problema de alteração do canal DLC, reduz o número de CETs necessários e não é afetado pela granularidade do fundo CET;
• Ao combinar a ponte OP-DLC com a ponte BitVM, fornece aos utilizadores múltiplos canais para depósitos e levantamentos, melhorando a experiência do utilizador;
• Configurar o consórcio BitVM tanto como Bob quanto como o oráculo, e utilizar o mecanismo OP, minimiza a confiança no oráculo;
• Integrar o saque excessivo do canal DLC na piscina de ponte BitVM aumenta a utilização de fundos.

4. Conclusão

DLC surgiu antes da ativação do Segwit v1 (Taproot) e já foi integrado à Lightning Network, permitindo a extensão do DLC para atualizar e executar contratos contínuos dentro do mesmo canal de DLC. Com tecnologias como Taproot e BitVM, verificações e liquidações de contratos off-chain mais complexos podem ser implementadas dentro do DLC. Além disso, ao integrar o mecanismo de desafio OP, é possível minimizar a confiança em Oracles.

Declaração:

1. Este artigo é reproduzido a partir demédio, originalmente intitulado “Tecnologia Principal Bitlayer: DLC e Suas Considerações de Otimização”. Os direitos autorais pertencem ao autor original, Bitlayer. Se houver alguma objeção a esta reimpressão, por favor entre em contato com o Equipe Gate LearnA equipa irá tratar disso de acordo com os procedimentos relevantes o mais rapidamente possível.

2. Aviso Legal: As opiniões expressas neste artigo representam apenas as opiniões pessoais do autor e não constituem qualquer conselho de investimento.

3. Outras versões do artigo foram traduzidas pela equipe Gate Learn. Sem menção de Gate, os artigos traduzidos não podem ser copiados, disseminados ou plagiados.