Finanças nativas do Bitcoin, sem pontes

Curiosidade

1. Como um contrato financeiro pode ser liquidado em satoshis nativos sem a necessidade de introduzir um novo token ou cadeia?
2. Quais suposições específicas de confiabilidade são introduzidas ao usar um oráculo para dados de preço em comparação com sua verificação localmente?
3. Por que a capacidade de sair unilateralmente de volta à camada de base é considerada a principal métrica de segurança para as finanças nativas do Bitcoin?

Explorar

1. Os Contratos Log Discreet, propostos por T. Dryja em 2017, permitem contratos financeiros com Bitcoin usando apenas moedas nativas. Ambas as partes bloqueiam os fundos em uma saída multisig de tipo 2-of-2 e assinam previamente uma transação de pagamento para cada resultado possível; cada uma delas só pode ser utilizada com a assinatura de um adaptador, que é completada somente com a assinatura do oráculo referente àquele resultado. O oráculo publica sua atestação sem saber que o contrato existe. Quando ele atesta, o pagamento correspondente torna-se válido; se falhar ou se comportar de maneira inadequada, um mecanismo de bloqueio temporal permite que os participantes recuperem seu capital após um período definido. Esse design evita a utilização do Bitcoin como token em outra cadeia, mas introduz uma dependência crítica: o usuário precisa confiar que o oráculo não assinará de forma maliciosa e que a rede fará valer o mecanismo de bloqueio temporal.
2. Estruturas de multisig e timelock facilitam protocolos de empréstimo nos quais o mutuário mantém a custódia de suas chaves, enquanto a garantia fica bloqueada. Nesses modelos, o credor possui uma chave e o mutuário outra; um mecanismo de terceiros ou baseado em scripts cuida da liquidação caso a garantia caia abaixo de um determinado limite. Diferentemente dos ativos “wrapped” que exigem um custodiano para criar tokens em outra cadeia, essa abordagem mantém todo o valor dentro do modelo UTXO do Bitcoin. O trade-off é a complexidade na gestão das chaves e o risco de erros no software responsável por criar e assinar essas transações.
3. Os canais da Lightning Network permitem fluxos de pagamento fora da cadeia, que só são liquidados na camada principal quando fechados. Isso reduz o congestionamento e as taxas para transações de alta frequência, mantendo ao mesmo tempo as garantias de finalidade do Bitcoin. O Ark permite que vários usuários compartilhem um único resultado dentro da cadeia, coordenado por um operador; cada usuário possui um caminho pré-assinado para sair sozinho da cadeia caso o operador desapareça. A segurança desses sistemas depende inteiramente do consenso da cadeia subjacente; nenhum novo conjunto de validadores é introduzido, preservando assim o modelo de segurança descentralizado estabelecido em lições anteriores.
4. Os designs no estilo BitVM visam verificar cálculos arbitrários sem modificar as regras de consenso do Bitcoin. A BitVM (Robin Linus, 2023) é otimista: um provedor declara um resultado fora da cadeia, e se alguém o contestar, uma disputa realizada por meio do Script do Bitcoin identifica o único passo errado e penaliza o provedor. Seu principal uso são pontes cuja segurança requer apenas um verificador honesto entre muitos, em vez de uma federação confiável. Ela representa uma mudança significativa das cadeias de propósito geral e completas de Turing em direção a cálculos seletivos e verificáveis.
5. Cada um desses mecanismos introduz pressupostos de confiança distintos que precisam ser avaliados em relação às propriedades fundamentais do Bitcoin. Os oráculos exigem confiança em fontes de dados externas; os contratos multisig exigem confiança na correção do código e no gerenciamento das chaves; os canais de estado exigem confiança em mecanismos de resolução de disputas. O elemento comum é a preservação da autogestão: os usuários podem sempre converter para satoshis nativos sem precisar da permissão de uma fundação ou de uma chave administrativa. Isso contrasta fortemente com ativos embalados, nos quais a conversão requer a passagem por intermediários confiáveis, reintroduzindo o risco de contraparte que os designs nativos evitam.
6. Leia a estrutura da transação nas especificações do DLC (dlcspecs): uma transação de financiamento com uma saída multisig de 2-de-2, uma transação de execução pré-assinada para cada resultado, e uma transação de reembolso bloqueada até um horário definido, caso o oráculo nunca forneça a confirmação. Indique em qual parte cada parte – o oráculo e a cadeia – é considerada confiável.

Fatos-chave

Exercício nove, seis, três, um

Verificação de fatos

Datas, números e afirmações verificados com as fontes publicadas listadas abaixo.

• T. Dryja, 'Discreet Log Contracts' (2017)
• R. Linus, 'BitVM: Compute Anything on Bitcoin' (2023); Discreet Log Contract specifications (github.com/discreetlogcontracts/dlcspecs)
• Lightning Network Whitepaper: J. Poon & T. Dryja (2015/2016)