Chainlink: децентрализованная сеть Oracle

Resumo

Neste whitepaper, articulamos uma visão para a evolução do Chainlink além de sua concepção inicial no whitepaper Chainlink original. Nós prevemos um papel cada vez mais expansivo para redes oracle, no qual elas complementam e aprimoram blockchains existentes e novos, fornecendo serviços rápidos, confiáveis e conectividade universal que preserva a confidencialidade e computação fora da cadeia para smart contracts. A base do nosso plano é o que chamamos de Redes Oracle Descentralizadas, ou DONs para abreviar. Um DON é uma rede mantida por um comitê de Chainlink nós. Ele suporta qualquer uma de uma gama ilimitada de funções oracle escolhidas para implantação pelo comitê. Um DON atua, portanto, como uma poderosa camada de abstração, oferecendo interfaces para smart contracts para extensos recursos off-chain e altamente recursos de computação off-chain eficientes, porém descentralizados, dentro do próprio DON. Tendo DONs como trampolim, Chainlink planeja focar em avanços em sete áreas principais: • smart contracts híbridos: oferecendo uma estrutura geral e poderosa para aumentar os recursos smart contract existentes, compondo com segurança na cadeia e recursos de computação fora da cadeia no que chamamos de smart contracts híbridos. • Abstraindo a complexidade: apresentando aos desenvolvedores e usuários soluções simples funcionalidade elimina a necessidade de familiaridade com processos subjacentes complexos protocolos e limites do sistema. • Dimensionamento: garantir que os serviços oracle atinjam as latências e taxas de transferência exigido por sistemas descentralizados de alto desempenho. • Confidencialidade: Habilitando sistemas de próxima geração que combinam blockchains’ transparência inata com novas e fortes proteções de confidencialidade para informações confidenciais dados. • Justiça de pedidos para transações: apoiando o sequenciamento de transações de várias maneiras que sejam justos para os usuários finais e evitem ataques front-running e outros ataques por bots e mineradores exploradores. • Minimização da confiança: criação de uma camada de suporte altamente confiável para smart contracts e outros sistemas dependentes de oracle por meio de descentralização, forte ancoragem em blockchains de alta segurança, criptografia técnicas e garantias criptoeconômicas. • Segurança (criptoeconômica) baseada em incentivos: projetar rigorosamente e implantar mecanismos robustos que garantam que os nós em DONs tenham fortes incentivos econômicos para se comportarem de maneira confiável e correta, mesmo diante de adversários com bons recursos. Apresentamos inovações preliminares e contínuas da comunidade Chainlink em cada uma dessas áreas, fornecendo uma imagem da expansão e cada vez mais recursos poderosos planejados para a rede Chainlink.

Introdução

Blockchain oracles são frequentemente vistos hoje como serviços descentralizados com um objetivo: para encaminhar dados de recursos fora da cadeia para blockchains. É um passo curto, porém, desde o encaminhamento de dados até a computação neles, armazenamento ou transmissão bidirecional. Esta observação justifica uma noção muito mais ampla da funcionalidade de oracles. Então também atendem aos crescentes requisitos de serviço de smart contracts e cada vez mais multifacetados tecnologias que dependem de redes oracle. Resumindo, um oracle pode e precisará ser uma interface de uso geral, bidirecional e habilitada para computação entre sistemas onchain e off-chain. O papel dos oráculos no ecossistema blockchain é melhorar o desempenho, funcionalidade e interoperabilidade de smart contracts para que eles possam trazer novos modelos de confiança e transparência para uma multiplicidade de indústrias. Esta transformação ocorrerá através da ampliação do uso de smart contracts híbridos, que fundem Propriedades especiais de blockchains com os recursos exclusivos de sistemas off-chain, como oracle redes e, assim, alcançar muito maior alcance e poder do que os sistemas on-chain isoladamente. Neste whitepaper, articulamos uma visão para o que chamamos de Chainlink 2.0, uma evolução de Chainlink além de sua concepção inicial no whitepaper Chainlink original [98]. Prevemos um papel cada vez mais expansivo para as redes oracle, em que eles complementam e aprimoram blockchains existentes e novos, fornecendo conectividade e computação universais rápidas, confiáveis e que preservam a confidencialidade para sistemas híbridos. smart contracts. Acreditamos que as redes oracle evoluirão até se tornarem serviços públicos para exportar dados de grau blockchain de alta integridade para sistemas além do blockchain ecossistema. Hoje, os nós Chainlink executados por um conjunto diversificado de entidades se reúnem em redes oracle para retransmitir dados para smart contracts no que é conhecido como relatórios. Podemos ver tal oracle nós como um comitê semelhante ao de um consenso clássico blockchain [72], mas com o objetivo de oferecer suporte a blockchains existentes, em vez de fornecer funcionalidade independente. Com funções aleatórias verificáveis (VRF) e relatórios fora da cadeia (OCR), Chainlink já está evoluindo em direção a uma estrutura e infraestrutura de uso geral para fornecer os recursos computacionais que smart contracts exigem para funcionalidade avançada. A base do nosso plano para Chainlink 2.0 é o que chamamos de Oracle Descentralizado Redes, ou DONs, para abreviar. Desde que introduzimos o termo “rede oracle” no white paper original Chainlink [98], oracles desenvolveram funcionalidades cada vez mais ricas e amplitude de aplicação. Neste artigo, oferecemos uma nova definição do termo de acordo com para a nossa visão futura para o ecossistema Chainlink. Nesta visão, um DON é uma rede mantido por um comitê de nós Chainlink. Enraizado num protocolo de consenso, suporta qualquer uma de uma gama ilimitada de funções oracle escolhidas para implantação pelo comitê. Um DON atua, portanto, como uma camada de abstração blockchain, fornecendo interfaces para recursos fora da cadeia para smart contracts e outros sistemas. Também fornece acesso a recursos de computação off-chain altamente eficientes, porém descentralizados. Em geral, a DON suporta operações em uma cadeia principal. Seu objetivo é permitir um acesso seguro e flexi-híbridos smart contracts, que combinam computação on-chain e off-chain com conexão com recursos externos. Ressaltamos que mesmo com a utilização de comitês em DONs, o próprio Chainlink permanece inerentemente sem permissão. DONs atuam como a base de um sistema sem permissão estrutura na qual os nós podem se unir para implementar redes oracle personalizadas com seus próprios regimes para inclusão de nós, que podem ser com ou sem permissão. Com DONs como base, planejamos focar em Chainlink 2.0 em avanços em sete áreas principais: smart contracts híbridos, abstração de complexidade, escalabilidade, confidencialidade, justiça de ordem para transações, minimização de confiança e segurança baseada em incentivos (criptoeconômica). Na introdução deste artigo, apresentamos uma visão geral da Descentralização Oracle Networks na Seção 1.1 e, em seguida, nossas sete principais áreas de inovação na Seção 1.2. Descrevemos a organização do restante deste artigo na Seção 1.3. 1.1 Redes Oracle Descentralizadas As Oracle Networks descentralizadas são projetadas para aprimorar e ampliar os recursos de smart contracts em um alvo blockchain ou cadeia principal por meio de funções que são não está disponível nativamente. Eles fazem isso fornecendo os três recursos básicos encontrados em sistemas de computação: rede, armazenamento e computação. Um DON visa oferecer esses recursos com fortes propriedades de confidencialidade, integridade e disponibilidade,1 como bem como a responsabilização. DONs são formados por comitês de nós oracle que cooperam para cumprir um determinado emprego ou optar por estabelecer um relacionamento duradouro para fornecer serviços persistentes aos clientes. DONs são projetados de maneira agnóstica blockchain. Eles prometem servir como uma ferramenta poderosa e flexível para desenvolvedores de aplicativos criarem suporte fora da cadeia para seus smart contracts em qualquer cadeia principal suportada. Dois tipos de funcionalidades realizam os recursos de um DON: executáveis e adaptadores. Executáveis ​​são programas executados continuamente e de forma descentralizada no DON. Embora não armazenem diretamente ativos da cadeia principal, eles apresentam benefícios importantes, incluindo alto desempenho e a capacidade de realizar operações confidenciais. computação. Os executáveis são executados de forma autônoma em um DON e executam tarefas determinísticas operações. Eles trabalham em conjunto com adaptadores que vinculam o DON a recursos externos e pode ser chamado por executáveis. Adaptadores, como os imaginamos para DONs, são um generalização dos adaptadores externos em Chainlink hoje. Embora os adaptadores existentes normalmente buscam dados apenas de fontes de dados, os adaptadores podem operar bidirecionalmente; em DONs, eles também podem aproveitar a computação conjunta por nós DON para alcançar recursos adicionais, como criptografia de relatórios para consumo com preservação de privacidade por um executável. Para fornecer uma ideia da operação básica de um DON, a Fig. 1 mostra conceitualmente como um DON pode ser usado para enviar relatórios para um blockchain e, assim, obter a funcionalidade oracle tradicional e existente. DONs podem fornecer muitos recursos adicionais, porém, além 1A “tríade da CIA” de segurança da informação [123, p. 26, §2.3.5].Redes existentes de Chainlink. Por exemplo, dentro da estrutura geral da Fig. 1, o executável poderia registrar dados de preços de ativos buscados no DON, usando esses dados para calcular, por exemplo, uma média final para seus relatórios. Figura 1: Figura conceitual mostrando como exemplo como uma Rede Oracle Descentralizada pode realizar a funcionalidade básica oracle, ou seja, retransmitir dados fora da cadeia para um contrato. Um executável usa adaptadores para buscar dados fora da cadeia, nos quais ele computa, enviando saída sobre outro adaptador para um destino blockchain. (Os adaptadores são iniciados pelo código no DON, representado por pequenas caixas azuis; setas mostram a direção do fluxo de dados para este exemplo específico.) O executável também pode ler e gravar em DON local armazenamento para manter o estado e/ou se comunicar com outros executáveis. Rede flexível, computação e armazenamento em DONs, todos representados aqui, permitem uma série de novidades aplicações. Um grande benefício dos DONs é sua capacidade de inicializar novos serviços blockchain. DONs são um veículo pelo qual as redes oracle existentes podem rapidamente suportar aplicações de serviço isso exigiria hoje a criação de redes construídas especificamente. Damos uma série de exemplos de tais aplicações na Seção 4. Na Seção 3, fornecemos mais detalhes sobre DONs, descrevendo suas capacidades em termos da interface que apresentam aos desenvolvedores e usuários. 1.2 Sete objetivos principais de design Aqui revisamos brevemente os sete focos principais enumerados acima para a evolução da Chainlink, a saber:smart contracts híbridos: Central para nossa visão para Chainlink é a ideia de segurança combinando componentes on-chain e off-chain em smart contracts. Referimo-nos a contratos concretizando essa ideia como smart contracts híbridos ou contratos híbridos.2 Blockchains são e continuarão a desempenhar dois papéis críticos no serviço descentralizado ecossistemas: ambos são os locais onde a propriedade de criptomoedas é representada e âncoras robustas para serviços descentralizados. Os contratos inteligentes devem, portanto, ser representados ou executados em cadeia, mas as suas capacidades em cadeia são severamente limitadas. Puramente o código de contrato na cadeia é lento, caro e insular, incapaz de se beneficiar do mundo real dados e uma variedade de funcionalidades que são inerentemente inatingíveis em cadeia, incluindo várias formas de computação confidencial, geração de (pseudo) aleatoriedade segura contra manipulação de mineradores/validator, etc. Para que smart contracts realizem todo o seu potencial, portanto, são necessários smart contracts a ser arquitetado com duas partes: uma parte na cadeia (que normalmente denotamos por SC) e uma parte off-chain, um executável rodando em um DON (que normalmente denotamos por executivo). O objetivo é alcançar uma composição segura de funcionalidade on-chain com o multiplicidade de serviços fora da cadeia que DONs pretendem fornecer. Juntas, as duas partes elaborar um contrato híbrido. Apresentamos a ideia conceitualmente na Fig. 2. Já hoje, Chainlink serviços3 como feeds de dados e VRFs estão possibilitando smart contract aplicações, variando de DeFi a NFTs gerados de forma justa e seguros descentralizados, como primeiros passos em direção a uma estrutura mais geral. Como serviços Chainlink expandir e ter mais desempenho de acordo com nossa visão neste whitepaper, assim como será o poder dos sistemas smart contract em todos os blockchains. Nossos outros seis focos principais neste whitepaper podem ser vistos como atuação no serviço do primeiro, abrangendo um dos contratos híbridos. Esses focos envolvem a remoção de visíveis complexidade de contratos híbridos, criando serviços adicionais fora da cadeia que permitem o construção de contratos híbridos cada vez mais capazes e, no caso da minimização da confiança, reforçando as propriedades de segurança alcançadas pelos contratos híbridos. Deixamos a ideia de contratos híbridos implícitos em grande parte do artigo, mas qualquer combinação de A lógica MAINCHAIN com DON pode ser vista como um contrato híbrido. Abstraindo a complexidade: DONs são projetados para fazer uso de recursos descentralizados sistemas fáceis para desenvolvedores e usuários, abstraindo o maquinário muitas vezes complexo por trás da poderosa e flexível gama de serviços de DONs. Serviços Chainlink existentes já possui esse recurso. Por exemplo, os feeds de dados em Chainlink hoje apresentam interfaces onchain que não exigem que os desenvolvedores se preocupem com detalhes de nível de protocolo, como os meios pelos quais o OCR impõe relatórios de consenso entre um 2A ideia de composição de contrato on-chain/off-chain surgiu anteriormente em vários países restritos. formulários, por exemplo, sistemas de camada 2, blockchains [80] baseados em TEE, etc. Nosso objetivo é apoiar e generalizar essas abordagens e garantir que elas possam abranger o acesso a dados fora da cadeia e outras oracle chaves serviços. 3Chainlink serviços compreendem uma variedade de serviços e funcionalidades descentralizados disponíveis através a rede. Eles são oferecidos por numerosos operadores de nós compostos em várias redes oracle em todo o ecossistema.Figura 2: Figura conceitual que descreve a composição do contrato on-chain/off-chain. Um híbrido smart contract 3⃝consiste em dois componentes complementares: um on-chain componente SC 1⃝, residente em um blockchain, e um componente off-chain exec 2⃝que é executado em um DON. O DON também serve como uma ponte entre os dois componentes como conectar o contrato híbrido com recursos fora da cadeia, como serviços da web, outros blockchains, armazenamento descentralizado, etc. conjunto descentralizado de nós. DONs vão um passo além no sentido de que expandem o gama de serviços para os quais Chainlink pode oferecer aos desenvolvedores uma camada de abstração com acompanhando interfaces simplificadas para serviços de alto nível. Apresentamos vários exemplos de aplicação na Seção 4 que destacam essa abordagem. Imaginamos empresas, por exemplo, usando DONs como uma forma de middleware seguro para conectar seus sistemas legados a blockchains. (Veja a Seção 4.2.) Este uso de DONs abstrai a complexidade da dinâmica geral de blockchain (taxas, reorganizações, etc.). Também abstrai os recursos de blockchains específicos, permitindo assim que as empresas conectem seus sistemas existentes a uma gama cada vez maior de sistemas blockchain sem necessidade de conhecimentos especializados nestes sistemas ou, mais genericamente, no desenvolvimento de sistemas descentralizados. Em última análise, a nossa ambição é aumentar o grau de abstração alcançado por Chainlink a ponto de implementar o que chamamos de metacamada descentralizada. Essa camada abstrairia a distinção on-chain/off-chain para todas as classes de desenvolvedores e usuários de DApps, permitindo a criação e uso contínuo de serviços descentralizados.Para simplificar o processo de desenvolvimento, os desenvolvedores poderiam especificar a funcionalidade DApp na metacamada como uma aplicação virtual em um modelo de máquina unificado. Eles poderiam em seguida, use um compilador de metacamada descentralizado para instanciar o DApp automaticamente como um conjunto de funcionalidades descentralizadas interoperacionais abrangendo blockchains, DONs e serviços externos. (Um desses serviços externos poderia ser um sistema empresarial, tornando a metacamada útil para aplicações que envolvem sistemas empresariais legados.) Tal a compilação é semelhante à forma como os compiladores modernos e os kits de desenvolvimento de software (SDKs) apoiar programadores generalistas no uso de todo o potencial de hardware heterogêneo arquiteturas que consistem em uma CPU de uso geral e hardware especializado como GPUs, aceleradores de aprendizado de máquina ou enclaves confiáveis. A Fig. 3 apresenta esta ideia a nível conceptual. Os smart contracts híbridos são um primeiro passo no caminho para esta visão e para um conceito que chamamos de metacontratos. Metacontratos são aplicações codificadas de forma descentralizada metalayer e abrange implicitamente a lógica on-chain (smart contracts), bem como a computação off-chain e a conectividade entre vários blockchains e off-chain existentes serviços. Dada a necessidade de suporte a linguagens e compiladores, novos modelos de segurança e harmonização conceitual e técnica de tecnologias díspares, no entanto, a realização de uma verdadeira metacamada descentralizada é uma meta ambiciosa à qual aspiramos há muito tempo. horizonte de tempo. No entanto, é um modelo ideal útil para se ter em mente durante a leitura este artigo, não detalhado aqui, mas algo em que planejamos focar em nosso trabalho futuro sobre Chainlink. Dimensionamento: Um objetivo de importância preeminente em nossos projetos em evolução é permitir que o Rede Chainlink para atender às crescentes necessidades de expansão do ecossistema blockchain. Com o congestionamento da rede se tornando um problema recorrente em redes sem permissão existentes blockchains [86], designs blockchain novos e com melhor desempenho estão entrando em uso, por exemplo, [103, 120, 203], bem como tecnologias complementares de escalonamento de camada 2, por exemplo, [5, 12, 121, 141, 169, 186, 187]. Os serviços Oracle devem atingir latências e taxas de transferência que atendem às demandas de desempenho desses sistemas, ao mesmo tempo que minimizam as taxas na rede (por exemplo, custos do gás) tanto para os operadores contratuais como para os utilizadores comuns. Com DONs, Chainlink a funcionalidade visa ir além e oferecer desempenho alto o suficiente para sistemas puramente baseados na web. DONs derivam grande parte de seu ganho de desempenho do uso de protocolos de consenso rápidos, baseados em comitês ou sem permissão, que eles combinam com os blockchains eles apoiam. Esperamos que muitos DONs com configurações diferentes sejam executados em paralelo; diferentes DApps e usuários podem navegar pelas compensações nas escolhas de consenso subjacentes de acordo com seus requisitos de aplicação. DONs podem ser vistos, na verdade, como tecnologias de camada 2. Esperamos que entre outros serviços, DONs suportarão o Transaction Execution Framework (TEF), que facilita a integração eficiente de DONs e, portanto, oracles com outros de alto desempenho sistemas de camada 2 - por exemplo, rollups, sistemas que agrupam transações off-chain para alcançar melhorias de desempenho. Apresentamos o TEF na Seção 6.

Figura 3: Figura conceitual mostrando a realização ideal de uma metacamada descentralizada. Para facilidade de desenvolvimento, um desenvolvedor especifica um DApp, destacado em rosa, como um virtual aplicação em um modelo de máquina unificado. Um compilador descentralizado de metacamada gera automaticamente funcionalidades de interoperabilidade correspondentes: smart contracts (denotado por SC), lógica (denotada por exec) em DONs, adaptadores conectados a serviços externos de destino e assim por diante, conforme indicado em destaque amarelo. A Figura 4 mostra conceitualmente como DONs melhoram o dimensionamento de blockchain (smart contract) concentrando o processamento de transações e relatórios oracle fora da cadeia, em vez de em cadeia. Esta mudança no locus principal de computação reduz a latência da transação e taxas e, ao mesmo tempo, aumentar o rendimento das transações. Confidencialidade: Blockchains fornecem transparência sem precedentes para smart contracts e para as aplicações que eles realizam. Mas existe uma tensão básica entre transparência e confidencialidade. Hoje, por exemplo, as transações de câmbio descentralizadas dos usuáriosFigura 4: Figura conceitual mostrando como as Redes Oracle Descentralizadas melhoram o dimensionamento de blockchains habilitados para blockchain. Figura A ⃝mostra um oracle convencional arquitetura. As transações são enviadas diretamente para blockchain, assim como os relatórios oracle. Assim o blockchain, destacado em amarelo, é o principal locus de processamento das transações. A Figura B⃝mostra o uso de um DON para apoiar contratos no blockchain. Um DON executável processa transações junto com dados de sistemas externos e encaminha resultados - por exemplo, transações agrupadas ou alterações no estado do contrato resultantes dos efeitos das transações - para blockchain. O DON, destacado em amarelo, é assim o principal locus para processamento de transações. as ações são registradas em cadeia, facilitando o monitoramento do comportamento da bolsa, mas também tornar as transações financeiras dos usuários publicamente visíveis. Da mesma forma, os dados transmitidos para sistemas inteligentes os contratos permanecem em cadeia. Isto torna esses dados convenientemente auditáveis, mas funciona como um desincentivo para provedores de dados que desejam fornecer smart contracts informações confidenciais ou dados proprietários. Acreditamos que as redes oracle desempenharão um papel fundamental na catalisação da próxima geração sistemas que combinam a transparência inata de blockchains com novas proteções de confidencialidade. Neste artigo, mostramos como eles farão isso usando três abordagens principais: • Adaptadores que preservam a confidencialidade: duas tecnologias com implantação planejada nas redes de Chainlink, DECO [234] e Town Crier [233], habilite os nós oracle para recuperar dados de sistemas fora da cadeia de forma a proteger a privacidade e os dados do usuário confidencialidade. Eles desempenharão um papel fundamental no projeto de adaptadores para DONs. (Consulte a Seção 3.6.2 para obter detalhes sobre essas duas tecnologias.) • Computação confidencial: DONs podem simplesmente ocultar sua computação de blockchains confiáveis. Usando computação multipartidária segura e/ou ambientes de execução confiáveis, uma confidencialidade mais forte também é possível em que nós DON computar dados sobre os quais eles próprios não têm visibilidade.

• Suporte para sistemas confidenciais de camada 2: O TEF foi projetado para suportar uma variedade de sistemas de camada 2, muitos dos quais usam provas de conhecimento zero para fornecer diversas formas de confidencialidade da transação. Discutimos essas abordagens na Seção 3 (com detalhes adicionais na Seção 6, Apêndice B.1 e Apêndice B.2). A Figura 5 apresenta uma visão conceitual de como os dados confidenciais podem fluir de fontes externas para um smart contract por meio de adaptadores que preservam a confidencialidade e cálculo confidencial em um DON. Figura 5: Diagrama conceitual de operações de preservação de confidencialidade em um DON em dados sensíveis (destacados em amarelo). Dados de origem confidenciais (círculos pretos) na web servidores é extraído para DON usando adaptadores de preservação de confidencialidade (linhas azuis com setas duplas). O DON recebe dados derivados (círculos vazios) desses adaptadores— o resultado da aplicação de uma função ou, por exemplo, do compartilhamento de segredo, à fonte confidencial dados. Um executável em DON pode aplicar computação confidencial a dados derivados para construir um relatório (círculo duplo), que envia por meio de um adaptador para o blockchain. Acreditamos que ferramentas poderosas para lidar com dados confidenciais abrirão todo um gama de aplicações. Entre eles estão o financiamento privado descentralizado (e centralizado), a identidade descentralizada, os empréstimos em cadeia baseados em crédito e empréstimos mais eficientes e protocolos fáceis de conhecer seu cliente e de credenciamento, conforme discutimos na Seção 4. Justiça de ordem para transações: Os designs blockchain de hoje têm um pouco de sujeira segredo aberto: Eles são efêmeros centralizados. Mineiros e validators podem solicitar trans-ações como quiserem. A ordem de transação também pode ser manipulada pelos usuários como em função das taxas de rede que pagam (por exemplo, preços do gás em Ethereum) e para alguns extensão, aproveitando conexões de rede rápidas. Tal manipulação pode, por exemplo, assumir a forma de front-running, em que um ator estratégico como uma mineradora observa a transação de um usuário e insere sua própria transação exploratória em uma transação anterior posição no mesmo bloco - roubando efetivamente dinheiro do usuário, aproveitando o conhecimento prévio da transação do usuário. Por exemplo, um bot pode fazer um pedido de compra antes de um usuário. Poderá então tirar partido do aumento dos preços dos activos induzido pela comércio do usuário. Front-running por alguns bots que prejudica usuários comuns – análogo ao de alta frequência negociação em Wall Street - já é predominante e bem documentado [90], assim como estão relacionados ataques como back-running [159] e simulação de transação automatizada [195]. Propostas para sistematizar a exploração de pedidos por mineradores surgiram recentemente [110]. Tecnologias de camada 2, como rollups, não resolvem o problema, apenas recentralizam encomenda, colocando-o nas mãos da entidade que cria um rollup. Um dos nossos objetivos é introduzir em Chainlink um serviço chamado Fair Sequencing Serviços (FSS) [137]. O FSS ajuda os designers de smart contract a garantir pedidos justos para seus transações e evitar ataques front-running, back-running e ataques relacionados às transações do usuário, bem como outros tipos de transações, como transmissão de relatórios oracle. FSS permite que um DON implemente ideias como a noção rigorosa e temporal de ordem e justiça introduzida em [144]. Como benefício incidental, o FSS também pode reduzir a rede dos usuários. taxas (por exemplo, custos de gás). Resumidamente, no FSS, as transações passam pelo DON, em vez de serem propagadas diretamente para um destino smart contract. O DON ordena as transações e depois encaminha -los ao contrato. Figura 6: Exemplo de como o FSS é benéfico. Figura A ⃝mostra como um mineiro, explorando seu poder centralizado para ordenar transações, pode trocar um par de transações: transação 1⃝ chega antes de 2⃝, mas o mineiro o sequencia depois de 2⃝. Em contraste, a Fig. B⃝mostra como um DON descentraliza o processo de pedido entre os nós DON. Se um quórum de nós honestos recebem 1⃝antes de 2⃝, o FSS faz com que 1⃝ apareça antes de 2⃝na cadeia— evitando o reordenamento dos mineradores anexando números de sequência executáveis ​​ao contrato. A Figura 6 compara a mineração padrão com o FSS. Mostra como na mineração padrão,o processo de pedido de transação é centralizado com o minerador e, portanto, sujeito a manipulação, como reordenar um par de transações em relação à sua chegada vezes. Em contraste, no FSS, o processo é descentralizado entre os nós DON. Supondo um quórum de nós honestos, o FSS ajuda a aplicar políticas como ordenação temporal de transações, reduzindo oportunidades de manipulação por mineradores e outras entidades. Além disso, como os usuários não precisam competir por pedidos preferenciais com base no preço do gás, eles podem pagar preços de gás relativamente baixos (enquanto as transações do DON podem ser agrupadas para economia de gás). Minimização da confiança: Nosso objetivo geral no projeto de DONs é facilitar um altamente camada confiável de suporte para smart contracts e outros sistemas dependentes de oracle por meio de descentralização, ferramentas criptográficas e garantias criptoeconômicas. O próprio DON é descentralizado e os usuários podem escolher entre qualquer DON disponível que suporta a cadeia principal na qual desejam operar ou gerar DONs adicionais com comitês de nós em que confiam. Para alguns aplicativos, no entanto, especialmente smart contracts, os usuários de Chainlink podem favorecer um modelo de confiança que trate a cadeia principal apoiada por um DON como mais confiável do que o próprio DON. Para esses usuários, já temos ou planejamos incorporar ao arquitetura da rede Chainlink uma série de mecanismos que permitem contratos em uma cadeia principal para fortalecer as garantias de segurança fornecidas por DONs, enquanto no ao mesmo tempo, também aplicando proteções contra a possibilidade de fontes de dados corrompidas como os servidores web dos quais DON obtém dados. Descrevemos esses mecanismos na Seção 7. Eles se enquadram em cinco títulos principais: • Autenticação de fonte de dados: ferramentas que permitem que provedores de dados assinem digitalmente seus dados e, assim, fortalecer a cadeia de custódia entre a origem e contrato confiável. • DON relatórios minoritários: sinalizadores emitidos por um subconjunto minoritário de nós DON que observa prevaricação majoritária no DON. • Guard rails: Lógica em uma cadeia principal que detecta condições anômalas e pausas ou interrompe a execução do contrato (ou invoca outras remediações). • Governança com confiança minimizada: Uso de atualizações de liberação gradual para facilitar a inspeção comunitária, bem como intervenções de emergência descentralizadas para rápida resposta a falhas do sistema. • Autenticação de entidade descentralizada: Uso de infraestrutura de chave pública (PKI) para identificar entidades na rede Chainlink. A Figura 7 apresenta um esquema conceitual de nossos objetivos de minimização de confiança. Segurança baseada em incentivos (criptoeconômica): A descentralização da geração de relatórios entre nós oracle ajuda a garantir a segurança mesmo quando alguns nós estão corrompidos.

Figura 7: Representação conceitual da meta de minimização da confiança de Chainlink, que é minimizar a necessidade dos usuários de comportamento correto de DON e fontes de dados como a web servidores. Os destaques amarelos na figura indicam loci de minimização de confiança: o DON e conjuntos individuais ou minoritários de servidores web. Destaques rosa indicam componentes do sistema que são altamente confiáveis por suposição: contratos no blockchain e uma maioria de servidores web, ou seja, servidores web no agregado. Igualmente importante, porém, é garantir que os nós tenham um incentivo financeiro para se comportarem corretamente. Staking, ou seja, exigir que os nós forneçam depósitos de LINK e slashing (confiscar) esses depósitos em caso de mau comportamento desempenhará um papel fundamental em Chainlink. É um projeto de incentivo importante já usado em vários blockchains, por exemplo, [81, 103, 120, 204]. No entanto, piquetar em Chainlink parece muito diferente de staking em modo autônomo blockchains. A aposta em blockchains visa prevenir ataques ao consenso. Tem um objetivo diferente em Chainlink: garantir a entrega oportuna de relatórios oracle corretos. Um sistema staking bem projetado para uma rede oracle deve renderizar ataques como suborno não lucrativo para um adversário, mesmo quando o alvo é um smart contract com alto valor monetário. Neste artigo, apresentamos uma abordagem geral para staking em Chainlink com três chaves inovações:1. Um modelo adversário poderoso que engloba ataques negligenciados nas abordagens. Um exemplo é o que chamamos de suborno prospectivo. Esta é uma forma de suborno que determina quais nós recebem subornos de forma condicional, por exemplo, oferece subornos garantidos antecipadamente aos nós que um mecanismo staking seleciona em aleatório para funções específicas (como acionar a adjudicação de relatórios). 2. Impacto staking superlinear, significando informalmente que, para ter sucesso, um adversário deve ter um orçamento em $B maior do que os depósitos combinados de todos os oracle nós. Mais precisamente, queremos dizer que em função de n, \(B(n) ≫\)dn em um rede de n oracle nós, cada um com um valor de depósito fixo $d (mais formalmente, \(B(n) is asymptotically larger in n than \)dn). A Fig. 8 dá uma visão conceitual de esta propriedade. 3. O Quadro de Incentivos Implícitos (IIF), um modelo de incentivo que desenvolvemos para abrangem incentivos empiricamente mensuráveis além dos depositados explícitos staking fundos, incluindo oportunidades futuras de taxas dos nós. O IIF amplia a noção de aposta além dos depósitos explícitos de nós. Figura 8: Diagrama conceitual representando escala superlinear em Chainlink staking. O o suborno $B(n) exigido por um adversário cresce mais rápido em n do que os depósitos combinados $dn de todos os nós oracle. Mostramos como o impacto IIF e super-linear staking juntos induzem o que chamamos de ciclo virtuoso de segurança econômica para redes oracle. Quando novos usuários entram

o sistema, aumentando os ganhos futuros potenciais com a execução de nós Chainlink, o o custo marginal da segurança económica cai para os utilizadores actuais e futuros. Num regime de demanda elástica, esse custo reduzido incentiva usuários adicionais a fazer uso do rede, perpetuando continuamente a adoção em um ciclo virtuoso contínuo. Observação: embora este whitepaper descreva elementos importantes de nossa visão para a evolução de Chainlink, ele é informal e inclui poucas especificações técnicas detalhadas. Nós planejamos lançar artigos técnicos focados em recursos e abordagens adicionais à medida que evoluem. Além disso, é importante ressaltar que muitos elementos da visão apresentada aqui (melhorias de escala, tecnologias de confidencialidade, FSS, etc.) podem e serão implantado de forma preliminar, mesmo antes de DONs avançados se tornarem um recurso básico de Chainlink. 1.3 Organização deste artigo Apresentamos nosso modelo de segurança e notação na Seção 2 e descrevemos o Sistema Descentralizado API Oracle Network na Seção 3. Na Seção 4, apresentamos vários exemplos de aplicativos para os quais DONs fornecem uma plataforma de implantação atraente. Os leitores podem aprenda a maioria dos conceitos-chave do artigo lendo até este ponto. O restante do artigo contém mais detalhes. Descrevemos o sequenciamento justo Services (FSS) na Seção 5 e o Transaction-Execution Framework (TEF) na Seção 6. Descrevemos nossa abordagem para minimização de confiança na Seção 7. Consideramos alguns requisitos importantes de implantação DON, ou seja, implementação incremental de recursos, associação de razão dinâmica e responsabilidade na Seção 8. Finalmente, na Seção 9, damos uma visão geral de nossa abordagem em desenvolvimento para design de incentivos. Concluímos na Seção 10. Para ajudar os leitores que têm familiaridade limitada com os conceitos deste artigo, nós fornecemos um glossário no Apêndice A. Apresentamos mais detalhes sobre a interface DON e funcionalidade no Apêndice B e apresentam alguns exemplos de adaptadores no Apêndice C. No Apêndice D, descrevemos uma primitiva criptográfica para fontes de dados com confiança minimizada. autenticação chamada assinaturas funcionais e introduzir uma nova variante chamada assinaturas funcionais discretizadas. Discutimos algumas considerações pertinentes à comissão seleção para DONs no Apêndice F.

