Jeremy Rubin lançou uma proposta há duas semanas intitulada Un'FE'd Covenants (FE = Functional Encryption). Dado o debate em curso sobre propostas de pacto para Bitcoin nos últimos dois anos, a sua proposta marca uma nova opção prática. Todas as propostas de aliança até agora exigem um soft fork (opcodes reais), o desenvolvimento e implementação de criptografia não comprovada (Criptografia Funcional) ou um custo monetário absurdamente alto para usar (ColliderScript).
A proposta de Jeremy não requer softforks e não impõe um custo oneroso e impraticável de utilização para os usuários. A contrapartida dessa capacidade é um modelo de segurança radicalmente diferente. Usando um sistema de oráculos e títulos baseados em BitVM capazes de reduzir, os convênios podem ser emulados no Bitcoin agora mesmo.
Os oráculos
A primeira parte do esquema são obviamente os oráculos que impõem diferentes condições da aliança. Esta é uma configuração relativamente simples e o primeiro alicerce necessário para a proposta de Jeremy. O oráculo tem a custódia dos fundos deste esquema e é responsável pela aplicação das condições do pacto. Você deseja que o oráculo não precise acompanhar localmente as condições do pacto que estão sendo aplicadas para cada moeda que ele custodia. Isto introduz um risco estatal onde, se o banco de dados dos oráculos for corrompido ou perdido, ele não terá ideia de como lidar com a aplicação honesta das moedas de todos. Para contornar esse problema, Jeremy faz uso do Taproot.
As chaves baseadas em Schnorr podem ser “ajustadas” usando o hash de dados para modificar uma chave pública. Isso permite que o ajuste da chave privada correspondente seja capaz de assinar a chave modificada, bem como provar que quaisquer dados usados para ajustar a chave pública estão comprometidos com essa chave. Fazer com que o oráculo gere uma chave e, em seguida, o usuário ajuste essa chave com seu programa de aliança permite um compromisso com o que o oráculo deve impor, ao mesmo tempo que mantém o fardo de armazenar essas informações sobre o usuário.
Os oráculos também podem ser federados para minimizar a confiança necessária em uma única parte para fazer cumprir as coisas. A partir daqui, os usuários podem simplesmente carregar o endereço resultante e, sempre que quiserem fazer cumprir a condição, abordar o(s) oráculo(s) com a transação de gasto, o programa do oráculo e os dados da testemunha necessários para provar que a transação dada ao oráculo atende. as condições da aliança. Se a transação for válida de acordo com as regras do pacto, o oráculo a assina.
Para qualquer acordo simples onde os resultados são conhecidos antecipadamente, como CHECKTEMPLATEVERIFY (CTV), os usuários podem imediatamente fazer com que o oráculo pré-assine as transações que fazem cumprir o acordo e simplesmente adiar seu uso até que seja necessário.
Um cenário importante a considerar que exige funcionalidade extra são os acordos baseados no estado, como rollups, que progridem regularmente e têm um estado real (o saldo atual dos usuários) para acompanhar. No caso de tais acordos, as transações que o oráculo assina devem comprometer-se com o estado atual do acordo usando OP_RETURN para que o oráculo possa verificar eficientemente cada transação atualizando o rollup ou outro sistema sem ter que baixar dados de testemunha para todo o histórico. Isso evita que o oráculo tenha que armazenar o estado localmente, o que, conforme observado acima, cria riscos.
No longo prazo, os requisitos de dados dos oráculos podem ser otimizados usando provas de conhecimento zero, de modo que o oráculo possa simplesmente verificar uma prova de que a transação que ele está sendo solicitado a assinar segue as regras do pacto, sem ter que verificar os dados brutos das testemunhas. para acordos maiores e mais complexos. Mais uma vez, porém, 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 para que eles os tenham em sua posse caso precisem entrar em contato diretamente com o oráculo para recuperar seus dados. fundos.
O vínculo BitVM
Até agora, o esquema é totalmente confiável. Basicamente, você está apenas dando seu dinheiro a outra pessoa e esperando que ela seja confiável para fazer cumprir as condições de acordos arbitrários. Ao modificar ligeiramente o esquema acima, isto pode ser garantido com um incentivo criptoeconómico em vez de pura confiança.
Acima foi descrito como OP_RETURN deve ser usado para rastrear o estado de acordos com estado. OP_RETURN também pode ser usado para publicar os dados testemunhais de quaisquer transações de aliança para provar que as condições foram cumpridas corretamente.
Um circuito BitVM pode ser construído para verificar se uma transação assinada pelo oráculo corresponde com sucesso às condições do pacto que está aplicando. Lembre-se de que a própria chave gerada e os fundos enviados comprometem-se com as condições de qualquer acordo que esteja sendo aplicado. O que significa que os dados, bem como uma transação gasta a partir do endereço, podem ser inseridos em uma instância BitVM.
Os Oráculos podem então ser obrigados a depositar uma garantia com um operador BitVM (que também deve depositar uma fiança para o Oráculo reivindicar se forem falsamente acusados). Dessa forma, desde que o valor do título seja superior ao valor garantido em convênios por um oráculo, o sistema pode ser utilizado com segurança. Não haveria maneira de um oráculo violar as condições de um pacto que está aplicando sem perder dinheiro no total.
Compensações
Existem aqui compromissos claros que são materialmente piores do que simplesmente implementar acordos em regras de consenso. Em primeiro lugar, o oráculo deve estar online e acessível para poder fazer uso dos acordos impostos pelo oráculo. Com exceção de convênios pré-assinados, como CTV, se o oráculo estiver offline quando os usuários precisarem fazer cumprir um convênio, eles não poderão. O oráculo deve estar presente para assinar.
Em segundo lugar, os requisitos de liquidez para as obrigações oracle podem tornar-se enormes se o sistema algum dia for amplamente adoptado. Isso o torna incrivelmente ineficiente em comparação com a implementação nativa de opcodes de aliança no nível de consenso.
Por último, os dados extras necessários para serem publicados na cadeia para que o esquema de títulos BitVM funcione são muito menos eficientes com o uso do espaço de bloco do que as implementações de aliança nativa.
No geral, a proposta não é nem de longe tão eficiente e segura quanto os pactos locais. Por outro lado, se acabarmos no pior cenário de ossificação prematura, esta é uma maneira muito viável de impor acordos ao Bitcoin sem depender de criptografia não comprovada ou de custos completamente impraticáveis impostos aos usuários finais.
Jeremy nos deu a opção do pior cenário para expandir o espaço de design do que pode ser construído no Bitcoin.
Fonte: bitcoinmagazine.com
