체인링크: 분산형 오라클 네트워크
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.
초록
이 백서에서 우리는 원본 Chainlink 백서의 초기 개념을 넘어 Chainlink의 진화에 대한 비전을 명확히 설명합니다. 우리는 예측한다 oracle 네트워크의 역할이 점차 확대되고 있으며, 빠르고 안정적이며 기밀성을 유지하는 범용 연결 및 오프체인 계산 smart contracts. 우리 계획의 기초는 분산형 Oracle 네트워크라고 부르는 것입니다. 줄여서 DONs입니다. DON은 Chainlink 위원회에서 유지 관리하는 네트워크입니다. 노드. 선택한 oracle 기능을 무제한으로 지원합니다. 위원회에 의한 배치. 따라서 DON은 강력한 추상화 계층 역할을 합니다. 광범위한 오프체인 리소스에 대한 smart contracts에 대한 인터페이스를 제공하고 DON 자체 내 효율적이면서도 분산된 오프체인 컴퓨팅 리소스입니다. DONs를 발판으로 Chainlink은 7개 분야의 발전에 집중할 계획입니다. 주요 분야: • 하이브리드 smart contracts: 온체인을 안전하게 구성하여 기존 smart contract 기능을 강화하기 위한 강력하고 일반적인 프레임워크 제공 그리고 오프체인 컴퓨팅 리소스를 우리가 하이브리드 smart contract라고 부르는 것으로 만들었습니다. • 복잡성 추상화: 개발자와 사용자에게 간단한 설명을 제공합니다. 기능을 사용하면 복잡한 기본 기능에 익숙할 필요가 없습니다. 프로토콜 및 시스템 경계. • 확장: oracle 서비스가 지연 시간 및 처리량을 달성하도록 보장 고성능 분산 시스템이 요구하는 것입니다. • 기밀성: blockchains'를 결합한 차세대 시스템 구현 민감한 정보에 대한 강력한 새 기밀 보호 기능을 갖춘 타고난 투명성 데이터. • 거래에 대한 주문 공정성: 다양한 방식으로 거래 순서 지원 최종 사용자에게 공정하고 선행 공격 및 기타 공격을 방지합니다. 봇과 착취적인 광부. • 신뢰 최소화: 매우 신뢰할 수 있는 지원 계층 생성 smart contracts 및 기타 oracle 종속 시스템은 분산화, 높은 보안 수준의 강력한 고정 blockchains, 암호화를 통해 기술 및 암호화폐 경제 보장. • 인센티브 기반(암호경제적) 보안: DONs의 노드가 자원이 풍부한 적들 앞에서도 안정적이고 올바르게 행동할 수 있는 강력한 경제적 인센티브를 갖도록 하는 메커니즘을 엄격하게 설계하고 강력하게 배포합니다. 우리는 Chainlink 커뮤니티의 예비적이고 지속적인 혁신을 제시합니다. 각 영역에서 확장되고 점점 더 커지는 그림을 제공합니다. 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.
소개
블록체인 oracle은 오늘날 한 가지 목표를 가진 분산형 서비스로 간주되는 경우가 많습니다. 오프체인 리소스의 데이터를 blockchains로 전달합니다. 짧은 걸음이지만, 데이터 전달부터 컴퓨팅, 저장, 양방향 전송까지. 이러한 관찰은 oracles의 기능에 대한 훨씬 더 광범위한 개념을 정당화합니다. 너무도 smart contracts의 증가하는 서비스 요구 사항을 수행하고 점점 더 다각화됩니다. oracle 네트워크에 의존하는 기술. 간단히 말해서, oracle는 다음을 수행할 수 있고 필요합니다. 온체인 시스템과 오프체인 시스템 간의 범용, 양방향, 컴퓨팅 지원 인터페이스입니다. blockchain 생태계에서 오라클의 역할은 smart contract의 성능, 기능 및 상호 운용성을 다양한 산업에 새로운 신뢰 모델과 투명성을 제공합니다. 이러한 변화는 하이브리드 smart contract의 사용 확대를 통해 이루어질 것입니다. blockchains의 특별한 속성은 다음과 같은 오프체인 시스템의 고유한 기능을 갖추고 있습니다. oracle 네트워크를 구축하여 온체인 시스템보다 훨씬 더 큰 도달 범위와 성능을 달성합니다. 고립되어 있습니다. 이 백서에서 우리는 원래 Chainlink 백서 [98]의 초기 개념을 뛰어넘는 Chainlink의 진화인 Chainlink 2.0에 대한 비전을 명확히 설명합니다. 우리는 oracle 네트워크의 역할이 점점 더 확장될 것으로 예상합니다. 하이브리드를 위한 빠르고 안정적이며 기밀성을 유지하는 범용 연결 및 계산을 제공하여 기존 및 새로운 blockchain을 보완하고 향상합니다. smart contracts. 우리는 oracle 네트워크가 유틸리티로 발전할 것이라고 믿습니다. 높은 무결성의 blockchain급 데이터를 blockchain 이상의 시스템으로 내보내는 데 사용됩니다. 생태계. 오늘날 다양한 개체 집합이 운영하는 Chainlink 노드는 oracle 네트워크에 모여 보고서라고 알려진 데이터를 smart contract에 전달합니다. 우리는 그러한 것을 볼 수 있습니다 oracle 노드는 고전적 합의 blockchain [72]과 유사한 위원회로서, 그러나 독립된 기능을 제공하기보다는 기존 blockchain을 지원하는 것이 목표입니다. 검증 가능한 무작위 함수(VRF) 및 오프체인 보고 (OCR), Chainlink은(는) smart contract에 필요한 계산 리소스를 제공하기 위한 범용 프레임워크 및 인프라로 이미 발전하고 있습니다. 고급 기능. Chainlink 2.0에 대한 우리 계획의 기초는 우리가 분산형 Oracle이라고 부르는 것입니다. 네트워크, 줄여서 DON입니다. "oracle 네트워크"라는 용어를 도입한 이후 원본 Chainlink 백서 [98], oracles는 더욱 풍부한 기능과 적용 범위가 넓습니다. 본 논문에서는 다음과 같은 용어에 대한 새로운 정의를 제공합니다. Chainlink 생태계에 대한 미래 비전을 소개합니다. 이 보기에서 DON은 네트워크입니다. Chainlink 노드로 구성된 위원회에서 유지관리합니다. 합의 프로토콜에 뿌리를 두고 있으며, 배포를 위해 선택한 oracle 기능을 무제한으로 지원합니다. 위원회. 따라서 DON는 blockchain 추상화 계층 역할을 하여 인터페이스를 제공합니다. smart contracts 및 기타 시스템 모두에 대한 오프체인 리소스에 연결됩니다. 그것은 또한 제공합니다 매우 효율적이면서도 분산화된 오프체인 컴퓨팅 리소스에 액세스할 수 있습니다. 일반적으로, DON은 메인 체인에서의 작업을 지원합니다. 그 목표는 안전하고 유연한 서비스를 제공하는 것입니다.온체인 및 오프체인 계산을 결합한 하이브리드 smart contracts 외부 리소스에 대한 연결. 우리는 DONs에서 위원회를 사용하더라도 Chainlink 자체가 본질적으로 허가가 없는 상태로 유지됩니다. DONs는 무허가형의 기초 역할을 합니다. 노드가 함께 모여 사용자 정의 oracle 네트워크를 구현할 수 있는 프레임워크 허가되거나 허가되지 않을 수 있는 노드 포함에 대한 자체 체제. DONs를 기반으로 Chainlink 2.0에서는 7개 분야의 발전에 집중할 계획입니다. 핵심 영역: 하이브리드 smart contracts, 복잡성 추상화, 확장성, 기밀성, 거래 주문 공정성, 신뢰 최소화 및 인센티브 기반(암호경제적) 보안. 이 백서 소개에서는 분산화의 개요를 제시합니다. 섹션 1.1의 Oracle Networks와 섹션 1.2의 7가지 주요 혁신 영역. 섹션 1.3에서 이 문서의 나머지 부분의 구성을 설명합니다. 1.1 분산형 오라클 네트워크 분산형 Oracle 네트워크는 기능을 향상하고 확장하도록 설계되었습니다. 대상 blockchain 또는 다음 기능을 통한 메인 체인의 smart contract 기본적으로 사용할 수 없습니다. 그들은 다음의 세 가지 기본 리소스를 제공하여 이를 수행합니다. 컴퓨팅 시스템: 네트워킹, 저장 및 계산. DON은(는) 다음을 제공하는 것을 목표로 합니다. 강력한 기밀성, 무결성 및 가용성 속성을 지닌 이러한 리소스는1 책임감도 그렇고. DONs는 특정 목적을 달성하기 위해 협력하는 oracle 노드 위원회로 구성됩니다. 직업을 갖거나 지속적인 서비스를 제공하기 위해 장기적인 관계 구축을 선택합니다. 클라이언트에게. DON은 blockchain에 구애받지 않는 방식으로 설계되었습니다. 그들은 다음과 같은 역할을 할 것을 약속합니다. 애플리케이션 개발자가 오프체인 지원을 생성할 수 있는 강력하고 유연한 도구입니다. 지원되는 메인 체인의 smart contracts. DON의 기능을 실현하는 두 가지 유형의 기능: 실행 파일 및 어댑터. 실행 파일은 DON에서 분산 방식으로 지속적으로 실행되는 프로그램입니다. 메인체인 자산을 직접 저장하지는 않지만 고성능 및 기밀 수행 능력을 포함한 중요한 이점이 있습니다. 계산. 실행 파일은 DON에서 자율적으로 실행되며 결정론적 수행을 수행합니다. 운영. DON을 외부 리소스에 연결하는 어댑터와 함께 작동합니다. 실행 파일에 의해 호출될 수 있습니다. DONs에 대해 우리가 구상한 어댑터는 오늘 Chainlink의 외부 어댑터 일반화. 기존 어댑터 중 일반적으로 데이터 소스에서만 데이터를 가져오며 어댑터는 양방향으로 작동할 수 있습니다. 안으로 DONs, 그들은 추가로 DON 노드의 공동 계산을 활용하여 다음을 달성할 수 있습니다. 개인 정보 보호 소비를 위한 보고서 암호화와 같은 추가 기능 실행 파일. DON의 기본 작동에 대한 이해를 제공하기 위해 그림 1은 개념적으로 DON은(는) blockchain에 보고서를 보내는 데 사용되어 기존의 oracle 기능을 달성할 수 있습니다. DONs는 그 이상의 많은 추가 기능을 제공할 수 있습니다. 1정보 보안의 "CIA 3대 요소" [123, p. 26, §2.3.5].Chainlink의 기존 네트워크. 예를 들어, 그림 1의 일반적인 구조 내에서, 실행 파일은 가져온 자산 가격 데이터를 DON에 기록할 수 있습니다. 예를 들어 보고서의 후행 평균을 계산합니다. 그림 1: 분산형 Oracle 네트워크가 기본 oracle 기능(예: 오프체인 데이터를 계약서에 전달)을 실현하는 방법을 예로 보여주는 개념적 그림. 안 실행 파일은 어댑터를 사용하여 오프체인 데이터를 가져와서 계산하고 출력을 보냅니다. 다른 어댑터를 통해 대상 blockchain에 연결합니다. (어댑터는 DON, 작은 파란색 상자로 표시됩니다. 화살표는 이에 대한 데이터 흐름 방향을 나타냅니다. 특정 예.) 실행 파일은 추가로 로컬 DON을 읽고 쓸 수 있습니다. 상태를 유지하고/하거나 다른 실행 파일과 통신하기 위한 저장소입니다. 여기에 제시된 DONs의 유연한 네트워킹, 계산 및 저장 기능을 통해 다양한 새로운 기능을 사용할 수 있습니다. 응용 프로그램. DONs의 주요 이점은 새로운 blockchain 서비스를 부트스트랩하는 기능입니다. DONs 기존 oracle 네트워크가 서비스 애플리케이션을 신속하게 구축할 수 있는 수단입니다. 이를 위해서는 오늘날 특수 목적으로 구축된 네트워크를 구축해야 합니다. 우리는 여러 가지를 제공합니다 섹션 4에 그러한 적용 사례가 나와 있습니다. 섹션 3에서는 DON에 대한 자세한 내용을 제공하고 해당 기능을 설명합니다. 개발자와 사용자에게 제공되는 인터페이스의 용어입니다. 1.2 7가지 주요 설계 목표 여기서는 위에서 열거한 7가지 핵심 초점을 간략하게 검토해 보겠습니다. Chainlink, 즉:하이브리드 smart contracts: Chainlink에 대한 우리 비전의 핵심은 보안이라는 아이디어입니다. smart contracts에서 온체인 및 오프체인 구성 요소를 결합합니다. 우리는 계약을 참조 이 아이디어를 하이브리드 smart contract 또는 하이브리드 계약으로 실현합니다.2 블록체인은 분산형 서비스에서 두 가지 중요한 역할을 수행하고 있으며 앞으로도 계속 그럴 것입니다. 생태계: 둘 다 암호화폐 소유권이 표현되는 장소입니다. 분산형 서비스를 위한 강력한 기반입니다. 따라서 스마트 계약은 체인에서 표현되거나 실행되어야 하지만 온체인 기능은 심각하게 제한됩니다. 순전히 온체인 계약 코드는 느리고, 비용이 많이 들고, 고립되어 있어 실제 세계의 이점을 누릴 수 없습니다. 다양한 형태의 기밀 계산, (의사)무작위성 생성 등 체인에서 본질적으로 달성할 수 없는 다양한 기능과 데이터 광부 / validator 조작 등에 대한 반대 따라서 smart contracts가 잠재력을 최대한 실현하려면 smart contracts가 필요합니다. 온체인 부분(일반적으로 SC로 표시)의 두 부분으로 구성됩니다. 그리고 DON에서 실행되는 실행 파일인 오프체인 부분(일반적으로 실행). 목표는 다음과 같은 온체인 기능의 안전한 구성을 달성하는 것입니다. DONs가 제공하고자 하는 다양한 오프체인 서비스. 두 부분이 함께 하이브리드 계약을 맺습니다. 우리는 그림 2에 개념적으로 아이디어를 제시합니다. 이미 오늘, Chainlink 데이터 피드 및 VRF와 같은 서비스3는 다른 방법으로는 달성할 수 없는 기능을 제공합니다. smart contract 애플리케이션은 DeFi에서 공정하게 생성된 NFT에 이르기까지 분산형 보험에 이르기까지 보다 일반적인 프레임워크를 향한 첫 번째 단계입니다. Chainlink 서비스로 이 백서의 비전에 따라 더 많은 성능을 확장하고 성장시킵니다. 모든 blockchain에 걸쳐 smart contract 시스템의 성능을 발휘하게 됩니다. 이 백서에 있는 다른 6가지 주요 초점은 서비스에서 작동하는 것으로 볼 수 있습니다. 첫째, 하이브리드 계약 중 가장 중요한 것 중 하나입니다. 이러한 초점에는 가시적인 제거가 포함됩니다. 하이브리드 계약으로 인한 복잡성으로 인해 추가적인 오프체인 서비스가 생성됩니다. 더욱 강력한 하이브리드 계약을 구축하고, 신뢰 최소화의 경우 하이브리드 계약을 통해 달성된 보안 속성을 강화합니다. 우리는 아이디어를 떠난다 논문의 대부분에 걸쳐 암묵적으로 혼합 계약이 존재하지만, DON이 포함된 MAINCHAIN 로직은 하이브리드 계약으로 볼 수 있습니다. 복잡성 추상화: DON은 분산화를 사용하도록 설계되었습니다. 종종 복잡한 기계를 추상화하여 개발자와 사용자가 쉽게 사용할 수 있는 시스템 DONs의 강력하고 유연한 서비스를 지원합니다. 기존 Chainlink 서비스 이미 이 기능이 있습니다. 예를 들어, 오늘날 Chainlink의 데이터 피드는 개발자가 프로토콜 수준의 세부 사항에 대해 걱정할 필요가 없는 온체인 인터페이스를 제공합니다. 2온체인/오프체인 계약 구성에 대한 아이디어는 이전에 다양한 제약 조건에서 나타났습니다. 양식(예: 레이어 2 시스템, TEE 기반 blockchains [80] 등)을 지원하고 일반화하는 것이 우리의 목표입니다. 이러한 접근 방식을 통해 오프체인 데이터 액세스 및 기타 키를 포괄할 수 있는지 확인합니다. oracle 서비스. 3Chainlink 서비스는 다음을 통해 제공되는 다양한 분산형 서비스와 기능으로 구성됩니다. 네트워크. 다양한 oracle 네트워크로 구성된 수많은 노드 운영자가 제공합니다. 생태계 전반에 걸쳐.그림 2: 온체인/오프체인 계약 구성을 나타내는 개념적 그림. 에이 하이브리드 smart contract 3⃝은 두 가지 보완적인 구성 요소, 즉 온체인으로 구성됩니다. blockchain에 상주하는 구성 요소 SC 1⃝ 및 오프 체인 구성 요소 exec 2⃝ DON에서 실행됩니다. DON은 두 구성요소 사이의 브리지 역할도 합니다. 웹 서비스 등 오프체인 리소스와 하이브리드 컨트랙트를 연결하는 등 blockchains, 분산형 저장소 등 분산된 노드 세트. DONs는 Chainlink이 개발자에게 추상화 계층을 제공할 수 있는 서비스 범위 높은 수준의 서비스를 위한 간소화된 인터페이스를 제공합니다. 이 접근 방식을 강조하는 몇 가지 응용 사례를 섹션 4에 제시합니다. 예를 들어 우리는 DONs를 보안 미들웨어의 한 형태로 사용하는 기업을 구상합니다. 레거시 시스템을 blockchain에 연결하세요. (섹션 4.2 참조) DON을 사용하면 일반적인 blockchain 역학(수수료, 재구성 등)의 복잡성이 추상화됩니다. 그것은 또한 특정 blockchain의 기능을 추상화하여 기업이 기존 시스템을 계속 확장되는 blockchain 시스템 어레이에 연결할 수 있도록 합니다. 이러한 시스템 또는 더 일반적으로는 분산형 시스템 개발에 대한 전문 지식이 필요합니다. 궁극적으로 우리의 목표는 Chainlink에 의해 달성된 추상화 수준을 높이는 것입니다. 우리가 분산형 메타레이어라고 부르는 것을 구현하는 지점까지 말이죠. 그러한 층 모든 계층의 개발자에 대한 온체인/오프체인 구분을 추상화합니다. 및 DApp 사용자를 통해 분산형 서비스를 원활하게 생성하고 사용할 수 있습니다.개발 프로세스를 단순화하기 위해 개발자는 메타 레이어의 DApp 기능을 통합 머신 모델의 가상 애플리케이션으로 지정할 수 있습니다. 그들은 할 수 있었다 그런 다음 분산형 금속층 컴파일러를 사용하여 DApp을 자동으로 인스턴스화합니다. blockchains, DONs에 걸쳐 상호 운용되는 분산 기능 세트 및 외부 서비스. (이러한 외부 서비스 중 하나는 엔터프라이즈 시스템일 수 있으므로 레거시 엔터프라이즈 시스템과 관련된 애플리케이션에 메타레이어를 유용하게 만듭니다.) 컴파일은 최신 컴파일러 및 소프트웨어 개발 키트(SDK)와 유사합니다. 이기종 하드웨어의 잠재력을 최대한 활용하는 일반 프로그래머 지원 범용 CPU와 GPU와 같은 특수 하드웨어로 구성된 아키텍처, 기계 학습 가속기 또는 신뢰할 수 있는 엔클레이브. 그림 3은 이 아이디어를 개념적 수준으로 제시합니다. 하이브리드 smart contract는 이 비전과 메타 계약이라고 부르는 개념을 향한 첫 번째 단계입니다. 메타 계약은 분산형 시스템에 코딩된 애플리케이션입니다. 메타레이어는 온체인 로직(smart contracts)뿐만 아니라 오프체인 계산 및 다양한 blockchains와 기존 오프체인 간의 연결을 암시적으로 포함합니다. 서비스. 언어 및 컴파일러 지원의 필요성을 고려하여 새로운 보안 모델 및 서로 다른 기술의 개념적, 기술적 조화는 실현되지만, 진정한 분산형 금속층을 구축하는 것은 우리가 오랫동안 열망해 온 야심찬 목표입니다. 시간 지평선. 그럼에도 불구하고 읽는 동안 명심해야 할 유용한 이상적인 모델입니다. 이 문서는 여기에 자세히 설명되어 있지 않지만 향후 작업에서 집중할 계획입니다. Chainlink. 스케일링: 진화하는 디자인에서 가장 중요한 목표는 Chainlink 네트워크는 blockchain 생태계의 증가하는 확장 요구 사항을 충족합니다. 기존 무허가형 환경에서는 네트워크 정체가 반복적으로 문제가 되면서 blockchains [86], 새롭고 더 성능이 뛰어난 blockchain 디자인이 사용되기 시작했습니다. 예를 들어 [103, 120, 203]과 보완적인 레이어 2 스케일링 기술(예: [5, 12, 121, 141, 169, 186, 187]. Oracle 서비스는 지연 시간과 처리량을 달성해야 합니다. 온체인 수수료를 최소화하면서 이러한 시스템의 성능 요구 사항을 충족합니다. (예: 가스 비용) 계약 운영자와 일반 사용자 모두에게 적용됩니다. DONs, Chainlink 사용 기능은 더 나아가 순수한 웹 기반 시스템에 충분히 높은 성능을 제공하는 것을 목표로 합니다. DONs는 blockchains와 결합된 빠른 위원회 기반 또는 무허가 합의 프로토콜을 사용하여 많은 성능 향상을 얻습니다. 그들은 지원합니다. 우리는 서로 다른 구성을 가진 많은 DON이 병렬로 실행될 것으로 예상합니다. 다양한 DApp과 사용자는 기본 합의 선택에서 트레이드오프를 탐색할 수 있습니다. 그들의 신청 요구 사항에 따라. DON은 사실상 레이어 2 기술로 볼 수 있습니다. 우리는 그 중에서 다른 서비스에서는 DONs가 TEF(Transaction Execution Framework)를 지원합니다. DON 및 oracle을 다른 고성능 제품과 효율적으로 통합할 수 있습니다. 레이어 2 시스템(예: rollups, 달성하기 위해 오프체인 트랜잭션을 번들로 묶는 시스템) 성능 개선. 섹션 6에서 TEF를 소개합니다.
그림 3: 분산형 금속층의 이상적인 구현을 보여주는 개념적 그림. 에 대한 개발의 용이성을 위해 개발자는 분홍색으로 강조된 DApp을 가상 애플리케이션으로 지정합니다. 통합 기계 모델에 적용. 분산형 메탈레이어 컴파일러는 해당 상호 운용 기능을 자동으로 생성합니다: smart contracts(표시됨) SC별), DONs의 논리(exec로 표시됨), 대상 외부 서비스에 연결하는 어댑터 등은 노란색으로 강조 표시됩니다. 그림 4는 DONs가 blockchain(smart contract) 스케일링을 어떻게 개선하는지 개념적으로 보여줍니다. 거래 및 oracle-보고서 처리를 온체인이 아닌 오프체인에 집중함으로써 체인. 계산의 주요 위치가 바뀌면 트랜잭션 대기 시간이 줄어들고 거래 처리량을 높이는 동시에 수수료를 부과합니다. 기밀성: 블록체인은 smart contracts 및 그들이 실현하는 애플리케이션에 대해 전례 없는 투명성을 제공합니다. 그러나 투명성과 기밀성 사이에는 기본적인 긴장이 있습니다. 예를 들어, 오늘날 사용자의 분산형 교환 거래는그림 4: 분산형 Oracle 네트워크가 어떻게 성능을 향상시키는지를 보여주는 개념적 그림 blockchain 활성화된 smart contract의 크기 조정. 그림 A ⃝는 기존의 oracle을 보여줍니다. 건축. 거래는 oracle 보고서와 마찬가지로 blockchain로 직접 전송됩니다. 따라서 노란색으로 강조 표시된 blockchain은 트랜잭션 처리의 주요 위치입니다. 그림 B⃝는 blockchain에 대한 계약을 지원하기 위해 DON을 사용하는 것을 보여줍니다. A DON 실행 파일은 외부 시스템의 데이터와 함께 트랜잭션을 처리하고 전달합니다. 결과(예: 번들 트랜잭션 또는 트랜잭션 효과로 인한 계약 상태 변경)를 blockchain에 보냅니다. 따라서 노란색으로 강조 표시된 DON가 주요 트랜잭션 처리를 위한 위치입니다. 활동은 체인에 기록되므로 교환 활동을 쉽게 모니터링할 수 있을 뿐만 아니라 사용자의 금융 거래를 공개적으로 표시합니다. 마찬가지로 데이터가 스마트로 전달됩니다. 계약은 체인에 남아 있습니다. 이를 통해 이러한 데이터를 편리하게 감사할 수 있지만 다음과 같은 역할을 합니다. smart contract에 민감하거나 민감한 데이터를 제공하려는 데이터 제공자에게는 방해가 됩니다. 독점 데이터. 우리는 oracle 네트워크가 차세대 촉매 역할을 할 것이라고 믿습니다. blockchains의 타고난 투명성과 새로운 기밀 보호 기능을 결합한 시스템입니다. 이 문서에서는 세 가지 주요 접근 방식을 사용하여 이를 수행하는 방법을 보여줍니다. • 기밀 유지 어댑터: 계획된 배포가 포함된 두 가지 기술 Chainlink의 네트워크 DECO [234] 및 Town Crier [233]에서 oracle 노드를 활성화합니다. 사용자 개인정보와 데이터를 보호하는 방식으로 오프체인 시스템에서 데이터를 검색합니다. 기밀성. 이는 DONs용 어댑터 설계에서 중요한 역할을 합니다. (이 두 기술에 대한 자세한 내용은 섹션 3.6.2를 참조하세요.) • 기밀 계산: DONs는 blockchains에 의존하지 않도록 자신의 계산을 숨길 수 있습니다. 안전한 다자간 계산 및/또는 신뢰할 수 있는 실행 환경을 사용하면 DON 노드에서 더 강력한 기밀성이 가능합니다. 자신이 볼 수 없는 데이터에 대해 계산합니다.
• 기밀 레이어 2 시스템 지원: TEF는 다양한 레이어 2 시스템을 지원하도록 설계되었으며, 그 중 다수는 영지식 증명을 사용하여 다음을 제공합니다. 다양한 형태의 거래 기밀성. 섹션 3에서 이러한 접근 방식을 논의합니다(섹션 6, 부록 B.1 및 부록 B.2의 추가 세부정보 포함). 그림 5는 기밀 유지 어댑터를 통해 민감한 데이터가 외부 소스에서 smart contract로 어떻게 흐를 수 있는지에 대한 개념적 보기를 제공합니다. DON의 기밀 계산. 그림 5: DON의 기밀 유지 작업에 대한 개념 다이어그램 민감한 데이터(노란색으로 강조 표시됨) 웹의 민감한 소스 데이터(검은색 원) 서버는 기밀 유지 어댑터(파란색, 이중 화살표 선)를 사용하여 DON로 추출됩니다. DON는 이러한 어댑터로부터 파생된 데이터(빈 원)를 수신합니다. 민감한 소스에 기능이나 비밀 공유 등을 적용한 결과 데이터. DON의 실행 파일은 파생된 데이터에 기밀 계산을 적용할 수 있습니다. 보고서(이중 원)를 구성하여 어댑터를 통해 blockchain로 보냅니다. 우리는 기밀 데이터를 처리하는 강력한 도구가 전체를 열어줄 것이라고 믿습니다. 응용 범위. 그 중에는 민간 분산형(및 중앙집중형) 금융, 분산형 신원, 신용 기반 온체인 대출, 보다 효율적이고 섹션 4에서 논의한 바와 같이 사용자 친화적인 고객 파악 및 인증 프로토콜. 거래의 주문 공정성: 오늘의 blockchain 디자인에는 약간 더러운 부분이 있습니다. 공개 비밀: 일시적으로 중앙 집중화되어 있습니다. 광부와 validators는 거래를 주문할 수 있습니다.그들이 선택한 행동. 거래 순서는 다음과 같이 사용자가 조작할 수도 있습니다. 그들이 지불하는 네트워크 수수료의 함수(예: Ethereum의 가스 가격) 및 일부 빠른 네트워크 연결을 활용하여 확장합니다. 그러한 조작은 다음과 같은 경우에 발생할 수 있습니다. 예를 들어, 채굴자와 같은 전략적 행위자가 참여하는 선행 실행(front-running) 형태를 취합니다. 사용자의 거래를 관찰하고 자신의 악용 거래를 이전 거래에 삽입합니다. 동일한 블록에 위치 - 사용자 거래에 대한 사전 지식을 활용하여 사용자로부터 효과적으로 돈을 훔칩니다. 예를 들어, 봇이 구매 주문을 할 수 있습니다. 사용자 앞에. 그러면 이는 다음으로 인한 자산 가격 상승을 활용할 수 있습니다. 사용자의 거래. 일반 사용자에게 해를 끼치는 일부 봇의 선행 실행(고빈도와 유사) 월스트리트에서의 거래는 이미 널리 퍼져 있으며 관련 내용이 잘 문서화되어 있습니다 [90] 백러닝 [159] 및 [195]을 모방한 자동 트랜잭션과 같은 공격. 채굴자들의 주문 착취를 체계화하려는 제안도 최근에 표면화되었습니다([110]). rollups와 같은 레이어 2 기술은 문제를 해결하지 못하고 단지 재중앙화만 합니다. 주문하여 rollup을 생성하는 개체의 손에 넘겨줍니다. 우리의 목표 중 하나는 Chainlink에 Fair Sequencing이라는 서비스를 도입하는 것입니다. 서비스 (FSS) [137]. FSS는 smart contract 디자이너가 공정한 주문을 보장하도록 돕습니다. 트랜잭션을 방지하고 사용자 트랜잭션은 물론 oracle 보고서 전송과 같은 기타 유형의 트랜잭션에 대한 선행 실행, 역실행 및 관련 공격을 방지합니다. FSS [144]에 도입된 엄격하고 일시적인 질서 공정성 개념과 같은 아이디어를 DON에서 구현할 수 있습니다. 부수적인 이점으로 FSS는 사용자의 네트워크 수준을 낮출 수도 있습니다. 수수료(예: 가스비). 간단히 말해서, FSS에서 트랜잭션은 대상 smart contract에 직접 전파되지 않고 DON을 통해 전달됩니다. DON은 거래를 주문한 다음 전달합니다. 계약에 그들을. 그림 6: FSS가 어떻게 유익한지에 대한 예. 그림A ⃝ 채굴자가 이를 활용하는 방법을 보여줍니다. 거래를 주문할 수 있는 중앙 집중식 전력, 한 쌍의 거래를 교환할 수 있음: 거래 1⃝ 2⃝ 이전에 도착하지만 광부는 대신 2⃝ 이후에 시퀀스를 지정합니다. 대조적으로, 그림 B⃝는 DON이 DON 노드 사이에서 주문 프로세스를 분산시키는 방법. 만약 정족수가 정직한 노드는 2⃝ 이전에 1⃝을 수신하고, FSS는 체인에서 1⃝이 2⃝ 이전에 나타나도록 합니다. 계약에 따라 시행 가능한 일련 번호를 첨부하여 채굴자 재정렬을 방지합니다. 그림 6은 표준 채굴과 FSS를 비교합니다. 이는 표준 채굴이 어떻게 이루어지는지 보여줍니다.거래 주문 프로세스는 채굴자에게 중앙 집중화되어 있으므로 도착과 관련하여 한 쌍의 거래를 재정렬하는 등의 조작 시간. 대조적으로, FSS에서는 프로세스가 DON 노드 간에 분산되어 있습니다. 가정 정직한 노드의 정족수인 FSS는 임시 순서 지정과 같은 정책을 시행하는 데 도움을 줍니다. 거래를 통해 채굴자 및 기타 주체의 조작 기회를 줄입니다. 또한, 사용자들은 가스 가격을 기준으로 우선 주문 경쟁을 할 필요가 없으므로, 상대적으로 낮은 가스 가격을 지불할 수 있습니다(DON의 거래는 일괄 처리될 수 있습니다). 가스 절약을 위해). 신뢰 최소화: DONs 설계의 일반적인 목표는 smart contracts 및 기타 oracle 종속 시스템에 대한 신뢰할 수 있는 지원 계층 분산화, 암호화 도구 및 암호화 경제 보장을 통해. DON 자체는 분산되어 있으며 사용자는 사용 가능한 DON 중에서 선택할 수 있습니다. 추가 DON을 운영하거나 생성하려는 메인 체인을 지원합니다. 그들이 신뢰하는 노드 위원회를 통해. 그러나 일부 애플리케이션, 특히 smart contracts, Chainlink 사용자의 경우 DON이 지원하는 메인 체인을 더 신뢰할 수 있는 것으로 취급하는 신뢰 모델을 선호합니다. DON 자체보다. 그러한 사용자를 위해 우리는 이미 Chainlink 네트워크의 아키텍처 계약을 가능하게 하는 다양한 메커니즘 DONs가 제공하는 보안 보증을 강화하기 위해 메인 체인에 동시에 데이터 소스가 손상될 가능성에 대비한 보호 조치도 시행합니다. DON이 데이터를 얻는 웹 서버와 같은 것입니다. 우리는 섹션 7에서 이러한 메커니즘을 설명합니다. 이는 다섯 가지 주요 제목으로 분류됩니다. • 데이터 소스 인증: 데이터 공급자가 디지털 서명을 할 수 있게 해주는 도구 데이터를 수집하여 원산지와 원산지 간의 관리 사슬을 강화합니다. 의존 계약. • DON 소수 보고서: DON 노드의 소수 하위 집합에서 발행한 플래그입니다. DON에서 대부분의 불법 행위를 관찰했습니다. • 가드레일: 비정상적인 조건을 감지하고 일시 중지하는 메인 체인의 로직 또는 계약 실행을 중단합니다(또는 다른 수정 조치를 호출합니다). • 신뢰가 최소화된 거버넌스: 점진적인 릴리스 업데이트를 사용하여 커뮤니티 검사를 촉진하고 분산형 긴급 개입을 통해 신속한 조치를 취합니다. 시스템 장애에 대한 대응. • 분산형 엔터티 인증: 공개 키 인프라(PKI)를 사용하여 다음을 수행합니다. Chainlink 네트워크의 엔터티를 식별합니다. 그림 7은 신뢰 최소화 목표의 개념적 개략도를 나타냅니다. 인센티브 기반(암호경제적) 보안: oracle 노드 전반에 걸쳐 보고서 생성을 분산화하면 일부 노드가 손상된 경우에도 보안을 보장할 수 있습니다.
그림 7: Chainlink의 신뢰 최소화 목표에 대한 개념적 묘사 DON 및 웹과 같은 데이터 소스의 올바른 동작에 대한 사용자의 요구를 최소화합니다. 서버. 그림의 노란색 강조 표시는 신뢰 최소화 위치를 나타냅니다: DON 및 개별 또는 소수의 웹 서버 세트. 분홍색 강조 표시는 시스템 구성 요소를 나타냅니다. 가정에 의해 매우 신뢰할 수 있는 것: blockchain에 대한 계약 및 대다수 웹 서버의 수, 즉 웹 서버 전체를 의미합니다. 하지만 마찬가지로 중요한 것은 노드가 올바르게 행동할 수 있는 재정적 인센티브를 갖도록 보장하는 것입니다. 스테이킹, 즉 노드가 LINK 예치금을 제공하고 슬래싱하도록 요구 (압수) 잘못된 행동이 있을 경우 이러한 예금은 Chainlink에서 핵심적인 역할을 할 것입니다. 이미 다수의 blockchain에서 사용되고 있는 중요한 인센티브 디자인입니다. 예를 들어 [81, 103, 120, 204]. 그러나 Chainlink에 스테이킹하는 것은 독립 실행형의 staking과 매우 다르게 보입니다. blockchains. blockchains에 스테이킹하는 것은 합의에 대한 공격을 방지하는 것을 목표로 합니다. 그것은 Chainlink의 다른 목표: 올바른 oracle 보고서를 적시에 전달하는 것입니다. oracle 네트워크를 위해 잘 설계된 staking 시스템은 뇌물 수수와 같은 공격을 렌더링해야 합니다. 목표가 높은 smart contract인 경우에도 적에게는 이익이 되지 않습니다. 금전적 가치. 본 논문에서는 세 가지 핵심을 통해 Chainlink의 staking에 대한 일반적인 접근 방식을 제시합니다. 혁신:1. 기존에서 간과된 공격을 포괄하는 강력한 적대 모델 접근합니다. 한 가지 예는 우리가 장래 뇌물 수수라고 부르는 것입니다. 이것은 다음과 같은 형태입니다. 어떤 노드가 조건부로 뇌물을 받는지 결정하는 뇌물 수수. staking 메커니즘이 선택한 노드에 미리 보장된 뇌물을 제공합니다. 특정 역할에 대해 무작위입니다(예: 보고서 심사 실행). 2. 초선형 staking 영향, 즉 성공하려면 적의 예산이 모든 oracle의 예금을 합친 것보다 $B 더 커야 함을 비공식적으로 의미합니다. 노드. 보다 정확하게는 n의 함수로서 \(B(n) ≫\)dn이 각각 고정 입금액 $d를 갖는 n oracle 노드의 네트워크(보다 공식적으로는 \(B(n) is asymptotically larger in n than \)dn). 그림 8은 이 속성. 3. 우리가 고안한 인센티브 모델인 암시적 인센티브 프레임워크(IIF) 명시적으로 예치된 것 이상으로 경험적으로 측정 가능한 인센티브를 포함합니다. staking 노드의 향후 수수료 기회를 포함한 자금. IIF는 다음의 개념을 확장합니다. 명시적인 노드 예금 이상의 지분을 보유합니다. 그림 8: Chainlink staking의 초선형 스케일링을 설명하는 개념 다이어그램. 는 적에게 요구되는 뇌물 $B(n)는 예금을 합친 것보다 n에서 더 빠르게 증가합니다. 모든 oracle 노드의 $dn. 우리는 IIF와 초선형 staking 영향이 어떻게 함께 우리가 원하는 것을 유도하는지 보여줍니다. oracle 네트워크에 대한 경제적 안정의 선순환을 불러옵니다. 신규유저가 들어오면
Chainlink 노드를 실행하여 잠재적인 미래 수익을 늘리는 시스템입니다. 현재 및 미래 사용자의 경제적 보안 한계 비용이 감소합니다. 정권에서는 탄력적인 수요로 인해 비용이 감소하면 추가 사용자가 네트워크를 통해 지속적인 선순환을 통해 지속적으로 채택을 영속화합니다. 참고: 이 백서는 Chainlink의 발전을 위한 우리 비전의 중요한 요소를 간략하게 설명하지만 비공식적이며 자세한 기술 사양이 거의 포함되어 있지 않습니다. 우리는 추가 기능과 접근 방식이 발전함에 따라 집중적으로 기술 문서를 발표합니다. 또한, 제시된 비전의 많은 요소를 강조하는 것이 중요합니다. 여기(확장 개선, 기밀성 기술, FSS 등)가 가능하며 앞으로도 그렇게 될 것입니다. 고급 DON이 기본 기능이 되기 전에도 예비 형태로 배포되었습니다. Chainlink. 1.3 본 논문의 구성 우리는 섹션 2에서 보안 모델과 표기법을 제시하고 분산형 보안의 개요를 설명합니다. 섹션 3의 Oracle Network API. 섹션 4에서는 다음과 같은 여러 가지 예를 제시합니다. DONs가 매력적인 배포 플랫폼을 제공하는 애플리케이션입니다. 독자는 다음을 수행할 수 있습니다. 지금까지 읽으면 논문의 주요 개념 대부분을 배울 수 있습니다. 문서의 나머지 부분에는 더 자세한 내용이 포함되어 있습니다. 우리는 공정한 순서를 설명합니다 섹션 5의 서비스(FSS) 및 섹션 6의 거래 실행 프레임워크(TEF). 섹션 7에서는 신뢰 최소화에 대한 접근 방식을 설명합니다. 중요한 DON 배포 요구 사항, 즉 기능의 점진적 출시, 동적 원장 멤버십 및 섹션 8의 책임. 마지막으로 섹션 9에서 다음을 제공합니다. 인센티브 디자인에 대한 우리의 개발 접근 방식에 대한 개요입니다. 섹션 10에서 결론을 내린다. 이 문서의 개념에 익숙하지 않은 독자를 돕기 위해 우리는 부록 A에 용어집을 제공합니다. DON 인터페이스에 대한 자세한 내용을 제시합니다. 및 기능은 부록 B에 나와 있으며 부록 C에는 몇 가지 어댑터 예시가 나와 있습니다. 부록 D에서는 신뢰가 최소화된 데이터 소스에 대한 암호화 기본 요소를 설명합니다. 기능 서명이라는 인증을 도입하고 이산화된 기능 서명이라는 새로운 변형을 도입합니다. 우리는 위원회와 관련된 몇 가지 고려 사항을 논의합니다. 부록 F의 DON에 대한 선택
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.
보안 모델 및 목표
분산형 오라클 네트워크는 우리가 기대하는 독특한 분산 시스템입니다. 처음에는 반드시 그런 것은 아니지만 일반적으로 위원회 기반의 합의 프로토콜이며 oracle 노드 세트에 의해 실행됩니다. DON은 주로 설계되었습니다. oracle 보고서를 사용하여 메인 체인에서 smart contract의 기능을 강화합니다. 그러나 다른 비blockchain 시스템에 동일한 지원 서비스를 제공할 수 있으므로 특정 메인 체인과 연결될 필요가 없습니다.
따라서 우리가 고려하는 모델과 속성은 다음의 사용과 크게 무관합니다. DON의 특정 응용 프로그램. 2.1 현재 아키텍처 모델 오늘날 Chainlink은 단일 서비스가 아니라 오히려 뚜렷하고 독립적인 실행이 가능한 무허가 프레임워크 oracle 노드 [77]의 네트워크. 네트워크에는 이기종 노드 운영자 세트가 있으며 디자인. 또한 제공하는 서비스 유형이 다를 수 있습니다. 예를 들어 데이터 피드, 보유량 증명, 검증 가능한 무작위성 등이 포함됩니다. 기타 차이점에는 분산 정도, 네트워크 규모 등이 포함될 수 있습니다. 지원하는 고정된 값, 데이터 빈도와 같은 다양한 서비스 수준 매개변수 그리고 정확성. Chainlink의 무허가형 모델은 생태계의 성장을 장려합니다. 서비스 제공자는 지역사회에 가장 잘 제공할 수 있는 서비스를 전문적으로 제공합니다. 이 모델은 모델보다 사용자에게 더 낮은 비용과 더 높은 서비스 품질을 제공할 가능성이 높습니다. 모든 노드와 네트워크가 모든 범위의 서비스를 제공해야 하는 접근 방식 최소한의 서비스를 시스템 전체에 채택하는 것으로 쉽게 전환될 수 있습니다. 노드에서 사용할 수 있는 리소스의 공통 분모입니다. Chainlink이 Chainlink 2.0에서 DON 기반 디자인으로 발전함에 따라 우리는 계속해서 무허가형 개방형 프레임워크 모델을 지원하며, 사용자에게 전 세계적으로 가장 적합한 서비스를 선택할 수 있는 다양한 서비스 제공 특정 응용 프로그램 요구 사항이 있습니다. 2.2 합의된 가정 우리는 분산형 Oracle 네트워크라는 용어를 사용하여 다음의 모든 기능을 포괄합니다. 우리가 설명하는 oracle 시스템: oracle 노드가 유지 관리하는 데이터 구조와 그 위에 핵심 API가 계층화되어 있습니다. 우리는 기본 데이터를 의미하기 위해 L로 표시되는 원장(소문자)이라는 용어를 사용합니다. DON에 의해 유지 관리되고 제공되는 특정 서비스를 지원하는 데 사용되는 구조입니다. 우리는 DON 프레임워크가 L을 다음과 같은 독립 시스템으로 취급하지 않는다는 점을 강조합니다. a blockchain: 그 목적은 blockchain 및 기타 시스템을 지원하는 것입니다. 블록체인은, 물론 신뢰할 수 있는 원장을 실현하는 한 가지 방법이지만 다른 방법도 있습니다. 우리는 기대한다 DONs는 많은 경우 비잔틴 내결함성을 사용하여 기본 원장을 실현합니다. (BFT) 시스템은 Bitcoin [174]과 같은 blockchain보다 훨씬 이전 버전입니다. 우리는 BFT-유형 표기 및 속성은 편의를 위해 논문 전반에 걸쳐 표시됩니다. DONs는 무허가 합의 프로토콜을 사용하여 실현될 수 있음을 강조합니다. 개념적으로 원장 L은 데이터가 선형적으로 정렬되어 있는 게시판입니다. 우리는 일반적으로 원장에 다음과 같은 몇 가지 주요 속성이 있다고 봅니다. blockchains [115]. 원장은 다음과 같습니다. • 추가 전용: 데이터는 한 번 추가되면 제거하거나 수정할 수 없습니다.• 공개: 누구든지 내용을 읽을 수 있으며, 시간이 지나도 일관된 내용을 담고 있습니다. 모든 사용자의 보기.4 • 사용 가능: 원장은 승인된 작성자가 언제든지 쓸 수 있고 읽을 수 있습니다. 누구든지 시기적절하게. DON에 의해 실현되면 원장에서 대체 속성이 가능합니다. 위원회. 예를 들어, 원장 쓰기 액세스는 다음과 같이 특정 사용자로 제한될 수 있습니다. 일부 애플리케이션에 대한 읽기 액세스가 있을 수 있습니다. 즉, 원장은 정의된 대로 공개될 필요가 없습니다. 위. 마찬가지로 원장 규칙은 데이터 수정 또는 편집을 허용할 수 있습니다. 우리는 그렇지 않습니다 그러나 이 문서에서는 이러한 변형을 명시적으로 고려합니다. DON의 모듈식 설계는 다양한 최신 BFT을 지원할 수 있습니다. 프로토콜(예: Hotstuff[231]). 정확한 선택은 신뢰 가정과 oracle 노드 간의 네트워크 특성. DON은 원칙적으로 대안으로 사용할 수 있습니다. 지원하는 역할의 원장에 고성능 무허가 blockchain을 사용합니다. 동일하게 확장 가능한 레이어 2 또는 blockchain 시스템. 마찬가지로 하이브리드화도 가능합니다. DON은 원칙적으로 기존 노드에서 validator인 노드로 구성될 수 있습니다. blockchain(예: 실행을 위해 위원회가 선택되는 지분 증명 시스템) 거래(예: [8, 81, 120, 146, 204]). 이 특정 작동 모드에는 다음이 필요합니다. 노드는 이중 용도 방식으로 작동합니다. 즉, blockchain 노드와 DON로 작동합니다. 노드. (변경의 연속성을 보장하기 위한 기술에 대한 논의는 섹션 8.2를 참조하십시오. 무작위 위원회 선정에 대한 몇 가지 주의 사항은 위원회 및 부록 F를 참조하세요.) 실제로 최신 BFT 알고리즘에서 노드는 원장의 메시지에 디지털 방식으로 서명합니다. 편의상 L에는 관련 공개 키 pkL이 있고 그 내용은 다음과 같다고 가정합니다. 해당 개인 키로 서명됩니다. 이 일반적인 표기법은 다음 경우에도 적용됩니다. L의 데이터는 임계값 서명을 사용하여 서명됩니다.5 임계값 서명은 편리합니다. 멤버십이 변경된 경우에도 DON에 대한 지속적인 ID를 활성화하므로 그것을 실행하는 노드. (부록 B.1.3 참조) 따라서 skL은 비밀 공유라고 가정합니다. 일부 보안 매개변수 k에 대해 (k, n)-임계값 방식(예: k = 2f + 1) n = 3f + 1, 여기서 f는 잠재적으로 결함이 있는 노드의 수입니다. (여기서 k를 선택함으로써 방식으로 결함이 있는 노드가 SKL을 학습하거나 서비스 거부를 마운트할 수 없도록 보장합니다. 공격을 통해 사용을 방해합니다.) L의 메시지는 M = (m, z) 형식을 취합니다. 여기서 m은 문자열이고 z는 고유합니다. 순차 인덱스 번호. 해당되는 경우 m = 형식으로 메시지를 작성합니다. ⟨메시지 유형 : 페이로드⟩. 메시지 유형 MessageType은 특정 메시지의 기능을 나타내는 구문 설탕입니다. 4최종성이 없는 blockchain이 원장을 실현하는 경우 일반적으로 불일치가 추상화됩니다. 충분하지 않은 깊이의 블록을 무시하거나 [115]을 "가지치기"하여 제거합니다. 5실제로 Hotstuff의 변형인 LibraBFT [205]와 같은 일부 코드 기반이 현재 채택되었습니다. 임계값 서명 대신 다중 서명을 사용하여 통신 복잡성을 줄였습니다. 더 간단한 엔지니어링. 약간의 비용을 추가하면 oracle 노드가 메시지에 임계값 서명을 추가할 수 있습니다. L에 사용되는 합의 프로토콜이 L을 사용하지 않더라도 L에 기록됩니다.2.3 표기법 원장을 실행하는 n oracle 노드 집합을 O = {Oi}n으로 나타냅니다. 나는 = 1입니다. 그러한 노드 집합을 흔히 위원회라고 합니다. 단순화를 위해 우리는 다음과 같은 집합을 가정합니다. oracles는 DON 기능, 즉 L 위에 서비스를 구현하는 것과 동일합니다. L을 유지하지만 서로 구별될 수 있습니다. pki를 공개 키로 지정하겠습니다. 플레이어 Oi를 선택하고 해당 개인 키를 스키로 이동하세요. 대부분의 BFT 알고리즘에는 최소한 n = 3f + 1개의 노드가 필요합니다. 여기서 f는 노드 수입니다. 잠재적으로 결함이 있는 노드; 나머지 노드는 정직합니다. 프로토콜은 지정된 대로 정확하게 수행됩니다. 우리는 위원회 O가 이 기준을 충족한다면 정직하다고 언급합니다. 즉, 정직한 노드의 비율이 2/3보다 큽니다. 달리 그렇지 않은 한 언급된 바와 같이, 우리는 O가 정직하다고 가정합니다(그리고 부패의 정적 모델). 우리는 pkO/를 사용합니다. skO는 상황에 따라 pkL / skL과 같은 의미로 사용됩니다. σ = Sigpk[m]이 pk와 관련하여 메시지 m의 서명을 표시하도록 합니다. 즉, 다음을 사용합니다. 해당 개인 키 sk. verify(pk, σ, m) →{false, true}는 해당 서명 검증 알고리즘을 나타냅니다. (우리는 문서 전반에 걸쳐 키 생성을 암묵적으로 남겨 둡니다.) 우리는 데이터 소스를 나타내기 위해 표기법 S를 사용하고 전체 집합을 나타내기 위해 S를 사용합니다. 특정 컨텍스트의 nS 소스. 우리는 MAINCHAIN을 통해 스마트 계약이 가능함을 나타냅니다. blockchain은 DON에서 지원됩니다. 우리는 스마트한 모든 것을 나타내기 위해 의존 계약이라는 용어를 사용합니다. DON과 통신하는 MAINCHAIN에 대한 계약을 맺고 SC 표기법을 사용하여 다음을 수행합니다. 그러한 계약을 나타냅니다. 우리는 일반적으로 DON이 단일 메인 체인 MAINCHAIN을 지원한다고 가정하지만, 섹션 4의 예에서 볼 수 있듯이 여러 체인을 지원할 수 있습니다. A DON은 MAINCHAIN에서 여러 의존 계약을 지원할 수 있으며 일반적으로 지원할 것입니다. ( 위에서 언급했듯이 DON은 blockchain이 아닌 서비스를 대안으로 지원할 수 있습니다.) 2.4 신뢰 모델에 대한 참고 사항 위에서 언급했듯이 DON은 위원회 기반 합의 프로토콜 위에 구축될 수 있으며, 그들은 일반적으로 그러한 프로토콜을 사용할 것으로 예상합니다. 강력한 주장이 많다. 위원회 기반 또는 무허가 blockchains의 두 가지 대안 중 하나는 다음을 제공합니다. 다른 것보다 보안이 더 강력합니다. 위원회 기반 보안과 무허가 보안의 보안을 인식하는 것이 중요합니다. 분산형 시스템은 비교할 수 없습니다. PoW 또는 PoS 침해 blockchain 51% 공격을 통해 적이 일시적으로 대부분의 자원을 획득해야 하며 예를 들어 PoW 시스템에서 hash 전력을 임대함으로써 잠재적으로 익명으로 가능합니다. 그러한 실제로 공격은 이미 여러 blockchains [200, 34]에 영향을 미쳤습니다. 대조적으로, 위원회 기반 시스템을 손상시키는 것은 노드의 임계값(일반적으로 1/3)을 손상시키는 것을 의미합니다. 여기서 노드는 공개적으로 알려지고 리소스가 풍부하며 그리고 신뢰할 수 있는 실체. 반면에 위원회 기반 시스템(및 무허가형 "하이브리드") 위원회를 지원하는 시스템)은 엄격하게 규정된 것보다 더 많은 기능을 지원할 수 있습니다.미션리스 시스템. 여기에는 다음과 같은 지속적인 비밀을 유지하는 기능이 포함됩니다. 서명 및/또는 암호화 키는 우리 설계의 한 가지 가능성입니다. 우리는 DON이 원칙적으로 위원회 기반 또는 무허가 합의 프로토콜 및 DON 배포자는 궁극적으로 채택을 선택할 수 있습니다. 어느 쪽이든 접근합니다. 신뢰 모델 강화: 오늘날 Chainlink의 주요 기능은 사용자가 다음을 수행할 수 있다는 것입니다. 논의된 대로 성능 기록의 분산된 기록을 기반으로 노드를 선택합니다. 섹션 3.6.4. 섹션 9에서 소개하는 staking 메커니즘과 암시적 인센티브 프레임워크는 함께 광범위하고 엄격한 메커니즘 설계를 구성합니다. DONs의 보안을 측정할 수 있는 크게 확장된 기능을 사용자에게 제공하는 프레임워크입니다. 이 동일한 프레임워크를 통해 DONs 자체도 가능해집니다. 참여 노드에 다양한 보안 요구 사항을 적용하고 운영을 보장합니다. 강력한 신뢰 모델 내에서. DONs에 대해 이 문서에 설명된 도구를 사용하여 규제 요구 사항 준수와 같은 특별한 신뢰 모델 요구 사항을 적용하는 것도 가능합니다. 에 대한 예를 들어, 섹션 4.3에서 논의된 기술을 사용하여 노드는 다음의 증거를 제시할 수 있습니다. 노드-운영자 특성(예: 작업 영역)을 돕는 데 사용할 수 있습니다. 예를 들어 일반 데이터 보호 규정(GDPR) 제3조(“지역 범위”) [105] 준수를 시행합니다. 그렇지 않으면 그러한 준수가 어려울 수 있습니다. 분산형 시스템에서 만나세요 [45]. 또한 섹션 7에서는 DON의 견고성을 강화하기 위한 계획에 대해 논의합니다. 그들이 지원하는 메인 체인의 신뢰 최소화 메커니즘을 통해.
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.
분산형 Oracle 네트워크 인터페이스 및 Ca-
능력 여기에서는 간단하지만 강력한 측면에서 DON의 기능을 간략하게 설명합니다. 인터페이스를 실현하도록 설계되었습니다. DON의 애플리케이션은 실행 파일과 어댑터로 구성됩니다. 실행 파일은 핵심 논리가 smart contract과 유사한 결정론적 프로그램인 프로그램입니다. 실행 파일에는 항목을 호출하는 프로그램과 함께 제공되는 여러 시작 프로그램도 있습니다. 미리 결정된 이벤트가 발생할 때 실행 파일 논리의 지점(예: 특정 시간) (크론 작업과 같은), 가격이 임계값을 초과하는 경우 등 - 키퍼와 매우 유사합니다(섹션 3.6.3 참조). 어댑터는 오프체인 리소스에 대한 인터페이스를 제공하며 다음에 의해 호출될 수 있습니다. 실행 파일의 개시자 또는 핵심 논리입니다. 그들의 행동은 그것에 달려 있을 수 있기 때문에 외부 리소스의 경우 개시자 및 어댑터가 비결정적으로 동작할 수 있습니다. 우리는 DON 개발자 인터페이스와 실행 파일의 기능을 설명하고 컴퓨팅 시스템을 특성화하는 데 일반적으로 사용되는 세 가지 리소스인 네트워킹, 컴퓨팅, 스토리지 측면에서 어댑터를 설명합니다. 우리는 이들 각각에 대한 간략한 개요를 제공합니다 아래 리소스를 참조하고 부록 B에 자세한 내용을 제공하세요.
3.1 네트워킹 어댑터는 DON에서 실행되는 실행 파일을 보내고 전송할 수 있는 인터페이스입니다. off-DON 시스템에서 데이터를 수신합니다. 어댑터는 다음의 일반화로 볼 수 있습니다. 현재 Chainlink에서 사용되는 어댑터 [20]. 어댑터는 양방향일 수 있습니다. 그냥 끌어올 수는 없지만 DON에서 웹 서버로 데이터를 푸시할 수 있습니다. 그들은 또한 활용할 수도 있습니다 분산 프로토콜 및 보안 다자간 보안과 같은 암호화 기능 계산. 그림 9: DON1로 표시되는 DON을 DON2로 표시되는 또 다른 DON, blockchain(메인 체인) 및 해당 리소스를 포함한 다양한 리소스와 연결하는 어댑터 멤풀, 외부 저장소, 웹 서버 및 IoT 장치(웹 서버를 통해). 어댑터가 생성될 수 있는 외부 리소스의 예가 표시됩니다. 그림 9에서. 여기에는 다음이 포함됩니다. • 블록체인: 어댑터는 blockchain에 트랜잭션을 보내는 방법을 정의할 수 있으며 블록, 개별 트랜잭션 또는 기타 상태를 읽는 방법. 어댑터 blockchain의 mempool에 대해서도 정의할 수 있습니다. (섹션 3.5 참조) • 웹 서버: 어댑터는 데이터를 검색할 수 있는 API를 정의할 수 있습니다. 특별히 적합하지 않은 레거시 시스템을 포함한 웹 서버에서 DONs와 인터페이스합니다. 이러한 어댑터에는 데이터를 전송하는 API도 포함될 수 있습니다. 그런 서버. DON이 연결되는 웹 서버는 게이트웨이 역할을 할 수 있습니다. IoT(사물 인터넷) 장치와 같은 추가 리소스에 연결됩니다.• 외부 저장소: 어댑터는 저장소를 읽고 쓰는 방법을 정의할 수 있습니다. 분산 파일 시스템[40, 188] 또는 클라우드와 같은 DON 외부 서비스 저장. • 기타 DONs: 어댑터는 DONs 간에 데이터를 검색하고 전송할 수 있습니다. DONs의 초기 배포에는 일련의 빌딩 블록이 포함될 것으로 예상됩니다. 일반적으로 사용되는 외부 리소스에 대한 어댑터를 추가로 허용하고 DON 특정 DON 노드에서 게시할 어댑터입니다. smart contract 개발자가 어댑터를 작성함에 따라 오늘 우리는 그들이 이 고급 기술을 사용하여 훨씬 더 강력한 어댑터를 구축할 것으로 기대합니다. 기능. 우리는 궁극적으로 사용자가 새로운 어댑터를 생성하는 것이 가능할 것으로 기대합니다. 무허가 방식. 일부 어댑터는 DON에 의해 제어되는 외부 리소스의 지속성과 가용성을 보장하는 방식으로 구성되어야 합니다. 예를 들어 클라우드 스토리지는 다음과 같습니다. 클라우드 서비스 계정의 유지 관리가 필요합니다. 또한 DON는 다음을 수행할 수 있습니다. 사용자를 대신하여 개인 키의 분산 관리(예: [160]) 및/또는 실행 파일. 결과적으로 DON은(예: blockchain 대상에서 트랜잭션을 보내는 데 사용될 수 있는) 암호화폐와 같은 리소스를 제어할 수 있습니다. DON 어댑터에 대한 자세한 내용은 부록 B.1을 참조하세요. 예시 어댑터. 3.2 계산 실행 파일은 DON의 기본 코드 단위입니다. 실행 파일은 exec = 쌍입니다. (논리, 초기화). 여기서 로직은 다수의 지정된 항목이 있는 결정론적 프로그램입니다. points (logic1, logic2, ..., logicℓ) 및 init는 해당 개시자의 집합입니다. (init1, init2, ..., inite). 실행 파일의 논리인 DON의 전체 감사 가능성을 보장하려면 모든 입력과 출력에 기본 원장 L을 사용합니다. 따라서 예를 들어 모든 어댑터는 실행 파일에 대한 입력으로 사용되는 데이터는 먼저 L에 저장되어야 합니다. 개시자: 현재 Chainlink의 개시자는 이벤트에 따른 작업 실행을 유발합니다. Chainlink 노드 [21]. DONs의 개시자는 거의 동일한 방식으로 작동합니다. 그러나 DON 개시자는 실행 파일과 구체적으로 연결됩니다. 개시자는 의존할 수 있습니다 외부 사건이나 상태, 현재 시간, 또는 DON 상태에 대한 술어. 이벤트에 대한 의존성으로 인해 개시자는 물론 비결정적으로 동작할 수도 있습니다. (물론 어댑터도 마찬가지입니다). 개시자는 개별 DON 노드 내에서 실행할 수 있습니다. 따라서 어댑터에 의존할 필요가 없습니다. (아래 예 1을 참조하세요.) 개시자는 실행 파일을 smart contract과 구별하는 중요한 기능입니다. 실행 파일은 개시자에 대한 응답으로 실행될 수 있으므로 효과적으로 작동할 수 있습니다. 물론 확장을 통해 실행 파일을 통합하는 하이브리드 계약이 자율적으로 가능합니다. 오늘날 개시자의 한 형태는 거래를 제공하는 Chainlink Keeper입니다.oracle 보고서를 기반으로 과소담보 대출 청산 및 지정가 주문 거래 실행과 같은 smart contract 실행을 실행하는 자동화 서비스입니다. 편리하게도 DONs의 개시자를 지정하는 방법으로 볼 수도 있습니다. 실행 파일에 적용되는 서비스 계약(아래 상황을 정의함) DON에서 호출해야 합니다. 다음 예에서는 실행 파일 내에서 개시자가 작동하는 방식을 보여줍니다. 예시 1(편차로 인한 가격 피드) smart contract SC에는 새로운 것이 필요할 수 있습니다. 예를 들어 1%와 같이 상당한 변화가 있을 때마다 가격 피드 데이터(섹션 3.6.3 참조) 한 쌍의 자산(예: ETH-USD) 간의 환율. 변동성에 민감한 가격 피드는 현재 Chainlink에서 지원되지만 어떻게 지원되는지 살펴보는 것이 좋습니다. 실행 가능한 execfeed를 통해 DON에서 실현되었습니다. 실행 가능한 execfeed는 L의 가장 최근 ETH-USD 가격 r을 유지합니다. ⟨NewPrice : j, r⟩항목의 시퀀스 형태. 여기서 j는 다음과 같이 증가하는 인덱스입니다. 각 가격 업데이트. 개시자 init1은 각 노드 Oi가 현재 ETH-USD 가격을 모니터링하도록 합니다. 인덱스 j를 사용하여 가장 최근에 저장한 가격 r에서 최소 1%의 편차. 시 이러한 편차를 감지한 Oi는 다음을 사용하여 새 가격의 현재 보기 ri를 L에 기록합니다. ⟨PriceView : i, j + 1, ri⟩ 형식의 항목. 두 번째 개시자 init2는 새 가격이 포함된 PriceView 항목이 k개 이상 있을 때 발생합니다. 개별 노드에서 생성된 인덱스 j + 1의 값이 L에 누적됩니다. 그러면 init2 첫 번째 k개의 유효한 유효한 가격 보기 값 k개의 중앙값 ρ를 계산하기 위해 진입점 logic2를 호출하고 새로운 값 ⟨NewPrice : j + 1, ρ⟩을 L에 씁니다. (운영상 노드 교대로 지정작가가 될 수 있다.) 세 번째 개시자 init3은 L의 NewPrice 항목을 감시합니다. 새 보고서가 나올 때마다 ⟨NewPrice : j, r⟩가 거기에 나타나며 (j, r)을 SC에 푸시하는 진입점 logic3을 호출합니다. 어댑터를 사용하여. 앞서 언급했듯이 실행 파일은 기능 면에서 smart contract과 유사합니다. 그러나 더 높은 성능 외에도 일반적인 메인 체인 계약과 다릅니다. 두 가지 중요한 방법으로: 1. 기밀성: 실행 파일은 기밀 계산을 수행할 수 있습니다. 즉, 비밀 프로그램이 일반 텍스트 입력을 처리하거나 게시된 프로그램이 처리할 수 있습니다. 비밀 입력 데이터 또는 둘의 조합. 간단한 모델에서는 비밀 데이터가 중간 결과를 숨기고만 공개하는 DON 노드에서 액세스할 수 있습니다. MAINCHAIN에 처리 및 삭제된 값. DONs 자체에서 민감한 데이터를 숨기는 것도 가능합니다. DONs는 다음과 같은 접근 방식을 지원하기 위한 것입니다. 다자간 계산(예: [42, 157]) 및 신뢰할 수 있는 실행 환경 (TEE) [84, 133, 152, 229] 이 목적을 위해.6 6더 나아가 DON 노드와 관련하여 실행 파일 자체를 비밀로 유지하는 것도 가능합니다. 이는 오늘날 TEE를 사용하는 중요하지 않은 실행 파일에만 실용적입니다.2. 지원 역할: 실행 파일은 기본에서 smart contract을 지원하기 위한 것입니다. 체인을 교체하는 대신 실행 파일에는 다음과 같은 몇 가지 제한 사항이 있습니다. smart contract은(는) 다음을 수행하지 않습니다. (a) 신뢰 모델: 실행 파일은 다음에 의해 정의된 신뢰 모델 내에서 작동합니다. DON: 올바른 실행은 O의 정직한 행동에 달려 있습니다. (메인 그러나 체인은 DON 불법 행위에 대한 일부 가드 레일을 제공할 수 있습니다. 섹션 7.3에서 논의됨) (b) 자산 액세스: DON은 blockchain의 계정을 제어할 수 있으므로 어댑터를 통해 자산을 제어합니다. 하지만 DON은 정식으로 사용할 수 없습니다. Ether 또는 ERC20 tokens와 같은 메인 체인에서 생성된 자산을 나타냅니다. 그들의 네이티브 체인은 소유권에 대한 권위 있는 기록을 유지합니다. (c) 수명 주기: DONs는 다음과 같이 제한된 수명으로 의도적으로 유지될 수 있습니다. DONs와 소유자 간의 온체인 서비스 수준 계약에 의해 정의됩니다. 의존 계약의. 대조적으로, 블록체인은 다음과 같이 기능하도록 되어 있습니다. 영구 보관 시스템. DON 계산에 대한 자세한 내용은 부록 B.2를 참조하세요. 3.3 저장 위원회 기반 시스템인 DON은 적당한 양의 데이터를 지속적으로 저장할 수 있습니다. L에서는 무허가 blockchain보다 훨씬 저렴한 비용으로 사용할 수 있습니다. 또한 어댑터를 통해 DONs는 데이터 저장을 위해 외부 분산 시스템을 참조할 수 있습니다(예: Filecoin [85], 이를 통해 해당 시스템을 smart contract에 연결할 수 있습니다. 이 옵션은 특히 "부풀음"이라는 만연한 문제를 해결하는 수단으로 대량 데이터에 적합합니다. blockchain 시스템. 따라서 DONs는 특별히 지원되는 서비스에 사용하기 위해 데이터를 로컬 또는 외부에 저장할 수 있습니다. DON은(는) 이러한 데이터를 기밀 방식으로 추가로 사용할 수 있습니다. (1) DON 노드 전체에서 비밀 공유되거나 암호화된 데이터에 대한 컴퓨팅 안전한 다자간 계산에 적합한 방식으로 DON 노드에서 관리하는 키 또는 부분적 또는 완전 동형 암호화; 또는 (2) 신뢰할 수 있는 실행을 사용하여 보호됨 환경. 우리는 DONs가 일반적인 간단한 메모리 관리 모델을 채택할 것으로 기대합니다. 스마트 계약 시스템: 실행 파일은 자체 메모리에만 쓸 수 있습니다. 실행 파일 그러나 다른 실행 파일의 메모리에서는 읽을 수 있습니다. DON 저장소에 대한 자세한 내용은 부록 B.3을 참조하세요. 3.4 트랜잭션 실행 프레임워크(TEF) DONs는 메인 체인 MAINCHAIN(또는 여러 메인 체인)의 계약을 지원하기 위한 것입니다. TEF(Transaction-Execution Framework)에 대해 자세히 설명합니다.섹션 6에서는 효율적인 계약 실행에 대한 일반적인 목적의 접근 방식을 설명합니다. MAINCHAIN 및 DON 전반의 SC. TEF는 FSS 및 레이어-2를 지원하도록 고안되었습니다. 원하는 경우 기술을 동시에 사용할 수 있습니다. 사실상 주력 차량이 될 가능성이 크다. FSS 사용에 대한 것입니다(그러한 이유로 이 섹션에서는 FSS에 대해 더 이상 논의하지 않습니다). 간단히 말해서, TEF에서는 MAINCHAIN을 위해 설계되거나 개발된 원래 대상 계약 SC입니다. 하이브리드 계약으로 리팩토링됩니다. 이 리팩토링은 두 가지 상호 운용성을 생성합니다. 하이브리드 계약의 일부: 명확성을 위해 우리가 언급하는 MAINCHAIN 계약 SCa TEF의 맥락에서 앵커 계약 및 DON의 실행 파일 실행 파일입니다. 는 계약 SCa는 사용자의 자산을 관리하고 권위 있는 상태 전환을 실행하며 DON의 오류에 대비한 보호 레일(섹션 7.3 참조)을 제공합니다. 실행 파일 exec 트랜잭션을 순서대로 나열하고 관련 oracle 데이터를 제공합니다. 묶을 수 있다 다양한 방법(예: 유효성 증명 기반 또는 낙관적인 rollups, DON에 의한 기밀 실행 등 우리는 개발자가 계약을 쉽게 분할할 수 있는 도구를 개발할 것으로 기대합니다. 고급 언어로 작성된 SC는 MAINCHAIN 및 DON 로직, SCa 및 안전하고 효율적으로 구성되는 각각의 임원입니다. TEF를 사용하여 고성능 트랜잭션 체계를 고성능과 통합 oracles는 oracle 확장 접근 방식의 핵심입니다. 3.5 멤풀 서비스 지원을 위해 DON에 배포하려는 중요한 애플리케이션 계층 기능 FSS와 TEF는 Mempool Services(MS)입니다. MS는 어댑터로 볼 수도 있지만, 그러나 최고 수준의 지원을 제공합니다. MS는 레거시 호환 트랜잭션 처리를 지원합니다. 이 용도에서는 MS 대상 계약을 위해 의도된 트랜잭션을 메인 체인의 멤풀에서 수집합니다. 메인체인의 SC. 그런 다음 MS는 이러한 트랜잭션을 DON의 실행 파일에 전달합니다. 원하는 방식으로 처리되는 곳입니다. MS 데이터는 DON에서 사용할 수 있습니다. DON에서 SC로 직접 전달될 수 있는 트랜잭션을 작성하거나 SC를 호출하는 다른 계약으로. 예를 들어 DON은 트랜잭션을 전달할 수 있습니다. MS를 통해 수집하거나 MS 데이터를 사용하여 보내는 거래에 대한 가스 가격을 설정할 수 있습니다. 메인체인. MS는 mempool을 모니터링하기 때문에 SC와 직접 상호 작용하는 사용자로부터 트랜잭션을 얻을 수 있습니다. 따라서 사용자는 다음을 사용하여 계속해서 거래를 생성할 수 있습니다. 레거시 소프트웨어, 즉 MS 및 MS 구성의 존재를 인식하지 못하는 애플리케이션 계약. (이 경우 원래 거래를 무시하고 SC를 변경해야 합니다. 이중 처리를 피하기 위해 MS에서 처리한 것만 허용합니다.) 대상 계약 SC와 함께 사용하기 위해 MS는 FSS 및/또는 TEF와 함께 사용될 수 있습니다.3.6 디딤돌: 기존 Chainlink 기능 3.6.1 오프체인 보고(OCR) OCR(오프체인 보고) [60]은 oracle 보고서 집계 및 의존 계약 SC로의 전송을 위한 Chainlink의 메커니즘입니다. Chainlink 가격으로 최근 배포됨 피드 네트워크에서는 전체 DON을 향한 첫 번째 단계를 나타냅니다. 핵심적으로 OCR은 부분적으로 동기식으로 작동하도록 설계된 BFT 프로토콜입니다. 네트워크. f < n/3이 존재할 때 임의로 활성도와 정확성을 보장합니다. 결함이 있는 노드는 비잔틴의 안정적인 방송 속성을 보장하지만 그렇지 않습니다. 완전한 BFT 합의 프로토콜. 노드는 다음과 같은 메시지 로그를 유지하지 않습니다. 모든 관점에서 동일한 원장을 나타낸다는 점에서 일관성이 있으며, 프로토콜의 리더는 안전을 위반하지 않고 모호하게 말할 수 있습니다. OCR은 현재 특정 메시지 유형(중간화된 집계)을 위해 설계되었습니다. (최소 2f +1) 값은 참여 노드에서 보고됩니다. 이는 다음에 대한 주요 보증을 제공합니다. SC에 대해 출력하는 보고서(증명된 보고서라고 함): 증명된 보고서의 중앙값 보고서는 두 정직한 노드가 보고한 값과 같거나 그 사이에 있습니다. 이 속성은 OCR의 주요 안전 조건입니다. 리더는 중앙값에 어느 정도 영향을 미칠 수 있습니다. 입증된 보고서의 가치는 이 정확성 조건에만 적용됩니다. OCR은 다양한 방식으로 값을 집계하는 메시지 유형으로 확장됩니다. Chainlink 네트워크의 활성 및 정확성 목표는 오늘날 필요하지 않지만 OCR이 완전한 합의 프로토콜이 되려면 기존 BFT 프로토콜에는 없는 몇 가지 추가 기능 형태를 제공하기 위해 OCR이 필요합니다. 특히 다음과 같습니다. 1. 전부 아니면 전무의 오프체인 보고서 방송: OCR은 증명된 보고서를 보장합니다. 모든 정직한 노드가 신속하게 사용할 수 있게 되거나 그 중 누구도 사용할 수 없게 됩니다. 이것이 공정성이다 정직한 노드가 참여할 기회를 갖도록 보장하는 재산 증명된 보고서 전송 시. 2. 안정적인 전송: OCR은 결함이 있거나 악의적인 경우에도 보장합니다. 모든 OCR 보고서와 메시지가 특정 내에서 SC로 전송되는 노드, 미리 정의된 시간 간격. 이는 활성 속성입니다. 3. 계약 기반 신뢰 최소화: SC는 잠재적으로 잘못된 OCR 생성 보고서를 필터링합니다(예: 보고된 값이 다른 값과 크게 벗어나는 경우). 최근에 받은 것. 이는 추가 프로토콜 정확성 적용의 한 형태입니다. 이 세 가지 속성은 모두 DONs에서 자연스러운 역할을 합니다. 전부 아니면 전무 오프체인(DON) 방송은 암호화폐 경제 보장을 위한 중요한 구성 요소입니다. 안정적인 전송을 중심으로 이는 결국 필수적인 어댑터 속성입니다. 신뢰 SC의 최소화는 섹션 7.3에서 논의된 바와 같이 일종의 가드레일입니다. OCR은 또한 Chainlink의 oracle 네트워크에서 BFT 프로토콜의 운영 배포 및 개선을 위한 기반을 제공합니다. DONs의 기능.3.6.2 DECO와 타운 크라이어 DECO [234] 및 Town Crier [233]은 현재 진행 중인 관련 기술 쌍입니다. Chainlink 네트워크에서 개발되었습니다. 오늘날 대부분의 웹 서버에서는 사용자가 프로토콜을 사용하여 보안 채널을 통해 연결할 수 있습니다. TLS(전송 계층 보안) [94]이라고 합니다. (HTTPS는 HTTP의 변형을 나타냅니다. TLS를 사용하여 활성화됩니다. 즉, "https" 접두사가 붙은 URL은 보안을 위해 TLS를 사용함을 나타냅니다.) 하지만 대부분의 TLS 지원 서버에는 눈에 띄는 제한 사항이 있습니다. 즉, 디지털 서명을 하지 않습니다. 데이터. 결과적으로, 사용자나 증명자는 서버로부터 받은 데이터를 제시할 수 없습니다. 다음을 보장하는 방식으로 oracle 또는 smart contract와 같은 제3자 또는 검증자에게 데이터의 신뢰성. 서버가 데이터에 디지털 서명을 하더라도 기밀성 문제가 남아 있습니다. 증명자는 중요한 데이터를 제출하기 전에 수정하거나 수정하기를 원할 수 있습니다. 검증자. 그러나 디지털 서명은 수정된 데이터를 무효화하기 위해 특별히 설계되었습니다. 따라서 증명자가 기밀성을 유지하면서 변경하는 것을 방지합니다. 데이터에. (자세한 내용은 섹션 7.1을 참조하세요.) DECO와 Town Crier는 증명자가 웹에서 데이터를 얻을 수 있도록 설계되었습니다. 무결성과 기밀성을 보장하는 방식으로 검증자에게 제공합니다. 두 시스템은 다음에 의해 제공되는 데이터를 보장한다는 의미에서 무결성을 유지합니다. 검증자에 대한 증명자는 대상 서버에서 인증됩니다. 그들은 지원한다 증명자가 데이터를 수정하거나 수정할 수 있도록 허용한다는 의미의 기밀성(여전히 무결성 유지). 두 시스템의 주요 특징은 어떤 수정도 필요하지 않다는 것입니다. 대상 웹 서버. 기존 TLS 지원 서버와 함께 작동할 수 있습니다. 사실, 서버에 투명합니다. 서버의 관점에서 증명자는 일반적인 연결을 설정합니다. 두 시스템은 비슷한 목표를 가지고 있지만 지금 간략하게 설명하는 것처럼 신뢰 모델과 구현이 다릅니다. DECO는 무결성을 달성하기 위해 암호화 프로토콜을 기본적으로 사용합니다. 및 기밀성 속성. DECO를 사용하여 대상 서버와 세션을 설정하는 동안 Prover는 동시에 대화형 프로토콜에 참여합니다. 검증자. 이 프로토콜을 통해 증명자는 검증자에게 수신했음을 증명할 수 있습니다. 현재 세션 동안 서버에서 주어진 데이터 D 조각. 증명자는 할 수 있다 대안으로 검증자에게 D의 일부 속성에 대한 영지식 증명을 제시합니다. 따라서 D를 직접적으로 공개하지 않습니다. DECO의 일반적인 사용에서 사용자 또는 단일 노드는 개인 데이터베이스에서 데이터 D를 내보낼 수 있습니다. DON의 모든 노드에 대한 웹 서버와의 세션. 결과적으로 전체 DON은(는) D의 진위(또는 영지식 증명을 통해 D에서 파생된 사실)를 증명합니다. 이 문서의 뒷부분에 나오는 예제 애플리케이션 외에도 이 기능을 사용할 수 있습니다. DON을 통해 데이터 소스에 대한 높은 무결성 액세스를 증폭하는 데 사용됩니다. 노드가 1개만 있어도 예를 들어 다음과의 독점 계약으로 인해 데이터 소스에 직접 액세스할 수 있습니다. 데이터 제공자—전체 DON가해당 노드에서 내보내는 보고서입니다. Town Crier는 Intel과 같은 TEE(신뢰할 수 있는 실행 환경)를 사용합니다. SGX. 간단히 말해서, TEE는 애플리케이션을 실행하는 일종의 블랙박스 역할을 합니다. 변조 방지 및 기밀 방식. 원칙적으로 해당 호스트의 소유자라도 실행 중인 TEE는 TEE로 보호되는 애플리케이션을 (감지 불가능하게) 변경할 수 없으며, 비밀 데이터가 포함될 수 있는 애플리케이션 상태를 봅니다. Town Crier는 DECO 등의 모든 기능을 구현할 수 있습니다. DECO는 증명자가 단일 검증자와 상호 작용하도록 제한합니다. 대조적으로, Town Crier는 다음을 가능하게 합니다. 대상 서버에서 가져온 데이터 D에 대해 공개적으로 검증 가능한 증거를 생성하는 증명자, 즉, smart contract이라도 누구나 직접 확인할 수 있는 증거입니다. 마을 외치는 사람은 할 수 있습니다 또한 보안 비밀(예: 사용자 자격 증명)을 안전하게 수집하고 활용합니다. Town Crier의 주요 제한 사항은 TEE에 대한 의존성입니다. 생산 TEE에는 기술은 초기 단계에 있으며 의심할 여지 없이 성숙해질 것이지만 최근에 여러 가지 심각한 취약점이 있는 것으로 나타났습니다. 자세한 내용은 부록 B.2.1 및 B.2.2를 참조하세요. TEE에 대한 추가 논의. DECO 및 Town Crier의 몇 가지 적용 예는 섹션 4.3, 4.5를 참조하세요. 9.4.3 및 부록 C.1. 3.6.3 기존 온체인 Chainlink 서비스 Chainlink oracle 네트워크는 다양한 분야에서 다양한 주요 서비스를 제공합니다. blockchains 및 오늘날의 기타 분산형 시스템. 설명 된대로 추가 진화 이 백서에서는 이러한 기존 서비스에 추가 기능을 부여하고 도달하다. 세 가지 예는 다음과 같습니다. 데이터 피드: 오늘날 smart contract에 의존하는 대부분의 Chainlink 사용자는 데이터 피드 사용. 이는 주요 데이터의 현재 가치에 대한 보고서입니다. 신뢰할 수 있는 오프체인 소스에. 예를 들어 가격 피드는 가격을 보고하는 피드입니다. 자산(암호화폐, 원자재, 외환, 지수, 주식 등)에 따라 교환 또는 데이터 수집 서비스. 오늘날 이러한 피드는 이미 수십억 달러의 보안을 확보하는 데 도움이 됩니다. Aave [147]와 같은 DeFi 시스템에서의 사용을 통한 온체인 가치의 달러 신세틱스 [208]. Chainlink 데이터 피드의 다른 예로는 다음의 날씨 데이터가 있습니다. 매개변수적 작물 보험 [75] 및 선거 데이터 [93] 등이 있습니다. 이 백서에 설명된 DON 및 기타 기술의 배포는 다음을 포함하여 여러 가지 방법으로 Chainlink 네트워크의 데이터 피드 제공을 향상시킵니다. • 확장: OCR 이후 DON은 Chainlink 서비스 확장을 목표로 합니다. 그들이 지원하는 많은 blockchain에 걸쳐 극적으로. 예를 들어, 우리는 DONs는 다음을 사용하여 노드에서 제공하는 데이터 피드 수를 늘리는 데 도움이 됩니다. Chainlink 100년대부터 1000년대 그리고 그 이상까지. 이러한 확장은 Chainlink에 도움이 될 것입니다. 생태계는 smart contracts와 관련된 데이터를 포괄적으로 제공하고 기존 및 미래의 요구 사항을 충족하고 예상한다는 목표를 달성합니다.• 보안 강화: 중간 보고서를 저장하면 DONs에서 기록을 유지합니다. 충실도가 높은 모니터링과 성능 및 정확성 측정을 위한 노드 동작을 통해 평판 시스템에 대한 강력한 경험적 기반을 제공합니다. Chainlink 노드의 경우. FSS와 TEF를 통해 가격 피드를 통합할 수 있습니다. 프론트 런(front-running)과 같은 공격을 방지하는 유연한 방식으로 거래 데이터를 사용합니다. (명시적) staking은 보안의 기존 암호경제적 보호를 강화합니다. 데이터 피드의 • 피드 민첩성: blockchain-agnostic 시스템(실제로 더 광범위하게는 소비자 독립적 시스템)으로서 DONs는 다양한 사용자에게 데이터 피드 제공을 용이하게 할 수 있습니다. 의존 시스템의. 단일 DON는 주어진 피드를 동시에 세트로 푸시할 수 있습니다. 다양한 blockchain을 사용하여 체인별 oracle 네트워크가 필요하지 않으며 새로운 blockchain에 대한 기존 피드와 추가 피드를 빠르게 배포할 수 있습니다. 현재 서비스되는 blockchain에 대한 피드입니다. • 기밀성: DON에서 일반화된 계산을 수행하는 기능을 통해 민감한 데이터에 대한 계산이 온체인을 피하고 오프체인에서 수행될 수 있습니다. 노출. 추가적으로 DECO나 Town Crier를 사용하면 기밀성이 더욱 강화되어 공개되지 않은 데이터를 기반으로 보고서를 생성할 수 있습니다. DON 노드에도 노출됩니다. 예시는 섹션 4.3 및 섹션 4.5를 참조하세요. 검증 가능한 무작위 함수(VRF): 여러 유형의 DApp에는 자체 공정한 운영을 검증할 수 있도록 검증 가능한 올바른 무작위성 소스가 필요합니다. 대체 불가능한 토큰(NFTs)이 그 예입니다. Aavegotchi [23] 및 Axie Infinity [35]의 NFT 기능의 희귀성은 Chainlink VRF에 의해 결정되며 분포도 마찬가지입니다. Ether 카드 [102]의 티켓 기반 추첨을 통해 NFTs; 다양한 결과가 무작위로 결정되는 게임 DApp 비전통적인 금융 수단(예: PoolTogether [89]과 같은 무손실 저축 게임) 무작위 우승자. 기타 blockchain 및 blockchain이 아닌 애플리케이션에도 보안이 필요합니다. 분산 시스템 위원회의 선택과 복권 실행. hashes 블록은 예측할 수 없는 무작위성의 소스 역할을 할 수 있지만, 적대적인 채굴자(및 어느 정도 제출한 사용자)의 조작에 취약합니다. 거래). Chainlink VRF [78]은 훨씬 더 안전한 대안을 제공합니다. 안 oracle에는 개인 키가 오프체인으로 유지되고 공개 키 pk가 게시되는 연결된 개인/공개 키 쌍(sk, pk)이 있습니다. 임의의 값을 출력하려면 의존 계약에 의해 제공되는 예측할 수 없는 시드 x에 sk를 적용합니다(예: hash 블록) 및 DApp별 매개변수) 함수 F를 사용하여 y = Fsk(x)를 산출합니다. 정확성의 증거. (Chainlink에서 사용할 수 있는 VRF는 [180]을 참조하세요.) VRF 검증 가능은 pk에 대한 지식을 바탕으로 증명의 정확성, 즉 y의 정확성을 확인할 수 있다는 사실입니다. 결과적으로 y 값은 예측할 수 없습니다. x를 예측하거나 sk를 학습할 수 없고 서비스가 조작할 수 없는 적입니다.Chainlink VRF는 오프체인 개인 키의 관리와 관련된 애플리케이션 제품군 중 하나로 볼 수 있습니다. 보다 일반적으로 DONs는 보안을 제공할 수 있습니다. 애플리케이션 및/또는 사용자를 위한 개별 키의 분산형 저장 및 결합 일반화된 계산을 통해 이 기능을 사용할 수 있습니다. 그 결과 수많은 응용 프로그램이 탄생했습니다. 이 문서에서는 Proof of Key 관리를 포함하여 몇 가지 예를 제공합니다. 예비금(섹션 4.1 참조) 및 사용자의 분산 자격 증명(및 기타 디지털 자산)(섹션 4.3 참조). 키퍼: Chainlink 키퍼 [87]는 개발자가 분산형 코드를 작성할 수 있도록 해줍니다. 일반적으로 의존하는 smart contract의 실행을 트리거하기 위한 오프체인 작업 실행. Keeper가 등장하기 전에는 개발자가 이러한 오프체인을 운영하는 것이 일반적이었습니다. 논리 자체가 중앙 집중화된 실패 지점을 생성합니다(상당한 중복 개발 노력도 포함). 대신 Keeper는 사용하기 쉬운 프레임워크를 제공합니다. 이러한 작업을 분산 아웃소싱하여 개발 주기를 단축하고 활성 및 기타 보안 속성에 대한 강력한 보증. 키퍼는 무엇이든 지원할 수 있습니다 가격에 따른 대출 청산 또는 금융 거래 실행, 시간에 따른 에어드롭 또는 결제 시작 수확량 수확 등을 갖춘 시스템에서. DON 프레임워크에서 개시자는 여러 의미에서 Keeper의 일반화로 볼 수 있습니다. 개시자는 어댑터를 사용할 수 있으므로 온체인 및 오프체인 시스템에 대한 모듈화된 인터페이스 라이브러리를 통해 신속한 안전하고 정교한 기능 개발. 개시자는 다음에서 계산을 시작합니다. DONs의 완전한 다양성을 제공하는 실행 파일입니다. 온체인 및 오프체인 애플리케이션을 위해 이 백서에서 제시하는 다양한 분산형 서비스입니다. 3.6.4 노드 평판 / 성능 내역 기존 Chainlink 생태계는 기본적으로 다음의 성능 기록을 문서화합니다. 체인에 노드를 기여합니다. 이 기능을 통해 개인에 대한 성과 데이터를 수집, 필터링 및 시각화하는 평판 지향 리소스 모음이 탄생했습니다. 노드 운영자 및 데이터 피드. 사용자는 이러한 리소스를 참조하여 정보를 얻을 수 있습니다. 노드 선택에 대한 결정을 내리고 기존 네트워크의 작동을 모니터링합니다. 유사한 기능은 사용자가 DON을 선택하는 데 도움이 됩니다. 예를 들어 오늘날 market.link와 같은 무허가 마켓플레이스는 노드를 허용합니다. 운영자는 자신의 oracle 서비스를 나열하고 다음을 통해 오프체인 신원을 증명합니다. Chainlink에 있는 노드의 프로필을 해당 노드에 바인딩하는 Keybase [4]와 같은 서비스 소유자의 기존 도메인 이름 및 소셜 미디어 계정. 추가적으로 성능 market.link 및 Reputation.link에서 제공되는 것과 같은 분석 도구를 사용하면 사용자는 다음을 포함하여 개별 노드의 과거 성능에 대한 통계를 볼 수 있습니다. 평균 응답 대기 시간, 보고서 값과 합의 값의 편차 체인을 통해 중계되고, 수익이 창출되고, 작업이 완료되는 등의 일이 발생합니다. 이러한 분석 도구는 또한 사용자는 다른 사용자의 다양한 oracle 네트워크 채택을 추적할 수 있습니다.그러한 네트워크를 보호하는 노드에 대한 암묵적인 보증. 그 결과는 평평한 "웹"입니다. 특정 노드를 사용하여 고부가가치 분산 애플리케이션을 생성하는 신뢰” 다른 사용자가 관찰하고 고려할 수 있는 노드에 대한 신뢰의 신호입니다. 자신의 노드 선택 결정. DONs(및 처음에는 OCR 사용)를 사용하면 트랜잭션 처리 및 계약 활동은 더 일반적으로 오프체인입니다. 기록 노드를 위한 분산형 모델 DON 자체 내에서는 성능이 유지됩니다. 과연 고성능 DONs의 데이터 용량으로 세분화된 기록 구축이 가능합니다. 또한 이러한 기록에 대해 분산형 계산을 수행하여 평판 서비스에서 사용하고 검사할 수 있는 신뢰할 수 있는 요약을 생성합니다. 메인체인. 원칙적으로 DON는 노드의 상당 부분이 손상된 경우 구성 노드의 동작을 잘못 나타낼 수 있지만 집단적 온체인 데이터를 전달하는 DON 자체의 성능은 MAINCHAIN에서 볼 수 있습니다. 따라서 잘못 표현될 수 없습니다. 추가적으로 우리는 다음과 같은 메커니즘을 탐색할 계획입니다. DON에서 노드 동작에 대한 정확한 내부 보고를 장려합니다. 예를 들어, 데이터를 가장 빠르게 반환하는 고성능 노드의 하위 집합을 보고하면 기여도가 높아집니다. 체인에 전달된 보고서에 대해 DON은 노드가 잘못된 것에 대해 이의를 제기하도록 인센티브를 생성합니다. 보고서: 이 하위 집합에 노드를 잘못 포함한다는 것은 노드를 잘못 제외한다는 의미입니다. 포함되어야 하므로 무효한 불이익을 줍니다. DON에 의한 반복적인 보고 실패는 또한 정직한 노드가 DON. 정확한 성과 이력의 분산화된 편집과 그에 따른 결과 사용자가 고성능 노드를 식별하고 노드 운영자가 구축할 수 있는 능력 평판은 Chainlink 생태계를 구별하는 중요한 특징입니다. 우리 섹션 9에서 우리가 그것들을 엄격하고 이해하기 쉬운 핵심 부분으로 추론할 수 있는 방법을 보여줍니다. 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].
Decentralized가 구현하는 분산형 서비스
오라클 네트웍스 DON의 다양성과 이를 통해 다양한 새로운 서비스를 활성화하는 방법을 설명하기 위해, 이 섹션에서는 DON 기반 애플리케이션의 다섯 가지 예를 제시하고 이를 실현하는 하이브리드 계약: (1) 크로스체인 서비스의 한 형태인 보유량 증명; (2) 기업/레거시 시스템과의 인터페이스, 즉 미들웨어 기반의 구축 최소한의 비용으로 blockchain 애플리케이션 개발을 용이하게 하는 추상화 계층 blockchain-특정 코드 또는 전문 지식; (3) 분산형 ID, 사용자가 다음을 수행할 수 있는 도구 자신의 신분 증명서와 자격 증명을 획득하고 관리합니다. (4) 우선순위 채널, 중요한 인프라 트랜잭션을 적시에 포함하도록 보장하는 서비스(예: oracle 보고서) blockchain; (5) 기밀 유지 DeFi, 즉 금융 참여 당사자의 민감한 데이터를 숨기는 smart contracts. 여기서 우리는
SC를 사용하여 하이브리드 계약의 MAINCHAIN 부분을 나타내고 DON을 설명합니다. 구성 요소를 별도로 또는 실행 가능한 exec 측면에서 사용합니다. 4.1 예비금 증명 많은 애플리케이션의 경우 blockchain 사이에서 상태를 중계하는 것이 유용합니다. 에이 이러한 서비스의 인기 있는 응용 프로그램은 암호화폐 래핑입니다. 포장된 동전 등 WBTC [15]은 분산 금융(DeFi)에서 인기 있는 자산이 되고 있습니다. 그들은 소스 blockchain MAINCHAIN(1)에 "래핑된" 지원 자산을 예치하는 것이 포함됩니다. 다른 대상 blockchain MAINCHAIN(2)에 해당 token을 생성합니다. 예를 들어, WBTC는 해당하는 Ethereum blockchain의 ERC20 token입니다. Bitcoin blockchain에서 BTC로. MAINCHAIN(2)에 대한 계약은 MAINCHAIN(1)에 대한 직접적인 가시성을 가지지 않기 때문에, 그들은 포장된 예금에 대해 보고하기 위해 명시적으로 또는 암시적으로 oracle에 의존해야 합니다. smart contract의 자산으로 적립금 증명이라고도 불리는 것을 생성합니다. 에서 WBTC [15], 예를 들어 관리인 BitGo는 BTC를 보유하고 WBTC를 발행합니다. Chainlink 예약금 증명을 제공하는 네트워크 [76]. DON 자체가 보유량 증명을 제공할 수 있습니다. 그러나 DON을 사용하면 가능합니다. 더 나아가려고. DON은 적절한 어댑터를 사용하여 비밀을 관리할 수 있습니다. 원하는 blockchain에서 거래할 수 있습니다. 결과적으로 DON가 작동하는 것이 가능합니다. 여러 관리인 중 한 명으로서, 심지어는 유일한 분산형 관리인으로서 래핑된 자산. DONs는 보안을 강화하는 플랫폼 역할을 할 수 있습니다. 보유금 증명을 사용하는 기존 서비스. 예를 들어 MAINCHAIN(1)이 Bitcoin이고 MAINCHAIN(2)이 Ethereum이라고 가정합니다. MAINCHAIN(2)에서 계약 SC는 래핑된 BTC를 나타내는 token을 발행합니다. DON BTC 주소 주소를 제어합니다(1) DON. BTC를 래핑하기 위해 사용자 U는 다음에서 X BTC를 보냅니다. 주소(1) 유 추가하기(1) DON MAINCHAIN(2)-주소 주소(2)와 함께 유. DON 모니터 주소(1) DON MAINCHAIN(1)에 대한 어댑터를 통해. U의 예금을 관찰하면 충분히 높은 확률로 확인된 후 어댑터를 통해 SC로 메시지를 보냅니다. 메인체인(2). 이 메시지는 SC에게 addr(2)에 대해 X tokens를 생성하도록 지시합니다. 유. U가 X tokens를 해제하려면 그 반대가 발생합니다. 그러나 MAINCHAIN(1)에서는 주소(1) DON는 X BTC를 addr(1)로 보냅니다. U(또는 사용자가 요청한 경우 다른 주소로). 물론 이러한 프로토콜은 직접적으로 작동하기보다는 교환과 함께 작동하도록 조정될 수 있습니다. 사용자와 함께. 4.2 엔터프라이즈/레거시 시스템과의 인터페이스 DON은 증명의 예에서와 같이 blockchain 사이에서 브리지 역할을 할 수 있습니다. 하지만 또 다른 목표는 예비군 사이의 양방향 다리 역할을 하는 것입니다. blockchains 및 레거시 시스템 [176] 또는 중앙 은행과 같은 blockchain 유사 시스템 디지털 통화 [30]. 기업은 기존 시스템과 시스템을 연결하는 데 있어 여러 가지 과제에 직면해 있습니다. 다음을 포함하는 분산형 시스템에 대한 프로세스:• 블록체인 민첩성: 블록체인 시스템은 빠르게 변화합니다. 기업은 blockchain의 급속한 새로운 등장이나 인기 상승에 직면할 수 있습니다. 상대방이 거래를 원하지만 기업이 이를 수행할 수 없는 경우 기존 인프라를 지원합니다. 일반적으로 blockchains의 역동성은 개별 기업이 전체 생태계를 따라가는 것은 어렵습니다. • 블록체인 관련 개발 리소스: 많은 조직의 경우, 특히 다음과 같은 관점에서 최첨단 blockchain 전문 지식을 고용하거나 육성하는 것이 어렵습니다. 민첩성에 도전합니다. • 개인 키 관리: blockchains 또는 암호화폐에 대한 개인 키를 관리하려면 기존 사이버 보안과 다른 운영 전문 지식이 필요합니다. 많은 기업에서는 사용할 수 없습니다. • 기밀성: 기업은 자신의 민감하고 독점적인 정보를 노출하는 것을 꺼립니다. 체인의 데이터. 이러한 어려움 중 처음 세 가지를 해결하기 위해 개발자는 DON를 사용하면 됩니다. 엔터프라이즈 시스템에서 읽거나 쓸 수 있도록 하는 보안 미들웨어 계층 blockchains. DON는 다음과 같은 자세한 기술적 고려 사항을 추상화할 수 있습니다. 개발자와 사용자 모두를 위한 가스 역학, 체인 재구성 등. 작성자: 엔터프라이즈 시스템에 간소화된 blockchain 인터페이스를 제공함으로써 DON은(는) 다음을 수행할 수 있습니다. blockchain 인식 엔터프라이즈 애플리케이션의 개발을 상당히 단순화하여 기업이 blockchain 특정 개발 리소스를 획득하거나 육성해야 하는 부담을 제거합니다. DONs의 이러한 사용은 엔터프라이즈 개발자가 다음을 수행할 수 있다는 점에서 특히 매력적입니다. 대체로 blockchain 불가지론적인 스마트 계약 애플리케이션을 만듭니다. 그 결과, DON이 미들웨어 역할을 하도록 계측된 blockchain 세트가 더 크면 기업 사용자가 쉽게 액세스할 수 있는 blockchain 세트가 더 커졌습니다. 개발자 최소한의 수정만으로 기존 blockchain의 애플리케이션을 새로운 애플리케이션으로 포팅할 수 있습니다. 내부적으로 개발된 애플리케이션에 적용됩니다. 추가적인 기밀성 문제를 해결하기 위해 개발자는 이 문서에서 소개하고 DON 애플리케이션을 지원하기 위해 배포할 예정인 도구입니다. 여기에는 DECO 및 Town Crier 섹션 3.6.2와 기밀 유지가 포함됩니다. 섹션 7.1.2에서 논의된 API 수정과 이 섹션의 나머지 부분에서 다루는 다양한 애플리케이션별 접근 방식. 이 DON 시스템은 다음을 제공할 수 있습니다. 공개하지 않고 엔터프라이즈 시스템 상태에 대한 높은 무결성, 온체인 증명 체인에 있는 민감한 기업 소스 데이터. 4.3 분산형 신원 분산형 ID는 사용자가 다음을 수행할 수 있어야 한다는 개념에 대한 일반적인 용어입니다. 제3자에게 의존하기보다는 자신의 자격 증명을 획득하고 관리합니다. 그래서. 분산형 자격 증명은 보유자의 속성이나 주장에 대한 증명입니다.흔히 클레임이라고 불리는 것입니다. 자격 증명은 엔터티에 의해 디지털 서명됩니다. 클레임을 사용자와 정식으로 연결할 수 있는 발급자입니다. 대부분의 제안된 계획에서는 클레임은 범용 식별자인 분산 식별자(DID)와 연결됩니다. 특정 사용자. 자격 증명은 사용자가 보유한 개인 키의 공개 키에 바인딩됩니다. 따라서 사용자는 개인 키를 사용하여 소유권 주장을 증명할 수 있습니다. 분산형 신원으로서의 비전은 기존 및 제안된 계획입니다(예: [14, 92, 129, 216]에는 세 가지 심각한 제한이 있습니다. • 레거시 호환성 부족: 기존 분산형 ID 시스템은 발급자라고 불리는 당국 커뮤니티가 DID 자격 증명을 생성합니다. 왜냐하면 기존 웹 서비스는 일반적으로 데이터에 디지털 서명을 하지 않으므로 발급자가 시작되어야 합니다. 특수 목적 시스템으로. 왜냐하면 아무런 인센티브도 없이는 이 일을 할 동기가 없기 때문입니다. 탈중앙화된 신원 생태계에서는 닭과 달걀의 문제가 발생합니다. 다른 곳에서는 즉, 발급자 생태계를 부트스트랩하는 방법이 불분명합니다. • 작동하지 않는 키 관리: 분산형 ID 시스템에서는 사용자가 다음을 수행해야 합니다. 개인 키 관리, 암호화폐 경험을 통해 알 수 있는 사실 실행 불가능한 부담이 되는 것입니다. 약 4,000,000 Bitcoin이(가) 발생한 것으로 추산됩니다. 키 관리 실패로 인해 영구적으로 손실되었으며 [194] 많은 사용자가 [193] 거래소의 암호화폐 자산으로 인해 분산화가 약화됩니다. • 개인 정보 보호 Sybil 저항 부족: 투표, token 판매 중 token의 공정한 할당 등과 같은 애플리케이션의 기본 보안 요구 사항은 다음과 같습니다. 사용자는 여러 ID를 주장할 수 없습니다. 기존의 분산형 신원 제안에서는 사용자가 이를 달성하기 위해 실제 신원을 공개해야 합니다. Sybil 저항으로 인해 중요한 개인 정보 보호 보장이 약화됩니다. 노드 위원회의 조합을 사용하여 이러한 문제를 해결하는 것이 가능합니다. DON 내에서 분산 계산을 수행하고 DECO와 같은 도구를 사용합니다. 또는 CanDID [160]이라는 시스템에 표시된 것처럼 Town Crier입니다. DECO 또는 Town Crier는 설계에 따라 수정 없이 기존 웹 서비스를 전환할 수 있습니다. 기밀 유지 자격 증명 발급자로 변경됩니다. DON을 사용하여 관련 항목을 내보낼 수 있습니다. 이러한 목적으로 데이터를 자격 증명으로 변환하고, 민감한 데이터를 숨겨서는 안 됩니다. 자격 증명에 나타납니다. 또한 사용자의 키 복구를 용이하게 하여 키 관리 문제를 해결합니다. 문제가 발생하면 DON을 사용하면 사용자가 개인 키를 비밀 공유 형식으로 저장할 수 있습니다. 사용자는 다음을 수행할 수 있습니다. DON의 노드에 증명하여 키를 복구합니다. 마찬가지로 Town Crier를 사용하거나 DECO—미리 결정된 웹 제공업체 집합의 계정에 로그인하는 기능(예: 트위터, 구글, 페이스북). Town Crier 또는 DECO를 사용하는 것의 이점은 다음과 같습니다. OAUTH는 사용자 개인정보 보호입니다. 이 두 도구를 사용하면 사용자가 DON에 공개되는 것을 피할 수 있습니다. 실제 신원을 파생할 수 있는 웹 제공자 식별자. 마지막으로 [160]에 표시된 것처럼 Sybil 저항을 제공하려면 DON이 다음을 수행할 수 있습니다. 사용자를 위한 고유한 실제 식별자의 개인 정보 보호 변환을 수행합니다. (예: 사회보장번호(SSN))를 사용자 등록 시 온체인 식별자로 변환합니다.이를 통해 시스템은 다음과 같은 민감한 데이터 없이 중복 등록을 감지할 수 있습니다. SSN은 개별 DON 노드에 공개됩니다.7 DON은 외부 분산 ID를 대신하여 이러한 서비스를 제공할 수 있습니다. 허가가 없거나 허가된 blockchain의 시스템(예: Hyperledger 인스턴스) 인디 [129]. 적용 예: KYC: 분산형 신원은 다음을 위한 수단으로 유망합니다. 사용자를 개선하는 동시에 blockchains의 금융 애플리케이션에 대한 요구 사항을 간소화합니다. 프라이버시. 해결하는 데 도움이 될 수 있는 두 가지 과제는 자금 세탁 방지/고객 파악(AML/KYC) 규정에 따른 인증 및 규정 준수 의무입니다. 많은 국가의 AML 규정에 따라 금융 기관(및 기타 기업)은 거래하는 개인 및 기업의 신원을 확인하고 확인해야 합니다. 그들은 거래를 수행합니다. KYC는 금융 기관의 한 구성 요소를 형성합니다. 일반적으로 사용자 행동을 모니터링하고 자금 흐름을 관찰하는 등 광범위한 AML 정책이 포함됩니다. KYC에는 일반적으로 사용자에게 어떤 형태로든 신원 자격 증명을 제시하는 과정이 포함됩니다(예: 사용자의 얼굴 앞에 신분증을 들고 온라인 웹 양식에 입력 비디오 세션 등). 분산형 자격 증명의 안전한 생성 및 제시 원칙적으로 다음과 같은 여러 측면에서 유익한 대안이 될 수 있습니다. (1) KYC 프로세스는 사용자와 금융 기관 모두에게 더 효율적입니다. 자격 증명을 취득하면 모든 금융 기관에 원활하게 제시될 수 있습니다. (2) 타협을 통한 신원 도용 기회를 줄여 사기를 줄입니다. 개인 식별 정보(PII) 및 영상 확인 중 스푸핑 그리고 (3) 사용자가 통제권을 유지함에 따라 금융 기관의 PII 손상 위험을 줄입니다. 자신의 데이터. AML 규정 준수 실패로 인해 금융 기관이 수십억 달러의 벌금을 지불하고 많은 금융 기관이 KYC에 매년 수백만 달러를 지출한다는 점을 고려하면 개선을 통해 금융 기관에 상당한 비용 절감 효과를 가져올 수 있습니다. 그리고 더 나아가 소비자를 위한 [196]. 전통적인 금융 부문은 부진하지만 새로운 규정 준수 도구를 채택하기 위해 DeFi 시스템에서는 이를 점점 더 많이 수용하고 있습니다 [43]. 적용 예: 과소담보 대출: 대부분의 DeFi 애플리케이션은 오늘날 지원 대출은 완전 담보 대출로만 이루어집니다. 대출을 받은 것들이에요 대출금을 초과하는 가치의 암호화폐 자산을 예치하는 차용자. 최근 DeFi 커뮤니티에서 일반적으로 과소담보 대출이라고 부르는 것에 대한 관심이 높아졌습니다. 이와 대조적으로 이는 해당 담보가 제공되는 대출입니다. 대출 원금보다 가치가 낮은 경우. 과소담보 대출 전통적인 금융 기관에서 흔히 제공하는 대출과 유사합니다. 의지하기보다는 대출 상환을 보장하기 위해 예치된 담보를 기반으로 대출을 제공합니다. 차용인의 신용 기록에 대한 결정. 7이 변환은 분산 의사 난수 함수(PRF)를 사용합니다.담보가 부족한 대출은 DeFi 대출 시장의 초기 단계이지만 성장하고 있는 부분을 구성합니다. 그들은 전통적인 금융 기관에서 사용하는 것과 같은 메커니즘에 의존합니다. 법적 계약과 같은 기관 [91]. 성장을 위한 필수 요구 사항 기존 대출 결정의 핵심 요소인 사용자 신용도에 대한 데이터를 강력한 무결성을 제공하는 방식으로 시스템에 제공할 수 있는 능력이 될 것입니다. 올바른 데이터 보장. DON 지원 분산형 신원 시스템을 통해 차용자가 될 수 있습니다. 보존하면서 신용도를 증명하는 높은 보증 자격 증명을 생성합니다. 민감한 정보의 기밀성. 특히 차용인은 다음을 생성할 수 있습니다. 신뢰할 수 있는 온라인 소스의 기록을 기반으로 한 자격 증명만 노출합니다. 잠재적으로 민감한 다른 데이터를 노출하지 않고 DON에 의해 증명된 데이터입니다. 에 대한 예를 들어, 차용인은 자신의 신용 점수를 나타내는 자격 증명을 생성할 수 있습니다. 일련의 신용 조사 기관이 자신을 공개하지 않고 특정 기준점(예: 750)을 초과합니다. 정확한 점수 또는 그녀의 기록에 있는 기타 데이터. 또한 원하는 경우 해당 자격 증명 익명으로 생성될 수 있습니다. 즉, 사용자 이름이 민감한 데이터로 취급될 수 있습니다. oracle 노드나 분산 자격 증명에 노출되지 않습니다. 자격 증명 애플리케이션에 따라 온체인 또는 오프체인으로 사용될 수 있습니다. 요약하자면, 차용인은 자신의 신용에 대해 대출 기관에 필수 정보를 제공할 수 있습니다. 강력하고 진실성이 있고 불필요하고 민감한 정보가 노출될 위험이 없는 역사 데이터. 차용인은 기타 다양한 기밀 유지 자격 증명을 제공할 수도 있습니다. 대출 결정에 도움이 됩니다. 예를 들어 자격 증명은 차용인의 다음 예에서 볼 수 있듯이 (오프체인) 자산을 소유합니다. 적용 예: 인증: 많은 관할권에서는 미등록 증권을 판매할 수 있는 투자자 등급을 제한합니다. 예를 들어 미국의 경우 SEC 규정 D는 그러한 투자 기회에 대해 인증을 받도록 규정하고 있습니다. 개인은 100만 달러의 순자산을 보유해야 하고, 특정 최소 소득 요건을 충족하거나 특정 전문 자격을 갖추어야 합니다[209, 210]. 현재 인증 프로세스가 번거롭고 비효율적이며 종종 증명서가 필요합니다. 회계사 또는 이와 유사한 증거. 분산형 신원 시스템을 통해 사용자는 다음에서 자격 증명을 생성할 수 있습니다. 인증 준수를 입증하는 기존 온라인 금융 서비스 계정 규정을 준수하여 보다 효율적이고 개인 정보를 보호하는 KYC 프로세스를 촉진합니다. 는 또한 DECO와 Town Crier의 개인 정보 보호 속성을 통해 다음이 가능해집니다. 사용자의 재정 상태에 대한 세부 정보를 직접 공개하지 않고 무결성을 강력하게 보장하여 자격 증명을 생성합니다. 예를 들어, 사용자는 자격 증명을 생성할 수 있습니다. 추가 정보를 공개하지 않고 그녀의 순자산이 최소 100만 달러임을 증명합니다. 그녀의 재정 상태에 대한 정보. 4.4 우선순위 채널 우선순위 채널은 DON을 사용하여 쉽게 구축할 수 있는 유용한 새 서비스입니다. 그들의
목표는 MAINCHAIN에서 적시에 선택되고 우선순위가 높은 거래를 제공하는 것입니다. 네트워크 정체 기간 동안. 우선순위 채널은 다음과 같은 형태로 볼 수 있습니다. 블록 공간에 대한 선물 계약 및 암호화폐 상품으로서 일부로 만들어진 용어입니다. 프로젝트 시카고 [61, 136]. 우선순위 채널은 특히 금융 거래와 같은 일반적인 사용자 수준 활동이 아닌 채굴자가 oracles, 계약에 대한 거버넌스 기능 등과 같은 인프라 서비스를 활성화할 수 있도록 고안되었습니다. 실제로 여기에서 설계된 대로 우선순위는 네트워크 내 채굴력의 100% 미만으로 구현된 채널은 오직 배송 시간에 대한 느슨한 경계를 제공하여 속도 의존도가 높은 용도로 사용하는 것을 방지합니다. 선두 달리기와 같은 목표. 그림 10: 우선순위 채널은 채굴자 M, 또는 더 일반적으로는 채굴자 M 세트 - 사용자 U에게 그녀의 거래 τ가 D 블록 내에서 채굴될 것임을 알립니다. mempool에 포함됩니다. 계약 SC는 DON 모니터링을 사용하여 채널의 서비스 약관. 우선순위 채널은 광부 또는 광부 그룹 간의 합의 형태를 취합니다. (또는 마이닝 풀) 채널을 제공하는 M과 접속에 대한 수수료를 지불하는 사용자 U입니다. M은 U가 트랜잭션 τ를 멤풀에 제출할 때(가스 가격에 상관없이,그러나 사전 합의된 가스 한도), M은 이를 다음 D 블록 내의 체인에 배치합니다.8 이 아이디어는 그림 10에 개략적으로 설명되어 있습니다. 우선 채널 계약 설명: 우선순위 채널은 다음과 같이 구현될 수 있습니다. 하이브리드 smart contract 대략 다음과 같습니다. SC는 MAINCHAIN의 로직을 나타냅니다. 그리고 그것은 exec의 DON에 있습니다. SC는 U.A로부터 예금/스테이크 \(d from M and an advance payment \)p를 수락합니다. DON 실행 가능한 exec는 mempool을 모니터링하여 트랜잭션 배치 시 트리거됩니다. M이 채굴한 거래를 U가 제출하면 SC에 성공 메시지를 보냅니다. 시기적절한 방법과 서비스 장애 발생 시 장애 메시지를 제공합니다. SC는 성공 메시지를 받고 M에게 $p 지불금을 보내고 남은 자금을 모두 보냅니다. 실패 메시지를 받으면 $d를 포함하여 U로 보냅니다. 성공적으로 종료되면 M에게 예금 $d를 해제합니다. 채굴자 M은 물론 여러 사용자에게 우선순위 채널을 동시에 제공할 수 있습니다. 사용자는 미리 합의된 수의 메시지에 대해 U를 사용하여 우선순위 채널을 열 수 있습니다. 4.5 기밀 유지 DeFi / Mixicles 오늘날 DeFi 애플리케이션 [1]은 사용자에게 기밀성을 거의 또는 전혀 제공하지 않습니다. 모든 거래는 체인에서 볼 수 있습니다. 다양한 영지식 기반 접근 방식(예: [149, 217]), 거래 프라이버시를 제공할 수 있으며 TEF는 이를 지원할 만큼 충분히 일반적입니다. 하지만 이러한 접근 방식은 포괄적이지 않으며, 예를 들어 일반적으로 다음 사항을 숨기지 않습니다. 거래의 기반이 되는 자산. DONs에서 궁극적으로 지원하려는 광범위한 계산 도구 세트는 이러한 격차를 메울 수 있는 다양한 방법으로 개인 정보 보호를 활성화하여 다른 시스템의 개인 정보 보호 보장을 보완합니다. 예를 들어, Chainlink 연구소 연구원 [135]이 제안한 기밀 유지 DeFi 도구인 Mixicles는 금융 상품을 뒷받침하는 자산 유형이며 DON에 매우 자연스럽게 들어맞습니다. 프레임워크. Mixicle은 간단한 바이너리를 구현하는 용도로 가장 쉽게 설명됩니다. 옵션. 바이너리 옵션은 두 명의 사용자가 참여하는 금융 상품입니다. 플레이어로서 [135]과의 일관성을 위해 여기를 참조하십시오. 가능한 두 가지 이벤트에 베팅하세요. 결과(예: 자산이 미리 지정된 시간에 목표 가격을 초과하는지 여부) 다음 예에서는 아이디어를 보여줍니다. 예시 2. Alice와 Bob은 자산 가치를 기반으로 한 바이너리 옵션의 당사자입니다. 캐롤의 버블 토큰(CBT)이라고 합니다. Alice는 CBT의 시장 가격이 다음과 같을 것이라고 베팅했습니다. 2025년 6월 21일 정오 T 시간에 최소 250 USD; Bob은 그 반대로 베팅했습니다. 각 플레이어 미리 지정된 기한까지 100 ETH를 입금합니다. 승리하는 위치에 있는 플레이어 200 ETH를 받습니다(즉, 100 ETH를 얻습니다). 물론 8D는 M이 높은 확률을 준수할 수 있을 만큼 충분히 커야 합니다. 에 대한 예를 들어 M이 네트워크 마이닝 파워의 20%를 제어하는 경우 D = 100을 선택할 수 있습니다. 실패 확률은 2 × 10−10, 즉 10억분의 1 미만입니다.기존 Chainlink oracle 네트워크 O를 고려하면 스마트한 구현이 쉽습니다. 예시 2의 합의를 실현한 SC 계약. 두 플레이어가 각각 예치 SC에서는 100 ETH. T 이후에, 가격 r을 요청하는 쿼리 q가 O로 전송됩니다. T.O 시점의 CBT는 이 가격에 대한 보고서 r을 SC에 보냅니다. SC는 Alice에게 돈을 보냅니다. r ≥250이면 Bob이고, 그렇지 않으면 Bob입니다. 그러나 이 접근법은 체인상의 r을 드러냅니다. 관찰자가 바이너리 옵션의 기본 자산을 추론할 수 있도록 합니다. Mixicles라는 용어에서는 결과를 개념적으로 생각하는 것이 도움이 됩니다. 조건자로 계산된 이진 값을 전송하는 스위치 측면에서 SC의 스위치(r). 이 예에서는 r ≥250이면 switch(r) = 0입니다. 이 결과가 주어지면 Alice가 승리합니다. 그렇지 않으면 switch(r) = 1이고 Bob이 승리합니다. DON은 실행 파일을 실행하여 기본 Mixicle을 하이브리드 계약으로 실현할 수 있습니다. 스위치(r)를 계산하고 이를 SC에 체인으로 보고하는 exec입니다. 이 구조를 보여드리겠습니다 그림 11에서. 그림 11: 예제 2의 기본 Mixicle 다이어그램. r을 보고하고 바이너리 옵션의 기본 자산인 oracle은 이진 값 스위치(r)만 전환하여 SC를 계약합니다. 이를 쉽게 달성할 수 있도록 부록 C.3에 어댑터 ConfSwitch를 지정합니다. DON의 목표입니다. ConfSwitch의 기본 아이디어는 매우 간단합니다. 신고하는 대신 r 값, ConfSwitch는 바이너리 스위치 값 switch(r)만 보고합니다. SC는 가능하다 스위치(r)만 기반으로 정확한 결제를 하고 스위치(r) 자체는 올바르게 결제하도록 설계되었습니다. 기본 자산(이 예에서는 CBT)에 대한 정보를 공개하지 않습니다. 추가적으로, 공개 키인 pkaud로 암호화된 원장의 (q, r)에 암호문을 배치하여 감사자인 어댑터 ConfSwitch는 기밀성을 유지하는 감사 추적을 생성합니다. 여기서 설명하기 위해 단순화를 위해 선택한 기본 Mixicle은 우리 예에서는 바이너리 옵션 뒤에 자산과 베팅이 있습니다. 본격적인 Mixicle [135]은(는) 두 가지 형태의 기밀성을 제공합니다. (1) 어떤 사건이 관찰자에게 숨겨지나요? 플레이어는 (즉, q와 r)에 베팅할 뿐만 아니라 (2) 어느 플레이어가 베팅에서 승리했는지에도 베팅합니다. Mixicles는 MAINCHAIN에서 실행되므로 한 플레이어 중 한 명이 릴레이해야 합니다. DON에서 MAINCHAIN으로 전환(r)하거나 실행 가능한 exec를 생성할 수 있습니다.
ConfSwitch의 출력에서 트리거되고 다른 어댑터를 호출하여 스위치(r)를 메인체인. 세 번째로 미묘한 유형의 기밀성도 고려해 볼 가치가 있습니다. ConfSwitch의 기본 구현에서 O는 DON에서 어댑터를 실행하므로 다음을 학습합니다. 자산(이 예에서는 CBT) 및 바이너리 옵션의 성격입니다. 논의한대로 그러나 부록 C.3에서는 DECO 또는 Town Crier를 사용하여 추가로 사용할 수 있습니다. 이 정보조차 O에게 숨깁니다. 이 경우 O는 더 이상 정보를 배우지 않습니다. SC의 공개 관찰자보다. Mixicles에 대한 자세한 내용은 독자들에게 [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.
공정한 순서 서비스
DONs가 네트워킹, 컴퓨팅 및 스토리지 기능을 활용하여 제공할 것으로 예상되는 중요한 서비스 중 하나는 FSS(Fair Sequencing Services)입니다. FSS는 단순히 DON 프레임워크 내에서 구현된 애플리케이션으로 볼 수 있지만, 우리는 이를 전 세계적으로 높은 수요가 있을 것으로 믿는 서비스로 강조합니다. blockchains이며 Chainlink 네트워크가 이를 적극적으로 지원할 것으로 기대합니다. 공용 blockchain 네트워크에서 실행되면 오늘날의 많은 DeFi 애플리케이션이 사용자가 자신의 이익을 위해 활용할 수 있는 정보를 공개합니다. 기존 시스템에 만연해 있는 일종의 내부 정보 유출 및 조작 기회 시장 [64, 155]. 대신 FSS는 공정한 DeFi 생태계를 향한 길을 열어줍니다. FSS 개발자가 시장 조작으로부터 보호되는 DeFi 계약을 구축하는 데 도움이 됩니다. 정보 유출로 인해 발생합니다. 아래에서 강조하는 문제를 고려하면 FSS는 레이어 2 서비스에 특히 매력적이며 그러한 서비스의 프레임워크 내에 적합합니다. 이에 대해서는 섹션 6에서 논의합니다. 과제: 기존 무허가 시스템에서는 트랜잭션이 전적으로 주문됩니다. 광부의 재량에 따라. 허가된 네트워크에서는 validator 노드가 같은 힘. 이는 대체로 인식되지 않는 임시 중앙 집중화의 한 형태입니다. 그렇지 않으면 분산 시스템. 채굴자는 거래를 (일시적으로) 검열할 수 있습니다. 자신의 이익을 [171]하거나 자신의 이익을 극대화하기 위해 순서를 변경합니다. 이를 광산 추출 가능 가치(MEV) [90]이라고 합니다. MEV라는 용어는 약간 기만적입니다. 채굴자가 포착할 수 있는 가치에만 적용: 일부 MEV는 일반 사용자가 포착할 수 있습니다. 그러나 채굴자는 일반 사용자보다 더 많은 권한을 갖기 때문에 MEV는 모든 개체가 적대적 재정렬을 통해 얻을 수 있는 가치의 상한선을 나타냅니다. 그리고 보완적인 거래 삽입. 채굴자가 단순히 거래를 주문하는 경우에도 수수료(가스)를 기준으로 조작 없이 사용자가 직접 가스 가격을 조작할 수 있습니다. 덜 정교한 거래에 비해 거래를 유리하게 만듭니다. Daianet al. [90] 봇(채굴자가 아님)이 가져오는 방식을 문서화하고 수량화합니다. 오늘날 DeFi 시스템 사용자에게 해를 끼치는 방식으로 가스 역학의 이점과 방법 MEV는 심지어 blockchain의 기본 합의 계층의 안정성을 위협합니다. 거래 주문 조작의 다른 예는 [50, 154]와 같이 정기적으로 나타납니다.rollups와 같은 새로운 트랜잭션 처리 방법은 매우 유망한 접근 방식입니다. 처리량이 많은 blockchains의 확장 문제. 그러나 그들은 다루지 않습니다 MEV의 문제. 대신 rollup을 생성하는 엔터티로 이동합니다. 그 smart contract의 운영자이든 (zk-)rollup을 제공하는 사용자이든 상관없이 엔터티 유효성 증명은 거래를 주문하고 삽입할 수 있는 권한을 갖습니다. 즉, rollups MEV를 REV: 롤업 추출 가능 값으로 교체합니다. MEV는 멤풀에 제출된 향후 거래에 영향을 미칩니다. 하지만 아직 체인에 커밋되지는 않았습니다. 그러한 거래에 관한 정보는 광범위하게 네트워크에서 사용 가능합니다. 채굴자, validators 및 일반 네트워크 참가자는 따라서 이 지식을 활용하고 종속 트랜잭션을 생성합니다. 또한, 채굴자와 validator은 자신이 수행하는 거래의 순서에 영향을 미칠 수 있습니다. 스스로를 이용하고 이를 자신들에게 유리하게 활용합니다. 합의에 따른 거래 주문에 대한 리더의 과도한 영향력 문제 프로토콜은 1990년대 이후 문헌에 알려져 있지만[71, 190] 만족스럽지 않습니다. 솔루션은 지금까지 실제로 실현되었습니다 [97]. 주된 이유는 제안된 솔루션이 적어도 아주 최근까지는 대중과 쉽게 통합될 수 없다는 것입니다. blockchains, 이후까지 비밀로 유지되는 거래 내용에 의존하기 때문입니다. 그들의 순서가 결정되었습니다. 공정한 시퀀싱 서비스(FSS) 개요: DONs는 트랜잭션 주문을 분산화하고 의존자가 지정한 정책에 따라 이를 구현하는 도구를 제공합니다. 계약 작성자, 이상적으로는 공정하고 유리한 행위자를 원하는 사람이 아닌 사람 거래 순서를 조작합니다. 이러한 도구는 집합적으로 FSS를 구성합니다. FSS에는 세 가지 구성 요소가 포함됩니다. 첫 번째는 거래 모니터링이다. FSS에서는 O의 oracle 노드는 MAINCHAIN의 mempool을 모니터링하고 (원하는 경우) 허용합니다. 전문 채널을 통한 오프체인 거래 제출. 두 번째는 거래 순서입니다. 의존 계약에 대한 O 주문 거래의 노드 해당 계약에 대해 정의된 정책에 따라. 세 번째는 거래 게시입니다. 트랜잭션이 주문된 후 O의 노드는 트랜잭션을 공동으로 보냅니다. 메인 체인. FSS의 잠재적 이점은 다음과 같습니다. • 주문 공정성: FSS에는 개발자가 거래를 보장하는 데 도움이 되는 도구가 포함되어 있습니다. 특정 계약에 대한 입력은 불공정하지 않은 방식으로 주문됩니다. 자원이 풍부하고 기술적으로 정통한 사용자에게 유리합니다. 주문 정책 이 목적으로 지정될 수 있습니다. • 정보 유출의 감소 또는 제거: 네트워크 참가자가 향후 거래에 대한 지식을 이용할 수 없도록 보장함으로써 FSS는 이를 완화하거나 제거할 수 있습니다. 이용 가능한 정보를 기반으로 하는 선행 실행과 같은 공격을 제거합니다. 트랜잭션이 커밋되기 전의 네트워크. 그러한 악용 방지 누출은 원래 보류에 의존하는 적대적 거래를 보장합니다. 원래 거래가 커밋되기 전에는 거래가 원장에 들어갈 수 없습니다.• 거래 비용 절감: 제출 속도에 대한 플레이어의 요구 사항 제거 smart contract에 대한 거래를 통해 FSS는 거래 처리 비용을 크게 줄일 수 있습니다. • 우선순위 지정: FSS는 중요한 거래에 자동으로 특별한 우선순위를 부여할 수 있습니다. 주문. 예를 들어 oracle에 대한 선행 공격을 방지하기 위해 보고서(예: [79]), FSS는 oracle 보고서를 거래 흐름에 삽입할 수 있습니다. 소급하여. DONs에서 FSS의 가장 중요한 목표는 DeFi 제작자가 공정한 실현을 실현할 수 있도록 권한을 부여하는 것입니다. 금융 시스템, 즉 특정 사용자(또는 채굴자)에게 이익을 주지 않는 시스템 속도, 내부 지식 또는 기술 수행 능력을 기준으로 다른 사람보다 우수합니다. 조작. 명확하고 일반적인 공정성 개념은 파악하기 어렵고 완벽한 공정성은 합리적인 감각은 달성할 수 없습니다. FSS는 개발자에게 강력한 기능을 제공하는 것을 목표로 합니다. DeFi에 대한 설계 목표를 달성하는 데 도움이 되는 정책을 시행할 수 있는 도구 세트입니다. FSS의 주요 목표는 공정한 시퀀싱 서비스 역할을 하는 것이지만 DON의 목표인 MAINCHAIN은 FSS가 원하는 것과 동일한 공정성 중 일부입니다. 보장은 또한 실행되는 (분산형) 프로토콜에도 적합할 수 있습니다. DON 파티. 따라서 FSS는 하위 집합이 제공하는 서비스로 더 광범위하게 볼 수 있습니다. DON 노드는 MAINCHAIN 사용자가 보낸 트랜잭션뿐만 아니라 공정한 순서를 지정합니다. 또한 다른 DON 노드 간에 공유되는 트랜잭션(즉, 메시지)도 있습니다. 이 섹션에서는 우리는 주로 MAINCHAIN 거래 순서를 정하는 목표에 중점을 둘 것입니다. 섹션 구성: 섹션 5.1에서는 FSS 설계에 동기를 부여하는 두 가지 상위 수준 애플리케이션, 즉 oracle 보고서의 전면 실행 방지 및 방지를 설명합니다. 사용자 트랜잭션의 선행 실행. 그런 다음 FSS 설계에 대한 자세한 내용을 제공합니다. 섹션 5.2에서. 섹션 5.3에서는 공정한 주문 보장 및 수단의 예를 설명합니다. 그것을 달성하기 위해. 마지막으로 섹션 5.4와 섹션 5.5에서는 네트워크 수준의 위협에 대해 논의합니다. 네트워크 플러딩과 Sybil에 대해 각각 이러한 정책과 이를 해결하는 수단 공격. 5.1 전면 실행 문제 FSS의 목표와 설계를 설명하기 위해 우리는 프론트러닝의 두 가지 일반적인 형태를 설명합니다. 공격과 기존 솔루션의 한계. 프론트 런닝은 클래스를 예시합니다. 트랜잭션 주문 공격: 우리가 다루지 않는 백런 및 샌드위치(프론트 러닝 및 백 런) [237]과 같은 관련 공격이 많이 있습니다. 여기에 있지만 FSS도 해결하는 데 도움이 됩니다. 5.1.1 Oracle 선두 실행 blockchain 애플리케이션에 오프체인 데이터를 제공하는 전통적인 역할에서 oracles 전방 공격의 자연스러운 표적이 됩니다.다양한 가격 피드를 제공하기 위해 oracle을 사용하는 일반적인 디자인 패턴을 고려하십시오. 온체인 거래소로: 주기적으로(매시간) oracle은 가격 데이터를 수집합니다. 다른 자산을 교환 계약으로 보냅니다. 이러한 가격 데이터 거래 명백한 차익 거래 기회 제공: 예를 들어 최신 oracle 보고서에 일부 자산의 가격이 훨씬 높을 경우, 적이 oracle 보고서를 미리 실행할 수 있습니다. 자산을 매입하고 oracle의 신고가 처리되면 즉시 재판매하세요. 과속방지턱 및 소급 가격: oracle 선점 문제에 대한 자연스러운 해결책은 oracle 보고서에 다른 거래보다 특별한 우선순위를 부여하는 것입니다. 에 대한 예를 들어, oracle 보고서는 채굴자가 처리하도록 장려하기 위해 높은 수수료로 전송될 수 있습니다. 먼저 그들. 그러나 차익거래 기회가 높다면 선행매매를 막을 수는 없습니다. 또한 채굴자 자신의 차익 거래를 막을 수도 없습니다. 따라서 일부 거래소는 처리하기 전에 여러 블록에 대해 사용자 트랜잭션을 대기열에 넣는 등 보다 무거운 "속도 향상"을 구현하는 데 의존했습니다. 또는 새로운 oracle 보고서가 도착하면 가격을 소급하여 조정합니다. 이러한 솔루션의 단점은 교환 구현에 복잡성을 추가한다는 것입니다. 저장 요구 사항이 증가하여 거래 비용이 증가하고 자산 교환이 상당한 기간이 지난 후에만 확인되므로 사용자 경험이 중단됩니다. 편승: FSS로 넘어가기 전에 우리는 매우 간단하고 간단한 피기백(piggybacking)에 대해 논의합니다. oracle 전면 실행 문제에 대한 우아한 솔루션입니다. 주소에는 해당되지 않습니다. 그러나 다른 시나리오에서는 선행 실행됩니다. 즉, 온체인 컨트랙트에 정기적으로 보고서를 보내는 대신 oracles 사용자가 구매 또는 판매 시 거래에 추가하는 서명된 보고서를 게시합니다. 온체인 자산. 그런 다음 거래소는 보고서가 유효하고 최신인지 확인합니다. (예: oracle은 보고서가 유효한 블록 범위에 서명할 수 있음) 그것으로부터 관련 가격 피드. 이 간단한 접근 방식은 위의 "과속 방지턱"에 비해 여러 가지 장점이 있습니다. 접근 방식: (1) 교환 계약은 가격 피드 상태를 유지할 필요가 없습니다. 거래 비용이 낮아집니다. (2) oracle 보고서는 필요에 따라 체인에 게시되므로 oracle은 더 자주(예: 매분) 업데이트를 생성할 수 있습니다. 보고서 선행 실행으로 인한 차익거래 기회 최소화9; (3) 거래는 다음과 같습니다. 항상 새로운 가격 피드가 포함되어 있으므로 즉시 검증됩니다. 그러나 접근 방식이 완벽하지는 않습니다. 첫째, 이 피기백 솔루션은 거래소 사용자는 최신 oracle 보고서를 가져와서 첨부할 책임이 있습니다. 거래. 둘째, 편승은 차익거래 기회를 최소화하지만, 온체인 계약의 활성 상태에 영향을 주지 않고 이를 완전히 방지합니다. 실제로 만약에 oracle 보고서는 일부 블록 번호 n까지 유효하며 이후 거래가 블록에 제출됩니다. n + 1에는 새로운 유효한 보고서가 필요합니다. 본질적인 전파 지연으로 인해 oracles에서 사용자에게 보고하는 경우 블록 n + 1에 유효한 새 보고서는 9차익거래는 자산 가격의 활용 가능한 차이가 외부 차익을 초과하는 경우에만 가치가 있습니다. 자산을 사고 파는 데 필요한 수수료(예: 채굴자와 거래소가 수집한 자산)블록 n + 1이 채굴되기 전 일정 기간(예: 블록 n −k)에 공개됩니다. 단기 차익거래 기회가 존재하는 일련의 k개 블록을 생성합니다. 우리 이제 FSS가 이러한 제한 사항을 어떻게 해결하는지 설명합니다. FSS를 통해 oracle 보고서의 우선순위 지정: FSS는 oracle 전면 실행 문제를 해결할 수 있습니다. 위의 피기백 솔루션을 기반으로 구축했지만 추가 솔루션을 추진하여 문제가 발생했습니다. oracle을 통한 트랜잭션 증가 작업은 분산형 오라클 네트워크에 보고됩니다. 높은 수준에서 oracle 노드는 온체인 교환을 위한 트랜잭션을 수집합니다. 실시간 가격 피드에 동의하고 수집된 거래와 함께 가격 피드를 메인 체인 계약에 게시합니다. 개념적으로는 이 접근 방식을 다음과 같이 생각할 수 있습니다. oracle이 최신 상태를 보장하는 "데이터 증강 트랜잭션 일괄 처리" 가격 피드는 항상 거래에 추가됩니다. FSS 솔루션은 거래소 사용자에게 투명하게 구현될 수 있으며, 섹션 5.2에서 자세히 설명하는 것처럼 계약 논리에 대한 최소한의 변경입니다. 보장 새로운 oracle 보고서가 항상 사용자 거래보다 우선시된다는 점은 단지 하나의 예일 뿐입니다. FSS가 채택하고 시행할 수 있는 주문 정책입니다. 질서 보장을 위한 금감원의 정책 공정성은 섹션 5.3에서 더 일반적으로 설명됩니다. 5.1.2 선행 사용자 트랜잭션 이제 위의 방어 방법이 사용되는 일반 애플리케이션에서 전면 실행으로 전환합니다. 작동하지 않습니다. 이 문제는 다음 시나리오를 통해 광범위하게 파악할 수 있습니다. 공격자는 P2P 네트워크로 전송된 일부 사용자 트랜잭션 tx1을 보고 주입합니다. 자신의 적대적 트랜잭션 tx2를 사용하여 tx2가 tx1보다 먼저 처리되도록 합니다(예: 더 높은 거래 수수료). 예를 들어, 이런 종류의 선행 실행은 다음 중 일반적입니다. DeFi 시스템 [90]에서 재정 거래 기회를 이용하고 사용자에게 영향을 미치는 봇 다양한 분산 애플리케이션 [101]. 거래간의 공정한 질서를 확립한다 blockchain에서 처리되면 이 문제가 해결됩니다. 더 근본적으로, tx1의 세부 사항을 보는 것이 때로는 필요하지도 않으며 단순한 존재에 대한 지식으로 인해 적이 tx1을 통해 tx1을 앞지르게 할 수 있습니다. tx2를 소유하고 tx1을 생성한 무고한 사용자를 속이세요. 예를 들어, 사용자는 정기적으로 특정 자산을 거래하는 것으로 알려져 있습니다. 그러한 공격을 예방하려면 다음이 필요합니다. 메타데이터 유출도 방지하는 완화 [62]. 이 문제에 대한 몇 가지 해결책 존재하지만 지연과 유용성 문제가 발생합니다. FSS를 사용하여 네트워크 순서에서 최종 순서까지: 선두주자의 기회 기존 시스템에는 순서를 보장하는 메커니즘이 없기 때문에 발생합니다. 거래는 사건의 순서와 정보 흐름을 존중하여 체인에 나타납니다. 네트워크 외부. 이는 blockchain에서 애플리케이션(예: 거래 플랫폼) 구현의 결함으로 인해 발생하는 문제를 나타냅니다. 이상적으로는 트랜잭션이 blockchain에서 동일한 순서로 커밋되었는지 확인하세요. 생성되어 blockchain의 P2P 네트워크로 전송됩니다. 하지만 blockchain 네트워크 이후
분산되어 있으면 그러한 주문을 캡처할 수 없습니다. 따라서 FSS는 메커니즘을 도입합니다. 분배로 인해 발생하는 공정성 위반으로부터 보호하기 위해 blockchain 네트워크의 성격. 5.2 FSS 세부정보 그림 12: 두 가지 다른 트랜잭션 경로를 갖춘 주문 공정 멤풀: 직접적이고 멤풀 기반. 그림 12는 FSS의 일반적인 개략도를 보여줍니다. 공정성을 보장하기 위해 FSS를 제공하는 DON은 MAINCHAIN에 진입할 때 거래 흐름을 방해해야 합니다. 클라이언트, MAINCHAIN의 smart contracts 또는 둘 다에 대한 조정이 필요할 수 있습니다. 높은 수준에서 FSS의 거래 처리는 세 가지로 분해될 수 있습니다. 아래에 설명된 단계: (1) 거래 모니터링; (2) 거래 순서; 그리고 (3) 거래 게시. 트랜잭션 순서 지정에 사용되는 주문 방법에 따라 다음 섹션에 설명된 대로 추가 프로토콜 단계가 필요합니다. 5.2.1 거래 처리 거래 모니터링: 우리는 FSS가 모니터링할 수 있는 두 가지 접근 방식을 구상합니다. 특정 smart contract을 대상으로 하는 사용자 트랜잭션, 직접 및 mempool 기반: • 직접: 직접 접근 방식은 개념적으로 가장 간단하지만 다음 사항에 대한 변경이 필요합니다. 트랜잭션이 분산형 Oracle로 직접 전송되도록 사용자 클라이언트메인 체인의 노드가 아닌 네트워크 노드. DON는 수집합니다 특정 smart contract SC로 향하는 사용자 트랜잭션을 기반으로 주문합니다. 일부 주문 정책에 대해 그런 다음 DON은 주문된 트랜잭션을 다음으로 보냅니다. smart contract 메인 체인에 있습니다. 일부 주문 메커니즘에는 트랜잭션을 생성하는 사용자가 암호화 방식을 사용해야 하므로 직접적인 접근 방식도 필요합니다. FSS로 보내기 전에 보호하십시오. • Mempool 기반: FSS와 레거시 클라이언트의 통합을 용이하게 하기 위해 DON Mempool Services(MS)를 사용하여 메인 체인의 mempool을 모니터링하고 수집할 수 있습니다. 거래. 직접 전송은 많은 계약에서 선호되는 구현일 가능성이 높습니다. 그리고 우리는 이것이 많은 경우 상당히 실용적일 것이라고 믿습니다. 우리는 기존 DApp을 최소한으로 수정하여 지원하는 방법에 대해 간략하게 논의합니다. 좋은 사용자 경험을 유지하면서 직접 전송합니다. 우리는 접근 방식을 설명합니다 오늘날 가장 인기 있는 선택이기 때문에 Ethereum 및 MetaMask [6]을 사용하지만 언급된 기술은 다른 체인과 지갑으로 확장되어야 합니다. 최근 Ethereum 개선 제안, “EIP-3085: 지갑 추가 Ethereum 체인 RPC 방법” [100], 사용자 정의 Ethereum 체인을 쉽게 타겟팅할 수 있습니다(다른 체인 ID 사용). MetaMask 및 기타 브라우저 기반 지갑의 재생 공격을 방지하기 위한 MAINCHAIN의 것입니다. 이 제안을 구현한 후 DON를 사용하려는 DApp은 직접 전송할 수 있도록 프런트 엔드에 단일 메서드 호출을 추가하기만 하면 됩니다. Ethereum 호환 API를 노출하는 DON에 대한 트랜잭션입니다. 그동안, "EIP-712: Ethereum 유형화된 구조화된 데이터 hash생성 및 서명" [49]은 약간의 정보를 제공합니다. DApp 사용자가 사용할 수 있는 더 복잡하지만 이미 널리 배포된 대안 DON 트랜잭션을 지정하는 구조화된 데이터에 서명하는 MetaMask입니다. DApp은 보낼 수 있습니다 이 서명된 구조화된 데이터를 DON에 보냅니다. 마지막으로 하이브리드 접근 방식도 가능하다는 점에 주목합니다. 예를 들어, 유산 클라이언트는 계속해서 메인 체인의 멤풀로 트랜잭션을 보낼 수 있지만 매우 중요합니다. 거래(예: oracle 보고서)는 DON 노드로 직접 전송됩니다(특히 가격 피드 업데이트와 같은 oracle 보고서를 제공하는 노드 세트 및 노드 세트 FSS 제공은 중복되거나 동일할 수 있습니다). 거래 순서: FSS의 주요 목적은 사용자 트랜잭션이 미리 정의된 정책에 따라 정렬되도록 보장하는 것입니다. 이 정책의 성격은 다음과 같습니다. 애플리케이션의 요구와 불공정 거래 명령 유형에 따라 다릅니다. 예방하는 것을 목표로 합니다. DON의 FSS는 데이터를 처리하고 로컬 상태를 유지할 수 있으므로, 그들은 정보를 기반으로 임의의 순서 지정 정책을 부과할 수 있습니다. oracles에서 사용 가능합니다. 특정 주문 정책과 그 구현은 이후 섹션 5.3에서 논의됩니다.거래 전기: 사용자로부터 직접 받거나 멤풀에서 수집한 사용자 트랜잭션을 수집하고 주문한 후 DON은 이러한 트랜잭션을 메인 체인으로 보냅니다. 따라서 DON의 메인 체인과의 상호 작용은 그대로 유지됩니다. 메인 체인의 채굴자가 관리하는 (잠재적으로 불공평한) 거래 명령이 적용됩니다. 분산형 거래 주문의 이점을 활용하기 위해 대상 스마트 따라서 계약 SC는 DON을 "일류" 시민으로 취급하도록 설계되어야 합니다. 우리 두 가지 접근 방식을 구별합니다. • DON 전용 계약: 가장 간단한 설계 옵션은 메인 체인을 스마트하게 만드는 것입니다. 계약 SC는 DON에 의해 처리된 거래만 수락합니다. 이 smart contract이(가) 제안한 순서대로 트랜잭션을 처리하는지 확인합니다. DON이지만 사실상 smart contract은 위원회 기반 시스템에서 운영되도록 제한됩니다(즉, DON 위원회는 이제 거래 주문 및 포함). • 이중 클래스 계약: 선호되고 보다 세분화된 설계를 통해 메인 체인이 스마트해집니다. 계약 SC는 DON 및 레거시에서 발생하는 트랜잭션을 수락합니다. 사용자10 그러나 DON에 의해 처리되지 않은 거래에는 전통적인 "과속 방지턱"이 적용됩니다. 예를 들어 DON의 거래가 처리될 수 있습니다. 즉시, 레거시 트랜잭션은 smart contract에 의해 "버퍼링"됩니다. 정해진 기간. 선행 실행을 방지하기 위한 기타 표준 메커니즘 커밋-공개 방식이나 VDF [53]과 같은 방식은 레거시에도 적용될 수 있습니다. 거래. 이렇게 하면 DON 주문된 트랜잭션이 처리됩니다. DON에 원치 않는 검열 권한을 부여하지 않고 합의된 명령 거래. FSS의 거래 순서 지정을 위해서는 거래가 "오프체인"으로 집계되어야 하므로 이 솔루션은 자연스럽게 온체인 처리 비용을 줄이기 위한 다른 집계 기술과 결합됩니다. 예를 들어, 수집한 후 거래를 주문하면 DON은 이러한 거래를 메인 체인에 보낼 수 있습니다. 단일 "일괄 트랜잭션"(예: rollup)으로 인해 총 트랜잭션이 줄어듭니다. 수수료. 거래 명령 집행: DON 전용 디자인이든 듀얼 클래스 디자인이든, 메인 체인 smart contract SC와 DON은 DON의 거래 순서가 유지되도록 보장하기 위해 공동 설계되어야 합니다. 여기서도 우리는 다른 것을 상상합니다. 디자인 옵션: • 시퀀스 번호: DON은 각 트랜잭션에 시퀀스 번호를 추가하고 이러한 트랜잭션을 메인 체인의 멤풀로 보낼 수 있습니다. 주요 10DON의 트랜잭션 모니터링이 멤풀을 기반으로 하는 경우 레거시 트랜잭션은 DON 트랜잭션과 구별되어야 DON에 의해 수집되지 않습니다(예: 특수 태그를 통해). 거래에 포함되거나 특정 가스 가격을 지정함으로써 가능합니다. DON 거래에 가스가 있습니다 특정 기준점 이하의 가격.체인 smart contract SC는 "순서가 맞지 않게" 도착하는 트랜잭션을 무시합니다. 우리 이 설정에서 메인 체인 채굴자는 DON을 무시하기로 결정할 수 있습니다. 트랜잭션 주문으로 인해 트랜잭션이 실패하게 됩니다. SC가 올바른 트랜잭션 순서를 강제하도록 (비싼) 상태를 유지함으로써 어느 정도 가능합니다. TCP가 누락된 패킷이 발견될 때까지 순서가 잘못된 패킷을 버퍼링하는 방법과 유사합니다. 받았습니다. • 거래 nonces: 많은 blockchains, 특히 Ethereum의 경우 위의 일련 번호 지정 방식은 내장된 트랜잭션 nonce을 활용하여 다음을 수행할 수 있습니다. 메인 체인 smart contract SC가 트랜잭션을 순서대로 처리하도록 강제합니다. 여기서 DON 노드는 DON 노드 간에 공유되는 키로 보호되는 단일 메인체인 계정을 통해 메인체인에 트랜잭션을 보냅니다. 계정의 transaction nonce은 거래가 올바른 순서로 채굴되고 처리되도록 보장합니다. • 집계 트랜잭션: DON은 rollup에서 여러 트랜잭션을 집계할 수 있습니다. (또는 rollup과 유사한 번들). 메인 체인 smart contract은 다음과 같아야 합니다. 이러한 집계 트랜잭션을 처리하도록 설계되었습니다. • 메인 체인 프록시를 사용한 집계 트랜잭션: 여기서 DON은 마찬가지로 트랜잭션을 메인 체인에 대한 하나의 "메타 트랜잭션"으로 묶지만 사용자 정의 프록시 smart contract를 사용하여 트랜잭션의 압축을 풀고 이를 대상 계약 SC. 이 기술은 레거시 호환성에 유용할 수 있습니다. 메타트랜잭션은 rollup과 유사하게 작동하지만 압축되지 않은 트랜잭션으로 구성된다는 점에서 다릅니다. 메인 체인에 한 번 게시된 거래 목록입니다. 마지막 디자인은 사용자 트랜잭션을 원활하게 지원한다는 장점이 있습니다. DON의 목표에 도달하기 전에 메인 체인 계약을 통해 스스로 프록시됩니다. SC와 계약을 맺다 예를 들어, 어떤 지갑에 거래를 보내는 사용자를 생각해 보세요. 계약은 내부 트랜잭션을 SC로 보냅니다. 시퀀스 할당 사용자의 지갑 계약이 그렇지 않은 경우를 제외하고 그러한 거래에 대한 번호는 까다로울 수 있습니다. 모든 내부 트랜잭션과 함께 시퀀스 번호를 전달하도록 특별히 설계되었습니다. SC. 마찬가지로 이러한 내부 트랜잭션은 SC로 직접 전송되는 메타트랜잭션으로 쉽게 집계될 수 없습니다. 우리는 다음에 대한 추가 설계 고려 사항에 대해 논의합니다. 아래의 프록시 거래. 5.2.2 트랜잭션 원자성 지금까지의 논의에서는 트랜잭션이 단일 개체와 상호작용한다고 암묵적으로 가정했습니다. 온체인 smart contract(예: 사용자가 교환소에 구매 요청을 보냅니다). 그러나 에서는 Ethereum와 같은 시스템에서 단일 트랜잭션은 여러 내부 트랜잭션으로 구성될 수 있습니다. 예를 들어 하나의 smart contract은 다른 계약의 함수를 호출합니다. 아래에서 우리는 "다중 계약" 거래 순서를 지정하기 위한 두 가지 고급 전략을 설명합니다. 트랜잭션의 원자성(즉, 다음에 의해 규정된 일련의 작업)을 보존합니다. 트랜잭션은 모두 올바른 순서로 실행되거나 전혀 실행되지 않습니다.강력한 원자성: 가장 간단한 해결책은 위에서 설명한 대로 FSS를 전체 "다중 계약" 거래에 직접 적용하는 것입니다. 즉, 사용자는 거래를 보냅니다. 네트워크에 들어가고 FSS는 이러한 거래를 모니터링하고 순서를 정하고 게시합니다. 메인 체인. 이 접근 방식은 기술적으로 간단하지만 한 가지 잠재적인 제한 사항이 있습니다. 거래는 공정한 활용을 원하는 두 계약 SC1 및 SC2와 상호 작용합니다. 시퀀싱 서비스를 사용하려면 이 두 계약의 시퀀싱 정책이 일관되어야 합니다. 즉, 각각 상호작용하는 두 개의 서로 다른 트랜잭션 tx1 및 tx2가 있는 경우 SC1과 SC2 모두 SC1의 정책이 tx2보다 먼저 tx1을 주문하는 경우가 있어서는 안 됩니다. SC2의 정책은 반대 순서를 규정합니다. 관심 있는 대부분의 시나리오에 대해 우리는 다양한 계약에서 채택한 순서 정책이 일관될 것이라고 생각합니다. 예를 들어 SC1과 SC2 모두 mempool에 대략적인 도착 시간을 기준으로 트랜잭션을 정렬하기를 원할 수 있습니다. SC1은 특정 oracle 보고서가 항상 먼저 전달되기를 원할 수도 있습니다. 다음과 같이 후자의 oracle 보고서 트랜잭션은 SC2와 상호 작용하지 않으며 정책은 일관됩니다. 약한 원자성: 일반적으로 FSS는 개인 수준에서 적용될 수 있습니다. 내부 거래. 일부 초기 항목으로 구성된 tx = { ~txpre, ~txSC, ~txpost} 형식의 트랜잭션을 고려하십시오. 트랜잭션 ~txpre, 이는 SC에서 내부 트랜잭션 ~txSC로 이어지며, 이는 차례로 내부 트랜잭션 ~txpost를 발행합니다. SC의 시퀀싱 정책에 따라 방법이 결정될 수 있습니다. 내부 트랜잭션 ~txSC는 전송된 다른 트랜잭션과 관련하여 주문되어야 합니다. SC로 이동하되 ~txpre 및 ~txpost에 대한 시퀀스 순서는 열어 둡니다. Ethereum과 같은 시스템에서 트랜잭션 처리의 본질적인 특성을 고려할 때 특정 내부 트랜잭션을 대상으로 하는 시퀀싱 서비스를 개발하는 것은 간단하지 않습니다. 특별히 설계된 계약 SC를 사용하면 다음과 같이 실현할 수 있습니다. 1. 트랜잭션 tx가 네트워크로 전송되어 채굴됩니다(시퀀싱 없이). FSS에서 수행). 초기 ~txpre가 실행되고 ~txSC를 호출합니다. 2. SC는 ~txSC를 실행하지 않고 반환됩니다. 3. FSS는 SC에 대한 내부 거래를 모니터링하고 순서를 정한 후 다시 게시합니다. SC로(즉, 트랜잭션 ~txSC를 SC로 직접 보냄) 4. SC는 FSS로부터 받은 트랜잭션 ~txSC를 처리하고, ~txSC의 결과인 내부 트랜잭션 ~txpost를 발행합니다. 이 접근 방식을 사용하면 트랜잭션이 완전히 원자적으로 실행되지 않습니다(즉, 원본 트랜잭션 tx는 여러 개의 온체인 트랜잭션으로 분할되지만 순서는 내부 거래는 보존됩니다. 이 솔루션에는 여러 가지 설계 제약이 따릅니다. 예를 들어 ~txpre는 다음을 수행할 수 없습니다. ~txSC 및 ~txpost가 실행될 것이라고 가정합니다. 더욱이 SC는 다음과 같이 설계되어야 한다. 특정 사용자를 대신하여 ~txSC 및 ~txpost 트랜잭션을 실행합니다.FSS에서 보냈습니다. 이러한 이유로 보다 세분화된 "Strong Atomicity" 솔루션 실제로는 위의 내용이 바람직할 수 있습니다. 여러 트랜잭션과 관련된 보다 복잡한 종속성을 존중하기 위해 각각의 내부 거래에는 FSS의 거래 스케줄러가 포함될 수 있습니다. 관계형 트랜잭션 관리자에서 볼 수 있는 것과 유사한 정교한 기능 데이터베이스 관리자. 5.3 공정한 거래 순서 여기에서는 FSS에 의해 실현될 수 있는 거래 순서 결정 및 해당 구현에 대한 두 가지 공정성 개념에 대해 논의합니다. 정책 기반 주문 공정성 FSS에 의해 부과되며 인과관계 보존을 보장하므로 FSS에 추가적인 암호화 방법이 필요합니다. 주문 공정성: 질서 공정성은 합의 프로토콜에서 시간적 공정성에 대한 개념입니다. Kelkar et al.에 의해 처음으로 공식적으로 소개되었습니다. [144]. Kelkaret al. 거래가 이루어지는 자연정책의 형태를 달성하는 것을 목표로 합니다. DON(또는 P2P 네트워크, mempool 기반 FSS의 경우). 그러나 분산형 시스템에서는 다릅니다. 노드는 트랜잭션이 다른 순서로 도착하는 것을 볼 수 있습니다. 전체 주문 설정 모든 거래에 대한 문제는 기반이 되는 합의 프로토콜에 의해 해결되는 바로 그 문제입니다. 메인체인. Kelkaret al. [144] 따라서 다음과 같은 약한 개념을 도입합니다. 이는 "블록 주문 공정성"이라고 불리는 분산형 Oracle 네트워크의 도움으로 달성됩니다. DON이(가) 일정 시간 간격 동안 수신한 트랜잭션을 다음과 같이 그룹화합니다. 블록을 생성하고 해당 블록의 모든 트랜잭션을 동시에 동일한 위치에 삽입합니다. (즉, 높이)를 MAINCHAIN에 넣습니다. 따라서 이들은 함께 주문되며 실행 가능해야 합니다. 동시에, 그들 사이에 어떤 갈등도 일으키지 않습니다. 대략적으로 말하자면, 주문 공정성은 많은 노드가 τ2 이전에 트랜잭션 τ1을 본다면 다음과 같이 말합니다. τ1은 τ2 이전 또는 동일한 블록에서 시퀀스됩니다. 이런 거친 짓을 해서 거래 주문을 세분화하면 선행 실행 및 기타 주문 관련 공격 기회가 크게 줄어듭니다. Kelkaret al. Aequitas [144]라는 프로토콜 제품군을 제안합니다. 동기식, 부분 동기식, 비동기식 네트워크 설정을 포함한 다양한 배포 모델. Aequitas 프로토콜은 기본 BFT 합의에 비해 상당한 통신 오버헤드를 부과하므로 실제 사용에는 적합하지 않습니다. 그러나 우리는 사용할 수 있는 Aequitas의 실용적인 변형이 나타날 것이라고 믿습니다. FSS 및 기타 애플리케이션의 트랜잭션 순서 지정을 위한 것입니다. 일부 관련 계획에는 형식주의와 속성이 덜 수반되는 방식이 이미 제안되었습니다. 예를 들어 [36, 151, 236]이지만 실제 성능이 더 좋습니다. 이러한 구성표가 지원될 수 있습니다. FSS에서도요. "공정성"이라는 용어가 blockchain의 다른 곳에 나타난다는 점도 주목할 가치가 있습니다. 다른 의미를 지닌 문학, 즉 기회라는 의미에서의 공정성헌신된 자원 [106, 181] 또는 validators에 비례하는 광부 평등한 기회 [153]. 안전한 인과관계 보존: 분산 플랫폼에서 선행 실행 및 기타 주문 위반을 방지하는 가장 널리 알려진 접근 방식은 암호화에 의존합니다. 기술. 그들의 일반적인 특징은 거래 데이터 자체를 숨기고 합의 계층의 순서가 확립되었으며 거래 데이터를 공개합니다. 나중에 처리를 위해. 이는 거래 간의 인과적 순서를 보존합니다. blockchain에 의해 실행됩니다. 관련 보안 개념 및 암호화 프로토콜 blockchains [71, 190]이 출현하기 전에 상당히 개발되었습니다. "입력 인과성" [190] 및 "안전한 인과성 보존"[71, 97]의 보안 조건은 거래에 대한 정보가 알려지지 않도록 공식적으로 요구합니다. 글로벌 순서에서 이 거래의 위치가 결정되기 전에. 공격자는 그때까지 암호화된 방식으로 어떤 정보도 추론할 수 없어야 합니다. 강한 감각. 인과관계를 보존하기 위해 네 가지 암호화 기술을 구별할 수 있습니다. • 커밋-공개 프로토콜 [29, 142, 145]: 트랜잭션이 발표되는 대신 명확하게는 거래에 대한 암호화된 약속만 공개됩니다. 모든 커밋되었지만 숨겨진 트랜잭션이 주문된 후(blockchain 초기에) MAINCHAIN 자체의 시스템(여기서는 FSS에 의한 시스템)에서 보낸 사람은 미리 결정된 시간 간격 내에 약속을 열고 거래 데이터를 공개해야 합니다. 그런 다음 네트워크는 개시가 이전 약속을 충족하는지 확인합니다. 는 이 방법의 기원은 blockchains 출현 이전입니다. 비록 매우 간단하지만 이 접근 방식은 상당한 단점을 가져오고 두 가지 이유로 사용하기 쉽지 않습니다. 첫째, 주문 프로토콜 수준에서는 커밋만 존재하므로 트랜잭션의 의미는 다음과 같습니다. 합의 중에는 검증할 수 없습니다. 클라이언트까지의 추가 왕복 필요합니다. 그러나 더 심각한 것은 개봉이 불가능할 가능성에 무게를 두고 있습니다. 이는 서비스 거부 공격에 해당할 수 있습니다. 게다가, 그것은 일관되고 분산된 방식으로 오프닝이 유효한지 여부를 결정하는 것은 어렵습니다. 왜냐하면 모든 참가자는 오프닝이 도착했는지 여부에 동의해야 하기 때문입니다. 시간. • 지연된 복구가 포함된 커밋-공개 프로토콜 [145]: 커밋-공개 접근 방식은 클라이언트가 추측에 따라 트랜잭션을 커밋하고 후속 트랜잭션으로 인해 수익성이 있는 경우에만 이를 공개할 수 있다는 것입니다. 에이 커밋-공개 접근 방식의 최근 변형은 이에 대한 탄력성을 향상시킵니다. 일종의 잘못된 행동. 특히 TEX 프로토콜 [145]은 이 문제를 해결합니다. 암호화된 트랜잭션에 암호 해독 키가 포함되는 영리한 접근 방식을 사용합니다. 검증 가능한 지연 함수(VDF)를 계산하여 얻을 수 있습니다[53, 221]. 클라이언트인 경우 적시에 그녀의 거래를 해독하지 못하면 시스템의 다른 사람들이 해독합니다. 그녀를 대신하여 적당히 어려운 암호화 퍼즐을 해결합니다.• 임계값 암호화 [71, 190]: 이 방법은 DON이 수행할 수 있는 기능을 활용합니다. 임계값 암호화 작업. FSS가 공개 암호화를 유지한다고 가정합니다. 키 pkO와 oracle은 해당 개인 키를 서로 공유합니다. 그런 다음 클라이언트는 pkO에서 거래를 암호화하여 FSS로 보냅니다. FSS 주문 DON의 트랜잭션을 해독한 후 마지막으로 DON에 삽입합니다. MAINCHAIN은 고정된 순서로 진행됩니다. 따라서 암호화는 주문이 거래 내용을 기반으로 하는 것이 아니라 데이터 자체를 다음과 같은 경우에 사용할 수 있습니다. 필요합니다. 이 방법은 원래 Reiter와 Birman([190])에 의해 제안되었으며 나중에 Cachin 등에 의해 개선되었습니다. [71], 허가된 합의와 통합되었습니다. 프로토콜. 보다 최근의 연구에서는 임계값 암호화를 다음과 같이 사용하는 방법을 연구했습니다. 일반 메시지 [33, 97] 및 공유 데이터 [41]를 사용한 일반 계산을 위한 합의 수준 메커니즘. 커밋 공개 프로토콜과 비교하여 임계값 암호화는 단순한 서비스 거부 공격을 방지합니다(암호 해독에 드는 계산 비용을 고려할 때 주의가 필요함). DON이(가) 자체 속도로 자동으로 진행되도록 합니다. 추가 클라이언트 작업을 기다리고 있습니다. 거래는 해독된 후 즉시 검증될 수 있습니다. 또한 클라이언트는 모든 거래를 하나로 암호화합니다. DON의 키이며 통신 패턴은 다른 키와 동일하게 유지됩니다. 거래. 임계값 키를 안전하게 관리하고 노드를 변경하여 그러나 O는 추가적인 어려움을 초래할 수 있습니다. • 커밋된 비밀 공유 [97]: 거래 데이터를 암호화하는 대신 DON이 보유한 키인 경우 클라이언트는 이를 O의 노드에 대해 비밀 공유할 수도 있습니다. 하이브리드, 계산적으로 안전한 비밀 공유 방식을 사용하여 트랜잭션 먼저 임의의 키가 있는 대칭 암호를 사용하여 암호화됩니다. 해당 대칭 키만 공유되고 암호문은 DON에 제출됩니다. 클라이언트는 별도로 암호화된 메시지를 사용하여 O의 각 노드에 하나의 키 공유를 보내야 합니다. 나머지 프로토콜 단계는 임계값과 동일합니다. 단, 거래 데이터는 대칭형으로 해독됩니다. 공유에서 트랜잭션별 키를 재구성한 후 알고리즘을 사용합니다. 이 방법에는 공개 키 암호화 시스템의 설정이나 관리가 필요하지 않습니다. DON과 연결되어 있습니다. 그러나 클라이언트는 다음 노드에 대해 알고 있어야 합니다. O 그리고 그들 각각과 안전한 상황에서 통신합니다. 고객의 추가 부담. 암호화 방법은 정보로부터 완전한 보호를 제공하지만 제출된 트랜잭션에서 네트워크로 유출되는 경우 메타데이터를 숨기지 않습니다. 에 대한 예를 들어, 발신자의 IP 주소 또는 Ethereum 주소는 계속해서 사용될 수 있습니다. 전방 공격 및 기타 공격을 수행하는 적입니다. 다양한 프라이버시 강화 네트워크 계층(예: [52, 95, 107]) 또는 트랜잭션 계층에 배포된 기술, 예를 들어, [13, 65]는 이 목표를 달성하는 데 필요할 것입니다. 특정 작품의 영향 즉, 거래가 전송되는 계약에 대한 메타데이터를 (부분적으로) 숨길 수 있습니다.동일한 DON에서 많은 계약을 다중화함으로써. 암호화 은폐 거래 자체도 손상된 거래의 우선순위를 방해하지 않습니다. DON 노드가 거래 발신자와 공모하고 있습니다. 암호화 프로토콜에 의해 보장되는 안전한 인과관계는 모든 정책에 대한 질서 공정성 보장을 보완하며, 우리는 이 두 가지의 조합을 탐색할 계획입니다. 가능한 경우 방법. 상대방이 상당한 이점을 얻을 수 없는 경우 메타데이터를 관찰하면서 안전한 인과관계 보존 프로토콜을 함께 사용할 수 있습니다. 순진한 주문 방식도 마찬가지입니다. 예를 들어 oracle 노드는 트랜잭션을 작성할 수 있습니다. 중복 없이 L에게 수신 즉시 전달됩니다. 그러면 거래는 다음과 같습니다. L에 나타나는 순서에 따라 주문한 후 해독됩니다. 우리는 또한 공정한 주문을 집행하는 데 도움이 되는 방법으로 TEE 사용을 고려할 계획입니다. 에 대한 예를 들어, Tesseract [44]는 인과적 순서의 형태를 달성하는 것으로 볼 수 있지만 명시적인 형식으로 거래를 처리하는 TEE의 능력으로 강화되었습니다. 기밀을 유지합니다. 5.4 네트워크 계층 고려 사항 지금까지 FSS에 대한 설명은 주로 다음 사항을 집행하는 문제에 중점을 두었습니다. 최종 거래 순서는 네트워크에서 관찰된 순서와 일치합니다. 이후, 네트워크 계층 자체에서 발생할 수 있는 공정성 문제를 고려합니다. 기존 전자 시장의 고주파 거래자는 상당한 투자를 합니다. 우수한 네트워크 속도를 얻기 위한 리소스 [64], 암호화폐 거래소의 거래자는 유사한 행동 [90]을 나타냅니다. 네트워크 속도는 두 측면 모두에서 이점을 제공합니다. 다른 당사자의 거래를 관찰하고 경쟁 거래를 제출하는 행위. Flash Boys [155] 책에서 실제로 배포되고 대중화된 한 가지 치료법은 다음과 같습니다. IEX 거래소 [128]에서 처음 도입된 "과속 방지턱"은 나중에 다른 거래소에서도 도입되었습니다. [179]을 교환합니다(혼합된 결과 [19] 포함). 이 메커니즘은 시장 접근에 지연(IEX의 경우 350마이크로초)을 부과합니다. 속도. 경험적 증거. [128], 특정 거래 감소에 대한 효율성을 지원합니다. 일반 투자자의 비용. FSS는 단순히 비대칭을 구현하는 데 사용될 수 있습니다. 과속방지턱 - 들어오는 거래를 지연시키는 것입니다. Budish, Cramton 및 Shim [64]은 속도 이점을 활용한다고 주장합니다. 연속시장에서는 피할 수 없으며, 구조적 해결책을 주장합니다. 일괄 경매 기반 시장의 형태. 그러나 이 접근 방식은 널리 받아들여지지 않았습니다. 기존 거래 플랫폼에서. 기존 거래 시스템은 중앙 집중화되어 있으며 일반적으로 다음을 통해 거래를 받습니다. 단일 네트워크 연결. 대조적으로, 분산형 시스템에서는 다음이 가능합니다. 여러 유리한 지점에서 트랜잭션 전파를 관찰합니다. 결과적으로, P2P 네트워크에서는 네트워크 플러딩과 같은 행위를 관찰할 수 있습니다. 우리는 의도한다 개발자가 정책을 지정하는 데 도움이 되는 FSS에 대한 네트워크 계층 접근 방식을 탐색합니다. 그러한 바람직하지 않은 네트워크 행위를 금지합니다.5.5 엔터티 수준의 공정성 정책 주문 공정성과 안전한 인과성은 다음과 같은 거래에 대한 주문을 시행하는 것을 목표로 합니다. 생성되어 네트워크에 처음 제출된 시간을 존중합니다. 이러한 공정성 개념의 한계는 상대방이 공격하는 것을 방지하지 못한다는 것입니다. 거래가 많은 시스템이 넘쳐 이점을 얻는다. token 판매 [159]에서 효과적인 거래 저격을 수행하는 방법으로 야생에서 CDP(부채담보포지션) 청산으로 인한 혼잡 발생 [48]. 즉, 주문 공정성은 플레이어가 아닌 거래에 대한 공정성을 강화합니다. CanDID 시스템 [160]에 나와 있듯이 DECO와 같은 oracle 도구를 사용할 수 있습니다. 또는 노드 위원회(예: DON)와 함께 Town Crier를 통해 달성할 수 있습니다. 개인 정보를 보호하면서 다양한 형태의 Sybil 저항을 제공합니다. 사용자는 신원을 등록할 수 있습니다. 신원 자체를 공개하지 않고 고유성에 대한 증거를 제공합니다. 시빌 방지 자격 증명은 트랜잭션 주문을 강화하는 가능한 접근 방식을 제공합니다. 홍수 공격의 기회를 제한하는 방식으로 정책을 시행합니다. 예를 들어, token 판매는 등록된 사용자당 하나의 거래만 허용할 수 있습니다. 사회보장번호와 같은 국가 식별자의 고유성 증명이 필요합니다. 이러한 접근 방식이 완벽하지는 않지만 트랜잭션 플러딩 공격을 완화하는 데 유용한 정책이 될 수 있습니다.
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.
DON 트랜잭션 실행 프레임워크
(DON-TEF) DONs는 oracle 및 레이어 2 솔루션에 대한 분산형 리소스 지원을 제공합니다. 우리는 분산형 Oracle 네트워크 트랜잭션 실행 프레임워크(DONTEF) 또는 줄여서 TEF라고 부릅니다. 현재 DeFi 계약에 대한 업데이트 빈도는 메인 체인 지연 시간으로 인해 제한됩니다. 예를 들어 Ethereum [104]의 10-15초 평균 블록 간격과 체인에 대량의 데이터를 푸시하고 계산/전송 처리량이 제한됨 샤딩 [148, 158, 232] 및 레이어 2 실행 [5, 12, 121, 141, 169, 186, 187]. 거래 시간이 훨씬 빠른 blockchains라도, 예를 들어 [120]은 오프체인 계산 [168]과 관련된 확장 전략을 제안했습니다. TEF는 이러한 레이어 1/MAINCHAIN 시스템에 대한 레이어 2 리소스 역할을 하기 위한 것입니다. TEF를 사용하면 DONs는 MAINCHAIN 계약에서 더 빠른 업데이트를 지원할 수 있습니다. 메인 체인이 제공하는 주요 신뢰 보증을 유지합니다. TEF는 지원할 수 있습니다 rollups11을 포함한 다양한 레이어 2 실행 기술 및 패러다임 중 하나 낙관적인 rollups, Validium 등 및 DON이 포함된 임계 신뢰 모델 노드는 트랜잭션을 실행합니다. TEF는 FSS를 보완하며 이를 지원하기 위한 것입니다. 즉, 어떤 TEF에서 실행되는 애플리케이션은 FSS를 사용할 수 있습니다. 11영지식 증명이 반드시 필요하지 않기 때문에 종종 "zk-rollups"라고 부르는데 이는 잘못된 명칭입니다.
6.1 TEF 개요 TEF는 고성능 하이브리드의 구축 및 실행을 위한 설계 패턴입니다. smart contract SC. 하이브리드 smart contracts의 기본 아이디어에 따라 TEF에는 다음이 포함됩니다. SC를 두 부분으로 분해: (1) TEF 맥락에서 앵커라고 부르는 것 MAINCHAIN에서 SCa를 계약하고 (2) DON 로직은 TEF 실행 파일을 호출하도록 선택합니다. 여기서는 SCa의 조합으로 구현된 논리적 계약을 나타내기 위해 SC를 사용합니다. 그리고 실행하십시오. (위에서 언급했듯이 우리는 SC를 자동으로 이러한 구성 요소로 변환합니다.) TEF 실행 파일 exect는 SC에서 사용자의 트랜잭션을 처리하는 엔진입니다. 그것 DON에서 실행되므로 성능이 뛰어난 방식으로 실행될 수 있습니다. 여기에는 여러 가지 기능이 있습니다. • 트랜잭션 수집: Exect는 사용자의 트랜잭션을 수신하거나 가져옵니다. 그렇게 할 수 있다 직접, 즉 DON에 대한 거래 제출을 통해 또는 MAINCHAIN을 통해 MS를 이용한 멤풀. • 빠른 거래 실행: Exect는 자산과 관련된 거래를 처리합니다. SC. 즉, DON에서 로컬로 수행됩니다. • 빠르고 저렴한 oracle / 어댑터 액세스: exect는 oracle 보고서에 대한 기본 액세스 권한을 가집니다. 예를 들어 더 빠르고 저렴하며 더 정확한 자산으로 이어지는 기타 어댑터 데이터 MAINCHAIN 실행보다 가격이 책정됩니다. 게다가 오프체인 oracle 액세스가 감소합니다. oracle의 운영 비용, 즉 시스템 사용 비용 값비싼 온체인 스토리지. • 동기화: Exect는 주기적으로 DON의 업데이트를 MAINCHAIN에 푸시하여 SCa를 업데이트합니다. 앵커 계약은 SC의 MAINCHAIN 프런트 엔드입니다. SC의 신뢰도가 높은 구성 요소로서 다음과 같은 여러 목적을 수행합니다. • 자산 보관: 사용자의 자금은 SCa에 예치, 보관 및 인출됩니다. • 동기화 확인: SCa는 실행 시 상태 업데이트의 정확성을 확인할 수 있습니다. 동기화(예: rollups에 연결된 SNARK). • 가드레일: SCa에는 손상이나 고장으로부터 보호하기 위한 조항이 포함될 수 있습니다. 예를 들어. (자세한 내용은 섹션 7을 참조하세요.) TEF에서 사용자의 자금은 MAINCHAIN에 관리됩니다. 즉, DON 자체는 비관리적입니다. 선택한 동기화 메커니즘(아래 참조)에 따라 사용자는 다음이 필요할 수 있습니다. 정확한 oracle 보고서와 MAINCHAIN과의 적시 동기화를 위해서만 DON을 신뢰하십시오. 결과적인 신뢰 모델은 주문서 기반 DEX(예: [2])의 모델과 매우 유사합니다. 오늘날 여기에는 일반적으로 주문 매칭을 위한 오프체인 구성요소와 청산 및 결제를 위한 온체인 구성요소가 포함됩니다.지불 시스템의 용어를 사용하려면 exec를 구성 요소로 생각할 수 있습니다. SC는 청산을 담당하고 SCa는 결제를 담당합니다. 회로도는 그림 13을 참조하세요. TEF의 묘사. 그림 13: TEF 회로도. 이 예에서 트랜잭션은 mempool을 통과합니다. MS를 통해 MAINCHAIN을 DON로 보냅니다. TEF 혜택: TEF는 세 가지 주요 이점을 제공합니다. • 고성능: SC는 MAINCHAIN보다 DON의 훨씬 높은 처리량을 상속합니다. 거래 및 oracle 보고서 모두에 대해. 또한 Exect는 MAINCHAIN 단독 구현보다 트랜잭션을 더 빠르게 처리하고 oracle 보고서에 적시에 응답할 수 있습니다. • 낮은 수수료: 동기화 프로세스는 트랜잭션 처리보다 시간에 덜 민감하며 트랜잭션은 DON에서 MAINCHAIN으로 일괄적으로 전송될 수 있습니다. 결과적으로, 이 접근 방식을 사용하면 트랜잭션당 온체인 수수료(예: 가스 비용)가 MAINCHAIN에서만 실행되는 계약보다 훨씬 낮습니다. • 기밀성: DON의 기밀성 메커니즘을 가져올 수 있습니다. SC에 곰.
TEF 제한사항: TEF의 한 가지 제한 사항은 순간적인 기능을 지원하지 않는다는 것입니다. MAINCHAIN에서만 발생하는 출금: 출금 요청을 보낼 때 SCa에 대해 사용자는 exec가 포함된 상태 업데이트를 수행할 때까지 기다려야 할 수도 있습니다. 인출 거래가 승인되기 전에. 우리는 부분적인 해결 방법을 논의합니다. 그러나 섹션 6.2. TEF의 또 다른 제한 사항은 DeFi의 원자 구성을 지원하지 않는다는 것입니다. MAINCHAIN 계약, 특히 여러 DeFi을 통해 자산을 라우팅하는 기능 단일 거래로 계약을 체결합니다. 그러나 TEF는 이러한 원자성을 지원할 수 있습니다. DeFi 계약은 동일한 DON에서 실행됩니다. 또한 이 문제를 해결하는 몇 가지 방법에 대해서도 논의합니다. 6.2절의 문제. 6.2 거래 라우팅 SC에 대한 거래는 사용자가 DON로 직접 보내거나 다음을 통해 라우팅될 수 있습니다. MAINCHAIN의 멤풀(FSS를 통해). 4가지의 서로 다른 거래 유형이 있으며, 각각 그 중 다른 처리가 필요합니다. 계약 내 거래: TEF는 가스 역학의 복잡성을 회피하기 때문에 SC에 트랜잭션 처리에 있어 다른 것보다 더 많은 유연성을 제공합니다. 레이어-1 계약에서 사용 가능합니다. 예를 들어, Ethereum의 mempool 트랜잭션이 있는 동안 가스 가격이 더 높은 새로운 거래로 덮어쓸 수 있으며, SC는 SC 내 자산에서 운영되는 거래가 눈에 보이는 즉시 권위 있는 거래로 처리할 수 있습니다. 멤풀에서. 결과적으로 SC는 거래가 확인될 때까지 기다릴 필요가 없습니다. 블록 내에서 지연 시간이 크게 단축됩니다. 프록시: 사용자는 지갑 계약을 통해 SC에 거래 τ를 보내거나 MAINCHAIN의 다른 계약. DON에서 실행을 시뮬레이션하는 것이 가능합니다. MAINCHAIN에서 τ를 수행하여 SC에 대한 후속 트랜잭션이 발생하는지 여부를 결정합니다. 그렇다면 τ는 SC에 대한 다른 트랜잭션과 순서를 지정할 수 있습니다. 몇 가지가 있습니다 DON이 그러한 거래를 식별하는 방법에 대한 가능성: (1) DON은 시뮬레이션할 수 있습니다 mempool의 모든 트랜잭션(비용이 많이 드는 접근 방식) (2) 특정 계약 또는 지갑과 같은 계약 유형은 DON에 의해 모니터링을 위해 나열될 수 있습니다. 또는 (3) 사용자는 다음을 수행할 수 있습니다. DON 검사를 위해 거래에 주석을 답니다. 단일 거래가 두 거래와 상호 작용할 때 문제는 더욱 복잡해집니다. SC1 및 SC2 계약은 둘 다 Fair Sequencing Services를 사용하고 호환되지 않는 주문 정책을 가지고 있습니다. 예를 들어 DON은 가장 최근에 τ를 시퀀스할 수 있습니다. 그것은 둘 다와 호환됩니다. 예금: MAINCHAIN 자산을 SC에 예치하는 거래는 SC가 이를 유효한 것으로 처리하기 전에 블록에서 확인되어야 합니다. 채굴이 감지되면 자산(예: Ether)을 SCa로 보내는 거래는 즉시 확인할 수 있습니다.보증금. 예를 들어, DON에 대해 현재 oracle 보고된 가격을 적용할 수 있습니다. 자산. 인출: 위에서 언급했듯이 TEF의 한계는 인출이 항상 즉시 실행될 수 없다는 것입니다. rollup 유형 실행 모델에서는 철회가 요청은 안전하게 처리되기 위해 다른 트랜잭션과 순서대로 처리되어야 합니다. 즉, 롤업되어야 합니다. 처리됨. 그러나 이 제한 사항에 대한 몇 가지 부분적인 해결 방법이 있습니다. DON이 인출 트랜잭션까지 rollup 유효성 증명을 신속하게 계산할 수 있다면 mempool exect에서 사용자의 트랜잭션 τ를 관찰하면 일종의 유익한 선행 실행인 더 높은 가스 가격으로 τ에 대한 상태 업데이트 트랜잭션 τ'를 보낼 수 있습니다. τ'가 멤풀에 도달하기 전에 τ가 채굴되지 않으면 τ'가 τ보다 먼저 발생하고 τ가 채굴됩니다. 승인된 철회에 영향을 미칩니다. 상태 업데이트를 계산하기 위해 DON을 사용하는 TEF 변형에서(참조: 아래의 임계값 서명 변형), DON는 대안으로 오프체인을 결정할 수 있습니다. 실행 시 SC의 상태를 고려하여 τ를 승인해야 하는지 여부. DON 그러면 전체 금액에 영향을 주지 않고 인출 τ를 승인하는 거래 τ'를 보낼 수 있습니다. 상태 업데이트. 이 접근 방식이 불가능하거나 성공하지 못하는 경우 DON에서 시작된 거래 τ'는 τ에 대한 응답으로 사용자에게 자금을 보낼 수 있으므로 사용자는 그럴 필요가 없습니다. 추가 거래를 시작합니다. 6.3 동기화 중 TEF 실행 파일 exect는 주기적으로 DON에서 MAINCHAIN으로 업데이트를 푸시합니다. 동기화라고 하는 프로세스에서 SCa 상태를 업데이트합니다. 동기화를 생각해 볼 수 있습니다. 레이어 2 트랜잭션을 레이어 1로 전파하므로 TEF는 다음 중 하나를 활용할 수 있습니다. rollups [5, 12, 16, 69]를 포함하여 이 목적을 위한 기존 기술의 낙관적 rollups [10, 11, 141], Validium [201] 또는 기본 임계값 서명(예: 임계값 BLS, Schnorr, 또는 ECDSA [24, 54, 116, 202]. 원칙적으로 신뢰할 수 있는 실행 환경 또한 상태 변경의 정확성을 증명할 수 있어 훨씬 더 나은 성능을 제공합니다. rollups를 대체하지만 하드웨어 종속 신뢰 모델을 사용합니다. (예: [80] 참조) 아래에서는 세 가지 주요 속성과 관련하여 이러한 동기화 옵션을 비교합니다. TEF: • 데이터 가용성: SC의 상태는 어디에 저장됩니까? 최소한 세 가지 옵션이 있습니다. TEF에서 사용 가능: MAINCHAIN, DON 또는 일부 타사 저장소에서 사용 가능 IPFS와 같은 공급자. 그들은 다양한 보안 보장, 가용성을 달성합니다. 수준 및 성능 프로필. 간략하게, MAINCHAIN에 상태를 저장하면 온체인 감사 가능성을 제공하고 상태 가용성에 대한 모든 당사자에 대한 의존성을 제거합니다. 반면에 상태를 오프체인에 저장하면 저장 비용을 줄이고 성능을 향상할 수 있습니다. 처리량은 신뢰할 수 있는 스토리지 제공업체(DON 또는 제3자)의 비용으로 데이터 가용성. 물론 이러한 옵션을 결합한 유연한 모델도 있습니다. 가능합니다. 표 1에는 필요한 데이터 가용성 형식이 나와 있습니다.• 정확성 보장: SCa는 업데이트의 정확성을 어떻게 확인합니까? exect에 의해 밀렸나요? 이는 Exect 및 SCa의 계산 부하에 영향을 미치며 동기화 대기 시간(아래 참조) • 지연 시간: 동기화 지연 시간에는 세 가지 요인이 있습니다. (1) 소요 시간 동기화 트랜잭션 τsync를 생성하기 위해; (2) τsync에 걸리는 시간 MAINCHAIN에서 확인됩니다. (3) τsync가 효과를 발휘하는 데 걸리는 시간 SCa. TEF에서 지연 시간은 인출에 특히 중요합니다(그러나 인출의 경우에는 덜 중요함). 계약 내 거래) 인출에는 필연적으로 (적어도 부분) 상태 동기화. 동기화 중 옵션 데이터 가용성 정확성 보증 대기 시간 롤업 [5, 12, 16, 69] 온체인 유효성 증명 생성하는데 걸리는 시간 유효성 증명(예: 현재 시스템의 분) 유효성 검사 [201] 오프체인 유효성 증명 위와 동일 낙관적 rollup [10, 11, 141] 온체인 사기 증명 도전의 길이 기간 (예: 일 또는 주) 임계값 서명 [24, 54, 116, 202] 유연한 DON의 임계값 서명 순간적인 신뢰할 수 있는 실행 환경 [80] 유연한 하드웨어 기반 증명 순간적인 표 1: TEF 및 해당 속성의 다양한 동기화 옵션. 표 1에는 TEF의 5가지 주요 동기화 옵션에 대한 이러한 속성이 요약되어 있습니다. (참고 이러한 기술을 독립형 레이어 2 확장과 비교하려는 의도는 없습니다. 솔루션. 이를 위해 독자들에게 [121]을 참조하라고 합니다.) 이제 각 동기화 옵션에 대해 설명합니다. 롤업: rollup [69]은 상태 전환이 다음에 의해 영향을 받는 프로토콜입니다. 일괄 거래는 오프체인으로 계산됩니다. 그런 다음 상태 변경이 전파됩니다. MAINCHAIN에. rollups를 구현하기 위해 앵커 smart contract SCa는 실제 상태의 압축 표현 Rstate(예: Merkle 루트)를 저장합니다. 동기화하려면 Exec가 τsync =를 보냅니다. (티, R' 상태)를 SCa로 변환합니다. 여기서 T는 마지막 이후 처리한 트랜잭션 집합입니다.동기화 및 R' 상태는 다음을 적용하여 계산된 새 상태의 간략한 표현입니다. T의 이전 상태 Rstate로의 트랜잭션. SCa가 τsync에서 상태 업데이트를 확인하는 방법에는 두 가지 인기 있는 변형이 있습니다. 첫 번째 (zk-)rollups는 정확성에 대한 간결한 주장을 첨부합니다. Rstate →R′ 전이에 대한 유효성 증명 상태. 이 변형을 구현하려면 다음을 실행하세요. τsync와 함께 유효성 증명(예: zk-SNARK 증명)을 계산하고 제출합니다. R′을 증명하는 것 state는 SCa의 현재 상태에 T를 적용한 결과입니다. 앵커 계약은 증명을 확인한 후에만 상태 업데이트를 수락합니다. 낙관적 rollup에는 정확성 인수가 포함되지 않지만 staking 및 상태 전환의 분산 검증을 용이하게 하는 챌린지 절차. 이를 위해 rollup 변형, SCa는 그것이 정확하다고 가정하여 잠정적으로 τsync를 받아들입니다(따라서 낙관적입니다). 그러나 τsync는 챌린지 기간 이후까지 적용되지 않습니다. MAINCHAIN을 모니터링하면 잘못된 상태 업데이트를 식별하고 SCa에게 이를 수행하도록 알릴 수 있습니다. 필요한 조치(예: 상태를 롤백하고 실행 시 페널티를 적용하는 등) rollup 두 변종 모두 트랜잭션이 게시됨에 따라 온체인 데이터 가용성을 달성합니다. 전체 상태를 구성할 수 있는 온체인입니다. zk-rollups의 대기 시간은 다음과 같습니다. 일반적으로 타당성 증명을 생성하는 데 필요한 시간이 지배적입니다. 기존 시스템에서는 몇 분 정도 소요되며 [16] 시간이 지남에 따라 개선될 가능성이 높습니다. 반면 낙관적인 rollup은 지연 시간이 더 깁니다(예: 며칠 또는 몇 주). 사기 증명이 작동하려면 챌린지 기간이 충분히 길어야 하기 때문입니다. 는 느린 확인의 의미는 미묘하고 때로는 계획에 따라 구체적입니다. 철저한 분석은 범위를 벗어납니다. 예를 들어, 특정 계획에서는 지불을 고려합니다. 상태 업데이트가 확인되기 전에 트랜잭션을 "무신뢰 최종"으로 [109] 일반 사용자는 MAINCHAIN보다 훨씬 빠르게 rollup을 확인할 수 있습니다. 유효성: Validium은 데이터를 오프체인에서만 사용할 수 있도록 하는 (zk-)rollup의 한 형태입니다. MAINCHAIN의 모든 데이터를 유지하지 않습니다. 구체적으로 exec는 새 항목만 보냅니다. 상태 및 증거는 있지만 SCa에 대한 거래는 아닙니다. Validium 스타일 동기화를 사용하면 다음과 같습니다. 이를 실행하는 DON은 완전한 상태를 저장하는 유일한 당사자입니다. 트랜잭션을 실행하는 것입니다. zk-rollups와 마찬가지로 동기화 대기 시간은 유효성에 의해 좌우됩니다. 증명 생성 시간. 그러나 zk-rollups와 달리 Validium 스타일 동기화는 스토리지 비용이 증가하고 처리량이 증가합니다. DON에 의한 임계값 서명: DON 노드의 임계값이 정직하다고 가정하면, 간단하고 빠른 동기화 옵션은 DON 노드가 새로운 상태에 집합적으로 서명하도록 하는 것입니다. 이 접근 방식은 온체인 및 오프체인 데이터 가용성을 모두 지원할 수 있습니다. 만약에 참고하세요 사용자는 oracle 업데이트에 대해 DON을 신뢰하므로 수락하기 위해 더 이상 신뢰할 필요가 없습니다. 상태 업데이트는 이미 임계값 신뢰 모델에 있기 때문입니다. 또 다른 이점 임계값 서명은 대기 시간이 짧습니다. 새로운 거래 서명 형식 지원 EIP-2938 [70]에서 제안되었으며 계정 추상화로 알려진 임계값이 설정됩니다. 임계값이 필요하지 않으므로 서명을 구현하기가 훨씬 더 쉽습니다. 훨씬 더 복잡한 프로토콜을 포함하는 ECDSA(예: [116, 117, 118])임계값 Schnorr [202] 또는 BLS [55] 서명과 같은 대안보다. 신뢰할 수 있는 실행 환경(TEE): TEE는 강력한 보안 보호를 제공하는 것을 목표로 하는 격리된 실행 환경(일반적으로 하드웨어에 의해 실현됨)입니다. 내부에서 실행되는 프로그램의 경우. 일부 TEE(예: Intel SGX [84])는 증거를 생성할 수 있습니다. 증명이라고 알려진, 출력이 특정 프로그램에 의해 올바르게 계산되었음을 나타냅니다. 특정 입력12. TEF 동기화의 TEE 기반 변형은 다음을 통해 구현할 수 있습니다. 기술을 사용하여 (zk-)rollups 또는 Validium의 증명을 TEE 증명으로 대체합니다. [80]에서. rollups 및 Validium에서 사용되는 영지식 증명과 비교할 때 TEE는 더 성능이 좋습니다. 임계값 서명과 비교하여 TEE는 다음의 복잡성을 제거합니다. 원칙적으로 단 하나의 TEE만 필요하므로 임계값 ECDSA 서명을 생성합니다. 참여. 그러나 TEE를 사용하면 추가 하드웨어 종속 신뢰 가정이 도입됩니다. TEE를 임계값 서명과 결합하여 복원력을 생성할 수도 있습니다. 이 보호 조치는 TEE 인스턴스의 일부가 손상되는 것을 방지합니다. 임계값 ECDSA 서명 생성의 복잡성이 다시 도입되었습니다. 추가적인 유연성: 이러한 동기화 옵션은 다음과 같은 방법으로 더 많은 유연성을 제공하도록 구체화될 수 있습니다. • 유연한 트리거링: TEF 애플리케이션은 다음 조건을 결정할 수 있습니다. 동기화가 트리거됩니다. 예를 들어 동기화는 배치 기반일 수 있습니다. N개의 트랜잭션마다, 시간 기반(예: 10개 블록마다) 또는 이벤트 기반(예: 발생) 목표 자산 가격이 크게 움직일 때마다. • 부분 동기화: 가능하며 어떤 경우에는 바람직합니다(예: rollups, 부분 동기화는 대기 시간을 줄일 수 있음) 작은 것의 빠른 동기화를 제공하기 위해 상태 양, 아마도 주기적으로만 전체 동기화를 수행합니다. 예를 들어, exect는 SCa에서 사용자 잔액을 업데이트하여 출금 요청을 승인할 수 있습니다. MAINCHAIN 상태를 별도로 업데이트하지 않고. 6.4 재구성 네트워크 불안정 또는 51% 공격으로 인한 블록체인 재구성 메인체인의 무결성에 위협이 될 수 있습니다. 실제로, 적들은 다음과 같은 방법을 사용했습니다. 이중 지출 공격을 가하기 위해 [34]. 주요 체인에 대한 이러한 공격은 장착이 까다로우나 일부 체인에서는 여전히 실행 가능합니다([88]). MAINCHAIN과 독립적으로 작동하기 때문에 DON는 흥미로운 이점을 제공합니다. 다음과 관련된 재구성에 대한 일부 보호를 관찰하고 제공할 가능성 공격. 예를 들어, DON는 MAINCHAIN의 의존 계약 SC에 일부 임계 길이 τ의 경쟁 포크의 존재를 보고할 수 있습니다. DON은 추가적으로 가능합니다. 12보충 세부 정보는 부록 B.2.1에서 확인할 수 있습니다. 이해하는 데에는 필요하지 않습니다.
PoW 또는 PoS 설정에서 그러한 포크가 존재한다는 증거를 제공합니다. 는 계약 SC는 일정 기간 동안 추가 거래 실행을 중단하는 등 적절한 방어 조치를 구현할 수 있습니다(예: 거래가 이중 지출을 블랙리스트에 올리도록 허용). 자산). 51% 공격을 가하는 상대는 검열을 시도할 수 있지만 DON의 보고에 따라 SC의 대책은 정기적인 보고를 요구하는 것입니다. DON 트랜잭션(예: 하트비트)을 처리하거나 새로운 보고서를 요구하기 위해 고가치 거래를 검증합니다. 이러한 분기 경고는 원칙적으로 DON가 제공할 수 있는 일반 서비스이지만 다양한 목적을 위해 우리의 계획은 이를 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.
신뢰 최소화
이질적인 개체 집합이 참여하는 분산형 시스템으로서, Chainlink 네트워크는 활성(가용성)과 안전성(보고 무결성) 모두에서 오류에 대한 강력한 보호를 제공합니다. 그러나 대부분의 분산형 시스템은 다음과 같이 다양합니다. 구성 요소 자체가 분산되어 있는 정도. 이 이는 채굴자 간의 분산화가 제한적인 대규모 시스템에서도 마찬가지이며 [32] 중개자 [51]는 오랫동안 존재해 왔습니다. 모든 탈중앙화 노력의 목표는 신뢰 최소화입니다. Chainlink 네트워크 내 시스템 손상이나 장애로 인한 부작용, 악의적인 DON로 인해. 우리의 기본 원칙은 최소 권한 원칙 [197]입니다. 시스템 구성 요소와 시스템 내의 행위자는 엄격하게 범위가 지정된 권한을 가져야 합니다. 할당된 역할을 성공적으로 완료하는 것만 허용합니다. 여기에서는 Chainlink이 드라이브에 채택할 수 있는 몇 가지 구체적인 메커니즘을 제시합니다. 더욱 큰 신뢰 최소화를 지향합니다. 우리는 이러한 메커니즘을 다음과 같이 특성화합니다. 그림 14에 표시된 유전자좌, 즉 뿌리가 있는 시스템 구성 요소의 각 하위 섹션의 각 위치를 다룹니다. 7.1 데이터 소스 인증 oracles의 현재 운영 모델은 데이터 소스가 거의 없다는 사실로 인해 제약을 받습니다. TLS가 기본적으로 서명하지 않기 때문에 생략한 데이터에 디지털 서명을 합니다. 데이터. TLS는 "핸드셰이크" 프로토콜에서 디지털 서명을 사용합니다. 서버와 클라이언트 사이의 공유 키). 따라서 HTTPS 지원 서버에는 인증서가 있습니다. 원칙적으로 데이터 서명에 사용할 수 있는 공개 키에 대해 일반적으로 사용하지는 않습니다. 데이터 서명을 지원하는 인증서입니다. 결과적으로 DON의 보안은 다음과 같습니다. 오늘날의 oracle 네트워크에서는 데이터에서 데이터를 충실하게 중계하는 oracle 노드에 의존합니다. 계약에 대한 소스입니다. Chainlink의 신뢰 최소화를 위한 우리 비전의 중요한 장기 구성 요소에는 데이터 서명을 위한 도구 및 표준 지원을 통한 더욱 강력한 데이터 소스 인증이 포함됩니다. 데이터 서명은 엔드투엔드 무결성 보장을 강화하는 데 도움이 될 수 있습니다. 원칙적으로 계약이 데이터가 직접 서명한 데이터 D 조각을 입력으로 수락하는 경우
그림 14: 이 섹션에서 논의된 신뢰 최소화 메커니즘의 위치. 1⃝데이터 소스는 데이터의 기능을 종속 항목에 전달하는 2⃝DON에 데이터를 제공합니다. 3⃝smart contract. 또한 DON 또는 oracle 네트워크에는 4⃝노드가 포함되어 있습니다. 보상 노드, 가드 등을 위한 MAINCHAIN의 smart contract 관리 레일 등. 소스가 있으면 oracle 네트워크는 D를 실질적으로 변조할 수 없습니다. 다양한 격려 OpenID Connect를 포함하여 이러한 데이터 서명을 활성화하려는 노력이 나타났습니다. 주로 사용자 인증을 위해 설계되었습니다. [9], TLS-N, 학술 프로젝트 TLS 인증서 및 TLS 증거 확장 [63]을 용도 변경하여 TLS [191]을 확장합니다. OpenID Connect가 일부 채택되었지만 TLS Evidence Extensions는 TLS-N은 아직 채택되지 않았습니다. 데이터 소스 인증의 또 다른 잠재적인 방법은 게시자의 자체 인증을 사용하는 것입니다. AMP(Accelerated Mobile Pages) 프로토콜 [225]의 일부로 콘텐츠 전달 네트워크에서 캐시할 수 있는 서명된 HTTP 교환(SXG) [230]. Chrome 모바일 브라우저는 AMP 캐시된 SXG의 콘텐츠를 마치 AMP에서 제공되는 것처럼 표시합니다. 캐시 서버 도메인 대신 게시자의 자체 네트워크 도메인. 이러한 브랜딩 인센티브는 CloudFlare의 실제 URL [83] 및 Google의 amppackager [124]과 같은 서비스를 사용하여 상대적으로 쉽게 활성화할 수 있다는 점과 결합되어 캐시된 뉴스 콘텐츠에 SXG를 널리 채택하게 할 수 있습니다. Chainlink oracles가 유효한 SXG에 보고된 뉴스 가치가 있는 이벤트에서 트리거되는 방법입니다. 뉴스 게시자의 AMP 캐시 SXG는 빠른 템포에는 유용하지 않습니다. 거래 데이터에 대한 보고서와 같은 애플리케이션은 사용자 정의를 위한 안전한 소스가 될 수 있습니다. 기상 이변이나 선거 결과와 같은 실제 사건과 관련된 계약. 우리는 간단한 배포, 성숙한 도구, 유연성이 핵심이라고 믿습니다. 데이터 소스 서명 가속화. 데이터 공급자가 Chainlink 노드를 다음과 같이 사용할 수 있도록 설정 인증된 API 프런트 엔드는 유망한 접근 방식으로 보입니다. 우리는네트워크 참여 여부에 관계없이 노드가 이 모드에서 작동하는 옵션 본격적인 oracle로. 우리는 이 기능을 인증된 데이터 생성이라고 부릅니다. (ADO). ADO와 함께 Chainlink 노드를 사용하면 데이터 소스가 이점을 얻을 수 있습니다. Chainlink 커뮤니티에서 개발한 경험과 도구를 통해 디지털 기능을 추가했습니다. 기존 오프체인 API 제품군에 서명 기능을 제공합니다. 그들은 달리기를 선택해야 할까요? 노드를 oracles로 사용하면 잠재적인 새로운 수익원을 추가로 열 수 있습니다. 기존 데이터 제공자와 동일한 모델(예: Kraken [28], Kaiko [140]) 다른 것들은 Chainlink 노드를 실행하여 체인에서 API 데이터를 판매합니다. 7.1.1 인증된 데이터 생성의 한계 데이터 소스에 의한 디지털 서명은 인증을 강화하는 데 도움이 될 수 있지만 그 자체로는 oracle의 모든 자연스러운 보안 또는 운영 목표를 달성하는 데 충분하지 않습니다. 네트워크. 우선, 주어진 데이터 D 조각은 여전히 강력하고 시기적절하게 전달되어야 합니다. 데이터 소스에서 smart contract 또는 다른 데이터 소비자로 가는 방법. 즉, 에서도 종속 항목에 사전 프로그래밍된 키를 사용하여 모든 데이터가 서명되는 이상적인 설정 계약을 체결하더라도 소스로부터 데이터를 안정적으로 전달하려면 DON이 여전히 필요합니다. 계약에. 또한 계약이나 기타 oracle-데이터가 소비자는 계산된 다양한 기능의 인증된 출력에 액세스하기를 원합니다. 두 가지 주요 이유는 소스 데이터입니다. • 기밀성: 데이터 소스 API는 민감하거나 독점적인 데이터를 제공할 수 있습니다. 체인에 공개되기 전에 수정하거나 정리해야 합니다. 그러나 서명된 데이터를 수정하면 서명이 무효화됩니다. 다른 것을 넣어 그런데 순진한 ADO와 데이터 삭제는 호환되지 않습니다. 예제 3에 나와 있습니다. 향상된 형태의 ADO를 통해 이 둘을 어떻게 조화시킬 수 있는지 알아보세요. • 데이터 소스 오류: 오류와 실패 모두 데이터 소스에 영향을 미칠 수 있으며 디지털 서명은 두 가지 문제를 모두 해결하지 못합니다. [98], Chainlink은 처음부터 이러한 결함을 해결하기 위한 메커니즘인 중복성이 이미 포함되어 있습니다. oracle 네트워크에서 발행한 보고서는 일반적으로 여러 네트워크의 결합된 데이터를 나타냅니다. 소스. 이제 소스 데이터의 기밀성을 강화하고 여러 소스의 데이터를 안전하게 결합하기 위해 ADO 설정에서 탐색 중인 구성표에 대해 논의합니다. 7.1.2 기밀성 데이터 소스는 원하는 API의 전체 영역을 예상하고 제공하지 못할 수 있습니다. 사용자에 의해. 특히 사용자는 사전 처리된 데이터에 액세스하여 다음을 보장할 수 있습니다. 기밀성. 다음 예에서는 문제를 보여줍니다.예시 3. Alice는 다음과 같은 DID(분산 신원) 자격 증명을 얻고 싶어합니다. 그녀는 18세 이상이어야 합니다(예를 들어 대출을 받을 수 있음). 해야 할 일 따라서 그녀는 자신의 나이에 대한 사실을 DID 자격 증명 발급자에게 증명해야 합니다. Alice는 자신이 거주하는 주의 DMV(Department of Motor Vehicles)의 데이터를 사용하기를 원합니다. 목적으로 웹사이트. DMV는 그녀의 생년월일 기록을 가지고 있으며 다음 형식의 디지털 서명된 증명 A: A = {이름: Alice, DoB: 1999년 2월 16일}. 이 예에서 증명 A는 Alice가 DID에 증명하기에 충분할 수 있습니다. 하지만 이는 민감한 정보를 불필요하게 유출합니다: Alice의 정확한 DoB. 이상적으로는 Alice가 DMV에서 원하는 것은 자동차 보험에 서명하는 것입니다. “앨리스는 18세 이상입니다.”라는 간단한 진술 A'입니다. 즉, 그녀는 그녀의 생일 X에 대한 함수 G의 출력. 여기서 (비공식적으로) A′ = G(X) = True인 경우 현재 날짜 −X ≥18년; 그렇지 않으면 G(X) = 거짓입니다. 일반화하자면, Alice는 데이터 소스로부터 서명된 데이터를 요청할 수 있기를 원합니다. 다음 형식의 증명 A': A′ = {이름: Alice, Func:G(X), 결과: True}, 여기서 G(X)는 함수 G와 그 입력 X의 사양을 나타냅니다. 사용자는 자신의 요청에 따라 원하는 G(X)를 입력으로 제공할 수 있어야 합니다. 해당 증명 A'. 데이터 소스의 증명 A'에는 사양 G(X)가 포함되어야 합니다. A'가 올바르게 해석되었는지 확인하세요. 위의 예에서 G(X)는 다음 의미를 정의합니다. A'의 부울 값이므로 True는 증명의 주제를 의미합니다. 18세 이상입니다. 우리는 사용자가 G(X)를 기능적 쿼리로 지정할 수 있는 유연한 쿼리를 참조합니다. 예제 3과 같은 사용 사례와 쿼리와 관련된 사용 사례를 지원하기 위해 계약에서 직접적으로 다음과 관련된 기능적 쿼리에 대한 지원을 포함할 계획입니다. ADO의 일부인 간단한 함수 G. 7.1.3 소스 데이터 결합 온체인 비용을 줄이기 위해 계약은 일반적으로 결합된 데이터를 소비하도록 설계됩니다. 다음 예에 설명된 것처럼 여러 소스에서 가져옵니다. 예 4(가격 데이터 중위화) 가격 피드 제공, 즉 하나의 가치 자산(예: ETH)을 다른 자산(예: USD)에 비해 oracle 네트워크는 일반적으로 거래소 등 다양한 소스에서 현재 가격을 얻습니다. oracle 네트워크 일반적으로 이러한 값의 중앙값을 종속 계약 SC에 보냅니다. 데이터 서명이 있는 환경에서 올바르게 작동하는 oracle 네트워크는 데이터 소스 S = {S1, . . . , SnS} 값의 시퀀스 V = {v1, v2, . . . , vnS} 에서 소스별 서명이 수반되는 nS 소스 Σ = {σ1, σ2, . . . , σnS}. 시 서명을 확인한 후 가격 v = 중앙값(V)을 SC로 전송합니다.불행하게도 oracle 네트워크가 중앙값을 전송하는 간단한 방법은 없습니다. v가 올바르게 계산되었다는 간결한 증거 σ와 함께 예제 4의 v 값을 SC에 전달합니다. 과도하게 서명된 입력. 순진한 접근 방식은 SC에서 모든 nS 데이터 소스의 공개 키를 인코딩하는 것입니다. 그런 다음 oracle 네트워크는 (V, Σ)를 중계하고 SC가 V의 중앙값을 계산하도록 허용합니다. 그러나 이는 크기 O(nS)의 증명 σ가 됩니다. 즉, σ는 간결하지 않습니다. 또한 모든 서명을 확인해야 하는 SC에 높은 가스 비용이 발생합니다. Σ. 이와 대조적으로 SNARK를 사용하면 올바르게 결합된 인증된 소스 값에 대한 간결한 증거가 가능합니다. 실제로 실행 가능할 수도 있지만 상당히 높은 수준을 부과합니다. 증명자의 계산 비용과 체인의 가스 비용이 다소 높습니다. 사용 Town Crier도 가능하지만 TEE를 사용해야 하므로 모든 사람에게 적합하지는 않습니다. 사용자의 신뢰 모델. 소스에서 결합된 데이터에 서명하는 일반적인 문제에 대한 솔루션을 구성하는 유용한 개념은 기능 서명으로 알려진 암호화 도구입니다[59, 132]. 간단히 말해서, 기능적 서명을 통해 서명자는 다음과 같은 서명 기능을 위임할 수 있습니다. 위임자는 서명자가 선택한 함수 F 범위의 메시지에만 서명할 수 있습니다. 우리는 부록 D에서 이 기능적 제약이 어떻게 범위를 제한하는 역할을 할 수 있는지 보여줍니다. 데이터 소스에서 서명된 값의 함수로 DON에서 내보내는 보고서 값입니다. 또한 정확성에 대한 완화된 요구 사항을 포함하지만 잠재적으로 훨씬 더 성능이 뛰어난 이산화된 기능 시그니처라고 하는 새로운 기본 요소를 도입합니다. SNARK와 같은 접근 방식보다. 소스 인증을 포함하는 방식으로 데이터 소스를 결합하는 문제 출력은 CoinCap, CoinMarketCap, CoinGecko와 같은 데이터 수집자에도 적용됩니다. 다양한 거래소로부터 데이터를 얻는 CryptoCompare 등 경우에 따라 공개하는 방법론을 사용하여 부피에 따른 무게 다른 경우에는 독점적입니다. 다음과 같은 값을 게시하려는 수집자 소스 인증은 노드 집합과 동일한 문제에 직면합니다. 소스 데이터. 7.1.4 소스 데이터 처리 정교한 smart contract은 사용자 정의 집계 통계에 의존할 가능성이 높습니다. 많은 자산에 대한 최근 가격 기록의 변동성과 같은 기본 데이터 소스 또는 관련 사건에 대한 뉴스의 텍스트 및 사진. DON에서는 계산 및 대역폭이 상대적으로 저렴하기 때문에 이러한 통계는 — 입력이 많은 복잡한 기계 학습 모델이라도 blockchain에 대한 출력 값이 충분히 간결하다면 경제적으로 처리할 수 있습니다. DON 참가자가 서로 다를 수 있는 계산 집약적인 작업의 경우 복잡한 입력에 대한 견해가 있는 경우 결과를 계산하기 전에 입력에 대한 합의를 확립하기 위해 DON 참가자 간의 추가 의사소통이 필요할 수 있습니다. 최종 값이 입력에 의해 완전히 결정되는 한, 입력 합의가 확립되면 각 참가자는 간단히 값을 계산하여 다른 참가자에게 알릴 수 있습니다.참가자는 부분 서명을 사용하거나 이를 수집자에게 보냅니다. 7.2 DON 신뢰 최소화 우리는 DON 구성 요소에 대한 신뢰를 최소화하는 두 가지 주요 방법을 구상합니다. 장애 조치 클라이언트 및 소수 보고서. 7.2.1 장애 조치 클라이언트 암호화 및 분산 시스템 문헌의 적대적 모델은 일반적으로 노드의 하위 집합을 손상(즉, 손상)할 수 있는 공격자를 고려합니다. 예를 들어 많은 BFT 프로토콜의 경우 1/3 미만입니다. 흔히 관찰되지만, 모든 노드가 동일한 소프트웨어를 실행하는 경우 치명적인 공격을 식별한 공격자는 원칙적으로 모든 노드를 어느 정도 동시에 손상시킵니다. 이 설정은 종종 소프트웨어 단일 문화라고 합니다 [47]. 문제를 해결하기 위해 소프트웨어 및 소프트웨어 구성을 자동으로 다양화하기 위한 다양한 제안이 제시되었습니다(예: [47, 113]). [47]에 명시된 바와 같이, 그러나 소프트웨어 다양성은 복잡한 문제이므로 신중한 고려가 필요합니다. 예를 들어, 소프트웨어 다양화는 다음과 같은 경우 단일 문화보다 더 나쁜 보안을 초래할 수 있습니다. 시스템의 공격 표면을 증가시켜 가능한 공격 벡터를 초과합니다. 그것이 제공하는 보안 이점. 우리는 강력한 장애 조치 클라이언트(즉, 노드가 연결되는 클라이언트)에 대한 지원이 가능하다고 믿습니다. 재앙이 닥쳤을 때 전환할 수 있다는 점은 특히 매력적인 형태입니다. 소프트웨어 다양화. 장애 조치 클라이언트는 잠재적 벡터 수를 늘리지 않습니다. 공격의 위험이 있습니다. 메인라인 소프트웨어로 배포되지 않기 때문입니다. 그들은 분명한 이점을 제공합니다. 그러나 두 번째 방어선으로 사용됩니다. 우리는 DONs에서 장애 조치 클라이언트를 다음과 같이 지원할 계획입니다. 단일 클라이언트에 대한 보안 의존도를 줄이는 주요 수단입니다. Chainlink에는 이미 강력한 장애 조치 클라이언트 시스템이 마련되어 있습니다. 우리의 접근 방식 철저한 테스트를 거친 이전 클라이언트 버전을 유지 관리하는 작업이 포함됩니다. 예를 들어 현재 OCR(오프체인 보고)을 기본 클라이언트로 사용하는 Chainlink 노드에는 지원이 포함됩니다. 필요한 경우 Chainlink의 이전 FluxMonitor 시스템용. 일부 사용 중이던 FluxMonitor는 보안 감사와 현장 테스트를 받았습니다. 그것은 동일한 것을 제공합니다 OCR 기능을 더 높은 비용으로 제공합니다. 비용은 필요할 때만 발생합니다. 7.2.2 마이너리티 리포트 충분히 큰 소수 집합이 주어지면 소수(다수의 불법 행위를 관찰하는 정직한 노드의 일부)가 소수를 생성하는 데 도움이 될 수 있습니다. 보고. 이는 종속 계약 SC 온체인에 전달되는 병렬 보고서 또는 플래그입니다. Ominority에 의해. SC는 자체 계약별 정책에 따라 이 플래그를 사용할 수 있습니다. 예를 들어, 생명력이나 반응성보다 안전이 더 중요한 계약의 경우 소수 보고서로 인해 계약에서 보충 보고서를 요청할 수 있습니다. 다른 DON에서 연결하거나 회로 차단기를 작동시키세요(다음 섹션 참조).다수가 정직할 때에도 소수 보고서는 중요한 역할을 할 수 있으며, 왜냐하면 모든 보고서 집계 체계는 기능적 서명을 사용하더라도 oracle 또는 데이터 오류에 대한 복원력을 보장하기 위해 임계값 방식으로 작동합니다. 에서 즉, 입력 내용을 기반으로 유효한 보고서를 생성하는 것이 가능해야 합니다. kS < nS oracles, 일부 임계값 kS의 경우. 이는 손상된 DON에 일부 오류가 있음을 의미합니다. 다음 중에서 선호하는 kS 값을 선택하여 보고서 값을 조작할 수 있는 위도 모든 소스가 정직하더라도 oracle 전체 세트에 의해 V에서 보고된 nS입니다. 예를 들어, 함수형을 사용하는 시스템에서 nS = 10이고 kS = 7이라고 가정합니다. ETH의 USD 가격에 대한 V에 대한 중앙값 계산을 인증하기 위한 서명입니다. 5개의 소스가 \(500, while the other five report \)1000의 가격을 보고한다고 가정합니다. 그런 다음 가장 낮은 7개 보고서의 중앙값을 조정하여 DON은 유효한 값 v = $500를 출력할 수 있습니다. 가장 높은 값의 중앙값을 계산하면 v = $1000를 출력할 수 있습니다. 모든 노드가 어떤 데이터가 있었는지 알 수 있도록 DON 프로토콜을 강화함으로써 사용 가능한 데이터와 보고서를 구성하는 데 사용된 데이터를 노드에서 감지하고 플래그를 지정할 수 있습니다. 특정 보고서 세트를 다른 보고서 세트보다 선호하는 통계적으로 유의미한 경향이 있으며 그 결과 소수 보고서. 7.3 가드 레일 DONs에 대한 우리의 신뢰 모델은 MAINCHAIN을 더 높은 보안, 더 높은 권한으로 취급합니다. DONs보다 시스템. (이 신뢰 모델이 항상 사실이 아닐 수도 있지만, DON가 더 높은 보안을 제공하는 상황에 결과 메커니즘을 적용합니다. 플랫폼보다 그 반대입니다.) 따라서 자연스러운 신뢰 최소화 전략에는 MAINCHAIN 프런트 엔드에서 smart contracts의 모니터링 및 안전 장치 메커니즘 구현이 포함됩니다. DON의 경우 또는 종속 계약 SC에서 직접. 우리는 이러한 메커니즘을 다음과 같이 지칭합니다. 가드레일을 확인하고 여기에 가장 중요한 사항을 열거하세요. • 회로 차단기: SC는 상태 업데이트 자체의 특성에 따라 상태 업데이트를 일시 중지하거나 중지할 수 있습니다(예: 순차 업데이트에 대한 큰 차이). 보고서) 또는 기타 입력을 기반으로 합니다. 예를 들어 회로 차단기가 작동할 수 있습니다. oracle 보고서가 시간이 지남에 따라 믿을 수 없을 정도로 변하는 경우입니다. 회로 차단기가 또한 소수 보고서에 의해 넘어질 수도 있습니다. 따라서 회로 차단기는 DONs를 방지할 수 있습니다. 심하게 잘못된 보고를 하는 것으로부터. 회로 차단기는 추가 개입을 고려할 시간을 제공할 수 있습니다. 아니면 운동을 했는지. 그러한 개입 중 하나는 탈출구입니다. • 탈출구: 일련의 관리인, 커뮤니티 token 보유자 또는 기타 수탁자 기관이 확인한 불리한 상황에서 계약이 실행될 수 있습니다. 탈출구 [163]라고도 불리는 비상 시설. 탈출용 해치 SC가 어떤 방식으로든 종료되거나 보류 중으로 종료됩니다. 미래 거래. 예를 들어, 보관된 자금을 사용자 [17])에게 반환할 수 있습니다.계약 조건을 종료하거나([162]) 보류 중인 거래 및/또는 향후 거래를 취소할 수 있습니다([173]). 탈출 해치는 계약 유형뿐만 아니라 모든 유형의 계약에 배치될 수 있습니다. DON에 의존하지만 잠재적인 완충 장치로 관심이 있습니다. DON 불법 행위. • 장애 조치: SC가 필수 서비스를 위해 DON에 의존하는 시스템에서는 SC가 서비스 지속을 보장하는 장애 조치 메커니즘을 제공할 수 있습니다. DON 실패 또는 잘못된 행동의 경우. 예를 들어, TEF(섹션 6)에서는 앵커 계약 SCa는 온체인과 특정 중요 작업에 대해 오프체인 실행 인터페이스가 지원됩니다(예: 인출) 또는 일반 거래의 경우 DON 거래의 선취를 방지하기 위해 적절한 지연이 있습니다. 데이터 소스가 데이터에 서명하는 경우 사용자는 다음을 수행할 수 있습니다. 또한 DON이 실패할 경우 SCa에 보고서를 제공합니다. 다양한 형태의 낙관적 rollup(섹션 6.3 참조)에 대해 제안된 사기 증명, 위에서 열거한 메커니즘과 맛이 유사하고 보완적입니다. 그들은 또한 온체인 모니터링의 형태를 제공하고 잠재적인 오류에 대한 보호를 제공합니다. 오프체인 시스템 구성요소. 7.4 신뢰를 최소화한 거버넌스 모든 분산형 시스템과 마찬가지로 Chainlink 네트워크에는 거버넌스 메커니즘이 필요합니다. 시간이 지남에 따라 매개변수를 조정하고, 긴급 상황에 대응하고, 진화를 안내합니다. 이러한 메커니즘 중 일부는 현재 MAINCHAIN에 있으며 앞으로도 계속될 수 있습니다. DON을 배포하더라도 그렇게 할 수 있습니다. 한 가지 예는 결제 메커니즘입니다. oracle 노드 공급자(DON 노드)의 경우. DON MAINCHAIN의 프런트 엔드 계약 가드레일과 같이 주기적으로 영향을 받을 수 있는 추가 메커니즘이 포함되어 있습니다. 수정. 우리는 진화적 메커니즘과 비상사태라는 두 가지 종류의 거버넌스 메커니즘을 예상합니다. 진화적 거버넌스: Chainlink 생태계에 대한 많은 수정 사항은 다음과 같습니다. 구현이 긴급한 문제가 되지 않도록: 성능 개선, 기능 향상, (긴급하지 않은) 보안 업그레이드 등. Chainlink이(가) 거버넌스에 더 많은 참여자를 향해 점진적으로 나아감에 따라 우리는 더 많은 또는 이러한 변경 사항의 대부분은 해당 변경 사항의 영향을 받은 특정 DON 커뮤니티에 의해 비준됩니다. 변화. 그 동안 그리고 아마도 궁극적으로는 병렬 메커니즘으로서 우리는 다음과 같이 믿습니다. 시간적 최소 특권의 개념은 진화적 거버넌스를 구현하는 데 유용한 수단이 될 수 있습니다. 아주 간단히 말하면, 변경 사항을 점진적으로 배포하여 다음을 보장하는 것입니다. 커뮤니티는 이에 대응할 수 있는 기회를 제공합니다. 예를 들어, 새로운 MAINCHAIN 계약은 새로운 계약을 배포해야 하도록 제한될 수 있습니다. 활성화하기 최소 30일 전.비상 거버넌스: MAINCHAIN의 악용 가능하거나 악용된 취약점 계약이나 기타 형태의 활성 또는 안전 오류는 치명적인 결과를 방지하기 위해 즉각적인 개입이 필요할 수 있습니다. 우리의 의도는 다중서명을 지원하는 것입니다. 모든 조직의 불법 행위를 방지하기 위한 개입 메커니즘 서명자는 여러 조직에 분산됩니다. 서명자의 일관된 가용성 보장 비상사태 승인을 위해 적절한 명령 체계에 대한 시기적절한 접근 변경 사항을 적용하려면 신중한 운영 계획과 정기적인 검토가 필요합니다. 이것들 과제는 다른 사이버 보안 사고 대응 테스트와 관련된 과제와 유사합니다. 기능 [134], 경계 감소 [223]과 같은 일반적인 문제를 해결하기 위한 유사한 필요성이 있습니다. DONs의 거버넌스는 많은 분산형 시스템의 거버넌스와 다릅니다. 잠재적인 이질성 정도. 각 DON에는 고유한 데이터 소스, 실행 파일, 가동 시간과 같은 서비스 수준 요구 사항 및 사용자가 있을 수 있습니다. Chainlink 네트워크의 거버넌스 메커니즘은 이러한 변화를 수용할 수 있을 만큼 유연해야 합니다. 운영 목표 및 매개변수. 우리는 디자인 아이디어를 적극적으로 탐구하고 있으며, 앞으로 이 주제에 대한 연구를 발표하세요. 7.5 공개 키 인프라 점진적인 분권화로 인해 강력한 식별이 필요해집니다. DON 노드를 포함한 네트워크 참가자. 특히 Chainlink에는 강력한 공개 키 인프라(PKI). PKI는 키를 ID에 바인딩하는 시스템입니다. 에 대한 예를 들어 PKI는 인터넷의 보안 연결(TLS) 시스템을 뒷받침합니다. HTTPS(예: https://www.chainlinklabs.com)을 통해 웹사이트에 연결하고 브라우저에 자물쇠가 나타나면 이는 도메인 소유자의 공개 키가 특히 디지털 서명을 통해 권한에 의해 해당 소유자에게 바인딩되었습니다. 일명 자격증. 최상위 루트 인증 기관이 널리 사용되는 브라우저에 내장되어 있는 CA(인증 기관)의 계층적 시스템은 인증서가 합법적인 도메인 소유자에게만 발급됩니다. 우리는 Chainlink이 결국 분산형 이름 서비스를 사용할 것으로 예상합니다. 처음에는 Ethereum 이름 서비스(ENS) [22]를 PKI의 기반으로 삼았습니다. 다음과 같이 이름에서 알 수 있듯이 ENS는 매핑을 수행하는 도메인 이름 시스템인 DNS와 유사합니다. (사람이 읽을 수 있는) 도메인 이름을 인터넷의 IP 주소로 변환합니다. 그러나 ENS는 대신 사람이 읽을 수 있는 Ethereum 이름을 blockchain 주소에 매핑합니다. 왜냐하면 ENS Ethereum blockchain에서 작동하며 키 손상을 방지하고 네임스페이스는 원칙적으로 이를 관리하는 계약을 변조하는 것만큼 어렵습니다. 및/또는 기본 blockchain. (반대로 DNS는 역사적으로 취약했습니다. 스푸핑, 하이재킹 및 기타 공격에 사용됩니다.) 우리는 Ethereum 메인넷의 ENS에 data.eth를 등록했으며, oracle 데이터 서비스의 ID가 있는 루트 네임스페이스로 설정하고 다른 Chainlink 네트워크 엔터티가 상주합니다. ENS의 도메인은 계층적입니다. 즉, 각 도메인에 참조가 포함될 수 있습니다. 그 아래 다른 이름으로. ENS의 하위 도메인은 구성 및 관리 방법으로 사용될 수 있습니다.신뢰를 위임합니다. data.eth의 주요 역할은 온체인 디렉터리 서비스 역할을 하는 것입니다. 데이터 피드. 전통적으로 oracles의 개발자와 사용자는 오프체인 소스를 사용해 왔습니다. (예: docs.chain.link 또는 data.chain.link와 같은 웹사이트 또는 다음과 같은 소셜 네트워크 Twitter) oracle 데이터 피드 주소(예: ETH-USD 가격)를 게시하고 획득합니다. 피드). data.eth와 같이 매우 신뢰할 수 있는 루트 네임스페이스를 사용하면 대신 eth-usd.data.eth를 smart contract 주소에 매핑하는 것이 가능합니다. ETH-USD 가격 피드에 대한 온체인 oracle 네트워크 수집기. 이것은 누구든지 blockchain를 정보 소스로 참조할 수 있는 보안 경로를 만듭니다. 해당 가격/이름 쌍(ETH-USD)의 데이터 피드입니다. 결과적으로 ENS를 사용하는 방법은 다음과 같습니다. 오프체인 데이터 소스에서는 얻을 수 없는 두 가지 이점을 실현합니다. • 강력한 보안: 도메인에 대한 모든 변경 사항과 업데이트는 불변하게 기록됩니다. 웹사이트의 텍스트 주소와 달리 암호화 방식으로 보호됩니다. 이 두 가지 보안 속성 중 어느 것도 누리지 마십시오. • 자동화된 온체인 전파: 데이터피드의 smart contract 기본 주소를 업데이트하면 종속 스마트에 전파되는 알림이 트리거될 수 있습니다. 예를 들어 종속 계약을 자동으로 업데이트할 수 있습니다. 새 주소.13 그러나 ENS와 같은 네임스페이스는 합법적인 소유권을 자동으로 확인하지 않습니다. 주장된 이름의. 따라서 예를 들어 네임스페이스에 항목이 포함된 경우 ⟨"Acme Oracle Node Co.", 주소⟩, 그런 다음 사용자는 addr이 Acme라는 이름의 청구자에 속한다는 확신을 얻습니다. Oracle Node Co.는 네임스페이스 관리에 대한 추가 메커니즘 없이 그러나 그녀는 그 이름이 합법적으로 법인에 속해 있다는 확신을 얻지 못합니다. 의미 있는 현실 세계의 의미에서 Acme Oracle Node Co.라고 불립니다. 이름 검증, 즉 상응하는 합법적인 실제 개체의 소유권을 보장하는 우리의 접근 방식은 여러 구성 요소에 의존합니다. 오늘은 Chainlink 연구소 Chainlink 네트워크에 대한 CA 역할을 효과적으로 수행합니다. Chainlink 실습은 계속됩니다. 이름을 검증하기 위해 PKI는 두 가지 방법으로 보다 분산된 모델로 발전할 것입니다. • 신뢰 웹 모델: 계층적 PKI의 분산형 대응물을 종종 신뢰 웹이라고 합니다.14 변형은 1990년대부터 제안되었습니다. 예를 들어 [98], 그리고 많은 연구자들은 blockchains가 전 세계적으로 일관된 인증서를 기록함으로써 아이디어(예: [227])의 사용을 용이하게 할 수 있음을 관찰했습니다. 원장. 우리는 엔터티의 신원을 검증하기 위해 이 모델의 변형을 탐색하고 있습니다. Chainlink 네트워크에서 보다 분산된 방식으로. 13A 종속 계약은 선택적으로 수동 검사를 허용하기 위해 미리 결정된 지연을 포함할 수 있습니다. 종속 계약 관리자의 개입. 14PGP [238]에 대해 Phil Zimmermann이 만든 용어입니다.• 검증 데이터에 대한 연결: 오늘날 상당한 양의 oracle 노드 성능 데이터가 온체인에서 볼 수 있으므로 노드 주소에 보관됩니다. 이러한 데이터는 네트워크에 (신뢰할 수 있는) 참여에 대한 역사적 증거를 제공함으로써 PKI의 정체성을 강화하는 것으로 볼 수 있습니다. 추가적으로 도구 DECO 및 Town Crier [160] 활성화 노드를 기반으로 한 분산 ID용 실제 데이터에서 파생된 자격 증명을 축적합니다. 한 가지 예로서, 노드 운영자는 소유를 증명하는 PKI 신원에 자격 증명을 첨부할 수 있습니다. Dun and Bradstreet 등급입니다. 이러한 보완적인 검증 형태는 다음과 같습니다. 네트워크 보안을 보장할 때 staking을 보완하세요. 실제 신원이 확립된 oracle 노드는 지분을 보유한 것으로 간주될 수 있습니다. 그 명성에서 비롯된 시스템에서. (섹션 4.3 및 섹션 9.6.3 참조) Chainlink PKI의 최종 요구 사항은 보안 부트스트래핑입니다. Chainlink 네트워크의 루트 이름, 현재 data.eth 게시(유사하게) 브라우저의 최상위 도메인을 하드와이어링합니다. 즉, Chainlink 사용자는 어떻게 data.eth가 실제로 Chainlink과 연결된 최상위 도메인인지 확인합니다. 프로젝트? Chainlink 네트워크의 이 문제에 대한 해결책은 다각적이며 다음이 포함될 수 있습니다: • 다음을 지정하는 chain.link의 도메인 레코드에 TXT 레코드 [224] 추가 data.eth를 Chainlink 생태계의 루트 도메인으로 사용합니다. (따라서 Chainlink은 루트 ENS 도메인의 유효성을 검사하기 위해 인터넷 도메인에 대한 PKI를 암시적으로 활용합니다.) • Chainlink의 기존 웹사이트(예: https://docs.chain.link. (인터넷 도메인에 대한 PKI의 또 다른 암시적 사용) • 본 백서를 포함한 다양한 문서를 통해 data.eth의 사용을 알립니다. • Twitter와 같은 소셜 미디어 채널에 data.eth를 공개적으로 게시합니다. Chainlink 블로그 [18]. • 동일한 등록자 주소로 대량의 LINK를 관리하는 행위 data.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.
DON 배포 고려 사항
핵심 설계의 일부는 아니지만 몇 가지 중요한 기술적 고려 사항이 있습니다. 여기서 치료받을 가치가 있는 DON을 실현합니다.
8.1 출시 접근 방식 이 문서에서는 고급 Chainlink 기능에 대한 야심찬 비전을 제시합니다. 이를 실현하려면 그 과정에서 많은 과제에 대한 솔루션이 필요합니다. 이 백서 몇 가지 문제를 식별하지만 예상치 못한 문제도 발생할 수 있습니다. 우리는 이 비전의 요소를 점진적인 방식으로 구현할 계획입니다. 연장된 기간. 우리는 DONs가 처음에 다음과 같이 출시될 것으로 예상합니다. 내부 팀이 공동으로 구축한 사전 구축된 특정 구성 요소에 대한 지원 Chainlink 커뮤니티. 의도는 DON을 더 광범위하게 사용하는 것입니다. 임의의 실행 파일을 실행하면 나중에 지원될 예정입니다. 이러한 주의가 필요한 한 가지 이유는 최근 플래시 대출 기반 공격이 예를 들어 [127, 189]에 표시되어 있습니다. 마찬가지로 smart contract, 어댑터 및 실행 파일에는 극도의 주의가 필요합니다. DONs의 초기 배포에서는 사전 구축된 템플릿화된 실행 파일 및 어댑터 세트만 포함할 계획입니다. 이를 통해 구성 보안에 대한 연구가 가능해집니다. 공식적인 방법 [46, 170] 및 기타 접근 방식을 사용하여 이러한 기능을 수행합니다. 그럴 것이다 또한 가격 책정을 단순화합니다. 기능 가격 책정은 채택된 접근 방식인 일반화된 측정을 통하지 않고 기능별로 DON 노드별로 설정할 수 있습니다. 예: [156]. 우리는 또한 Chainlink 커뮤니티가 창작에 참여할 것으로 기대합니다. 다양한 어댑터와 실행 파일을 점점 더 많이 결합하는 추가 템플릿 수천 명은 아니더라도 수백 명이 운영할 수 있는 유용한 분산형 서비스 DONs. 또한 이 접근 방식은 상태 팽창(즉, DON의 필요성)을 방지하는 데 도움이 될 수 있습니다. 작업 메모리에 작업할 수 없는 양의 상태를 유지하는 노드입니다. 이 문제는 무허가형 blockchains에서 이미 발생하고 있으며, "상태 비저장"과 같은 접근 방식에 동기를 부여합니다. 클라이언트”(예: [206] 참조). 처리량이 높은 시스템에서는 더욱 심각해질 수 있습니다. DON이 상태 크기에 최적화된 실행 파일만 배포하는 접근 방식입니다. DON이 발전하고 성숙해지며 섹션 7에 설명된 강력한 가드레일, 섹션 9에 설명된 암호화폐 경제 및 평판 기반 보안 메커니즘, DON 사용자에게 높은 수준의 보증을 제공하는 기타 기능을 포함함에 따라 우리는 또한 보다 광범위한 출시와 사용을 촉진하기 위한 프레임워크와 도구를 개발할 것으로 예상됩니다. DONs는 커뮤니티에서 제공합니다. 이상적으로 이러한 도구는 노드 운영자 모음을 활성화합니다. oracle 네트워크로 함께 모여서 무허가 환경에서 자신만의 DON을 시작합니다. 또는 셀프 서비스 방식으로 일방적으로 그렇게 할 수 있음을 의미합니다. 8.2 동적 DON 멤버십 특정 DON을 실행하는 노드 집합은 시간이 지남에 따라 변경될 수 있습니다. 두 가지 접근 방식이 있습니다. O의 동적 멤버십을 통해 SKL의 키 관리에 사용됩니다. 첫 번째는 멤버십 변경 시 노드가 보유한 SKL의 지분을 업데이트하는 것입니다. pkL을 변경하지 않고 유지합니다. [41, 161, 198]에서 탐구된 이 접근법은 장점이 있습니다. 신뢰 당사자가 pkL을 업데이트하도록 요구하지 않습니다.[122]에 도입된 전통적인 공유 재공유 기술은 다음과 같은 간단한 기능을 제공합니다. 그리고 그러한 공유 업데이트를 실현하는 효율적인 방법입니다. 비밀을 전송할 수 있게 해줍니다. 한 세트의 노드 O(1)과 두 번째 노드 사이에서, 아마도 하나의 O(2)와 교차할 수 있습니다. 이에 접근 방식, 각 노드 O(1) 나 전체에서 비밀 공유의 (k(2), n(2)) 비밀 공유를 수행합니다. n(2) = |O(2)|에 대한 O(2)의 노드 그리고 원하는(아마도 새로운) 임계값 k(2). 다양한 VSS(검증 가능한 비밀 공유) 체계 [108]는 다음과 같은 공격자에 대한 보안을 제공할 수 있습니다. 노드를 적극적으로 손상시킵니다. 즉, 프로토콜에 악의적인 동작을 도입합니다. [161]의 기술은 통신 복잡성을 줄이고 다음을 제공하는 동시에 이를 수행하는 것을 목표로 합니다. 암호화 경도 가정의 실패에 대한 탄력성. 두 번째 접근 방식은 원장 키 pkL을 업데이트하는 것입니다. 이는 앞으로의 이점이 있습니다. 보안: pkL의 오래된 공유(예: 이전 위원회 노드)가 손상되지 않습니다. 현재 키가 손상될 수 있습니다. 그러나 pkL 업데이트에는 두 가지 단점이 있습니다. (1) pkL로 암호화된 데이터는 키 새로 고침 중에 다시 암호화되어야 하며 (2) 주요 업데이트는 신뢰 당사자에게 전파되어야 합니다. 우리는 두 가지 접근 방식과 두 가지의 하이브리드화를 모두 탐색할 계획입니다. 8.3 DON 책임 기존 Chainlink oracle 네트워크와 마찬가지로 DONs에는 올바른 노드 동작을 기록, 모니터링 및 시행하는 책임 메커니즘이 포함됩니다. DON은(는) 기존의 많은 무허가 blockchain보다 훨씬 더 많은 데이터 용량, 특히 외부 분산 저장소에 연결할 수 있다는 점을 고려하면 더욱 그렇습니다. 결과적으로 노드의 성능 내역을 자세히 기록할 수 있게 됩니다. 보다 세분화된 책임 메커니즘. 예를 들어, 오프체인 계산은 다음과 같습니다. 자산 가격에는 중간 결과가 전송되기 전에 폐기되는 입력이 포함될 수 있습니다. 체인. DON에는 이러한 중간 결과가 기록될 수 있습니다. 따라서 DON의 개별 노드에 의한 오작동 또는 성능 저하가 해결되거나 처벌될 수 있습니다. DON을 세밀하게 처리합니다. 우리는 구축 방법에 대해서도 추가로 논의했습니다. 시스템 장애의 계약별 영향을 다루는 섹션 7.3의 가드레일. 그러나 DON 자체에 대한 안전 장치 메커니즘을 갖추는 것도 중요합니다. 즉, 체계적이고 잠재적으로 치명적인 DON 오류로부터 보호합니다. 지금 설명하는 것처럼 포크/모호함 및 서비스 수준 계약(SLA) 실패. 포크/모호함: 결함이 있는 노드가 충분히 많으면 DON는 분기할 수 있습니다. 또는 모호하게 표현하여 L에서 두 개의 서로 다른 일관성 없는 블록 또는 블록 시퀀스를 생성합니다. 그러나 DON은 L의 내용에 디지털 서명을 하기 때문에 모호함을 방지 및/또는 처벌하기 위한 메인 체인 MAINCHAIN. DON은 MAINCHAIN의 감사 계약에서 L의 상태를 주기적으로 체크포인트할 수 있습니다. 미래 상태가 체크포인트 상태에서 벗어나면 사용자/감사자는 증거를 제시할 수 있습니다. 감사 계약에 대한 이러한 잘못된 행동. 이러한 증거는 경고를 생성하는 데 사용될 수 있습니다. 또는 계약에서 슬래싱을 통해 DON 노드에 불이익을 줍니다. 이 후자의 접근 방식은 특정 oracle 피드에 대한 것과 유사한 인센티브 설계 문제이며 이를 기반으로 구축할 수 있습니다. 우리의 작업은 섹션 9에 설명되어 있습니다.서비스 수준 계약 시행: DON이 반드시 그런 것은 아닙니다. 무한정 실행되므로 SLA(서비스 수준 계약)를 준수하는 것이 중요합니다. 사용자와 함께. 기본 SLA 시행은 메인 체인에서 가능합니다. 예를 들어, DON 노드는 특정 날짜까지 DON을 유지하거나 서비스 종료에 대한 사전 통지(예: 3개월 전 통지)를 제공하기로 약속할 수 있습니다. 에 대한 계약 MAINCHAIN은 기본적인 암호경제학적 SLA 시행을 제공할 수 있습니다. 예를 들어 SLA 계약은 체크포인트가 다음과 같은 경우 예치된 자금 DON을 삭감할 수 있습니다. 필요한 간격으로 제공되지 않습니다. 사용자는 자금을 입금하고 DON에 이의를 제기할 수 있습니다. 체크포인트가 유효한 블록의 시퀀스를 정확하게 나타내는지 증명하기 위해(어떤 방식으로든) 예를 들어 다음과 유사합니다. [141]). 물론 블록생산은 거래와 동일하지 않습니다. 처리하지만 SLA 계약은 후자를 시행하는 역할도 할 수 있습니다. 예를 들어, 트랜잭션을 mempool에서 가져오고(섹션 5.2 참조) 트랜잭션을 채굴하여 체인에 배치하는 레거시 호환 버전의 FSS입니다. 사용자 다음 거래와 함께 SLA 계약을 제공하여 DON 불법 행위를 입증할 수 있습니다. 채굴되었지만 대상 계약에 의한 처리를 위해 DON에 의해 전송되지 않았습니다. 적절한 시간 간격 내에서.15 보다 세분화된 SLA의 존재를 증명하고 처벌하는 것도 가능합니다. 실행 파일을 사용한 계산 오류를 포함한 실패(예: 메커니즘을 통해) 섹션 6.3에 설명된 올바른 오프체인 상태 트랜잭션 또는 실행 실패를 증명하기 위해 DON에 표시되는 개시자 기반 실행 파일, DON의 데이터를 다음으로 전달하지 못했습니다. 적시에 MAINCHAIN을 수행하는 등의 작업을 수행합니다.
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.
경제학과 암호경제학
Chainlink 네트워크가 분산형 신뢰 모델 내에서 강력한 보안을 달성하려면, 노드가 집합적으로 올바른 동작을 나타내는 것이 중요합니다. 대부분의 경우 정확히 DON 프로토콜에 적용됩니다. 이 섹션에서는 접근 방식에 대해 논의합니다. 경제적 인센티브(일명 암호경제학)를 통해 그러한 행동을 강제하도록 돕는 것입니다. 인센티브. 이러한 인센티브는 명시적 인센티브와 암묵적 인센티브, 실현형이라는 두 가지 범주로 나뉩니다. staking 및 향후 수수료 기회(FFO)를 통해 각각. 스테이킹: 다른 blockchain 시스템과 마찬가지로 Chainlink에 스테이킹하려면 네트워크 참가자(예: oracle 노드)가 참여하고 LINK tokens 형식으로 잠긴 자금을 예치해야 합니다. 이것들 지분 또는 명시적 지분이라고도 하는 자금은 명시적인 인센티브입니다. 그들은 노드 장애 또는 불법 행위 시 몰수될 수 있습니다. blockchain 맥락에서, 이 절차를 흔히 슬래싱이라고 합니다. 그러나 Chainlink의 oracle 노드에 의한 스테이킹은 staking과 근본적으로 다릅니다. 권한이 없는 blockchains에서 validators에 의해. 검증인은 거래를 모호하게 하거나 적대적으로 주문함으로써 잘못된 행동을 할 수 있습니다. 기본 합의 프로토콜 15사용자는 mempool의 트랜잭션을 대체할 수 있으므로 채굴된 트랜잭션과 DON 제출된 트랜잭션 간의 올바른 대응을 보장하기 위해 주의가 필요합니다.하지만 무허가 blockchain은 확실하고 빠른 블록 유효성 검사 규칙과 암호화 프리미티브를 사용하여 validator이 잘못된 블록을 생성하는 것을 방지합니다. 대조적으로, 프로그래밍 방식의 보호로는 부정 행위 oracle 네트워크가 생성되는 것을 방지할 수 없습니다. 잘못된 보고서. 그 이유는 두 가지 시스템 유형 간의 주요 차이점입니다. blockchains의 트랜잭션 유효성 검사는 내부 일관성의 속성인 반면 정확성은 oracle의 blockchain에 대한 보고서는 외부, 즉 오프체인 데이터의 속성입니다. 우리는 Chainlink 네트워크 기반을 위한 예비 staking 메커니즘을 설계했습니다. 외부 데이터를 사용할 수 있는 oracle 노드 간의 대화형 프로토콜에서. 이 메커니즘은 명시적인 보상을 사용하여 올바른 행동에 대한 재정적 인센티브를 생성합니다. 페널티(슬래싱). 메커니즘이 경제적이므로 노드를 방지하도록 설계되었습니다. 금융 자원을 사용하여 노드를 손상시키는 적에 의한 부패 뇌물 수수. (이러한 적은 매우 일반적이며, 예를 들어 협력하는 노드까지 확장됩니다. 집단적인 잘못된 행동에서 가치를 추출합니다.) 우리가 디자인한 Chainlink staking 메커니즘에는 강력하고 새로운 기능이 있습니다. 특징.16 이러한 주요 특징은 초선형 영향(구체적으로는 2차)입니다. 공격자는 노드에 예치된 자금을 훨씬 초과하는 리소스를 보유해야 합니다. 메커니즘을 파괴하기 위해. 우리의 staking 메커니즘은 유사한 시스템에서 이전에 고려했던 것보다 더 강력한 적에 대한 보호 기능을 추가로 제공합니다. 노드의 미래 행동에 따라 뇌물을 제공할 수 있는 적입니다. 또한 DECO와 같은 Chainlink 도구가 staking을 강화하는 데 어떻게 도움이 될 수 있는지 논의합니다. 결함이 있는 노드 동작의 경우 올바른 판단을 촉진하여 메커니즘을 제공합니다. 미래 수수료 기회(FFO): 두 PoW의 무허가 blockchains 그리고 PoS 다양성 - 오늘날 우리가 암시적 인센티브라고 부르는 것에 크게 의존하고 있습니다. 이들은 명시적인 보상이 아닌 정직한 행동에 대한 경제적 인센티브 플랫폼 참여 자체에서. 예를 들어, Bitcoin 채굴자 커뮤니티는 신뢰를 훼손할 위험이 있으므로 51% 공격을 가하지 않도록 인센티브를 받습니다. Bitcoin, 그 가치를 저하시키고 결과적으로 집단의 가치를 침식합니다. 광산 인프라에 대한 자본 투자 [150]. Chainlink 네트워크는 우리가 참조하는 유사한 암시적 인센티브로부터 이점을 얻습니다. 미래 수수료 기회(FFO)로. 강력한 성능 기록을 보유한 Oracle 노드 또는 평판은 사용자로부터 수수료를 받습니다. oracle 노드의 오작동으로 인해 미래가 위태로워집니다. 수수료를 지불하고 잠재력 측면에서 기회비용으로 노드에 불이익을 줍니다. 네트워크 참여를 통해 얻은 수익. 명시적 지분과 유사하게, FFO는 암묵적 지분의 한 형태로 볼 수 있으며, 이는 정직한 행동에 대한 인센티브입니다. 플랫폼에 대한 신뢰를 유지함으로써 얻을 수 있는 공유 이익에서 비롯됩니다. 노드 운영자의 비즈니스는 즉, 노드의 긍정적인 성과와 평판에 달려 있습니다. 네트워크. 이 인센티브는 Chainlink 네트워크에 내재되어 있지만 명시적으로 표현되지는 않습니다. 프로토콜. Bitcoin에서는 위에서 언급한 채굴 운영의 가치를 유지합니다. 16여기서 설명하는 staking 메커니즘은 현재 올바른 보고서 전달을 강제하는 것을 목표로 합니다. oracle 네트워크로. 우리는 향후 작업에서 이를 확장하여 많은 항목의 올바른 실행을 보장할 것으로 기대합니다. DONs가 제공할 다른 기능입니다.마찬가지로 암묵적 지분의 한 형태로 볼 수 있습니다. FFO는 이미 Chainlink에 존재하며 네트워크 보안에 도움이 된다는 점을 강조합니다. 오늘. Chainlink의 추가 개발에 대한 우리의 주요 기여는 FFO와 같은 암시적 인센티브를 평가하는 원칙에 입각하고 경험에 기반한 접근 방식이 될 것입니다. 우리는 암시적 인센티브 프레임워크(IIF)라고 부릅니다. 등의 수량을 추정하려면 노드의 향후 수수료 기회에 따라 IIF는 포괄적인 정보를 지속적으로 활용할 것입니다. Chainlink 네트워크가 축적한 성과 및 결제 데이터. 그러한 추정 노드 인센티브를 반영하는 staking 시스템의 IIF 기반 매개변수화를 활성화합니다. 현재의 경험적 및/또는 정적 모델보다 더 높은 정확도를 제공합니다. 그러면 올바른 oracle 노드에 대한 두 가지 주요 경제적 인센티브를 요약해 보겠습니다. 개발 중인 Chainlink 네트워크의 동작은 다음과 같습니다. • 스테이킹(예치된 지분) 오 명시적 인센티브 • 미래 수수료 기회(FFO) 오 암묵적 인센티브 이 두 가지 형태의 인센티브는 상호보완적입니다. Oracle 노드는 동시에 Chainlink staking 프로토콜에 참여하고, 지속적인 수익원을 즐기세요. 사용자는 지속적인 좋은 행동으로 인해 총체적으로 이익을 얻습니다. 따라서 두 인센티브 모두 oracle 네트워크가 제공하는 암호경제적 보안에 기여합니다. 추가적으로, 두 가지 인센티브는 서로 강화되거나 거래될 수 있습니다. 예를 들어, 실적 내역과 수익원이 없는 새로운 oracle 운영자는 정직한 행동을 보장하기 위해 대량의 LINK를 제공하여 사용자를 유치합니다. 그리고 수수료. 반대로, 길고 상대적으로 결함이 없는 확립된 oracle 연산자 성과 기록은 대규모 사용자 기반에서 상당한 수수료를 부과할 수 있으므로 이에 의존합니다. 암묵적인 인센티브의 형태로 FFO에 더 중점을 두고 있습니다. 일반적으로 여기서 고려하는 접근 방식은 주어진 양의 oracle-네트워크를 목표로 합니다. 합리적으로 Chainlink에서 가능한 최대의 경제적 인센티브를 창출할 수 있는 자원 에이전트(즉, 재정적 효용을 극대화하는 노드)는 정직하게 행동합니다. 다른 것을 넣어 방식으로, 목표는 적이 공격하는 데 필요한 재정 자원을 최대화하는 것입니다. 네트워크가 성공적으로 완료되었습니다. staking 프로토콜을 수학적으로 잘 공식화함으로써 경제적 안보를 정의하고 IIF를 사용하여 우리는 경제 안보의 강도를 측정하는 것을 목표로 합니다. Chainlink의 인센티브를 최대한 정확하게 전달하세요. 의존 계약의 작성자는 그런 다음 oracle 네트워크가 충족하는지 여부를 자신있게 결정할 수 있습니다. 필요한 수준의 암호화폐 보안. 경제 안보의 선순환: 이 섹션에서 논의하는 인센티브인 staking 및 FFO는 보안 강화 이상의 영향을 미칩니다. DONs. 그들은 우리가 경제 안보의 선순환이라고 부르는 것을 유도할 것을 약속합니다. 초선형 staking 영향(및 기타 규모의 경제)으로 인해 운영이 저하됩니다. DON의 보안이 강화됨에 따라 비용이 증가합니다. 비용이 낮아지면 DON에 더 많은 사용자가 유입됩니다.수수료 지불을 강화합니다. 수수료 인상은 계속해서 성장을 촉진합니다. 선순환을 이어가는 네트워크입니다. 우리는 경제 안보의 선순환이 하나의 예일 뿐이라고 믿습니다. 이 섹션의 뒷부분에서 논의할 규모의 경제와 네트워크 효과 등이 있습니다. 섹션 구성: 스테이킹은 주목할만한 기술 및 개념적 과제를 제시합니다. 우리는 새로운 기능을 갖춘 메커니즘을 설계했습니다. 따라서 스테이킹은 이 섹션의 주요 초점은 다음과 같습니다. 섹션 9.1에서 이 문서에 소개된 staking 접근 방식에 대한 개요를 제공하고 섹션 9.2~9.5에서 자세한 논의를 진행합니다. IFF를 소개합니다 섹션 9.6에서. 섹션 9.7에서는 Chainlink 네트워크 인센티브에 대한 요약 보기를 제시합니다. 섹션 9.8에서는 우리가 제안한 staking 접근 방식이 oracle 네트워크에 가져올 수 있는 경제적 보안의 선순환에 대해 논의합니다. 마지막으로 다른 가능성에 대해 간단히 설명하겠습니다. 섹션 9.9에서 Chainlink 네트워크의 성장을 촉진하는 효과가 있습니다. 9.1 스테이킹 개요 위에서 언급한 것처럼 여기서 소개하는 staking 메커니즘 설계에는 oracle 노드 간의 불일치를 해결할 수 있는 대화형 프로토콜이 포함됩니다. 외부 데이터 보고. 스테이킹은 합리적인 oracle 노드의 정직한 행동을 보장하는 것을 목표로 합니다. 따라서 우리는 staking 프로토콜을 공격하는 공격자를 모델링할 수 있습니다. 뇌물 수수: 적의 전략은 재정적 인센티브를 사용하여 oracle 노드를 부패시키는 것입니다. 공격자는 성공적인 변조를 통해 전향적으로 재정적 자원을 확보할 수 있습니다. oracle 보고서를 사용하여 예를 들어 결과 이익을 손상된 노드와 공유하겠다고 제안합니다. 우리는 staking 메커니즘 설계를 동시에 두 가지 야심찬 목표로 삼고 있습니다. 1. 강력한 적에 저항: staking 메커니즘은 보호하기 위해 설계되었습니다. oracle 네트워크는 복잡하고, 뇌물을 제공하는 장래의 뇌물 수수를 포함한 조건부 뇌물 수수 전략 사실 이후에 신원이 확인된 oracles에게(예: 뇌물 제공) oracle은 우선순위가 높은 알림을 위해 무작위로 선택됩니다. 다른 oracle 디자인 현실적인 능력을 모두 갖추지 못한 좁은 범위의 공격을 고려했습니다. 우리가 아는 한, 우리가 도입하는 적대적 메커니즘 광범위한 뇌물 수수 전략을 명시적으로 다루고 보여주는 첫 번째 사례는 다음과 같습니다. 이 모델의 저항. 우리 모델은 공격자 이외의 노드가 다음과 같다고 가정합니다. (정직과는 반대로) 경제적으로 합리적이며, 우리는 일반적인 사용에는 엄청나게 비용이 많이 들지만 사용 가능한 정보 소스 동의하지 않는 경우(아래에서 자세히 설명) 2. 초선형 staking 영향 달성: 우리의 목표는 합리적인 에이전트로 구성된 oracle 네트워크가 보고서를 작성하도록 하는 것입니다. 실제로 초선형 예산을 가진 공격자가 있는 경우에도 마찬가지입니다.전체 네트워크가 예치한 총 지분입니다. 기존 staking 시스템에서 다음과 같은 경우 n개의 노드 각각은 $d를 스테이크하며, 공격자는 요청하는 신뢰할 수 있는 뇌물을 발행할 수 있습니다. 노드는 다음보다 약간 더 많은 금액을 지불하는 대가로 부정직하게 행동합니다. \(d to each node, using a total budget of about \)dn. 이것은 이미 높은 기준입니다. 공격자는 예금을 합친 정도의 유동 예산을 가지고 있어야 합니다. 네트워크의 모든 스테이커. 우리의 목표는 더욱 강력한 경제적 안정을 이루는 것입니다. 이것보다 이미 상당한 장애물이 있습니다. 우리는 최초의 staking 시스템을 설계하는 것을 목표로 합니다. n의 예산 초선형으로 일반 공격자에 대한 보안을 달성할 수 있습니다. 아래에서 논의하는 바와 같이 실제적인 고려 사항은 더 낮은 영향을 미칠 수 있지만, 우리의 예비 설계는 다음보다 더 큰 적대적 예산 요구 사항을 달성합니다. $dn2/2, 즉 n으로 2차 스케일링하여 뇌물 수수를 거의 비현실적으로 만듭니다. 노드가 적당한 양만 스테이킹하는 경우. 이 두 가지 목표를 달성하려면 혁신적인 인센티브 설계 조합이 필요합니다. 그리고 암호화. 주요 아이디어: 우리의 staking 접근 방식은 감시 우선 순위라고 부르는 아이디어에 달려 있습니다. Chainlink oracle 네트워크에서 생성되어 신뢰 계약으로 전송되는 보고서 (예: 자산 가격)은 참여 노드가 제공한 개별 보고서에서 집계됩니다(예: 중앙값을 사용하여). 일반적으로 서비스 수준 계약(SLA) 보고서에 대해 허용 가능한 편차 범위, 즉 노드의 보고서가 얼마나 멀리까지 허용되는지를 지정합니다. 집계 보고서에서 벗어나는 범위와 집계가 어느 정도까지 허용되어야 하는지 실제 값에서 벗어나면 올바른 것으로 간주됩니다. staking 시스템에서 특정 보고 라운드에 대해 각 oracle 노드는 다음과 같은 역할을 할 수 있습니다. 집계 보고서가 부정확하다고 판단되면 경고를 발생시키는 감시자입니다. 각각 보고 라운드에서 각 oracle 노드에는 다음을 결정하는 공개 우선순위가 할당됩니다. 경고(있는 경우)가 처리되는 순서입니다. 우리의 메커니즘은 보상을 목표로 합니다. 이는 경보를 발생시키는 최우선 순위의 감시자가 결함이 있는 노드의 예금을 압수하여 전체 보상을 얻습니다. staking 시스템 설계에는 두 가지 계층, 즉 첫 번째 기본 계층과 두 번째 계층이 포함됩니다. 백스톱 계층. 첫 번째 계층은 n개의 노드 집합인 oracle 네트워크 자체입니다. (단순화를 위해, 우리는 n이 홀수라고 가정합니다.) 대다수의 노드가 잘못된 값을 보고하면 첫 번째 계층은 경고를 발생시키도록 강력한 인센티브를 받습니다. 경고가 발생하면 보고는 그런 다음 네트워크 결정은 네트워크 서비스 수준 계약에서 사용자가 지정할 수 있는 고비용, 최대 신뢰성 시스템인 두 번째 계층으로 승격됩니다. 예를 들어, 강력한 노드로만 구성된 시스템일 수 있습니다. 과거 신뢰도 점수 또는 그보다 훨씬 더 많은 oracle을 가진 점수 첫 번째 계층. 또한 섹션 9.4.3에서 설명한 대로 DECO 또는 Town Crier가 서비스를 제공할 수 있습니다. 두 번째 계층에서 효율적이고 결정적인 판결을 보장하는 데 도움이 되는 강력한 도구입니다. 단순화를 위해 우리는 이 두 번째 계층 시스템이 올바른 보고서에 도달한다고 가정합니다. 가치. 모든 보고서를 생성하기 위해 두 번째 계층에 의존하는 것이 매력적으로 보일 수도 있지만, 우리 설계의 이점은 보안 속성을 지속적으로 달성한다는 것입니다.일반적인 경우에는 운영 비용만 지불하면서 두 번째 계층 시스템을 운영합니다. 1차 시스템. Watchdog 우선 순위는 다음과 같은 방식으로 초선형 staking 영향을 미칩니다. 1차 계층 oracle 네트워크가 잘못된 결과와 다수의 감시 노드를 출력합니다. 경고, staking 인센티브 메커니즘은 우선순위가 가장 높은 감시자에게 다음과 같은 보상을 제공합니다. $dn/2 이상은 (대부분) 오작동하는 노드의 예금에서 인출됩니다. 는 따라서 총 보상은 이 단일 감시자의 손에 집중됩니다. 적이 잠재적인 감시자에게 약속해야 하는 최소값을 결정합니다. 경고하지 않도록 장려하십시오. 우리 메커니즘은 모든 oracle이 우선순위가 높은 감시자가 뇌물을 받은 경우 감시자 역할을 할 수 있는 기회 (그리고 경고하지 않기로 결정한 경우) 따라서 적수는 다음보다 더 많은 뇌물을 제공해야 합니다. 경고가 발생하는 것을 방지하기 위해 모든 노드에 $dn/2. n개의 노드가 있으므로, 성공적인 뇌물 수수를 위해 적의 필수 예산은 $dn2/2 이상입니다. 는 네트워크의 노드 수 n에 대해 2차입니다. 9.2 배경 staking에 대한 우리의 접근 방식은 게임 이론 및 메커니즘 분야의 연구를 바탕으로 합니다. 디자인(MD)(교과서 참조는 [177] 참조). 게임이론은 수학적으로 전략적 상호작용에 대한 공식화된 연구. 이런 맥락에서 게임은 그러한 모델이다. 일반적으로 현실 세계에서 사용 가능한 일련의 작업을 체계화하는 상호 작용 플레이어라고 하는 게임 참가자. 게임은 또한 획득한 보상을 지정합니다. 개별 플레이어에 의한 보상 - 플레이어가 선택한 행동과 결과에 따라 달라지는 보상 다른 플레이어의 행동. 아마도 게임에서 연구된 게임의 가장 잘 알려진 예일 것입니다. 이론은 죄수의 딜레마 [178]입니다. 게임 이론가들은 일반적으로 이해하는 것을 목표로 합니다. 주어진 게임에서 표현되는 평형 또는 평형(있는 경우). 균형은 어느 누구도 더 높은 점수를 얻을 수 없는 일련의 전략(각 플레이어당 하나씩) 일방적으로 전략에서 벗어나는 결과를 초래합니다. 한편, 메커니즘 디자인은 인센티브를 디자인하는 과학입니다. 상호 작용(및 관련 게임)의 균형에는 몇 가지 바람직한 속성이 있습니다. MD는 게임 이론의 반대라고 볼 수 있습니다: 게임의 정식 질문 이론은 "인센티브와 모델이 주어지면 균형은 어떻게 될까요?"입니다. MD에서는 대신 질문은 "어떤 인센티브가 바람직한 균형을 이루는 게임을 만들 것인가?"입니다. 메커니즘 설계자의 일반적인 목표는 '인센티브 호환' 메커니즘을 만드는 것입니다. 즉, 메커니즘 참가자(예: 경매 또는 기타 정보)가 유도 시스템 [228])은 어떤 문제(예: 어떻게 그들은 특정 품목을 매우 중요하게 생각합니다). Vickrey(2차 가격) 경매는 아마도 참가자가 봉인된 입찰을 제출하는 가장 잘 알려진 인센티브 호환 메커니즘 품목에 대해 가장 높은 입찰자가 품목을 획득하지만 두 번째로 높은 가격을 지불합니다. [214]. 암호경제학은 암호학을 활용하는 도메인별 MD 형태입니다. 분산형 시스템 내에서 바람직한 균형을 만드는 기술. 뇌물수수와 공모는 MD 분야 전반에 걸쳐 심각한 문제를 야기합니다. 거의 모든 메커니즘은 담합(부차적 계약으로 정의됨)이 있는 경우 중단됩니다.메커니즘에 참여하는 당사자 사이를 연결합니다[125, 130]. 외부 당사자가 게임에 새로운 인센티브를 도입하는 뇌물수수는 더욱 심각한 문제를 야기합니다. 공모보다; 담합은 게임 간 뇌물수수의 특수한 경우로 볼 수 있다. 참가자. 블록체인 시스템은 종종 금전적(암호화폐 기반) 보상을 제공하는 게임으로 개념화될 수 있습니다. 간단한 예는 작업 증명 채굴입니다. 채굴자는 행동 공간을 갖습니다. 블록을 채굴할 hash비율을 선택할 수 있습니다. 채굴의 보상은 보장된 음의 보상(전기 및 장비 비용)에 확률론적 보상을 더한 것입니다. 다른 활성 채굴자 수에 따라 달라지는 긍정적인 보상(채굴 보조금) [106, 172] 및 거래 수수료. SchellingCoin [68]과 같은 크라우드소싱 oracle은 또 다른 예입니다. 작업 공간은 oracle이 보낼 수 있는 가능한 보고서 세트입니다. 지불은 oracle 메커니즘에 의해 지정된 보상입니다. 예를 들어 지불은 달라질 수 있습니다. oracle의 보고서가 다른 보고서의 중앙값에 얼마나 가까운지에 대한 정보입니다[26, 68, 119, 185]. 블록체인 게임은 공모 및 뇌물 공격의 기회를 제공합니다. 실제로, smart contracts는 이러한 공격을 용이하게 할 수도 있습니다[96, 165]. 아마도 가장 잘 알려진 크라우드소싱된 oracles에 대한 뇌물 수수 공격은 p-plus-epsilon 공격 [67]입니다. 이 공격 플레이어가 부울 값 보고서(즉, 거짓 또는 참)를 제출하고 해당 내용에 동의할 경우 p로 보상받는 SchellingCoin과 유사한 메커니즘의 맥락에서 발생합니다. 다수 제출. p-plus-epsilon 공격에서 공격자는 다음과 같이 확실하게 약속합니다. 예를 들어, 다수의 제출이 사실인 경우에만 거짓 투표에 대해 사용자에게 $p + ϵ를 지불합니다. 그 결과 모든 플레이어가 허위 보고를 하도록 장려되는 균형이 이루어졌습니다. 다른 플레이어가 무엇을 하든 상관없습니다. 결과적으로 뇌물은 노드를 유도할 수 있습니다. 약속된 뇌물을 통해 실제로 뇌물을 주지 않고 허위신고를 하게 됩니다(!). 그러나 oracle, 특히 크라우드소싱되지 않은 oracle의 맥락에서 다른 뇌물 수수 전략을 탐색하는 것은 상당히 약한 적에게만 국한되었습니다. 모델. 예를 들어, PoW 환경에서 연구자들은 결과에 따른 결과를 연구했습니다. 뇌물, 즉 대상 메시지가 성공적으로 검열되고 검열되지 않은 경우에만 뇌물이 지급됩니다. 개별 광부의 행동과 관계없이 블록에 나타납니다[96, 165]. 이 경우 그러나 p-plus-epsilon 공격 외에 우리는 oracles의 작업만 알고 있습니다. 뇌물수수자가 조건부로 뇌물을 보내는 엄격하게 제한된 뇌물수수 모델 결과가 아닌 개별 플레이어의 행동에 따라 결정됩니다. 여기서 우리는 인센티브를 유지하는 정보 추출 메커니즘의 설계를 스케치합니다. 다음 하위 섹션에서 설명하는 것처럼 강력한 적대적 모델에서도 호환됩니다. 9.3 모델링 가정 이 하위 섹션에서는 플레이어의 행동과 능력을 모델링하는 방법을 설명합니다. 우리 시스템, 특히 첫 번째 계층 oracle 노드, 두 번째 계층의 노드(판정) 레이어와 적.9.3.1 1차 인센티브 모델: Rational Actors 많은 blockchain 시스템은 몇 가지 정직한 정보를 가정하여 보안에 의존합니다. 참여 노드. 노드는 프로토콜을 따르면 정직하다고 정의됩니다. 그렇게 하는 것이 재정적으로 이익이 되지 않는 경우. 일반적으로 작업 증명 시스템 솔직히 말해서 대부분의 hash 권한이 필요합니다. 지분 증명 시스템은 일반적으로 솔직히 말해서 모든 참여 지분의 2/3 이상이 필요하며 심지어 다음과 같은 레이어 2 시스템도 필요합니다. Arbitrum [141]에는 최소한 한 명의 정직한 참가자가 필요합니다. staking 메커니즘을 모델링할 때 우리는 훨씬 약한 가정을 합니다. (될 명확하고 약한 가정은 더 강력한 보안 특성을 의미하므로 바람직합니다.) 우리는 적이 손상, 즉 통제, 일부(소수)를 손상했다고 가정합니다. 첫 번째 계층 oracle 노드의 비율입니다. 우리는 정직한 에이전트가 아닌 나머지 노드를 모델링합니다. 그러나 합리적 기대효용 극대화자로서. 이러한 노드는 전적으로 이기적인 재정적 인센티브에 따라 행동하며 예상되는 재정적 결과를 가져오는 행동을 선택합니다. 이득. 예를 들어, 노드가 다음으로 인한 보상보다 더 큰 뇌물을 제공받는 경우 정직하게 행동하면 뇌물을 받을 것입니다. 적대적 노드에 대한 참고 사항: 일반적인 신뢰 모델링에 따르면 분산형 시스템에서는 모든 노드가 합리적이라고 가정합니다. 즉, 최대화를 추구합니다. 악의적인 적에 의해 통제되는 것이 아니라 순수익입니다. 그러나 우리의 주장은— 특히 초선형 또는 2차 staking 영향 - 점근적으로 제공됨 적대적으로 제어되는 노드 세트는 최대 (1/2 −c)n입니다. 일부 긍정적인 경우 상수 다. 9.3.2 2차 판단 모델: 가정에 의한 정확성 보안을 달성하는 데 도움이 되는 staking 메커니즘의 중요한 기능은 합리적인 노드에 대한 두 번째 계층 시스템입니다. 제안된 staking 메커니즘에서 모든 oracle은 다음을 나타내는 경고를 발생시킬 수 있습니다. 메커니즘의 출력이 올바르지 않다고 생각합니다. 경고로 인해 신뢰도가 높아집니다. 두 번째 계층 시스템을 활성화하고 올바른 결과를 보고합니다. 따라서 핵심 모델링 우리의 접근 방식에 대한 요구 사항은 올바른 판결, 즉 2차 시스템. 우리의 staking 모델은 부패할 수 없고 최대한 신뢰할 수 있는 정보 소스 역할을 하는 2차 계층 시스템을 가정합니다. 이러한 시스템은 비용이 많이 들고 속도가 느릴 수 있습니다. 일반적인 경우에 사용하기에는 부적절합니다. 그러나 평형의 경우, 즉 첫 번째 계층 시스템이 올바르게 작동하면 두 번째 계층 시스템이 호출되지 않습니다. 대신, 그 존재는 다음을 제공함으로써 전체 oracle 시스템의 보안을 강화합니다. 높은 보증 백스톱. 신뢰도가 높고 비용이 높은 판결 레이어의 사용은 항소 프로세스와 유사합니다. 대부분의 사법 시스템의 핵심입니다. oracle 디자인에서도 이미 흔히 볼 수 있는 현상입니다. 시스템(예: [119, 185]). 우리는 두 번째 계층의 실현에 대한 접근 방식을 간략하게 논의합니다. 섹션 9.4.3의 메커니즘에서.우리의 staking 프로토콜은 oracle 노드의 올바른 보고를 시행하기 위한 신뢰할 수 있는 위협으로 두 번째 계층 시스템의 올바른 판결 가정을 사용합니다. 프로토콜 다음으로 식별되는 보고서를 생성하는 oracle 노드 지분의 일부 또는 전부를 압수합니다. 두 번째 계층 시스템이 잘못된 것으로 간주됩니다. 따라서 Oracle 노드는 오작동을 방지합니다. 그에 따른 금전적 처벌을 받습니다. 이 접근 방식은 다음에서 사용되는 방식과 유사합니다. 낙관적인 rollups(예: [141, 10]) 9.3.3 적대적 모델 우리의 staking 메커니즘은 광범위하고 잘 정의된 적군에 대해 보안을 달성하면서 진실한 정보를 도출하도록 설계되었습니다. 이전 작품에 비해 개선되었으며, 이는 명시적인 적대적 모델을 생략하거나 위에서 논의한 p-plus-epsilon 적과 같은 좁은 하위 클래스의 적에 초점을 맞춥니다. 우리의 목표는 staking을 디자인하는 것입니다. 모든 종류의 공격자에 대해 공식적으로 입증된 보안을 갖춘 메커니즘 실무에서 접하게 됩니다. 우리는 상대방이 다음과 같이 고정된(매개변수화 가능한) 예산을 갖고 있다고 모델링합니다. $B. 적은 oracle와 개별적으로 비밀리에 통신할 수 있습니다. 네트워크를 통해 개인에게 비밀리에 뇌물 지급을 보장할 수 있습니다. 메커니즘의 공개적으로 관찰 가능한 결과에 따라 달라집니다. 결과 결정 뇌물에는 예를 들어 oracle에서 보고한 값, 공개 메시지 등이 포함될 수 있습니다. oracle에 의해 메커니즘(예: 경고)으로 전송된 값은 다른 oracles 및 메커니즘에 의해 출력되는 값입니다. 무제한의 능력을 갖춘 공격자로부터 보호할 수 있는 메커니즘은 없습니다. 따라서 일부 동작은 비현실적이거나 범위를 벗어난 것으로 간주됩니다. 우리는 공격자를 가정합니다 표준 암호화 기본 형식을 깨뜨릴 수 없으며 위에서 언급한 것처럼 고정되어 있습니다(만약 잠재적으로 큰 규모) 예산 $B. 또한 적이 통제하지 못한다고 가정합니다. oracle 네트워크에서의 통신은 특히 실질적으로 지연될 수 없습니다. 첫 번째 계층 및/또는 두 번째 계층 노드 간의 트래픽. (상대가 그러한 통신을 관찰할 수 있는지 여부는 아래에서 설명하는 것처럼 특정 메커니즘에 따라 다릅니다.) 그러나 위에서 언급한 바와 같이 비공식적으로는 적이 다음과 같이 할 수 있다고 가정합니다. (1) 부패 oracle 노드의 일부(일부 상수 c에 대한 (1/2 −c)-분수), 즉 완전히 제어 (2) 지불 조건을 보장하여 원하는 노드에 뇌물을 제공합니다. 위에서 설명한 대로 적이 지정한 결과에 따라 결정됩니다. 우리는 적의 전체 공격에 대한 공식적인 모델이나 완전한 분류를 제공하지 않습니다. 본 백서에 나와 있는 다양한 뇌물 수수 능력에 대한 예는 다음과 같습니다. 우리 모델에 포함되는 뇌물 수수. 단순화를 위해 oracles가 부울을 방출한다고 가정합니다. 정확한 값(w.l.o.g.)이 참이고 최종 결과가 다음과 같이 계산되는 보고서입니다. smart contract 소비에 의해 사용되는 이러한 보고서의 집합입니다. 뇌물을 준 사람의 목표는 최종 결과가 부정확해지는 것, 즉 거짓이 되는 것입니다. • 무조건적인 뇌물수수: 뇌물수수자는 허위 보고를 하는 모든 oracle에게 $b 뇌물을 제공합니다. • 확률적 뇌물수수: 뇌물수수자는 임의의 oracle에게 q 확률로 $b 뇌물을 제공합니다. 거짓으로 보고하는 것입니다.• 거짓 결과 조건부 뇌물: 뇌물은 최종 결과가 거짓인 경우 거짓을 보고하는 모든 oracle에게 뇌물 $b를 제공합니다. • 비경고 조건 뇌물수수: 뇌물수수자는 보고하는 모든 oracle에게 뇌물 $b를 제공합니다. 경고가 발생하지 않는 한 false입니다. • p-plus-epsilon 뇌물 수수: 뇌물 수수는 다음과 같이 허위 보고를 하는 모든 oracle에게 뇌물 $b를 제공합니다. oracles의 대다수가 거짓을 보고하지 않는 한. • 잠재적 뇌물 수수: 뇌물 수수자는 oracle을 선택한 사람에게 미리 $b의 뇌물을 제공합니다. 무작위 역할에 대해 거짓으로 보고합니다. 우리가 제안한 staking 프로토콜에서는 모든 노드는 잠재적인 감시자 역할을 하며, 우리는 무작위화를 보여줄 수 있습니다 감시 우선 순위는 잠재적인 뇌물 수수에 적합하지 않습니다. 많은 작업 증명, proof-of-stake 및 허가된 시스템은 잠재적으로 취약합니다. 그러나 뇌물수수는 적의 입장에서 이를 고려하는 것이 중요함을 보여줍니다. 모델을 만들고 staking 프로토콜이 이에 대한 탄력성을 갖도록 보장합니다. 부록 E를 참조하세요. 자세한 내용은 9.3.4 암호경제학적 보안은 어느 정도면 충분합니까? 합리적인 공격자는 이익을 얻을 수 있는 경우에만 시스템을 공격하는 데 돈을 지출합니다. 지출보다 더 크다. 따라서 우리의 적대적 모델과 제안된 staking에 대해 메커니즘에서 $B는 적이 얻을 수 있는 잠재적 이익의 척도로 볼 수 있습니다. oracle 네트워크를 손상시키고 이를 유발하여 의존하는 smart contract에서 추출합니다. 잘못된 보고서 또는 보고서 세트를 생성합니다. oracle 네트워크 여부를 결정할 때 목적에 맞는 충분한 수준의 암호경제적 보안을 제공하는 경우, 사용자는 다음을 수행해야 합니다. 이러한 관점에서 네트워크를 평가하십시오. 실제 상황에서 그럴듯한 적의 경우 $B는 일반적으로 smart contracts에 의존하는 총 자산보다 훨씬 작습니다. 대부분의 경우, 공격자가 이러한 자산을 전체적으로 추출하는 것은 불가능합니다. 9.4 스테이킹 메커니즘: 스케치 여기서 우리는 staking 메커니즘의 주요 아이디어와 일반 구조를 제시합니다. 현재 고려 중입니다. 프레젠테이션의 편의를 위해 간단하지만 느린 방법을 설명합니다. (다중) 프로토콜. 그러나 우리는 이 계획이 상당히 실용적. 메커니즘이 제공하는 경제적 보장, 즉 결함이 있는 노드에 대한 처벌 및 그에 따른 인센티브를 고려하면 많은 사용자가 기꺼이 다음을 수행할 수 있습니다. 보고서를 낙관적으로 받아들입니다. 즉, 해당 사용자는 신고 이전에 신고를 수락할 수 있습니다. 두 번째 계층의 잠재적인 판결. 낙관적으로 보고서를 받아들이고 싶지 않은 사용자는 프로토콜이 나올 때까지 기다리도록 선택할 수 있습니다. 즉, 두 번째 계층으로의 잠재적인 에스컬레이션이 발생할 때까지 실행이 종료됩니다. 이, 그러나 보고서 확인 시간이 상당히 느려질 수 있습니다. 그러므로 우리는 간략하게그림 15: 경고가 포함된 staking 체계의 도식. 이 예에서는 1⃝a 다수 의 노드가 손상되거나 뇌물을 받고 올바른 값이 아닌 잘못된 값 ~r을 방출합니다. 보고서 값 r. 감시 노드 2⃝는 2차 위원회에 경고를 보냅니다. 3⃝은 올바른 보고 값 r을 결정하고 내보내며, 그 결과 노드가 손상됩니다. 각 $d는 워치독 노드 4⃝에 예치금을 몰수합니다. 다소 더 많은 경우 더 빠른(단일 라운드) 결과를 가져오는 몇 가지 최적화에 대한 개요를 설명합니다. 섹션 9.5의 복잡한 설계. staking 메커니즘의 첫 번째 계층은 기본 oracle로 구성됩니다. 네트워크 자체. 위에서 설명한 것처럼 우리 메커니즘의 주요 구조는 각 라운드마다 다음과 같습니다. 각 노드는 우선 순위에 따라 "감시자" 역할을 할 수 있습니다. 메커니즘이 올바른 출력이 아닌 잘못된 출력 ~r에 도달하면 경고를 발생시킵니다. 하나의 r. 이 경고는 올바른 결과에 도달한다고 가정하는 두 번째 계층 해결 방법을 발생시킵니다. 보고. 잘못된 보고를 한 노드는 지분이 있다는 의미에서 처벌됩니다. 감시견에게 베고 수여했습니다. 이 기본 구조는 oracle 시스템에서 일반적입니다. 예를 들어 [119, 185]와 같습니다. 위에서 간략히 언급한 우리 설계의 핵심 혁신은 모든 노드가 잠재적인 감시자 순서에 따라 뚜렷한 우선순위가 할당됩니다. 즉 감시견이다. 우선순위에 따라 경고할 기회가 주어집니다. 노드에 경고를 발생시키는 것이 가장 높은 우선순위이며 모든 오작동에 대해 $d의 삭감된 예치금을 받습니다. 잘못된 보고는 다음을 의미하므로 총 \(dn/2 = \)d × n/2보다 많은 노드 대부분의 불량 노드. 결과적으로, 적은 최소한 이 보상을 지불해야 합니다. 임의의 노드에 뇌물을 줍니다. 따라서 대다수의 노드에 뇌물을 제공하려면 공격자는 다음과 같은 비용을 지불해야 합니다. 즉, 엄밀히 말하면 $dn2/2보다 많은 대규모 뇌물을 노드에 제공합니다. 그림 15에서는 경고 및 감시 에스컬레이션이 어떻게 작동하는지 개략적으로 보여줍니다.9.4.1 추가 메커니즘 세부정보 이제 우리가 더 자세히 설명하는 뇌물 방지 시스템은 다음과 같은 단순화된 개요입니다. 우리가 건설하려는 2층 구조. 우리의 초점은 대부분 설명하는 것입니다. 첫 번째 계층 네트워크(이하 맥락에서 명확한 경우 간단히 "네트워크") 인센티브 메커니즘과 두 번째 계층으로의 에스컬레이션 절차를 설명합니다. 다음을 담당하는 n개의 oracle 노드로 구성된 Chainlink 네트워크를 생각해 보세요. 정기적으로(예: 1분에 한 번) 부울 값(예: 시장이 BTC의 시가총액이 ETH의 시가총액을 초과합니다. staking 메커니즘의 일부로 노드는 두 가지 보증금을 제공해야 합니다. 보증금 $d는 동의하지 않을 경우 삭감될 수 있습니다. 다수 및 감시 예치금 $dw에 결함이 있는 경우 삭감될 수 있음 에스컬레이션. 우리는 노드가 다른 노드의 제출물을 복사할 수 없다고 가정합니다. 섹션 5.3에서 논의된 커밋-공개 체계를 통해. 각 라운드에서 노드가 먼저 보고서를 커밋하고 모든 노드가 커밋되면(또는 제한 시간이 만료되면) 노드는 보고서를 공개합니다. 생성될 각 보고서에 대해 모든 노드에는 무작위로 선택된 1과 n 사이의 감시 우선순위가 부여되며, 1이 최고 우선순위입니다. 이 우선순위를 사용하면 한 감시자의 손에 보상이 집중됩니다. 모든 신고가 공개된 후, 경고 단계가 이어집니다. n(동기) 라운드의 시퀀스에 걸쳐 노드는 우선 순위는 i 라운드에서 경고할 기회가 있습니다. 노드가 공개된 후 메커니즘에 대한 가능한 결과를 고려해 보겠습니다. 그들의 보고서. 다시 이진 보고서를 가정하고 올바른 값이 true이고 잘못된 것은 거짓입니다. 또한 첫 번째 계층 메커니즘이 다음을 출력한다고 가정합니다. 최종 보고서 r로서 노드에 의해 출력된 다수의 값. 메커니즘에는 세 가지 가능한 결과가 있습니다. • 완전한 합의: 최선의 경우 노드는 완전한 합의에 있습니다. 모든 노드는 사용 가능하며 동일한 값 r에 대한 보고를 시기적절하게 제공했습니다(둘 중 하나). 또는 거짓). 이 경우 네트워크는 r을 의존 계약으로 전달하기만 하면 됩니다. 각 노드에 라운드당 고정 지불금 $p를 지급합니다. 이는 훨씬 작은 금액입니다. $d보다. • 부분적 동의: 일부 노드가 오프라인이거나 어떤 값이 올바른지에 대해 의견 차이가 있을 수 있지만 대부분의 노드는 true를 보고하고 소수의 보고가 거짓입니다. 이 경우도 간단합니다. 다수의 가치 (true)가 계산되어 올바른 보고서 r이 생성됩니다. r을 보고한 모든 노드는 잘못 신고한 oracles가 예치금을 가지고 있는 동안 $p로 보상을 받습니다. 예를 들어 $10p 정도 인하되었습니다. • 경고: 감시자가 네트워크의 출력이 잘못되었다고 판단하는 경우, 이는 공개적으로 경고를 트리거하여 메커니즘을 2차 계층 네트워크로 확대합니다. 그러면 두 가지 결과가 나올 수 있습니다. – 올바른 경고: 두 번째 계층 네트워크에서그림 16: 집중된 경고 보상을 통해 뇌물 수수 비용을 증폭시킵니다. 뇌물 공격자는 경고를 통해 얻을 수 있는 보상보다 더 많은 것을 각 노드에 뇌물을 주어야 합니다. (빨간색 막대로 표시됨) 경고 보상이 공유되는 경우 이 보상은 상대적일 수 있습니다. 작다. 집중된 경고 보상은 단일 노드가 얻을 수 있는 보상을 증가시킵니다. (높은 빨간색 막대)를 얻습니다. 결과적으로 상대방이 실행 가능한 뇌물에 대해 지불한 총 금액은 다음과 같습니다. (회색 영역)은 공유된 알림 보상보다 집중된 알림 보상이 훨씬 더 큽니다. 첫 번째 계층 네트워크가 올바르지 않아 경고하는 감시 노드가 보상을 받습니다. 모두 삭감된 예금으로 구성되므로 $dn/2 이상입니다. – 잘못된 경고: 두 번째 계층과 첫 번째 계층 oracle이 동의하는 경우 에스컬레이션은 결함이 있는 것으로 간주되고 경고 노드는 $dw 보증금을 잃습니다. 보고서가 긍정적으로 받아들여지는 경우 감시 경보는 다음을 유발하지 않습니다. 의존 계약 실행의 모든 변경. 기다리도록 설계된 계약의 경우 2위 위원회 중재 가능성, 감시단 경고는 늦어졌지만 계약 실행을 동결하지 마십시오. 계약을 통해 지정하는 것도 가능합니다. 판정 기간 동안 장애 조치 DON. 9.4.2 2차 스테이킹 영향 엄격한 노드 우선순위와 결합하여 모든 노드가 감시 역할을 하는 기능 집중된 보상을 보장하여 메커니즘이 2차 staking을 달성할 수 있도록 합니다. 섹션 9.3.3에 설명된 각 종류의 뇌물 공격자에 대한 영향. 이것을 기억하십시오 이는 우리 설정에서 각각 보증금이 있는 n개의 노드가 있는 네트워크의 경우를 의미합니다. $d, 성공적인 뇌물 제공자(위의 종류 중 하나)는 다음보다 더 큰 예산을 가져야 합니다. $dn2/2. 정확하게 말하면 뇌물수수자는 최소한 (n+1)/2개의 노드를 부패시켜야 합니다. n 노드의 대다수를 손상시킵니다(가정에 따라 홀수 n의 경우). 따라서 감시자는 다음을 수행합니다. $d(n + 1)/2의 보상을 얻습니다. 따라서 뇌물 제공자는 모든 사람에게 이 금액을 지불해야 합니다.노드가 감시자 역할을 하지 않도록 합니다. 우리는 다음과 같은 사실을 공식적으로 보여주기 위해 노력하고 있습니다. 뇌물 제공자는 최대 $d(n2 + n)/2의 예산을 가지며, 하위 게임 완전 균형이 됩니다. 뇌물수수자와 oracles 사이의 게임, 즉 균형 게임이 진행되는 동안 어느 시점에서든 뇌물을 준 사람은 뇌물을 발행해서는 안 되며, 각 oracle의 진정한 가치를 정직하게 보고합니다. 우리는 성공적인 뇌물 제공을 위해서는 다음과 같은 방법이 필요할 수 있다는 점을 위에서 설명했습니다. 노드 예치금의 합계보다 예산이 훨씬 더 많습니다. 이것을 설명하기 위해 직관적인 결과, 그림 16은 집중된 경고 보상의 영향을 그래픽으로 보여줍니다. 거기에서 볼 수 있듯이, 감시자 경보에 대한 보상, 즉 뇌물 예치금이 지급된다면 false를 보고하는 노드) - 모든 잠재적 경고로 분할되었으며, 개별 경고 노드는 상대적으로 작을 것이라고 예상할 수 있습니다. $d. $d보다 큰 지불금이 있을 가능성이 낮다는 것을 알고 있는 뇌물 제공자는 다음과 같은 방법을 사용할 수 있습니다. n개의 노드 각각에 다음보다 약간 더 많은 뇌물을 제공하는 거짓 결과 조건부 뇌물 $d + ϵ. 반직관적으로, 그림 16은 보상을 광범위하게 분배하는 시스템을 보여줍니다. 경고를 보내는 노드 중 보상을 집중시키는 노드보다 훨씬 약합니다. 하나의 감시견의 손. 예시 매개변수: n = 100개의 노드가 있는 (1차 계층) 네트워크를 생각해 보세요. \(d = \)20K를 입금합니다. 이 네트워크에는 총 200만 달러가 예치되어 있지만 예산 \(100M = \)dn2/2로 뇌물로부터 보호받을 수 있습니다. 수의 증가 oracles는 물론 $d를 늘리는 것보다 더 효과적이며 극적인 효과를 가질 수 있습니다. n = 300개 노드와 예치금 \(d = \)20K를 가진 네트워크는 다음과 같은 위험으로부터 보호됩니다. 최대 9억 달러의 예산으로 뇌물을 제공합니다. staking 시스템은 많은 경우에 다음을 나타내는 smart contract을 보호할 수 있습니다. 제공되는 뇌물수수 방지 수준보다 더 많은 가치를 갖습니다. 그 이유는 상대방이 이러한 계약을 공격하면 많은 경우 전체 가치를 추출할 수 없습니다. 예를 들어, 10억 달러의 가치를 보장하는 Chainlink 기반 계약에는 담보만 필요할 수 있습니다. 그러한 적이 실현 가능하게 이익을 추출할 수 있기 때문에 1억 달러의 자원을 가진 뇌물 수수자 계약금액의 10%에 불과하다. 참고: 네트워크의 가치가 2차적으로 증가할 수 있다는 생각은 다음과 같이 표현됩니다. 잘 알려진 Metcalfe의 법칙[167, 235]은 네트워크의 가치가 연결된 엔터티 수가 2차적으로 증가합니다. 그러나 Metcalfe의 법칙은 잠재적인 쌍별 네트워크 연결 수의 증가로 인해 발생합니다. 이는 인센티브에 기본이 되는 2차 staking 영향과는 다른 현상입니다. 메커니즘. 9.4.3 Second Tier 실현 두 가지 운영 기능으로 신뢰성이 높은 두 번째 계층의 실현을 촉진합니다. (1) 2단계 판결은 oracle 네트워크에서는 드문 경우이므로 다음과 같은 일이 발생할 수 있습니다. 첫 번째 계층의 일반 운영보다 훨씬 더 많은 비용이 듭니다. (2) 가정낙관적으로 받아들여진 보고서 또는 실행이 중재를 기다릴 수 있는 계약 두 번째 계층은 실시간으로 실행될 필요가 없습니다. 이러한 기능으로 인해 다양한 결과가 발생합니다. 특정 DON의 요구 사항을 충족하기 위한 두 번째 계층의 구성 옵션입니다. 접근 방식의 예로서, 두 번째 계층 위원회는 다음과 같은 노드로 구성될 수 있습니다. Chainlink에서 가장 오래 서비스되고 가장 안정적인 노드의 DON(즉, 첫 번째 계층) 네트워크. 상당한 관련 운영 경험 외에도 운영자는 그러한 노드 중 FFO에는 욕구를 유발하는 상당한 암시적 인센티브가 있습니다. Chainlink 네트워크의 신뢰성이 높게 유지되도록 합니다. 그들은 또한 공개적으로 신뢰성에 대한 투명성을 제공하는 사용 가능한 성능 기록입니다. 두 번째 계층 노드는 첫 번째 계층 네트워크에 참여할 필요가 없으며 주목할 가치가 있습니다. 여러 1차 네트워크 전반에 걸쳐 결함을 판정할 수 있습니다. 주어진 DON의 노드는 다음과 같은 n' 집합을 미리 지정하고 공개적으로 커밋할 수 있습니다. 노드는 해당 DON에 대한 2차 위원회를 구성합니다. 또한 DON 노드는 2차 투표 수를 결정하는 매개변수 k′ ≤n′을 게시합니다. 첫 번째 계층 노드에 페널티를 적용하는 데 필요합니다. 특정 보고서에 대해 경고가 생성되면 두 번째 계층의 구성원은 각 계층이 제공한 값의 정확성에 대해 투표합니다. 첫 번째 계층 노드 중 하나입니다. k′ 부정 투표를 받은 첫 번째 계층 노드는 해당 노드를 상실합니다. 워치독 노드에 예치합니다. 재판이 드물고, 장기집행 기회가 드물기 때문이다. 위에서 언급했듯이 첫 번째 계층과 달리 두 번째 계층의 노드는 다음을 수행할 수 있습니다. 1. 판결 수행에 대해 높은 보상을 받습니다. 2. 첫 번째 데이터 소스에서 사용하는 다양한 세트를 넘어서는 추가 데이터 소스를 활용합니다. 3. 수동 및/또는 전문가 검사 및 개입에 의존합니다. 예를 들어 식별하고 소스 데이터의 오류를 조정하고 정직한 노드 중계를 구별합니다. 잘못된 데이터와 오작동하는 노드. 우리는 두 번째 계층 노드 선택과 판결을 관리하는 정책에 대해 방금 설명한 접근 방식이 대규모 노드 내의 한 지점일 뿐이라는 점을 강조합니다. 두 번째 계층의 가능한 실현을 위한 설계 공간. 우리의 인센티브 메커니즘은 다음과 같습니다. 두 번째 계층을 구현하는 방법에 대한 완전한 유연성. 따라서 개별 DON은(는) 특정 요구 사항을 충족하는 두 번째 계층에 대한 규칙을 구성하고 설정합니다. 참여 노드와 사용자의 기대. 심사 도구로서의 DECO 및 Town Crier: 2층에서는 꼭 필요합니다 우리 메커니즘에서는 적대적인 첫 번째 계층 노드를 구별할 수 있습니다. 의도적으로 잘못된 보고서를 생성하고 의도치 않게 정직한 1차 노드를 생성합니다. 소스에서 잘못된 데이터를 중계합니다. 그래야만 두 번째 계층에서 구현할 수 있습니다. 우리 메커니즘의 목표인 부정 행위를 방지하기 위해 삭감합니다. DECO와 타운 크라이어 두 번째 계층 노드가 이러한 중요한 구별을 할 수 있도록 하는 강력한 도구입니다. 안정적으로.두 번째 계층 노드는 경우에 따라 사용된 데이터 소스를 직접 쿼리할 수 있습니다. 잘못된 보고가 있는지 확인하려면 첫 번째 계층 노드를 사용하거나 ADO 섹션 7.1을 사용하세요. 잘못된 데이터 소스로 인해 발생했습니다. 그러나 다른 경우에는 두 번째 계층 노드가 부족할 수 있습니다. 첫 번째 계층 노드의 데이터 소스에 직접 액세스합니다. 이런 경우에는 올바른 판단이 필요합니다. 실행 불가능해 보이거나 주관적인 판단에 의존해야 합니다. 이전 oracle 분쟁 시스템은 이러한 문제를 해결하기 위해 비효율적이고 확대되는 투표에 의존해 왔습니다. 도전. 그러나 DECO 또는 Town Crier를 사용하면 첫 번째 계층 노드가 올바른 동작을 증명할 수 있습니다. 두 번째 계층 노드에. (두 시스템에 대한 자세한 내용은 섹션 3.6.2를 참조하십시오.) 특히 다음과 같은 경우 두 번째 계층 노드는 첫 번째 계층 노드가 잘못된 보고서 값 ~r을 출력한 것으로 식별합니다. 첫 번째 계층 노드는 DECO 또는 Town Crier를 사용하여 변조 방지 증거를 생성할 수 있습니다. (TLS 지원) 소스에서 ~r을 올바르게 중계하고 있는 두 번째 계층 노드 DON에 의해 권위 있는 것으로 인정되었습니다. 중요한 것은 첫 번째 계층 노드가 이 작업을 수행할 수 있다는 것입니다. 데이터 소스에 직접 액세스해야 하는 2차 계층 노드가 없습니다.17 결과적으로, 원하는 데이터 소스에 대해 Chainlink에서 올바른 판결이 가능합니다. 9.4.4 보험을 잘못 보고함 우리의 staking 메커니즘을 통해 달성된 강력한 뇌물수수 저항은 근본적으로 다음과 같습니다. 경고자에게 수여되는 삭감된 자금에 대해. 금전적 보상이 없으면 경고자는 뇌물을 거부할 직접적인 동기가 없습니다. 그러나 결과적으로 삭감된 자금은 그렇지 않습니다. 잘못된 신고로 인해 피해를 입은 사용자(예: 돈을 잃은 사용자)에게 보상이 가능합니다. 잘못된 가격 데이터가 smart contract에 전달되는 경우. 가정에 따르면 잘못된 보고서는 보고서가 승인된 경우 문제를 일으키지 않습니다. 잠재적인 판결, 즉 두 번째 단계의 조치 후에만 계약을 체결합니다. 설명대로 그러나 가능한 최상의 성능을 달성하기 위해 계약은 대신에 의존할 수 있습니다. 올바른 보고를 시행하는 메커니즘에 대해 낙관적으로 생각합니다. 잠재적인 2차 판결 이전에 보고합니다. 실제로 그러한 낙관적인 행동은 예산이 예산을 초과하지 않는 합리적인 적을 가정하는 우리 모델에서는 안전합니다. staking 메커니즘의 영향. 사용자는 다음과 같은 이유로 메커니즘 오류가 발생할 가능성이 없는 상황을 우려하고 있습니다. 예를 들어, 압도적인 재정 자원을 보유한 적들은 보험을 잘못 보고하는 형태로 추가적인 경제적 보안 계층을 사용하기를 원할 수 있습니다. 우리는 알고있다 이미 이러한 종류의 스마트 계약 기반 정책을 제공하려는 여러 보험사 DAO(예: [7])과 같은 혁신적인 메커니즘을 포함하여 가까운 미래에 Chainlink 보안 프로토콜을 위해. Chainlink에 대한 공연 내역이 존재합니다. 노드 및 지분 금액과 같은 노드에 관한 기타 데이터는 위험에 대한 통계적 평가를 위한 매우 강력한 기반을 제공하여 정책 가격 책정을 가능하게 합니다. 보험 계약자에게는 저렴하면서도 보험사에게는 지속 가능한 방식으로 말입니다. 17Town Crier를 사용하면 1차 노드가 로컬에서 증명을 생성하는 것도 가능합니다. 출력된 보고서의 정확성을 확인하고 이러한 증명을 두 번째 계층 노드에 제공합니다. 필요에 따라.기본적인 형태의 허위신고 보험은 신뢰할 수 있고 smart contracts를 사용하는 효율적인 방식입니다. 간단한 예로 파라메트릭 보험을 들 수 있습니다. 계약 SCins는 인센티브 메커니즘이 다음과 같은 경우 보험 계약자에게 자동으로 보상할 수 있습니다. 두 번째 계층은 첫 번째 계층에서 생성된 보고서의 오류를 식별합니다. 보험 가입을 원하는 사용자 U(예: 대상 생성자) 계약 SC는 분산형 보험사에 보험 금액 요청을 제출할 수 있습니다. 100만 달러 계약. U를 승인하면 보험사는 지속적인(예: 월별) 서비스를 설정할 수 있습니다. SCins의 프리미엄은 $P입니다. U가 보험료를 지불하는 동안 그녀의 보험은 계속 유효합니다. SC에서 보고 실패가 발생하면 결과는 (r1, r2) 쌍의 방출이 됩니다. SC에 대한 충돌 보고서의 경우 r1은 우리 메커니즘의 첫 번째 계층에서 서명되고 해당 수정 보고서인 r2는 두 번째 계층에서 서명됩니다. U가 제공한다면 SCins에 대한 유효한 쌍(r1, r2)인 경우 계약은 자동으로 $M을 지불합니다. 그녀의 보험료 지불은 최신 상태입니다. 9.5 단일 라운드 변형 이전 하위 섹션에 설명된 프로토콜에서는 2단계 위원회가 감시자가 경보를 발령했는지 여부를 확인하기 위해 n 라운드를 기다려야 합니다. 이 요구사항은 낙관적인 경우, 즉 첫 번째 계층이 작동하는 경우에도 유지됩니다. 올바르게. 낙관적으로 보고서를 받아들이고 싶지 않은 사용자의 경우, 즉 잠재적인 판결이 내려지면 해당 접근 방식과 관련된 지연은 실행 불가능할 것입니다. 이러한 이유로 우리는 단 하나의 프로토콜만 필요로 하는 대체 프로토콜도 탐색하고 있습니다. 라운드. 이 접근 방식에서 모든 oracle 노드는 여부를 나타내는 비밀 비트를 제출합니다. 그들은 경고를 보내고 싶어합니다. 그런 다음 두 번째 계층 위원회에서는 이러한 값을 확인합니다. 우선순위. 대략적인 스케치를 제공하기 위해 이러한 계획에는 다음이 포함될 수 있습니다. 단계: 1. Watchdog 비트 제출: 각 노드 Oi는 1비트 Watchdog 값을 비밀 공유합니다. 생성된 모든 보고서에 대해 두 번째 계층의 노드 사이에서 wi ∈{no Alert, Alert}가 발생합니다. 2. 익명 팁: 모든 oracle 노드는 감시 비트가 제출되는 동일한 라운드에서 두 번째 계층 위원회에 익명 팁 α를 제출할 수 있습니다. 이 팁α 현재 보고서에 대해 경고가 발생했음을 나타내는 메시지입니다. 3. 워치독 비트 확인: 2차 위원회에서 oracle 노드의 워치독 공개 비트를 우선순위로 합니다. 노드는 경고하지 않을 때 경고 감시 비트를 보내서는 안 됩니다. 그렇지 않으면 트래픽 분석이 모든 노드의 비트를 드러냅니다. 프로토콜은 경고 없음을 나타냅니다. 우선순위가 가장 높은 경고 워치독보다 우선순위가 높은 노드의 워치독 비트입니다. 밝혀진 내용은 n-라운드 프로토콜의 내용과 동일합니다. 보상은 또한 해당 체계와 동일하게 분배됩니다. 즉, 처음으로 식별된 감시자 잘못된 보고서를 제출한 노드의 예치금을 삭감합니다.익명 제보를 사용하면 경고가 발생하지 않은 경우 2차 위원회가 비대화형 상태를 유지하여 의사소통의 복잡성을 줄일 수 있습니다. 일반적인 경우. 경고를 발생시키는 감시자는 익명 제보를 제출할 경제적 인센티브가 있습니다. 제보가 제출되지 않으면 누구에게도 보상이 지급되지 않습니다. 노드. 익명 제보 α의 보낸 사람 Oi가 식별되지 않도록 하기 위해 네트워크 데이터를 기반으로 적에게 익명 제보를 보낼 수 있습니다. 예를 들어 Tor를 통하거나 보다 실질적으로 클라우드 서비스 제공업체를 통해 프록시되는 채널입니다. 받는 사람 팁이 O에서 시작된 것으로 인증하면 Oi는 링 서명을 사용하여 α에 서명할 수 있습니다[39, 192]. 또는 악의적인 oracle 노드에 의한 2차 위원회에 대한 원인 없는 서비스 거부 공격을 방지하기 위해 α는 다음과 같은 익명 자격 증명이 될 수 있습니다. 취소 가능한 익명성 [73]. 이 프로토콜은 실질적으로 달성 가능하지만 다소 무거운 엔지니어링을 가지고 있습니다. (저희는 이를 줄이는 방법을 모색 중입니다) 예를 들어 첫 번째 계층 노드는 디렉터리 유지 관리가 필요한 두 번째 계층 노드와 직접 통신해야 합니다. 익명 채널 및 링 서명의 필요성이 엔지니어링에 추가됩니다. 계획의 복잡성. 마지막으로, 간략하게 논의된 특별한 신뢰 요구 사항이 있습니다. 아래 메모에. 따라서 우리는 여전히 달성할 수 있는 더 간단한 계획을 모색하고 있습니다. 초선형 staking 영향은 있지만 뇌물 제공자는 점근적으로 최소한 $n log n의 자원을 필요로 하는 2차식보다 덜할 수 있습니다. 아래 계획 중 일부 감시자 역할을 할 노드의 엄격한 하위 집합을 무작위로 선택하는 것을 고려합니다. 이 경우 뇌물 수수 가능성이 특히 강력한 공격이 됩니다. 비고: 이 단일 라운드 staking 메커니즘의 보안에는 접근할 수 없는 기술이 필요합니다. oracle과 2계층 노드 사이의 채널 — 투표[82, 138]와 같은 강제 저항 시스템의 표준 요구 사항이며 실제로는 합리적인 요구 사항입니다. 그러나 추가적으로 뇌물수수자와 협력하려는 노드 Oi는 뇌물 수수자에게 특정 정보를 암호화했음을 보여주는 방식으로 비밀 공유 가치. 예를 들어, Oi가 뇌물 제공자가 어느 노드를 제어하는지 알지 못하는 경우 Oi는 다음을 수행할 수 있습니다. 모든 위원회 구성원에게 가치가 0인 주식을 제출합니다. 그러면 뇌물 제공자는 Oi의 사실을 확인할 수 있습니다. 확률적으로 준수합니다. 단일 라운드 프로토콜에서 이 문제를 피하기 위해 우리는 Oi가 적어도 하나의 정직한 2계층 노드의 신원을 알아야 합니다. 각 두 번째 계층 노드가 무작위화를 추가하는 대화형 프로토콜 사용 공유 요소를 공유하는 경우 뇌물 제공자가 할 수 있는 최선의 방법은 Oi가 무작위로 선택하도록 강요하는 것입니다. 감시 비트. 9.6 암시적 인센티브 프레임워크(IIF) FFO는 Chainlink 네트워크의 올바른 행동에 대한 암시적 인센티브의 한 형태입니다. 그것 명시적인 지분, 즉 예금과 같은 기능을 통해 경제적 안정을 강화하는 데 도움이 됩니다. 네트워크. 즉, FFO는 (유효) 예금의 일부로 포함되어야 합니다. 네트워크에 있는 노드의 $d.문제는 FFO 및 기타 형태의 암묵적 인센티브를 어떻게 측정하는가입니다. Chainlink 네트워크 내에서요? IIF(암시적 인센티브 프레임워크)는 다음과 같은 집합입니다. 이를 위해 우리가 개발할 원칙과 기술. 블록체인 시스템 다양한 형태의 전례 없는 투명성과 노드의 높은 신뢰 기록을 제공합니다. 그들이 창출하는 성능은 IIF가 어떻게 작동할지에 대한 우리의 비전을 위한 발판입니다. 여기에서는 IIF의 핵심 요소에 대한 아이디어를 매우 간략하게 설명합니다. IIF 자체는 평가에서 중요하다고 식별된 일련의 요소로 구성됩니다. 분석 알고리즘에서 사용할 수 있도록 관련 데이터를 높은 보증 형식으로 게시하는 메커니즘과 함께 암시적 인센티브를 제공합니다. 다른 Chainlink 사용자는 다음을 수행할 수 있습니다. 다양한 요인에 서로 다른 가중치를 부여하는 등 다양한 방식으로 IIF를 사용하려고 합니다. 사용자가 IIF를 적용하는 데 도움이 되는 분석 서비스가 커뮤니티에서 나타날 것으로 기대합니다. 개인의 위험 평가 선호도에 따라 우리의 목표는 다음과 같습니다. 높은 보증과 시기적절한 지원 데이터에 대한 액세스를 보장함으로써 이러한 서비스를 제공합니다. 아래에서 논의하는 것처럼(섹션 9.6.4). 9.6.1 향후 수수료 기회 노드는 Chainlink 생태계에 참여하여 이 백서에서 설명한 다양한 서비스에 대해 네트워크가 지불하는 수수료의 일부를 얻습니다. 분산 ID, 공정한 순서 지정과 같은 고급 서비스에 대한 일반 데이터 피드, 기밀 유지 DeFi. Chainlink 네트워크의 수수료는 서버 운영, 필요한 데이터 라이선스 획득, 유지 관리 등에 대한 노드 운영자의 비용을 지원합니다. 높은 가동 시간을 보장하는 글로벌 직원. FFO는 서비스 수수료, 순 비용을 나타냅니다. 노드가 미래에 이익을 얻거나 잘못된 동작을 보여주면 잃을 것입니다. FFO는 네트워크 보안에 도움이 되는 지분 형태입니다. FFO의 유용한 기능은 온체인 데이터(오프체인으로 보완됨)입니다. 데이터) 노드 이력에 대한 높은 신뢰 기록을 수립하여 FFO 계산을 가능하게 합니다. 투명하고 경험적으로 주도되는 방식으로. FFO에 대한 간단한 1차 측정은 특정 기업의 평균 순수익에서 파생될 수 있습니다. 일정 기간 동안의 노드(예: 총 수익에서 운영 비용을 뺀 값) FFO는 다음을 수행할 수 있습니다. 예를 들어 누적 미래 순수익의 순 현재 가치 [114]로 계산됩니다. 즉, 미래의 모든 수입을 시간으로 할인한 가치입니다. 그러나 노드 수익은 그림 17에서 볼 수 있듯이 변동이 심할 수 있습니다. 더 중요한 것은 노드 수익이 고정된 분포를 따르지 않을 수 있다는 것입니다. 시간이 지남에 따라. 결과적으로 FFO 추정 시 탐구할 다른 요소는 다음과 같습니다. • 성과 내역: 보고서의 정확성과 적시성, 가동 시간을 포함한 운영자의 성과 내역은 목표를 제공합니다. 사용자가 신뢰성을 평가할 수 있는 시금석입니다. 실적 내역은 다음과 같습니다. 사용자가 oracle 노드를 선택하는 데 중요한 요소를 제공합니다(또는 출현과 함께). DON 중, DON 중 선택). 강력한 실적 이력이 있을 가능성이 높습니다. 지속적인 높은 수익과 상관관계가 있습니다.18 18우리가 다루고자 하는 중요한 연구 문제는 위조된 서비스 양을 탐지하는 것입니다.그림 17: 단일 데이터 피드(ETH-USD)에서 Chainlink 노드가 얻은 수익 2021년 3월의 대표적인 주간. • 데이터 액세스: oracles는 개방형 API에서 다양한 형태의 데이터를 얻을 수 있지만 특정 형태의 데이터나 특정 고품질 소스는 구독 기반 또는 계약 계약을 통해. 특정에 대한 특권적 접근 데이터 소스는 안정적인 수익원을 창출하는 역할을 할 수 있습니다. • DON 참여: DONs의 출현으로 노드 커뮤니티가 등장할 것입니다. 특별한 서비스를 제공하기 위해 함께 모입니다. 많은 DON에 포함될 것으로 예상됩니다. 선택적으로 운영자를 통해 평판이 좋은 DON에 참여하도록 설정합니다. 일관된 수익원을 보장하는 데 도움이 되는 특권적인 시장 지위. • 크로스 플랫폼 활동: 일부 노드 운영자는 PoS validators 또는 blockchain 이외의 컨텍스트의 데이터 공급자. 이러한 다른 시스템에서의 성과(데이터가 신뢰할 수 있는 형식으로 제공되는 경우)는 평가에 정보를 제공할 수 있습니다. 그들의 공연 기록. 마찬가지로 Chainlink 네트워크의 잘못된 동작 사용자를 몰아냄으로써 다른 시스템의 수익을 위태롭게 할 수 있습니다(예: FFO). 여러 플랫폼으로 확장할 수 있습니다. 9.6.2 투기적 FFO 노드 운영자는 단지 수익을 창출하기 위해 Chainlink 네트워크에 참여하지 않습니다. 그러나 작업을 실행하기 위한 새로운 기회를 활용하기 위해 스스로를 만들고 위치를 정하는 것입니다. 즉, 네트워크 내 oracle 노드의 지출도 DeFi 및 기타 스마트 계약 애플리케이션의 미래에 대한 긍정적인 진술 도메인뿐만 아니라 oracle 네트워크의 새로운 비 blockchain 애플리케이션도 포함됩니다. 오늘날 노드 운영자는 기존 Chainlink 네트워크에서 사용 가능한 수수료를 얻는 동시에 동시에 이는 문제가 인터넷 사이트에서 더 쉽다는 점을 제외하면 인터넷 사이트의 가짜 리뷰와 어느 정도 유사합니다. oracle 상품이 주문되었는지, 즉 보고서가 주문되었는지에 대한 확실한 기록이 있기 때문에 설정됩니다. 예를 들어 온라인 상점에서 주문한 실제 상품과 반대되는 배송입니다. 다른 말로 하면 oracle에서 고객의 진실성은 검증할 수 없더라도 설정을 통해 성능을 검증할 수 있습니다.평판, 실적 이력, 운영 전문성을 구축하여 입지를 다질 것입니다. 미래 네트워크에서 사용할 수 있는 수수료를 얻는 데 유리합니다(물론 조건에 따라). 정직한 행동에 대해). 현재 Chainlink 생태계에서 운영되는 노드는 다음과 같습니다. Chainlink 추가 수수료를 받는 데 신규 이민자보다 유리하다는 의미입니다. 서비스가 가능해집니다. 이러한 이점은 새로운 운영업체는 물론 평판이 좋은 기술 회사에도 적용됩니다. 예를 들어 T-Systems는 전통적인 기술 제공업체(Deutsche Telekom의 자회사)와 대규모 중앙 집중식 회사인 Kraken Exchange는 Chainlink 생태계 [28, 143]에서 초기 입지를 구축했습니다. 향후 기회에 oracle 노드가 참여하는 것은 그 자체로 간주될 수 있습니다. 일종의 투기적 FFO로서 Chainlink의 지분 형태를 구성합니다. 네트워크. 9.6.3 외부 평판 우리가 설명한 대로 IIF는 엄격한 가명으로 네트워크에서 작동할 수 있습니다. 즉, 관련된 사람이나 실제 실체를 공개하지 않습니다. 그러나 사용자가 공급자를 선택할 때 잠재적으로 중요한 요소 중 하나는 외부입니다. 평판. 외부 평판이란 가명이 아닌 실제 신원에 부여된 신뢰성에 대한 인식을 의미합니다. 평판 위험 실제 정체성은 암묵적인 인센티브의 한 형태로 볼 수 있습니다. 평판을 본다 즉, 암호경제학적 의미에서 IIF의 렌즈를 통해 FFO 추정치에 통합될 수 있는 크로스 플랫폼 활동. FFO 추정의 요인으로 외부 평판을 사용하는 이점은 이와 반대로 가명 연결은 외부 평판이 성과를 단순히 연결하는 것이 아니라 운영자의 기존 활동뿐만 아니라 향후 활동에도 적용됩니다. 예를 들어 평판이 좋지 않은 경우 개인에게 부착되면 그 사람의 미래 사업을 오염시킬 수 있습니다. 다르게 말하면, 외부 평판은 가명보다 더 넓은 범위의 FFO를 포착할 수 있습니다. 개인 또는 확립된 불법 행위의 영향으로서의 성과 기록 회사는 가명 운영과 관련된 것보다 탈출하기가 더 어렵습니다. Chainlink은(는) 분산형 ID 기술(섹션 4.3)과 호환됩니다. IIF에서 외부 평판 사용에 대한 지원을 제공할 수 있습니다. 이러한 기술 운영자가 주장하는 실제 세계의 진실성을 검증하고 보장하는 데 도움이 될 수 있습니다. 신원.19 9.6.4 IIF 분석 열기 앞서 언급했듯이 IIF는 신뢰할 수 있는 오픈 소스 데이터와 도구를 제공하는 것을 목표로 합니다. 암시적 인센티브 분석. 목표는 지역사회 내에서 서비스 제공자를 활성화하는 것입니다. 다양한 부분의 위험 평가 요구에 맞는 분석을 개발합니다. Chainlink 사용자 기반. 19분산형 신원 증명은 원하는 경우 검증된 인증을 통해 가명을 장식할 수도 있습니다. 보충 정보. 예를 들어, 노드 운영자는 원칙적으로 그러한 자격 증명을 사용하여 다음을 수행할 수 있습니다. 어떤 회사인지 밝히지 않고 Fortune 500대 기업임을 입증합니다.노드의 수익 및 성능에 관한 상당한 양의 과거 데이터 신뢰도가 높고 변경 불가능한 형태로 체인에 상주합니다. 그러나 우리의 목표는 오직 눈에만 보이는 행동에 대한 데이터를 포함한 가장 포괄적인 데이터 오프체인 보고(OCR) 또는 DON 활동과 같은 체인. 이러한 데이터는 잠재적으로 방대하다. 데이터를 저장하고 무결성을 보장하는 가장 좋은 방법입니다. 변조는 논의된 기술을 사용하여 DONs의 도움을 받을 것이라고 믿습니다. 섹션 3.3에서. 일부 인센티브는 staking와 같은 직접적인 측정 형태에 적합합니다. 예금 및 기본 FFO. 투기적 FFO 및 평판과 같은 다른 것들은 파악하기가 더 어렵습니다. 객관적인 방식으로 측정하지만, 다음을 포함한 뒷받침하는 데이터 형태가 있다고 믿습니다. Chainlink 생태계의 역사적 성장, 평판에 대한 소셜 미디어 지표 등 정량화하기 어려운 요소에 대해서도 IIF 분석 모델을 지원할 수 있습니다. 우리는 특별히 모니터링, 검증 및 확인을 위해 전용 DON이 발생한다고 상상할 수 있습니다. 노드의 오프체인 성능 기록과 관련된 데이터 및 기타 데이터를 기록합니다. 검증된 신원 정보와 같이 IIF에서 사용됩니다. 이러한 DON은 Chainlink 커뮤니티에 서비스를 제공하는 모든 분석 제공자에게 균일하고 신뢰도가 높은 IIF 데이터를 제공할 수 있습니다. 또한 분석 제공업체의 주장을 뒷받침하는 황금 기록을 제공할 것입니다. 커뮤니티에서 독립적으로 검증할 수 있습니다. 9.7 종합적으로: 노드 운영자 인센티브 노드 운영자에 대한 명시적 및 암시적 인센티브에 대한 위의 논의를 종합합니다. 노드 운영자가 참여하고 혜택을 받는 방식에 대한 전체적인 관점을 제공합니다. Chainlink 네트워크. 개념적 가이드로서 주어진 Chainlink에 의해 위험에 처한 총 자산을 표현할 수 있습니다. 노드 연산자 $S는 다음과 같이 대략적으로 양식화된 형식으로 표시됩니다. \(S ≈\)D + \(F + \)FS + $R, 여기서: • $D는 모든 네트워크에 걸쳐 명시적으로 예치된 모든 지분의 합계입니다. 운영자가 참여합니다. • $F는 모든 네트워크에 걸쳐 모든 FFO를 합산한 순 현재 가치입니다. 운영자가 참여하는 것; • $FS는 운영자의 투기적 FFO의 순 현재 가치입니다. 그리고 • $R은 Chainlink 생태계 외부 운영자의 평판 자산입니다. oracle 노드에서 확인된 오작동으로 인해 위험에 처할 수 있습니다. 대체로 개념적이지만, 이 대략적인 동등성은 Chainlink 노드의 높은 신뢰성 성능을 선호하는 다양한 경제적 요인이 있음을 유용하게 보여줍니다. $D를 제외한 이러한 모든 요소는 오늘날의 Chainlink 네트워크에 존재합니다.9.8 경제 안보의 선순환 초선형 staking 영향과 수수료 지불 표현의 조합 IIF의 미래 수수료 기회(FFO)는 우리가 선순환이라고 부르는 것으로 이어질 수 있습니다. oracle 네트워크의 경제적 안정. 일종의 경제라고 볼 수 있다. 규모의. 특정 네트워크가 확보한 총액이 늘어날수록 고정된 양의 경제적 안정을 추가하는 데 필요한 추가 지분은 감소합니다. 평균 사용자당 비용. 따라서 사용자가 가입하는 것이 수수료 측면에서 더 저렴합니다. 동일한 네트워크 경제성 증가를 달성하는 것보다 이미 존재하는 네트워크를 사용하는 것보다 새로운 네트워크를 생성하여 보안을 강화합니다. 중요한 것은 각각의 신규 사용자 추가가 낮아진다는 것입니다. 해당 네트워크의 모든 이전 사용자에 대한 서비스 비용. 특정 수수료 구조(예: 스테이킹된 금액에 대한 특정 수익률)를 고려하면 네트워크가 벌어들이는 총 수수료가 증가하면 이는 추가 자금 흐름을 장려합니다. 더 높은 비율로 네트워크를 보호하려면 네트워크에 지분을 투자하세요. 특히, 총 지분이 개별 노드가 시스템에 보유할 수 있는 한도가 제한되어 있으며, 새로운 수수료 지불 시 시스템에 들어가서 FFO를 높이면 노드 수 n이 증가합니다. 덕분에 인센티브 시스템 설계의 초선형 staking 영향, 경제적 안정 시스템은 n보다 빠르게 상승할 것입니다. 예를 들어 섹션 9.4에서 설명한 메커니즘의 n2와 같습니다. 결과적으로 경제적 안정을 위한 평균 비용, 즉 기여하는 지분의 양은 1달러의 경제적 안정이 떨어질 것입니다. 따라서 네트워크는 사용자에게 요금을 청구할 수 있습니다. 더 낮은 수수료. oracle 서비스에 대한 수요가 탄력적이라고 가정합니다(예: 간략한 내용은 [31] 참조). 설명) 수요가 증가하여 추가 수수료와 FFO가 발생합니다. 다음 예를 통해 이 점을 설명합니다. 예시 5. 인센티브를 통해 oracle 네트워크의 경제적 보안이 강화된 이후 계획은 \(dn2 for stake \)dn이며, 1달러 지분으로 인한 경제적 안정입니다. n은 경제적 안정의 달러당 평균 비용, 즉 지분의 양입니다. 1달러의 경제적 안정에 기여하는 금액은 1/n입니다. 경제적 인센티브가 전적으로 FFO로 구성된 네트워크를 생각해 보세요. 노드당 \(d ≤\)10K입니다. 네트워크에 n = 3개의 노드가 있다고 가정합니다. 그러면 평균비용 경제적 안정의 1달러당 약 0.33달러입니다. 네트워크의 총 FFO가 \(30K (e.g., to \)31K 이상으로 증가한다고 가정합니다. 주어진 노드당 FFO의 한도를 늘리면 네트워크는 (적어도) n = 4로 성장합니다. 이제 평균 비용은 경제적 안정의 1달러당 약 0.25달러로 떨어집니다. 우리는 그림 18에서 oracle 네트워크의 경제적 안정의 전체 선순환을 개략적으로 설명합니다. 경제 안보의 선순환은 다음과 같은 효과에서 비롯된다는 점을 강조합니다. 사용자가 수수료를 합산합니다. 더 큰 이익을 위해 일하는 것은 그들의 집단 FFO입니다. 네트워크 규모가 커지고 집단 보안이 강화됩니다. 우리는 또한 선순환이 경제적 안정은 DON의 재정적 지속 가능성 달성에 유리합니다. 한 번 사용자 요구 사항을 해결하는 DON이 생성된 지점 이상으로 성장해야 합니다. 수수료 수익이 oracle 노드의 운영 비용을 초과합니다.
그림 18: Chainlink staking의 선순환 도식. 사용자 수수료 인상 oracle 네트워크 1⃝에 지불하면 네트워크가 성장하고 경제적 성장으로 이어집니다. 보안 2⃝. 이러한 초선형 성장은 Chainlink 네트워크에서 규모의 경제를 실현합니다. 3⃝. 구체적으로 이는 경제적 안정을 위한 평균 비용의 감소를 의미합니다. 수수료 지불 또는 기타 지분 소스에서 발생하는 달러당 경제적 안정 증가합니다. 비용 절감이 사용자에게 전달되어 oracle에 대한 수요 증가를 촉진합니다. 서비스 4⃝. 9.9 네트워크 성장을 이끄는 추가 요인 Chainlink 생태계가 계속 확장됨에 따라 우리는 그 매력을 믿습니다. blockchain 경제를 위한 인프라로서의 중요성이 가속화될 것입니다. oracle 네트워크가 제공하는 가치는 초선형적이므로 더 빠르게 성장합니다.네트워크 자체의 크기보다 이러한 가치 성장은 두 가지 모두에서 비롯됩니다. 규모의 경제 - 서비스 양이 증가함에 따라 사용자당 비용 효율성이 향상됩니다. 네트워크 효과 - 사용자가 DON을 더 광범위하게 채택함에 따라 네트워크 유틸리티가 증가합니다. 기존 smart contract은 계속해서 더 많은 가치를 확보하고 완전히 새로운 것을 보여줍니다. smart contract 애플리케이션은 보다 분산화된 서비스를 통해 가능해지며, 총 DONs의 사용 및 총 수수료가 증가해야 합니다. 수수료 풀 증가 더욱 분산화된 서비스를 창출하기 위한 수단과 인센티브로 전환됩니다. 결과적으로 선순환이 됩니다. 이 선순환은 닭고기와 달걀의 중요한 문제를 해결합니다. 하이브리드 smart contract 생태계의 문제: 혁신적인 smart contract 기능 아직 존재하지 않는 분산형 서비스가 필요한 경우가 많습니다(예: 새로운 DeFi 시장이 자주 발생함) 새로운 데이터 피드가 필요하지만 존재하기 위해서는 충분한 경제적 수요가 필요합니다. 기존 DON에 대한 다양한 smart contract의 수수료 풀링은 다음에 대한 수요를 나타냅니다. 증가하는 사용자 기반에서 추가 분산형 서비스를 생성하여 생성 DONs 및 새롭고 다양한 하이브리드 smart contracts를 지속적으로 활성화하고 있습니다. 요약하자면, 우리는 네트워크 보안의 성장이 선덕에 의해 주도된다고 믿습니다. Chainlink staking 메커니즘의 주기는 다음과 같은 더 큰 성장 패턴을 보여줍니다. Chainlink 네트워크는 분산형 온체인 경제를 구현하는 데 도움이 될 수 있습니다. 서비스.
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.
결론
본 문서에서는 Chainlink의 진화에 대한 비전을 제시했습니다. 주요 테마 이 비전에는 훨씬 더 광범위한 서비스를 제공할 수 있는 네트워크의 능력이 있습니다. 단순한 데이터 전달보다 smart contracts. DON을 미래의 분산형 서비스의 기반으로 사용하여 Chainlink은 성능과 기밀성이 강화된 oracle 기능을 제공하는 것을 목표로 합니다. oracle 네트워크는 강력한 신뢰 최소화를 제공합니다. staking과 같은 원칙적인 암호 경제 메커니즘의 조합을 통해 메인 체인에 의존하여 신중하게 고안된 가드레일과 서비스 수준 시행. DONs는 또한 레이어 2 시스템이 트랜잭션에 대해 유연하고 공정한 주문 정책을 시행하고 멤풀 라우팅 트랜잭션에 대한 가스 비용을 줄이는 데 도움이 됩니다. 함께 찍은, 이러한 기능은 모두 안전하고 풍부한 기능을 갖춘 하이브리드 스마트의 방향으로 나아가고 있습니다. 계약. DONs의 유연성은 기존 Chainlink 서비스를 향상시키고 많은 추가 smart contract 기능 및 응용 프로그램. 그 중에는 원활한 다양한 오프체인 시스템과의 연결, 분산형 ID 생성 기존 데이터, 인프라에 중요한 정보를 적시에 제공하는 데 도움이 되는 우선순위 채널 거래 및 기밀 유지 DeFi 도구. 우리가 여기서 제시한 비전은 야심적입니다. 단기적으로는 역량 강화를 추구합니다. 현재 smart contracts의 도달 범위를 넘어서는 목표를 달성하기 위한 하이브리드 계약을 체결하는 동시에 장기적으로 우리는 분산형 금속층을 구현하는 것을 목표로 하고 있습니다. 행복하게 그릴 수 있어요 합의 알고리즘부터 영지식 증명까지 다양한 새로운 도구와 아이디어 빠르게 발전하는 연구의 결과로 커뮤니티가 발전하고 있는 시스템입니다.
마찬가지로, 우리는 이에 대한 대응으로 이 백서의 아이디어 구현을 우선시할 것으로 기대합니다. Chainlink 사용자 커뮤니티의 요구에 부응합니다. 우리는 다음 단계를 기대합니다 보편적인 연결을 통해 smart contracts에게 권한을 부여하고 세계 차세대 금융의 중추로서의 분산형 기술 그리고 법률 시스템. 감사의 말 이 문서에 그림을 제공한 Julian Alterini와 Shawn Lee에게 감사드립니다.