Modelo e metas de segurança

Uma Rede Oracle Descentralizada é um sistema distribuído distinto que esperamos que inicialmente ser implementado normalmente - embora não necessariamente - por um comitê baseado em protocolo de consenso e executado por um conjunto de nós oracle. Um DON foi projetado principalmente para aumentar os recursos de um smart contract em uma cadeia principal com relatórios oracle e outros serviços, mas pode fornecer esses mesmos serviços de suporte a outros sistemas nãoblockchain e, portanto, não precisa estar associado a uma cadeia principal específica.

O modelo e as propriedades que consideramos são, portanto, em grande parte independentes do uso de as aplicações específicas de um DON. 2.1 Modelo Arquitetônico Atual É importante ressaltar que Chainlink hoje não é um serviço monolítico, mas sim uma estrutura sem permissão dentro da qual é possível lançar recursos distintos e independentes redes de oracle nós [77]. As redes têm conjuntos heterogêneos de operadores de nós e projetos. Eles também podem diferir em termos dos tipos de serviços que prestam, o que pode incluem, por exemplo, feeds de dados, Prova de Reservas, aleatoriedade verificável e assim por diante. Outro As diferenças podem incluir o grau de descentralização, o tamanho da rede em termos de valor bloqueado que ele suporta e vários parâmetros de nível de serviço, como frequência de dados e precisão. O modelo sem permissão de Chainlink incentiva o crescimento de um ecossistema no qual os provedores se especializam nos serviços que são mais capazes de fornecer à comunidade. Isto modelo provavelmente resultará em custos mais baixos para os usuários e maior qualidade de serviço do que um modelo que exige que todos os nós e redes forneçam uma gama completa de serviços, uma abordagem que pode facilmente evoluir para a adoção em todo o sistema dos serviços que representam menos denominador comum de recursos disponíveis para os nós. À medida que Chainlink evolui em direção a designs baseados em DON em Chainlink 2.0, continuamos a apoiar o modelo de uma estrutura aberta e sem permissão, tendo em vista o objetivo de fornecendo aos usuários uma variedade de opções de serviços que resultam globalmente na melhor combinação com requisitos de aplicação específicos. 2.2 Suposições de consenso Usamos o termo Rede Oracle Descentralizada para abranger toda a funcionalidade do o sistema oracle que descrevemos: tanto a estrutura de dados que os nós oracle mantêm e a API principal colocada em cima dela. Usamos o termo razão (minúsculas), denotado por L, para significar os dados subjacentes estrutura mantida por DON e usada para dar suporte aos serviços específicos que ele fornece. Enfatizamos que nossa estrutura DON não trata L como um sistema independente como a blockchain: Sua finalidade é oferecer suporte a blockchains e outros sistemas. Blockchains são, é claro, uma forma de realizar um livro-razão confiável, mas existem outras. Nós esperamos DONs, em muitos casos, para realizar seus livros contábeis subjacentes usando Byzantine Fault Tolerant (BFT), que são consideravelmente anteriores a blockchains, como Bitcoin [174]. Nós usamos notação e propriedades do tipo BFT em todo o artigo por conveniência, embora enfatize que DONs podem ser realizados usando protocolos de consenso sem permissão. Conceitualmente, um livro-razão L é um quadro de avisos no qual os dados são ordenados linearmente. Vemos um livro-razão geralmente como tendo algumas propriedades-chave comumente atribuídas a blockchains [115]. Um livro razão é: • Somente acréscimo: Os dados, uma vez adicionados, não podem ser removidos ou modificados.• Público: Qualquer pessoa pode ler seu conteúdo, que é consistente ao longo do tempo no visualização de todos os usuários.4 • Disponível: O razão sempre pode ser gravado por escritores autorizados e lido por qualquer pessoa em tempo hábil. Propriedades alternativas são possíveis no razão para um DON quando realizadas por um comitê. Por exemplo, o acesso à gravação do razão pode ser restrito a determinados usuários, como pode ler o acesso para algumas aplicações, ou seja, o razão não precisa ser público conforme definido acima. Da mesma forma, as regras contábeis podem permitir a modificação ou redação de dados. Nós não considere explicitamente tais variantes neste artigo, no entanto. O design modular de DONs pode suportar qualquer uma de uma ampla variedade de BFT modernos protocolos, por exemplo, Hotstuff[231]. A escolha exata dependerá de suposições de confiança e características de rede entre os nós oracle. Um DON poderia, em princípio, alternativamente usar um blockchain sem permissão de alto desempenho para seu razão em sua função de suporte a um sistema igualmente escalonável de camada 2 ou blockchain. Da mesma forma, a hibridização também é possível: O DON poderia, em princípio, ser composto de nós que são validators em um existente blockchain, por exemplo, em sistemas de Prova de Participação nos quais os comitês são selecionados para executar transações, por exemplo, [8, 81, 120, 146, 204]. Este modo específico de operação requer que os nós operam de maneira de uso duplo, ou seja, operam como nós blockchain e como nós DON nós. (Veja a Seção 8.2 para uma discussão de técnicas para garantir a continuidade na mudança comitês e Apêndice F para algumas advertências sobre a seleção aleatória de comitês.) Na prática, nos algoritmos BFT modernos, os nós assinam digitalmente as mensagens no livro-razão. Assumimos por conveniência que L tem uma chave pública associada pkL e que seu conteúdo são assinados pela chave privada correspondente. Esta notação geral se aplica mesmo quando os dados em L são assinados usando assinaturas de limite.5 Assinaturas de limite são convenientes, pois permitem uma identidade persistente para um DON mesmo com mudanças de associação em os nós que o executam. (Veja o Apêndice B.1.3.) Assim, assumimos que skL é compartilhado em segredo de uma maneira (k, n)-limiar para algum parâmetro de segurança k, por exemplo, k = 2f + 1 e n = 3f + 1, onde f é o número de nós potencialmente defeituosos. (Ao escolher k neste Dessa forma, garantimos que nós defeituosos não possam aprender skL nem montar um sistema de negação de serviço ataque impedindo seu uso.) Uma mensagem em L assume a forma M = (m, z), onde m é uma string e z um único número de índice sequencial. Quando aplicável, escrevemos mensagens no formato m = ⟨MessageType: carga útil⟩. O tipo de mensagem MessageType é um açúcar sintático que indica a função de uma mensagem específica. 4Nos casos em que um blockchain sem finalidade realiza um livro-razão, a inconsistência é normalmente abstraída eliminado desconsiderando blocos insuficientemente profundos ou “podando” [115]. 5Na prática, algumas bases de código, por exemplo, LibraBFT [205], uma variante do Hotstuff, adotaram atualmente assinaturas múltiplas, em vez de assinaturas de limite, trocando complexidade de comunicação reduzida por engenharia mais simples. Com algum custo adicional, os nós oracle podem anexar assinaturas de limite às mensagens escritos em L mesmo que o protocolo de consenso usado para L não os empregue.2.3 Notação Denotamos o conjunto de n nós oracle executando o razão por O = {Oi}n eu=1. Tal conjunto de nós é frequentemente chamado de comitê. Para simplificar, assumimos que o conjunto de oracles implementando a funcionalidade DON, ou seja, serviços em cima de L, é idêntico a que mantendo L, mas eles podem ser distintos. Deixamos pki denotar a chave pública de jogador Oi, e esquie a chave privada correspondente. A maioria dos algoritmos BFT requerem pelo menos n = 3f + 1 nós, onde f é o número de nós potencialmente defeituosos; os nós restantes são honestos, no sentido de que seguem o protocolo exatamente como especificado. Referimo-nos ao comitê O como honesto se atender a este requisito, ou seja, tem mais de 2/3 fração de nós honestos. A menos que de outra forma afirmado, assumimos que O é honesto (e um modelo estático de corrupção). Usamos pkO / skO de forma intercambiável com pkL/skL, dependendo do contexto. Deixamos σ = Sigpk[m] denotar uma assinatura na mensagem m em relação a pk, ou seja, usando chave privada correspondente sk. Deixe verify(pk, σ, m) →{false, true} denotar um algoritmo de verificação de assinatura correspondente. (Deixamos a geração de chaves implícita ao longo do artigo.) Usamos a notação S para denotar uma fonte de dados e S para denotar o conjunto completo de Fontes nS em um determinado contexto. Denotamos por MAINCHAIN um contrato inteligente habilitado blockchain suportado por um DON. Usamos o termo contrato confiável para denotar qualquer contrato inteligente contrato no MAINCHAIN que se comunica com um DON e use a notação SC para denotar tal contrato. Geralmente assumimos que um DON suporta uma única cadeia principal MAINCHAIN, embora possa suportar múltiplas dessas cadeias, como mostramos nos exemplos da Seção 4. A DON pode e normalmente oferecerá suporte a vários contratos dependentes no MAINCHAIN. (Como mencionado acima, um DON pode alternativamente suportar serviços não blockchain.) 2.4 Nota sobre modelos de confiança Conforme observado acima, DONs podem ser construídos com base em protocolos de consenso baseados em comitês, e nós esperamos que eles normalmente usem esses protocolos. Existem muitos argumentos fortes que uma das duas alternativas, blockchains com base em comitê ou sem permissão, fornece segurança mais forte que o outro. É importante reconhecer que a segurança dos sistemas baseados em comitês versus os sistemas sem permissão sistemas descentralizados é incomensurável. Comprometendo um PoW ou PoS blockchain via ataque de 51% exige que um adversário obtenha recursos majoritários de forma efêmera e potencialmente anonimamente, por exemplo, alugando hash energia em um sistema PoW. Tal os ataques na prática já impactaram vários blockchains [200, 34]. Em contraste, comprometer um sistema baseado em comitê significa corromper um número limite (normalmente um terço) de seus nós, onde os nós podem ser conhecidos publicamente, ter bons recursos, e entidades confiáveis. Por outro lado, sistemas baseados em comitês (bem como sistemas “híbridos” sem permissão) sistemas que apoiam comitês) podem suportar mais funcionalidades do que estritamentesistemas sem missão. Isso inclui a capacidade de manter segredos persistentes, como chaves de assinatura e/ou criptografia – uma possibilidade em nossos projetos. Enfatizamos que DONs podem, em princípio, ser construídos em cima de um comitê baseado ou protocolo de consenso sem permissão e os implantadores DON podem, em última análise, optar por adotar qualquer abordagem. Reforçando os modelos de confiança: Um recurso importante do Chainlink hoje é a capacidade dos usuários de selecionar nós com base em registros descentralizados de seus históricos de desempenho, conforme discutido na Seção 3.6.4. O mecanismo staking e a Estrutura de Incentivos Implícitos que apresentamos na Seção 9 juntos constituem um projeto de mecanismo rigoroso e de amplo escopo estrutura que capacitará os usuários com uma capacidade bastante ampliada de avaliar a segurança de DONs. Esta mesma estrutura também tornará possível para os próprios DONs para impor vários requisitos de segurança nos nós participantes e garantir a operação dentro de modelos de confiança fortes. Também é possível usar as ferramentas descritas neste documento para DONs para impor requisitos especiais de modelo de confiança, como conformidade com requisitos regulatórios. Para Por exemplo, usando técnicas discutidas na Seção 4.3, os nós podem apresentar evidências de características do operador do nó, por exemplo, território de operação, que podem ser usadas para ajudar impor a conformidade com, por exemplo, o Artigo 3 do Regulamento Geral de Proteção de Dados (GDPR) (“Âmbito Territorial”) [105]. Caso contrário, tal conformidade pode ser um desafio para atendem em sistemas descentralizados [45]. Além disso, na Seção 7 discutimos planos para fortalecer a robustez de DONs através de mecanismos de minimização de confiança nas principais cadeias que apoiam.

Interface de rede Oracle descentralizada e Ca-

habilidades Aqui esboçamos brevemente as capacidades de DONs em termos do simples, mas poderoso interface que eles foram projetados para realizar. Os aplicativos em DON são compostos de executáveis ​​e adaptadores. Um executável é um programa cuja lógica central é um programa determinístico, análogo a um smart contract. Um executável também possui vários iniciadores, programas que chamam entrada pontos na lógica do executável quando ocorrem eventos predeterminados - por exemplo, em determinados momentos (como um cron job), quando um preço ultrapassa um limite, etc. – muito parecido com o Keepers (consulte a Seção 3.6.3). Adaptadores fornecem interfaces para recursos fora da cadeia e podem ser chamados por os iniciadores ou a lógica central dos executáveis. Como o comportamento deles pode depender disso de recursos externos, iniciadores e adaptadores podem se comportar de forma não determinística. Descrevemos a interface do desenvolvedor DON e o funcionamento de executáveis e adaptadores em termos dos três recursos normalmente usados para caracterizar sistemas de computação: rede, computação e armazenamento. Damos uma breve visão geral de cada um desses recursos abaixo e forneça mais detalhes no Apêndice B.

3.1 Rede Adaptadores são interfaces através das quais executáveis em execução em um DON podem enviar e receber dados de sistemas off-DON. Adaptadores podem ser vistos como uma generalização de os adaptadores usados em Chainlink hoje [20]. Os adaptadores podem ser bidirecionais, ou seja, eles não pode apenas extrair, mas enviar dados de um DON para um servidor web. Eles também podem aproveitar protocolos distribuídos, bem como funcionalidade criptográfica, como segurança multipartidária computação. Figura 9: Adaptadores conectando um DON, denotado DON1, com uma variedade de recursos diferentes, incluindo outro DON, denotado DON2, um blockchain (cadeia principal) e seu mempool, armazenamento externo, um servidor web e dispositivos IoT (por meio de um servidor web). São mostrados exemplos de recursos externos para os quais adaptadores podem ser criados na Fig. 9. Eles incluem: • Blockchains: um adaptador pode definir como enviar transações para um blockchain e como ler blocos, transações individuais ou outro estado dele. Um adaptador também pode ser definido para um mempool de blockchain. (Ver Seção 3.5.) • Servidores Web: Os adaptadores podem definir APIs através das quais os dados podem ser recuperados de servidores web, incluindo sistemas legados que não são especialmente adaptados para fazendo interface com DONs. Esses adaptadores também podem incluir APIs para enviar dados para tais servidores. Os servidores web aos quais um DON se conecta podem servir como gateways a recursos adicionais, como dispositivos de Internet das Coisas (IoT).• Armazenamento externo: um adaptador pode definir métodos para ler e gravar no armazenamento serviços fora do DON, como um sistema de arquivos descentralizado [40, 188] ou nuvem armazenamento. • Outros DONs: Os adaptadores podem recuperar e transmitir dados entre DONs. Esperamos que as implantações iniciais de DONs incluam um conjunto de blocos de construção adaptadores para recursos externos comumente usados e permitirá ainda DON específicos adaptadores a serem publicados pelos nós DON. À medida que os desenvolvedores smart contract escrevem adaptadores hoje, esperamos que eles construam adaptadores ainda mais poderosos usando este avançado funcionalidade. Esperamos que, em última análise, seja possível aos usuários criar novos adaptadores em um maneira sem permissão. Alguns adaptadores devem ser construídos de forma a garantir a persistência e disponibilidade de recursos externos controlados por um DON. Por exemplo, o armazenamento em nuvem pode exigem a manutenção de uma conta de serviços em nuvem. Além disso, um DON pode executar gerenciamento descentralizado de chaves privadas em nome dos usuários (como em, por exemplo, [160]) e/ou executáveis. Consequentemente, o DON é capaz de controlar recursos, como criptomoeda, que podem ser usados, por exemplo, para enviar transações em um alvo blockchain. Consulte o Apêndice B.1 para obter mais detalhes sobre os adaptadores DON, assim como o Apêndice C para alguns exemplo de adaptadores. 3.2 Computação Um executável é a unidade básica de código em um DON. Um executável é um par exec = (lógica, inicialização). Aqui, a lógica é um programa determinístico com um número de entradas designadas pontos (logic1, logic2, . . . , logicℓ) e init é um conjunto de iniciadores correspondentes (init1, init2, . . . , iniciar). Para garantir a auditabilidade total do DON, a lógica de um executável usa o razão subjacente L para todas as entradas e saídas. Assim, por exemplo, qualquer adaptador os dados que servem como entrada para um executável devem ser armazenados primeiro em L. Iniciadores: Os iniciadores em Chainlink hoje causam execuções de tarefas dependentes de eventos em Chainlink nós [21]. Os iniciadores em DONs funcionam da mesma maneira. Um iniciador DON, entretanto, está especificamente associado a um executável. Um iniciador pode depender em um evento ou estado externo, na hora atual ou em um predicado no estado DON. Com a sua dependência de eventos, os iniciadores podem, naturalmente, comportar-se de forma não determinística. (como é claro, os adaptadores). Um iniciador pode ser executado em nós DON individuais e portanto não precisa depender de um adaptador. (Veja o Exemplo 1 abaixo.) Iniciadores são um recurso importante que distingue executáveis de smart contracts. Como um executável pode ser executado em resposta a um iniciador, ele pode operar efetivamente de forma autônoma, como é claro, por extensão, um contrato híbrido que incorpora o executável. Uma forma de iniciadores hoje são Chainlink Keepers, que fornecem transaçõesserviços de automação, desencadeando a execução de smart contract – como liquidação de empréstimos com garantia insuficiente e execução de negociações com ordens de limite – com base em relatórios oracle. Convenientemente, os iniciadores em DONs também podem ser vistos como uma forma de especificar o contratos de serviço que se aplicam a um executável, pois definem as circunstâncias sob qual o DON deve chamá-lo. O exemplo a seguir ilustra como os iniciadores funcionam em um executável: Exemplo 1 (feed de preço acionado por desvio). Um smart contract SC pode exigir novos dados de alimentação de preços (ver Seção 3.6.3) sempre que houver uma mudança substancial, por exemplo, 1%, em a taxa de câmbio entre um par de ativos, por exemplo, ETH-USD. Preço sensível à volatilidade feeds são suportados em Chainlink hoje, mas é instrutivo ver como eles podem ser realizado em um DON por meio de um execfeed executável. O executável execfeed mantém o preço ETH-USD mais recente r em L, no forma de uma sequência de ⟨NewPrice: j, r⟩entries, onde j é um índice incrementado com cada atualização de preço. Um iniciador init1 faz com que cada nó Oi monitore o preço atual do ETH-USD para desvios de pelo menos 1% do preço armazenado mais recentemente r com índice j. Após detecção de tal desvio, a Oi escreve sua visão atual ri do novo preço para L usando uma entrada no formato ⟨PriceView : i, j + 1, ri⟩. Um segundo iniciador init2 é acionado quando pelo menos k dessas entradas PriceView com novo preço valores para o índice j + 1 criados por nós distintos foram acumulados em L. Então, init2 invoca uma lógica de ponto de entrada2 para calcular a mediana ρ dos primeiros k valores novos e válidos de priceview e grava um novo valor ⟨NewPrice : j + 1, ρ⟩to L . (Operacionalmente, nós podem se revezar como escritores designados.) Um terceiro iniciador init3 observa as entradas NewPrice em L. Sempre que um novo relatório ⟨NewPrice : j, r⟩aparece lá, invoca uma lógica de ponto de entrada3 que empurra (j, r) para SC usando um adaptador. Como observamos, um executável é semelhante em suas capacidades a um smart contract. Além de seu desempenho superior, difere de um contrato típico da cadeia principal. de duas maneiras essenciais: 1. Confidencialidade: Um executável pode realizar computação confidencial, ou seja, um programa secreto pode processar entradas de texto não criptografado, ou um programa publicado pode processar dados de entrada secretos ou uma combinação de ambos. Num modelo simples, os dados secretos podem ser acessado por nós DON, que ocultam resultados intermediários e divulgam apenas valores processados e higienizados para MAINCHAIN. Também é possível ocultar dados confidenciais dos próprios DONs: DONs destinam-se a apoiar abordagens como como computação multipartidária, por exemplo, [42, 157] e ambientes de execução confiáveis (TEEs) [84, 133, 152, 229] para esse fim.6 6Por extensão, também é possível manter os próprios executáveis em segredo em relação aos nós DON, embora isso só seja prático hoje para executáveis não triviais usando TEEs.2. Função de suporte: um executável destina-se a suportar smart contracts em um servidor principal cadeia, em vez de substituí-los. Um executável tem várias limitações que um smart contract não: (a) Modelo de confiança: um executável opera dentro do modelo de confiança definido pelo DON: Sua execução correta depende do comportamento honesto de O. (A principal cadeia pode, no entanto, fornecer algumas barreiras de proteção contra DON prevaricação, como discutido na Seção 7.3.) (b) Acesso a ativos: Um DON pode controlar uma conta em um blockchain - e, portanto, controlar ativos nele por meio de um adaptador. Mas um DON não pode ser autorizado representam ativos criados em uma cadeia principal, por exemplo, Ether ou ERC20 tokens, uma vez que sua cadeia nativa mantém o registro oficial de sua propriedade. (c) Ciclo de vida: DONs podem ser levantados intencionalmente com vida útil limitada, como definido por acordos de nível de serviço na cadeia entre DONs e os proprietários de contratos confiáveis. Blockchains, por outro lado, devem funcionar como sistemas de arquivo permanente. Consulte o Apêndice B.2 para obter mais detalhes sobre o cálculo de DON. 3.3 Armazenamento Como um sistema baseado em comitê, um DON pode armazenar quantidades moderadas de dados de forma persistente em L a um custo muito menor do que um blockchain sem permissão. Além disso, através de adaptadores, DONs podem fazer referência a sistemas descentralizados externos para armazenamento de dados, por exemplo, Filecoin [85], e pode, assim, conectar tais sistemas a smart contracts. Esta opção é particularmente atraente para dados em massa como forma de resolver o problema generalizado de “inchaço” em blockchain sistemas. DONs podem, portanto, armazenar dados local ou externamente para uso em seus serviços especificamente suportados. Um DON também pode fazer uso desses dados de forma confidencial, computação em dados que são: (1) compartilhados em segredo entre nós DON ou criptografados em uma chave gerenciada por nós DON de maneira adequada para computação multipartidária segura ou criptografia parcial ou totalmente homomórfica; ou (2) protegido usando uma execução confiável ambiente. Esperamos que DONs adotem um modelo simples de gerenciamento de memória comum a sistemas de contrato inteligente: um executável só pode gravar em sua própria memória. Executáveis pode, no entanto, ler da memória de outros executáveis. Consulte o Apêndice B.3 para obter mais detalhes sobre o armazenamento DON. 3.4 Estrutura de Execução de Transações (TEF) DONs destinam-se a apoiar contratos em uma cadeia principal MAINCHAIN (ou em várias cadeias principais). O Transaction-Execution Framework (TEF), discutido em detalhesna Seção 6, é uma abordagem de propósito geral para a execução eficiente de um contrato SC em MAINCHAIN e um DON. O TEF destina-se a apoiar FSS e camada 2 tecnologias - simultaneamente, se desejado. Na verdade, é provável que sirva como o principal veículo para uso do FSS (e por essa razão, não discutiremos mais detalhadamente o FSS nesta seção). Resumidamente, no TEF, um contrato-alvo original SC projetado ou desenvolvido para MAINCHAIN é refatorado em um contrato híbrido. Essa refatoração produz os dois processos interoperacionais partes do contrato híbrido: um contrato MAINCHAIN SCa ao qual nos referimos para maior clareza no contexto dos TEFs como um contrato âncora e um executivo executável em um DON. O O contrato SCa custodia os ativos dos usuários, executa transições de estado autorizadas e também fornece guarda-corpos (consulte a Seção 7.3) contra falhas no DON. Os executivos executáveis sequencia transações e fornece dados oracle associados para elas. Pode agrupar transações para SCa de várias maneiras - por exemplo, usando provas de validade ou rollups otimistas, execução confidencial por DON, etc. Esperamos desenvolver ferramentas que facilitem aos desenvolvedores a partição de um contrato SC escrito em uma linguagem de alto nível em partes da lógica MAINCHAIN e DON, SCa e executivos respectivamente, que compõem com segurança e eficiência. Usando TEF para integrar esquemas de transações de alto desempenho com transações de alto desempenho oracles é parte integrante da nossa abordagem de escalonamento oracle. 3.5 Serviços de mempool Um recurso importante da camada de aplicação que pretendemos implantar em DONs para suporte do FSS e do TEF são Mempool Services (MS). MS pode ser visto como um adaptador, mas com suporte de primeira classe. MS fornece suporte para processamento de transações compatíveis com legado. Neste uso, MS ingere do mempool de uma cadeia principal as transações destinadas a um contrato alvo SC em MAINCHAIN. A MS então passa essas transações para um executável no DON, onde são processados da maneira desejada. Os dados MS podem ser usados pelo DON para compor transações que podem então ser passadas diretamente para SC a partir do DON ou para outro contrato que chama SC. Por exemplo, o DON pode encaminhar transações colhido via MS, ou pode usar dados do MS para definir os preços do gás para as transações que envia para MAINCHAIN. Por monitorar o mempool, o MS pode obter transações de usuários interagindo diretamente com o SC. Assim, os usuários podem continuar a gerar suas transações usando software legado, ou seja, aplicativos que desconhecem a existência de MS e software configurado por MS contratos. (Neste caso, SC deve ser alterado para ignorar as transações originais e aceitar apenas os processados pelo MS, de modo a evitar o duplo processamento.) Para uso com um SC de contrato-alvo, o MS pode ser usado com o FSS e/ou o TEF.3.6 trampolins: capacidades Chainlink existentes 3.6.1 Relatórios fora da cadeia (OCR) Relatórios fora da cadeia (OCR) [60] é um mecanismo em Chainlink para oracle agregação e transmissão de relatórios para um SC de contrato confiável. Implantado recentemente pelo preço de Chainlink redes de alimentação, representa um primeiro passo no caminho para DONs completos. Em sua essência, OCR é um protocolo BFT projetado para operar de forma parcialmente síncrona. rede. Garante vivacidade e correção na presença de f <n/3 arbitrariamente nós defeituosos, garantindo as propriedades da transmissão confiável bizantina, mas não é um protocolo de consenso BFT completo. Os nós não mantêm logs de mensagens que são consistente no sentido de representar um livro-razão que é idêntico em todas as suas visões, e o líder do protocolo pode equivocar-se sem violar a segurança. OCR é atualmente projetado para um tipo específico de mensagem: agregação mediana de (pelo menos 2f +1) valores relatados pelos nós participantes. Ele fornece uma garantia fundamental sobre os relatórios que ele gera para SC, chamados de relatórios atestados: O valor mediano em um atestado report é igual ou está entre os valores relatados por dois nós honestos. Esta propriedade é a principal condição de segurança para OCR. O líder pode ter alguma influência sobre a mediana valor em laudo atestado, mas somente sujeito a esta condição de correção. OCR pode ser estendido a tipos de mensagens que agregam valores de diferentes maneiras. Embora as metas de atividade e correção da rede Chainlink hoje não exijam Para que o OCR seja um protocolo de consenso completo, eles exigem que o OCR forneça algumas formas adicionais de funcionalidade não presentes nos protocolos BFT convencionais, mais notavelmente: 1. Transmissão de relatório fora da cadeia do tipo tudo ou nada: OCR garante que um relatório atestado é disponibilizado rapidamente para todos os nós honestos ou para nenhum deles. Isto é uma justiça propriedade que ajuda a garantir que nós honestos tenham a oportunidade de participar na transmissão de relatório atestado. 2. Transmissão confiável: OCR garante, mesmo na presença de falhas ou mal-intencionados nós, que todos os relatórios e mensagens de OCR são transmitidos ao SC dentro de um determinado, intervalo de tempo pré-definido. Esta é uma propriedade de vivacidade. 3. Minimização da confiança baseada em contrato: o SC filtra relatórios gerados por OCR potencialmente errados, por exemplo, se seus valores relatados se desviarem significativamente de outros recebidos recentemente. Esta é uma forma de aplicação de correção extraprotocolo. Todas essas três propriedades desempenharão um papel natural em DONs. A transmissão off-chain do tipo tudo ou nada (DON) é um importante alicerce para garantias criptoeconômicas em torno da transmissão confiável, que por sua vez é uma propriedade essencial do adaptador. Confiança a minimização em SC é um tipo de guarda-corpo, conforme discutido na Seção 7.3. OCR também fornece uma base para implantação operacional e refinamento de protocolos BFT nas redes Chainlink de oracle e, portanto, como observado acima, um caminho para a plena funcionalidade de DONs.3.6.2 DECO e Pregoeiro DECO [234] e Town Crier [233] são um par de tecnologias relacionadas atualmente em desenvolvido em redes Chainlink. A maioria dos servidores web hoje permite que os usuários se conectem através de um canal seguro usando um protocolo chamado Transport Layer Security (TLS) [94]. (HTTPS indica uma variante de HTTP que está habilitado com TLS, ou seja, URLs prefixados com “https” indicam o uso de TLS para segurança.) A maioria dos servidores habilitados para TLS tem uma limitação notável: eles não assinam digitalmente dados. Consequentemente, um usuário ou Prover não pode apresentar os dados que recebe de um servidor a um terceiro ou verificador, como um oracle ou smart contract, de uma forma que garanta a autenticidade dos dados. Mesmo que um servidor assinasse digitalmente os dados, ainda existiria um problema de confidencialidade. Um Provador pode desejar redigir ou modificar dados confidenciais antes de apresentá-los a um Verificador. Entretanto, as assinaturas digitais são projetadas especificamente para invalidar dados modificados. Assim, evitam que um Provador faça alterações que preservem a confidencialidade. aos dados. (Veja a Seção 7.1 para mais discussão.) DECO e Town Crier são projetados para permitir que um provador obtenha dados de uma web servidor e apresentá-lo a um verificador de uma forma que garanta integridade e confidencialidade. Os dois sistemas preservam a integridade no sentido de garantirem que os dados apresentados pelos o Provador para o Verificador se origina autenticamente do servidor de destino. Eles apoiam confidencialidade no sentido de permitir que o Provador edite ou modifique os dados (enquanto ainda preservando a integridade). Uma característica fundamental de ambos os sistemas é que eles não exigem nenhuma modificação em um servidor web de destino. Eles podem operar com qualquer servidor existente habilitado para TLS. Na verdade, eles são transparentes para o servidor: Do ponto de vista do servidor, o Provador é estabelecendo uma conexão comum. Os dois sistemas têm objetivos semelhantes, mas diferem em seus modelos de confiança e implementações, como explicaremos brevemente agora. DECO faz uso fundamental de protocolos criptográficos para alcançar sua integridade e propriedades de confidencialidade. Ao estabelecer uma sessão com um servidor alvo usando DECO, o Provador se envolve ao mesmo tempo em um protocolo interativo com o Verificador. Este protocolo permite ao Provador provar ao Verificador que recebeu um determinado dado D do servidor durante sua sessão atual. O Provador pode alternativamente, apresente ao Verificador uma prova de conhecimento zero de alguma propriedade de D e, portanto, não revela D diretamente. Em um uso típico do DECO, um usuário ou um único nó pode exportar dados D de um servidor privado. sessão com um servidor web para todos os nós em um DON. Como resultado, o DON completo pode atestar a autenticidade de D (ou um fato derivado de D através de uma prova de conhecimento zero). Além dos exemplos de aplicações dados posteriormente neste artigo, esse recurso pode ser usado para amplificar o acesso de alta integridade a uma fonte de dados por um DON. Mesmo que apenas um nó tem acesso direto a uma fonte de dados – devido, por exemplo, a um acordo exclusivo com um provedor de dados - ainda é possível para todo o DON atestar a exatidão derelatórios emitidos por esse nó. Town Crier depende do uso de um ambiente de execução confiável (TEE), como Intel SGX. Resumidamente, um TEE funciona como uma espécie de caixa preta que executa aplicações de uma forma forma inviolável e confidencial. Em princípio, mesmo o proprietário do host no qual o TEE está em execução não pode alterar (de forma indetectável) um aplicativo protegido por TEE nem visualizar o estado do aplicativo, que pode incluir dados secretos. Town Crier pode alcançar todas as funcionalidades do DECO e muito mais. DECO restringe o Provador à interação com um único Verificador. Em contraste, o Town Crier permite um provador para gerar uma prova publicamente verificável sobre os dados D obtidos de um servidor de destino, ou seja, uma prova que qualquer pessoa, mesmo um smart contract, pode verificar diretamente. O Pregoeiro da Cidade pode também ingerir e usar segredos com segurança (por exemplo, credenciais de usuário). A principal limitação do Town Crier é a sua dependência dos TEEs. Os ETEs de produção têm recentemente demonstrou ter uma série de vulnerabilidades graves, embora a tecnologia esteja na sua infância e irá, sem dúvida, amadurecer. Consulte os Apêndices B.2.1 e B.2.2 para discussão mais aprofundada sobre ETEs. Para alguns exemplos de aplicações de DECO e Town Crier, consulte as Seções 4.3, 4.5 e 9.4.3 e Apêndice C.1. 3.6.3 Serviços Chainlink existentes na rede As redes Chainlink oracle fornecem vários serviços principais em uma multiplicidade de blockchains e outros sistemas descentralizados hoje. Evolução adicional conforme descrito neste whitepaper dotará esses serviços existentes com recursos adicionais e alcance. Três exemplos são: Feeds de dados: Hoje, a maioria dos usuários de Chainlink que dependem de smart contracts fazem uso de feeds de dados. Estes são relatórios sobre o valor atual dos principais dados de acordo com para fontes oficiais fora da cadeia. Por exemplo, feeds de preços são feeds que informam os preços de ativos - criptomoedas, commodities, forex, índices, ações, etc. - de acordo com trocas ou serviços de agregação de dados. Esses feeds hoje já ajudam a garantir bilhões de dólares em valor na cadeia por meio de seu uso em sistemas DeFi como Aave [147] e Sintetix [208]. Outros exemplos de feeds de dados Chainlink incluem dados meteorológicos para seguro agrícola paramétrico [75] e dados eleitorais [93], entre vários outros. A implantação de DONs e outras tecnologias descritas neste documento melhorará o fornecimento de feeds de dados em redes Chainlink de várias maneiras, incluindo: • Dimensionamento: OCR e subsequentemente DONs visam permitir o dimensionamento dos serviços Chainlink dramaticamente nos muitos blockchains que eles suportam. Por exemplo, esperamos que DONs ajudarão a aumentar o número de feeds de dados fornecidos pelos nós usando Chainlink de 100 a 1000 e além. Esse dimensionamento ajudará o Chainlink ecossistema atingir seu objetivo de fornecer dados relevantes para smart contracts de forma abrangente e atender e antecipar as necessidades existentes e futuras.• Segurança aprimorada: ao armazenar relatórios intermediários, DONs reterão registros de comportamentos de nós para monitoramento e medição de alta fidelidade de seu desempenho e precisão, permitindo uma forte base empírica de sistemas de reputação para nós Chainlink. O FSS e o TEF permitirão a incorporação de feeds de preços com dados de transação de maneiras flexíveis que evitam ataques como front-running. (Explícito) staking reforçará a proteção criptoeconômica existente da segurança de feeds de dados. • Agilidade de alimentação: como sistemas agnósticos blockchain (na verdade, mais amplamente, sistemas agnósticos de consumo), DONs podem facilitar o fornecimento de feeds de dados para uma multiplicidade de sistemas confiáveis. Um único DON pode enviar um determinado feed simultaneamente para um conjunto de diferentes blockchains, eliminando a necessidade de redes oracle por cadeia e permitindo a rápida implantação de feeds existentes em novos blockchains e de adicionais feeds em blockchains atualmente atendidos. • Confidencialidade: A capacidade de realizar computação generalizada em um DON permite que cálculos em dados confidenciais ocorram off-chain, evitando on-chain exposição. Além disso, utilizando DECO ou Town Crier, é possível conseguir confidencialidade ainda mais forte, permitindo a geração de relatórios com base em dados que não são exposto até mesmo a nós DON. Consulte a Seção 4.3 e a Seção 4.5 para exemplos. Funções aleatórias verificáveis (VRFs): Vários tipos de DApps exigem uma fonte de aleatoriedade comprovadamente correta para permitir a verificação de sua própria operação justa. Tokens Não Fungíveis (NFTs) são um exemplo. A raridade dos recursos NFT em Aavegotchi [23] e Axie Infinity [35] é determinada por Chainlink VRF, assim como a distribuição de NFTs por meio de sorteios baseados em tickets em Cartões Ether [102]; a grande variedade de DApps de jogos cujos resultados são aleatórios; e instrumentos financeiros não convencionais, por exemplo, jogos de poupança sem perdas, como PoolTogether [89], que alocam fundos para vencedores aleatórios. Outros aplicativos blockchain e não blockchain também exigem segurança fontes de aleatoriedade, incluindo a seleção de comitês do sistema descentralizado e o execução de loterias. Embora os blocos hashes possam servir como uma fonte de aleatoriedade imprevisível, eles são vulneráveis à manipulação por mineradores adversários (e, até certo ponto, por usuários que enviam transações). Chainlink VRF [78] oferece uma alternativa consideravelmente mais segura. Um oracle possui um par de chaves privada/pública associado (sk, pk) cuja chave privada é mantida off-chain e cuja chave pública pk é publicada. Para gerar um valor aleatório, é aplica sk a uma semente imprevisível x fornecida por um contrato confiável (por exemplo, um bloco hash e parâmetros específicos do DApp) usando uma função F, produzindo y = Fsk(x) junto com um prova de correção. (Consulte [180] para o VRF disponível em Chainlink.) O que torna um VRF verificável é o fato de que com o conhecimento de pk é possível verificar a exatidão da prova e, portanto, de y. O valor y é consequentemente imprevisível para um adversário que não pode prever x ou aprender sk e é inviável para o serviço manipular.Chainlink VRF pode ser visto apenas como parte de uma família de aplicações que envolvem a custódia de chaves privadas off-chain. De forma mais geral, DONs podem oferecer segurança, armazenamento descentralizado de chaves individuais para aplicativos e/ou usuários e combinar esta capacidade com computação generalizada. O resultado é uma série de aplicações, de que damos alguns exemplos neste artigo, incluindo gerenciamento de chaves para Prova de Reservas (ver Seção 4.1) e para credenciais descentralizadas de usuários (e outras activos) (ver Secção 4.3). Guardiões: Chainlink Keepers [87] permitem que os desenvolvedores escrevam código para sistemas descentralizados execução de trabalhos fora da cadeia, geralmente para acionar a execução de smart contracts confiáveis. Antes do advento dos Keepers, era comum que os desenvolvedores operassem tais plataformas fora da cadeia. lógica, criando pontos de falha centralizados (bem como esforços de desenvolvimento duplicados consideráveis). Em vez disso, os Keepers fornecem uma estrutura fácil de usar para terceirização descentralizada dessas operações, possibilitando ciclos de desenvolvimento mais curtos e forte garantia de vivacidade e outras propriedades de segurança. Os Keepers podem apoiar qualquer de uma ampla variedade de objetivos desencadeadores, incluindo liquidação de empréstimos dependente do preço ou execução de transações financeiras, início dependente do tempo de lançamentos aéreos ou pagamentos em sistemas com colheita produtiva e assim por diante. Na estrutura DON, os iniciadores podem ser vistos como uma generalização dos Guardiões em vários sentidos. Os iniciadores podem fazer uso de adaptadores e, portanto, podem aproveitar uma biblioteca modularizada de interfaces para sistemas on-chain e off-chain, permitindo rápida desenvolvimento de funcionalidades seguras e sofisticadas. Iniciadores iniciam a computação em executáveis, que oferecem toda a versatilidade dos DONs, permitindo a ampla gama de serviços descentralizados que apresentamos neste artigo para aplicações on-chain e off-chain. 3.6.4 Reputação do nó/histórico de desempenho O ecossistema Chainlink existente documenta nativamente os históricos de desempenho de nós contribuintes na cadeia. Esse recurso deu origem a uma coleção de recursos orientados à reputação que ingerem, filtram e visualizam dados de desempenho de indivíduos. operadores de nós e feeds de dados. Os usuários podem consultar esses recursos para obter informações decisões na seleção de nós e monitorar a operação das redes existentes. Recursos semelhantes ajudarão os usuários a escolher DONs. Por exemplo, hoje em dia, os mercados sem permissão, como market.link, permitem que o nó operadores listem seus serviços oracle e ateste suas identidades fora da cadeia por meio serviços como Keybase [4], que vinculam o perfil de um nó em Chainlink ao seu nomes de domínio existentes e contas de mídia social do proprietário. Além disso, o desempenho ferramentas analíticas, como as disponíveis em market.link e reputação.link, permitem usuários visualizem estatísticas sobre o desempenho histórico de nós individuais, incluindo seus latência média de resposta, o desvio dos valores em seus relatórios dos valores de consenso retransmitidos na cadeia, receitas geradas, empregos realizados e muito mais. Essas ferramentas analíticas também permitir que os usuários rastreiem a adoção de várias redes oracle por outros usuários, uma forma deendosso implícito dos nós que protegem essas redes. O resultado é uma “rede de confiança” na qual, ao usar nós específicos, aplicações descentralizadas de alto valor criam um sinal de sua confiança nos nós que outros usuários podem observar e levar em consideração em seus próprias decisões de seleção de nós. Com DONs (e inicialmente com OCR) ocorre uma mudança no processamento de transações e atividade de contrato mais geralmente fora da cadeia. Um modelo descentralizado para nó de gravação o desempenho permanece possível dentro do próprio DON. Na verdade, o alto desempenho e a capacidade de dados de DONs tornam possível construir registros de maneira fina maneira e também para realizar computação descentralizada nesses registros, produzindo resumos confiáveis que podem ser consumidos por serviços de reputação e verificados em MAINCHAIN. Embora seja possível, em princípio, que um DON deturpe o comportamento dos nós constituintes se uma grande fração dos nós estiver corrompida, notamos que o coletivo o desempenho do próprio DON na entrega de dados on-chain é visível em MAINCHAIN e, portanto, não pode ser deturpada. Além disso, planejamos explorar mecanismos que incentivar relatórios internos precisos sobre o comportamento dos nós em um DON. Por exemplo, reportando o subconjunto de nós de alto desempenho que retornam mais rapidamente dados que contribuem para um relatório transmitido em cadeia, um DON cria um incentivo para os nós contestarem relatórios: incluir nós incorretamente neste subconjunto significa excluir nós incorretamente que deveriam ter sido incluídos e, portanto, penalizá-los inválidamente. Falhas repetidas de relatórios por parte de um DON também criariam um incentivo para que os nós honestos deixassem o DON. Compilação descentralizada de históricos de desempenho precisos e a consequente capacidade dos usuários de identificar nós de alto desempenho e de os operadores de nós construírem reputações são características distintivas importantes do ecossistema Chainlink. Nós mostrar na Seção 9 como podemos raciocinar sobre eles como uma peça-chave de uma abordagem rigorosa e visão expansiva da segurança econômica fornecida por DONs.

