Jeremy Rubin lançou uma proposta há duas semanas intitulada Un'FE'd Covenants (FE = Functional Encryption). Dado o debate em curso sobre as propostas de liquidação do Bitcoin ao longo dos últimos dois anos, a sua proposta marca uma nova opção viável. Todas as propostas de consenso até agora exigem um soft fork (opcodes reais), o desenvolvimento e uso de criptografia não comprovada (Active Encryption) ou um custo de capital absurdamente alto para implementar (ColliderScript).
A proposta de Jeremy não exige softforks e não impõe custos pesados e impraticáveis aos usuários que devem implementá-los. A contrapartida dessa capacidade é um modelo de segurança muito diferente. Usando um sistema de previsão, com títulos baseados em BitVM que podem ser cortados, os contratos podem ser simulados em Bitcoin agora mesmo.
Oráculos
A primeira parte do plano são obviamente os predicados que impõem diferentes condições de acordo. Esta é uma configuração simples e o primeiro alicerce necessário na proposta de Jeremy. O oráculo tem a custódia dos fundos deste acordo e é encarregado de fazer cumprir os termos do acordo. Você deseja que o oráculo não precise acompanhar as condições de consenso aplicadas a cada moeda armazenada. Isto representa um risco estatal de que, se o banco de dados dos oráculos for danificado ou perdido, eles não saibam como lidar com a aplicação confiável das moedas de todos. Para lidar com esse problema, Jeremy usa Taproot.
As chaves baseadas em Schnorr podem ser “modificadas” usando um hash dos dados para modificar a chave pública. Isso permite a troca da chave privada correspondente para que você possa assinar a chave alterada e garantir que quaisquer dados usados para modificar a chave pública sejam confirmados por essa chave. Fazer com que o oráculo gere uma chave e, em seguida, o usuário modifique essa chave com seu próprio sistema de acordo permite um compromisso com o que o oráculo deve afirmar, ao mesmo tempo que mantém o ônus de manter essas informações sobre o usuário.
Os oráculos também podem ser combinados para reduzir a confiança necessária em uma das partes para fazer cumprir as coisas. A partir daqui, os usuários podem simplesmente fazer upload do endereço resultante e, sempre que quiserem fazer cumprir uma condição, abordam o oráculo com a função de gasto, o programa de voz e os dados da testemunha necessários para provar que a função dada pelo oráculo atende. condições do acordo. Se a transação funcionar de acordo com as regras do acordo, o oráculo a assina.
Em qualquer contrato simples onde os resultados são conhecidos antecipadamente, como CHECKTEMPLATEVERIFY (CTV), os usuários podem rapidamente ter uma palavra a dizer e pré-assinar as funções que fazem cumprir o contrato e simplesmente esquecer de usá-las até que seja necessário.
Uma situação importante a considerar e que requer mais funcionalidades são os acordos baseados em estado, como rollups, que são contínuos e têm status em tempo real (saldo atual do usuário) para serem rastreados. No caso de tais acordos, os tokens de voz das operações devem ser executados no estado atual do acordo usando OP_RETURN para que a voz possa verificar cada operação que atualiza o lançamento ou outro sistema sem baixar os dados testemunhas de todo o histórico. Isso evita que a Oracle tenha que armazenar o estado localmente, o que, conforme observado acima, cria um risco.
Com o tempo, os requisitos de dados dos oráculos podem ser melhorados usando prova de conhecimento, de modo que o oráculo simplesmente verifique a prova de que o trabalho que eles são solicitados a assinar segue as regras do acordo sem verificar os dados brutos das testemunhas. para acordos grandes e complexos. Novamente, no caso de sistemas como rollups, deve-se tomar cuidado ao projetá-los para garantir que os dados necessários para sair do sistema sejam disponibilizados aos usuários caso precisem entrar em contato diretamente com a Oracle para recuperar fundos.
Título BitVM
Até agora o sistema é totalmente confiável. Você está basicamente dando seu dinheiro a outra pessoa e esperando que ela seja confiável para usar termos injustos. Mudando um pouco o sistema acima, isso pode ser garantido com um incentivo criptoeconômico em vez de pura confiança.
Acima é explicado como OP_RETURN deve ser usado para rastrear o status de protocolos estritos. OP_RETURN também pode ser usado para publicar dados testemunhais de qualquer transação para garantir que as condições sejam cumpridas corretamente.
Um circuito BitVM pode ser construído para verificar se uma transação assinada por um oráculo cumpre com êxito os termos do contrato que ele aplica. Lembre-se de que a própria chave é gerada e o dinheiro enviado é vinculado aos termos de qualquer contrato utilizado. O que significa que os dados, bem como o trabalho gasto no endereço, podem ser colocados na instância do BitVM.
Em seguida, os Oráculos podem ser obrigados a prestar uma fiança com o usuário do BitVM (que também deve prestar uma fiança para a Oracle reivindicar se for falsamente acusado). Dessa forma, desde que o valor do título seja superior ao valor garantido nos contratos com a oráculo, o sistema pode ser utilizado com segurança. Não haverá forma de o profeta quebrar os termos do acordo que estão a fazer cumprir sem perder o dinheiro já incluído.
Compensações
Há aqui um compromisso óbvio que é pior do que utilizar convenções em regras de consenso. Primeiro, o oráculo deve estar online e acessível para usar os protocolos oráculos impostos. Sem acordos pré-assinados, como o CTV, se o oráculo estiver offline quando os usuários precisarem fazer cumprir o acordo, eles não conseguirão fazê-lo. O oráculo deve estar presente para ser assinado.
Em segundo lugar, os requisitos de liquidez das obrigações Oracle poderiam ser substanciais se o esquema se tornasse amplamente aceite. Isso o torna incrivelmente ineficiente em comparação com a implementação nativa de códigos de operação de consenso no nível de consenso.
Finalmente, os dados adicionais necessários para serem enviados na cadeia para que o sistema de títulos BitVM funcione são menos eficientes com implementações de blockspace do que com implementações de consenso nativo.
No geral, esta proposta não é nem de longe tão eficiente e segura como os acordos tradicionais. Por outro lado, se chegarmos ao pior caso de ossificação pré-maturidade, esta é a maneira mais eficiente de fazer acordos de calçada em Bitcoin sem depender de criptografia não verificada ou de custos completamente impossíveis impostos aos usuários finais.
Jeremy nos deu a opção do pior cenário possível para expandir o espaço de design do que pode ser construído no Bitcoin.
