Polkadot: วิสัยทัศน์สำหรับกรอบงาน Multi-Chain ที่ต่างกัน

Resumo

POLKADOT: VISÃO PARA UMA ESTRUTURA MULTI-CADEIA HETEROGÊNEA ESBOÇO 1 DR. MADEIRA GAVIN FUNDADOR, ETHEREUM E PARIDADE [email protected] Resumo. Todas as arquiteturas blockchain atuais sofrem de uma série de problemas, incluindo meios práticos de extensibilidade e escalabilidade. Acreditamos que isto decorre da ligação de duas partes muito importantes da arquitectura de consenso, nomeadamente canonicidade e validade, muito próximas. Este artigo apresenta uma arquitetura, a multicadeia heterogênea, o que fundamentalmente diferencia os dois. Ao compartimentar estas duas partes e ao manter a funcionalidade geral fornecida a um mínimo absoluto de segurança e transporte, introduzimos meios práticos de extensibilidade central in situ. A escalabilidade é abordada através uma abordagem de dividir e conquistar para estas duas funções, expandindo-se para fora do seu núcleo ligado através do incentivo de nós públicos não confiáveis. A natureza heterogênea desta arquitetura permite que muitos tipos altamente divergentes de sistemas de consenso interoperem em uma “federação” totalmente descentralizada e sem confiança, permitindo que redes abertas e fechadas tenham acesso livre de confiança a um ao outro. Apresentamos um meio de fornecer compatibilidade retroativa com uma ou mais redes pré-existentes, como Ethereum. Acreditamos que tal sistema fornece um componente de nível básico útil na busca geral por um sistema praticamente sistema implementável capaz de atingir níveis de escalabilidade e privacidade no comércio global. 1. Prefácio Este pretende ser um resumo técnico da “visão” de uma possível direção que pode ser tomada no desenvolvimento do paradigma blockchain, juntamente com alguma justificativa sobre por que essa direção é sensata. Ele se estabelece em tantos detalhes quanto possível neste estágio de desenvolvimento um sistema que possa proporcionar uma melhoria concreta num vários aspectos da tecnologia blockchain. Não pretende ser uma especificação, formal ou não. Não pretende ser abrangente nem ser uma projeto final. Não se destina a cobrir aspectos não essenciais da estrutura, como APIs, ligações, linguagens e uso. Isto é notavelmente experimental; onde parâmetros são especificados, eles provavelmente mudarão. Os mecanismos irão ser adicionado, refinado e removido em resposta às necessidades da comunidade ideias e críticas. Grandes porções deste documento provavelmente serão ser revisado à medida que evidências experimentais e prototipagem fornecem nos informações sobre o que funcionará e o que não funcionará. Este documento inclui uma descrição básica do protocolo, juntamente com ideias de orientações que podem ser tomadas para melhorar vários aspectos. Prevê-se que o núcleo descrição será usada como ponto de partida para uma série de provas de conceito. Uma “versão 1.0” final seria baseado neste protocolo refinado, juntamente com as ideias adicionais que foram comprovadas e estão determinadas a necessários para que o projeto atinja seus objetivos. 1.1. História. • 10/09/2016: 0.1.0-prova1 • 20/10/2016: 0.1.0-prova2 • 11/01/2016: 0.1.0-prova3 • 11/10/2016: 0.1.0 2. Introdução Blockchains demonstraram grande promessa de utilidade em vários campos, incluindo “Internet das Coisas” (IoT), finanças, governança, gestão de identidade, descentralização da web e rastreamento de ativos. No entanto, apesar do promessa tecnológica e grande conversa, ainda não vimos implantação significativa no mundo real da tecnologia atual. Acreditamos que isto se deve a cinco falhas principais da actual pilhas de tecnologia: Escalabilidade: quantos recursos são gastos globalmente sobre processamento, largura de banda e armazenamento para o sistema processar uma única transação e quantas as transações podem ser razoavelmente processadas sob condições de pico? Isolabilidade: As necessidades divergentes de múltiplos as partes e as candidaturas sejam abordadas num grau quase óptimo no âmbito do mesmo enquadramento? Capacidade de desenvolvimento: quão bem as ferramentas funcionam? Faça as APIs atendem às necessidades dos desenvolvedores? Existem materiais educativos disponíveis? As integrações certas estão aí? Governança: A rede pode permanecer flexível para evoluir e se adaptar ao longo do tempo? As decisões podem ser feito com suficiente inclusão, legitimidade e transparência para fornecer liderança eficaz de um sistema descentralizado? Aplicabilidade: A tecnologia realmente atende a uma necessidade premente por si só? É necessário outro “middleware” para preencher a lacuna para aplicações reais? No presente trabalho pretendemos abordar os dois primeiros questões: escalabilidade e isolabilidade. Dito isto, acreditamos a estrutura Polkadot pode fornecer melhorias significativas em cada uma dessas classes de problemas. Implementações blockchain modernas e eficientes, como o cliente Paridade Ethereum [17] pode processarmenos em excesso 3.000 transações por segundo quando executado em hardware de consumo de alto desempenho. No entanto, o mundo real atual blockchain redes estão praticamente limitadas a cerca de 30 transações por segundo. Esta limitação tem origem principalmente no facto de os actuais mecanismos de consenso síncrono exigirem amplas margens temporais de segurança em o tempo de processamento esperado, que é agravado pela 1

Introdução

Blockchains demonstraram grande promessa de utilidade em vários campos, incluindo “Internet das Coisas” (IoT), finanças, governança, gestão de identidade, descentralização da web e rastreamento de ativos. No entanto, apesar do promessa tecnológica e grande conversa, ainda não vimos implantação significativa no mundo real da tecnologia atual. Acreditamos que isto se deve a cinco falhas principais da actual pilhas de tecnologia: Escalabilidade: quantos recursos são gastos globalmente sobre processamento, largura de banda e armazenamento para o sistema processar uma única transação e quantas as transações podem ser razoavelmente processadas sob condições de pico? Isolabilidade: As necessidades divergentes de múltiplos as partes e as candidaturas sejam abordadas num grau quase óptimo no âmbito do mesmo enquadramento? Capacidade de desenvolvimento: quão bem as ferramentas funcionam? Faça as APIs atendem às necessidades dos desenvolvedores? Existem materiais educativos disponíveis? As integrações certas estão aí? Governança: A rede pode permanecer flexível para evoluir e se adaptar ao longo do tempo? As decisões podem ser feito com suficiente inclusão, legitimidade e transparência para fornecer liderança eficaz de um sistema descentralizado? Aplicabilidade: A tecnologia realmente atende a uma necessidade premente por si só? É necessário outro “middleware” para preencher a lacuna para aplicações reais? No presente trabalho pretendemos abordar os dois primeiros questões: escalabilidade e isolabilidade. Dito isto, acreditamos a estrutura Polkadot pode fornecer melhorias significativas em cada uma dessas classes de problemas. Implementações blockchain modernas e eficientes, como o cliente Parity Ethereum [17] pode processar mais de 3.000 transações por segundo quando executado em hardware de consumo de alto desempenho. No entanto, o mundo real atual blockchain redes estão praticamente limitadas a cerca de 30 transações por segundo. Esta limitação tem origem principalmente no facto de os actuais mecanismos de consenso síncrono exigirem amplas margens temporais de segurança em o tempo de processamento esperado, que é agravado pelaPOLKADOT: VISÃO PARA UMA ESTRUTURA MULTI-CADEIA HETEROGÊNEA ESBOÇO 1 2 desejo de apoiar implementações mais lentas. Isto é devido a a arquitetura de consenso subjacente: o mecanismo de transição do estado, ou os meios pelos quais as partes agrupam e executar transações, tem sua lógica fundamentalmente ligada no mecanismo de “canonização” de consenso, ou no meio pelo qual as partes acordam uma de uma série de histórias possíveis e válidas. Isso se aplica igualmente a sistemas proof-of-work (PoW), como Bitcoin [15] e Ethereum [5,23] e sistemas de prova de aposta (PoS), como NXT [8] e Bitshares [12]: em última análise, todos sofrem da mesma deficiência. É um simples estratégia que ajudou a tornar blockchains um sucesso. No entanto, acoplando firmemente esses dois mecanismos em uma única unidade do protocolo, também agrupamos vários diferentes atores e aplicações com diferentes perfis de risco, diferentes requisitos de escalabilidade e diferentes necessidades de privacidade. Um tamanho não serve para todos. Acontece com demasiada frequência que, num desejo de amplo apelo, uma rede adota um grau de conservadorismo que resulta em um menor denominador comum servindo de forma otimizada a poucos e, em última análise, levando a um fracasso na capacidade de inovar, executar e adaptar, às vezes dramaticamente. Alguns sistemas, como por ex. Factom [21] abandona completamente o mecanismo de transição de estado. No entanto, grande parte utilidade que desejamos requer a capacidade de transição de estado de acordo com uma máquina de estados compartilhada. Deixar cair resolve um problema alternativo; não oferece uma alternativa solução. Parece claro, portanto, que uma direção razoável explorar como um caminho para uma computação descentralizada e escalonável plataforma é dissociar a arquitetura de consenso da o mecanismo de transição de estado. E, talvez sem surpresa, esta é a estratégia que Polkadot adota como solução para escalabilidade. 2.1. Protocolo, Implementação e Rede. Gosto Bitcoin e Ethereum, Polkadot referem-se ao mesmo tempo a um protocolo de rede e ao (até então pressuposto) primário rede pública que executa este protocolo. Polkadot pretende ser um projeto gratuito e aberto, a especificação do protocolo está sob uma licença Creative Commons e o código sendo colocado sob uma licença FLOSS. O projeto é desenvolvido de forma aberta e aceita contribuições onde quer que sejam úteis. Um sistema de RFCs, não muito diferente as propostas de melhoria do Python, permitirão um meio de colaborar publicamente em mudanças e atualizações de protocolo. Nossa implementação inicial do protocolo Polkadot será conhecida como Plataforma Parity Polkadot e será inclui uma implementação completa do protocolo junto com API ligações. Como outras implementações de Paridade blockchain, O PPP foi projetado para ser uma pilha de tecnologia blockchain de uso geral, não exclusivamente para uma rede pública nem para operação privada/consorciada. O seu desenvolvimento assim até agora foi financiado por vários partidos, inclusive através de uma subvenção do governo britânico. Este artigo, no entanto, descreve Polkadot sob o contexto de uma rede pública. A funcionalidade que imaginamos em uma rede pública é um superconjunto daquela exigida em configurações alternativas (por exemplo, privadas e/ou consórcios). Além disso, neste contexto, o escopo completo de Polkadot pode ser mais claramente descritas e discutidas. Isso significa o leitor deve estar ciente de que certos mecanismos podem ser descritos (por exemplo, interoperação com outras redes públicas) que não são diretamente relevantes para Polkadot quando implantado em situações não públicas (“permitidas”). 2.2. Trabalho anterior. A dissociação do consenso subjacente da transição do Estado foi proposta informalmente em privado durante pelo menos dois anos - Max Kaye foi um defensor de tal estratégia durante os primeiros dias de Ethereum. Uma solução escalável mais complexa conhecida como Chain fibras, que remonta a junho de 2014 e publicado pela primeira vez mais tarde naquele ano1, defendeu uma única cadeia de retransmissão e múltiplas cadeias homogêneas, fornecendo um mecanismo transparente de execução intercadeias. A decoerência foi paga através da latência de transação – transações que exigem o coordenação de porções díspares do sistema demorar mais para processar. Polkadot tira grande parte de sua arquitetura disso e das conversas de acompanhamento com várias pessoas, embora seja muito diferente em grande parte do seu design e disposições. Embora não existam sistemas comparáveis a Polkadot atualmente em produção, vários sistemas de alguma relevância foram propostas, embora poucas em qualquer nível substancial de detalhe. Estas propostas podem serdividido em sistemas que eliminam ou reduzem a noção de um mundo globalmente coerente máquina estatal, aquelas que tentam fornecer uma solução global máquina singleton coerente por meio de fragmentos homogêneos e aqueles que visam apenas a heterogeneidade. 2.2.1. Sistemas sem Estado Global. Factom [21] é um sistema que demonstra canonicidade sem o acordo validade, permitindo efetivamente o registro dos dados. Devido à evitação do estado global e às dificuldades com o dimensionamento que isso traz, pode ser considerada uma solução escalonável. No entanto, como mencionado anteriormente, o conjunto de problemas que resolve é estrita e substancialmente menor. Tangle [18] é uma nova abordagem para sistemas de consenso. Em vez de organizar as transacções em blocos e formar consenso sobre uma lista estritamente ligada para fornecer uma ordenação globalmente canónica das mudanças de estado, abandona em grande parte a ideia de uma ordenação fortemente estruturada e, em vez disso, busca um gráfico acíclico direcionado de transações dependentes com itens posteriores ajudando a canonizar itens anteriores através de referências explícitas. Para mudanças de estado arbitrárias, este gráfico de dependência se tornaria rapidamente intratável, no entanto, para o modelo UTXO2 muito mais simples, isso se torna bastante razoável. Como o sistema é apenas vagamente coerente e as transações são geralmente independentes uma da outra outro, uma grande quantidade de paralelismo global torna-se bastante natural. Usar o modelo UTXO tem o efeito de limitar o Tangle a uma “moeda” puramente de transferência de valor sistema em vez de algo mais geral ou extensível. Além disso, sem a dura coerência global, a interacção com outros sistemas – que tendem a necessitar de uma conhecimento de grau sobre o estado do sistema - torna-se impraticável. 1https://github.com/ethereum/wiki/wiki/Chain-Fibers-Redux 2saída de transação não gasta, o modelo que Bitcoin usa, em que o estado é efetivamente o conjunto de endereços associados a algum valor; as transações agrupam esses endereços e os transformam em um novo conjunto de endereços cuja soma total é equivalente