Serviços descentralizados habilitados por descentralizados

Redes Oracle Para ilustrar a versatilidade dos DONs e como eles permitem uma série de novos serviços, apresentamos cinco exemplos de aplicativos baseados em DON nesta seção e descrevemos o contratos híbridos que os realizam: (1) Prova de Reservas, uma forma de serviço cross-chain; (2) Interface com sistemas corporativos/legados, ou seja, criação de um ambiente baseado em middleware camada de abstração que facilita o desenvolvimento de aplicativos blockchain com o mínimo blockchain-código ou conhecimento específico; (3) Identidade descentralizada, ferramentas que permitem aos utilizadores obter e gerenciar seus próprios documentos e credenciais de identidade; (4) Canais prioritários, um serviço que garante a inclusão oportuna de transações de infraestrutura crítica (por exemplo, oracle relatórios) em blockchain; e (5) DeFi de preservação de confidencialidade, ou seja, financeiro smart contracts que ocultam os dados confidenciais das partes participantes. Aqui, nós

use SC para denotar a parte MAINCHAIN de um contrato híbrido e descreva o DON componente separadamente ou em termos de um executável exec. 4.1 Comprovante de Reservas Para muitas aplicações, é útil retransmitir o estado entre blockchains. Um Uma aplicação popular de tais serviços é o empacotamento de criptomoedas. Moedas embrulhadas como como WBTC [15] estão se tornando um ativo popular nas finanças descentralizadas (DeFi). Eles envolvem o depósito do ativo de garantia “embrulhado” em sua fonte blockchain MAINCHAIN(1) e criando um token correspondente em um destino blockchain MAINCHAIN(2) diferente. Por exemplo, WBTC é um ERC20 token no Ethereum blockchain que corresponde para BTC no Bitcoin blockchain. Como os contratos em MAINCHAIN(2) não têm visibilidade direta em MAINCHAIN(1), eles devem confiar explícita ou implicitamente em um oracle para relatar os depósitos do pacote embalado ativo em um smart contract, produzindo o que às vezes é chamado de Prova de Reservas. Em WBTC [15], por exemplo, o custodiante BitGo detém BTC e emite WBTC, com o Chainlink rede que fornece Comprovantes de Reserva [76]. Um DON pode fornecer uma Prova de Reservas. Com um DON, entretanto, é possível para ir mais longe. Um DON pode gerenciar segredos e, através do uso de adaptadores apropriados, pode fazer transações em qualquer blockchain desejado. Consequentemente, é possível que o DON atue como um entre vários custodiantes - ou mesmo como um único custodiante descentralizado - para um ativo embrulhado. DONs podem servir como uma plataforma para aumentar a segurança de serviços existentes que utilizam Provas de Reservas. Por exemplo, suponha que MAINCHAIN(1) seja Bitcoin e MAINCHAIN(2) seja Ethereum. Em MAINCHAIN(2), um contrato SC emite tokens representando BTC embalado. O DON controla um endereço BTC addr(1) DON. Para encapsular o BTC, então, um usuário U envia X BTC de endereço(1) Você para endereço(1) DON junto com um endereço MAINCHAIN(2) addr(2) Você. O DON monitora endereço(1) DON através de um adaptador para MAINCHAIN(1). Ao observar o depósito de U, com confirmação de probabilidade suficientemente alta, ele envia uma mensagem para SC através de um adaptador para CORRENTE PRINCIPAL(2). Esta mensagem instrui SC a cunhar X tokens para addr(2) Você. Para U liberar X tokens, acontece o inverso. Em MAINCHAIN(1), entretanto, endereço(1) DON envia X BTC para addr(1) U (ou para outro endereço, se assim for solicitado pelo utilizador). Esses protocolos podem ser adaptados, é claro, para funcionar com exchanges, em vez de diretamente com os usuários. 4.2 Interface com sistemas corporativos/legados DONs podem servir como pontes entre blockchains, como no exemplo de Prova de Reservas, mas outro objetivo é que atuem como pontes bidirecionais entre blockchains e sistemas legados [176] ou sistemas semelhantes a blockchain, como banco central moedas digitais [30]. As empresas enfrentam uma série de desafios para conectar seus sistemas existentes e processos para sistemas descentralizados, incluindo:• Agilidade Blockchain: Os sistemas Blockchain mudam rapidamente. Uma empresa pode enfrentar o rápido aparecimento ou aumento de popularidade de blockchains nos quais contrapartes desejam realizar transações, mas para as quais a empresa não tem suporte em sua infra-estrutura existente. Em geral, o dinamismo de blockchains faz com que é difícil para as empresas individuais manterem-se a par de todo o ecossistema. • Recursos de desenvolvimento específicos para Blockchain: Para muitas organizações, contratar ou incubar conhecimentos blockchain de ponta é difícil, especialmente em vista da desafio da agilidade. • Gerenciamento de chaves privadas: o gerenciamento de chaves privadas para blockchains ou criptomoedas requer conhecimento operacional distinto daquele da segurança cibernética tradicional práticas e indisponíveis para muitas empresas. • Confidencialidade: As empresas desconfiam de expor seus dados confidenciais e proprietários dados na cadeia. Para resolver as três primeiras dessas dificuldades, os desenvolvedores podem simplesmente usar um DON como uma camada de middleware segura para permitir que sistemas corporativos leiam ou gravem em blockchains. O DON pode abstrair considerações técnicas detalhadas, como dinâmica de gases, reorganização da cadeia e assim por diante, tanto para desenvolvedores quanto para usuários. Por apresentando uma interface blockchain simplificada para sistemas corporativos, um DON pode, portanto, simplificar consideravelmente o desenvolvimento de aplicativos empresariais com reconhecimento de blockchain, eliminando o fardo das empresas de adquirir ou incubar recursos de desenvolvimento específicos de blockchain. Esse uso de DONs é especialmente atraente porque permite que os desenvolvedores corporativos criar aplicativos de contratos inteligentes que são em grande parte blockchain agnósticos. Como resultado, o maior o conjunto de blockchains para os quais um DON é instrumentado para atuar como middleware, o maior o conjunto de blockchains aos quais os usuários corporativos podem obter acesso fácil. Desenvolvedores pode portar aplicativos de blockchains existentes para novos com modificação mínima às suas aplicações desenvolvidas internamente. Para resolver o problema adicional da confidencialidade, os desenvolvedores podem recorrer ao ferramentas que apresentamos neste documento e esperamos implantar para suporte a aplicativos DON. Estes incluem DECO e Town Crier Seção 3.6.2, bem como sistemas de preservação de confidencialidade Modificações de API discutidas na Seção 7.1.2 e uma série de abordagens específicas de aplicação abordadas no restante desta seção. Esses sistemas DON podem fornecer atestados on-chain de alta integridade sobre o estado do sistema empresarial sem revelar dados confidenciais de origem empresarial na cadeia. 4.3 Identidade Descentralizada Identidade descentralizada é um termo geral para a noção de que os usuários devem ser capazes de obter e gerenciar suas próprias credenciais, em vez de depender de terceiros para fazer então. Credenciais descentralizadas são atestados de atributos ou afirmações do titular,que muitas vezes são chamados de reivindicações. As credenciais são assinadas digitalmente por entidades, muitas vezes chamadas emissores, que podem associar declarações com autoridade aos usuários. Na maioria dos esquemas propostos, reivindicações estão associadas a um Identificador Descentralizado (DID), um identificador universal para um determinado usuário. As credenciais estão vinculadas a uma chave pública cuja chave privada o usuário possui. O usuário pode assim provar a posse de uma reivindicação usando sua chave privada. Por mais visionários que sejam a identidade descentralizada, os esquemas existentes e propostos, por exemplo, [14, 92, 129, 216], têm três limitações severas: • Falta de compatibilidade legada: Os sistemas de identidade descentralizados existentes dependem de um comunidade de autoridades, chamadas emissores, para produzir credenciais DID. Porque os serviços web existentes geralmente não assinam dados digitalmente, os emissores devem ser lançados como sistemas para fins especiais. Porque não há incentivo para fazer isso sem uma ecossistema de identidade descentralizada, o resultado é um problema do ovo e da galinha. Em outro palavras, não está claro como inicializar um ecossistema de emissores. • Gerenciamento de chaves impraticável: Os sistemas de identidade descentralizados exigem que os usuários gerenciar chaves privadas, algo que a experiência com criptomoeda mostrou ser um ônus inviável. Estima-se que cerca de 4.000.000 Bitcoin foram perdidos para sempre devido a falhas de gerenciamento de chaves [194], e muitos usuários armazenam seus ativos criptográficos com exchanges [193], minando assim a descentralização. • Falta de resistência Sybil que preserve a privacidade: Um requisito básico de segurança de aplicações como votação, alocação justa de tokens durante vendas de token, etc. os usuários não poderão afirmar múltiplas identidades. As propostas de identidade descentralizadas existentes exigem que os utilizadores revelem as suas identidades do mundo real, a fim de alcançar tal resistência Sybil, minando assim importantes garantias de privacidade. É possível resolver estes problemas usando uma combinação de um comitê de nós realizando computação distribuída dentro de um DON e o uso de ferramentas como DECO ou Town Crier, conforme mostrado em um sistema chamado CanDID [160]. DECO ou Town Crier podem, por design, transformar serviços web existentes sem modificação em emissores de credenciais que preservam a confidencialidade. Eles permitem que um DON exporte dados relevantes dados para esse fim em uma credencial, ocultando dados confidenciais que não deveriam aparecem na credencial. Além disso, para facilitar a recuperação de chaves para os usuários, abordando assim o problema de gerenciamento de chaves problema, um DON pode permitir que os usuários armazenem chaves privadas em formato secreto compartilhado. Os usuários podem recupere suas chaves provando aos nós no DON - da mesma forma, usando Town Crier ou DECO – uma capacidade de fazer login em contas com um conjunto de provedores da web pré-determinados (por exemplo, Twitter, Google, Facebook). O benefício de usar Town Crier ou DECO, em oposição a OAUTH, é a privacidade do usuário. Essas duas ferramentas permitem que o usuário evite revelar ao DON um identificador de provedor da web – do qual muitas vezes podem ser derivadas identidades do mundo real. Finalmente, para fornecer resistência Sybil, conforme mostrado em [160], é possível que um DON realizar uma transformação que preserva a privacidade de identificadores exclusivos do mundo real para usuários (por exemplo, números de segurança social (SSNs)) em identificadores na rede após o registro do usuário.O sistema pode, assim, detectar registros duplicados sem dados confidenciais, como SSNs sendo revelados para nós DON individuais.7 Um DON pode fornecer qualquer um desses serviços em nome de identidade descentralizada externa sistemas em blockchains sem ou com permissão, por exemplo, instâncias do Hyperledger Indy [129]. Exemplo de aplicação: KYC: A identidade descentralizada é promissora como meio de simplificar os requisitos para aplicações financeiras em blockchains enquanto melhora o usuário privacidade. Dois desafios que pode ajudar a resolver são as obrigações de acreditação e conformidade ao abrigo dos regulamentos anti-lavagem de dinheiro/conheça o seu cliente (AML/KYC). As regulamentações ABC em muitos países exigem que as instituições financeiras (e outras empresas) estabeleçam e verifiquem as identidades de indivíduos e empresas com as quais eles realizam transações. KYC constitui um componente do sistema de uma instituição financeira uma política ABC mais ampla, que normalmente também envolve a monitorização do comportamento dos utilizadores e a observação dos fluxos de fundos, entre outras coisas. O KYC normalmente envolve a apresentação de credenciais de identidade pelo usuário de alguma forma (por exemplo, entrada em um formulário on-line da web, segurando um documento de identidade na frente do rosto do usuário em uma sessão de vídeo, etc.). Criação segura e apresentação de credenciais descentralizadas poderia, em princípio, ser uma alternativa benéfica em vários aspectos, nomeadamente: (1) Fazendo o processo KYC mais eficiente para usuários e instituições financeiras, porque uma vez a credencial for obtida, ela poderá ser apresentada perfeitamente a qualquer instituição financeira; (2) Reduzir a fraude, reduzindo as oportunidades de roubo de identidade através de comprometimento de informações de identificação pessoal (PII) e falsificação durante a verificação de vídeo; e (3) Reduzir o risco de comprometimento de PII em instituições financeiras, à medida que os usuários mantêm o controle dos seus próprios dados. Dadas as multas multibilionárias pagas pelas instituições financeiras por falhas de conformidade com a AML, e as muitas instituições financeiras que gastam milhões de dólares anualmente em KYC, as melhorias poderiam gerar poupanças consideráveis para as instituições financeiras. e, por extensão, para consumidores [196]. Embora o setor financeiro tradicional seja lento para adotar novas ferramentas de conformidade, DeFi os sistemas estão cada vez mais adotando-as [43]. Exemplo de aplicação: Empréstimos com garantia insuficiente: A maioria dos aplicativos DeFi que os empréstimos de apoio hoje originam apenas empréstimos totalmente garantidos. Estes são empréstimos feitos para mutuários que depositam ativos de criptomoeda de valor superior ao dos empréstimos. Recentemente surgiu interesse naquilo que a comunidade DeFi geralmente chama de empréstimos com garantia insuficiente. Estes, pelo contrário, são empréstimos para os quais a garantia correspondente tem valor inferior ao do principal do empréstimo. Empréstimos com garantia insuficiente assemelham-se a empréstimos frequentemente concedidos por instituições financeiras tradicionais. Em vez de confiar na garantia depositada como garantia do reembolso do empréstimo, eles baseiam o empréstimo decisões sobre os históricos de crédito dos mutuários. 7Essa transformação depende de uma função pseudoaleatória distribuída (PRF).Os empréstimos com garantia insuficiente constituem uma parte nascente, mas crescente, do mercado de empréstimos DeFi. Eles dependem de mecanismos como aqueles empregados pelas finanças tradicionais. instituições, como contratos legais [91]. Um requisito essencial para o seu crescimento será a capacidade de fornecer dados sobre a qualidade de crédito do usuário - um fator-chave nas decisões de empréstimo convencionais - para sistemas DeFi de uma forma que forneça forte integridade, ou seja, garantia de dados corretos. Um sistema de identidade descentralizado habilitado para DON permitiria que os possíveis mutuários gerar credenciais de alta garantia que atestem sua qualidade de crédito, preservando ao mesmo tempo a confidencialidade de informações sensíveis. Especificamente, os mutuários podem gerar esses credenciais baseadas em registros de fontes on-line confiáveis, expondo apenas o dados atestados por DON, sem expor outros dados potencialmente sensíveis. Para Por exemplo, um mutuário pode gerar uma credencial indicando que sua pontuação de crédito com um conjunto de agências de crédito excede um limite específico (por exemplo, 750), sem revelar seu pontuação precisa ou quaisquer outros dados em seus registros. Além disso, se desejado, tais credenciais podem ser gerados anonimamente, ou seja, o nome do usuário pode ser tratado como dado sensível e ela própria não está exposta aos nós oracle ou em sua credencial descentralizada. A credencial em si pode ser usado em cadeia ou fora da cadeia, dependendo da aplicação. Em resumo, um mutuário pode fornecer informações essenciais aos credores sobre o seu crédito histórias com forte integridade e sem risco de exposição de informações desnecessárias e sensíveis dados. Um mutuário também pode fornecer uma variedade de outras credenciais que preservam a confidencialidade útil na tomada de decisões de empréstimo. Por exemplo, as credenciais podem atestar a posse de ativos (fora da cadeia), como mostramos em nosso próximo exemplo. Exemplo de aplicação: Credenciamento: Muitas jurisdições limitam a classe de investidores aos quais os títulos não registrados podem ser vendidos. Por exemplo, nos EUA, SEC O Regulamento D estipula que para ser credenciado para tais oportunidades de investimento, um o indivíduo deve possuir um patrimônio líquido de US$ 1 milhão, atender a certos requisitos de renda mínima ou ter certas qualificações profissionais [209, 210]. Credenciamento atual processos são complicados e ineficientes, muitas vezes exigindo uma carta de atestado do um contador ou evidência semelhante. Um sistema de identidade descentralizado permitiria aos usuários gerar credenciais de contas de serviços financeiros on-line existentes que comprovem conformidade com o credenciamento regulamentações, facilitando um processo KYC mais eficiente e que preserva a privacidade. O Além disso, as propriedades de preservação da privacidade da DECO e da Town Crier permitiriam que estes credenciais a serem geradas com uma forte garantia de integridade, sem revelar diretamente detalhes da situação financeira de um usuário. Por exemplo, um usuário pode gerar uma credencial provar que ela tem um patrimônio líquido de pelo menos US$ 1 milhão sem revelar qualquer valor adicional informações sobre sua situação financeira. 4.4 Canais Prioritários Os canais prioritários são um novo serviço útil e fácil de construir usando um DON. Seu

o objetivo é entregar transações selecionadas e de alta prioridade em tempo hábil no MAINCHAIN durante períodos de congestionamento da rede. Os canais prioritários podem ser vistos como uma forma de contrato futuro no espaço do bloco e, portanto, como uma criptomoeda, um termo cunhado como parte do Projeto Chicago [61, 136]. Os canais prioritários destinam-se especificamente aos mineradores para permitir serviços de infraestrutura, como oracles, funções de governança para contratos, etc. – e não para atividades comuns no nível do usuário, como transações financeiras. Na verdade, tal como concebido aqui, uma prioridade canal implementado por menos de 100% do poder de mineração na rede só pode fornecem limites frouxos nos prazos de entrega, evitando seu uso para tarefas altamente dependentes da velocidade. objetivos como a liderança. Figura 10: Um canal prioritário é uma garantia de um minerador M – ou, mais geralmente, um conjunto de mineradores M - para um usuário U que sua transação τ será extraída em D blocos de inclusão no mempool. Um SC de contrato pode usar monitoramento DON para fazer cumprir o termos de serviço do canal. Um canal prioritário assume a forma de um acordo entre um minerador ou um conjunto de mineradores (ou pools de mineração) M que fornece o canal e um usuário U que paga uma taxa pelo acesso. M concorda que quando U envia uma transação τ ao mempool (com qualquer preço de gás,mas um limite de gás pré-acordado), M irá colocá-lo na cadeia nos próximos blocos D.8 A ideia é representada esquematicamente na Fig. Descrição do contrato de canal prioritário: Um canal prioritário pode ser realizado como um híbrido smart contract aproximadamente como segue. Deixamos SC denotar a lógica em MAINCHAIN e isso em DON por exec. SC aceita um depósito/aposta \(d from M and an advance payment \)p dos EUA DON executável exec monitora o mempool, acionando na colocação de uma transação por U. Ele envia uma mensagem de sucesso para SC se U enviar uma transação que M minera em em tempo hábil e uma mensagem de falha em caso de falha no serviço. SC envia o pagamento $p para M com uma mensagem de sucesso e envia todos os fundos restantes, incluindo $d, para U se receber uma mensagem de falha. Após a rescisão bem-sucedida, libera o depósito $d para M. O minerador M pode, é claro, fornecer canais prioritários simultaneamente para vários usuários e pode abrir um canal prioritário com U para um número pré-acordado de mensagens. 4,5 Preservação de confidencialidade DeFi / Mixicles Hoje, DeFi aplicativos [1] fornecem pouca ou nenhuma confidencialidade aos usuários: todas as transações são visíveis na cadeia. Várias abordagens baseadas em conhecimento zero, por exemplo, [149, 217], podem fornecer privacidade às transações e o TEF é geral o suficiente para apoiá-los. Mas essas abordagens não são abrangentes e, por exemplo, normalmente não escondem o ativo no qual uma transação se baseia. O amplo conjunto de ferramentas computacionais que pretendemos apoiar em DONs irá permitir a privacidade de diversas maneiras diferentes que podem preencher essas lacunas, ajudando a complementar as garantias de privacidade de outros sistemas. Por exemplo, Mixicles, um instrumento de preservação de confidencialidade DeFi proposto por Chainlink pesquisadores do Labs [135], pode ocultar o tipo de ativo que respalda um instrumento financeiro e se enquadra muito naturalmente no DON quadro. Mixicles são mais facilmente explicados em termos de seu uso para realizar um sistema binário simples. opção. Uma opção binária é um instrumento financeiro no qual dois usuários, que iremos consulte aqui para consistência com [135] como jogadores, aposte em um evento com dois possíveis resultados, por exemplo, se um ativo excede ou não um preço-alvo em um momento pré-designado. O exemplo a seguir ilustra a ideia. Exemplo 2. Alice e Bob são partes de uma opção binária baseada no valor de um ativo chamado Carol’s Bubble Token (CBT). Alice aposta que o CBT terá um preço de mercado de pelo menos pelo menos 250 USD no horário T = meio-dia de 21 de junho de 2025; Bob aposta o contrário. Cada jogador deposita 100 ETH em um prazo pré-especificado. O jogador com a posição vencedora recebe 200 ETH (ou seja, ganha 100 ETH). É claro que 8D deve ser grande o suficiente para garantir que M possa cumprir com alta probabilidade. Para Por exemplo, se M controlar 20% do poder de mineração na rede, ele poderá escolher D = 100, garantindo uma probabilidade de falha de ≈2 × 10−10, ou seja, menos de uma em um bilhão.Dada uma rede Chainlink oracle O existente, é fácil implementar um sistema inteligente contrato SC que realiza o acordo no Exemplo 2. Cada um dos dois jogadores deposita 100 ETH em SC. Algum tempo depois de T, uma consulta q é enviada a O solicitando o preço r de CBT no momento T. O envia um relatório r desse preço para SC. SC então envia dinheiro para Alice se r ≥250 e Bob se não. Esta abordagem, no entanto, revela r em cadeia – tornando mais fácil para um observador deduzir o ativo subjacente à opção binária. Na terminologia de Mixicles, é útil pensar conceitualmente no resultado de SC em termos de um Switch que transmite um valor binário calculado como um predicado interruptor (r). Em nosso exemplo, switch(r) = 0 se r ≥250; dado este resultado, Alice vence. Caso contrário switch(r) = 1 e Bob vence. Um DON pode realizar um Mixicle básico como um contrato híbrido executando um executável exec que calcula switch(r) e reporta-o em cadeia para SC. Mostramos esta construção na Figura 11. Figura 11: Diagrama do Mixicle básico no Exemplo 2. Para fornecer sigilo na cadeia para relatório r e, portanto, o ativo subjacente à opção binária, o oracle envia para o contrate SC via Switch apenas o valor binário switch(r). Especificamos um adaptador ConfSwitch no Apêndice C.3 que torna mais fácil conseguir isso meta em um DON. A ideia básica por trás do ConfSwitch é bastante simples. Em vez de relatar o valor r, ConfSwitch relata apenas o valor da chave binária switch(r). SC pode ser projetado para fazer um pagamento correto com base apenas no switch(r) e no switch(r) por si só não revela nenhuma informação sobre o ativo subjacente – CBT em nosso exemplo. Além disso, colocando um texto cifrado em (q, r) no livro-razão criptografado em pkaud, a chave pública de um auditor, o adaptador ConfSwitch cria uma trilha de auditoria que preserva a confidencialidade. O Mixicle básico que escolhemos para simplificar a descrição aqui esconde apenas o ativo e aposta atrás da opção binária em nosso exemplo. Um Mixicle completo [135] pode fornecer duas formas de confidencialidade. Ela esconde dos observadores: (1) Qual evento o os jogadores apostam em (ou seja, q e r), mas também (2) em qual jogador ganhou a aposta. Como os Mixicles são executados no MAINCHAIN, qualquer um dos jogadores precisaria retransmitir switch(r) de DON para MAINCHAIN, ou um executável exec pode ser criado que

é acionado na saída pelo ConfSwitch e chama outro adaptador para enviar switch(r) para MAINCHAIN. Também vale a pena considerar um terceiro tipo sutil de confidencialidade. Em uma implementação básica do ConfSwitch, O está executando o adaptador no DON e, portanto, aprende o ativo – CBT em nosso exemplo – e, portanto, a natureza da opção binária. Conforme discutido no Apêndice C.3, no entanto, também é possível usar DECO ou Town Crier para ocultar até mesmo esta informação de O. Neste caso, o O não aprende mais informações do que um observador público de SC. Para mais detalhes sobre Mixicles, recomendamos aos leitores [135].

Serviços de sequenciamento justo

