1. Introdução

O Contrato de Log Discreto (DLC) é uma estrutura de execução contratual baseada em um Oráculo, proposta 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 os resultados possíveis, pré-assinam os mesmos e usam essas pré-assinaturas para realizar pagamentos quando o Oráculo aprova o resultado. Portanto, o DLC possibilita novas aplicações financeiras descentralizadas, garantindo a segurança dos depósitos de Bitcoin.

Comparado à Lightning Network, DLC tem as seguintes vantagens significativas:

• Privacidade: DLC oferece uma proteção de privacidade melhor do que a Lightning Network. Os detalhes do contrato são compartilhados apenas entre as partes envolvidas e não são armazenados no blockchain. Em contraste, as transações da Lightning Network são roteadas por canais e nós públicos, tornando 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 aplicativos complexos.
• Risco Contraparte Reduzido: Os fundos do DLC são bloqueados em contratos multi-assinatura e são liberados apenas 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, ainda carrega certos riscos de contraparte na gestão de canais e provisão de liquidez.
• Não é necessário gerenciar canais de pagamento: as operações de DLC não exigem a criação ou manutenção de canais de pagamento, que são essenciais para a Lightning Network e envolvem um gerenciamento complexo e intensivo em recursos.
• Escalabilidade para Casos de Uso Específicos: Embora a Lightning Network aumente um pouco a taxa de transação do Bitcoin, o DLC oferece uma melhor escalabilidade para contratos complexos na rede do Bitcoin.

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

• Risco-chave: Existe o risco de vazamento ou perda das chaves privadas da Oracle e dos números aleatórios comprometidos, levando à perda dos ativos do usuário.
• Risco de Confiança Centralizado: A centralização nos Oráculos pode facilmente levar a ataques de negação de serviço.
• Problema de Derivação de Chave Descentralizada: Se o Oracle for descentralizado, os nós do Oracle possuem apenas partes da chave privada. No entanto, os nós do Oracle descentralizados não podem usar diretamente o BIP32 para a derivação de chave 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 de confiança com os Oracles permanece sem solução. É necessário um mecanismo de monitoramento confiá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. Portanto, o uso de 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 esses problemas, este artigo propõe várias soluções e ideias de otimização para mitigar os riscos e questões associados aos DLCs, melhorando assim a segurança do ecossistema do Bitcoin.

2. Princípio DLC

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

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

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

• A chave privada do Oracle é z, e sua chave pública é Z, satisfazendo Z=z⋅G;
• A chave privada de Alice é x, e sua chave pública é X, satisfazendo X=x⋅G;
• A chave privada de Bob é y, e sua chave pública é 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 Oracle calcula o compromisso

e então 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 bloco (n+k)-ésimo, o Oracle gera o s ou s' correspondente com base no valor de hash desse bloco.

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

• Se o valor hash do bloco (n+k) é par, o Oráculo calcula e transmite

Retirada: Alice ou Bob podem retirar os ativos com base no s ou s′ transmitido pelo Oráculo.

• Se o Oracle transmitir s, Alice pode calcular a nova chave privada sk^{Alice} e sacar 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 o relacionamento do logaritmo discreto

Assim, o saque da 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 o relacionamento do logaritmo discreto

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

Além disso, se o Oracle transmitir s, é útil para Alice, mas não para Bob porque Bob não pode calcular a nova chave privada correspondente sk^{Bob}. Da mesma forma, se o Oracle transmitir s′, é útil para Bob, mas não para Alice, porque Alice não pode calcular a nova chave privada correspondente sk^{Alice}. Finalmente, a descrição acima omite o bloqueio de tempo. Um bloqueio de tempo deve ser adicionado para permitir que uma parte calcule a nova chave privada e retire dentro do tempo t. Caso contrário, se exceder o tempo t, a outra parte pode usar a chave privada original para retirar os ativos.

3. Otimizações do DLC

3.1 Gerenciamento de Chaves

No protocolo DLC, a chave privada do Oracle e o nonce comprometido são cruciais. O vazamento ou perda da chave privada do Oracle e do nonce comprometido pode levar aos seguintes quatro problemas de segurança:

(1) Oracle Perde Chave Privada z