POLKADOT: VISÃO PARA UMA ESTRUTURA MULTI-CADEIA HETEROGÊNEA ESBOÇO 1 3 2.2.2. Sistemas de Cadeias Heterogêneas. Cadeias laterais [3] é um adição proposta ao protocolo Bitcoin que permitiria interação sem confiança entre a cadeia Bitcoin principal e cadeias laterais adicionais. Não há previsão de qualquer grau de interação “rica” entre cadeias laterais: a interação seria limitada a permitir que as cadeias laterais fossem custodiantes dos bens uns dos outros, efetuando - no local jargão - uma indexação bidirecional 3. A visão final é para uma estrutura onde a moeda Bitcoin possa ser fornecida com funcionalidade adicional, se periférica, por meio de sua vinculação em algumas outras cadeias com transição de estado mais exótica sistemas do que o protocolo Bitcoin permite. Nesse sentido, as cadeias laterais abordam a extensibilidade em vez da escalabilidade. Na verdade, não há fundamentalmente nenhuma disposição sobre a validade das cadeias laterais; tokens de uma cadeia (por exemplo, Bitcoin) mantidos em nome de uma cadeia lateral são garantidos apenas pelo a capacidade da cadeia lateral de incentivar os mineradores a canonizar transições válidas. A segurança da rede Bitcoin não pode ser facilmente transferido para trabalhar em nome de outros blockchains. Além disso, um protocolo para garantir Bitcoin os mineradores fundem a mina (isto é, duplicam seu poder de canonização no da cadeia lateral) e, mais importante, validam que as transições da cadeia lateral estão fora do âmbito desta proposta. Cosmos [10] é um sistema multi-cadeia proposto no mesma linha das cadeias laterais, trocando o Nakamoto PoW método de consenso para o algoritmo Tendermint de Jae Kwon. Essencialmente, descreve múltiplas cadeias (operando em zonas) cada uma usando instâncias individuais do Tendermint, juntamente com um meio de comunicação livre de confiança através de um cadeia de cubo mestre. Esta comunicação entre cadeias é limitada à transferência de ativos digitais (“especificamente sobre tokens”) em vez de informações arbitrárias, no entanto, tal comunicação entre cadeias tem um caminho de retorno para dados, por exemplo para informar ao remetente o status da transferência. Conjuntos de validadores para as cadeias zoneadas e, em particular os meios de incentivá-los, são, como cadeias laterais, deixadas como um problema não resolvido. A suposição geral é que cada cadeia zoneada conterá ela própria um token de valor cuja inflação é usada para pagar por validators. Ainda nos estágios iniciais de design, atualmente a proposta carece de detalhes abrangentes sobre os meios económicos para alcançar a escalabilidade certeza sobre a validade global. Contudo, a fraca coerência necessária entre as zonas e o centro permitirá para flexibilidade adicional sobre os parâmetros do zoneamento cadeias em comparação com um sistema que impõe medidas mais fortes coerência. 2.2.3. Cásper. Ainda não há revisão abrangente ou comparação lado a lado entre Casper [6] e Polkadot foram feitas, embora se possa fazer uma análise bastante abrangente caracterização (e, portanto, imprecisa) dos dois. Casper é uma reimaginação de como um algoritmo de consenso PoS poderia ser baseado em participantes apostando em qual garfo acabaria por se tornar canônico. Consideração substancial foi dada para garantir que ele fosse robusto para a rede forks, mesmo quando prolongados, e possuem algum grau adicional de escalabilidade além do modelo Ethereum básico. Como tal, Casper até agora tendeu a ser um substancialmente mais protocolo complexo do que Polkadot e seus antepassados, e um desvio substancial do formato blockchain básico. Isso permanece sem saber como Casper irá iterar no futuro e como será se finalmente for implantado. Embora Casper e Polkadot representem novos protocolos interessantes e, em certo sentido, aumentos de Ethereum, existem diferenças substanciais entre seus objetivos finais e caminhos para implantação. Cásper é um Ethereum Projeto centrado na fundação originalmente concebido ser uma alteração PoS no protocolo sem desejo de crie um blockchain fundamentalmente escalável. Crucialmente, é projetado para ser um hard fork, em vez de algo mais expansivo e, portanto, todos os Ethereum clientes e usuários seriam necessário atualizar ou permanecer em uma bifurcação de adoção incerta. Como tal, a implementação torna-se substancialmente mais difícil, como é inerente a um projecto descentralizado onde coordenação é necessária. Polkadot difere de várias maneiras; em primeiro lugar, Polkadot foi projetado para ser totalmente extensível e escalável blockchain teste de desenvolvimento, implantação e interação cama. Ele foi construído para ser um arnês amplamente preparado para o futuro, capaz de assimilar novo blockchaintecnologia à medida que se torna disponível, sem coordenação descentralizada excessivamente complicada ou garfos rígidos. Já imaginamos vários casos de uso, como como cadeias de consórcio criptografadas e cadeias de alta frequência com tempos de bloqueio muito baixos que são irrealistas de fazer em qualquer versão futura de Ethereum atualmente prevista. Finalmente, o acoplamento entre ele e Ethereum é extremamente solto; nenhuma ação por parte de Ethereum é necessária para permitir o encaminhamento de transações sem confiança entre os dois redes. Resumindo, enquanto Casper/Ethereum 2.0 e Polkadot compartilham algumas semelhanças passageiras, acreditamos que seu objetivo final é substancialmente diferente e que, em vez de competir, os dois protocolos provavelmente coexistirão sob um relacionamento mutuamente benéfico para o futuro previsível.

Resumo

Polkadot é uma multicadeia heterogênea escalável. Isto significa que, diferentemente das implementações anteriores de blockchain que se concentraram em fornecer uma única cadeia de diversos graus de generalidade sobre aplicações potenciais, Polkadot em si foi projetado para não fornecer nenhuma funcionalidade inerente ao aplicativo. Em vez disso, Polkadot fornece a base “cadeia de retransmissão” sobre a qual um grande número de informações validáveis, estruturas de dados dinâmicas globalmente coerentes podem ser hospedadas lado a lado. Chamamos essas estruturas de dados de “paralelizadas” correntes ou parachains, embora não haja necessidade específica de eles sejam de natureza blockchain. Em outras palavras, Polkadot pode ser considerado equivalente a um conjunto de cadeias independentes (por exemplo, o conjunto contendo Ethereum, Ethereum Classic, Namecoin e Bitcoin), exceto por dois pontos muito importantes: • Segurança conjunta; • transacionalidade entre cadeias sem confiança. É por esses pontos que consideramos Polkadot “escalável”. Em princípio, um problema a ser implantado em Polkadot pode ser substancialmente paralelizado - ampliado - ao longo de um grande número de pára-quedas. Como todos os aspectos de cada parachain pode ser conduzido em paralelo por um segmento diferente da rede Polkadot, o sistema tem alguma capacidade para escalar. Polkadot fornece um pedaço bastante básico de 3em oposição a uma fixação unilateral que é essencialmente a ação de destruir tokens em uma cadeia para criar tokens em outra sem o mecanismo para fazer o inverso a fim de recuperar os tokens originaisPOLKADOT: VISÃO PARA UMA ESTRUTURA MULTI-CADEIA HETEROGÊNEA ESBOÇO 1 4 infraestrutura, deixando grande parte da complexidade para ser abordada no nível do middleware. Esta é uma decisão consciente que visa reduzir o risco de desenvolvimento, permitindo que a software necessário a ser desenvolvido em um curto espaço de tempo e com um bom nível de confiança sobre sua segurança e robustez. 3.1. A Filosofia de Polkadot. Polkadot deveria fornecer uma base absolutamente sólida sobre a qual construir a próxima onda de sistemas de consenso, através o espectro de risco de projetos maduros com capacidade de produção às ideias nascentes. Ao fornecer fortes garantias de segurança, isolamento e comunicação, Polkadot pode permitir parachains para selecionar entre uma variedade de propriedades. Na verdade, prevemos vários blockchains experimentais empurrando as propriedades do que poderia ser considerado sensato hoje. Vemos conservadores, cadeias de alto valor semelhantes a Bitcoin ou Z-cash [20] coexistindo com valores mais baixos “cadeias temáticas” (como marketing, tão divertido) e redes de teste com taxas zero ou quase zero. Vemos totalmente criptografado, cadeias de consórcios “obscuras” operando lado a lado – e até mesmo fornecendo serviços para cadeias altamente funcionais e abertas como aqueles como Ethereum. Vemos novos experimentos Cadeias baseadas em VM, como um wasm subjetivo com cobrança de tempo cadeia sendo usada como um meio de terceirizar problemas de computação difíceis de uma cadeia mais madura do tipo Ethereum ou uma cadeia mais restrita do tipo Bitcoin. Para gerenciar atualizações em cadeia, Polkadot irá inerentemente apoiar algum tipo de estrutura de governança, provavelmente baseada nos sistemas políticos estáveis existentes e com um aspecto bicameral semelhante ao Conselho do Livro Amarelo [24]. Como a autoridade final, os detentores subjacentes de token teriam o controle do “referendo”. Para refletir a opinião dos usuários necessidade de desenvolvimento, mas a necessidade de legitimidade dos desenvolvedores, esperamos que uma direção razoável seja formar as duas câmaras de um comitê “usuário” (composto por vinculados validators) e um comitê “técnico” composto dos principais desenvolvedores de clientes e participantes do ecossistema. O corpo de titulares de token manteria a legitimidade final e formaria uma maioria absoluta para aumentar, reparametrizar, substituir ou dissolver esta estrutura, algo que não duvide da eventual necessidade de: nas palavras de Twain “Governos e fraldas devem ser trocadas com frequência, e para pelo mesmo motivo”. Embora a reparametrização seja normalmente trivial de organizar dentro de um mecanismo de consenso mais amplo, mudanças mais qualitativas, como substituição e aumento, seriam necessárias. provavelmente precisarão ser “decretos suaves” não automatizados (por exemplo, através da canonização de um número de bloco e da hash de um documento especificando formalmente o novo protocolo) ou exigir que o mecanismo central de consenso contenha um linguagem suficientemente rica para descrever qualquer aspecto de si mesmo que pode precisar mudar. Este último é um objetivo eventual, no entanto, é mais provável que o primeiro seja escolhido para facilitar um cronograma de desenvolvimento razoável. Os princípios primários de Polkadot e as regras dentro das quais avaliamos todas as decisões de design são: Mínimo: Polkadot deve ter o mínimo de funcionalidade possível. Simples: nenhuma complexidade adicional deve estar presente no protocolo base do que pode razoavelmente ser transferido para middleware, colocado através de um parachain ou introduzido em uma otimização posterior. Geral: nenhum requisito desnecessário, restrição ou limitação deve ser colocada em pára-quedas; Polkadot deve ser uma plataforma de teste para o desenvolvimento de sistema de consenso que pode ser otimizado por meio de tornando o modelo no qual as extensões se enquadram o mais abstrato possível. Robusto: Polkadot deve fornecer fundamentalmente camada base estável. Além da solidez económica, isto também significa descentralizar para minimizar os vetores para ataques de alta recompensa.

Participação em Polkadot

Existem quatro funções básicas na manutenção de um Polkadot rede: coletor, pescador, nomeador e validator. Em uma possível implementação de Polkadot, a última função na verdade, pode ser dividido em duas funções: validator básico e fiador de disponibilidade; isso é discutido na seção 6.5.3. Coletor Pescador Validadores (este grupo) Validadores (outros grupos) aprova torna-se monitores relatórios ruim comportamento para fornece bloco candidatos para Nomeador Figura 1. A interação entre o quatro funções de Polkadot. 4.1. Validadores. Um validator é a cobrança mais alta e ajuda a selar novos blocos na rede Polkadot. O papel do validator depende de um título suficientemente alto sendo depositado, embora permitamos que outras partes vinculadas nomear um ou mais validators para agir em seu nome e como tal parte do título do validator pode não ser necessariamente propriedade do próprio validator, mas sim destes nomeadores. Um validator deve executar uma implementação de cliente de cadeia de retransmissão com alta disponibilidade e largura de banda. Em cada bloco o nó deve estar pronto para aceitar o papel de ratificar um novo bloco em um parachain nomeado. Este processo envolve receber, validar e republicar candidatos blocos. A nomeação é determinística, mas virtualmente imprevisível com muita antecedência. Como o validator não pode razoavelmente esperado que mantenha um sistema totalmente sincronizado banco de dados de todos os parachains, espera-se que o validator nomeie a tarefa de elaborar uma nova sugestão bloco parachain para terceiros, conhecido como agrupador. Uma vez que todos os novos blocos de parachain tenham sido devidamente ratificados por seus subgrupos validator designados, validators deve então ratificar o próprio bloco da cadeia de relés. Isso envolve atualizando o estado das filas de transação (essencialmente mover dados da fila de saída de um parachain para outra fila de entrada do parachain), processando as transações de o conjunto de transações ratificadas em cadeia de retransmissão e ratificando o bloco final, incluindo as alterações finais do parachain.POLKADOT: VISÃO PARA UMA ESTRUTURA MULTI-CADEIA HETEROGÊNEA ESBOÇO 1 5 Um validator não cumprindo seu dever de encontrar consenso sob as regras do nosso algoritmo de consenso escolhido é punido. Para falhas iniciais e não intencionais, isso ocorre através retendo a recompensa de validator. Falhas repetidas resultam na redução do seu título de segurança (através da queima). Ações provavelmente maliciosas, como assinatura dupla ou conspirar para fornecer um bloqueio inválido resultará na perda de todo o vínculo (que está parcialmente queimado, mas principalmente dado ao informante e aos atores honestos). Em certo sentido, validators são semelhantes aos pools de mineração dos PoW atuais blockchains. 4.2. Nomeadores. Um nominador é uma parte interessada que contribui para a caução de um validator. Eles não têm qualquer função adicional, exceto a de colocar capital de risco e como tal para sinalizar que eles confiam em um determinado validator (ou conjunto deles) a agir com responsabilidade na manutenção do rede. Eles recebem um aumento ou redução proporcional em seu depósito de acordo com o crescimento do título ao qual eles contribuem. Juntamente com os agrupadores, em seguida, os nomeadores estão em alguns sentido semelhante aos mineradores das redes PoW atuais. 4.3. Coletores. Agrupadores de transações (abreviadamente agrupadores) são partes que auxiliam validators na produção de blocos de pára-quedas. Eles mantêm um “nó completo” para um parachain específico; o que significa que eles retêm todos os recursos necessários informações para poder criar novos blocos e executar transações da mesma maneira que os mineradores fazem nos PoW blockchains atuais. Em circunstâncias normais, eles irá agrupar e executar transações para criar um não selado bloquear e fornecê-lo, junto com um conhecimento zero prova, para um ou mais validators atualmente responsáveis por propondo um bloco parachain. A natureza precisa do relacionamento entre agrupadores, nomeadores e validators provavelmente mudará ao longo tempo. Inicialmente, esperamos que os agrupadores trabalhem em estreita colaboração com validators, já que haverá apenas alguns (talvez apenas um) parachain(s) com pouco volume de transações. O a implementação inicial do cliente incluirá RPCs para permitir um nó de agrupamento parachain para fornecer incondicionalmente um nó (relaychain) validator com um parachain comprovadamente válido bloco. Como o custo de manutenção de uma versão sincronizada do todos esses parachains aumentam, esperamos ver infra-estrutura existente que ajudará a separar o deveres para com partidos independentes e com motivação económica. Eventualmente, esperamos ver pools de agrupamentos que disputam coletar o máximo de taxas de transação. Esses agrupadores podem ser contratados para atender validators específicos durante um período de tempo por uma participação contínua nos rendimentos da recompensa. Alternativamente, os agrupadores “freelance” podem simplesmente criar um mercado que oferece blocos de parachain válidos em troca de uma parcela competitiva da recompensa pagável imediatamente. Da mesma forma, os grupos de nominadores descentralizados permitiriam múltiplos participantes vinculados para coordenar e compartilhar o dever de um validator. Esta capacidade de reunir garante uma participação aberta levando a um sistema mais descentralizado. 4.4. Pescadores. Ao contrário dos outros dois partidos activos, pescadores não estão diretamente relacionados com a autoria do bloco processo. Em vez disso, eles são “caçadores de recompensas” independentes motivado por uma grande recompensa única. Precisamente devido a existência de pescadores, esperamos que eventos de mau comportamento aconteçam raramente, e quando acontecem apenas devido a a parte vinculada sendo descuidada com a segurança da chave secreta, e não através de intenção maliciosa. O nome vem desde a frequência esperada da recompensa, os requisitos mínimos para participar e o eventual tamanho da recompensa. Os pescadores obtêm a sua recompensa através de uma prova atempada de que pelo menos uma parte vinculada agiu ilegalmente. Ações ilegais incluem assinar dois blocos cada um com o mesmo pai ratificado ou, no caso de parachains, ajudar a ratificar um inválido bloco. Para evitar recompensas excessivas ou o compromisso e uso ilícito da chave secreta de uma sessão, a recompensa básica para fornecer uma única mensagem assinada ilegalmente por validator é mínimo. Esta recompensa aumenta assintoticamente à medida que mais corroborar assinaturas ilegais de outros validators são desde que implique um ataque genuíno. A assíntota está definida em 66% seguindo nossa afirmação básica de segurança de que pelo menos dois terços dos validators agem com benevolência. Os pescadores são um pouco semelhantes aos “nós completos” em sistemas blockchain atuais que os recursos necessários são relativamente pequenos e o compromisso de tempo de atividade estável e largura de banda não é necessária. Os pescadores diferem tanto tanto quanto eles devem pagar uma pequena fiança.Esse vínculo impede ataques Sybil desperdiçam tempo e computação de validators recursos. É imediatamente retirável, provavelmente não mais do que o equivalente a alguns dólares e pode levar para colher uma grande recompensa por detectar um mau comportamento validator.