Um serviço importante que esperamos que DONs ofereça e que aproveite seus recursos de rede, computação e armazenamento é chamado de Fair Sequencing Services (FSS). Embora o FSS possa ser visto simplesmente como uma aplicação realizada dentro da estrutura DON, destacamos-o como um serviço que acreditamos que terá alta demanda em todo o mundo. blockchains, e que esperamos que a rede Chainlink suporte ativamente. Quando executados em redes blockchain públicas, muitos dos aplicativos DeFi atuais revelar informações que podem ser exploradas pelos usuários em seu próprio benefício, de forma análoga a o tipo de vazamentos internos e oportunidades de manipulação que são difundidos nos mercados existentes mercados [64, 155]. Em vez disso, o FSS abre caminho para um ecossistema DeFi justo. FSS ajuda os desenvolvedores a construir contratos DeFi protegidos contra manipulação de mercado decorrentes de vazamento de informações. Dados os problemas que destacamos abaixo, o FSS é especialmente atraente para serviços da camada 2 e se enquadra na estrutura para tais serviços que discutimos na Seção 6. O desafio: Nos sistemas sem permissão existentes, as transações são ordenadas inteiramente a critério dos mineiros. Em redes autorizadas, os nós validator podem exercer o mesmo poder. Esta é uma forma de centralização efêmera em grande parte não reconhecida na sistemas de outra forma descentralizados. Um minerador pode (temporariamente) censurar transações para seus benefício próprio [171] ou reordená-los para maximizar seu próprio ganho, uma noção chamada valor minerextraível (MEV) [90]. O termo MEV é ligeiramente enganador: não se refere apenas ao valor que os mineradores podem capturar: Alguns MEV podem ser capturados por usuários comuns. No entanto, como os mineradores têm mais poder do que os usuários comuns, o MEV representa um limite superior na quantidade de valor que qualquer entidade pode obter por meio de reordenamento adversário. e inserção de transação complementar. Mesmo quando os mineradores ordenam transações simplesmente com base em taxas (gás), sem manipulação, os próprios usuários podem manipular os preços do gás para favorecer suas transações em detrimento daquelas de menor sofisticação. Daian et al. [90] documenta e quantifica as maneiras pelas quais os bots (não os mineradores) tomam vantagem da dinâmica dos gases de uma forma que prejudica os usuários dos sistemas DeFi hoje e como MEV até ameaça a estabilidade da camada de consenso subjacente em um blockchain. Outros exemplos de manipulação de ordens de transação surgem regularmente, por exemplo, [50, 154].Novos métodos de processamento de transações, como rollups, são uma abordagem muito promissora aos problemas de dimensionamento de blockchains de alto rendimento. Eles não abordam, no entanto, o problema do MEV. Em vez disso, eles o transferem para a entidade que gera o rollup. Isso entidade, seja o operador de um smart contract ou um usuário fornecendo a (zk-)rollup com uma prova de validade, tem o poder de ordenar e inserir transações. Em outras palavras, rollups trocar MEV por REV: valor extraível de rollup. MEV afeta as próximas transações que foram enviadas ao mempool mas ainda não estão comprometidos em cadeia. As informações sobre essas transações são amplamente disponível na rede. Mineiros, validators e participantes comuns da rede podem portanto, explore esse conhecimento e crie transações dependentes. Além disso, mineradores e validators podem influenciar a ordem das transações que realizam e explorar isso em seu benefício. O problema da influência indevida dos líderes na ordem das transações em consenso protocolos são conhecidos na literatura desde a década de 1990 [71, 190], mas nenhum soluções foram implementadas na prática até agora [97]. A principal razão é que as soluções propostas – pelo menos até muito recentemente – não podem ser facilmente integradas com os serviços públicos. blockchains, pois dependem do conteúdo das transações que permanecem secretas até depois sua ordem foi determinada. Visão geral dos Serviços de Sequenciamento Justo (FSS): DONs fornecerá ferramentas para descentralizar a ordenação de transações e implementá-las de acordo com uma política especificada por um país confiável. criador do contrato, de preferência um que seja justo e não vantajoso para os atores que desejam manipular a ordem das transações. Coletivamente, essas ferramentas constituem o FSS. O FSS inclui três componentes. O primeiro é o monitoramento das transações. No FSS, oracle nós em O monitoram o mempool de MAINCHAIN e (se desejado) permitem submissão off-chain de transações por meio de canal especializado. O segundo é o sequenciamento das transações. Os nós em transações de ordem O para um contrato confiável de acordo com uma política definida para esse contrato. O terceiro é o lançamento de transações. Após as transações serem ordenadas, os nós em O enviam conjuntamente as transações para o cadeia principal. Os benefícios potenciais do FSS incluem: • Equidade nas ordens: o FSS inclui ferramentas para ajudar os desenvolvedores a garantir que as transações contribuições para um determinado contrato sejam ordenadas de uma forma que não dê uma margem injusta vantagem para usuários com bons recursos e/ou tecnicamente experientes. Políticas de pedidos podem ser especificados para esse fim. • Redução ou eliminação de fugas de informação: Ao garantir que os participantes da rede não possam explorar o conhecimento sobre transacções futuras, o FSS pode reduzir ou eliminar ataques como front-running que são baseados em informações disponíveis em rede antes que as transações sejam confirmadas. Prevenir a exploração de tais o vazamento garante que as transações contraditórias que dependem da pendência original as transações não podem entrar no razão antes que as transações originais sejam confirmadas.• Custo de transação reduzido: eliminando a necessidade dos jogadores de velocidade no envio suas transações para smart contract, o FSS pode reduzir bastante o custo do processamento de transações. • Ordenação de prioridade: o FSS pode atribuir automaticamente prioridade especial a transações críticas encomenda. Por exemplo, para evitar ataques frontais contra oracle relatórios, por exemplo, [79], o FSS pode inserir um relatório oracle em um fluxo de transações retroativamente. Um objetivo abrangente do FSS em DONs é capacitar os criadores de DeFi para realizarem sistemas financeiros, isto é, sistemas que não beneficiam usuários específicos (ou mineradores) sobre outros com base na velocidade, conhecimento interno ou capacidade de executar tarefas técnicas manipulação. Embora uma noção clara e geral de justiça seja ilusória, e a justiça perfeita em qualquer sentido razoável é inatingível, o FSS visa fornecer aos desenvolvedores um poderoso conjunto de ferramentas para que possam aplicar políticas que ajudem a cumprir suas metas de design para DeFi. Observamos que embora o principal objetivo do FSS seja atuar como um serviço de sequenciamento justo para o MAINCHAIN que DONs tem como alvo, alguns dos mesmos desejos de justiça que o FSS garantias também podem ser apropriadas para protocolos (descentralizados) executados entre DON festas. Assim, o FSS pode ser visto de forma mais ampla como um serviço prestado por um subconjunto de nós DON para sequenciar de forma justa não apenas transações enviadas por usuários de MAINCHAIN mas também transações (ou seja, mensagens) compartilhadas entre outros nós DON. Nesta seção, focaremos principalmente no objetivo de sequenciar as transações MAINCHAIN. Organização da seção: Na Seção 5.1, descrevemos duas aplicações de alto nível que motivam o design do FSS: impedir a execução antecipada de relatórios oracle e prevenir front-running das transações do usuário. Em seguida, fornecemos mais detalhes sobre o design do FSS na Seção 5.2. A Seção 5.3 descreve exemplos de garantias e meios de pedidos justos para alcançá-los. Finalmente, a Seção 5.4 e a Seção 5.5 discutem ameaças em nível de rede para tais políticas e meios para enfrentá-las, respectivamente para inundação de rede e Sybil ataques. 5.1 O problema inicial Para explicar os objetivos e o design do FSS, descrevemos duas formas gerais de front-running ataques e as limitações das soluções existentes. Front-running exemplifica uma classe de ataques de ordenação de transações: há uma série de ataques relacionados, como backrunning e sanduíche (front-running mais back-running) [237] que não abordamos aqui, mas que o FSS também ajuda a resolver. 5.1.1 Oracle Front Running Em sua função tradicional de fornecer dados fora da cadeia para aplicações blockchain, oracles tornar-se um alvo natural para ataques frontais.Considere o padrão de design comum de usar um oracle para fornecer vários feeds de preços para uma exchange on-chain: periodicamente (digamos, a cada hora), o oracle coleta dados de preços para ativos diferentes e os envia para um contrato de troca. Essas transações de dados de preços apresentam oportunidades óbvias de arbitragem: por exemplo, se o relatório oracle mais recente listar um preço muito mais alto para algum ativo, um adversário poderia antecipar o relatório oracle para comprar ativos e revendê-los imediatamente assim que o relatório de oracle for processado. Redutores de velocidade e preços retroativos: Uma solução natural para o problema de frontrunning de oracle é dar aos relatórios oracle prioridade especial sobre outras transações. Para por exemplo, relatórios oracle poderiam ser enviados com taxas altas para incentivar os mineradores a processar eles primeiro. Mas isto não impedirá a liderança se a oportunidade de arbitragem for elevada, nem pode impedir a arbitragem por parte dos próprios mineiros. Algumas exchanges recorreram, portanto, à implementação de “redutores de velocidade” mais pesados, como enfileirar as transações do usuário por vários blocos antes do processamento. ou ajustando os preços retroativamente quando um novo relatório oracle chegar. As desvantagens destas soluções são que acrescentam complexidade à implementação da troca, aumentam os requisitos de armazenamento e, portanto, os custos de transação, e perturbam a experiência do usuário, pois as trocas de ativos só são confirmadas após um período de tempo significativo. Pegando carona: Antes de passarmos para o FSS, discutiremos o piggybacking, uma forma bastante simples e solução elegante para o problema inicial oracle. Não é aplicável ao endereço no entanto, liderando em outros cenários. Resumindo, em vez de enviar relatórios periodicamente para o contrato on-chain, oracles publicar relatórios assinados que os usuários anexam às suas transações ao comprar ou vender ativos na cadeia. A exchange então simplesmente verifica se o relatório é válido e atualizado (por exemplo, o oracle pode assinar um intervalo de blocos para os quais o relatório é válido) e extrai o feed de preço relevante dele. Esta abordagem simples tem uma série de vantagens sobre o “lombada” acima abordagem: (1) O contrato de câmbio não precisa manter o estado dos preços, o que deve levar a custos de transação mais baixos; (2) Como os relatórios oracle são publicados na rede conforme a necessidade, oracles podem gerar atualizações mais frequentes (por exemplo, a cada minuto), assim minimizar oportunidades de arbitragem na preparação de um relatório9; (3) As transações podem ser validados imediatamente, pois sempre incluem um novo feed de preços. A abordagem não é perfeita, no entanto. Primeiro, esta solução de carona coloca o responsabilidade dos usuários da exchange buscarem relatórios oracle atualizados e anexá-los aos seus transações. Em segundo lugar, embora o piggybacking minimize as oportunidades de arbitragem, não pode evitá-los totalmente sem afetar a vigência do contrato em cadeia. Na verdade, se um oracle o relatório é válido até algum número de bloco n, então uma transação submetida ao bloco n + 1 exigiria um novo relatório válido. Devido a atrasos inerentes na propagação de relatórios de oracles para os usuários, o novo relatório válido para o bloco n + 1 teria 9A arbitragem só vale a pena se a diferença explorável nos preços dos activos exceder a diferença externa taxas exigidas para comprar e vender os ativos, por exemplo, aquelas cobradas pelos mineradores e pela bolsa.a ser divulgado algum período antes do bloco n + 1 ser minerado, digamos, no bloco n −k, assim criando uma sequência de k blocos onde existe uma oportunidade de arbitragem de curta duração. Nós agora descreva como o FSS contorna essas limitações. Priorizando relatórios oracle com FSS: O FSS pode abordar o oracle front-running problema, aproveitando a solução de carona acima, mas empurrando o adicional trabalho de aumento de transações com relatórios oracle para a Rede Oracle Descentralizada. Em um nível alto, os nós oracle coletam transações destinadas a uma troca na cadeia, concordar com um feed de preços em tempo real e publicar o feed de preços junto com as transações coletadas no contrato da cadeia principal. Conceitualmente, pode-se pensar nesta abordagem como uma “lote de transações aumentadas de dados”, onde o oracle garante que um arquivo atualizado o feed de preços é sempre adicionado às transações. As soluções FSS podem ser implementadas de forma transparente para os usuários da bolsa e com mudanças mínimas na lógica do contrato, conforme descrevemos com mais detalhes na Seção 5.2. Garantindo que relatórios oracle recentes são sempre priorizados em relação às transações do usuário é apenas um exemplo de uma política de ordenação que o FSS possa adotar e aplicar. Políticas do FSS para garantir a ordem justiça são descritos de forma mais geral na Seção 5.3. 5.1.2 Transações de usuário iniciais Passamos agora para o front-running em aplicações genéricas, onde o método de defesa acima não funciona. O problema pode ser capturado de forma ampla através do seguinte cenário: Um adversário vê alguma transação do usuário tx1 enviada para a rede P2P e injeta sua própria transação adversária tx2, de modo que tx2 seja processado antes de tx1 (por exemplo, pagando uma taxa de transação mais alta). Por exemplo, este tipo de front-running é comum entre bots que exploram oportunidades de arbitragem em DeFi sistemas [90] e afetaram usuários de vários aplicativos descentralizados [101]. Imposição de uma ordem justa entre as transações processado em blockchain resolve esse problema. Mais fundamentalmente, às vezes nem é necessário ver os detalhes de tx1 e o conhecimento de sua mera existência pode permitir que um adversário avance o tx1 através de seu possuir o tx2 e fraudar o usuário inocente que criou o tx1. Por exemplo, o usuário pode ser conhecido por negociar um ativo específico em horários regulares. Prevenir tais ataques requer mitigações que também evitam o vazamento de metadados [62]. Algumas soluções para este problema existem, mas introduzem atrasos e preocupações de usabilidade. Do pedido de rede ao pedido finalizado com FSS: Oportunidades para liderança surgem porque os sistemas existentes não têm mecanismos para garantir que a ordem em que as transações aparecem em cadeia respeita a ordem dos eventos e o fluxo de informações fora da rede. Isto representa um problema decorrente de deficiências na implementação de aplicações (por exemplo, plataformas de negociação) em um blockchain. Idealmente, alguém garantir que as transações sejam confirmadas em blockchain na mesma ordem em que foram criado e enviado para a rede P2P de blockchain. Mas como a rede blockchain

é distribuído, tal ordem não pode ser capturada. O FSS introduz, portanto, mecanismos para proteger contra violações da justiça, que surgem apenas por causa da distribuição natureza da rede blockchain. 5.2 Detalhes do FSS Figura 12: Mempool de ordem justa com dois caminhos de transação diferentes: direto e baseado em mempool. A Figura 12 mostra um esquema geral do FSS. Para garantir a justiça, o DON que fornece o FSS deve interferir no fluxo das transações à medida que elas entram na MAINCHAIN. Ajustes nos clientes, nos smart contracts no MAINCHAIN ​​ou em ambos podem ser necessários. A um nível elevado, o processamento de transações pelo FSS pode ser decomposto em três fases, descritas a seguir: (1) Monitoramento das transações; (2) Sequenciamento de transações; e (3) Lançamento de transações. Dependendo do método de ordenação utilizado para sequenciamento de transações, são necessárias etapas adicionais de protocolo, conforme descrito na próxima seção. 5.2.1 Processamento de transações Monitoramento de transações: Prevemos duas abordagens diferentes para o FSS monitorar transações de usuário destinadas a um smart contract específico, diretas e baseadas em mempool: • Direto: A abordagem direta é conceitualmente mais simples, mas requer mudanças clientes usuários para que as transações sejam enviadas diretamente para o Oracle DescentralizadoNós da rede, em vez dos nós da cadeia principal. O DON coleta transações do usuário destinadas a um SC smart contract específico e as ordena com base em alguma política de pedidos. O DON então envia as transações solicitadas para o smart contract na cadeia principal. Alguns mecanismos de ordenação também requerem a abordagem direta porque o usuário que cria uma transação deve criptograficamente proteja-o antes de enviá-lo ao FSS. • Baseado em Mempool: Para facilitar a integração do FSS com clientes legados, o DON pode usar Mempool Services (MS) para monitorar o mempool da cadeia principal e coletar transações. A transmissão direta será provavelmente a implementação preferida para muitos contratos, e acreditamos que deveria ser bastante prático em muitos casos. Discutimos brevemente como os DApps existentes poderiam ser minimamente modificados para suportar transmissão direta, preservando uma boa experiência do usuário. Nós descrevemos abordagens usando Ethereum e MetaMask [6] já que essas são as escolhas mais populares hoje, mas as técnicas mencionadas devem se estender a outras redes e carteiras. Um Ethereum recente Proposta de Melhoria, “EIP-3085: Wallet add Ethereum método RPC de cadeia” [100], facilitará a segmentação de cadeias Ethereum personalizadas (usando um ID de CHAIN diferente do o do MAINCHAIN para evitar ataques de repetição) do MetaMask e outras carteiras baseadas em navegador. Após a implementação desta proposta, um DApp que pretenda utilizar um DON simplesmente adicionariam uma única chamada de método ao seu front-end para poder transmitir diretamente transações para qualquer DON expondo uma API compatível com Ethereum. Enquanto isso, “EIP-712: Ethereum dados estruturados digitados hashing e assinatura” [49] fornece um pouco alternativa mais envolvente, mas já amplamente implantada, onde um usuário DApp pode usar MetaMask para assinar dados estruturados especificando uma transação DON. O DApp pode enviar esses dados estruturados assinados para DON. Finalmente, notamos que abordagens híbridas também são possíveis. Por exemplo, legado os clientes podem continuar a enviar transações para o mempool da cadeia principal, mas transações (por exemplo, relatórios oracle) são enviadas diretamente para nós DON (em particular, o conjunto de nós que fornecem relatórios oracle, como atualizações de feed de preços e o conjunto de nós fornecimento do FSS pode sobrepor-se ou ser idêntico). Sequenciamento de transações: O principal objetivo do FSS é garantir que as transações dos usuários sejam ordenadas de acordo com uma política pré-definida. A natureza desta política irá dependem das necessidades do aplicativo e dos tipos de ordens de transação injustas que ele visa prevenir. Como o FSS no DON é capaz de processar dados e manter o estado local, eles podem impor uma política de sequenciamento arbitrária com base nas informações que são disponível em oracles. As políticas específicas de pedidos e sua implementação são discutidas posteriormente na Seção 5.3.Lançamento de transação: Após coletar e ordenar as transações dos usuários, recebidas diretamente dos usuários ou coletadas do mempool, o DON envia essas transações para a cadeia principal. Como tal, as interações de DON com a cadeia principal permanecem sujeito a ordens de transação (potencialmente injustas) regidas pelos mineradores da cadeia principal. Para aproveitar os benefícios da ordenação de transações descentralizadas, o alvo inteligente o contrato SC, portanto, deve ser projetado para tratar o DON como um cidadão de “primeira classe”. Nós distinguir duas abordagens: • Contratos somente DON: A opção de design mais simples é ter a cadeia principal inteligente o contrato SC aceita apenas transações que foram processadas pelo DON. Isto garante que smart contract processe transações na ordem proposta por o DON, mas de fato restringe o smart contract a operar em um sistema baseado em comitê (ou seja, o comitê DON agora tem poder contínuo para determinar o ordenação e inclusão de transações). • Contratos de classe dupla: um design preferencial e mais granular torna a cadeia principal inteligente contrato SC aceita transações originadas tanto de DON quanto de legado usuários,10 mas coloca “redutores de velocidade” tradicionais em transações que não foram processadas pelo DON. Por exemplo, as transações do DON podem ser processadas imediatamente, enquanto as transações legadas são “armazenadas em buffer” pelo smart contract para um período fixo de tempo. Outros mecanismos padrão para prevenir o front-running como esquemas de confirmação-revelação ou VDFs [53] também podem ser aplicados a legados transações. Isso garante que as transações solicitadas por DON sejam processadas em a ordem acordada, sem dar ao DON o poder indesejado de censurar transações. Como a imposição da ordenação de transações pelo FSS exige que as transações sejam agregadas “off-chain”, esta solução é naturalmente combinada com outras técnicas de agregação que visam reduzir os custos de processamento on-chain. Por exemplo, depois de coletar e ordenando transações, o DON pode enviar essas transações para a cadeia principal como um única “transação em lote” (por exemplo, um rollup), reduzindo assim a transação agregada taxa. Fazendo cumprir a ordem de transação: Seja em um design somente DON ou de classe dupla, a cadeia principal smart contract SC e DON devem ser co-projetadas para garantir que a ordem de transação de DON seja mantida. Aqui também, imaginamos diferentes opções de projeto: • Números de sequência: O DON pode anexar um número de sequência a cada transação e enviar essas transações para o mempool da cadeia principal. O principal 10Se o monitoramento de transações do DON for baseado no mempool, as transações legadas devem ser distinguíveis das transações DON para que não sejam coletadas pelo DON, por exemplo, por meio de uma tag especial incorporado na transação ou especificando um preço específico do gás, por ex. DON transações têm gás preços abaixo de um determinado limite.chain smart contract SC ignora transações que chegam “fora de sequência”. Nós observe que nesta configuração, os mineradores da cadeia principal podem decidir ignorar o DON ordenação de transações, fazendo com que as transações falhem. É possível, mantendo o estado (caro), que o SC imponha a ordem correta das transações, de certa forma de forma análoga a como o TCP armazena pacotes fora de ordem até que os pacotes perdidos sejam recebido. • Transação nonces: Para muitos blockchains, e em particular para Ethereum, o A abordagem de numeração de sequência acima pode aproveitar a transação integrada nonces para impor que o SC da cadeia principal smart contract processe as transações em sequência. Aqui, os nós DON enviam transações para a cadeia principal por meio de uma única conta da cadeia principal, protegida por uma chave compartilhada entre os nós DON. A conta a transação nonce garante que as transações sejam extraídas e processadas na ordem correta. • Transações agregadas: o DON pode agregar múltiplas transações em um rollup (ou em um pacote semelhante a rollup). A cadeia principal smart contract precisa ser projetado para lidar com essas transações agregadas. • Transações agregadas com um proxy da cadeia principal: aqui, o DON agrupa de forma semelhante as transações em uma “metatransação” para a cadeia principal, mas depende de um proxy personalizado smart contract para descompactar as transações e retransmiti-las para o contrato alvo SC. Esta técnica pode ser útil para compatibilidade herdada. As metatransações agem como rollups, mas diferem porque consistem em um arquivo não compactado lista de transações postadas uma vez na cadeia principal. O último design tem a vantagem de suportar perfeitamente as transações do usuário que eles próprios são procurados por meio de um contrato de cadeia principal antes de atingir a meta de DON contrato SC. Por exemplo, considere um usuário que envia uma transação para alguma carteira contrato, que por sua vez envia uma transação interna para SC. Atribuindo uma sequência número para tal transação seria complicado, a menos que o contrato da carteira do usuário seja especialmente projetado para encaminhar o número de sequência com cada transação interna para SC. Da mesma forma, tais transações internas não podem ser facilmente agregadas em uma metatransação enviada diretamente ao SC. Discutimos outras considerações de design para tais transações por procuração abaixo. 5.2.2 Atomicidade da transação Nossa discussão até agora assumiu implicitamente que as transações interagem com um único on-chain smart contract (por exemplo, um usuário envia uma solicitação de compra para uma exchange). Ainda assim, em sistemas como Ethereum, uma única transação pode consistir em múltiplas transações internas, por exemplo, uma smart contract chamando uma função em outro contrato. Abaixo, nós descrevem duas estratégias de alto nível para sequenciar transações “multicontratos”, enquanto preservando a atomicidade da transação (ou seja, a sequência de ações prescritas por as transações são todas executadas na ordem correta ou não são executadas).Atomicidade forte: A solução mais simples é aplicar o FSS, conforme descrito acima, diretamente a transações inteiras de “multicontratos”. Ou seja, os usuários enviam suas transações na rede e o FSS monitora, sequencia e publica essas transações no cadeia principal. Esta abordagem é tecnicamente simples, mas tem uma limitação potencial: se um usuário transação interage com dois contratos SC1 e SC2 que desejam alavancar serviços de sequenciação, então a política de sequenciação destes dois contratos tem de ser consistente. Isto é, dadas duas transações diferentes tx1 e tx2 com as quais cada uma interage tanto SC1 quanto SC2, não deve ser o caso de a política de SC1 ordenar tx1 antes de tx2 enquanto a política do SC2 prescreve a ordem oposta. Para a grande maioria dos cenários de interesse, prevemos que as políticas de sequenciamento adotadas por diferentes contratos serão consistentes. Por exemplo, SC1 e SC2 pode querer que as transações sejam ordenadas pela hora aproximada de chegada no mempool, e SC1 pode ainda querer que certos relatórios oracle sejam sempre entregues primeiro. Como o últimas oracle transações de relatório não interagem com SC2, as políticas são consistentes. Atomicidade fraca: Na sua total generalidade, o FSS poderia ser aplicado ao nível de indivíduos transações internas. Considere transações da forma tx = { ˜txpre, ˜txSC, ˜txpost}, consistindo em algumas transações iniciais transação(ões) ˜txpre, que resulta em uma transação interna ˜txSC para SC, que por sua vez emite transação(ões) interna(s) ˜txpost. A política de sequenciamento do SC pode determinar como a transação interna ˜txSC deve ser ordenada em relação a outras transações enviadas para SC, mas deixe em aberto a ordem de sequenciamento para ˜txpre e ˜txpost. Dadas as características intrínsecas do processamento de transações em sistemas como Ethereum, desenvolver um serviço de sequenciamento que vise transações internas específicas não é simples. Com um SC de contrato especialmente concebido, isto pode ser realizado da seguinte forma: 1. A transação tx é enviada para a rede e extraída (sem qualquer sequenciamento realizado pelo FSS). O ˜txpre inicial é executado e chama ˜txSC. 2. SC não executa ˜txSC e retorna. 3. O FSS monitora as transações internas do SC, sequencia-as e publica-as de volta para SC (ou seja, enviando transações ˜txSC diretamente para SC). 4. O SC processa as transações ˜txSC recebidas do FSS e emite as transações internas ˜txpost resultantes de ˜txSC. Com esta abordagem, as transações não são executadas totalmente atomicamente (ou seja, o original transação tx é dividida em várias transações na cadeia), mas a ordem de as transações internas são preservadas. Esta solução implica uma série de restrições de design. Por exemplo, ˜txpre não pode suponha que ˜txSC e ˜txpost serão executados. Além disso, o SC deve ser concebido de modo a executar transações ˜txSC e ˜txpost em nome de um determinado usuário, mesmo que tenham sidoenviado pelo FSS. Por estas razões, a solução de “Atomicidade Forte” de granulação mais grossa acima é provavelmente preferível na prática. Por respeitar dependências mais complexas, envolvendo múltiplas transações e suas respectivas transações internas, o escalonador de transações do FSS poderá conter funções elaboradas que se assemelham àquelas encontradas em gerenciadores de transações de relacionamentos gerenciadores de banco de dados. 5.3 Sequenciamento justo de transações Aqui discutimos duas noções de justiça para o sequenciamento de transações e as implementações correspondentes, que podem ser realizadas pelo FSS: justiça de ordem baseada em uma política imposto pelo FSS e preservação segura da causalidade, o que requer métodos criptográficos adicionais no FSS. Justiça da ordem: A justiça da ordem é uma noção de justiça temporal em protocolos de consenso que foi introduzido formalmente pela primeira vez por Kelkar et al. [144]. Kelkar et al. visam alcançar uma forma de política natural em que as transações sejam ordenados com base na hora em que foram recebidos pela primeira vez pelo DON (ou pela rede P2P, no caso de um FSS baseado em mempool). Num sistema descentralizado, no entanto, diferentes os nós podem ver as transações chegarem em uma ordem diferente. Estabelecendo uma ordem total em todas as transações é o próprio problema resolvido pelo protocolo de consenso subjacente MAINCHAIN. Kelkar et al. [144] introduz, portanto, uma noção mais fraca que pode ser alcançado com a ajuda de uma rede Oracle descentralizada, chamada “justiça de pedido em bloco”. Ele agrupa as transações que DON recebeu durante um intervalo de tempo em um “bloco” e insere todas as transações do bloco simultaneamente e na mesma posição (ou seja, altura) em MAINCHAIN. Eles são, portanto, ordenados juntos e devem ser executáveis paralelamente, sem criar conflitos entre eles. Grosso modo, orderfairness afirma que se uma grande fração de nós vê a transação τ1 antes de τ2, então τ1 será sequenciado antes ou no mesmo bloco que τ2. Ao impor uma atitude tão grosseira granularidade na ordem de transação, as oportunidades de ataques front-running e outros ataques relacionados a ordens são bastante reduzidas. Kelkar et al. propor uma família de protocolos chamada Aequitas [144], que aborda diferentes modelos de implantação, incluindo configurações de rede síncronas, parcialmente síncronas e assíncronas. Os protocolos Aequitas impõem uma sobrecarga de comunicação significativa em relação ao consenso BFT básico e, portanto, não são ideais para uso prático. Acreditamos, no entanto, que surgirão variantes práticas de Aequitas que poderão ser usadas para sequenciamento de transações no FSS e outras aplicações. Alguns esquemas relacionados já foram propostos que têm menos formalismo de acompanhamento e propriedades mais fracas, por exemplo, [36, 151, 236], mas melhor desempenho prático. Esses esquemas podem ser apoiados também no FSS. Também é importante notar que o termo “justiça” aparece em outras partes do blockchain literatura com um significado diferente, nomeadamente justiça no sentido de oportunidade paramineradores proporcionais aos seus recursos comprometidos [106, 181] ou para validators em termos de oportunidades iguais [153]. Preservação segura da causalidade: A abordagem mais conhecida para evitar frontrunning e outras violações de ordenação em plataformas distribuídas depende de criptografia. técnicas. Sua característica comum é ocultar os próprios dados da transação, aguardando até a ordem na camada de consenso foi estabelecida e para revelar os dados da transação posteriormente para processamento. Isso preserva a ordem causal entre as transações que são executado pelo blockchain. As noções de segurança relevantes e protocolos criptográficos foram desenvolvidos consideravelmente antes do advento de blockchains [71, 190]. As condições de segurança de “causalidade de entrada” [190] e “preservação segura da causalidade” [71, 97] exigem formalmente que nenhuma informação sobre uma transação se torne conhecida antes que a posição desta transação na ordem global tenha sido determinada. Um adversário não deve ser capaz de inferir qualquer informação até esse momento, de forma criptografada. sentido forte. Podem-se distinguir quatro técnicas criptográficas para preservar a causalidade: • Protocolos commit-reveal [29, 142, 145]: Em vez de uma transação ser anunciada claramente, apenas um compromisso criptográfico com a transação é transmitido. Depois que todas as transações confirmadas, mas ocultas, forem solicitadas (no início de blockchain sistemas no próprio MAINCHAIN, mas aqui pelo FSS), o remetente deve abrir o compromisso e revelar os dados da transação dentro de um intervalo de tempo pré-determinado. A rede então verifica se a abertura satisfaz o compromisso anterior. O as origens deste método datam de antes do advento de blockchains. Embora seja particularmente simples, a abordagem apresenta desvantagens consideráveis ​​e não é fácil de utilizar por duas razões. Primeiro, como apenas o compromisso existe no nível do protocolo de pedido, a semântica da transação não pode ser validado durante o consenso. Uma viagem adicional de ida e volta ao cliente é necessário. Mais severamente, porém, pondera a possibilidade de que nenhuma abertura possa chegar, o que pode equivaler a um ataque de negação de serviço. Além disso, é difícil determinar se a abertura é válida de uma forma consistente e distribuída. maneira porque todos os participantes devem concordar se a abertura chegou em tempo. • Protocolos de confirmação-revelação com recuperação atrasada [145]: um desafio com o abordagem commit-reveal é que um cliente pode se comprometer com uma transação especulativamente e revelá-la mais tarde somente se as transações subsequentes a tornarem lucrativa. Um variante recente da abordagem de compromisso-revelação melhora a resiliência contra esta tipo de mau comportamento. Em particular, o protocolo TEX [145] aborda este problema usando uma abordagem inteligente em que as transações criptografadas incluem uma chave de descriptografia obtido calculando uma função de atraso verificável (VDF) [53, 221]. Se um cliente não conseguir descriptografar sua transação em tempo hábil, outras pessoas no sistema irão descriptografar em seu nome, resolvendo um quebra-cabeça criptográfico moderadamente difícil.• Criptografia de limite [71, 190]: Este método explora que o DON pode executar operações criptográficas de limite. Suponha que o FSS mantenha uma criptografia pública key pkO e os oracles compartilham a chave privada correspondente entre si. Os clientes então criptografam as transações sob pkO e as enviam para o FSS. Pedidos FSS transações no DON, então as descriptografa e finalmente as injeta em MAINCHAIN na ordem fixa. A criptografia, portanto, garante que o pedido seja não com base no conteúdo da transação, mas que os próprios dados estão disponíveis quando necessário. Este método foi originalmente proposto por Reiter e Birman [190] e posteriormente refinado por Cachin et al. [71], onde foi integrado com um consenso permitido protocolo. Trabalhos mais recentes exploraram o uso da criptografia de limite como mecanismo de nível de consenso para mensagens genéricas [33, 97] e para cálculos gerais com dados compartilhados [41]. Comparada aos protocolos de confirmação e revelação, a criptografia de limite evita ataques simples de negação de serviço (embora seja necessário cuidado, dado o custo computacional da descriptografia). Permite que o DON prossiga de forma autônoma, em sua própria velocidade e sem aguardando novas ações do cliente. As transações podem ser validadas imediatamente após terem sido descriptografadas. Além disso, os clientes criptografam todas as transações com um chave para DON e o padrão de comunicação permanece o mesmo que com outros transações. Gerenciando a chave de limite com segurança e com alteração de nós em O, no entanto, pode apresentar dificuldades adicionais. • Compartilhamento secreto confirmado [97]: em vez de criptografar os dados da transação em uma chave mantida por DON, o cliente também pode compartilhá-la secretamente para os nós em O. Usando um esquema de compartilhamento de segredos híbrido e computacionalmente seguro, a transação é criptografado primeiro usando uma cifra simétrica com uma chave aleatória. Apenas a chave simétrica correspondente é compartilhada e o texto cifrado é enviado para DON. O cliente deve enviar um compartilhamento de chave para cada nó em O usando uma mensagem criptografada separadamente. As etapas restantes do protocolo são as mesmas do limite criptografia, exceto que os dados da transação são descriptografados com o simétrico algoritmo após reconstruir a chave por transação a partir de seus compartilhamentos. Este método não requer configuração ou gerenciamento de um sistema criptográfico de chave pública associado ao DON. No entanto, os clientes devem estar cientes dos nós em O e comunicar num contexto seguro com cada um deles, o que coloca encargos adicionais para os clientes. Embora os métodos criptográficos ofereçam proteção completa contra informações vazando das transações enviadas para a rede, eles não ocultam metadados. Para por exemplo, um endereço IP ou um endereço Ethereum do remetente ainda pode ser usado por um adversário para realizar ataques frontais e outros. Vários recursos para melhorar a privacidade técnicas implantadas na camada de rede, por exemplo, [52, 95, 107], ou na camada de transação, por exemplo, [13, 65], seria necessário para atingir esse objetivo. O impacto de uma determinada peça de metadados, nomeadamente para qual contrato uma transação é enviada, podem ser (parcialmente) ocultadosatravés da multiplexação de muitos contratos no mesmo DON. Ocultação criptográfica de transações por si só também não impede a priorização de transações por DON nós em conluio com remetentes de transações. A causalidade segura garantida por protocolos criptográficos complementa as garantias de justiça da ordem para qualquer política, e pretendemos explorar uma combinação das duas métodos, onde isso for possível. Se um adversário não puder obter vantagem significativa observando metadados, os protocolos seguros de preservação de causalidade poderiam ser usados juntamente com uma abordagem de pedido ingênua também. Por exemplo, nós oracle podem gravar transações para L assim que os receberem, sem duplicação. As transações seriam então ordenados de acordo com sua aparência em L e posteriormente descriptografados. Também planejamos considerar o uso de TEEs como uma forma de ajudar a impor uma ordem justa; para Por exemplo, Tesseract [44] pode ser visto como alcançando uma forma de ordenação causal, mas um fortalecido pela capacidade do TEE de processar transações de forma explícita enquanto mantendo sua confidencialidade. 5.4 Considerações sobre a camada de rede Até agora, a nossa descrição do FSS centrou-se principalmente no problema de garantir que o a ordem finalizada das transações corresponde à ordem observada na rede. Doravante, consideramos questões de justiça que poderiam surgir na própria camada de rede. Os comerciantes de alta frequência em mercados eletrônicos convencionais investem consideráveis recursos para obter velocidade de rede superior [64], e os comerciantes em bolsas de criptomoedas exibem comportamento semelhante [90]. A velocidade da rede confere uma vantagem tanto em observar as transações de outras partes e na apresentação de transações concorrentes. Um remédio implantado na prática e popularizado no livro Flash Boys [155] é o “redutor de velocidade” introduzido inicialmente na bolsa IEX [128] e posteriormente em outras trocas [179] (com resultados mistos [19]). Este mecanismo impõe um atraso (350 microssegundos em IEX) no acesso ao mercado, com o objectivo de neutralizar vantagens no velocidade. Evidência empírica, por ex. [128], apoia sua eficácia na diminuição de certas negociações custos para investidores comuns. O FSS pode ser usado simplesmente para implementar um sistema assimétrico aumento de velocidade – aquele que atrasa as transações recebidas. Budish, Cramton e Shim [64] argumentam que a exploração das vantagens da velocidade é inevitável em mercados de tempo contínuo e defendem uma solução estrutural no forma de mercados baseados em leilões em lote. Mas esta abordagem não se consolidou amplamente em plataformas de negociação existentes. Os sistemas de negociação convencionais são centralizados, normalmente recebendo transações através de uma única conexão de rede. Num sistema descentralizado, pelo contrário, é possível observe a propagação da transação a partir de vários pontos de vista. Consequentemente, é possível observar comportamentos como inundação de rede em uma rede P2P. Nós pretendemos explorar abordagens de camada de rede para FSS que ajudem os desenvolvedores a especificar políticas proibindo tais comportamentos de rede indesejáveis.5.5 Políticas de justiça em nível de entidade A justiça da ordem e a causalidade segura visam impor uma ordem em transações que respeita o momento em que foram criados e submetidos pela primeira vez à rede. Uma limitação desta noção de justiça é que ela não impede ataques em que um adversário ganha vantagem ao inundar um sistema com muitas transações, uma estratégia observada em estado selvagem como uma forma de realizar sniping de transações eficaz em token vendas [159] e para criar congestionamento resultando na liquidação de posições de dívida colateralizada (CDPs) [48]. Em outras palavras, a justiça da ordem impõe justiça em relação às transações, não aos jogadores. Conforme mostrado no sistema CanDID [160], é possível usar ferramentas oracle como DECO ou Town Crier em conjunto com um comitê de nós (como um DON) para alcançar várias formas de resistência a Sybil, protegendo ao mesmo tempo a privacidade. Os usuários podem registrar identidades e fornecer evidências de sua singularidade sem revelar as próprias identidades. Credenciais resistentes a Sybil oferecem uma abordagem possível para enriquecer a ordem de transação políticas de uma forma que limitaria as oportunidades para ataques de inundação. Por exemplo, um A venda de token pode permitir apenas uma transação por usuário registrado, onde o registro exige uma prova da exclusividade de um identificador nacional, como um número de segurança social. Tal abordagem não é infalível, mas pode revelar-se uma política útil para mitigar ataques de inundação de transações.

