0. Introdução
A Web3 remodelou o valor dos dados, mas a estrutura distribuída do blockchain é um sistema determinístico fechado, e os contratos inteligentes não implementam a função de chamadas externas de API, portanto, o mecanismo oracle nasceu para ajudar os contratos inteligentes a obter dados externos.
Não é difícil carregar dados fora da cadeia para a cadeia. O que é difícil é conceber e produzir confiança através de tecnologia e mecanismos. O problema do oráculo requer a resolução do problema da confiança desde a fonte de dados até ao processamento e alimentação de preços.
Uma condição básica para se tornar um oráculo reconhecido publicamente é a descentralização, ou seja, se são permitidos pontos únicos de falha e verificação de dados. Uma solução comum para a descentralização da cadeia é usar vários nós de dados para formar uma rede oráculo descentralizada. Cada nó coletará dados e os inserirá em um contrato inteligente no blockchain após chegar a um consenso.
Arquitetura de elo de corrente
O principal uso atual dos oráculos é fornecer feed de preços para DeFi e atualizar o preço dos ativos subjacentes de forma segura, oportuna e precisa. De acordo com dados da DefiLlama, Chainlink é uma das maiores soluções oráculo do mercado, com um valor total garantido de aproximadamente US$ 11 bilhões no momento em que este artigo foi escrito, representando 46% do mercado total.
Dados de mercado da Oracle
Com o desenvolvimento do blockchain, a demanda por dados fora da cadeia está ficando cada vez mais forte. Simplesmente alimentar os preços do DeFi não pode mais atender às necessidades dos desenvolvedores. A grande maioria dos dados no mundo real e na Web2 não são acessíveis ao público, mas é necessário construir cenários inovadores de aplicações Web3 (empréstimo de crédito, redes sociais, DID, KYC/AML, etc.). Uma nova geração de oráculos precisa, portanto, permitir que os contratos inteligentes apoiem casos de utilização complexos que envolvam dados sensíveis, de uma forma que preserve a privacidade.
DECO é a solução da Chainlink nessa direção, usando tecnologia de prova de conhecimento zero para permitir que os usuários gerem provas de dados privados fora da cadeia para contratos inteligentes sem revelar os dados ao público ou ao próprio nó oracle. O DECO pode ser conectado a APIs existentes e não requer nenhuma modificação por parte do provedor de dados da API, mesmo que a autenticação do usuário final seja necessária (por exemplo, obter o saldo de uma conta bancária requer login). Chegou agora à fase alfa e está testando a prova de conceito com vários parceiros.
1. Histórico
O histórico necessário sobre TLS e ZKP é fornecido aqui, e o DECO é construído com base nesses protocolos.
1.1 TLS
TLS (Transport Layer Security) é um protocolo de segurança poderoso e amplamente implantado, anteriormente SSL, projetado para promover a privacidade e a segurança dos dados das comunicações da Internet, localizado na camada de protocolo de aplicação e na camada TCP/IP. Entre eles, o principal caso de uso é criptografar a comunicação entre aplicativos da web e servidores.
A comunicação por HTTP é feita em texto simples e é suscetível a espionagem, adulteração e falsificação de identidade. Com o TLS, os dados HTTP que os usuários enviam ao site (clique, preencha um formulário, etc.) e os dados HTTP que o site envia ao usuário são criptografados, e o destinatário deve usar uma chave para descriptografar os dados criptografados. HTTPS implementa criptografia TLS com base no protocolo HTTP. É uma prática padrão para sites que precisam instalar um certificado TLS em seu servidor de origem e os navegadores marcarão todos os sites não HTTPS como inseguros.
Site não HTTPS
A ideia básica do TLS é usar criptografia de chave pública. O certificado TLS/SSL compartilhado publicamente pelo site contém a chave pública, e a chave privada é instalada no servidor de origem e de propriedade do site. O cliente primeiro solicita ao servidor a chave pública do certificado digital e, em seguida, usa a chave pública para criptografar as informações. Depois que o servidor recebe o texto cifrado, ele usa sua própria chave privada para descriptografá-lo.
Há um problema aqui: a criptografia de chave pública requer muitos cálculos. Para reduzir o tempo consumido pela sessão, o cliente e o servidor geram uma "chave de sessão" para cada sessão e a utilizam para criptografar as informações. Como a “chave de sessão” é criptografada simetricamente, a velocidade de operação é muito rápida, e a chave pública do servidor é usada apenas para criptografar a própria “chave de sessão”, o que reduz o tempo consumido pela operação de criptografia.
Portanto, o protocolo TLS pode ser dividido principalmente em duas camadas:
Protocolo handshake para negociação de chaves de autenticação: comunicação em texto simples, confirmação mútua e verificação mútua através de criptografia assimétrica, estabelecendo o algoritmo de criptografia a ser usado e gerando uma chave de sessão consistente para registrar a criptografia simétrica do acordo
Protocolo de registro para transmissão simetricamente criptografada: o corpo principal do protocolo, que protege a confidencialidade e integridade da transmissão de dados
Pilha de protocolo TLS
O conjunto de criptografia TLS (CipherSuite) é uma combinação de 4 algoritmos:
Autenticação: Determine a autenticidade da identidade, os principais são RSA/DSA/ECDSA
Troca de chaves: As partes comunicantes negociam a chave usada para criptografia. A principal é a ECDHE.
Criptografia: Criptografia simétrica para comunicação, a tendência é usar GCM
MAC (código de autenticação de mensagem, código de autenticação de mensagem): usado para verificar a integridade dos dados e se os dados foram adulterados. Os principais incluem SHA256/SHA384/SHA1, etc.
O TLS é muito poderoso, mas tem uma limitação: não permite que o usuário prove a terceiros que os dados que ele acessa realmente vêm de um site específico. Como a transmissão de dados utiliza criptografia simétrica, o usuário e o servidor têm a vantagem. mesma capacidade de assinar os dados. Um exemplo intuitivo é que as informações de identidade de Alice são armazenadas nos servidores de muitos sites. Pode ser facilmente verificado que Alice tem mais de 18 anos, mas é difícil para Alice provar isso a Bob. Alice poderia tirar uma captura de tela do site, mas as capturas de tela são facilmente falsificadas e, mesmo que a captura de tela pudesse ser comprovada como autêntica, ela revelaria informações - a data exata de nascimento de Alice, não apenas o fato de ela ter mais de 18 anos.
A máquina oráculo precisa ser descentralizada (sem depender de um único ponto, como um servidor de site) para provar a procedência de dados privados fora da cadeia e ser usada por contratos inteligentes sem vazar privacidade. As provas de conhecimento zero podem ajudar a atingir essas funções.
1.2 CPC
Zero Knowledge Proof (ZKP) recebeu ampla atenção no blockchain, e suas principais aplicações são ZK-Rollup (muitos compromissos foram feitos no design do algoritmo para melhorar a eficiência da expansão, sem a Validity Proof de ZK) e tecnologia de privacidade (real zk). A prova de conhecimento zero permite que o Provador prove ao Verificador que possui uma solução (Testemunha) que pode resolver um determinado problema computacional (Declaração) sem revelar qualquer informação adicional sobre a solução (Testemunha).
Um sistema ZK típico pode ser dividido em front-end e back-end.
Front-end: compilador, que escreve a instrução que precisa ser verificada em uma linguagem específica de domínio (DSL) e depois a compila em um formato compatível com ZK, como circuitos aritméticos;
Backend: sistema de prova, sistema de demonstração interativo que verifica a exatidão do circuito, como Marlin, Plonky2, Halo2;
Sistema ZK
O processo de construção de perguntas interativas em um sistema aberto como o blockchain é muito complicado e a prova precisa ser verificada por qualquer pessoa a qualquer momento. Portanto, o sistema ZK no aplicativo blockchain geralmente não é interativo e o Fiat-Shamir-. pode ser usado de forma interativa.
2. Como funciona o DECO
DECO foi estendido com base no protocolo HTTPS/TLS para que o servidor possa ser usado sem modificações.
A ideia central do DECO é construir um novo protocolo de handshake de três partes entre Prover (usuário ou Dapp executando DECO Prover), Verifier (oráculo Chainlink executando DECO Verifier) e Server (provedor de dados).
Proveniência: Quando o Prover consulta informações do Servidor Web, o Verifier testemunha o processo de interação e recebe um Compromisso criado pelo Prover sobre os dados da sessão TLS, para que o Verifier possa verificar a verdadeira fonte da informação;
Privacidade: se os dados não exigirem privacidade, o Prover pode fornecer diretamente a chave que pode descriptografar os dados ao Verifier para que os desenvolvedores adicionem dados ao Dapp, se a privacidade for necessária, o Prover usa ZKP para gerar provas que não vazam dados para os desenvolvedores; adicione ao Dapp.
Exemplo DECO
Especificamente, o protocolo DECO consiste em três fases:
O handshake de três partes, o Prover, o Verifier e o Server estabelecem uma chave de sessão em um formato especial para garantir que os dados não possam ser falsificados;
Execução de consulta, Prover usa Query com seus parâmetros privados θs (como senha da conta, chave API) para consultar dados do servidor;
Geração de prova, o Prover prova que a resposta satisfaz as condições exigidas.
Arquitetura DECO
2.1 Aperto de mão de três partes
Nota: As instruções a seguir são baseadas no algoritmo de criptografia AES-CBC-HMAC. O TLS 1.3 mantém apenas o AEAD mais seguro como algoritmo de criptografia, usando uma chave para criptografia e MAC, e nenhuma chave MAC é necessária. No entanto, devido à independência de chave do TLS 1.3, um protocolo de handshake de três partes com complexidade semelhante também pode ser construído.
O Provador P não pode se comprometer após obter a chave MAC, caso contrário ele pode falsificar ou adulterar os dados. Portanto, a ideia do handshake de três partes é usar o Provador P e o Verificador V como clientes TLS para estabelecer um MAC compartilhado. chave com servidor TLS S . A chave MAC k é dividida no lado do cliente, o Provador contém kp e o Verificador contém kv, k=kp+kv. Ao mesmo tempo, P também contém a chave de criptografia k^{Enc} usada para o algoritmo de criptografia simétrica. Se o verificador não fizer o mal, o protocolo de handshake de três partes pode garantir que os dados não sejam falsificáveis.
2.2 Execução da consulta
Após o handshake, como a chave MAC é compartilhada secretamente, P e V executam um protocolo interativo (computação segura de duas partes) e usam os parâmetros privados θs para construir uma consulta criptografada de mensagem TLS Query Q. Então P atua como um cliente TLS padrão e envia Q para S. Nesse processo, apenas P se comunica com S, e qualquer consulta que ele envia não pode ser vazada para V.
Após receber a resposta R de S, P se compromete com a sessão enviando o texto cifrado Rˆ para V e recebe o kv de V para verificar a autenticidade da resposta R.
2.3 Geração de prova
Em seguida, P precisa provar que o texto simples R correspondente ao texto cifrado Rˆ satisfaz certos atributos. Se a privacidade não for necessária, a chave de criptografia k^{Enc} pode ser revelada diretamente. Se a privacidade for necessária, a prova de conhecimento zero precisa ser revelada. usado.
Se o texto simples consiste em vários blocos de dados R=(B1,...,Bn), o DECO usa a Abertura Seletiva para gerar uma prova de conhecimento zero:
Revele apenas linhas de dados específicas: prove que o i-ésimo bloco de dados de R é Bi sem revelar outros blocos de dados
Ocultar linhas de dados contendo dados privados: provar que R_{-i} e R são iguais, exceto que Bi é excluído
No entanto, muitas vezes o Verifier precisa verificar se a substring revelada aparece no contexto correto, e os métodos mencionados acima não são suficientes para fornecer proteção de integridade do contexto. Para compensar isso, o DECO utiliza uma tecnologia chamada análise de dois estágios de conhecimento zero: o Prover analisa os dados da sessão localmente, determina a menor substring que pode convencer o Verifier e, em seguida, envia os dados para o Verifier. A privacidade é assim alcançada.
Provas de conhecimento zero puras e não interativas (NIZK) geralmente têm alta sobrecarga no lado do Prover em termos de computação e memória. Como o verificador de ZKP realizado pelo DECO é especificado (oráculo do Chainlink), provas interativas de conhecimento zero mais eficientes podem ser usadas, como menor uso de memória, evitação de configurações confiáveis, cálculos baratos, etc.
No Alpha Test atual, o DECO ainda usa Dapp para atuar como Prover. Em iterações futuras, está planejado que o Prover possa ser implantado localmente por usuários finais (como telefones celulares) ou implantado em um Ambiente de Execução Confiável (TEE).
3. Aplicação
A DECO pode verificar a validade das informações de identidade fora da cadeia dos utilizadores, garantindo ao mesmo tempo a privacidade dos dados, desbloqueando assim muitos cenários inovadores de aplicações Web3, desde económicos até sociais.
Recuperação social auto-hospedada/prova de identidade legal (quem é você): Usando o DECO, aproveite sites institucionais (bancos, mídias sociais) que já possuem mecanismos de autenticação maduros para atuar como um dos guardiões da recuperação social.
Empréstimo de crédito/prova de fundos (quanto dinheiro você tem): Teller é um protocolo de empréstimo de crédito DeFi que usa o protocolo DECO para provar que o saldo de ativos do usuário na conta bancária fora da rede excede o limite mínimo dinâmico exigido para empréstimos.
Prova de seguidor/prova de interação (com quem você interagiu): Clique é um oráculo social que desenvolve uma solução que fornece influência do usuário fora da rede, lealdade em várias plataformas de mídia social (por exemplo, usando a API do Twitter) e análise aprofundada das contribuições.
Prova de identidade digital/identidade social (você tem uma conta online): PhotoChromic é uma solução de identidade digital que usa DECO para vincular usuários Web3 às suas contas sociais do Twitter ou Discord sem expor os dados de identificação pessoal subjacentes no processo. Usuários.
A resistência do DAO aos ataques Sybil, SBT, KYC/AML, etc.
4. Outros jogadores
Axiom constrói oráculos ZK para Uniswap TWAP, usando fontes de dados verificáveis completamente da cadeia, mais semelhantes à Indexação (por exemplo, Hyper Oracle e DECO são mais complementares do que competitivos: mais e mais atividades econômicas acontecerão na cadeia, puras on-); os oráculos da cadeia são uma direção; cada vez mais dados fora da cadeia precisam ser carregados na cadeia, e os oráculos de privacidade fora da cadeia também são uma direção.
A Empiric Network usa a computação zk para colocar todo o oráculo na cadeia. Não há infraestrutura fora da cadeia pela qual os dados devam fluir.
4. Conclusão
Chainlink é líder absoluto em oráculos atuais. Através do oráculo DECO, enormes dados privados fora da cadeia podem ser chamados por contratos inteligentes na cadeia sob a premissa de proteção de privacidade, o que pode desbloquear muitos cenários de aplicação, desde finanças até identidade e redes sociais. Os riscos potenciais são a velocidade de geração de provas do Prover e os problemas de centralização do Verifier.