Visão geral do projeto

Esta seção tem como objetivo fornecer uma breve visão geral do sistema como um todo. Uma exploração mais aprofundada do sistema é fornecido na seção seguinte. 5.1. Consenso. Na cadeia de retransmissão, Polkadot atinge consenso de baixo nível sobre um conjunto de regras válidas mutuamente acordadas blocos por meio de um algoritmo moderno assíncrono bizantino tolerante a falhas (BFT). O algoritmo será inspirado pelo simples Tendermint [11] e pelo substancialmente mais envolvido HoneyBadgerBFT [14]. Este último fornece uma consenso eficiente e tolerante a falhas sobre um acordo arbitrariamente infraestrutura de rede defeituosa, dado um conjunto de autoridades em sua maioria benignas ou validators. Para uma rede estilo prova de autoridade (PoA), só isso seria suficiente, no entanto, Polkadot é imaginado como sendo também implantável como uma rede em um ambiente totalmente aberto e público situação sem qualquer organização específica ou confiável autoridade necessária para mantê-lo. Como tal precisamos de um meio de determinar um conjunto de validators e incentivar para serem honestos. Para isso utilizamos seleção baseada em PoS critérios. 5.2. Provando a aposta. Supomos que a rede terá alguns meios de medir quanto “aposta” qualquer conta específica possui. Para facilitar a comparação com sistemas pré-existentes, chamaremos a unidade de medida “tokens”. Infelizmente, o termo não é o ideal para uma uma série de razões, inclusive por ser simplesmente um escalar valor associado a uma conta, não há noção de individualidade. Imaginamos que validators sejam eleitos, raramente (no máximo uma vez por dia, mas talvez tão raramente quanto uma vez por trimestre), através de um esquema de Prova de Participação Nomeada (NPoS). O incentivo pode acontecer através de uma alocação proporcional dePOLKADOT: VISÃO PARA UMA ESTRUTURA MULTI-CADEIA HETEROGÊNEA ESBOÇO 1 6 Relé corrente Enxame de validadores (cada um colorido por seu pára-quedas designado) Transação (enviado por ator externo) Parachain ponte Parachain virtual (por exemplo, Ethereum) Parachain Parachain filas e E/S Transações propagadas Bloquear envio de candidato 2ª ordem Cadeia de relés Comunidade Parachain Conta Transação de entrada Transação de saída Transações intercadeias (gerenciado por validators) Coletor Bloco propagado Pescador Figura 2. Um esquema resumido do sistema Polkadot. Isso mostra agrupadores coletando e propagando transações de usuários, bem como propagando candidatos a blocos para pescadores e validators. Também mostra como uma conta pode lançar uma transação que é realizada em seu parachain, através da cadeia de retransmissão e em outro parachain onde pode ser interpretado como uma transação para uma conta lá. fundos provenientes de uma expansão de base token (até 100% por ano, embora mais provavelmente em torno de 10%), juntamente com quaisquer taxas de transação cobradas. Embora a expansão da base monetária normalmente leve à inflação, uma vez que todos os proprietários de token teria uma oportunidade justa de participação, nenhum titular de token precisaria sofrer uma redução no valor de seus participações ao longo do tempo, desde que estivessem felizes em assumir um papel no mecanismo de consenso. Uma proporção específica de tokens seriam direcionados para o processo staking; o a expansão efetiva da base token seria ajustada através um mecanismo baseado no mercado para atingir esta meta. Os validadores estão fortemente vinculados às suas apostas; saindo Os títulos dos validators permanecem em vigor por muito tempo após o término das obrigações dos validators (talvez cerca de 3 meses). Tanto tempo período de liquidação de títulos permite que mau comportamento futuro seja punido até a verificação periódica da cadeia. O mau comportamento resulta em punição, como redução de recompensa ou, nos casos que comprometam intencionalmente a integridade da rede, o validator perdendo parte ou todos os seus interesse para outros validators, informantes ou partes interessadas como um todo (através da queima). Por exemplo, um validator que tenta ratificar ambos os ramos de uma bifurcação (às vezes conhecido como ataque de “curto alcance”) pode ser identificado e punido desta última forma. Ataques de longo alcance “nada em jogo”4 são contornados através de um simples bloqueio de “ponto de verificação” que impede uma reorganização perigosa da cadeia de mais de um profundidade de cadeia específica. Para garantir clientes recém-sincronizados não podem ser enganados na corrente errada, regular ocorrerão “hard forks” (no máximo no mesmo período do validators’ liquidação de títulos) que codifica o bloco de ponto de verificação recente hashes nos clientes. Isto funciona bem com uma medida adicional de redução da pegada de “comprimento finito da cadeia” ou reinicialização periódica do bloco genesis. 5.3. Parachains e coladores. Cada pára-quedas recebe recursos de segurança semelhantes à cadeia de relés: o os cabeçalhos dos parachains são selados dentro do bloco da cadeia de relés garantir que nenhuma reorganização ou “gasto duplo” seja possível após a confirmação. Esta é uma garantia de segurança semelhante à oferecida pelas cadeias laterais e fusão de Bitcoin. Polkadot, no entanto, também fornece fortes garantias de que as transições de estado dos parachains são válidas. Isto acontece através do conjunto de validators sendo segmentado criptograficamente aleatoriamente em subconjuntos; um subconjunto por parachain, os subconjuntos potencialmente diferentes por bloco. Isto a configuração geralmente implica que os tempos de bloqueio dos parachains serão ser pelo menos tão longo quanto o da cadeia de relés. O específico meio de determinar o particionamento está fora do escopo 4É neste tipo de ataque que o adversário forja uma cadeia histórica inteiramente nova, a partir do bloco génese. Através do controle de um parcela relativamente insignificante da aposta na compensação, eles são capazes de aumentar gradativamente sua parcela da aposta em relação a todos os outros partes interessadas, pois são os únicos participantes activos na sua história alternativa. Como não existe nenhuma limitação física intrínseca na criação de blocos (ao contrário do PoW, onde a energia computacional bastante real deve ser gasta), eles são capazes de criar uma cadeia mais longa do que a cadeia real em um intervalo de tempo relativamente curto e potencialmente torná-lo o mais longo e melhor, assumindo o estado canônico da rede.POLKADOT: VISÃO PARA UMA ESTRUTURA MULTI-CADEIA HETEROGÊNEA ESBOÇO 1 7 deste documento, mas provavelmente seria baseado em torno uma estrutura de confirmação-revelação semelhante ao RanDAO [19] ou use dados combinados de blocos anteriores de cada parachain sob um hash criptograficamente seguro. Esses subconjuntos de validators são necessários para fornecer um candidato de bloco parachain que é garantido como válido (em dor de confisco de títulos). A validade gira em torno de dois pontos importantes; primeiro, que é intrinsecamente válido – que todas as transições de estado foram executadas fielmente e que todas os dados externos referenciados (ou seja, transações) são válidos para inclusão. Em segundo lugar, que quaisquer dados extrínsecos à sua candidato, como aquelas transações externas, tem disponibilidade suficientemente alta para que os participantes possam baixe-o e execute o bloco manualmente.5 Os validadores podem fornecer apenas um bloco “nulo” que não contém dados de “transações” externas, mas podem correr o risco de obter uma recompensa reduzida se o fizerem. Eles trabalham ao lado um protocolo de fofoca parachain com agrupadores - indivíduos que agrupam transações em blocos e fornecem uma prova não interativa e de conhecimento zero de que o bloco constitui um filho válido de seu pai (e aceitando qualquer transação taxas por seus problemas). Resta aos protocolos parachain especificar seus próprios meios de prevenção de spam: não existe uma noção fundamental de “medição de recursos computacionais” ou “taxa de transação” imposta pela cadeia de retransmissão. Também não há aplicação direta disso pelo protocolo de cadeia de retransmissão (embora é improvável que as partes interessadas optem por adotar um parachain que não fornecia um mecanismo decente). Este é um aceno explícito à possibilidade de cadeias diferentes Ethereum, por ex. uma cadeia semelhante a Bitcoin que tem um modelo de taxas muito mais simples ou algum outro modelo de prevenção de spam ainda a ser proposto. A própria cadeia de relés de Polkadot provavelmente existirá como um Contas e cadeia de estados semelhantes a Ethereum, possivelmente um derivado de EVM. Como os nós da cadeia de relés serão obrigados a fazer outros processamentos substanciais, taxa de transferência de transações será minimizado em parte através de grandes taxas de transação e, caso nossos modelos de pesquisa exijam, um limite de tamanho de bloco. 5.4. Comunicação Intercadeia. O ingrediente final crítico de Polkadot é a comunicação entre cadeias. Desde parachains podem ter algum tipo de canal de informação entre eles, nos permitimos considerar Polkadot um multi-cadeia escalável. No caso de Polkadot, a comunicação é tão simples quanto possível: transações executadas em um parachain são (de acordo com a lógica dessa cadeia) capazes de efetuar o envio de uma transação para um segundo parachain ou, potencialmente, a cadeia de retransmissão. Como transações externas na produção blockchains, eles são totalmente assíncronos e não há capacidade intrínseca para eles retornarem qualquer tipo de informação de volta à sua origem. Destino: recebe dados de anteriores validators do bloco. A conta recebe postagem: entrada removida de entrada Merkle tree A conta envia postagem: entrada colocada em saída Merkle tree para destino pára-quedas saída Fonte: ações dados com o próximo bloco validators comprovante postal armazenado em saída de pára-quedas Merkle árvore referência roteada colocada no parachain de destino entrada Merkle tree ingresso Figura 3. Um esquema básico mostrando as principais partes do roteamento para postagem transações (“postagens”). Para garantir complexidade mínima de implementação, risco e mínimo camisa de força de futuro arquiteturas parachain, essas transações interchain são efetivamente indistinguível de transações padrão assinadas externamente. A transação possui um segmento de origem, proporcionando a capacidade de identificar um parachain, e um endereço que pode ser de tamanho arbitrário. Ao contrário dos sistemas atuais comuns, como Bitcoin e Ethereum, as transações interchain não vêm com qualquer tipo de “pagamento” de taxa associada; qualquer pagamento desse tipo deve ser gerenciado por meio de lógica de negociação nos parachains de origem e destino. Um sistema como o proposto para O lançamento do Serenity de Ethereum [7] seria um meio simples de gerenciar esse pagamento de recursos entre cadeias, embora presumimos que outros poderão vir à tona no devido tempo. As transações entre cadeias são resolvidas usando um simples mecanismo de enfileiramento baseado em Merkle tree para garantir fidelidade. É tarefa dos mantenedores da cadeia de retransmissão mover transações na fila de saída de um parachain na fila de entrada do parachain de destino. O as transações passadas são referenciadas na cadeia de retransmissão, mas não são relevantesas próprias transações em cadeia. Para evitar que um parachain envie spam para outro parachain com transações, para que uma transação seja enviada, é necessário que a fila de entrada do destino não seja muito grande em a hora do final do bloco anterior. Se a entrada a fila for muito grande após o processamento do bloco, então ela será considerada “saturada” e nenhuma transação poderá ser roteada para dentro dos blocos subsequentes até ser reduzido abaixo do limite. Essas filas são administradas na cadeia de retransmissão permitindo que parachains determinem a saturação um do outro estado; desta forma, uma tentativa fracassada de postar uma transação para um destino paralisado pode ser relatado de forma síncrona. (Embora não exista nenhum caminho de retorno, se uma transação secundária falhar por esse motivo, ela não poderá ser relatada de volta para o chamador original e alguns outros meios de recuperação teria que acontecer.) 5.5. Polkadot e Ethereum. Devido à integridade de Turing de Ethereum, esperamos que haja ampla oportunidade para Polkadot e Ethereum serem interoperáveis com entre si, pelo menos dentro de alguns limites de segurança facilmente dedutíveis. Em suma, prevemos que as transações de Polkadot pode ser assinado por validators e depois inserido 5Tal tarefa pode ser compartilhada entre validators ou pode se tornar a tarefa designada de um conjunto de validators fortemente ligados, conhecido como fiadores de disponibilidade.