Se o Oráculo perder sua chave privada, o DLC não pode ser liquidado, sendo necessária a execução de um contrato de reembolso de DLC. Portanto, o protocolo DLC inclui uma transação de reembolso para evitar as consequências do Oráculo perder sua chave privada.

(2) Vazamento da chave privada z da Oracle

Se a chave privada do Oracle for vazada, 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 (n+k)-ésimo bloco é tanto ímpar quanto par.

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

Se o Oracle vazar o nonce k, então na fase de liquidação, independentemente de o Oracle transmitir s ou s′, um atacante pode calcular a chave privada z do Oracle 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 Oracle perder o nonce k, o DLC correspondente não pode ser liquidado, o que torna 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 Oráculo é crucial, pois fornece dados externos essenciais que determinam o resultado do contrato. Para aumentar a segurança desses contratos, são necessários Oráculos descentralizados. Ao contrário dos Oráculos centralizados, os Oráculos descentralizados distribuem a responsabilidade de fornecer dados precisos e à prova de manipulação entre 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 Oráculo descentralizado, os DLCs podem alcançar um maior grau 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 aprimorada: 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.
• Controle Distribuído: As assinaturas de limiar permitem o controle distribuído sobre a gestão de chaves, eliminando uma única entidade para deter todos os poderes de assinatura, reduzindo assim os riscos associados à concentração de poder.
• Disponibilidade melhorada: As assinaturas podem ser concluídas desde que um certo número de nós Oracle concorde, aumentando a flexibilidade e a 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 de assinatura com base na sua parte de chave privada, e outros participantes podem verificar a correção dessa parte de assinatura usando a parte de chave pública correspondente, possibilitando a responsabilidade. Se estiver correto, essas partes de assinatura são acumuladas para produzir uma assinatura completa.

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

3.3 Acoplamento de Descentralização e Gerenciamento de Chaves

Na tecnologia de gerenciamento de chaves, um Oráculo possui uma chave completa z e, usando BIP32 juntamente com incrementos ω, pode derivar uma infinidade 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 os respectivos eventos msg.

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

No entanto, em um 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 gerenciamento de chaves não podem ser integradas diretamente.

O artigo "Derivação de Chave Distribuída para Gerenciamento Multi-Partes de Ativos Digitais de Blockchain"propõe um esquema de derivação de chave distribuída em cenários de assinatura de limiar. A ideia central é baseada em polinômios de interpolação de Lagrange, onde a parte da chave privada 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 parcela 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 parcela da chave privada filha z_i+ω e a chave filha z+ω satisfazem a relação de interpolação. Portanto, cada participante pode usar sua parcela da chave privada z_i mais o incremento ω para derivar a parcela da chave privada filha z_i+ω, usada para gerar parcelas de assinatura filha, e validá-las usando a chave pública filha correspondente Z+ω⋅G.

No entanto, deve-se considerar BIP32 endurecido e não endurecido. BIP32 endurecido recebe a chave privada, o código de cadeia e o caminho como entrada, realiza SHA512 e gera o incremento e o código de cadeia filho. Por outro lado, o BIP32 não endurecido recebe a chave pública, o código de cadeia e o caminho como entrada, realiza SHA512 e gera o incremento e o código de cadeia filho. Em um cenário de assinatura de limite, a chave privada não existe, portanto, apenas o BIP32 não endurecido pode ser usado. Ou, usando uma função de hash homomórfica, o BIP32 endurecido pode ser aplicado. 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 a operação do DLC.

Para reduzir a confiança no Oracle, foram realizadas pesquisas sobre a execução de 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 Oracles para assinar o contrato e executar o contrato com base nos resultados de todos os Oracles. Este modelo requer que todos os Oracles estejam online para assinar. Se algum Oracle ficar offline ou houver discordância nos resultados, isso afeta a execução do contrato de DLC. A suposição de confiança aqui é que todos os Oracles 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 o 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 Oráculos não alcança a desconfiança dos Oráculos porque, após ações maliciosas por um Oráculo, a parte prejudicada no contrato não tem recurso on-chain.