A estrutura de execução de transações DON

(DON-TEF) DONs fornecerão oracle e suporte de recursos descentralizados para soluções de camada 2 dentro o que chamamos de Estrutura Descentralizada de Execução de Transações da Oracle Network (DONTEF) ou TEF, para abreviar. Hoje, a frequência de atualizações dos contratos DeFi é limitada pelas latências da cadeia principal, por exemplo, o intervalo médio de bloqueio de 10 a 15 segundos em Ethereum [104] - bem como o custo de enviar grandes quantidades de dados em cadeia e taxa de transferência computacional/tx limitada - motivando abordagens de escalonamento, como fragmentação [148, 158, 232] e execução da camada 2 [5, 12, 121, 141, 169, 186, 187]. Mesmo blockchains com tempos de transação muito mais rápidos, por exemplo, [120], propuseram estratégias de escalonamento que envolvem computação fora da cadeia [168]. O TEF destina-se a atuar como um recurso de camada 2 para qualquer sistema de camada 1/MAINCHAIN. Usando TEF, DONs podem suportar atualizações mais rápidas em um contrato MAINCHAIN enquanto mantendo as principais garantias de confiança fornecidas pela cadeia principal. TEF pode apoiar qualquer uma de uma série de técnicas e paradigmas de execução da camada 2, incluindo rollups,11 rollups otimistas, Validium, etc., bem como um modelo de confiança de limite no qual DON nós executam transações. O TEF é complementar ao FSS e destina-se a apoiá-lo. Em outras palavras, qualquer aplicação em execução no TEF pode usar FSS. 11Frequentemente chamados de “zk-rollups”, um nome impróprio, pois não precisam necessariamente de provas de conhecimento zero.

6.1 Visão geral do TEF O TEF é um padrão de projeto para a construção e execução de um híbrido de alto desempenho smart contractSC. De acordo com a ideia principal por trás dos smart contracts híbridos, o TEF envolve um decomposição de SC em duas partes: (1) O que chamamos no contexto TEF de âncora contrato SCa em MAINCHAIN e (2) lógica DON executada que chamamos de executável TEF. Usamos SC aqui para denotar o contrato lógico implementado pela combinação de SCa e executar. (Como observado acima, esperamos desenvolver ferramentas de compilação para decompor um contrate SC automaticamente nesses componentes.) O executável TEF exec é o mecanismo que processa as transações dos usuários no SC. Isso pode ser executado com bom desempenho, pois é executado no DON. Possui diversas funções: • Ingestão de transações: exec recebe ou busca as transações dos usuários. Isso pode acontecer diretamente, ou seja, através do envio da transação no DON, ou através do MAINCHAIN mempool usando MS. • Execução rápida de transações: o exec processa transações envolvendo ativos dentro SC. Isso é feito localmente, ou seja, no DON. • Acesso rápido e de baixo custo oracle / adaptador: exec tem acesso nativo a relatórios oracle e outros dados do adaptador que levam, por exemplo, a dados de ativos mais rápidos, mais baratos e mais precisos preços do que a execução MAINCHAIN. Além disso, o acesso oracle fora da cadeia reduz o custo operacional do oracle, daí o custo de utilização do sistema, evitando armazenamento caro na cadeia. • Sincronização: exec envia periodicamente atualizações de DON para MAINCHAIN, atualizando SCa. O contrato âncora é o front end MAINCHAIN ​​do SC. Como componente de maior confiança do SC, ele serve a vários propósitos: • Custódia de ativos: os fundos dos usuários são depositados, mantidos e retirados da SCa. • Verificação de sincronização: o SCa pode verificar a exatidão das atualizações de estado quando executado sincroniza, por exemplo, SNARKs anexados a rollups. • Guarda-corpos: SCa pode incluir disposições para proteção contra corrupção ou falhas na verdade. (Veja a Seção 7 para mais detalhes.) No TEF, os fundos dos usuários são custodiados na MAINCHAIN, o que significa que o próprio DON não tem custódia. Dependendo da escolha do mecanismo de sincronização (veja abaixo), os usuários podem precisar confiar em DON apenas para relatórios oracle precisos e sincronização oportuna com MAINCHAIN. O modelo de confiança resultante é muito semelhante àquele para DEXes baseados em carteira de pedidos, por exemplo, [2], que hoje geralmente incluem um componente fora da cadeia para correspondência de pedidos e um componente onchain para compensação e liquidação.Para usar o vocabulário dos sistemas de pagamento, pode-se pensar em exec como o componente do SC responsável pela compensação, enquanto o SCa trata da liquidação. Veja a Fig. 13 para um esquema representação do TEF. Figura 13: Esquema TEF. Neste exemplo, as transações passam pelo mempool de MAINCHAIN via MS para DON. Benefícios do TEF: O TEF traz três benefícios principais: • Alto desempenho: SC herda o rendimento muito maior do DON do que o MAINCHAIN para transações e relatórios oracle. Além disso, o exec pode processar transações mais rapidamente e responder aos relatórios oracle em tempo hábil do que uma implementação apenas no MAINCHAIN. • Taxas mais baixas: O processo de sincronização é menos urgente do que o processamento de transações, e as transações podem ser enviadas de DON para MAINCHAIN ​​em lotes. Consequentemente, as taxas por transação na cadeia (por exemplo, custos de gás) com esta abordagem são muito mais baixas do que para um contrato executado apenas em MAINCHAIN. • Confidencialidade: Os mecanismos de confidencialidade do DON podem ser trazidos para aguenta SC.

Limitações do TEF: Uma limitação do TEF é que ele não suporta saques, pois ocorrem apenas na MAINCHAIN: Ao enviar uma solicitação de saque para SCa, um usuário pode precisar esperar que exec execute uma atualização de estado que inclua o transação de retirada antes que ela possa ser aprovada. Discutimos algumas soluções parciais, no entanto, na Seção 6.2. Outra limitação do TEF é que ele não suporta composição atômica de DeFi contratos no MAINCHAIN, especificamente a capacidade de rotear ativos através de múltiplos DeFi contratos em uma única transação. O TEF pode, no entanto, apoiar tal atomicidade entre DeFi contratos em execução no mesmo DON. Também discutimos algumas maneiras de resolver isso problema na Seção 6.2. 6.2 Roteamento de transações As transações para SC podem ser enviadas pelos usuários diretamente para DON ou podem ser roteadas através o mempool em MAINCHAIN (via FSS). Existem quatro tipos de transação distintos, cada um dos quais requer tratamento diferente: Transações dentro do contrato: Por evitar as complicações da dinâmica dos gases, o TEF proporciona ao SC mais flexibilidade no tratamento das transações do que seria disponível em um contrato de camada 1. Por exemplo, enquanto uma transação mempool em Ethereum pode ser substituída por uma nova transação com um preço de gás mais alto, o SC pode tratar uma transação que opere em ativos dentro do SC como oficial assim que se tornar visível no pool de membros. Consequentemente, o SC não precisa esperar que uma transação seja confirmada dentro de um bloco, resultando em latência consideravelmente reduzida. Proxy: Um usuário pode desejar enviar uma transação τ para SC através de um contrato de carteira ou outro contrato em MAINCHAIN. É possível que o DON simule a execução de τ em MAINCHAIN para determinar se isso resulta em uma transação subsequente para SC. Nesse caso, τ pode ser sequenciado com outras transações para SC que o façam. Existem alguns possibilidades de como o DON identifica tais transações: (1) O DON pode simular todas as transações no mempool (uma abordagem cara); (2) Certos contratos ou tipos de contratos, por exemplo, carteiras, podem ser listados para monitoramento pelo DON; ou (3) os usuários podem anote transações para inspeção DON. As coisas ficam mais complicadas quando uma única transação interage com duas contratos, SC1 e SC2, ambos os quais usam serviços de sequenciamento justo e têm políticas de pedidos incompatíveis. O DON pode, por exemplo, sequenciar τ no último momento que é compatível com ambos. Depósitos: Uma transação que deposita um ativo MAINCHAIN em SC precisa ser confirmada em um bloco antes que SC possa tratá-la como válida. Quando detecta a mineração de um transação que envia ativos (por exemplo, Ether) para SCa, o executivo pode confirmar instantaneamente adepósito. Por exemplo, ele pode aplicar um preço atual relatado por oracle no DON ao ativo. Retiradas: Conforme observado acima, uma limitação do TEF é que os saques nem sempre podem ser executados instantaneamente. Em um modelo de execução do tipo rollup, a retirada a solicitação deve ser sequenciada com outras transações, ou seja, acumulada, para ser segura processado. Existem, no entanto, algumas soluções parciais para esta limitação. Se DON puder calcular rapidamente uma prova de validade de rollup até a transação de retirada, então observar a transação de um usuário τ no mempool exec pode enviar uma transação de atualização de estado τ ′ para τ a um preço de gás mais alto, uma espécie de front-running benéfico. Desde que τ não seja extraído antes de τ ′ atingir o mempool, τ ′ precederá τ e τ efetuará uma retirada aprovada. Em uma variante TEF onde o DON é utilizado para calcular atualizações de estado (consulte a variante de assinatura de limite abaixo), o DON pode alternativamente determinar fora da cadeia se τ deve ser aprovado dado o estado de SC no momento de sua execução. O DON pode então enviar uma transação τ ′ que aprova a retirada τ - sem efetuar uma transação completa atualização do estado. Se esta abordagem não for possível, ou nos casos em que não for bem-sucedida, um procedimento iniciado por DON a transação τ ′ pode enviar fundos ao usuário em resposta a τ para que o usuário não precise iniciar uma transação adicional. 6.3 Sincronizando O executável TEF exec envia periodicamente atualizações de DON para MAINCHAIN, atualizar o estado do SCa em um processo que chamamos de sincronização. A sincronização pode ser pensada como propagação de transações da camada 2 para a camada 1, então o TEF pode recorrer a qualquer número de técnicas existentes para este fim, incluindo rollups [5, 12, 16, 69], otimista rollups [10, 11, 141], Validium [201] ou assinatura de limite básico, por exemplo, limite BLS, Schnorr ou ECDSA [24, 54, 116, 202]. Em princípio, ambientes de execução confiáveis também pode atestar a correção das mudanças de estado, oferecendo um desempenho muito melhor alternativa a rollups, mas com um modelo de confiança dependente de hardware. (Veja, por exemplo, [80].) Abaixo comparamos essas opções de sincronização em relação a três propriedades principais em TEF: • Disponibilidade de dados: Onde é armazenado o estado de SC? Pelo menos três opções são disponível em TEF: no MAINCHAIN, em DON ou por algum armazenamento de terceiros provedores como IPFS. Eles alcançam diferentes garantias de segurança, disponibilidade níveis e perfis de desempenho. Resumidamente, armazenar o estado no MAINCHAIN permite auditabilidade na cadeia e elimina a dependência de qualquer parte para disponibilidade do estado; por outro lado, armazenar o estado off-chain pode reduzir o custo de armazenamento e melhorar taxa de transferência, ao custo de provedores de armazenamento confiáveis (DON ou terceiros) para disponibilidade de dados. É claro que modelos flexíveis que combinam estas opções também são possível. Indicamos a forma necessária de disponibilização dos dados na Tabela 1.• Garantias de correção: como a SCa verifica a exatidão das atualizações empurrado por exec? Isso afeta a carga computacional em exec e SCa e o latência de sincronização (veja abaixo). • Latência: a latência de sincronização tem três fatores contribuintes: (1) O tempo necessário para esperar gerar uma transação de sincronização τsync; (2) O tempo necessário para τsync a ser confirmado no MAINCHAIN; e (3) O tempo para τsync entrar em vigor SCa. No TEF, a latência é particularmente importante para retiradas (mas menos importante para transações dentro do contrato) porque as retiradas exigem necessariamente um (pelo menos parcial) sincronização de estado. Sincronizando opções Dados disponibilidade Correção garantias Latência Acúmulo [5, 12, 16, 69] Na rede Provas de validade Tempo necessário para gerar provas de validade (por exemplo, minutos nos sistemas atuais) Válido [201] Fora da cadeia Provas de validade Igual ao acima Otimista rollup [10, 11, 141] Na rede Provas de fraude Duração do desafio período (por exemplo, dias ou semanas) Assinatura de limite [24, 54, 116, 202] Flexível Limite de assinaturas por DON Instantâneo Ambientes de execução confiáveis [80] Flexível Baseado em hardware atestados Instantâneo Tabela 1: Várias opções de sincronização no TEF e suas propriedades. A Tabela 1 resume essas propriedades nas cinco principais opções de sincronização no TEF. (Nota que não pretendemos comparar essas tecnologias como escalonamento de camada 2 independente soluções. Para isso, recomendamos aos leitores, por exemplo, [121].) Agora discutimos cada opção de sincronização. Acumulações: Um rollup [69] é um protocolo no qual a transição de estado efetuada por um lote de transações é computado fora da cadeia. A mudança de estado é então propagada para MAINCHAIN. Para implementar rollups, a âncora smart contract SCa armazena uma representação compacta Rstate (por exemplo, uma raiz Merkle) do estado real. Para sincronizar, exec envia τsync = (T, R′ estado) para SCa onde T é o conjunto de transações processadas desde o últimosincronizar e R′ estado é a representação compacta do novo estado calculado aplicando transações em T para o estado anterior Rstate. Existem duas variantes populares que diferem na forma como o SCa verifica as atualizações de estado no τsync. Os primeiros, (zk-)rollups, anexam um argumento sucinto de correção, às vezes chamado uma prova de validade, para a transição Rstate →R′ estado. Para implementar esta variante, execute calcula e envia a prova de validade (por exemplo, uma prova zk-SNARK) junto com τsync, provando que R' state é o resultado da aplicação de T ao estado atual de SCa. A âncora contrato aceita a atualização do estado somente após ter verificado a comprovação. rollups otimistas não incluem argumentos de correção, mas têm staking e desafiar procedimentos que facilitam a verificação distribuída de transições de estado. Para isso Variante rollup, SCa aceita provisoriamente τsync assumindo que está correto (daí o otimismo) mas τsync não entra em vigor até depois de um período de desafio, durante o qual qualquer parte monitorar MAINCHAIN pode identificar atualizações de estado errôneas e informar a SCa para tomar ações necessárias (por exemplo, reverter o estado e infligir uma penalidade na execução). Ambas as variantes rollup alcançam disponibilidade de dados na cadeia, à medida que as transações são publicadas on-chain, a partir do qual o estado completo pode ser construído. A latência de zk-rollups é dominado pelo tempo necessário para gerar provas de validade, que normalmente está no ordem de minutos em sistemas existentes [16] e provavelmente verá melhorias ao longo do tempo. rollups otimistas, por outro lado, têm uma latência maior (por exemplo, dias ou semanas) porque o período de desafio precisa ser longo o suficiente para que as provas de fraude funcionem. O A implicação da confirmação lenta é sutil e às vezes específica do esquema, de modo que uma análise completa está fora do escopo. Por exemplo, certos regimes consideram o pagamento transações como “trustless final” [109] antes da atualização do estado ser confirmada, uma vez que um um usuário comum poderia verificar um rollup muito mais rapidamente do que o MAINCHAIN. Valídio: Validium é uma forma de (zk-)rollup que disponibiliza dados apenas fora da cadeia e não mantém todos os dados no MAINCHAIN. Especificamente, exec envia apenas o novo estado e a prova, mas não transações para SCa. Com sincronização estilo Validium, exceto e o DON que o executa são as únicas partes que armazenam o estado completo e que executam transações. Tal como acontece com zk-rollups, a latência de sincronização é dominada pela validade tempo de geração da prova. Ao contrário de zk-rollups, no entanto, a sincronização no estilo Validium reduz o custo de armazenamento e aumenta o rendimento. Assinatura de limite por DON: Supondo que um limite de nós DON seja honesto, um A opção de sincronização simples e rápida é fazer com que os nós DON assinem coletivamente o novo estado. Esta abordagem pode apoiar a disponibilidade de dados dentro e fora da cadeia. Observe que se os usuários confiam em DON para atualizações de oracle, eles não precisam confiar mais nele para aceitar atualizações de estado, pois já estão em um modelo de confiança de limite. Outro benefício a assinatura de limite é de baixa latência. Suporte para novos formatos de assinatura de transação como proposto em EIP-2938 [70] e conhecido como abstração de conta tornaria o limite assinatura consideravelmente mais fácil de implementar, pois eliminaria a necessidade de limites ECDSA, que envolve protocolos consideravelmente mais complexos (por exemplo, [116, 117, 118])do que alternativas como assinaturas de limite Schnorr [202] ou BLS [55]. Ambientes de execução confiáveis (TEEs): TEEs são ambientes de execução isolados (geralmente realizados por hardware) que visam fornecer fortes proteções de segurança para programas executados internamente. Alguns TEEs (por exemplo, Intel SGX [84]) podem produzir provas, conhecidos como atestados, que uma saída é calculada corretamente por um programa específico para uma determinada entrada12. Uma variante de sincronização TEF baseada em TEE pode ser implementada por substituindo provas em (zk-)rollups ou Validium por atestados TEE usando técnicas de [80]. Comparados às provas de conhecimento zero usadas em rollups e Validium, os TEEs são muito mais desempenho. Em comparação com a assinatura de limite, os TEEs eliminam a complexidade de gerar assinaturas ECDSA de limite, pois, em princípio, é necessário haver apenas um TEE envolvido. O uso de TEEs, entretanto, introduz suposições extras de confiança dependentes de hardware. Também é possível combinar TEEs com sinalização de limite para criar resiliência contra o comprometimento de uma fração das instâncias de TEE, embora esta medida de proteção reintroduz a complexidade de geração de assinaturas ECDSA de limite. Flexibilidade adicional: Essas opções de sincronização podem ser refinadas para fornecer mais flexibilidade das seguintes maneiras. • Acionamento flexível: a aplicação TEF pode determinar as condições sob as quais a sincronização é acionada. Por exemplo, a sincronização pode ser baseada em lote, por exemplo, ocorrer após a cada N transações, baseadas no tempo, por exemplo, a cada 10 blocos, ou baseadas em eventos, por exemplo, ocorrem sempre que os preços-alvo dos activos se movem significativamente. • Sincronização parcial: é possível e em alguns casos desejável (por exemplo, com rollups, a sincronização parcial pode reduzir a latência) para fornecer sincronização rápida de pequenos quantidades de estado, realizando sincronização completa talvez apenas periodicamente. Por exemplo, exec pode aprovar uma solicitação de saque atualizando o saldo de um usuário no SCa sem atualizar o estado MAINCHAIN. 6.4 Reorganizações Reorganizações de blockchain resultantes de instabilidade de rede ou mesmo de ataques de 51% pode representar uma ameaça à integridade de uma cadeia principal. Na prática, os adversários têm usado para que eles montem ataques de gastos duplos [34]. Embora tais ataques às principais cadeias sejam difíceis de montar, eles permanecem viáveis para algumas cadeias [88]. Por operar independentemente do MAINCHAIN, um DON oferece a interessante possibilidade de observar e fornecer algumas proteções contra reorganizações associadas a ataques. Por exemplo, um DON pode reportar a um contrato SC confiável em MAINCHAIN ​​a existência de uma bifurcação concorrente de algum comprimento limite τ. O DON pode adicionalmente 12Detalhes complementares podem ser encontrados no Apêndice B.2.1. Eles não são necessários para a compreensão.

fornecer prova – em uma configuração PoW ou PoS – da existência de tal bifurcação. O O contrato SC pode implementar ações defensivas adequadas, como suspender a execução de transações adicionais por um período de tempo (por exemplo, para permitir que as exchanges coloquem na lista negra os gastos duplos ativos). Observe que embora um adversário que realize um ataque de 51% possa tentar censurar relatórios de um DON, uma contramedida em SC é exigir relatórios periódicos do DON para processar transações (ou seja, uma pulsação) ou para exigir um novo relatório para validar uma transação de alto valor. Embora esses alertas de bifurcação sejam, em princípio, um serviço geral, o DON pode fornecer para uma série de finalidades, nosso plano é incorporá-las ao TEF.

Minimização de confiança

Sendo um sistema descentralizado com a participação de um conjunto heterogêneo de entidades, o A rede Chainlink fornece forte proteção contra falhas tanto na atividade (disponibilidade) quanto na segurança (integridade do relatório). A maioria dos sistemas descentralizados, no entanto, varia em o grau em que os seus componentes constituintes são eles próprios descentralizados. Isto é verdade mesmo para grandes sistemas, onde a descentralização limitada entre os mineradores [32] e intermediários [51] estão presentes há muito tempo. O objetivo de qualquer esforço de descentralização é a minimização da confiança: procuramos reduzir o efeitos adversos de corrupção ou falha sistêmica na rede Chainlink, mesmo que devido a um DON malicioso. Nosso princípio orientador é o Princípio do Menor Privilégio [197]. Os componentes e atores do sistema dentro do sistema devem ter privilégios estritamente definidos para permitir apenas a conclusão bem-sucedida das funções atribuídas. Aqui apresentamos vários mecanismos concretos para Chainlink adotar em seu impulso em direção a uma minimização cada vez maior da confiança. Nós caracterizamos esses mecanismos em termos dos loci, ou seja, componentes do sistema, nos quais estão enraizados, mostrados na Fig. abordar cada locus em uma respectiva subseção. 7.1 Autenticação de fonte de dados Os modelos operacionais atuais para oracles são limitados pelo fato de que poucas fontes de dados assinar digitalmente os dados que omitem, em grande parte porque o TLS não assina nativamente dados. O TLS faz uso de assinaturas digitais em seu protocolo de “handshake” (para estabelecer uma chave compartilhada entre um servidor e um cliente). Servidores habilitados para HTTPS, portanto, possuem certificados em chaves públicas que podem, em princípio, servir para assinar dados, mas geralmente não usam esses certificados para dar suporte à assinatura de dados. Consequentemente, a segurança de um DON, como nas redes oracle atuais, depende de nós oracle que retransmitem fielmente os dados de uma rede de dados fonte para um contrato. Um componente importante de longo prazo de nossa visão para a minimização da confiança em Chainlink envolve uma autenticação mais forte da fonte de dados por meio do suporte de ferramentas e padrões para assinatura de dados. A assinatura de dados pode ajudar a aplicar garantias de integridade de ponta a ponta. Em princípio, se um contrato aceita como entrada um dado D assinado diretamente por um fornecedor de dados