POLKADOT: VISÃO PARA UMA ESTRUTURA MULTI-CADEIA HETEROGÊNEA ESBOÇO 1 8 Ethereum onde podem ser interpretados e promulgados por um contrato de encaminhamento de transação. Na outra direção, prevemos o uso de logs (eventos) especialmente formatados provenientes de um “contrato break-out” para permitir uma verificação rápida de que uma determinada mensagem deve ser encaminhada. 5.5.1. Polkadot a Ethereum. Através da escolha de um BFT mecanismo de consenso com validators formado a partir de um conjunto de partes interessadas determinado através de uma votação de aprovação mecanismo, somos capazes de obter um consenso seguro com uma mudando com pouca frequência e número modesto de validators. Em um sistema com um total de 144 validators, um tempo de bloqueio de 4 segundos e uma finalidade de 900 blocos (permitindo ataques maliciosos). comportamento como votos duplos a serem relatados, punidos e reparado), a validade de um bloqueio pode ser razoavelmente considerado comprovado através de apenas 97 assinaturas (dois terços de 144 mais uma) e um período de verificação subsequente de 60 minutos onde nenhuma contestação é depositada. Ethereum é capaz de hospedar um “contrato de invasão” que pode manter os 144 signatários e ser controlado por eles. Como a recuperação da assinatura digital da curva elíptica (ECDSA) leva apenas 3.000 gás sob o EVM, e desde provavelmente só quereríamos que a validação acontecesse em um supermaioria de validators (em vez de unanimidade total), o custo base de Ethereum confirmando que uma instrução foi devidamente validado como proveniente da rede Polkadot não seria superior a 300.000 gás - apenas 6% do o limite total de gás do bloco em 5,5M. Aumentar o número de validators (conforme seria necessário para lidar com dezenas de redes) inevitavelmente aumenta esse custo, no entanto espera-se que a largura de banda de transação de Ethereum cresça ao longo do tempo à medida que a tecnologia amadurece e a infraestrutura melhora. Juntamente com o facto de não todos os validators precisam estar envolvidos (por exemplo, apenas os mais altos validators apostados podem ser chamados para tal tarefa) o os limites deste mecanismo se estendem razoavelmente bem. Supondo uma rotação diária de tais validators (que é bastante conservador (semanalmente ou mesmo mensalmente pode ser aceitável), então o custo para a rede de manutenção esta ponte de encaminhamento Ethereum seria em torno de 540.000 gás por dia ou, aos preços atuais do gás, US$ 45 por ano. Uma transação básica encaminhada sozinha pela ponte custaria cerca de US$ 0,11; o cálculo adicional do contrato custaria mais, é claro. Ao armazenar em buffer e agrupar transações juntos, os custos de autorização de arrombamento podem ser facilmente compartilhada, reduzindo substancialmente o custo por transação; se 20 transações foram necessárias antes do encaminhamento, então o custo do encaminhamento de uma transação básica cairia para cerca de US$ 0,01. Uma alternativa interessante e mais barata a este modelo de contrato com múltiplas assinaturas seria a utilização de assinaturas limiares, a fim de alcançar a semântica de propriedade multilateral. Embora os esquemas de assinatura de limite para ECDSA são computacionalmente caros, aqueles para outros esquemas como as assinaturas de Schnorr são muito razoáveis. Ethereum planeja introduzir primitivos que tornariam tal esquemas baratos para usar no próximo hardfork Metropolis. Se tal meio pudesse ser utilizado, os custos do gás para encaminhar uma transação Polkadot para o Ethereum rede seria drasticamente reduzida a quase zero despesas gerais além dos custos básicos para validação do assinatura e execução da transação subjacente. Neste modelo, os nós validator de Polkadot teriam fazer pouco além de assinar mensagens. Para que as transações sejam realmente roteadas para a rede Ethereum, nós suponha que os próprios validators também residiriam em a rede Ethereum ou, mais provavelmente, que pequenas recompensas ser oferecido ao primeiro ator que encaminha a mensagem para a rede (a recompensa poderia ser paga trivialmente ao originador da transação). 5.5.2. Ethereum a Polkadot. Fazer com que as transações sejam encaminhado de Ethereum para Polkadot usa a noção simples de logs. Quando um contrato Ethereum deseja despachar uma transação para um parachain específico de Polkadot, basta simplesmente celebrar um “contrato de rescisão” especial. O contrato de ruptura exigiria qualquer pagamento que pudesse ser exigido e emitir uma instrução de registro para que sua existência possa ser comprovada através de uma prova Merkle e uma afirmação de que o cabeçalho do bloco correspondente é válido e canônico. Das duas últimas condições, a validade é talvez a mais simples de provar. Em princípio, o único requisito épara cada nó Polkadot que precisa da prova (ou seja, nós validator designados) para executar uma instância totalmente sincronizada de um nó Ethereum padrão. Infelizmente, esta é em si uma dependência bastante pesada. Um mais método leve seria usar uma prova simples de que o cabeçalho foi avaliado corretamente fornecendo apenas o parte da tentativa de estado de Ethereum necessária para executar corretamente as transações do bloco e verificar se os logs (contidos no recibo do bloco) são válidos. Tal “tipo SPV”6 as provas podem ainda exigir uma quantidade substancial de informações; convenientemente, eles normalmente não seriam necessários em todos: um sistema de títulos dentro de Polkadot permitiria títulos terceiros enviem cabeçalhos sob o risco de perder seus título caso algum terceiro (como um “pescador”, ver 6.2.3) forneça uma prova de que o cabeçalho é inválido (especificamente que a raiz estatal ou as raízes receptoras eram impostoras). Em uma rede PoW não finalizada como Ethereum, o a canonicidade é impossível de ser provada de forma conclusiva. Para resolver isso, os aplicativos que tentam contar com qualquer tipo de causa-efeito dependente da cadeia, espere por uma série de “confirmações” ou até que a transação dependente esteja em algum momento. profundidade específica dentro da cadeia. Em Ethereum, este a profundidade varia de 1 bloco para as transações menos valiosas sem problemas de rede conhecidos até 1.200 blocos como era o caso durante o lançamento inicial do Frontier para trocas. Na rede estável “Homestead”, este número fica em 120 blocos para a maioria das exchanges, e provavelmente levaríamos um parâmetro semelhante. Então nós pode imagine nosso Lado Polkadot Ethereuminterface tenha algumas funções simples: poder aceitar um novo cabeçalho da rede Ethereum e validar o PoW, para poder aceitar alguma prova de que um log específico foi emitido pelo contrato de breakout do lado Ethereum para um cabeçalho de profundidade suficiente (e encaminhamento a mensagem correspondente dentro de Polkadot) e finalmente ser capaz de aceitar provas de que um documento anteriormente aceito, mas o cabeçalho ainda não promulgado contém uma raiz de recibo inválida. Para realmente obter os próprios dados do cabeçalho Ethereum (e quaisquer provas de SPV ou refutações de validade/canonicidade) em a rede Polkadot, um incentivo ao encaminhamento 6SPV refere-se à Verificação Simplificada de Pagamento em Bitcoin e descreve um método para os clientes verificarem transações, mantendo apenas uma cópia de todos os cabeçalhos de blocos da cadeia PoW mais longa.POLKADOT: VISÃO PARA UMA ESTRUTURA MULTI-CADEIA HETEROGÊNEA ESBOÇO 1 9 são necessários dados. Isso pode ser tão simples quanto um pagamento (financiado por taxas cobradas do lado Ethereum) pago para qualquer pessoa capaz de encaminhar um bloco útil cujo cabeçalho seja válido. Os validadores seriam chamados a reter informações relativas aos últimos milhares de blocos, a fim de ser capaz de gerenciar forks, seja através de algum meio protocolar intrínseco ou através de um contrato mantido no cadeia de relé. 5.6. Polkadot e Bitcoin. Bitcoin interoperação apresenta um desafio interessante para Polkadot: um chamado “ligação bidirecional” seria uma peça útil de infraestrutura ter do lado de ambas as redes. No entanto, devido as limitações de Bitcoin, fornecer tal pino com segurança é um empreendimento nada trivial. Entregando uma transação de Bitcoin a Polkadot pode, em princípio, ser feito com um processo semelhante ao de Ethereum; um “endereço de ruptura” controlado de alguma forma pelos Polkadot validators poderia receber tokens transferidos (e dados enviados junto com eles). As provas de SPV podem ser fornecidas por oracles incentivados e, juntamente com um período de confirmação, uma recompensa dada por identificação de blocos não canônicos que implicam a transação foi “gasto em dobro”. Quaisquer tokens de propriedade do O “endereço de fuga” seria então, em princípio, controlado por esses mesmos validators para dispersão posterior. O problema, entretanto, é como os depósitos podem ser controlados com segurança a partir de um conjunto rotativo validator. Ao contrário Ethereum que é capaz de tomar decisões arbitrárias com base mediante combinações de assinaturas, Bitcoin é substancialmente mais limitado, com a maioria dos clientes aceitando apenas transações com múltiplas assinaturas com no máximo 3 partes. Estender este número para 36, ​​ou mesmo para milhares, como seria desejável, é impossível no âmbito do protocolo actual. Uma opção é alterar o protocolo Bitcoin para ativar tal funcionalidade, porém os chamados “hard forks” no Bitcoin mundo são difíceis de organizar a julgar pelas tentativas recentes. Uma possibilidade é o uso de assinaturas de limite, esquemas criptográficos para permitir um público unicamente identificável chave para ser efetivamente controlada por múltiplas “partes” secretas, alguns ou todos eles devem ser utilizados para criar uma assinatura válida. Infelizmente, assinaturas de limite compatíveis com ECDSA de Bitcoin são computacionalmente caros para criar e de complexidade polinomial. Outros esquemas como as assinaturas Schnorr oferecem custos muito mais baixos, no entanto, o cronograma em que eles podem ser introduzidos no Bitcoin protocolo é incerto. Dado que a segurança final dos depósitos cabe uma série de validators ligados, uma outra opção é reduzir os porta-chaves com múltiplas assinaturas a apenas um número fortemente subconjunto vinculado do total de validators tal que limite assinaturas tornam-se viáveis ​​(ou, na pior das hipóteses, o nativo de Bitcoin multi-assinatura é possível). Isto naturalmente reduz o valor total de títulos que poderiam ser deduzidos em indenizações caso os validators se comportassem ilegalmente, no entanto, este é uma degradação graciosa, simplesmente estabelecendo um limite superior de a quantidade de fundos que pode circular com segurança entre o duas redes (ou mesmo, na% de perdas caso um ataque dos validators bem-sucedidos). Como tal, acreditamos que não é irrealista colocar um “parachain virtual” de interoperabilidade Bitcoin razoavelmente seguro entre as duas redes, embora ainda assim seja um esforço substancial com um cronograma incerto e muito possivelmente exigindo a cooperação das partes interessadas dentro desse rede.

Protocolo em detalhes

O protocolo pode ser dividido em três partes: o mecanismo de consenso, a interface parachain e roteamento de transações entre cadeias. 6.1. Cadeia de relés Operação. O cadeia de relés vontade provavelmente será uma cadeia muito semelhante a Ethereum no sentido de que é baseado no estado com o endereço de mapeamento do estado para a conta informações, principalmente saldos e (para evitar replays) um contador de transações. Colocar contas aqui cumpre um propósito: fornecer contabilidade para a qual a identidade possui qual a quantidade de participação no sistema.7 No entanto, haverá diferenças notáveis: • Os contratos não podem ser implementados através de transações; seguindo o desejo de evitar a funcionalidade da aplicação na cadeia de relés, não será apoiar a implantação pública de contratos. • O uso de recursos computacionais (“gás”) não é contabilizado; já que as únicas funções disponíveis para uso público será corrigido, a lógica por trás da contabilidade do gás não se sustenta mais. Como tal, será aplicada uma taxa fixa em todos os casos, permitindo mais desempenho de qualquer execução dinâmica de código que pode precisar ser feita e um formato de transação mais simples. • Funcionalidade especial é suportada para contratos listados que permite execução automática e saída de mensagens de rede. Caso a cadeia de retransmissão tenha uma VM e seja baseado em EVM, teria uma série de modificações para garantir a máxima simplicidade. Provavelmente seria têm uma série de contratos integrados (semelhantes aos de endereços 1-4 em Ethereum) para permitir especificações específicas da plataforma deveres a serem gerenciados, incluindo um contrato de consenso, um validator contrato e um contrato parachain. Se não for o EVM, então um backend WebAssembly [2] (wasm) é a alternativa mais provável; neste caso o total estrutura seria semelhante, mas não haveria necessidade para os contratos integrados com Wasm sendo um alvo viável para linguagens de uso geral, em vez de imaturas e idiomas limitados para EVM. Outros desvios prováveis do atual protocolo Ethereum são bem possíveis, por exemplo, uma simplificação do formato de recebimento de transação que permite a execução paralela de transações não conflitantes dentro do mesmo bloco, conforme proposto para a série de mudanças Serenity. É possível, embora improvável, que uma situação semelhante à Serenidade cadeia “pura” seja implantada como cadeia de retransmissão, permitindo uma contrato específico para gerenciar coisas como staking token equilíbrio, em vez de fazer disso uma parte fundamental do o protocolo da cadeia. Actualmente, sentimos que é improvável que isso aconteça. oferecerá uma simplificação de protocolo suficientemente grande para ser vale a pena a complexidade adicional e a incerteza envolvidas em desenvolvê-lo. 7Como forma de representar o montante que um determinado titular é responsável pela segurança geral do sistema, estas contas de participação serão inevitavelmente codificam algum valor econômico. No entanto, deve ser entendido que, uma vez que não há intenção de que tais valores sejam utilizados em de qualquer forma, com a finalidade de troca por bens e serviços do mundo real, deve-se notar, portanto, que os tokens não devem ser comparados a moeda e, como tal, a cadeia de retransmissão mantém a sua filosofia niilista em relação às aplicações.POLKADOT: VISÃO PARA UMA ESTRUTURA MULTI-CADEIA HETEROGÊNEA ESBOÇO 1 10 Há uma série de pequenas funcionalidades necessárias para administrar o mecanismo de consenso, conjunto validator, mecanismo de validação e parachains. Estes poderiam ser implementados em conjunto sob um protocolo monolítico. No entanto, por razões de modularidade, descrevemos estes como “contratos” da cadeia de retransmissão. Isso deveria ser entendido como significando que eles são objetos (no sentido de programação orientada a objetos) gerenciada pelo mecanismo de consenso da cadeia de retransmissão, mas não necessariamente isso eles são definidos como programas em opcodes do tipo EVM, nem mesmo que sejam individualmente endereçáveis através do sistema de contas. 6.2. Contrato de piquetagem. Este contrato mantém o conjunto validator. Ele gerencia: • quais contas são atualmente validators; • que estão disponíveis para se tornarem validators em breve aviso prévio; • quais contas colocaram indicação de aposta para um validator; • propriedades de cada um, incluindo volume staking, taxas de pagamento e endereços aceitáveis ​​e identidades de curto prazo (sessão). Ele permite que uma conta registre o desejo de se tornar um validator vinculados (junto com seus requisitos), para nomear alguma identidade, e para validators vinculados pré-existentes registrar seu desejo de sair desse status. Também inclui o próprio mecanismo de validação e canonização. 6.2.1. Participação-token Liquidez. Geralmente é desejável ter o máximo possível do total de staking tokens para ser apostado nas operações de manutenção da rede desde isso vincula diretamente a segurança da rede à “capitalização de mercado” geral de staking token. Isto pode facilmente ser incentivado através da inflação da moeda e da distribuição dos rendimentos para aqueles que participam como validators. No entanto, fazer isso apresenta um problema: se o token está bloqueado no Contrato de Stake sob pena de redução, como pode uma parte substancial permanecer suficientemente líquido para permitir a descoberta de preços? Uma resposta para isso é permitir um contrato de derivativo direto, garantindo tokens fungíveis em um token apostado subjacente. Isso é difícil de organizar de maneira livre de confiança. Além disso, estes derivados tokens não podem ser tratados de forma igual pela mesma razão que diferentes obrigações governamentais da zona euro não são fungíveis: há é uma chance de o ativo subjacente falhar e se tornar inútil. Com os governos da zona euro, poderia haver uma padrão. Com validator com tokens apostados, o validator pode agir maliciosamente e ser punido. Mantendo nossos princípios, optamos pela solução mais simples: nem todos os tokens podem ser apostados. Isso significaria que alguma proporção (talvez 20%) de tokens permanecerá forçosamente líquida. Embora isto seja imperfeito do ponto de vista da segurança, é pouco provável que faça uma diferença fundamental na a segurança da rede; 80% das reparações possíveis decorrentes do confisco de títulos ainda poderiam ser feitas em comparação com o “caso perfeito” de 100% staking. A proporção entre tokens apostados e líquidos pode ser alcançada de forma bastante simples por meio de um mecanismo de leilão reverso. Essencialmente, titulares de token interessados em ser validator cada um postaria uma oferta para o contrato staking declarando a taxa de pagamento mínima que eles exigiriam para assumir parte. No início de cada sessão (as sessões seriam acontecem regularmente, talvez até uma vez por hora) o validator as vagas seriam preenchidas de acordo com cada pretenso Aposta e taxa de pagamento de validator. Um algoritmo possível pois isso seria aceitar aqueles com as ofertas mais baixas que representam uma aposta não superior à aposta total visada dividido pelo número de slots e não inferior a um limite inferior de metade desse valor. Se as vagas não puderem ser preenchidas, o limite inferior pode ser repetidamente reduzido por algum fator para ser satisfeito. 6.2.2. Nomeando. É possível nomear sem confiança uns staking tokens para um validator ativo, dando-lhes a responsabilidade dos deveres de validator. Nomeando trabalhos através de um sistema de votação de aprovação. Cada candidato a nomeador pode postar uma instrução no contrato staking expressando uma ou mais identidades validator sob cujas responsabilidade que estão preparados para confiar seu vínculo. A cada sessão, os títulos dos nominadores são dispersos para serem representado por um ou mais validators. O algoritmo de dispersão otimiza para um conjunto de validators de total equivalente títulos. Os títulos dos nominadores passam a ser de responsabilidade efetiva do validator ae ganhar interesse ou sofrer um redução da punição em conformidade. 6.2.3. Confisco/queima de títulos. Certo comportamento de validator resulta em uma redução punitiva de seu vínculo. Se o título for reduzido abaixo do mínimo permitido, o sessão é encerrada prematuramente e outra iniciada. Uma lista não exaustiva de mau comportamento validator punível inclui: • Fazer parte de um grupo de pára-quedas incapaz de fornecer consenso sobre a validade de um bloco parachain; • assinar ativamente a validade de um documento inválido bloco de pára-quedas; • incapacidade de fornecer cargas úteis de saída anteriormente votado como disponível; • inatividade durante o processo de consenso; • validação de blocos de cadeia de retransmissão em bifurcações concorrentes. Alguns casos de mau comportamento ameaçam a integridade da rede (como a assinatura de blocos de parachain inválidos e a validação de vários lados de uma bifurcação) e, como tal, resultam num exílio efetivo através da redução total do vínculo. Em outros casos menos graves (por exemplo, inatividade no consenso processo) ou casos em que a culpa não pode ser atribuída com precisão (fazer parte de um grupo ineficaz), uma pequena parte do título pode, em vez disso, ser multado. Neste último caso, este funciona bem com a rotatividade de subgrupos para garantir que os nodos sofrem substancialmente mais perdas do que os nodos benevolentes danificados colateralmente. Em alguns casos (por exemplo, validação multi-fork e inválida assinatura de sub-bloco) validators não conseguem detectar facilmente o mau comportamento uns dos outros, pois a verificação constante de cada bloco de parachain seria uma tarefa muito árdua. Aqui é necessário angariar o apoio de partes externas ao o processo de validação para verificar e relatar tal mau comportamento. As partes recebem uma recompensa por denunciar tal atividade; seu termo, “pescadores”, deriva da improbabilidade de tal recompensa. Dado que estes casos são tipicamente muito graves, prevemos que quaisquer recompensas possam ser facilmente pagas a partir do título confiscado. Em geral preferimos equilibrar a queima (ou seja, redução a nada) com realocação, em vez de tentativa de realocação por atacado. Isto tem o efeito de

POLKADOT: VISÃO PARA UMA ESTRUTURA MULTI-CADEIA HETEROGÊNEA ESBOÇO 1 11 aumentando o valor global do token, compensando o até certo ponto, a rede em geral, e não a rede específica. parte envolvida na descoberta. Isto é principalmente como uma segurança mecanismo: as grandes quantias envolvidas poderiam levar a um incentivo extremo e agudo ao comportamento, se todas elas concedido a um único alvo. Em geral, é importante que a recompensa seja suficientemente grande para fazer com que a verificação valha a pena para a rede, mas não tão grande a ponto de compensar os custos de enfrentar um problema. crime de “nível industrial” bem financiado e bem orquestrado ataque de hacking a algum validator azarado para forçar o mau comportamento. Desta forma, o montante reclamado geralmente não deve ser maior que o vínculo direto do errante validator, para que um surgem incentivos perversos de se comportar mal e se reportar à recompensa. Isto pode ser combatido explicitamente através de um requisito mínimo de títulos diretos para ser um validator ou implicitamente, educando os nomeadores que validators com poucos títulos depositados não têm grande incentivo comportar-se bem. 6.3. Registro Parachain. Cada parachain é definido em este registro. É uma construção relativamente simples, semelhante a um banco de dados, e contém informações estáticas e dinâmicas sobre cada cadeia. As informações estáticas incluem o índice da cadeia (um simples inteiro), junto com a identidade do protocolo de validação, um meio de distinguir entre as diferentes classes de parachain para que o algoritmo de validação correto possa ser dirigido por validators encarregados de apresentar um candidato válido. Uma prova de conceito inicial se concentraria em colocar os novos algoritmos de validação nos próprios clientes, exigindo efetivamente um hard fork do protocolo cada vez que um classe adicional de corrente foi adicionada. Em última análise, porém, pode ser possível especificar o algoritmo de validação em de uma forma rigorosa e eficiente o suficiente para que os clientes sejam capaz de trabalhar efetivamente com novos pára-quedas sem garfo duro. Um caminho possível para isso seria especificar o algoritmo de validação parachain de uma forma bem estabelecida, linguagem compilada nativamente e de plataforma neutra, como WebAssembly. Pesquisas adicionais são necessárias para determinar se isso é realmente viável, no entanto, se for, poderia trazer com isso a tremenda vantagem de banir hard-forks para sempre. As informações dinâmicas incluem aspectos do sistema de roteamento de transações que devem ter um acordo global, como como a fila de entrada do parachain (descrita na seção 6.6). O registro só pode adicionar parachains através de votação em referendo completo; isso poderia ser gerenciado internamente, mas seria mais provável que fosse colocado em um ambiente externo contrato de referendo, a fim de facilitar a reutilização sob componentes de governação mais gerais. Os parâmetros a requisitos de votação (por exemplo, qualquer quórum necessário, maioria obrigatório) para registro de cadeias adicionais e outros, atualizações de sistema menos formais serão definidas em um “mestre constituição”, mas provavelmente seguirão uma abordagem bastante tradicional caminho, pelo menos inicialmente. A formulação precisa está fora de escopo para o presente trabalho, mas, e. uma maioria absoluta de dois terços para aprovar com mais de um terço do sistema total votar positivamente pode ser um ponto de partida sensato. As operações adicionais incluem a suspensão e remoção de pára-quedas. Esperançosamente, a suspensão nunca acontecer, no entanto, foi concebido para ser uma salvaguarda menos há algum problema intratável no sistema de validação de um parachain. O exemplo mais óbvio em que poderia necessária é uma diferença crítica de consenso entre as implementações, levando validators a não conseguirem chegar a um acordo sobre validade ou bloqueios. Os validadores seriam incentivados a usar múltiplas implementações de clientes para que eles possam identificar esse problema antes do confisco dos títulos. Sendo a suspensão uma medida emergencial, seria sob os auspícios da votação dinâmica validator, em vez do que um referendo. A reintegração seria possível tanto dos validators ou de um referendo. A remoção total dos pára-quedas viria apenas após um referendo e com o qual seria necessária uma período de carência substancial para permitir uma transição ordenada para uma cadeia independente ou para se tornar parte de alguma outra sistema de consenso. O período de carência provavelmente seria de na ordem de meses e provavelmente será estabelecido por cadeia no registro de parachain para que diferentes parachains podem desfrutar de diferentes períodos de carência de acordo com sua necessidade. 6.4. Vedação de blocos de relés. Vedação refere-se, em essência, ao processo de canonização; isto é, um dado básico transformar o quemapeia o original em algo fundamentalmente singular e significativo. Sob uma cadeia PoW, vedação é efetivamente sinônimo de mineração. No nosso caso, envolve a coleta de declarações assinadas de validators sobre a validade, disponibilidade e canonicidade de um bloco específico da cadeia de retransmissão e os blocos parachain que ele representa. A mecânica do algoritmo de consenso BFT subjacente está fora do escopo do presente trabalho. Nós iremos em vez disso, descreva-o usando uma primitiva que assume um máquina de estado criadora de consenso. Em última análise, esperamos ser inspirado por uma série de consensos BFT promissores algoritmos no núcleo; Tangaora [9] (uma variante BFT de Jangada [16]), Tendermint [11] e HoneyBadgerBFT [14]. O algoritmo terá que chegar a um acordo sobre múltiplos parachains em paralelo, diferindo assim do habitual blockchain mecanismos de consenso. Assumimos que uma vez o consenso é alcançado, somos capazes de registrar o consenso numa prova irrefutável que pode ser fornecida por qualquer um dos os participantes a ele. Também assumimos que o mau comportamento dentro do protocolo pode ser geralmente reduzido a um pequeno grupo contendo participantes malcomportados para minimizar o dano colateral ao aplicar a punição.8 A prova, que assume a forma de nossas declarações assinadas, é colocada no cabeçalho do bloco da cadeia de retransmissão junto com com alguns outros campos, entre eles a raiz da tentativa de estado da cadeia de retransmissão e a raiz da tentativa de transação. O vedação processo leva lugar sob um solteiro gerador de consenso mecanismo endereçamento ambos o bloco da cadeia de relés e os blocos dos parachains que fazem parte do conteúdo do revezamento: os parachains não são “comprometidos” separadamente por seus subgrupos e depois agrupados mais tarde. Isso resulta em um processo mais complexo para a cadeia de retransmissão, mas nos permite completar todo o consenso do sistema em um único estágio, minimizando a latência e permitindo para requisitos de disponibilidade de dados bastante complexos que são útil para o processo de roteamento abaixo. 8Os esquemas de consenso BFT existentes baseados em PoS, como o Tendermint BFT e o Slasher original, atendem a essas afirmações.

POLKADOT: VISÃO PARA UMA ESTRUTURA MULTI-CADEIA HETEROGÊNEA ESBOÇO 1 12 O estado da máquina de consenso de cada participante pode ser modelado como uma tabela simples (bidimensional). Cada participante (validator) possui um conjunto de informações, no formato de declarações assinadas (“votos”) de outros participantes, em relação a cada candidato de bloco parachain, bem como ao candidato de bloco de retransmissão. O conjunto de informações é composto por duas peças de dados: Disponibilidade: faz isso validator tem saída informações de postagem de transação deste bloco, então eles são capazes de validar adequadamente os candidatos parachain no bloco seguinte? Eles podem votar 1 (conhecido) ou 0 (ainda não conhecido). Uma vez que eles voto 1, eles se comprometem a votar de forma semelhante para o resto deste processo. Votos posteriores que não respeitar isso são motivos para punição. Validade: o bloco parachain é válido e é tudo dados referenciados externamente (por ex. transações) disponível? Isso é relevante apenas para validators atribuídos ao parachain no qual estão votando. Eles podem votar 1 (válido), -1 (inválido) ou 0 (ainda não conhecido). Uma vez que votam diferente de zero, eles estão empenhados em votar desta forma durante o resto do o processo. Votos posteriores que não respeitam isso são motivo de punição. Todos os validators devem enviar votos; poderão ser reapresentados votos, qualificados pelas regras acima. A progressão de o consenso pode ser modelado como vários algoritmos de consenso BFT padrão sobre cada parachain acontecendo em paralelo. Uma vez que estas são potencialmente frustradas por uma situação relativamente pequena minoria de atores maliciosos concentrados em um único grupo parachain, existe um consenso geral para estabelecer um mecanismo de apoio, limitando o pior cenário possível impasse para apenas um ou mais blocos de parachain vazios (e uma rodada de punição para os responsáveis). As regras básicas para validade dos blocos individuais (que permitem que o conjunto total de validators como um todo chegue a consenso sobre ele se tornar o único candidato parachain a ser referenciado a partir do relé canônico): • deve ter pelo menos dois terços dos seus validators votando positivamente e nenhum votando negativamente; • deve ter mais de um terço dos validators votando positivamente quanto à disponibilidade de informações da fila de saída. Se houver pelo menos um voto positivo e pelo menos um negativo sobre a validade, é criada uma condição excepcional e todo o conjunto de validators deve votar para determinar se houver partes maliciosas ou se houver um acidente garfo. Além de válidos e inválidos, um terceiro tipo de votos são permitidos, equivalente a votar em ambos, o que significa que o nó tem opiniões conflitantes. Isto pode ser devido ao proprietário do nó executando múltiplas implementações que fazem discordo, indicando uma possível ambiguidade no protocolo. Depois que todos os votos forem contados do conjunto completo validator, se a opinião perdedora tem pelo menos uma pequena proporção (para ser parametrizado; no máximo metade, talvez significativamente menos) dos votos do parecer vencedor, presume-se então será um fork acidental do parachain e o parachain será automaticamente suspenso do processo de consenso. Caso contrário, assumimos que é um ato malicioso e punimos o minoria que votou a favor da opinião divergente. A conclusão é um conjunto de assinaturas demonstrando canonicidade. O bloco da cadeia de relés pode então ser selado e iniciado o processo de selagem do próximo bloco. 6.5. Melhorias para blocos de relé de vedação. Enquanto este método de vedação oferece fortes garantias sobre a operação do sistema, não tem uma escalabilidade particularmente boa uma vez que as principais informações de cada parachain devem ter seu disponibilidade garantida por mais de um terço de todos os validators. Isso significa que a pegada de responsabilidade de cada validator cresce à medida que mais cadeias são adicionadas. Embora a disponibilidade de dados em redes abertas de consenso é essencialmente um problema não resolvido, existem maneiras de mitigar a sobrecarga colocada nos nós validator. Um simples solução é perceber que embora validators devam assumir assumem a responsabilidade pela disponibilidade dos dados, eles próprios não precisam de armazenar, comunicar ou replicar os dados. Silos de dados secundários, possivelmente relacionados (ou mesmo com o próprio mesmo) os compiladores que compilam esses dados, podem gerenciar o tarefa de garantir a disponibilidade com os validators fornecendo uma parcela de seus juros/receitas em pagamento. No entanto, embora isso possa adquirir alguma escalabilidade intermediária, ainda não ajuda no problema subjacente; desde adicionar mais cadeias geralmente exigirá validators adicionais, o consumo contínuo de recursos de rede (particularmente em termos de largura de banda) cresce com o quadrado de ocorrentes, uma propriedade insustentável a longo prazo. Em última análise, é provável que continuemos a bater a cabeça contra a limitação fundamental que afirma que, para uma rede de consenso para ser considerada disponível como segura, o os requisitos contínuos de largura de banda são da ordem do total validators vezes o total de informações de entrada. Isto é devido a a incapacidade de uma rede não confiável de distribuir adequadamente a tarefa de armazenamento de dados entre muitos nós, que fica além da tarefa eminentemente distribuível de processamento. 6.5.1. Apresentando Latência. Um meio de suavizar isso A regra é relaxar a noção de imediatismo. Ao exigir que 33%+1 validators votem pela disponibilidade apenas eventualmente, e não imediatamente, podemos utilizar melhor a propagação exponencial de dados e ajudar a equilibrar os picos no intercâmbio de dados. Uma igualdade razoável (embora não comprovada) pode ser: (1) latência = participantes × cadeias No modelo atual, o tamanho do sistema aumenta com o número de cadeias para garantir que o processamento seja distribuído; já que cada cadeia exigirá pelo menos um validator e fixamos o atestado de disponibilidade para uma constante proporção de validators, então os participantes crescem de forma semelhante com o número de cadeias. Terminamos com: (2) latência = tamanho2 O que significa que à medida que o sistema cresce, a largura de banda necessária e a latência até que a disponibilidade seja conhecida em todo o rede, que também pode ser caracterizada como o número de blocos antes da finalidade, aumenta com seu quadrado. Isto é um factor de crescimento substancial e pode revelar-se um obstáculo notável e forçar-nos a paradigmas “não planos” como compor vários “Polkadotes” em uma hierarquia para roteamento multinível de postagens por meio de uma árvore de cadeias de retransmissão.

POLKADOT: VISÃO PARA UMA ESTRUTURA MULTI-CADEIA HETEROGÊNEA ESBOÇO 1 13 6.5.2. Participação Pública. Mais uma direção possível é conseguir a participação pública no processo através de uma sistema de micro-reclamações. Semelhante aos pescadores, há poderiam ser partes externas para policiar os validators que reivindicam disponibilidade. A sua tarefa é encontrar alguém que pareça incapaz de demonstrar tal disponibilidade. Ao fazer isso eles pode apresentar uma micro-reclamação a outros validators. PoW ou um título apostado pode ser usado para mitigar o ataque de sibila o que tornaria o sistema em grande parte inútil. 6.5.3. Fiadores de Disponibilidade. Um caminho final seria nomear um segundo conjunto de validators vinculados como “disponibilidade fiadores”. Eles seriam ligados da mesma forma que os validators normais e podem até ser retirados do mesmo conjunto (embora, nesse caso, seriam escolhidos durante um período de longo prazo, pelo menos por sessão). Ao contrário dos validators normais, eles não mudaria entre parachains, mas sim formar um único grupo para atestar a disponibilidade de todos os dados intercadeias importantes. Isto tem a vantagem de relaxar a equivalência entre participantes e cadeias. Essencialmente, as cadeias podem crescer (junto com o conjunto original da cadeia validator), enquanto os participantes, e especificamente aqueles que participam do testamento de disponibilidade de dados, podem permanecer pelo menos sublineares e possivelmente constante. 6.5.4. Preferências do agrupador. Um aspecto importante deste sistema é garantir que haja uma seleção saudável de agrupadores criando os blocos em qualquer parachain. Se um único agrupador dominou um parachain e depois alguns ataques tornar-se mais viável, uma vez que a probabilidade da falta de a disponibilidade de dados externos seria menos óbvia. Uma opção é pesar artificialmente blocos de parachain em um mecanismo pseudo-aleatório para favorecer uma ampla variedade de agrupadores. No primeiro caso, precisaríamos como parte do mecanismo de consenso que validators favorece candidatos do bloco parachain determinados como “mais pesados”. Da mesma forma, devemos incentivar validators a tentar sugerir o bloco mais pesado que puderem encontrar - isso pode ser feito através de uma parcela de sua recompensa proporcional ao peso de seu candidato. Para garantir que os agrupadores recebam uma avaliação justa e razoável chance de seu candidato ser escolhido como vencedor candidato em consenso, fazemos o peso específico de um candidato de bloco parachain determinado em uma função aleatória conectada a cada agrupador. Por exemplo, tomando a medida da distância XOR entre o endereço do ordenador e algum número pseudoaleatório criptograficamente seguro determinado próximo ao ponto do bloco que está sendo criado (um “bilhete vencedor” nocional). Isso efetivamente dá a cada agrupador (ou, mais especificamente, o endereço de cada agrupador) um chance aleatória de seu bloco candidato “ganhar” todos os outros. Para mitigar o ataque sybil de um único agrupador “minerando” um endereço próximo ao bilhete vencedor e assim sendo um favorito em cada bloco, adicionaríamos alguma inércia ao endereço de um agrupador. Isso pode ser tão simples quanto exigir que eles ter uma quantia básica de fundos no endereço. Um mais abordagem elegante seria ponderar a proximidade com o bilhete vencedor com o valor dos fundos estacionados no endereço em questão. Embora a modelagem ainda não tenha sido feita, é bem possível que este mecanismo permita até mesmo pequenas partes interessadas contribuam como compiladores. 6.5.5. Blocos de excesso de peso. Se um conjunto validator for comprometido, eles podem criar e propor um bloco que, embora válido, leva uma quantidade excessiva de tempo para ser executado e validar. Isto é um problema já que um grupo validator poderia razoavelmente formar um bloco que leva muito tempo para executar, a menos que alguma informação específica já seja conhecida, permitindo um atalho, por ex. fatorando um grande principal. Se um único compilador conhecesse essa informação, então eles teriam uma clara vantagem em obter o seu próprio os candidatos aceitaram desde que os demais estivessem ocupados processando o bloco antigo. Chamamos esses blocos de excesso de peso. A proteção contra o envio e validação desses blocos por validators cai em grande parte sob o mesmo disfarce que para blocos inválidos, embora com uma ressalva adicional: já que o tempo necessário para executar um bloco (e, portanto, seu status como excesso de peso) é subjetivo, o resultado final de uma votação sobre o mau comportamento cairá essencialmente em três campos. Um possibilidade é que o bloco definitivamente não esteja acima do peso - neste caso, mais de dois terços declaram que poderiam execute o bloco dentro de algum limite (por exemplo, 50% do tempo total permitido entre blocos). Outra é que o bloco é ddefinitivamente acima do peso - isso aconteceria se mais de dois terços declaram que não conseguiram executar o bloco dentro do referido limite. Uma última possibilidade é uma situação razoavelmente igual divisão de opinião entre validators. Neste caso, podemos escolha fazer alguma punição proporcional. Para garantir que validators possam prever quando poderão ser propondo um bloco com excesso de peso, poderá ser sensato exigir-lhes que publiquem informações sobre o seu próprio desempenho para cada bloco. Durante um período de tempo suficiente, isso deve permitir que eles avaliem sua velocidade de processamento em relação aos pares que os julgariam. 6.5.6. Seguro de Colador. Um problema permanece para validators: ao contrário das redes PoW, para verificar o bloco para validade, eles devem realmente executar as transações nele. Coletores maliciosos podem alimentar blocos inválidos ou com excesso de peso para validators, causando-lhes sofrimento (desperdiçando seus recursos) e cobrando um custo de oportunidade potencialmente substancial. Para mitigar esta situação, propomos uma estratégia simples sobre o parte de validators. Em primeiro lugar, os candidatos ao bloco parachain foram enviados para validators devem ser assinados a partir de uma conta de cadeia de retransmissão com fundos; se não estiverem, então o validator deve cair isso imediatamente. Em segundo lugar, esses candidatos devem ser ordenados em prioridade por uma combinação (por exemplo, multiplicação) de a quantidade de fundos na conta até certo limite, o número de blocos anteriores que o ordenador propôs com sucesso no passado (sem mencionar qualquer bloco anterior punições), e o fator de proximidade com o vencedor bilhete conforme discutido anteriormente. A tampa deve ser a mesma como os danos punitivos pagos ao validator no caso deles enviando um bloco inválido. Para desincentivar os agrupadores de enviar candidatos de bloco inválidos ou com excesso de peso para validators, qualquer validator pode colocar no próximo bloco uma transação incluindo o bloco infrator, alegando mau comportamento com o efeito de transferir alguns ou todos os fundos na conta do ordenador que se comportou mal. conta ao lesado validator. Este tipo de transação antecipa qualquer outra para garantir que o ordenador não possa remover os fundos antes da punição. A quantidade de fundos transferidos como indenização é um parâmetro dinâmico ainda

POLKADOT: VISÃO PARA UMA ESTRUTURA MULTI-CADEIA HETEROGÊNEA ESBOÇO 1 14 a ser modelado, mas provavelmente será uma proporção da recompensa do bloco validator para refletir o nível de sofrimento causado. Para evitar que validators maliciosos confisquem arbitrariamente os fundos dos agrupadores, o agrupador poderá apelar da decisão do validator com um júri de validators escolhidos aleatoriamente em troca para fazer um pequeno depósito. Se eles acharem a favor de validator, o depósito será consumido por eles. Se não, o o depósito é devolvido e o validator é multado (já que o validator estiver em uma posição muito mais abobadada, a multa será provavelmente será bastante pesado). 6.6. Intercadeia Transação Roteamento. Intercadeia o roteamento de transações é uma das manutenções essenciais tarefas da cadeia de relés e seus validators. Este é o lógica que governa como uma transação lançada (muitas vezes abreviada para simplesmente “post”) deixa de ser uma saída desejada de um parachain de origem para ser uma entrada não negociável de outro parachain de destino sem qualquer confiança requisitos. Escolhemos cuidadosamente o texto acima; notavelmente nós não exige que tenha havido uma transação na origem parachain por ter sancionado explicitamente esta postagem. O único restrições que colocamos em nosso modelo é que parachains devem fornecer, embalados como parte de seu bloco geral saída de processamento, as postagens que são o resultado do execução do bloco. Essas postagens são estruturadas como diversas filas FIFO; o número de listas é conhecido como base de roteamento e pode ser cerca de 16. Notavelmente, este número representa a quantidade de pára-quedas que podemos apoiar sem ter que recorrer a roteamento multifásico. Inicialmente, Polkadot apoiará isso tipo de roteamento direto, no entanto, descreveremos um possível processo de roteamento multifásico (“hiper-roteamento”) como meio de expandir muito além do conjunto inicial de parachains. Nós assumir isso tudo participantes sabe o subgrupos para os próximos dois blocos n, n + 1. Em resumo, o O sistema de roteamento segue estas etapas: • CollatorS: entre em contato com membros dos Validadores[n][S] • Agrupadores: PARA CADA subgrupo: garantir pelo menos pelo menos 1 membro dos validadores[n][s] em contato • Coletores: PARA CADA subgrupo: assumir egress[n −1][s][S] está disponível (todas as postagens recebidas dados para 'S' do último bloco) • Coletores: Componha o bloco candidato b para S: (b.cabeçalho, b.ext, b.prova, b.recibo, b.egress) • Coletores: Enviar prova informação prova[S] = (b.cabeçalho, b.ext, b.prova, b.recibo) para Validadores[n][S] • CollatorS: Garante dados de transações externas b.ext é disponibilizado para outros agrupadores e validators • Coletores: PARA CADA subgrupo é: Enviar saída informação saída[n][S][s] = (b.cabeçalho, b.recibo, b.egress[s]) para o recebendo subgrupo membros de próximo bloquear Validadores[n + 1][s] • ValidadorV: pré-conecta todos os membros do mesmo conjunto para o próximo bloco: seja N = Chain[n + 1][V ]; conectar todos os validators v tais que Chain[n + 1][v] = N • ValidadorV: Agrupe toda a entrada de dados para isso bloco: PARA CADA subgrupo é: Recuperar egress[n −1][s][Chain[n][V ]], obtém de outros validators v tal que Chain[n][v] = Chain[n][V ]. Possivelmente passando por outros validators selecionados aleatoriamente para prova de tentativa. • ValidadorV: Aceite provas de candidato para isso prova de bloco[Cadeia[n][V]]. Validade do bloco de votação • ValidadorV: Aceitar dados de saída de candidatos para próximo bloco: PARA CADA subgrupo s, aceite saída[n][s][N]. Disponibilidade de saída do bloco de votação; republicar entre validators interessados v de forma que Cadeia[n + 1][v] = Cadeia[n + 1][V ]. • ValidadorV: ATÉ CONSENSO Onde: egress[n][from][to] é a fila de saída atual informações para postagens que vão do parachain ‘de’, para parachain ‘to’ no número do bloco ‘n’. CollatorS é um agrupador para parachain S. V alidators[n][s] é o conjunto de validators para parachain s no bloco número n. Por outro lado, Chain[n][v] é o parachain ao qual validator v é atribuído no bloco número n. block.egress[to] é a saída fila de postagens de algum bloco parachain cujo parachain de destino é. Como os agrupadores cobram taxas (de transação) com base em seus blocos se tornando canônicos, eles são incentivados a garantir que, para cada destino do próximo bloco, o subgrupo os membros são informados da fila de saída do presente bloco. Os validadores são incentivados apenas a formar um consenso sobre um bloco (parachain), portanto, eles pouco se importam com qual bloco do ordenador finalmente se torna canônico. Em princípio, um validator poderia formar uma aliança com um agrupador e conspirar para reduzir as chances de outros agrupadores bloqueia se tornar canônico, no entanto, isso é difícil para organizar devido à seleção aleatóriaação de validators para parachains e poderia ser defendido com uma redução nas taxas a pagar por blocos de parachain que resistem o processo de consenso. 6.6.1. Disponibilidade de dados externos. Garantindo um paraquedas dados externos estão realmente disponíveis é um problema perene com sistemas descentralizados com o objetivo de distribuir a carga de trabalho entre a rede. No centro da questão está a disponibilidade problema que afirma que, como não é possível fazer uma prova de disponibilidade não interativa nem qualquer tipo de prova de indisponibilidade, para que um sistema BFT funcione adequadamente validar qualquer transição cuja correção dependa do disponibilidade de alguns dados externos, o número máximo de nós aceitavelmente bizantinos, mais um, do sistema deve atestar que os dados estão disponíveis. Para que um sistema seja dimensionado corretamente, como Polkadot, isso convida a um problema: se uma proporção constante de validators deve atestar a disponibilidade dos dados, e assumindo que validators desejarão realmente armazenar os dados antes de afirmar que estão disponíveis, então como podemos evitar o problema dos requisitos de largura de banda/armazenamento aumentando com o tamanho do sistema (e, portanto, o número de validators)? Uma resposta possível seria ter um conjunto separado de validators (garantidores de disponibilidade), cujo pedido cresce sublinearmente com o tamanho de Polkadot como um todo. Isto é descrito em 6.5.3. Também temos um truque secundário. Como grupo, os agrupadores têm um incentivo intrínseco para garantir que todos os dados sejam disponível para o parachain escolhido, pois sem ele eles não são capazes de criar mais blocos a partir dos quais possam cobrar taxas de transação. Os agrupadores também formam um grupo cuja composição é variada (devido à natureza aleatória do parachain validator grupos) não trivial de entrar e fácil

POLKADOT: VISÃO PARA UMA ESTRUTURA MULTI-CADEIA HETEROGÊNEA ESBOÇO 1 15 para provar. Os agrupadores recentes (talvez dos últimos milhares de blocos) estão, portanto, autorizados a emitir desafios para a disponibilidade de dados externos para um determinado parachain bloco para validators para um pequeno título. Os validadores devem entrar em contato com aqueles do subgrupo aparentemente infrator validator que testemunharam e adquirir e devolver os dados ao compilador ou escalar o questão, testemunhando a falta de disponibilidade (a recusa direta em fornecer os dados conta como um crime de confisco de títulos, portanto, o mau comportamento validator provavelmente apenas interromper a conexão) e entrar em contato com validators adicionais para executar o mesmo teste. Neste último caso, a caução do colator é retornado. Assim que for alcançado um quórum de validators que possam fazer tais depoimentos de indisponibilidade, eles serão liberados, o o subgrupo que se comporta mal é punido e o bloqueio é revertido. 6.6.2. Roteamento de postagens. Cada cabeçalho parachain inclui um saída-trie-root; esta é a raiz de uma tentativa contendo o compartimentos de base de roteamento, sendo cada compartimento uma lista concatenada de postos de saída. As provas Merkle podem ser fornecidas em parachain validators para provar que um determinado parachain O bloco tinha uma fila de saída específica para um parachain de destino específico. No início do processamento de um bloco parachain, cada a fila de saída de outro parachain com destino ao referido bloco é mesclado na fila de entrada do nosso bloco. Assumimos forte, provavelmente CSPR9, ordenação de subbloco para alcançar uma operação determinística que não oferece favoritismo entre quaisquer emparelhamento de blocos parachain. Os agrupadores calculam a nova fila e drenar as filas de saída de acordo com o parachain lógica. O conteúdo da fila de entrada é escrito explicitamente no bloco de pára-quedas. Isto tem dois propósitos principais: em primeiro lugar, significa que o parachain pode ser sincronizado sem confiança, isoladamente dos outros parachains. Em segundo lugar, simplifica a logística de dados caso todo o ingresso a fila não pode ser processada em um único bloco; validators e agrupadores são capazes de processar os seguintes blocos sem ter que obter os dados da fila especialmente. Se a fila de entrada do parachain estiver acima de um limite valor no final do processamento do bloco, então ele é marcado saturado na cadeia de retransmissão e nenhuma mensagem adicional pode ser entregue a ele até que seja liberado. As provas de Merkle são usado para demonstrar a fidelidade da operação do alceador em a prova do bloco parachain. 6.6.3. Crítica. Uma pequena falha relacionada a este mecanismo é o ataque pós-bomba. É aqui que todos parachains enviam o máximo de posts possíveis para um parachain específico. Embora isso amarre o alvo fila de entrada de uma só vez, nenhum dano é causado além um ataque DoS de transação padrão. Operando normalmente, com um conjunto de sinais bem sincronizados e agrupadores não maliciosos e validators, para N parachains, N × M total de validators e L agrupadores por parachain, nós pode dividir o total de caminhos de dados por bloco para: Validador: M −1+L+L: M −1 para os outros validators no conjunto de parachain, L para cada ordenador fornecendo um bloco de parachain candidato e um segundo L para cada ordenador do próximo bloco exigindo as cargas de saída do bloco anterior. (Este último é na verdade mais parecido com o pior caso operação, uma vez que é provável que os agrupadores compartilhem tais dados.) Collator: M +kN: M para uma conexão com cada bloco parachain validator, kN para semear as cargas úteis de saída para algum subconjunto de cada grupo parachain validator para o próximo bloco (e possivelmente algum(s) agrupador(es) preferido(s)). Como tal, os caminhos dos dados por nó crescem linearmente com a complexidade geral do sistema. Enquanto isso é razoável, à medida que o sistema se expande para centenas ou milhares de parachains, alguma latência de comunicação pode ser absorvido em troca de uma taxa de crescimento de menor complexidade. Neste caso, um algoritmo de roteamento multifásico pode ser usado para reduzir o número de caminhos instantâneos ao custo da introdução de buffers de armazenamento e latência. 6.6.4. Roteamento hipercubo. O roteamento hipercubo é um mecanismo que pode ser construído principalmente como uma extensão do mecanismo básico de roteamento descrito acima. Essencialmente, em vez de aumentar a conectividade do nó com o número de parachains e nós de subgrupos, crescemos apenas com o logaritmo dos parachains. As postagens podem transitar entre várias filas de parachains a caminho da entrega final. O roteamento em si é determinístico e simples. Começamos por limitar o número de compartimentos nas filas de entrada/saída; em vez de serem o número total de pára-quedas, eles são osbase de roteamento (b) . Isso será corrigido como o número de mudanças de parachains, com o expoente de roteamento (e) sendo aumentado. Sob este modelo, nosso volume de mensagens cresce com O (ser), com os caminhos permanecendo constantes e a latência (ou número de blocos necessários para entrega) com O(e). Nosso modelo de roteamento é um hipercubo de dimensões e, com cada lado do cubo tendo b localizações possíveis. Cada bloco roteamos mensagens ao longo de um único eixo. Nós alterne o eixo de forma round-robin, garantindo assim o pior tempo de entrega dos blocos e. Como parte do processamento de parachain, com destino ao exterior as mensagens encontradas na fila de entrada são roteadas imediatamente para o compartimento apropriado da fila de saída, considerando o número do bloco atual (e, portanto, dimensão de roteamento). Isto o processo necessita de transferência de dados adicional para cada salto na rota de entrega, no entanto, isso é um problema em si que pode ser mitigado usando alguns meios alternativos de entrega de carga útil de dados e incluindo apenas uma referência, em vez da carga útil completa da postagem no pós-teste. Um exemplo de roteamento hipercubo para um sistema com 4 parachains, b = 2 e e = 2 pode ser: Fase 0, em cada mensagem M: • sub0: se Mdest ∈{2, 3} então sendTo(2) senão mantém • sub1: se Mdest ∈{2, 3} então sendTo(3) senão mantém • sub2: se Mdest ∈{0, 1} então sendTo(0) senão mantém • sub3: se Mdest ∈{0, 1} então sendTo(1) senão mantém Fase 1, em cada mensagem M: • sub0: se Mdest ∈{1, 3} então sendTo(1) senão mantém • sub1: se Mdest ∈{0, 2} então sendTo(0) senão mantém • sub2: se Mdest ∈{1, 3} então sendTo(3) senão mantém • sub3: se Mdest ∈{0, 2} então sendTo(2) senão mantém As duas dimensões aqui são fáceis de ver como a primeira dois bits do índice de destino; para o primeiro bloco, o apenas um bit de ordem superior é usado. O segundo bloco trata com o bit de ordem inferior. Uma vez que ambos acontecem (de forma arbitrária ordem) então a postagem será roteada. 9pseudo-aleatório criptograficamente seguro

POLKADOT: VISÃO PARA UMA ESTRUTURA MULTI-CADEIA HETEROGÊNEA ESBOÇO 1 16 6.6.5. Maximizando a Serendipidade. Uma alteração do básico proposta veria um total fixo de c2 −c validators, com c−1 validators em cada subgrupo. Cada bloco, em vez de havendo um reparticionamento não estruturado de validators entre parachains, em vez de para cada subgrupo de parachains, cada validator seria atribuído a um único e diferente subgrupo parachain no bloco seguinte. Isso seria levam ao invariante que entre quaisquer dois blocos, para qualquer dois pares de parachain, existem dois validators que trocaram as responsabilidades do parachain. Embora isto não possa ser usado para obter garantias absolutas sobre a disponibilidade (um único validator ocasionalmente ficará off-line, mesmo se benevolente), pode, no entanto, otimizar o caso geral. Esta abordagem não é isenta de complicações. A adição de um parachain também exigiria uma reorganização do conjunto validator. Além disso o número de validators, estando vinculado ao quadrado do número de parachains, começaria inicialmente muito pequeno e eventualmente cresceria muito muito rápido, tornando-se insustentável após cerca de 50 parachains. Nenhum destes são problemas fundamentais. No primeiro caso, reorganização dos conjuntos validator é algo que deve ser feito regularmente de qualquer maneira. Em relação ao tamanho do validator definido, quando muito pequeno, vários validators podem ser atribuídos para o mesmo parachain, aplicando um fator inteiro ao total geral de validators. Um mecanismo de roteamento multifásico, como o roteamento hipercubo, discutido em 6.6.4, aliviar a necessidade de um grande número de validators quando há um grande número de cadeias. 6.7. Validação Parachain. O objetivo principal de um validator é testemunhar, como um ator bem vinculado, que o parachain bloco é válido, incluindo, mas não limitado a, qualquer transição de estado, quaisquer transações externas incluídas, a execução de quaisquer postos de espera na fila de entrada e o estado final da fila de saída. O processo em si é bastante simples. Uma vez que o validator selou o bloco anterior, eles estão livres para começar a trabalhar para fornecer um bloco de parachain candidato candidato para a próxima rodada de consenso. Inicialmente, o validator encontra um candidato a bloco parachain por meio de um agrupamento de parachain (descrito a seguir) ou um de seus co-validators. Os dados do candidato do bloco parachain inclui o cabeçalho do bloco, o cabeçalho do bloco anterior, quaisquer dados de entrada externos incluídos (para Ethereum e Bitcoin, tais dados seriam chamados de transações, no entanto, em princípio, podem incluir estruturas de dados arbitrárias para fins arbitrários), dados de fila de saída e dados internos para provar a validade da transição de estado (para Ethereum estes seriam os vários nós de teste de estado/armazenamento necessários para executar cada transação). Evidências experimentais mostram este conjunto de dados completo para um bloco Ethereum recente ter no máximo algumas centenas de KiB. Simultaneamente, se ainda não for feito, o validator será tentando recuperar informações relativas à transição do bloco anterior, inicialmente a partir do bloco anterior validators e posteriores de todos os validators que assinam o disponibilidade dos dados. Depois que validator receber esse bloco de candidato, eles então o validam localmente. O processo de validação está contido no módulo validator da classe parachain, um módulo de software sensível ao consenso que deve ser escrito para qualquer implementação de Polkadot (embora em princípio uma biblioteca com C ABI poderia permitir que uma única biblioteca ser compartilhado entre implementações com o apropriado redução na segurança resultante de ter apenas uma única implementação de “referência”). O processo pega o cabeçalho do bloco anterior e verifica sua identidade através da cadeia de retransmissão recentemente acordada. bloco no qual seu hash deve ser gravado. Uma vez verificada a validade do cabeçalho pai, o parachain específico a função de validação da classe pode ser chamada. Esta é uma função única que aceita vários campos de dados (aproximadamente aqueles fornecidos anteriormente) e retornando um booleano simples proclamando a validade do bloqueio. A maioria dessas funções de validação verificará primeiro o campos de cabeçalho que podem ser derivados diretamente de o bloco pai (por exemplo, pai hash, número). Seguindo isso, eles preencherão quaisquer estruturas de dados internas como necessários para processar transações e/ou postagens. Para uma cadeia do tipo Ethereum, isso equivale a preencher um teste o banco de dados com os nós que serão necessários para o execução completa das transações. Outros tipos de cadeia podem ter outro pmecanismos reparatórios. Uma vez feito isso, os posts de entrada e as transações externas (ou o que quer que os dados externos representem) serão promulgada, equilibrada de acordo com a especificação da cadeia. (Um o padrão sensato pode ser exigir que todas as postagens de entrada sejam processado antes que as transações externas sejam atendidas, no entanto, isso deve ser decidido pela lógica do parachain.) Através desta lei, uma série de postos de saída serão criados e será verificado se estes realmente correspondem o candidato do colador. Finalmente, o devidamente preenchido o cabeçalho será verificado em relação ao cabeçalho do candidato. Com um bloco candidato totalmente validado, o validator pode então votar no hash de seu cabeçalho e enviar todas as informações de validação necessárias para os co-validators em seu subgrupo. 6.7.1. Coladores Parachain. Os agrupadores de parachain são operadores não vinculados que cumprem grande parte da tarefa dos mineradores nas redes blockchain atuais. Eles são específicos para um parachain específico. Para funcionarem devem manter a cadeia de relés e o totalmente sincronizado pára-quedas. O significado preciso de “totalmente sincronizado” dependerá da classe do parachain, embora sempre inclua o estado atual da fila de entrada do parachain. No caso de Ethereum também envolve pelo menos manter um banco de dados Merkle-tree dos últimos blocos, mas pode também inclui várias outras estruturas de dados, incluindo Bloom filtros para existência de conta, informações familiares, registro saídas e tabelas de pesquisa reversa para número de bloco. Além de manter as duas cadeias sincronizadas, também deve “pescar” transações mantendo uma fila de transações e aceitando transações devidamente validadas da rede pública. Com a fila e a cadeia, é capaz de criar novos blocos candidatos para os validators escolhidos em cada bloco (cuja identidade é conhecida desde que a cadeia de relés esteja sincronizada) e submetê-los, juntamente com o diversas informações auxiliares, como prova de validade, via a rede peer. Por seu problema, cobra todas as taxas relativas às transações que inclui. Várias economias flutuam em torno disso arranjo. Num mercado fortemente competitivo onde há houver um excedente de coladores, é possível que a transação taxas serão compartilhadas com o parachain validators para incentivar a inclusão de um bloco de agrupamento específico. De forma similar,

POLKADOT: VISÃO PARA UMA ESTRUTURA MULTI-CADEIA HETEROGÊNEA ESBOÇO 1 17 alguns agrupadores podem até aumentar as taxas exigidas que precisam a ser pago para tornar o bloco mais atrativo para validators. Neste caso, um mercado natural deve se formar com transações que pagam taxas mais altas evitando a fila e ter uma inclusão mais rápida na cadeia. 6.8. Rede. Rede em blockchains tradicionais como Ethereum e Bitcoin tem requisitos bastante simples. Todas as transações e bloqueios são transmitidos em uma simples fofoca não direcionada. A sincronização está mais envolvida, especialmente com Ethereum mas na realidade esta lógica estava contida em a estratégia de pares, em vez do protocolo em si, que resolve alguns tipos de mensagens de solicitação e resposta. Embora Ethereum tenha feito progresso nas ofertas atuais de protocolo com o protocolo devp2p, o que permitiu muitos subprotocolos sejam multiplexados em uma única conexão de ponto e, portanto, tenham a mesma sobreposição de ponto, suportam muitos protocolos p2p simultaneamente, a parte Ethereum de o protocolo ainda permaneceu relativamente simples e o p2p protocolo por um tempo permanece inacabado com importantes funcionalidade ausente, como suporte QoS. Infelizmente, o desejo de criar um protocolo “web 3” mais onipresente, em grande parte falhou, com os únicos projetos que o utilizam sendo aqueles explicitamente financiado pela venda coletiva Ethereum. Os requisitos para Polkadot são bastante mais substanciais. Em vez de uma rede totalmente uniforme, Polkadot tem vários tipos de participantes, cada um com requisitos diferentes em relação à composição de seus pares e diversas redes “avenidas” cujos participantes tenderão a conversar sobre dados específicos. Isso significa uma sobreposição de rede substancialmente mais estruturada – e um protocolo que suporta isso – provavelmente será necessário. Além disso, a extensibilidade para facilitar adições futuras, como novos tipos de “cadeia”, pode eles próprios exigem uma nova estrutura de sobreposição. Embora uma discussão aprofundada sobre como a rede protocolo pode parecer estar fora do escopo deste documento, algumas análises de requisitos são razoáveis. Nós podemos dividir aproximadamente os participantes da nossa rede em dois conjuntos (relay-chain, parachains) cada um dos três subconjuntos. Nós podemos também afirmam que cada um dos participantes do parachain são apenas interessados em conversar entre si em vez de participantes de outros parachains: • Participantes da cadeia de retransmissão: • Validadores: P, dividido em subconjuntos P[s] para cada pára-quedas • Fiadores de Disponibilidade: A (podem ser representados por Validadores na forma básica do protocolo) • Clientes de cadeia de retransmissão: M (observe os membros de cada conjunto parachain também tenderá a ser membros de M) • Participantes do Parachain: • Coletores Parachain: C[0], C[1], . . . • Pescadores de paraquedas: F[0], F[1], . . . • Clientes Parachain: S[0], S[1], . . . • Clientes leves Parachain: L[0], L[1], . . . Em geral, nomeamos classes específicas de comunicação tenderá a ocorrer entre membros desses conjuntos: • P | Um <-> P | R: O cheio definir de validators/fiadores deve ser bem conectado para alcançar consenso. • P[s] <-> C[s] | P[s]: Cada validator como membro de um determinado grupo parachain tenderá a fofocar com outros membros, bem como com os compiladores desse parachain para descobrir e compartilhar candidatos de bloco. • A <-> P[s] | C | R: Cada fiador de disponibilidade precisará coletar dados de cadeia cruzada sensíveis ao consenso dados dos validators atribuídos a ele; agrupadores também pode otimizar a chance de consenso sobre seus bloquear anunciando-o aos fiadores de disponibilidade. Assim que os tiverem, os dados serão desembolsados para outro fiador para facilitar o consenso. • P[s] <-> A | P[s']: Parachain validators irá precisa coletar dados de entrada adicionais do conjunto anterior de validators ou dos fiadores de disponibilidade. • F[s] <-> P: Ao reportar, os pescadores podem colocar uma reclamação com qualquer participante. • M <-> M | P | R: Os clientes gerais da cadeia de retransmissão desembolsam dados de validators e fiadores. • S[s] <-> S[s] | P[s] | R: Os clientes Parachain desembolsam dados dos validator/fiadores. • L[s] <-> L[s] | S[s]: Clientes leves Parachain desembolsar dados dos clientes completos. Para garantir um mecanismo de transporte eficiente, um “plano” rede de sobreposição - como o devp2p de Ethereum - onde cada nó não diferencia (não arbitrariamente) a aptidão de seu é improvável que os pares sejam adequados. Um razoavelmente extensível o mecanismo de seleção e descoberta de pares provavelmente precisará a serem incluídos no protocolo, bem como agressivos planejando uma previsão para garantir o tipo certo de pares são “acidentalmente” connectado no momento certo. A estratégia precisa de composição de pares será diferente para cada turma de participantes: para uma escalação adequada multi-cadeias, os alceadores precisarão ser continuamente reconectando-se aos validators devidamente eleitos, ou irá precisa de acordos contínuos com um subconjunto de validators para garantir que eles não sejam desconectados durante a grande maioria das vezes em que são inúteis para isso validator. Os agrupadores também tentarão naturalmente manter um ou conexões mais estáveis no garantidor de disponibilidade definido para garantir a rápida propagação de suas ideias sensíveis ao consenso dados. Os fiadores de disponibilidade terão como objetivo principal manter um conexão estável entre si e com validators (para consenso e dados parachain críticos de consenso aos quais eles atestam), bem como a alguns coladores (para o parachain dados) e alguns pescadores e clientes plenos (para dispersão informações). Os validadores tenderão a procurar outros validators, especialmente aqueles do mesmo subgrupo e qualquer agrupadores que podem fornecer-lhes candidatos a blocos de parachain. Pescadores, bem como redes de revezamento e paraquedas em geral os clientes geralmente terão como objetivo manter uma conexão aberta a um validator ou fiador, mas muitos outros nós semelhantes para si mesmos de outra forma. Os clientes Parachain Light terão como objetivo semelhante estar conectados a um cliente completo do parachain, se não apenas outros clientes leves de parachain. 6.8.1. O problema da rotatividade de pares. Na proposta básica do protocolo, cada um desses subconjuntos se altera constantemente de forma aleatória a cada bloco conforme os validators atribuídos para verificar as transições parachain são eleitas aleatoriamente. Isso pode ser um problema caso nós díspares (não pares) precisem passar dados entre si. É preciso confiar em uma rede de pares bem distribuída e bem conectada para

POLKADOT: VISÃO PARA UMA ESTRUTURA MULTI-CADEIA HETEROGÊNEA ESBOÇO 1 18 garantir que a distância do salto (e, portanto, a latência do pior caso) só cresça com o logaritmo do tamanho da rede (um protocolo semelhante ao Kademlia [13] pode ajudar aqui), ou deve-se introduzir tempos de bloqueio mais longos para permitir que a negociação de conexão necessária ocorra para manter um conjunto de pares que reflete as necessidades atuais de comunicação do nó. Nenhuma dessas são ótimas soluções: longos tempos de bloqueio ser forçado na rede pode torná-la inútil para aplicações e cadeias específicas. Mesmo uma situação perfeitamente justa e rede conectada resultará em desperdício substancial de largura de banda à medida que aumenta devido a nós desinteressados tendo para encaminhar dados inúteis para eles. Embora ambas as direções possam fazer parte da solução, uma otimização razoável para ajudar a minimizar a latência seria ser para restringir a volatilidade desses parachain validator conjuntos, reatribuindo a associação apenas entre séries de blocos (por exemplo, em grupos de 15, que em 4 segundos o tempo de bloqueio significaria alterar as conexões apenas uma vez por minuto) ou rotacionando os membros de forma incremental, por ex. mudando por um membro de cada vez (por exemplo, se houver são 15 validators atribuídos a cada parachain, então, em média, seria um minuto inteiro entre completamente único conjuntos). Ao limitar a quantidade de rotatividade entre pares e garantir que conexões vantajosas entre pares sejam bem feitas em avançar através da previsibilidade parcial do parachain conjuntos, podemos ajudar a garantir que cada nó mantenha um permanentemente seleção fortuita de pares. 6.8.2. Caminho para um protocolo de rede eficaz. Provavelmente o o esforço de desenvolvimento mais eficaz e razoável se concentrará na utilização de um protocolo pré-existente, em vez de continuar o nosso. Existem vários protocolos base peer-to-peer que podemos usar ou aumentar, incluindo o próprio devp2p de Ethereum [22], libp2p [1] do IPFS e GNUnet [4] do GNU. Uma revisão completa desses protocolos e sua relevância para a construção de um rede modular de pares que suporta certas garantias estruturais, orientação dinâmica entre pares e subprotocolos extensíveis está muito além do escopo deste documento, mas será um passo importante na implementação de Polkadot. 7. Aspectos práticos do Protocolo 7.1. Pagamento de transações intercadeias. Embora um ótimo quantidade de liberdade e simplicidade é obtida eliminando a necessidade de uma estrutura holística de contabilidade de recursos de computação como o gás de Ethereum, isso levanta uma questão importante: sem gás, como um parachain evitar que outro parachain o force a fazer cálculos? Embora possamos contar com a fila de entrada pós-transação buffers para evitar que uma cadeia envie spam para outra com dados de transação, não há mecanismo equivalente fornecido pelo protocolo para evitar spam no processamento de transações. Este é um problema deixado para o nível superior. Desde cadeias são livres para anexar semântica arbitrária à entrada dados de postagem de transação, podemos garantir que o cálculo deve ser pago antes de começar. Numa linha semelhante à modelo adotado por Ethereum Serenity, podemos imaginar um contrato de “arrombamento” dentro de um parachain que permite um validator terá pagamento garantido em troca do fornecimento de um determinado volume de recursos de processamento. Esses recursos podem ser medidos em algo como gás, mas também pode ser algum modelo totalmente novo, como tempo de execução subjetivo ou um modelo de taxa fixa semelhante a Bitcoin. Por si só, isso não é tão útil, pois não podemos presumir prontamente que o chamador fora da cadeia tenha disponível para ele qualquer que seja o mecanismo de valor reconhecido pela invasão contrato. No entanto, podemos imaginar um contrato secundário de “ruptura” na cadeia de origem. Os dois contratos juntos formariam uma ponte, reconhecendo-se e fornecendo equivalência de valor. (Estaqueamento-tokens, disponível para cada um, poderia ser usado para liquidar o balanço de pagamentos.) Ligar para outra cadeia desse tipo significaria proxy através desta ponte, que forneceria os meios de negociar a transferência de valor entre cadeias para pagar pelos recursos de computação necessários no parachain de destino. 7.2. Adicional Correntes. Enquanto o adição de um parachain é uma operação relativamente barata, não é gratuita. Mais parachains significa menos validators por parachain e, eventualmente, um número maior de validators, cada um com um título médio reduzido. Embora a questão de um menor custo de coerção para atacar um parachain seja mitigada através de pescadores, o crescente conjunto validator essencialmente força um maior grau de latência devido à mecânica do consenso subjacenteisso. Além disso, cada parachain traz consigo o potencial de lamentar validators com um algoritmo de validação excessivamente pesado. Como tal, haverá algum “preço” que validators e/ou a comunidade interessada extrairá para o adição de um novo parachain. Este mercado de correntes possivelmente veja a adição de: • Cadeias que provavelmente terão pagamento de contribuição líquida zero (em termos de bloqueio ou queima de staking tokens) a serem incluídas (por exemplo, cadeias de consórcio, Doge-chains, cadeias específicas de aplicativos); • cadeias que entregam valor intrínseco à rede através da adição de funcionalidades específicas difíceis para chegar a outro lugar (por exemplo, confidencialidade, escalabilidade interna, vínculos de serviço). Essencialmente, a comunidade de partes interessadas precisará ser incentivado a adicionar cadeias infantis - seja financeiramente ou através do desejo de adicionar cadeias funcionais ao relé. Prevê-se que novas cadeias adicionadas terão um impacto muito curto prazo para remoção, permitindo que novas cadeias sejam ser experimentado sem qualquer risco de comprometer a proposta de valor de médio ou longo prazo. 8. Conclusão Descrevemos uma direção que se pode tomar para criar um protocolo multicadeia escalável e heterogêneo com potencial para ser compatível com versões anteriores de determinados protocolos pré-existentes blockchain redes. Sob tal protocolo, os participantes trabalhar com interesse próprio e esclarecido para criar um sistema global que possa ser estendido de maneira excepcionalmente gratuita e sem o custo típico para os usuários existentes que vem de um design padrão blockchain. Nós demos um esboço da arquitetura que seria necessária, incluindo a natureza dos participantes, seus incentivos econômicos e os processos sob os quais eles devem se envolver. Nós temos identificou um projeto básico e discutiu seus pontos fortes e limitações; portanto, temos outras orientações que pode aliviar essas limitações e fornecer mais terreno para uma solução blockchain totalmente escalonável.POLKADOT: VISÃO PARA UMA ESTRUTURA MULTI-CADEIA HETEROGÊNEA ESBOÇO 1 19 8.1. Material faltante e questões abertas. A bifurcação da rede é sempre uma possibilidade devido a implementações divergentes do protocolo. A recuperação de tal condição excepcional não foi discutida. Dado que a rede terá necessariamente um período de finalização diferente de zero, não deve ser um grande problema recuperar-se da bifurcação da cadeia de retransmissão, no entanto, exigirá uma integração cuidadosa no o protocolo de consenso. O confisco de títulos e, inversamente, a provisão de recompensas não foi profundamente explorado. Atualmente assumimos recompensas são fornecidos na base de que o vencedor leva tudo: isso pode não fornecer o melhor modelo de incentivo para os pescadores. Um processo de compromisso-revelação de curto prazo permitiria a muitos pescadores reivindicar o prêmio dando uma distribuição mais justa de recompensas, no entanto, o processo pode levar a latência adicional no descoberta de mau comportamento. 8.2. Agradecimentos. Muito obrigado a todos revisores que ajudaram a colocar isso em uma forma vagamente forma apresentável. Em particular, Peter Czaban, Bjorn Wagner, Ken Kappler, Robert Habermeier, Vitalik Buterin, Reto Trinkler e Jack Petersson. Obrigado a todos as pessoas que contribuíram com ideias ou o início disso, Marek Kotewicz e Aeron Buchanan merecem menção especial. E obrigado a todos pela ajuda ao longo do caminho. Todos os erros são meus. Partes deste trabalho, incluindo pesquisas iniciais sobre algoritmos de consenso, foi financiado em parte pelos britânicos Governo no âmbito do programa Innovate UK.