Portanto, propomos OP-DLC, que incorpora um mecanismo de desafio otimista na DLC. Antes de participar da configuração do DLC, n Oráculos precisam se comprometer e construir um jogo OP on-chain sem permissão com antecedência, 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 Oracle malicioso, perdendo seu depósito. Além disso, o OP-DLC também pode adotar o modelo "k-of-n" para assinatura, onde o valor de k pode até ser 1. Portanto, a suposição de confiança é reduzida a apenas precisar de um participante honesto na rede para iniciar um desafio de OP e penalizar um nó Oracle mal-intencionado.

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

• Se um Oráculo assina com resultados incorretos, causando prejuízos a Alice, Alice pode usar os resultados corretos do cálculo da Camada 2 para desafiar o jogo OP permissionless on-chain adiantado do Oráculo. Vencendo o jogo, Alice pode penalizar o Oráculo malicioso e compensar suas perdas.
• Da mesma forma, Bob, outros nós Oracle honestos e observadores honestos de terceiros também podem iniciar desafios. No entanto, para evitar desafios maliciosos, o desafiador também deve fazer um compromisso.

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

3.5 OP-DLC + BitVM Ponte Dupla

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

• Exige pré-configuração por meio de CETs, o que significa 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, ela força a liquidação dos ativos do usuário Bob da Camada 2 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 saques independentemente das ações de outros usuários.
• Alice e Bob negociam gastos. O problema aqui é que requer a disposição de ambas as partes para cooperar.

Portanto, para resolver a questão mencionada, propomos a ponte dupla OP-DLC + BitVM. Essa solução permite aos usuários depositar e sacar por meio da ponte sem permissão do BitVM, bem como por meio do mecanismo OP-DLC, possibilitando alterações em qualquer granularidade e aumentando a liquidez.

No OP-DLC, o Oráculo é a federação BitVM, com Alice como uma usuária regular e Bob como a federação BitVM. Ao configurar o OP-DLC, os CETs construídos permitem gastos imediatos 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 tempo bloqueado. Quando Alice deseja sacar:

• Se a federação BitVM, atuando como o Oráculo, assinar corretamente, Alice pode sacar na Camada 1. No entanto, Bob pode sacar na Camada 1 após o período de bloqueio temporal.
• Se a federação BitVM, atuando como o Oráculo, trapacear, causando uma perda para Alice, ela pode desafiar o UTXO de Bob. Se o desafio for bem-sucedido, a quantia de Bob pode ser confiscada. Observação: 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, trapaceia, causando uma perda para 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 a usuária Alice quiser sacar da Camada 2, mas os CETs predefinidos no contrato OP-DLC não corresponderem ao valor, Alice pode escolher os seguintes métodos:

• Retirar através do BitVM, com o operador BitVM adiantando a quantia na Camada 1. A ponte do BitVM pressupõe que haja pelo menos um participante honesto na federação BitVM.
• Retirar através de um CET específico em OP-DLC, com o troco restante fornecido pelo operador BitVM na Camada 1. Retirar através de OP-DLC fechará o canal DLC, mas os fundos restantes no canal DLC serão transferidos para o pool da Camada 1 do BitVM, sem forçar outros usuários da Camada 2 a retirar. A ponte OP-DLC pressupõe que haja pelo menos um participante honesto no canal.
• Alice e Bob negociam os gastos sem o envolvimento de um Oracle, exigindo cooperação de Bob.

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

• BitVM resolve o problema de troca 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 usuários vários canais para depósitos e saques, melhorando a experiência do usuário;
• 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 excedente do canal DLC no pool de ponte BitVM aumenta a utilização de fundos.

4. Conclusão

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 fora da cadeia mais complexos podem ser implementados dentro do DLC. Além disso, ao integrar o mecanismo de desafio OP, é possível minimizar a confiança nos Oracles.

Declaração:

1. Este artigo foi reproduzido de médio, originalmente intitulado “Tecnologia Core do Bitlayer: DLC e Suas Considerações de Otimização”. Os direitos autorais pertencem ao autor original, Camada de Bit. Se houver alguma objeção a este reenvio, entre em contato com o Time de Aprendizagem do GateA equipe irá lidar com isso de acordo com os procedimentos relevantes o mais rápido possível.

2. Aviso Legal: As opiniões expressas neste artigo representam apenas as visõ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.io, os artigos traduzidos não podem ser copiados, divulgados ou plagiados.