Figura 14: Locais de mecanismos de minimização de confiança discutidos nesta seção. 1⃝Dados fontes fornecem dados para 2⃝DON, que retransmite uma função dos dados para um dependente 3⃝smart contract. Além disso, a rede DON ou oracle inclui 4⃝nós gerenciamento smart contracts em MAINCHAIN para, por exemplo, nós de compensação, proteção trilhos e assim por diante. fonte, então a rede oracle não pode adulterar D. Vários encorajadores surgiram esforços para permitir essa assinatura de dados, incluindo o OpenID Connect, que foi projetado principalmente para autenticação de usuário [9], TLS-N, um projeto acadêmico que visa estender o TLS [191] reaproveitando certificados TLS e extensões de evidências TLS [63]. Embora o OpenID Connect tenha tido alguma adoção, no entanto, as TLS Evidence Extensions e o TLS-N ainda não foi adotado. Outra via potencial de autenticação de fonte de dados é usar os próprios editores Signed HTTP Exchanges (SXG) [230], que podem ser armazenados em cache em redes de distribuição de conteúdo como parte do protocolo Accelerated Mobile Pages (AMP) [225]. O navegador móvel Chrome exibe o conteúdo de SXGs armazenados em cache de AMP como se fossem veiculados por os próprios domínios de rede de seus editores em vez do domínio do servidor de cache. Este incentivo de marca, juntamente com a relativa facilidade de ativá-lo usando serviços como o Real URL [83] da CloudFlare e o amppackager [124] do Google, pode levar à adoção generalizada de SXGs em conteúdo de notícias em cache, o que permitiria uma solução simples e resistente a adulterações. maneira de Chainlink oracles serem acionados em eventos de interesse jornalístico relatados em SXGs válidos. Embora os SXGs armazenados em cache de AMP de editores de notícias não sejam úteis para aplicativos como relatórios sobre dados comerciais, eles podem ser uma fonte segura para informações personalizadas contratos relativos a eventos do mundo real, como condições climáticas extremas ou resultados eleitorais. Acreditamos que a implantação simples, ferramentas maduras e flexibilidade serão vitais para acelerando a assinatura da fonte de dados. Permitir que provedores de dados usem nós Chainlink como um front-end de API autenticado parece uma abordagem promissora. Pretendemos criar umopção para os nós funcionarem neste modo, com ou sem participação na rede como um oracle completo. Nos referimos a esse recurso como origem de dados autenticada (ADO). Ao usar nós Chainlink com ADO, as fontes de dados poderão se beneficiar da experiência e ferramentas desenvolvidas pela comunidade Chainlink para adicionar digital recursos de assinatura para seu conjunto existente de APIs fora da cadeia. Eles deveriam escolher correr seus nós como oracles, eles também podem abrir novos fluxos de receita em potencial sob o mesmo modelo dos provedores de dados existentes, por exemplo, Kraken [28], Kaiko [140], e outros, que executam nós Chainlink para vender dados de API em cadeia. 7.1.1 As limitações da origem de dados autenticados A assinatura digital por fontes de dados, embora possa ajudar a fortalecer a autenticação, não é suficiente por si só para atingir todas as metas naturais de segurança ou operacionais de um oracle rede. Para começar, um determinado dado D ainda deve ser transmitido de forma robusta e oportuna. caminho de uma fonte de dados para smart contract ou outro consumidor de dados. Ou seja, mesmo em um ambiente ideal em que todos os dados são assinados usando chaves pré-programadas em dependentes contratos, um DON ainda seria necessário para comunicar os dados de forma confiável das fontes aos contratos. Além disso, há vários casos em que contratos ou outros dados oracle os consumidores desejam acesso à saída autenticada de várias funções computadas dados de origem por dois motivos principais: • Confidencialidade: uma API de fonte de dados pode fornecer dados confidenciais ou proprietários que precisa ser redigido ou higienizado antes de se tornar publicamente visível na rede. Qualquer modificação nos dados assinados, entretanto, invalidava a assinatura. Coloque outro Dessa forma, o ADO ingênuo e a limpeza de dados são incompatíveis. Mostramos no Exemplo 3 como os dois podem ser reconciliados através de uma forma aprimorada de ADO. • Falhas nas fontes de dados: erros e falhas podem afetar as fontes de dados, e as assinaturas digitais não resolvem nenhum dos problemas. Desde o seu início [98], Chainlink tem já incluía um mecanismo para remediar tais falhas: redundância. Os relatórios emitidos pelas redes oracle normalmente representam os dados combinados de vários fontes. Discutiremos agora os esquemas que estamos explorando no ambiente ADO para aumentar a confidencialidade dos dados de origem e combinar dados de múltiplas fontes com segurança. 7.1.2 Confidencialidade As fontes de dados podem não antecipar e disponibilizar toda a gama de APIs desejada pelos usuários. Especificamente, os usuários podem desejar acessar dados pré-processados para ajudar a garantir confidencialidade. O exemplo a seguir ilustra o problema.Exemplo 3. Alice deseja obter uma credencial de identidade descentralizada (DID) informando que ela tem mais de 18 anos (e portanto pode, por exemplo, contrair um empréstimo). Para fazer então, ela precisa provar esse fato sobre sua idade para um emissor de credencial DID. Alice espera usar dados do Departamento de Veículos Motorizados (DMV) de seu estado site para o efeito. O Detran tem registro de sua data de nascimento e emitirá um atestado A assinado digitalmente no seguinte formato: A = {Nome: Alice, Data de nascimento: 16/02/1999}. Neste exemplo, o atestado A pode ser suficiente para Alice provar ao DID emissor da credencial que ela tem mais de 18 anos. Mas vaza desnecessariamente informações confidenciais: Alice's DoB exato. Idealmente, o que Alice gostaria do DMV seria uma assinatura em um declaração simples A′ de que “Alice tem mais de 18 anos”. Em outras palavras, ela quer que o saída de uma função G em sua data de nascimento X, onde (informalmente), A′ = G(X) = True se DataAtual −X ≥18 anos; caso contrário, G(X) = Falso. Para generalizar, Alice gostaria de poder solicitar da fonte de dados um documento assinado atestado A′ do formato: A′ = {Nome: Alice, Func:G(X), Resultado: Verdadeiro}, onde G(X) denota uma especificação de uma função G e sua(s) entrada(s) X. Imaginamos que um usuário deve ser capaz de fornecer um G(X) desejado como entrada com sua solicitação de um atestado correspondente A′. Observe que o atestado A′ da fonte de dados deve incluir a especificação G(X) para certifique-se de que A′ seja interpretado corretamente. No exemplo acima, G(X) define o significado do valor booleano em A′ e, portanto, True significa o assunto do atestado tem mais de 18 anos de idade. Referimo-nos a consultas flexíveis nas quais um usuário pode especificar G(X) como consultas funcionais. Para dar suporte a casos de uso como o do Exemplo 3, bem como aqueles que envolvem consultas diretamente dos contratos, pretendemos incluir suporte para consultas funcionais envolvendo funções simples G como parte do ADO. 7.1.3 Combinando dados de origem Para reduzir os custos na cadeia, os contratos são geralmente concebidos para consumir dados combinados de múltiplas fontes, conforme ilustrado no exemplo a seguir. Exemplo 4 (Medianização de dados de preços). Para fornecer um feed de preços, ou seja, o valor de um ativo (por exemplo, ETH) em relação a outro (por exemplo, USD), uma rede oracle geralmente obter preços atuais de diversas fontes, como bolsas. A rede oracle normalmente envia para um contrato dependente SC a mediana desses valores. Em um ambiente com assinatura de dados, uma rede oracle funcionando corretamente obtém de fontes de dados S = {S1, . . . , SnS} uma sequência de valores V = {v1, v2, . . . , vnS} de Fontes nS acompanhadas de assinaturas específicas da fonte Σ = {σ1, σ2, . . . , σnS}. Após verificando as assinaturas, transmite o preço v = median(V ) para SC.Infelizmente, não existe uma maneira simples de uma rede oracle transmitir a mediana valor v no Exemplo 4 para SC junto com uma prova sucinta σ∗ de que v foi calculado corretamente sobre entradas assinadas. Uma abordagem ingénua seria codificar em SC as chaves públicas de todas as fontes de dados nS. A rede oracle então retransmitiria (V, Σ) e permitiria que SC calculasse a mediana de V . Isso, no entanto, resultaria em uma prova σ de tamanho O(nS) - ou seja, σ∗não seria sucinto. Também incorreria em elevados custos de gás para SC, que precisaria verificar todas as assinaturas em Σ. O uso de SNARKs, por outro lado, permite uma prova sucinta de valores de origem autenticados combinados corretamente. Pode ser viável na prática, mas impõe custos bastante elevados custos computacionais no provador e custos de gás um tanto elevados na cadeia. Uso de O Pregoeiro também é uma possibilidade, mas exige o uso de TEEs, o que não atende a todos modelos de confiança dos usuários. Um conceito útil para enquadrar soluções para o problema geral de assinatura de dados combinados de fontes é uma ferramenta criptográfica conhecida como assinaturas funcionais [59, 132]. Resumidamente, as assinaturas funcionais permitem que um signatário delegue capacidade de assinatura, de modo que o delegado só pode assinar mensagens no intervalo de uma função F escolhida pelo signatário. Mostramos no Apêndice D como esta restrição funcional pode servir para limitar o intervalo dos valores do relatório emitidos por um DON em função dos valores assinados pelas fontes de dados. Também introduzimos uma nova primitiva, chamada assinatura funcional discretizada, que inclui um requisito relaxado de precisão, mas tem potencialmente um desempenho muito melhor do que abordagens como SNARKs. O problema de combinar fontes de dados de uma forma que inclua autenticação de origem dos resultados também se aplica a agregadores de dados, por exemplo, CoinCap, CoinMarketCap, CoinGecko, CryptoCompare, etc., que obtêm dados de uma multiplicidade de exchanges, que eles peso baseado em volumes, utilizando metodologias que em alguns casos tornam públicas e em outros casos são proprietários. Um agregador que deseja publicar um valor com a autenticação de origem enfrenta o mesmo desafio que uma coleção de nós agregando dados de origem. 7.1.4 Processando dados de origem smart contracts sofisticados provavelmente dependerão de estatísticas agregadas personalizadas fontes primárias de dados, como volatilidade no histórico recente de preços de muitos ativos, ou textos e fotografias de notícias sobre acontecimentos pertinentes. Como a computação e a largura de banda são relativamente baratas em um DON, essas estatísticas— mesmo modelos complexos de aprendizado de máquina com muitas entradas podem ser processados economicamente, desde que qualquer valor de saída destinado a um blockchain seja suficientemente conciso. Para trabalhos computacionalmente intensivos onde DON participantes podem ter diferentes opiniões sobre entradas complexas, rodadas extras de comunicação entre os participantes DON podem ser necessárias para estabelecer consenso sobre as entradas antes de calcular o resultado. Desde que o valor final seja totalmente determinado pelas entradas, uma vez estabelecido o consenso de entrada, cada participante pode simplesmente calcular o valor e transmiti-lo ao outro.participantes com sua assinatura parcial ou enviá-la para um agregador. 7.2 DON Minimização de confiança Imaginamos duas maneiras principais de minimizar a confiança depositada nos componentes do DON: clientes de failover e relatórios minoritários. 7.2.1 Clientes de failover Modelos adversários na literatura de criptografia e sistemas distribuídos normalmente considerar um adversário capaz de corromper (ou seja, comprometer) um subconjunto de nós; por exemplo, menos de um terço para muitos protocolos BFT. É comumente observado, no entanto, que se todos os nós executarem software idêntico, um adversário que identifique uma exploração fatal poderá em princípio, comprometem todos os nós mais ou menos simultaneamente. Esta configuração é frequentemente referida como monocultura de software [47]. Várias propostas para diversificar automaticamente software e configurações de software foram apresentadas para resolver o problema, por exemplo, [47, 113]. Conforme observado em [47], entretanto, a diversidade de software é uma questão complexa e requer consideração cuidadosa. A diversificação de software, por exemplo, pode resultar em pior segurança do que uma monocultura se for aumenta a superfície de ataque de um sistema e, portanto, seus possíveis vetores de ataque em excesso os benefícios de segurança que oferece. Acreditamos que o suporte para clientes robustos de failover, ou seja, clientes aos quais os nós pode mudar diante de um evento catastrófico – é uma forma especialmente atraente de diversificação de software. Os clientes de failover não aumentam o número de vetores potenciais de ataque, pois não são implantados como software principal. Eles oferecem benefícios claros, no entanto, como uma segunda linha de defesa. Pretendemos oferecer suporte a clientes de failover em DONs como um meio fundamental de reduzir sua dependência de segurança em um único cliente. Chainlink já possui um sistema robusto de clientes de failover. Nossa abordagem envolve a manutenção de versões de clientes anteriores e testadas em batalha. Hoje, por exemplo, nós Chainlink com relatórios fora da cadeia (OCR) como cliente principal incluem suporte para o sistema FluxMonitor anterior de Chainlink, se necessário. Tendo sido usado por alguns Ao mesmo tempo, o FluxMonitor recebeu auditorias de segurança e testes de campo. Ele fornece o mesmo funcionalidade como OCR, mas com um custo mais elevado – um custo incorrido apenas conforme a necessidade. 7.2.2 Relatórios Minoritários Dado um conjunto minoritário suficientemente grande de Ominoridade – uma fração de nós honestos que observam a prevaricação da maioria – pode ser útil para eles gerar uma minoria. relatório. Este é um relatório ou sinalizador paralelo, retransmitido para um SC de contrato dependente na cadeia por Ominoridade. SC pode fazer uso desta bandeira de acordo com sua política específica do contrato. Por exemplo, para um contrato em que a segurança é mais importante do que a vivacidade ou a capacidade de resposta, um relatório minoritário pode fazer com que o contrato solicite relatórios suplementares. de outro DON ou acione um disjuntor (veja a próxima seção).Os relatórios minoritários podem desempenhar um papel importante mesmo quando a maioria é honesta, porque qualquer esquema de agregação de relatórios, mesmo que utilize assinaturas funcionais, deve operar de forma limitada, para garantir resiliência contra oracle ou falha de dados. Em outras palavras, deve ser possível produzir um relatório válido com base nas informações de kS < nS oracles, para algum limite kS. Isso significa que um DON corrompido tem alguns latitude na manipulação de valores de relatório, selecionando seus valores kS preferidos entre os nS relatado em V pelo conjunto completo de oracles, mesmo que todas as fontes sejam honestas. Por exemplo, suponha que nS = 10 e kS = 7 em um sistema que utiliza uma função assinatura para autenticar o cálculo da mediana sobre V para o preço da ETH em dólares. Suponha que cinco fontes relatem um preço de \(500, while the other five report \)1000. Então, medianizando os 7 relatórios mais baixos, o DON pode gerar um valor válido v = $500, e medianizando o mais alto, pode gerar v = $ 1.000. Ao aprimorar o protocolo DON para que todos os nós estejam cientes de quais dados foram disponíveis e quais dados foram usados para construir um relatório, os nós poderiam detectar e sinalizar tendências estatisticamente significativas para favorecer um conjunto de relatórios em detrimento de outro e produzir como resultado, um relatório minoritário. 7.3 Guarda-corpos Nosso modelo de confiança para DONs trata MAINCHAIN como um sistema de maior segurança e maior privilégio sistema do que DONs. (Embora este modelo de confiança nem sempre seja verdadeiro, é mais fácil adaptar o mecanismo resultante a situações em que DON é a segurança mais alta plataforma do que vice-versa.) Uma estratégia natural de minimização da confiança envolve, portanto, a implementação de mecanismos de monitoramento e à prova de falhas em smart contracts - seja em um front-end MAINCHAIN para um DON ou diretamente em um contrato de dependente SC. Nos referimos a esses mecanismos como guarda-corpos e enumere alguns dos mais importantes aqui: • Disjuntores: o SC pode pausar ou interromper as atualizações de estado em função das características das próprias atualizações de estado (por exemplo, grande variação entre relatórios) ou com base em outras informações. Por exemplo, um disjuntor pode desarmar casos em que os relatórios oracle variam de forma implausível ao longo do tempo. Um disjuntor pode também ser tropeçado por um relatório minoritário. Assim, os disjuntores podem evitar DONs de fazer relatórios grosseiramente errados. Os disjuntores podem fornecer tempo para que intervenções adicionais sejam consideradas ou exercido. Uma dessas intervenções são as saídas de emergência. • Escotilhas de fuga: Em circunstâncias adversas, conforme identificado por um conjunto de custodiantes, detentores de token comunitários ou outros órgãos de curadores, um contrato pode invocar uma instalação de emergência às vezes chamada de escotilha de fuga [163]. Uma escotilha de fuga faz com que o SC seja desligado de alguma maneira e/ou termine pendente e possivelmente transações futuras. Por exemplo, pode devolver fundos custodiados aos usuários [17]),pode rescindir os termos do contrato [162] ou pode cancelar transações pendentes e/ou futuras [173]. As escotilhas de fuga podem ser implantadas em qualquer tipo de contrato, não apenas aquele que depende de um DON, mas eles são de interesse como um buffer potencial contra DON prevaricação. • Failover: Em sistemas onde o SC depende do DON para serviços essenciais, é possível que o SC forneça mecanismos de failover que garantam a continuação do serviço mesmo no caso de falha ou mau comportamento de DON. Por exemplo, no TEF (Secção 6), o contrato âncora SCa pode fornecer interfaces duplas onde tanto on-chain quanto interfaces de execução fora da cadeia são suportadas para certas operações críticas (por exemplo, retirada), ou para transações normais, com um atraso adequado para evitar a antecipação de transações DON. Nos casos em que as fontes de dados assinam dados, os usuários podem também fornecerá relatórios à SCa quando o DON não o fizer. Provas de fraude, conforme proposto para várias formas de rollup otimista (ver Seção 6.3), são semelhantes em sabor e complementares aos mecanismos que enumeramos acima. Eles também fornece uma forma de monitoramento e proteção na cadeia contra possíveis falhas em componentes do sistema fora da cadeia. 7.4 Governança com confiança minimizada Como todos os sistemas descentralizados, a rede Chainlink requer mecanismos de governança ajustar parâmetros ao longo do tempo, responder a emergências e orientar sua evolução. Alguns desses mecanismos residem atualmente no MAINCHAIN e podem continuar a existir. faça isso mesmo com a implantação de DONs. Um exemplo é o mecanismo de pagamento para provedores de nós oracle (nós DON). DON contratos front-end em MAINCHAIN conter mecanismos adicionais, como guarda-corpos, que podem estar sujeitos a alterações periódicas modificação. Prevemos duas classes de mecanismos de governança: evolutivos e emergenciais. Governança evolucionária: Muitas modificações no ecossistema Chainlink são de modo que sua implementação não seja uma questão urgente: Melhorias de desempenho, aprimoramentos de recursos, atualizações de segurança (não urgentes) e assim por diante. À medida que Chainlink avança progressivamente em direção a ainda mais participantes em sua governança, esperamos que muitos ou a maioria dessas mudanças deve ser ratificada pela comunidade de um DON específico afetado por aqueles mudanças. Entretanto, e talvez em última análise como mecanismo paralelo, acreditamos que uma noção de menor privilégio temporal pode ser um meio útil de implementar a governação evolutiva. Muito simplesmente, a ideia é que as mudanças sejam implementadas gradualmente, garantindo à comunidade uma oportunidade de responder a eles. Por exemplo, a migração para um novo O contrato MAINCHAIN pode ser restringido para que o novo contrato seja implantado pelo menos trinta dias antes da ativação.Governança de emergência: Vulnerabilidades exploráveis ou exploradas em MAINCHAIN contratos ou outras formas de vida ou falhas de segurança podem exigir intervenção imediata para garantir resultados catastróficos. Nossa intenção é apoiar um multisig mecanismo de intervenção no qual, para garantir contra má conduta por parte de qualquer organização, os signatários estarão dispersos pelas organizações. Garantindo disponibilidade consistente de assinantes e acesso oportuno às cadeias de comando apropriadas para autorização de emergência as mudanças exigirão claramente um planeamento operacional cuidadoso e uma revisão regular. Estes os desafios são semelhantes aos envolvidos no teste de outras respostas a incidentes de segurança cibernética capacidades [134], com uma necessidade semelhante de combater problemas comuns como o decréscimo de vigilância [223]. A governança de DONs difere daquela de muitos sistemas descentralizados em sua grau potencial de heterogeneidade. Cada DON pode ter fontes de dados, executáveis, requisitos de nível de serviço distintos, como tempo de atividade e usuários. A rede Chainlink mecanismos de governação devem ser suficientemente flexíveis para acomodar tais variações na metas e parâmetros operacionais. Estamos explorando ativamente ideias de design e planejamos publicar pesquisas sobre este tema no futuro. 7,5 Infraestrutura de chave pública Com a descentralização progressiva, surgirá a necessidade de uma identificação robusta dos participantes da rede, incluindo nós DON. Em particular, Chainlink requer um forte Infraestrutura de chave pública (PKI). Uma PKI é um sistema que vincula chaves a identidades. Para Por exemplo, uma PKI sustenta o sistema de conexões seguras (TLS) da Internet: quando você se conecta a um site via HTTPS (por exemplo, https://www.chainlinklabs.com) e um lock aparece no seu navegador, isso significa que a chave pública do proprietário do domínio foi foi vinculado a esse proprietário por uma autoridade - especificamente, por meio de uma assinatura digital em um chamado certificado. Um sistema hierárquico de autoridades de certificação (CAs), cujas autoridades raiz de nível superior estão conectadas a navegadores populares, ajuda a garantir que os certificados são emitidos apenas para os legítimos proprietários de domínios. Esperamos que Chainlink eventualmente faça uso de serviços de nomes descentralizados, inicialmente o Ethereum Name Service (ENS) [22], como base para nossa PKI. Como seu nome sugere, ENS é análogo ao DNS, o Sistema de Nomes de Domínio que mapeia nomes de domínio (legíveis por humanos) para endereços IP na Internet. O ENS, no entanto, mapeia nomes Ethereum legíveis por humanos para endereços blockchain. Porque ENS opera no Ethereum blockchain, impedindo o comprometimento da chave, adulterando seu namespace é, em princípio, tão difícil quanto adulterar o contrato que o administra e/ou o blockchain subjacente. (O DNS, por outro lado, tem sido historicamente vulnerável para falsificação, sequestro e outros ataques.) Registramos data.eth com ENS na rede principal Ethereum e pretendemos estabelecê-lo como um namespace raiz sob o qual as identidades dos serviços de dados oracle e outras entidades de rede Chainlink residem. Os domínios no ENS são hierárquicos, o que significa que cada domínio pode conter referências para outros nomes sob ele. Os subdomínios no ENS podem servir como uma forma de organizar edelegar confiança. A principal função do data.eth será servir como um serviço de diretório on-chain para feeds de dados. Tradicionalmente, os desenvolvedores e usuários de oracles têm usado fontes fora da cadeia (por exemplo, sites como docs.chain.link ou data.chain.link, ou redes sociais como Twitter) para publicar e obter endereços de feed de dados oracle (como o preço ETH-USD alimentação). Com um namespace raiz altamente confiável como data.eth, é possível estabelecer um mapeamento de eth-usd.data.eth para, por exemplo, o endereço smart contract de um agregador de rede oracle on-chain para o feed de preços ETH-USD. Isso seria criar um caminho seguro para qualquer pessoa se referir ao blockchain como a fonte da verdade para aquele feed de dados desse par preço/nome (ETH-USD). Consequentemente, tal uso de ENS percebe dois benefícios não disponíveis em fontes de dados fora da cadeia: • Segurança forte: todas as alterações e atualizações no domínio são registradas de forma imutável e protegidos criptograficamente, em oposição aos endereços de texto em um site, que não desfrute de nenhuma dessas duas propriedades de segurança. • Propagação automatizada na cadeia: atualizações no endereço subjacente de um feed de dados smart contract podem acionar notificações que se propagam para dispositivos inteligentes dependentes. contratos e pode, por exemplo, atualizar automaticamente contratos dependentes com os novos endereços.13 Namespaces como ENS, no entanto, não validam automaticamente a propriedade legítima de nomes afirmados. Assim, por exemplo, se o namespace incluir a entrada ⟨“Acme Oracle Node Co.”, endereço⟩, então, um usuário obtém a garantia de que addr pertence ao requerente do nome Acme Oracle Node Co. Sem mecanismos adicionais para administração de namespace, no entanto, ela não obtém garantia de que o nome pertence a uma entidade legitimamente chamado Acme Oracle Node Co. em um sentido significativo do mundo real. Nossa abordagem para validação de nomes, ou seja, garantir sua propriedade por entidades correspondentes e legítimas do mundo real, depende de vários componentes. Hoje, Chainlink Laboratórios atua efetivamente como uma CA para a rede Chainlink. Enquanto os laboratórios Chainlink continuarão para validar nomes, nossa PKI evoluirá para um modelo mais descentralizado de duas maneiras: • Modelo de rede de confiança: A contrapartida descentralizada de uma PKI hierárquica é muitas vezes referida como uma rede de confiança.14 Variantes têm sido propostas desde a década de 1990, por exemplo, [98], e vários pesquisadores observaram que blockchains podem facilitar o uso da ideia, por exemplo, [227] registrando certificados de uma forma globalmente consistente. livro razão. Estamos explorando variantes deste modelo para validar as identidades das entidades na rede Chainlink de forma mais descentralizada. 13Um contrato dependente pode incluir opcionalmente um atraso predeterminado para permitir inspeção manual e intervenção de administradores de contratos dependentes. 14Um termo cunhado por Phil Zimmermann para PGP [238].• Vinculação com dados de validação: hoje, uma quantidade substancial de dados de desempenho de nós oracle é visível na cadeia e, portanto, vinculada de forma arquivística aos endereços de nós. Esses dados podem ser vistos como enriquecedores de uma identidade na PKI, fornecendo provas históricas da sua participação (confiável) na rede. Além disso, ferramentas para identidade descentralizada baseada em DECO e Town Crier [160] habilitar nós para acumular credenciais derivadas de dados do mundo real. Como apenas um exemplo, um o operador do nó pode anexar uma credencial à sua identidade PKI que comprove a posse de uma classificação Dun e Bradstreet. Estas formas complementares de validação podem suplemento staking na criação de garantia de segurança da rede. Um nó oracle com uma identidade estabelecida no mundo real pode ser visto como tendo participação em um sistema derivado de sua reputação. (Consulte a Seção 4.3 e a Seção 9.6.3.) Um requisito final para a PKI Chainlink é a inicialização segura, ou seja, publicando o nome raiz da rede Chainlink, atualmente data.eth (analogamente à conexão física de domínios de nível superior em navegadores). Em outras palavras, como os usuários Chainlink determine que data.eth é de fato o domínio de nível superior associado ao Chainlink projeto? A solução para este problema para a rede Chainlink é multifacetada e pode envolver: • Adicionar um registro TXT [224] ao nosso registro de domínio para chain.link que especifica data.eth como domínio raiz do ecossistema Chainlink. (Chainlink aproveita implicitamente a PKI para domínios da Internet para validar seu domínio ENS raiz.) • Link para data.eth do site existente de Chainlink, por exemplo, de https://docs.chain.link. (Outro uso implícito da PKI para domínios da Internet.) • Divulgar o uso do data.eth por meio de vários documentos, incluindo este whitepaper. • Publicar data.eth publicamente em nossos canais de mídia social, como o Twitter, e o blog Chainlink [18]. • Colocar uma grande quantidade de LINK sob o controle do mesmo endereço de registrante como dados.eth.

DON Considerações sobre implantação

Embora não faça parte do nosso design principal, existem várias considerações técnicas importantes na realização de DONs que merecem tratamento aqui.

8.1 Abordagem de implementação Este artigo apresenta uma visão ambiciosa da funcionalidade avançada Chainlink cujo a realização exigirá soluções para muitos desafios ao longo do caminho. Este artigo identifica alguns desafios, mas certamente surgirão desafios imprevistos. Planejamos implementar elementos desta visão de forma incremental ao longo de um período de tempo prolongado. Nossa expectativa é que DONs seja lançado inicialmente com suporte para componentes pré-construídos específicos construídos de forma colaborativa por equipes dentro do Chainlink comunidade. A intenção é que usos mais amplos de DONs, por exemplo, a capacidade de lançar executáveis arbitrários, terá suporte posteriormente. Uma razão para tal cautela é que a composição de smart contracts pode ter efeitos colaterais complexos, não intencionais e perigosos, como recentes ataques baseados em empréstimos flash por exemplo mostrado [127, 189]. Da mesma forma, a composição de smart contracts, adaptadores e executáveis exigirão extremo cuidado. Em nossa implantação inicial de DONs, planejamos incluir apenas um conjunto pré-construído de executáveis ​​e adaptadores modelados. Isto permitirá o estudo da segurança composicional dessas funcionalidades usando métodos formais [46, 170] e outras abordagens. Isso vai também simplificar o preço: o preço da funcionalidade pode ser estabelecido por nós DON com base na funcionalidade, em vez de por meio de medição generalizada, uma abordagem adotada em, por exemplo, [156]. Esperamos também que a comunidade Chainlink participe na criação de modelos adicionais, combinando vários adaptadores e executáveis em cada vez mais serviços descentralizados úteis que podem ser administrados por centenas, senão milhares de indivíduos DONs. Além disso, esta abordagem pode ajudar a evitar o inchaço do estado, ou seja, a necessidade de DON nós para reter uma quantidade impraticável de estado na memória de trabalho. Este problema é já surgindo em blockchains sem permissão, motivando abordagens como “stateless clientes” (ver, por exemplo, [206]). Pode ser mais agudo em sistemas de maior rendimento, motivando uma abordagem na qual um DON implanta apenas executáveis otimizados para tamanho de estado. À medida que os DONs evoluem e amadurecem e incluem barreiras de proteção robustas, conforme discutido na Seção 7, mecanismos de segurança criptoeconômicos e baseados em reputação, conforme discutido na Seção 9, e outros recursos que fornecem um alto grau de garantia para usuários de DON, nós também esperamos desenvolver uma estrutura e ferramentas para facilitar o lançamento e uso mais amplo de DONs pela comunidade. Idealmente, essas ferramentas permitirão uma coleção de operadores de nós se unirem como uma rede oracle e lançarem seus próprios DONs em um ambiente sem permissão ou de autoatendimento, o que significa que podem fazê-lo unilateralmente. 8.2 Associação dinâmica DON O conjunto de nós executando um determinado DON pode mudar com o tempo. Existem duas abordagens ao gerenciamento de chaves para skL, dada a associação dinâmica em O. A primeira é atualizar as ações de skL mantidas pelos nós após mudanças na associação, enquanto mantém o pkL inalterado. Esta abordagem, explorada em [41, 161, 198], tem o mérito de não exigir que as partes confiantes atualizem o pkL.A técnica clássica de compartilhar novamente, introduzida em [122], fornece uma maneira simples e eficiente de realizar tais atualizações de compartilhamento. Permite que um segredo seja transferido entre um conjunto de nós O(1) e um segundo, possivelmente cruzando um O(2). Neste abordagem, cada nó O (1) eu executa um compartilhamento secreto (k(2), n(2)) de seu compartilhamento secreto entre nós em O(2) para n(2) = |O(2)| e limite desejado (possivelmente novo) k(2). Vários esquemas de compartilhamento de segredos verificáveis (VSS) [108] podem fornecer segurança contra um adversário que corrompe ativamente os nós, ou seja, introduz comportamento malicioso no protocolo. As técnicas em [161] visam fazer isso, reduzindo a complexidade da comunicação e fornecendo resiliência contra falhas em suposições de dureza criptográfica. Uma segunda abordagem é atualizar a chave do razão pkL. Isto tem a vantagem de avançar segurança: O comprometimento de antigos compartilhamentos de pkL (ou seja, antigos nós do comitê) não seria resultar no comprometimento da chave atual. As atualizações do pkL, no entanto, apresentam duas desvantagens: (1) Os dados criptografados sob pkL precisam ser criptografados novamente durante uma atualização de chave e (2) As principais atualizações precisam ser propagadas para terceiros confiáveis. Pretendemos explorar ambas as abordagens, bem como hibridizações das duas. 8.3 DON Responsabilidade Tal como acontece com as redes Chainlink oracle existentes, DONs incluirão mecanismos de responsabilização, ou seja, gravação, monitoramento e aplicação do comportamento correto do nó. DONs terão capacidade de dados muito mais substancial do que muitos blockchains sem permissão existentes, especialmente devido à sua capacidade de conexão com armazenamento descentralizado externo. Consequentemente, eles serão capazes de registrar detalhadamente o histórico de desempenho dos nós, permitindo mecanismos de responsabilização mais refinados. Por exemplo, computação fora da cadeia de os preços dos ativos podem envolver insumos que são descartados antes que um resultado mediano seja enviado cadeia. Em um DON, esses resultados intermediários poderiam ser registrados. O mau comportamento ou falhas de desempenho de nós individuais em um DON podem, portanto, ser remediados ou penalizados em o DON de uma forma refinada. Além disso, discutimos abordagens para construir grades de proteção na Seção 7.3 que abordam o impacto específico do contrato de falhas sistêmicas. Contudo, também é importante ter mecanismos à prova de falhas para os próprios DONs, ou seja, proteções contra falhas DON sistêmicas e potencialmente catastróficas, especificamente falhas de bifurcação/equivocação e acordo de nível de serviço (SLA), como explicamos agora. Bifurcação / equívoco: Dado um número suficiente de nós defeituosos, um DON pode bifurcar ou equívoco, produzindo dois blocos ou sequências de blocos distintos e inconsistentes em L. Entretanto, como um DON assina digitalmente o conteúdo de L, é possível aproveitar um cadeia principal MAINCHAIN para prevenir e/ou penalizar equívocos. O DON pode verificar periodicamente o estado de L em um contrato de auditoria no MAINCHAIN. Se o seu estado futuro se desviar de um estado de checkpoint, um usuário/auditor poderá apresentar prova deste mau comportamento ao contrato de auditoria. Tal prova pode ser usada para gerar um alerta ou penalizar os nós DON por meio de cortes no contrato. Esta última abordagem introduz um problema de design de incentivo semelhante ao de feeds oracle específicos e pode se basear nosso trabalho descrito na Seção 9.Aplicação de acordos de nível de serviço: Embora DONs não sejam necessariamente destinados a executados indefinidamente, é importante que eles cumpram os acordos de nível de serviço (SLAs) com seus usuários. A aplicação básica do SLA é possível em uma cadeia principal. Por exemplo, Os nós DON podem se comprometer a manter o DON até uma determinada data ou a fornecer aviso prévio de rescisão do serviço (por exemplo, aviso prévio de três meses). Um contrato em MAINCHAIN pode fornecer aplicação básica de SLA criptoeconômico. Por exemplo, o contrato SLA pode reduzir os fundos depositados em DON se os pontos de verificação forem não fornecido nos intervalos exigidos. Um usuário pode depositar fundos e desafiar o DON para provar que um ponto de verificação representa corretamente uma sequência de blocos válidos (de uma maneira análogo a, por ex. [141]). É claro que a produção de blocos não significa transação processamento, mas o contrato SLA também pode servir para fazer cumprir este último. Por exemplo, em a versão compatível com legado do FSS, na qual as transações são buscadas no mempool (consulte a Seção 5.2), as transações são eventualmente extraídas e colocadas na cadeia. Um usuário pode provar DON prevaricação fornecendo ao contrato SLA uma transação que foi extraído, mas não foi transmitido pelo DON para processamento pelo contrato alvo dentro do intervalo de tempo apropriado.15 Também é possível provar a existência e penalizar SLAs mais refinados. falhas, incluindo erros na computação usando executáveis (através, por exemplo, dos mecanismos para provar transações estaduais fora da cadeia corretas descritas na Seção 6.3) ou falha na execução executáveis baseados em iniciadores visíveis em um DON, falha na retransmissão de dados em DON para MAINCHAIN em tempo hábil e assim por diante.

Economia e Criptoeconomia

Para que a rede Chainlink alcance uma segurança forte dentro de um modelo de confiança descentralizado, é essencial que os nós exibam coletivamente um comportamento correto, o que significa que eles aderem na maioria das vezes exatamente para protocolos DON. Nesta seção, discutimos abordagens para ajudar a impor tal comportamento por meio de incentivos econômicos, também conhecidos como criptoeconômicos incentivos. Esses incentivos se enquadram em duas categorias: explícitos e implícitos, realizados respectivamente por meio de staking e oportunidade de taxa futura (FFO). Estacamento: O staking em Chainlink, como em outros sistemas blockchain, envolve participantes da rede, ou seja, nós oracle, depositando fundos bloqueados na forma de LINK tokens. Estes os fundos, que também chamamos de participação ou participação explícita, são um incentivo explícito. Eles estão sujeitos a confisco em caso de falha ou prevaricação do nó. No contexto blockchain, esse procedimento costuma ser chamado de corte. O piqueteamento por nós oracle em Chainlink, no entanto, difere fundamentalmente de staking por validators em blockchains sem permissão. Os validadores podem se comportar mal ao ordenar transações de forma equivocada ou adversária. O protocolo de consenso subjacente em um 15Como os usuários podem substituir transações no mempool, é necessário cuidado para garantir uma correspondência correta entre as transações extraídas e as enviadas por DON.blockchain sem permissão, entretanto, usa regras de validação de bloco rígidas e rápidas e primitivas criptográficas para evitar que validators gerem blocos inválidos. Em contraste, as proteções programáticas não podem impedir que uma rede oracle trapaceira gere relatórios inválidos. O motivo é uma diferença fundamental entre os dois tipos de sistema: a validação da transação em blockchains é uma propriedade de consistência interna, enquanto a correção dos relatórios oracle em um blockchain é uma propriedade de dados externos, ou seja, dados fora da cadeia. Projetamos um mecanismo staking preliminar para a rede Chainlink baseada em um protocolo interativo entre nós oracle que podem fazer uso de dados externos. Isto mecanismo cria incentivos financeiros para o comportamento correto usando recompensas explícitas e penalidades (corte). Como o mecanismo é econômico, ele foi projetado para evitar que os nós corrupção por um adversário que usa recursos financeiros para corromper nós por meio de suborno. (Tal adversário é muito geral e se estende, por exemplo, a nós que cooperam para extrair valor de seu mau comportamento coletivo.) O mecanismo Chainlink staking que projetamos tem alguns recursos poderosos e inovadores características.16 A principal característica é o impacto superlinear staking (especificamente, quadrático). Um adversário deve ter recursos consideravelmente superiores aos fundos depositados pelos nós em para subverter o mecanismo. Nosso mecanismo staking fornece adicionalmente proteção contra um adversário mais forte do que considerado anteriormente em sistemas semelhantes, ou seja, um adversário que pode criar subornos condicionados ao comportamento futuro dos nós. Além disso, discutimos como ferramentas Chainlink como DECO podem ajudar a fortalecer nosso staking mecanismo, facilitando a adjudicação correta no caso de comportamento defeituoso do nó. Oportunidade de taxa futura (FFO): blockchains sem permissão - tanto do PoW e variedade de PoS – hoje dependem criticamente do que chamamos de incentivos implícitos. Estes são incentivos económicos para o comportamento honesto que não derivam de recompensas explícitas, mas da própria participação na plataforma. Por exemplo, a comunidade mineira Bitcoin é incentivada a não montar um ataque de 51% pelo risco de minar a confiança em Bitcoin, deprimindo seu valor e, conseqüentemente, corroendo o valor de seu coletivo investimentos de capital em infraestrutura de mineração [150]. A rede Chainlink se beneficia de um incentivo implícito semelhante ao qual nos referimos como oportunidade de taxa futura (FFO). Nós Oracle com fortes históricos de desempenho ou reputações atraem taxas dos usuários. O mau comportamento de um nó oracle compromete o futuro pagamentos de taxas e, portanto, penaliza o nó com um custo de oportunidade em termos de potencial receitas obtidas através da participação na rede. Por analogia com a aposta explícita, O FFO pode ser visto como uma forma de participação implícita, um incentivo para um comportamento honesto que deriva do benefício compartilhado de manter a confiança na plataforma na qual o negócio dos operadores de nós depende, ou seja, do desempenho positivo e da reputação do rede. Este incentivo é inerente, mas não explicitamente expresso, na rede Chainlink protocolos. Em Bitcoin, manutenção do valor das operações de mineração conforme mencionado acima 16O mecanismo staking que descrevemos aqui atualmente visa apenas forçar a entrega de relatórios corretos por redes oracle. Esperamos em trabalhos futuros estendê-lo para garantir a execução correta dos muitos outras funcionalidades DONs fornecerão.pode igualmente ser visto como uma forma de aposta implícita. Ressaltamos que o FFO já existe em Chainlink e ajuda a proteger a rede hoje. Nossa principal contribuição no desenvolvimento futuro de Chainlink será uma abordagem baseada em princípios e empiricamente orientada para avaliar incentivos implícitos, como o FFO, por meio de o que chamamos de Quadro de Incentivos Implícitos (IIF). Para estimar quantidades como o oportunidade futura de taxas dos nós, o IIF aproveitará continuamente o abrangente dados de desempenho e pagamento acumulados pela rede Chainlink. Tais estimativas permitirá a parametrização baseada em IIF de sistemas staking que reflete os incentivos dos nós com maior precisão do que os modelos heurísticos e/ou estáticos atuais. Para resumir, então, os dois principais incentivos econômicos para o nó oracle correto o comportamento na rede Chainlink em desenvolvimento será: • Staking (participação depositada) ó Incentivo explícito • Oportunidade de taxas futuras (FFO) ó Incentivo implícito Essas duas formas de incentivo são complementares. Os nós Oracle podem simultaneamente participe do protocolo Chainlink staking, desfrute de um fluxo de receita contínuo de usuários e se beneficiar coletivamente de seu bom comportamento contínuo. Assim, ambos os incentivos contribuir para a segurança criptoeconômica fornecida por uma rede oracle. Além disso, os dois incentivos podem reforçar-se e/ou ser negociados entre si. Por exemplo, um novo operador oracle sem histórico de desempenho e fluxo de receita pode apostar um grande quantidade de LINK como garantia de comportamento honesto, atraindo assim usuários e taxas. Por outro lado, um operador oracle estabelecido com um tempo longo e relativamente livre de falhas histórico de desempenho pode cobrar taxas substanciais de uma grande base de usuários e, portanto, depender mais fortemente no seu FFO como forma de incentivo implícito. Em geral, a abordagem que consideramos aqui visa uma determinada quantidade de oracle-rede recurso para criar os maiores incentivos econômicos possíveis em Chainlink para racional agentes – isto é, nós que maximizam sua utilidade financeira – se comportem honestamente. Coloque outro Dessa forma, o objetivo é maximizar os recursos financeiros necessários para um adversário atacar a rede com sucesso. Ao formular um protocolo staking com matematicamente bem segurança econômica definida e também usando o IFI, pretendemos medir a força de Os incentivos de Chainlink com a maior precisão possível. Os criadores de contratos confiáveis irão então ser capaz de determinar com forte confiança se uma rede oracle atende seus níveis exigidos de segurança criptoeconômica. O ciclo virtuoso da segurança económica: Os incentivos que discutimos nesta seção, staking e FFO, têm um impacto além do reforço da segurança de DONs. Eles prometem induzir o que chamamos de ciclo virtuoso de segurança económica. O impacto superlinear staking (e outras economias de escala) resulta em menor custo à medida que a segurança de um DON aumenta. O custo mais baixo atrai usuários adicionais para DON,aumentando o pagamento de taxas. Um aumento no pagamento de taxas continua a incentivar o crescimento do rede, que perpetua o ciclo virtuoso. Acreditamos que o ciclo virtuoso da segurança económica é apenas um exemplo de uma economia de escala e efeito de rede, entre outros que discutiremos mais adiante nesta seção. Organização da seção: O piqueteamento apresenta desafios técnicos e conceituais notáveis para que projetamos um mecanismo com recursos novos. O piqueteamento será, portanto, nosso foco principal nesta seção. Fornecemos uma visão geral da abordagem staking que apresentamos neste artigo na Seção 9.1, seguida por uma discussão detalhada nas Seções 9.2 a 9.5. Apresentamos o IFF na Seção 9.6. Apresentamos uma visão resumida dos incentivos da rede Chainlink na Seção 9.7. Na Secção 9.8, discutimos o ciclo virtuoso de segurança económica que a nossa abordagem staking proposta pode trazer para as redes oracle. Finalmente, descrevemos brevemente outros potenciais efeitos que impulsionam o crescimento da rede Chainlink na Seção 9.9. 9.1 Visão geral do piqueteamento O design do mecanismo staking que apresentamos aqui, conforme observado acima, envolve um protocolo interativo entre nós oracle permitindo a resolução de inconsistências no reporte de dados externos. O piqueteamento visa garantir um comportamento honesto de nós oracle racionais. Podemos, portanto, modelar um adversário atacando um protocolo staking como um subornador: A estratégia do adversário é corromper nós oracle usando incentivos financeiros. O adversário pode obter recursos financeiros prospectivamente através da manipulação bem-sucedida com um relatório oracle, por exemplo, oferta para compartilhar o lucro resultante com nós corrompidos. Em nosso projeto de mecanismo staking visamos simultaneamente dois objetivos ambiciosos: 1. Resistir a um adversário poderoso: O mecanismo staking foi projetado para proteger oracle redes contra uma ampla classe de adversários que são capazes de ações complexas, estratégias de suborno condicional, incluindo suborno prospectivo, que oferece subornos para oracles cujas identidades são determinadas após o fato (por exemplo, oferece subornos a oracles selecionados aleatoriamente para alerta de alta prioridade). Enquanto outros designs oracle consideraram um conjunto restrito de ataques sem todas as capacidades de um cenário realista adversário, até onde sabemos, o mecanismo adversário que introduzimos aqui é o primeiro a abordar explicitamente um amplo conjunto de estratégias de suborno e mostrar resistência neste modelo. Nosso modelo assume que os nós além do invasor estão economicamente racional (em oposição a honesto), e assumimos a existência de um fonte de verdade que é proibitivamente cara para uso típico, mas está disponível em caso de desacordo (discutido mais abaixo). 2. Alcançando impacto superlinear staking: Nosso objetivo é garantir que uma rede oracle composta por agentes racionais reporte sinceramente, mesmo na presença de um invasor com um orçamento superlinearna participação total depositada por toda a rede. Em sistemas staking existentes, se cada um dos n nós aposta $d, um invasor pode emitir um suborno confiável que solicita que os nós se comportem desonestamente em troca de um pagamento de um pouco mais do que \(d to each node, using a total budget of about \)dn. Isto já é um padrão alto, pois o invasor precisa ter um orçamento líquido da ordem dos depósitos combinados de todos os participantes da rede. O nosso objectivo é um grau ainda mais forte de segurança económica do que este obstáculo já substancial. Nosso objetivo é projetar o primeiro sistema staking que pode alcançar segurança para um invasor geral com um orçamento superlinear em n. Embora as considerações práticas possam ter um impacto menor, como discutiremos abaixo, nosso projeto preliminar atinge um requisito orçamentário adversário maior do que $dn2/2, ou seja, escalando quadrático em n, tornando o suborno amplamente impraticável, mesmo quando os nós apostam apenas quantias moderadas. Alcançar estes dois objectivos requer uma combinação inovadora de concepção de incentivos e criptografia. Ideias principais: Nossa abordagem staking depende de uma ideia que chamamos de prioridade de vigilância. Um relatório gerado por uma rede Chainlink oracle e enviado para um contrato confiável (por exemplo, no preço de um ativo) é agregado a partir de relatórios individuais contribuídos pelos nós participantes (por exemplo, tomando a mediana). Normalmente, um acordo de nível de serviço (SLA) especifica limites aceitáveis de desvio para relatórios, ou seja, até que ponto o relatório de um nó pode desviar-se do relatório agregado e até que ponto o agregado deve ser autorizado a desviar do valor verdadeiro para ser considerado correto. Em nosso sistema staking, para uma determinada rodada de relatórios, cada nó oracle pode atuar como um watchdog para emitir um alerta se acreditar que o relatório agregado está incorreto. Em cada rodada de relatórios, cada nó oracle recebe uma prioridade pública que determina o ordem em que seu alerta (se houver) será processado. Nosso mecanismo visa recompensar concentração, o que significa que o cão de guarda de maior prioridade para emitir um alerta ganha o recompensa total obtida pelo confisco dos depósitos de nós defeituosos. Nossos projetos de sistema staking envolvem dois níveis: o primeiro, nível padrão, e o segundo, nível de proteção. A primeira camada é a própria rede oracle, um conjunto de n nós. (Para simplificar, assumimos que n é ímpar.) Se a maioria dos nós relatar valores incorretos, um watchdog no O primeiro nível é fortemente incentivado a emitir um alerta. Se um alerta for gerado, o relatório A decisão da rede é então escalada para um segundo nível – um sistema de alto custo e máxima confiabilidade que pode ser especificado pelo usuário no acordo de nível de serviço da rede. Este poderia ser um sistema que, por exemplo, é composto apenas por nós com forte pontuações de confiabilidade histórica, ou uma que tenha uma ordem de magnitude maior que oracles do que o primeiro nível. Além disso, conforme discutido na Seção 9.4.3, DECO ou Town Crier podem servir como ferramentas poderosas para ajudar a garantir uma adjudicação eficiente e conclusiva no segundo nível. Para simplificar, assumimos assim que este sistema de segundo nível chega a um relatório correto valor. Embora possa parecer atraente confiar apenas no segundo nível para gerar todos os relatórios, o benefício do nosso design é que ele atinge consistentemente as propriedades de segurança dosistema de segundo nível, pagando apenas o custo operacional, no caso típico, do sistema de primeiro nível. A prioridade do watchdog resulta em impacto superlinear staking da seguinte maneira: se o rede oracle de primeira camada gera um resultado incorreto e vários nós de vigilância alerta, o mecanismo de incentivo staking recompensa o cão de guarda de maior prioridade com mais de $dn/2 retirados dos depósitos da (maioria) nós com comportamento inadequado. O a recompensa total é, portanto, concentrada nas mãos deste único cão de guarda, que, portanto, determina o mínimo que um adversário deve prometer a um cão de guarda em potencial para incentivá-lo a não alertar. Como nosso mecanismo garante que todo oracle receba o chance de agir como cão de guarda se os cães de guarda de maior prioridade aceitarem seus subornos (e optou por não alertar), o adversário deve, portanto, oferecer um suborno de mais de $dn/2 para cada nó para evitar que qualquer alerta seja gerado. Como existem n nós, o o orçamento necessário do adversário para um suborno bem-sucedido equivale a mais de $dn2/2, o que é quadrático no número n de nós na rede. 9.2 Plano de fundo Nossa abordagem para staking baseia-se em pesquisas nas áreas de teoria dos jogos e mecanismos design (MD) (para referência de livro, consulte [177]). A teoria dos jogos é matematicamente estudo formalizado de interação estratégica. Neste contexto, um jogo é um modelo de tal uma interação, tipicamente no mundo real, que codifica conjuntos de ações disponíveis para participantes do jogo, conhecidos como jogadores. Um jogo também especifica os pagamentos obtidos pelos jogadores individuais - recompensas que dependem das ações escolhidas pelo jogador e do ações dos outros jogadores. Talvez o exemplo mais conhecido de jogo estudado em game teoria é o Dilema dos Prisioneiros [178]. Os teóricos dos jogos geralmente pretendem compreender o equilíbrio ou equilíbrios (se houver) representados em um determinado jogo. Um equilíbrio é um conjunto de estratégias (uma para cada jogador) tal que nenhum jogador possa obter um valor mais alto recompensa ao desviar-se unilateralmente da sua estratégia. O desenho de mecanismos, por sua vez, é a ciência de desenhar incentivos de modo que o O equilíbrio de uma interação (e seu jogo associado) tem alguma propriedade desejável. MD pode ser visto como o inverso da teoria dos jogos: a questão canônica no jogo a teoria é: “dados os incentivos e o modelo, qual será o equilíbrio?” Em MD, o a questão é, em vez disso, “que incentivos resultarão num jogo com um equilíbrio desejável?” Um objetivo típico de um projetista de mecanismo é criar um mecanismo “compatível com incentivos”, o que significa que os participantes do mecanismo (por exemplo, um leilão ou outra informação sistema de elicitação [228]) são incentivados a relatar a verdade sobre algum assunto (por exemplo, como quanto eles valorizam um determinado item). O leilão de Vickrey (segundo preço) é talvez o mecanismo compatível com incentivos mais conhecido, no qual os participantes apresentam propostas lacradas para um item e o licitante com lance mais alto ganha o item, mas paga o segundo preço mais alto [214]. A criptoeconomia é uma forma de MD de domínio específico que aproveita a criptografia técnicas para criar equilíbrios desejáveis dentro de sistemas descentralizados. O suborno e o conluio criam desafios significativos em todo o campo da DM. Quase todos os mecanismos quebram na presença de conluio, definido como contratos paralelos entreentre as partes participantes de um mecanismo [125, 130]. O suborno, em que uma parte externa introduz novos incentivos no jogo, apresenta um problema ainda mais difícil do que o conluio; o conluio pode ser visto como um caso especial de suborno entre jogadores participantes. Os sistemas Blockchain podem muitas vezes ser conceituados como jogos com recompensas monetárias (baseadas em criptomoedas). Um exemplo simples é a mineração Proof-of-Work: os mineradores têm um espaço de ação no qual eles podem escolher a hashtaxa com a qual extrair blocos. O retorno da mineração é uma recompensa negativa garantida (custo de eletricidade e equipamentos) mais um fator estocástico. recompensa positiva (subsídio de mineração) que depende do número de outros mineradores ativos [106, 172] e taxas de transação. oracles crowdsourced como SchellingCoin [68] são outro exemplo: o espaço de ação é o conjunto de relatórios possíveis que um oracle pode enviar, enquanto a recompensa é a recompensa especificada pelo mecanismo oracle, por exemplo, o pagamento pode depender sobre quão próximo o relatório de um oracle está da mediana dos outros relatórios [26, 68, 119, 185]. Os jogos Blockchain oferecem oportunidades propícias para ataques de conluio e suborno; na verdade, smart contracts podem até facilitar tais ataques [96, 165]. Talvez o mais conhecido O ataque de suborno a oracles de crowdsourcing é o ataque p-plus-epsilon [67]. Este ataque surge no contexto de um mecanismo semelhante ao SchellingCoin, no qual os jogadores enviam relatórios com valor booleano (ou seja, falsos ou verdadeiros) e são recompensados com p se concordarem com o submissão da maioria. Em um ataque p-mais-épsilon, o invasor promete, com credibilidade, por exemplo, pague aos usuários $p + ϵ por votarem falso se e somente se a submissão da maioria for verdadeira. O resultado é um equilíbrio, em que todos os intervenientes são incentivados a denunciar falsas independentemente do que os outros jogadores façam; conseqüentemente, o subornador pode induzir os nós através do suborno prometido para reportar informações falsas sem realmente pagar o suborno (!). A exploração de outras estratégias de suborno no contexto de oracles, no entanto - e particularmente de oracles que não são de crowdsourcing - tem sido limitada a adversários bastante fracos. modelos. Por exemplo, no cenário PoW, os pesquisadores estudaram subornos, ou seja, subornos pagos apenas se uma mensagem alvo for censurada com sucesso e não aparecem em um bloco, independentemente da ação individual de um minerador [96, 165]. No caso de oracles, no entanto, além do ataque p-plus-epsilon, estamos cientes apenas do trabalho em um modelo estritamente limitado de suborno, no qual um subornador envia um suborno condicionado a um ação individual do jogador, não no resultado resultante. Aqui esboçamos projetos de mecanismos de elicitação de informações que permanecem incentivos compatível mesmo em um modelo adversário forte, conforme descrito na próxima subseção. 9.3 Suposições de modelagem Nesta subseção, explicamos como modelamos o comportamento e as capacidades dos jogadores em nosso sistema, especificamente nós oracle de primeira camada, nós de segunda camada (julgamento) camada e adversários.9.3.1 Modelo de incentivo de primeiro nível: atores racionais Muitos sistemas blockchain dependem de segurança na suposição de um certo número de informações honestas nós participantes. Os nós são definidos para serem honestos se seguirem o protocolo mesmo quando não for do seu interesse financeiro fazê-lo. Sistemas de prova de trabalho normalmente exigem que a maior parte do poder de hash seja honesto, os sistemas de prova de participação normalmente exigem que 2/3 ou mais de todas as participações participantes sejam honestos, e até mesmo sistemas de camada 2 como Arbitrum [141] exige pelo menos um único participante honesto. Na modelagem do nosso mecanismo staking, fazemos uma suposição muito mais fraca. (Para ser suposições claras e mais fracas significam propriedades de segurança mais fortes e são, portanto, preferíveis.) Assumimos que o adversário corrompeu, ou seja, controla, alguns (minoria) fração de nós oracle de primeira camada. Modelamos os nós restantes não como agentes honestos, mas como maximizadores racionais da utilidade esperada. Esses nós agem inteiramente de acordo com incentivos financeiros de interesse próprio, escolhendo ações que resultem em um resultado financeiro esperado. ganho. Por exemplo, se for oferecido a um nó um suborno maior do que a recompensa resultante de comportamento honesto, aceitará o suborno. Nota sobre nós adversários: De acordo com a modelagem de confiança comum para sistemas descentralizados, assumimos que todos os nós são racionais, ou seja, buscando maximizar receita líquida, em vez de ser controlada por um adversário malicioso. Nossas reivindicações, no entanto - impacto staking especificamente superlinear ou quadrático - mantido assintoticamente fornecido que o conjunto de nós controlados adversamente é no máximo (1/2 −c)n, para alguns pontos positivos constante c. 9.3.2 Modelo de adjudicação de segundo nível: correção por suposição Lembre-se de que um recurso crítico do nosso mecanismo staking que ajuda a alcançar a segurança contra nós racionais é seu sistema de segunda camada. Em nosso mecanismo staking proposto, qualquer oracle pode gerar um alerta indicando que ele acredita que a saída do mecanismo está incorreta. Um alerta resulta em uma alta confiança sistema de segundo nível ativando e relatando o resultado correto. Assim, uma modelagem chave O requisito para a nossa abordagem é a adjudicação correta, ou seja, o relato correto por parte do sistema de segundo nível. Nosso modelo staking assume um sistema de segundo nível que atua como uma fonte de verdade incorruptível e extremamente confiável. É provável que tal sistema seja caro e lento e, portanto, inadequado para uso no caso típico. No caso de equilíbrio, entretanto, ou seja, quando Se o sistema de primeira camada funcionar corretamente, o sistema de segunda camada não será invocado. Em vez disso, a sua existência aumenta a segurança de todo o sistema oracle, fornecendo um proteção de alta segurança. O uso de uma camada de julgamento de alta confiança e alto custo assemelha-se ao processo de apelação no coração da maioria dos sistemas judiciais. Também já é comum no design de oracle sistemas, por exemplo, [119, 185]. Discutimos brevemente abordagens para a realização do segundo nível em nosso mecanismo na Seção 9.4.3.Nosso protocolo staking usa a suposta adjudicação correta do sistema de segundo nível como uma ameaça credível para impor relatórios corretos por nós oracle. O protocolo confisca parte ou toda a participação dos nós oracle que geram relatórios identificados por o sistema de segundo nível como incorreto. Os nós Oracle são, portanto, impedidos de se comportarem mal pela penalidade financeira resultante. Esta abordagem é semelhante em sabor àquela usada em rollups otimistas, por exemplo, [141, 10]. 9.3.3 Modelo Adversário Nosso mecanismo staking foi projetado para obter informações verdadeiras e, ao mesmo tempo, obter segurança contra uma classe ampla e bem definida de adversários. Melhora os trabalhos anteriores, que omitem um modelo adversário explícito ou se concentram em subclasses estreitas de adversários, por exemplo, o adversário p-mais-épsilon discutido acima. Nosso objetivo é projetar um staking mecanismo com segurança formalmente comprovada contra todo o espectro de adversários prováveis a ser encontrado na prática. Modelamos nosso adversário como tendo um orçamento fixo (parametrizável), denotado por $ B. O adversário pode se comunicar individual e confidencialmente com cada oracle em rede e pode oferecer secretamente a qualquer indivíduo oracle pagamento garantido de suborno dependente de resultados publicamente observáveis do mecanismo. Resultados determinantes subornos podem incluir, por exemplo, o valor relatado pelo oracle, quaisquer mensagens públicas enviado por qualquer oracle ao mecanismo (por exemplo, um alerta), os valores relatados por outros oracles e o valor gerado pelo mecanismo. Nenhum mecanismo pode proteger contra um invasor com capacidades ilimitadas. Portanto, consideramos alguns comportamentos irrealistas ou fora do escopo. Presumimos que nosso atacante não pode quebrar primitivas criptográficas padrão e, como observado acima, tem um valor fixo (se potencialmente grande) orçamento $B. Assumimos ainda que o adversário não controla comunicação na rede oracle, especificamente que não pode atrasar substancialmente tráfego entre nós de primeira e/ou segunda camada. (Se o adversário pode observar tal comunicação depende do mecanismo específico, conforme explicamos abaixo.) Informalmente, porém, como observado acima, presumimos que o adversário pode: (1) Corromper uma fração de nós oracle ((1/2 −c)-fração para alguma constante c), ou seja, controle total e (2) oferecer subornos a quaisquer nós desejados, com pagamento contingente garantido nos resultados especificados pelo adversário, conforme descrito acima. Embora não ofereçamos um modelo formal ou uma taxonomia completa da situação completa do adversário, gama de capacidades de suborno neste whitepaper, aqui estão exemplos dos tipos de subornos abrangidos pelo nosso modelo. Para simplificar, assumimos que oracles emitem booleanos relatórios cujo valor correto (w.l.o.g.) é verdadeiro, e que um resultado final é calculado como um agregado desses relatórios a ser usado por um consumidor smart contract. O subornado O objetivo é que o resultado final seja incorreto, ou seja, falso. • Subornador incondicional: O suborno oferece suborno $b a qualquer oracle que reporte algo falso. • Subornador probabilístico: o subornador oferece suborno $b com alguma probabilidade q para qualquer oracle que reporta falso.• suborno condicionado a resultado falso: o subornador oferece suborno $b a qualquer oracle que relate falso, desde que o resultado final seja falso. • Subornador sem alerta: o subornador oferece suborno em $b a qualquer oracle que denuncie false enquanto nenhum alerta for gerado. • Subornador p-plus-epsilon: O suborno oferece suborno $b a qualquer oracle que relate falso como desde que a maioria dos oracles não relatem falsos. • Subornador em potencial: o suborno oferece suborno $b antecipadamente para qualquer oracle selecionado para um papel aleatório e relatórios falsos. Em nosso protocolo staking proposto, todos nós atuam como potenciais vigilantes, e somos capazes de mostrar que a randomização das prioridades de vigilância não se presta a possíveis subornos. Muitos sistemas de prova de trabalho, proof-of-stake e sistemas autorizados são suscetíveis a possíveis suborno, no entanto, o que mostra a importância de considerá-lo em nosso contexto antagônico modelo e garantindo que nossos protocolos staking sejam resilientes a ele. Consulte o Apêndice E para mais detalhes. 9.3.4 Quanto de segurança criptoeconômica é suficiente? Um adversário racional só gastará dinheiro para atacar um sistema se puder obter lucro maior do que as suas despesas. Assim, para nosso modelo adversário e proposto staking mecanismo, $B pode ser visto como uma medida do lucro potencial que um adversário é capaz extrair de smart contracts confiáveis corrompendo uma rede oracle e causando-a para gerar um relatório ou conjunto de relatórios incorreto. Ao decidir se uma rede oracle oferece um grau suficiente de segurança criptoeconômica para seus propósitos, um usuário deve avaliar a rede a partir desta perspectiva. Para adversários plausíveis em ambientes práticos, esperamos que $B seja geralmente substancialmente menor do que os ativos totais em smart contracts confiáveis. Na maioria dos casos, é é inviável para um adversário extrair esses ativos na sua totalidade. 9.4 Mecanismo de piquetagem: esboço Apresentamos aqui as ideias principais e a estrutura geral do mecanismo staking que estão considerando atualmente. Para facilitar a apresentação, descrevemos um método simples, mas lento protocolo (multi-round) nesta subseção. Notamos, no entanto, que este esquema é bastante prático. Dadas as garantias económicas proporcionadas pelo mecanismo, ou seja, a penalização e o consequente incentivo contra nós defeituosos, muitos utilizadores podem estar dispostos a aceitar relatórios com otimismo. Em outras palavras, tais usuários podem aceitar relatórios antes de possível julgamento pela segunda camada. Os usuários que não desejam aceitar relatórios de forma otimista podem optar por esperar até que o protocolo a execução termina, ou seja, até que ocorra qualquer escalonamento potencial para o segundo nível. Isto, no entanto, pode retardar substancialmente o tempo de confirmação dos relatórios. Portanto, brevementeFigura 15: Esquema do esquema staking com alerta. Neste exemplo, 1⃝a maioria de nós são corrompidos/subornados e emitem um valor incorreto ˜r, em vez do correto valor do relatório r. O nó watchdog 2⃝envia um alerta ao comitê de segundo nível, que 3⃝determina e emite o valor correto do relatório r, resultando em nós corrompidos perdendo seus depósitos - cada $d para o nó watchdog 4⃝. delinear algumas otimizações que resultam em uma rodada mais rápida (rodada única), embora um pouco mais projeto complexo na Seção 9.5. Lembre-se de que a primeira camada do nosso mecanismo staking consiste no oracle básico própria rede. A estrutura principal do nosso mecanismo, conforme descrito acima, é que em cada rodada, cada nó pode atuar como um “watchdog” com alguma prioridade e, portanto, tem a capacidade de emitir um alerta se o mecanismo chegar a uma saída incorreta ˜r, em vez de uma saída correta um R. Este alerta causa uma resolução de segundo nível, que presumimos que chega a um nível correto relatório. Nós com relatórios incorretos são punidos, no sentido de que suas apostas são cortado e concedido a cães de guarda. Esta estrutura básica é comum em sistemas oracle, como em, por exemplo, [119, 185]. A principal inovação em nosso projeto, mencionada brevemente acima, é que cada nó é atribuiu uma prioridade distinta na ordenação de potenciais vigilantes. Ou seja, cães de guarda recebem oportunidades de alertar em sequência de prioridade. Lembre-se de que se um nó tiver o prioridade mais alta para gerar um alerta, ele recebe o depósito reduzido $d de cada mau comportamento nó, para um total de mais de \(dn/2 = \)d × n/2, pois um relatório incorreto implica um maioria dos nós ruins. Consequentemente, o adversário deve pagar pelo menos esta recompensa ao subornar um nó arbitrário. Assim, para subornar a maioria dos nós, o adversário deve pagar uma taxa grande suborno para a maioria dos nós, ou seja, estritamente mais do que $dn2/2. Mostramos esquematicamente como funciona o alerta e o escalonamento do watchdog na Figura 15.9.4.1 Mais detalhes do mecanismo O sistema resistente ao suborno que descrevemos agora com mais detalhes é um esboço simplificado de a construção de dois níveis que pretendemos construir. A maior parte do nosso foco será na descrição a rede de primeiro nível (doravante simplesmente “rede” quando claro no contexto) junto com o seu mecanismo de incentivo e o procedimento de escalada para o segundo nível. Considere uma rede Chainlink composta por n nós oracle que são responsáveis por regularmente (por exemplo, uma vez por minuto) relatando um valor booleano (por exemplo, se o mercado a capitalização do BTC excede a da ETH). Como parte do mecanismo staking, nós deve fornecer dois depósitos: um depósito $d sujeito a redução em caso de desacordo com a maioria e um depósito de vigilância $dw sujeito a redução em caso de defeito escalada. Assumimos que os nós não podem copiar os envios de outros nós, por exemplo, através de um esquema commit-reveal conforme discutido na Seção 5.3. Em cada rodada, os nós primeiro comprometer-se com seu relatório e, quando todos os nós forem confirmados (ou o tempo limite expirar), nós revelam seus relatórios. Para cada relatório a ser gerado, cada nó também recebe uma prioridade de watchdog entre 1 e n escolhida aleatoriamente, sendo 1 a prioridade máxima. Esta prioridade permite concentração de recompensa nas mãos de um cão de guarda. Depois que todos os relatórios forem públicos, segue-se uma fase de alerta. Ao longo de uma sequência de n rodadas (síncronas), o nó com prioridade i tem a oportunidade de alertar na rodada i. Vamos considerar os resultados possíveis para o mecanismo após os nós terem revelado seus relatórios. Novamente assumindo um relatório binário, suponha que o valor correto seja verdadeiro e o incorreto é falso. Suponha também que o mecanismo de primeiro nível produza o valor majoritário produzido pelos nós como o relatório final r. Existem três resultados possíveis no mecanismo: • Concordância completa: na melhor das hipóteses, os nós estão em concordância completa: todos os nós estão disponíveis e forneceram um relatório oportuno com o mesmo valor r (verdadeiro ou falso). Neste caso, a rede precisa apenas encaminhar r para contratos confiáveis e recompensar cada nó com um pagamento fixo por rodada $p, que é muito menor do que $ d. • Concordância parcial: é possível que alguns nós estejam off-line ou haja desacordo sobre qual valor é correto, mas a maioria dos nós reporta verdadeiro e apenas um relatórios minoritários falsos. Este caso também é simples. O valor majoritário (verdadeiro) é calculado, resultando em um relatório correto r. Todos os nós que relataram r são recompensado com $p enquanto os oracles que relataram incorretamente têm seus depósitos reduzido modestamente, por exemplo, em US$ 10 centavos. • Alerta: Caso um watchdog acredite que a saída da rede está incorreta, ele aciona publicamente um alerta, escalando o mecanismo para a rede de segundo nível. Existem então dois resultados possíveis: – Alerta correto: Se a rede de segundo nível confirmar que a saída doFigura 16: Ampliando o custo do suborno por meio de recompensas concentradas em alertas. Um suborno O adversário deve subornar cada nó com mais do que a recompensa que pode ganhar ao alertar (mostrado como uma barra vermelha). Se as recompensas de alerta forem compartilhadas, então esta recompensa pode ser relativamente pequeno. Recompensas de alerta concentrado aumentam a recompensa que qualquer nó único pode obter (barra vermelha alta). Consequentemente, o pagamento total pelo adversário por um suborno viável (regiões cinzas) é muito maior com recompensas de alerta concentradas do que compartilhadas. rede de primeira camada estava incorreta, o nó watchdog alertador recebe uma recompensa consistindo em todos os depósitos reduzidos e, portanto, mais de $dn/2. – Alerta de falha: Se os oracles de segundo e primeiro nível concordarem, o escalonamento é considerado defeituoso e o nó de alerta perde seu depósito $dw. No caso de aceitação otimista dos relatórios, os alertas de vigilância não causam qualquer alteração na execução de contratos de confiança. Para contratos concebidos para aguardar possível arbitragem pelo comitê de segundo nível, alertas de vigilância atrasam, mas não congele a execução do contrato. Também é possível que os contratos designem um failover DON para períodos de adjudicação. 9.4.2 Impacto de piquetagem quadrática A capacidade de cada nó atuar como um cão de guarda, combinada com uma prioridade estrita de nó garantindo recompensas concentradas, permite que o mecanismo atinja staking quadrático impacto para cada tipo de atacante de suborno descrito na Seção 9.3.3. Lembre-se que isso significa especificamente em nossa configuração que, para uma rede com n nós, cada um com depósito $d, um subornador bem-sucedido (de qualquer um dos tipos acima) deve ter um orçamento maior que $dn2/2. Para ser mais preciso, o subornador deve corromper pelo menos (n+1)/2 nós, uma vez que o subornador deve corromper a maioria de n nós (para n ímpares, por suposição). Assim, um cão de guarda deve ganhe uma recompensa de $d(n + 1)/2. O subornador, consequentemente, deve pagar esta quantia a cadanó para garantir que nenhum atue como um cão de guarda. Estamos trabalhando para mostrar formalmente que se o subornador tem um orçamento de no máximo $d(n2 + n)/2, então o equilíbrio perfeito do subjogo do jogo entre os subornadores e os oracles - em outras palavras, o equilíbrio em qualquer ponto durante o jogo - é para o subornador não emitir o suborno e para cada oracle relate seus verdadeiros valores honestamente. Explicamos acima como é possível que um subornador bem-sucedido exija uma orçamento significativamente maior do que a soma dos depósitos dos nós. Para ilustrar isso resultado intuitivo, a Fig. 16 mostra graficamente o impacto das recompensas de alerta concentrado. Como vemos aí, se a recompensa pelo alerta de vigilância - nomeadamente os depósitos de dinheiro subornado nós reportando falsos) - foram divididos entre todos os alertas potenciais, o valor total que qualquer nó de alerta individual poderia esperar que fosse relativamente pequeno, da ordem de $d. Um subornador, sabendo que um pagamento maior que $d era improvável, poderia usar um suborno condicional de resultado falso para subornar cada um dos n nós com um pouco mais de $d + ϵ. Contra-intuitivamente, a Fig. 16 mostra que um sistema que distribui uma recompensa amplamente entre os nós que sinalizam um alerta é muito mais fraco do que aquele que concentra a recompensa em nas mãos de um único cão de guarda. Parâmetros de exemplo: Considere uma rede (de primeira camada) com n = 100 nós, cada depositando \(d = \)20K. Esta rede teria um total de US$ 2 milhões depositados, mas estar protegido contra suborno com orçamento \(100M = \)dn2/2. Aumentando o número de oracles é mais eficaz do que aumentar $d, é claro, e pode ter um efeito dramático: uma rede com n = 300 nós e depósitos \(d = \)20K estaria protegida contra um subornador com orçamento de até US$ 900 milhões. Observe que um sistema staking pode, em muitos casos, proteger smart contracts representando mais valor do que o nível oferecido de proteção contra suborno. Isso ocorre porque um adversário atacar estes contratos não consegue extrair o valor total em muitos casos. Por exemplo, um O contrato movido por Chainlink que garante US$ 1 bilhão em valor só pode exigir garantia contra um subornador com US$ 100 milhões em recursos porque tal adversário pode extrair lucro de maneira viável de apenas 10% do valor do contrato. Nota: A ideia de que o valor de uma rede pode crescer quadraticamente é expressa em a conhecida Lei de Metcalfe [167, 235], que afirma que o valor de uma rede cresce quadraticamente no número de entidades conectadas. A Lei de Metcalfe, no entanto, surge do crescimento no número de possíveis conexões de rede em pares, um fenômeno diferente daquele impacto quadrático subjacente staking em nosso incentivo mecanismo. 9.4.3 Realização do Segundo Nível Dois recursos operacionais facilitam a realização de um segundo nível de alta confiabilidade: (1) A adjudicação de segundo nível deve ser um evento raro em redes oracle e, portanto, pode ser significativamente mais dispendioso do que a operação normal do primeiro nível e (2) Assumindorelatórios aceitos com otimismo – ou contratos cuja execução pode aguardar arbitragem – a segunda camada não precisa ser executada em tempo real. Estas características resultam em uma série de opções de configuração para o segundo nível para atender aos requisitos de DONs específicos. Como exemplo de abordagem, um comitê de segundo nível pode consistir em nós selecionados por um DON (ou seja, primeiro nível) dos nós mais antigos e confiáveis no Chainlink rede. Além de considerável experiência operacional relevante, os operadores de tais nós têm um incentivo implícito considerável no FFO que motiva um desejo para garantir que a rede Chainlink permaneça altamente confiável. Eles também têm publicamente históricos de desempenho disponíveis que fornecem transparência em sua confiabilidade. Vale ressaltar que os nós de segunda camada não precisam ser participantes da rede de primeira camada, e pode julgar falhas em múltiplas redes de primeira camada. Os nós em um determinado DON podem pré-designar e comprometer-se publicamente com um conjunto de n′ tais nós como constituindo o comitê de segundo nível para aquele DON. Além disso, DON os nós publicam um parâmetro k′ ≤n′ que determina o número de votos de segundo nível necessário para penalizar um nó de primeira camada. Quando um alerta é gerado para um determinado relatório, os membros do segundo nível votam na correção dos valores fornecidos por cada dos nós de primeira camada. Qualquer nó de primeira camada que receber k′ votos negativos perde sua depósitos no nó watchdog. Devido à raridade do julgamento e à oportunidade de execução prolongada mencionado acima, em contraste com o primeiro nível, os nós do segundo nível podem: 1. Ser altamente remunerado pela condução da adjudicação. 2. Recorrer a fontes de dados adicionais, para além do conjunto diversificado utilizado pelo primeiro nível. 3. Confiar na inspeção e intervenção manual e/ou especializada, por exemplo, para identificar e reconciliar erros nos dados de origem e distinguir entre um nó honesto retransmitindo dados defeituosos e um nó com mau comportamento. Enfatizamos que a abordagem que acabamos de descrever para a seleção de nós de segundo nível e para a adjudicação de políticas que governam representa apenas um ponto dentro de um grande espaço de design de possíveis realizações do segundo nível. Nosso mecanismo de incentivo oferece total flexibilidade quanto à forma como o segundo nível é realizado. DONs individuais podem, portanto, constituir e definir regras para seus segundos níveis que atendam aos requisitos específicos e expectativas dos nós e usuários participantes. DECO e Town Crier como ferramentas de adjudicação: É essencial para o segundo nível em nosso mecanismo para sermos capazes de distinguir entre nós adversários de primeira camada que produzem intencionalmente relatórios incorretos e nós honestos de primeira camada que involuntariamente retransmitir dados incorretos na origem. Só então o segundo nível poderá implementar cortar para desincentivar a trapaça, o objetivo do nosso mecanismo. DECO e Pregoeiro são ferramentas poderosas que podem permitir que nós de segundo nível façam essa distinção crítica de forma confiável.Os nós de segunda camada podem, em alguns casos, ser capazes de consultar diretamente a fonte de dados usada por um nó de primeira camada ou use a Seção 7.1 do ADO para verificar se um relatório incorreto resultou de uma fonte de dados defeituosa. Em outros casos, entretanto, os nós de segundo nível podem não ter acesso direto à fonte de dados de um nó de primeira camada. Nesses casos, a decisão correta seria parecem ser inviáveis ou exigem confiança em julgamento subjetivo. Anterior oracle sistemas de disputas têm dependido de rodadas de votação ineficientes e crescentes para resolver tais desafios. Usando DECO ou Town Crier, no entanto, um nó de primeiro nível pode provar o comportamento correto para nós de segunda camada. (Veja a Seção 3.6.2 para detalhes sobre os dois sistemas.) Especificamente, se o nó da segunda camada identifica um nó da primeira camada como tendo gerado um valor de relatório defeituoso ˜r, o nó de primeiro nível pode usar DECO ou Town Crier para gerar evidências à prova de falsificação para nós de segunda camada que estão retransmitindo corretamente ˜r de uma fonte (habilitada para TLS) reconhecido como oficial pelo DON. Criticamente, o nó de primeira camada pode fazer isso sem nós de segundo nível que exijam acesso direto à fonte de dados.17 Consequentemente, a adjudicação correta é viável em Chainlink para qualquer fonte de dados desejada. 9.4.4 Relatório incorreto de seguro A forte resistência ao suborno alcançada pelo nosso mecanismo staking depende fundamentalmente sobre a redução de fundos concedidos aos alertadores. Sem uma recompensa monetária, os alertadores não têm incentivo direto para rejeitar subornos. Como resultado, porém, os fundos cortados não são disponível para compensar usuários prejudicados por relatórios incorretos, por exemplo, usuários que perdem dinheiro quando dados de preço incorretos são retransmitidos para smart contract. Por suposição, relatórios incorretos não representam um problema se os relatórios forem aceitos por um contrato somente após eventual adjudicação, ou seja, ação da segunda camada. Como explicado acima, porém, para alcançar o melhor desempenho possível, os contratos podem, em vez disso, contar com otimistas sobre o mecanismo para impor relatórios corretos, o que significa que eles aceitam relatórios antes de uma possível adjudicação de segundo nível. Na verdade, esse comportamento optimista está seguro em nosso modelo assumindo adversários racionais cujos orçamentos não excedam o staking impacto do mecanismo. Usuários preocupados com o evento improvável de falha do mecanismo resultante de, por exemplo, adversários com recursos financeiros esmagadores podem querer empregar uma camada adicional de segurança económica sob a forma de declarações falsas de seguros. Nós sabemos de múltiplas seguradoras que já pretendem oferecer apólices deste tipo apoiadas por contratos inteligentes para protocolos protegidos por Chainlink em um futuro próximo, inclusive por meio de mecanismos inovadores como DAOs, por exemplo, [7]. A existência de histórico de desempenho para Chainlink nós e outros dados sobre nós, como seus valores de participação, fornecem uma base excepcionalmente forte para avaliações atuariais de risco, tornando possível definir preços de políticas de formas que sejam baratas para os segurados, mas sustentáveis para as seguradoras. 17Com o Town Crier, também é possível que nós de primeiro nível gerem atestados localmente de correção para os relatórios que eles produzem e fornecem esses atestados para nós de segundo nível em um conforme necessário.Formas básicas de seguro contra declarações falsas podem ser implementadas de forma confiável e maneira eficiente usando smart contracts. Como exemplo simples, um seguro paramétrico contrato SCins pode compensar os segurados automaticamente se nosso mecanismo de incentivo segunda camada identifica um erro em um relatório gerado na primeira camada. Um usuário U que deseja adquirir uma apólice de seguro, por exemplo, o criador de um alvo contrato SC, pode enviar uma solicitação a uma seguradora descentralizada por um valor de apólice $ milhões no contrato. Ao aprovar U, a seguradora pode definir um valor contínuo (por exemplo, mensal) prêmio de $P em SCins. Enquanto U paga o prêmio, sua apólice permanece ativa. Caso ocorra falha de reporte no SC, o resultado será a emissão de um par (r1, r2) de relatórios conflitantes para SC, onde r1 é assinado pelo primeiro nível em nosso mecanismo e r2, o relatório corrigido correspondente, é assinado pelo segundo nível. Se o U fornecer um par válido (r1, r2) para SCins, o contrato paga automaticamente $M a ela, desde que seus pagamentos de prêmio estão em dia. 9,5 Variante de Rodada Única O protocolo descrito na subseção anterior exige que o comitê de segundo nível espere n rodadas para determinar se um cão de guarda emitiu um alerta. Isto O requisito é válido mesmo no caso otimista, ou seja, quando o primeiro nível está funcionando corretamente. Para usuários que não desejam aceitar relatórios de forma otimista, ou seja, antes de possíveis adjudicação, o atraso associado a essa abordagem seria impraticável. Por esta razão, também estamos explorando protocolos alternativos que requerem apenas um redondo. Nesta abordagem, todos os nós oracle enviam bits secretos indicando se ou não eles desejam levantar um alerta. O comité de segundo nível verifica então estes valores em ordem de prioridade. Para fornecer um esboço, tal esquema pode envolver o seguinte etapas: 1. Envio de bits de watchdog: cada nó Oi compartilha secretamente um valor de watchdog de um bit wi ∈{no alert, alert} entre os nós da segunda camada para cada relatório gerado. 2. Dicas anônimas: Qualquer nó oracle pode enviar uma dica anônima α ao comitê de segundo nível na mesma rodada em que os bits de vigilância são enviados. Essa dica α é uma mensagem indicando que um alerta foi gerado para o relatório atual. 3. Verificação de bits de vigilância: o comitê de segundo nível revela o cão de guarda dos nós oracle bits em ordem de prioridade. Observe que os nós não devem enviar bits de vigilância de alerta quando não alertam: caso contrário, a análise de tráfego revela os bits de todos os nós. O protocolo revela o não alerta bits de watchdog de nós com prioridade mais alta do que o watchdog de alerta de maior prioridade. Observe que o que é revelado é idêntico ao do nosso protocolo n-round. As recompensas também são distribuídas de forma idêntica a esse esquema, ou seja, o primeiro cão de guarda identificado recebe os depósitos reduzidos de nós que enviaram relatórios incorretos.O uso de denúncias anônimas permite que o comitê de segundo nível permaneça não interativo nos casos em que nenhum alerta foi levantado, reduzindo a complexidade da comunicação no caso comum. Observe que qualquer cão de guarda que emita um alerta tem um incentivo econômico para enviar uma denúncia anônima: se nenhuma denúncia for enviada, nenhuma recompensa será paga a qualquer nó. Para garantir que o remetente Oi de uma denúncia anônima α não possa ser identificado pelo adversário com base em dados de rede, a denúncia anônima pode ser enviada por meio de uma rede anônima canal, por exemplo, via Tor, ou, mais praticamente, proxy através de um provedor de serviços em nuvem. Para autenticar a ponta como originária de O, Oi pode assinar α usando uma assinatura de anel [39, 192]. Alternativamente, para evitar ataques de negação de serviço não atribuíveis contra o comitê de segundo nível por um nó oracle malicioso, α pode ser uma credencial anônima com anonimato revogável [73]. Este protocolo, embora praticamente alcançável, possui engenharia um tanto pesada requisitos (que estamos explorando maneiras de reduzir). Nós de primeira camada, por exemplo, deve se comunicar diretamente com nós de segunda camada, exigindo manutenção de um diretório. A necessidade de canais anônimos e assinaturas em anel aumenta a engenharia complexidade do esquema. Finalmente, há um requisito especial de confiança brevemente discutido na nota abaixo. Estamos, portanto, também a explorar esquemas mais simples que ainda alcançam impacto superlinear staking, mas talvez menos que quadrático, em que um subornador precisa assintoticamente de recursos de pelo menos $n log n, por exemplo. Alguns dos esquemas sob consideração envolve a seleção aleatória de um subconjunto estrito de nós para atuar como vigilantes, nesse caso, o possível suborno torna-se um ataque especialmente poderoso. Observação: A segurança deste mecanismo staking de rodada única requer canais entre oracle e nós de segundo nível - um requisito padrão em sistemas resistentes à coerção, por exemplo, votação [82, 138], e um requisito razoável na prática. Além disso, porém, um nó da Oi que busca cooperar com um subornador pode construir suas ações secretas de forma a mostrar ao subornador que ele codificou um determinado valor. Por exemplo, se a Oi não sabe quais nós o subornador controla, então a Oi pode enviar ações com valor 0 para todos os membros do comitê. O subornador pode então verificar as informações da Oi conformidade probabilisticamente. Para evitar este problema em qualquer protocolo de rodada única, exigir que a Oi conheça a identidade de pelo menos um nó honesto de segunda camada. Com um protocolo interativo no qual cada nó de segunda camada adiciona uma randomização fator para as ações, o melhor que o subornador pode fazer é forçar a seleção pela Oi de um número aleatório pedaço de cão de guarda. 9.6 Quadro de Incentivos Implícitos (IIF) FFO é uma forma de incentivo implícito para o comportamento correto na rede Chainlink. Isso funciona como participação explícita, ou seja, depósitos, na medida em que ajuda a reforçar a segurança económica para a rede. Em outras palavras, o FFO deve ser incluído como parte do depósito (efetivo) $d de um nó na rede.A questão é: como medimos o FFO e outras formas de incentivo implícito dentro da rede Chainlink? O Quadro de Incentivos Implícitos (IIF) é um conjunto de princípios e técnicas que planejamos desenvolver para esse fim. Sistemas Blockchain fornecem muitas formas de transparência sem precedentes e os registros de alta confiança dos nós O desempenho que eles criam é um trampolim para a nossa visão de como o IIF funcionará. Aqui esboçamos brevemente ideias sobre elementos-chave do IIF. O próprio IIF consistirá em um conjunto de fatores que identificamos como importantes na avaliação incentivos implícitos, juntamente com mecanismos para publicação de dados relevantes de forma altamente segura para consumo por algoritmos analíticos. Diferentes usuários Chainlink podem desejam usar o IFI de maneiras diferentes, por exemplo, dando pesos diferentes a fatores diferentes. Esperamos que surjam serviços de análise na comunidade que ajudem os usuários a aplicar o IIF de acordo com suas preferências individuais de avaliação de risco, e nosso objetivo é facilitar tais serviços, garantindo o seu acesso a dados de apoio de alta segurança e oportunos, conforme discutiremos abaixo (Seção 9.6.4). 9.6.1 Oportunidade de taxas futuras Os nós participam do ecossistema Chainlink para ganhar uma parte das taxas que as redes pagam por qualquer um dos vários serviços descritos neste artigo, desde feeds de dados comuns para serviços avançados, como identidade descentralizada, sequenciamento justo, e preservação de confidencialidade DeFi. As taxas na rede Chainlink suportam os custos dos operadores de nós para, por exemplo, executar servidores, adquirir licenças de dados necessárias e manter uma equipe global para garantir alto tempo de atividade. FFO denota as taxas de serviço, líquidas de despesas, que um nó pode ganhar no futuro – ou perder caso demonstre comportamento defeituoso. FFO é uma forma de participação que ajuda a proteger a rede. Uma característica útil do FFO é o fato de que os dados on-chain (complementados por dados off-chain dados) estabelecem um registro de alta confiança do histórico de um nó, permitindo o cálculo do FFO de forma transparente e empiricamente orientada. Uma medida simples e de primeira ordem do FFO pode derivar da receita líquida média de um nó durante um período de tempo (ou seja, receita bruta menos despesas operacionais). FFO pode então ser calculado como, por exemplo, o valor presente líquido [114] da receita líquida futura acumulada, em outras palavras, o valor descontado no tempo de todos os ganhos futuros. A receita do nó pode ser volátil, no entanto, como mostrado, por exemplo, na Figura 17. Mais importante ainda, a receita do nó pode não seguir uma distribuição estacionária ao longo do tempo. Consequentemente, outros fatores que planejamos explorar na estimativa do FFO incluem: • Histórico de desempenho: o histórico de desempenho de um operador – incluindo a exatidão e pontualidade de seus relatórios, bem como seu tempo de atividade – fornece um objetivo pedra de toque para os usuários avaliarem sua confiabilidade. O histórico de desempenho será, portanto, fornecem um fator crítico na seleção de nós oracle pelos usuários (ou, com o advento de DONs, sua seleção de DONs). É provável que um forte histórico de desempenho correlacionar com alta receita contínua.18 18Uma importante questão de investigação que pretendemos abordar é a detecção de volumes de serviços falsificados.Figura 17: Receita obtida por nós Chainlink em um único feed de dados (ETH-USD) durante uma semana representativa em março de 2021. • Acesso a dados: embora oracles possam obter muitas formas de dados de APIs abertas, certas formas de dados ou certas fontes de alta qualidade podem estar disponíveis apenas em um por assinatura ou por meio de acordos contratuais. Acesso privilegiado a determinados as fontes de dados podem desempenhar um papel na criação de um fluxo de receitas estável. • Participação de DON: Com o advento de DONs, comunidades de nós surgirão juntos para fornecer serviços específicos. Esperamos que muitos DONs incluam operadores de forma seletiva, estabelecendo participação em DONs respeitáveis como um posição privilegiada no mercado que ajuda a garantir uma fonte consistente de receitas. • Atividade entre plataformas: alguns operadores de nós podem ter presenças bem estabelecidas e registros de desempenho em outros contextos, por exemplo, como PoS validators ou provedores de dados em contextos não blockchain. O seu desempenho nestes outros sistemas (quando os dados sobre eles estão disponíveis de forma confiável) pode informar a avaliação de seu histórico de desempenho. Da mesma forma, comportamento defeituoso na rede Chainlink pode comprometer a receita nesses outros sistemas, afastando usuários, ou seja, FFO pode se estender através de plataformas. 9.6.2 FFO especulativo Os operadores de nós participam da rede Chainlink não apenas para gerar receita de operações, mas sim criar e posicionar-se para aproveitar novas oportunidades para administrar empregos. Em outras palavras, os gastos por oracle nós da rede também são uma declaração positiva sobre o futuro de DeFi e outras aplicações de contratos inteligentes domínios, bem como aplicativos emergentes não blockchain de redes oracle. Os operadores de nós hoje ganham as taxas disponíveis nas redes Chainlink existentes e, simultaneamente, Estas são vagamente análogas às avaliações falsas em sites da Internet, exceto que o problema é mais fácil no oracle porque temos um registro definitivo se as mercadorias, ou seja, relatórios, foram encomendadas e entregues - em oposição, por exemplo, a bens físicos encomendados em lojas online. Dito de outra forma, no oracle configuração, o desempenho pode ser validado, mesmo que a veracidade do cliente não possa.construir uma reputação, histórico de desempenho e conhecimento operacional que posicionará vantajosamente para ganhar taxas disponíveis em redes futuras (contingentes, é claro, sobre comportamento honesto). Os nós que operam no ecossistema Chainlink hoje irão neste sentido, têm uma vantagem sobre os recém-chegados em ganhar taxas adicionais Chainlink serviços ficam disponíveis. Esta vantagem aplica-se a novos operadores, bem como a empresas de tecnologia com reputação estabelecida; por exemplo, a T-Systems, uma tradicional fornecedor de tecnologia (subsidiária da Deutsche Telekom) e Kraken, uma grande empresa centralizada exchange, estabeleceram presenças iniciais no ecossistema Chainlink [28, 143]. Tal participação dos nós oracle em oportunidades futuras pode ser considerada em si como uma espécie de FFO especulativo e, portanto, constitui uma forma de participação no Chainlink rede. 9.6.3 Reputação Externa O IIF, como o descrevemos, pode operar em uma rede com nomes estritamente pseudônimos. operadores, ou seja, sem divulgação das pessoas ou entidades do mundo real envolvidas. Um fator potencialmente importante para a seleção de fornecedores pelos usuários, no entanto, é a reputação. Por reputação externa entendemos a percepção de confiabilidade associada a identidades do mundo real, em vez de pseudônimos. Risco reputacional associado a identidades do mundo real podem ser vistas como uma forma de incentivo implícito. Nós vemos a reputação através das lentes do IIF, ou seja, no sentido criptoeconômico, como meio de estabelecer atividade multiplataforma que pode ser incorporada nas estimativas de FFO. O benefício de usar a reputação externa como um fator nas estimativas do FFO, em oposição à ligação por pseudônimo, é que a reputação externa vincula o desempenho não apenas a um atividades atuais do operador, mas também às futuras. Se, por exemplo, uma má reputação atribui a uma pessoa individual, pode manchar os futuros empreendimentos dessa pessoa. Dito de outra forma, a reputação externa pode capturar uma faixa mais ampla de FFO do que o pseudônimo registros de desempenho, como o impacto da má conduta associada a uma pessoa ou estabelecida empresa é mais difícil de escapar do que aquela associada a uma operação pseudônima. Chainlink é compatível com tecnologias de identidade descentralizadas (Seção 4.3) que pode fornecer suporte para o uso da reputação externa no IFI. Tais tecnologias pode validar e, assim, ajudar a garantir a veracidade das declarações do mundo real afirmadas pelos operadores. identidades.19 9.6.4 Abra a análise IIF O IIF, como observamos, visa fornecer dados e ferramentas confiáveis e de código aberto para análise de incentivo implícito. O objetivo é capacitar os provedores da comunidade desenvolver análises adaptadas às necessidades de avaliação de risco de diferentes partes do Chainlink base de usuários. 19Credenciais de identidade descentralizadas também podem, quando desejado, embelezar pseudônimos com informações validadas informações complementares. Por exemplo, um operador de nó poderia, em princípio, usar essas credenciais para provar que se trata de uma empresa Fortune 500, sem revelar qual.Uma quantidade considerável de dados históricos sobre receita e desempenho dos nós reside na cadeia de uma forma imutável e de alta confiança. Nosso objetivo, no entanto, é fornecer o dados mais abrangentes possíveis, incluindo dados sobre comportamentos que são visíveis apenas fora cadeia, como relatório fora da cadeia (OCR) ou atividade DON. Esses dados podem potencialmente ser volumoso. A melhor forma de armazená-lo e garantir sua integridade, ou seja, protegê-lo de a adulteração, acreditamos, será com a ajuda de DONs, usando técnicas discutidas na Seção 3.3. Alguns incentivos se prestam a formas diretas de medição, como staking depósitos e FFO básico. Outros, como o FFO especulativo e a reputação, são mais difíceis de medir de maneira objetiva, mas acreditamos que apoiar formas de dados, incluindo crescimento histórico do ecossistema Chainlink, métricas de reputação de mídia social, etc., pode suportar modelos analíticos IIF mesmo para esses elementos mais difíceis de quantificar. Podemos imaginar que DONs dedicados surgem especificamente para monitorar, validar e registrar dados relacionados a registros de desempenho off-chain de nós, bem como outros dados usados no IIF, como informações de identidade validadas. Esses DONs podem fornecer dados IIF uniformes e de alta confiança para qualquer provedor de análise que atenda à comunidade Chainlink. Eles também fornecerão um registro de ouro que fará com que as reivindicações dos provedores de análise verificável de forma independente pela comunidade. 9.7 Juntando tudo: incentivos para operadores de nós Sintetizando nossas discussões acima sobre incentivos explícitos e implícitos para operadores de nós fornece uma visão holística das maneiras pelas quais os operadores de nós participam e se beneficiam a rede Chainlink. Como guia conceitual, podemos expressar o total de ativos em jogo por um determinado Chainlink operador de nó $S em uma forma aproximada e estilizada como: \(S ≈\)D + \(F + \)FS +$R, onde: • $D é o agregado de todas as participações explicitamente depositadas em todas as redes nas quais a operadora participa; • $F é o valor presente líquido do agregado de todos os FFO em todas as redes em em que o operador participa; • $FS é o valor presente líquido do FFO especulativo do operador; e • $R é o patrimônio reputacional do operador fora do ecossistema Chainlink que pode ser prejudicado pelo mau comportamento identificado em seus nós oracle. Embora em grande parte conceitual, essa igualdade aproximada mostra de forma útil que há uma multiplicidade de fatores econômicos que favorecem o desempenho de alta confiabilidade dos nós Chainlink. Todos esses fatores, exceto $D, estão presentes nas redes Chainlink atuais.9,8 O Ciclo Virtuoso da Segurança Económica A combinação do impacto superlinear staking com representação de pagamentos de taxas como a oportunidade de taxas futuras (FFO) no IIF pode levar ao que chamamos de ciclo virtuoso de segurança econômica em uma rede oracle. Isto pode ser visto como uma espécie de economia de escala. À medida que o montante total garantido por uma determinada rede aumenta, o montante de a participação adicional necessária para adicionar uma quantidade fixa de segurança econômica diminui, assim como o custo médio por usuário. Portanto, é mais barato, em termos de taxas, para um usuário aderir uma rede já existente do que alcançar o mesmo aumento na economia de rede segurança criando uma nova rede. É importante ressaltar que a adição de cada novo usuário diminui o custo do serviço para todos os usuários anteriores dessa rede. Dada uma estrutura de taxas específica (por exemplo, uma taxa de rendimento específica sobre o valor apostado), se o total de taxas recebidas por uma rede aumentar, isso incentiva o fluxo de recursos adicionais apostar na rede para protegê-la a uma taxa mais alta. Especificamente, se a aposta total um nó individual pode reter no sistema é limitado, então, quando novos pagamentos de taxas entrar no sistema, aumentando seu FFO, o número de nós n aumentará. Graças ao impacto superlinear staking do design do nosso sistema de incentivos, a segurança econômica de o sistema subirá mais rápido que n, por exemplo, como n2 no mecanismo que esboçamos na Seção 9.4. Como resultado, o custo médio para a segurança económica – ou seja, a quantidade de participação que contribui um dólar de segurança económica – cairá. A rede pode, portanto, cobrar de seus usuários taxas mais baixas. Supondo que a demanda por serviços oracle seja elástica (ver, por exemplo, [31] para um breve explicação), a demanda aumentará, gerando taxas e FFO adicionais. Ilustramos esse ponto com o seguinte exemplo. Exemplo 5. Visto que a segurança económica de uma rede oracle com o nosso incentivo esquema é \(dn2 for stake \)dn, a segurança econômica contribuída por um dólar de participação é n e, portanto, o custo médio por dólar de segurança econômica - ou seja, o valor da participação contribuir para um dólar de segurança económica – é 1/n. Considere uma rede na qual os incentivos económicos consistem inteiramente em FFO, limitados em \(d ≤\)10K por nó. Suponha que a rede tenha n = 3 nós. Então o custo médio por dólar de segurança económica é de cerca de 0,33 dólares. Suponha que o FFO total da rede ultrapasse \(30K (e.g., to \)31K). Dado o limite de FFO por nó, a rede cresce para (pelo menos) n = 4. Agora o custo médio por dólar de segurança económica cai para cerca de 0,25 dólares. Ilustramos esquematicamente o ciclo virtuoso completo da segurança económica nas redes oracle na Fig. Enfatizamos que o ciclo virtuoso da segurança económica deriva do efeito dos usuários agrupando suas taxas. É o seu FFO colectivo que trabalha a favor de maiores tamanhos de rede e, portanto, maior segurança coletiva. Notamos também que o ciclo virtuoso da segurança económica funciona a favor de DONs alcançarem a sustentabilidade financeira. Uma vez criados, DONs que atendem às necessidades do usuário devem crescer até e além do ponto em que a receita proveniente de taxas excede os custos operacionais para nós oracle.

Figura 18: Esquema do ciclo virtuoso de Chainlink staking. Um aumento nas taxas de utilização pagamentos para uma rede oracle 1⃝faz com que ela cresça, levando ao crescimento de sua economia segurança 2⃝. Este crescimento superlinear realiza economias de escala em redes Chainlink 3⃝. Especificamente, significa uma redução no custo médio da segurança económica, ou seja, a segurança econômica por dólar decorrente de pagamentos de taxas ou outras fontes de participação aumenta. Custos mais baixos, repassados aos usuários, estimulam o aumento da demanda por oracle serviços 4⃝. 9,9 Fatores adicionais que impulsionam o crescimento da rede À medida que o ecossistema Chainlink continua a se expandir, acreditamos que a sua atratividade para os usuários e a importância da infraestrutura para a economia blockchain irá acelerar. O valor fornecido pelas redes oracle é superlinear, o que significa que cresce mais rápidodo que o tamanho das próprias redes. Este crescimento em valor decorre tanto economias de escala – maior eficiência de custos por usuário à medida que os volumes de serviço aumentam – e efeitos de rede – um aumento da utilidade da rede à medida que os usuários adotam DONs mais amplamente. À medida que os smart contracts existentes continuam a ver mais valor garantido e totalmente novo smart contract aplicações são possibilitadas por serviços mais descentralizados, o total o uso e as taxas agregadas pagas a DONs devem aumentar. Aumentar os conjuntos de taxas em por sua vez, traduzem-se em meios e incentivos para criar serviços ainda mais descentralizados, resultando em um ciclo virtuoso. Este ciclo virtuoso resolve uma questão crítica do ovo e da galinha problema no ecossistema híbrido smart contract: recursos inovadores smart contract muitas vezes exigem serviços descentralizados que ainda não existem (por exemplo, novos mercados DeFi muitas vezes exigem novos fluxos de dados) mas precisam de procura económica suficiente para existirem. O agrupamento de taxas por vários smart contracts para DONs existentes sinalizará a demanda por serviços descentralizados adicionais a partir de uma base de utilizadores crescente, dando origem à sua criação por DONs e uma capacitação contínua de novos e variados smart contracts híbridos. Em resumo, acreditamos que o crescimento da segurança de rede impulsionado por princípios virtuosos ciclos no mecanismo Chainlink staking exemplificam padrões maiores de crescimento que a rede Chainlink pode ajudar a criar uma economia em cadeia para descentralização serviços.

Conclusão

Neste artigo, apresentamos uma visão para a evolução de Chainlink. O tema principal nesta visão está a capacidade das redes oracle de fornecer uma gama muito mais ampla de serviços para smart contracts do que a mera entrega de dados. Usando DONs como base para os serviços descentralizados do futuro, Chainlink terá como objetivo fornecer funcionalidade oracle de desempenho e confidencialidade aprimorada. Suas redes oracle oferecerão forte minimização de confiança através de uma combinação de mecanismos criptoeconômicos de princípios, como staking e guarda-corpos cuidadosamente concebidos e aplicação do nível de serviço em cadeias principais confiáveis. DONs também ajudarão os sistemas de camada 2 a aplicar políticas de pedidos flexíveis e justas nas transações, bem como a reduzir os custos de gás para transações roteadas em mempool. Tomados em conjunto, todos esses recursos direcionam na direção de sistemas inteligentes híbridos seguros e altamente funcionais contratos. A flexibilidade dos DONs irá melhorar os serviços Chainlink existentes e dar origem a muitos recursos e aplicativos smart contract adicionais. Entre estes estão perfeitos conexão a uma ampla variedade de sistemas fora da cadeia, criação descentralizada de identidade a partir de dados existentes, canais prioritários para ajudar a garantir a entrega oportuna de recursos críticos para a infraestrutura transações e instrumentos de preservação de confidencialidade DeFi. A visão que apresentamos aqui é ambiciosa. No curto prazo, procuramos capacitar contratos híbridos para cumprir metas além do alcance de smart contracts hoje, enquanto no longo prazo, pretendemos realizar uma metacamada descentralizada. Felizmente podemos desenhar em novas ferramentas e ideias – desde algoritmos de consenso até prova de conhecimento zero sistemas – que a comunidade está desenvolvendo como fruto de pesquisas em rápida evolução.

Da mesma forma, esperamos priorizar a implementação das ideias deste documento em resposta às necessidades da comunidade de usuários de Chainlink. Estamos ansiosos pela próxima etapa em nossa busca para capacitar smart contracts por meio da conectividade universal e estabelecer tecnologias descentralizadas como a espinha dorsal da próxima geração de recursos financeiros do mundo e sistemas jurídicos. Agradecimentos Agradecimentos a Julian Alterini e Shawn Lee pela representação das figuras neste artigo.