Polkadot: Visão para uma estrutura heterogênea de múltiplas cadeias

Polkadot: Vision for a Heterogeneous Multi-Chain Framework

द्वारा Gavin Wood · 2016

🇺🇸 English (मूल)

🇧🇷 Português (अनुवाद)

Abstract

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 DR. GAVIN WOOD FOUNDER, ETHEREUM & PARITY [email protected] Abstract. Present-day blockchain architectures all suﬀer from a number of issues not least practical means of extensibility and scalability. We believe this stems from tying two very important parts of the consensus architecture, namely canonicality and validity, too closely together. This paper introduces an architecture, the heterogeneous multi-chain, which fundamentally sets the two apart. In compartmentalising these two parts, and by keeping the overall functionality provided to an absolute minimum of security and transport, we introduce practical means of core extensibility in situ. Scalability is addressed through a divide-and-conquer approach to these two functions, scaling out of its bonded core through the incentivisation of untrusted public nodes. The heterogeneous nature of this architecture enables many highly divergent types of consensus systems interoperating in a trustless, fully decentralised “federation”, allowing open and closed networks to have trust-free access to each other. We put forward a means of providing backwards compatibility with one or more pre-existing networks such as Ethereum. We believe that such a system provides a useful base-level component in the overall search for a practically implementable system capable of achieving global-commerce levels of scalability and privacy. 1. Preface This is intended to be a technical “vision” summary of one possible direction that may be taken in further developing the blockchain paradigm together with some rationale as to why this direction is sensible. It lays out in as much detail as is possible at this stage of development a system which may give a concrete improvement on a number of aspects of blockchain technology. It is not intended to be a speciﬁcation, formal or otherwise. It is not intended to be comprehensive nor to be a ﬁnal design. It is not intended to cover non-core aspects of the framework such as APIs, bindings, languages and usage. This is notably experimental; where parameters are speciﬁed, they are likely to change. Mechanisms will be added, reﬁned and removed in response to community ideas and critiques. Large portions of this paper will likely be revised as experimental evidence and prototyping gives us information about what will work and what not. This document includes a core description of the protocol together with ideas for directions that may be taken to improve various aspects. It is envisioned that the core description will be used as the starting point for an initial series of proofs-of-concept. A ﬁnal “version 1.0” would be based around this reﬁned protocol together with the additional ideas that become proven and are determined to be required for the project to reach its goals. 1.1. History. • 09/10/2016: 0.1.0-proof1 • 20/10/2016: 0.1.0-proof2 • 01/11/2016: 0.1.0-proof3 • 10/11/2016: 0.1.0 2. Introduction Blockchains have demonstrated great promise of utility over several ﬁelds including “Internet of Things” (IoT), ﬁnance, governance, identity management, webdecentralisation and asset-tracking. However, despite the technological promise and grand talk, we have yet to see signiﬁcant real-world deployment of present technology. We believe that this is down to ﬁve key failures of present technology stacks: Scalability: How much resources are spent globally on processing, bandwidth and storage for the system to process a single transaction and how many transactions can be reasonably processed under peak conditions? Isolatability: Can the divergent needs of multiple parties and applications be addressed to a nearoptimal degree under the same framework? Developability: How well do the tools work? Do the APIs address the developers’ needs? Are educational materials available? Are the right integrations there? Governance: Can the network remain ﬂexible to evolve and adapt over time? Can decisions be made with suﬃcient inclusivity, legitimacy and transparency to provide eﬀective leadership of a decentralised system? Applicability: Does the technology actually address a burning need on its own? Is other “middleware” required in order to bridge the gap to actual applications? In the present work, we aim to address the ﬁrst two issues: scalability and isolatability. That said, we believe the Polkadot framework can provide meaningful improvements in each of these classes of problems. Modern, eﬃcient blockchain implementations such as the Parity Ethereum client [17] can process in excess of 3,000 transactions per second when running on performant consumer hardware. However, current real-world blockchain networks are practically limited to around 30 transactions per second. This limitation mainly originates from the fact that the current synchronous consensus mechanisms require wide timing margins of safety on the expected processing time, which is exacerbated by the 1

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

Introduction

Blockchains have demonstrated great promise of utility over several ﬁelds including “Internet of Things” (IoT), ﬁnance, governance, identity management, webdecentralisation and asset-tracking. However, despite the technological promise and grand talk, we have yet to see signiﬁcant real-world deployment of present technology. We believe that this is down to ﬁve key failures of present technology stacks: Scalability: How much resources are spent globally on processing, bandwidth and storage for the system to process a single transaction and how many transactions can be reasonably processed under peak conditions? Isolatability: Can the divergent needs of multiple parties and applications be addressed to a nearoptimal degree under the same framework? Developability: How well do the tools work? Do the APIs address the developers’ needs? Are educational materials available? Are the right integrations there? Governance: Can the network remain ﬂexible to evolve and adapt over time? Can decisions be made with suﬃcient inclusivity, legitimacy and transparency to provide eﬀective leadership of a decentralised system? Applicability: Does the technology actually address a burning need on its own? Is other “middleware” required in order to bridge the gap to actual applications? In the present work, we aim to address the ﬁrst two issues: scalability and isolatability. That said, we believe the Polkadot framework can provide meaningful improvements in each of these classes of problems. Modern, eﬃcient blockchain implementations such as the Parity Ethereum client [17] can process in excess of 3,000 transactions per second when running on performant consumer hardware. However, current real-world blockchain networks are practically limited to around 30 transactions per second. This limitation mainly originates from the fact that the current synchronous consensus mechanisms require wide timing margins of safety on the expected processing time, which is exacerbated by the

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 2 desire to support slower implementations. This is due to the underlying consensus architecture: the state transition mechanism, or the means by which parties collate and execute transactions, has its logic fundamentally tied into the consensus “canonicalisation” mechanism, or the means by which parties agree upon one of a number of possible, valid, histories. This applies equally to both proof-of-work (PoW) systems such as Bitcoin [15] and Ethereum [5,23] and proofof-stake (PoS) systems such as NXT [8] and Bitshares [12]: all ultimately suﬀer from the same handicap. It is a simple strategy that helped make blockchains a success. However, by tightly coupling these two mechanisms into a single unit of the protocol, we also bundle together multiple diﬀerent actors and applications with diﬀerent risk proﬁles, diﬀerent scalability requirements and diﬀerent privacy needs. One size does not ﬁt all. Too often it is the case that in a desire for broad appeal, a network adopts a degree of conservatism which results in a lowest-common-denominator optimally serving few and ultimately leading to a failing in the ability to innovate, perform and adapt, sometimes dramatically so. Some systems such as e.g. Factom [21] drop the statetransition mechanism altogether. However, much of the utility that we desire requires the ability to transition state according to a shared state-machine. Dropping it solves an alternative problem; it does not provide an alternative solution. It seems clear, therefore, that one reasonable direction to explore as a route to a scalable decentralised compute platform is to decouple the consensus architecture from the state-transition mechanism. And, perhaps unsurprisingly, this is the strategy that Polkadot adopts as a solution to scalability. 2.1. Protocol, Implementation and Network. Like Bitcoin and Ethereum, Polkadot refers at once to a network protocol and the (hitherto presupposed) primary public network that runs this protocol. Polkadot is intended to be a free and open project, the protocol speciﬁcation being under a Creative Commons license and the code being placed under a FLOSS license. The project is developed in an open manner and accepts contributions where ever they are useful. A system of RFCs, not unlike the Python Enhancement Proposals, will allow a means of publicly collaborating over protocol changes and upgrades. Our initial implementation of the Polkadot protocol will be known as the Parity Polkadot Platform and will include a full protocol implementation together with API bindings. Like other Parity blockchain implementations, PPP is designed to be a general-purpose blockchain technology stack, neither uniquely for a public network nor for private/consortium operation. The development of it thus far has been funded by several parties including through a grant from the British government. This paper nonetheless describes Polkadot under the context of a public network. The functionality we envision in a public network is a superset of that required in alternative (e.g. private and/or consortium) settings. Furthermore, in this context, the full scope of Polkadot can be more clearly described and discussed. This does mean the reader should be aware that certain mechanisms may be described (for example interoperation with other public networks) which are not directly relevant to Polkadot when deployed under non-public (“permissioned”) situations. 2.2. Previous work. Decoupling the underlying consensus from the state-transition has been informally proposed in private for at least two years—Max Kaye was a proponent of such a strategy during the very early days of Ethereum. A more complex scalable solution known as Chain ﬁbers, dating back to June 2014 and ﬁrst published later that year1, made the case for a single relay-chain and multiple homogeneous chains providing a transparent interchain execution mechanism. Decoherence was paid for through transaction latency—transactions requiring the coordination of disparate portions of the system would take longer to process. Polkadot takes much of its architecture from that and the follow-up conversations with various people, though it diﬀers greatly in much of its design and provisions. While there are no systems comparable to Polkadot actually in production, several systems of some relevance have been proposed, though few in any substantial level of detail. These proposals can be broken down into systems which drop or reduce the notion of a globally coherent state machine, those which attempt to provide a globally coherent singleton machine through homogeneous shards and those which target only heterogeneity. 2.2.1. Systems without Global State. Factom [21] is a system that demonstrates canonicality without the according validity, eﬀectively allowing the chronicling of data. Because of the avoidance of global state and the diﬃculties with scaling which this brings, it can be considered a scalable solution. However, as mentioned previously, the set of problems it solves is strictly and substantially smaller. Tangle [18] is a novel approach to consensus systems. Rather than arranging transactions into blocks and forming consensus over a strictly linked list to give a globally canonical ordering of state-changes, it largely abandons the idea of a heavily structured ordering and instead pushes for a directed acyclic graph of dependent transactions with later items helping canonicalise earlier items through explicit referencing. For arbitrary state-changes, this dependency graph would quickly become intractable, however for the much simpler UTXO model2 this becomes quite reasonable. Because the system is only loosely coherent and transactions are generally independent of each other, a large amount of global parallelism becomes quite natural. Using the UTXO model does have the eﬀect of limiting Tangle to a purely value-transfer “currency” system rather than anything more general or extensible. Furthermore without the hard global coherency, interaction with other systems—which tend to need an absolute degree knowledge over the system state—becomes impractical. 1https://github.com/ethereum/wiki/wiki/Chain-Fibers-Redux 2unspent transaction output, the model that Bitcoin uses whereby the state is eﬀectively the set of address associated with some value; transactions collate such addresses and reform them into a new set of addresses whose sum total is equivalent

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 3 2.2.2. Heterogeneous Chain Systems. Side-chains [3] is a proposed addition to the Bitcoin protocol which would allow trustless interaction between the main Bitcoin chain and additional side-chains. There is no provision for any degree of ‘rich’ interaction between side-chains: the interaction would be limited to allowing side-chains to be custodians of each other’s assets, eﬀecting—in the local jargon—a two-way peg 3. The end vision is for a framework where the Bitcoin currency could be provided with additional, if peripheral, functionality through pegging it onto some other chains with more exotic state transition systems than the Bitcoin protocol allows. In this sense, side-chains addresses extensibility rather than scalability. Indeed, there is fundamentally no provision for the validity of side-chains; tokens from one chain (e.g. Bitcoin) held on behalf of a side-chain are secured only by the side-chain’s ability to incentivise miners to canonicalise valid transitions. The security of the Bitcoin network cannot easily be transitioned to work on behalf of other blockchains. Furthermore, a protocol for ensuring Bitcoin miners merge-mine (that is duplicate their canonicalisation power onto that of the side-chain) and, more importantly, validate the side-chain’s transitions is outside the scope of this proposal. Cosmos [10] is a proposed multi-chain system in the same vein as side-chains, swapping the Nakamoto PoW consensus method for Jae Kwon’s Tendermint algorithm. Essentially, it describes multiple chains (operating in zones) each using individual instances of Tendermint, together with a means for trust-free communication via a master hub chain. This interchain communication is limited to the transfer of digital assets (“speciﬁcally about tokens”) rather than arbitrary information, however such interchain communication does have a return path for data, e.g. to report to the sender on the status of the transfer. Validator sets for the zoned chains, and in particular the means of incentivising them, are, like side-chains, left as an unsolved problem. The general assumption is that each zoned chain will itself hold a token of value whose inﬂation is used to pay for validators. Still in the early stages of design, at present the proposal lacks comprehensive details over the economic means of achieving the scalable certainty over global validity. However, the loose coherence required between the zones and the hub will allow for additional ﬂexibility over the parameters of the zoned chains compared to that of a system enforcing stronger coherence. 2.2.3. Casper. As yet no comprehensive review or sideby-side comparison between Casper [6] and Polkadot have been made, though one can make a fairly sweeping (and accordingly inaccurate) characterisation of the two. Casper is a reimagining of how a PoS consensus algorithm could be based around participants betting on which fork would ultimately become canonical. Substantial consideration was given to ensuring that it be robust to network forks, even when prolonged, and have some additional degree of scalability on top of the basic Ethereum model. As such, Casper to date has tended to be a substantially more complex protocol than Polkadot and its forebears, and a substantial deviation from the basic blockchain format. It remains unseen as to how Casper will iterate in the future and what it will look like should it ﬁnally be deployed. While Casper and Polkadot both represent interesting new protocols and, in some sense, augmentations of Ethereum, there are substantial diﬀerences between their ultimate goals and paths to deployment. Casper is an Ethereum Foundation-centered project originally designed to be a PoS alteration to the protocol with no desire to create a fundamentally scalable blockchain. Crucially, it is designed to be a hard-fork, rather than anything more expansive and thus all Ethereum clients and users would be required to upgrade or remain on a fork of uncertain adoption. As such, deployment is made substantially more difﬁcult as is inherent in a decentralised project where tight coordination is necessary. Polkadot diﬀers in several ways; ﬁrst and foremost, Polkadot is designed to be a fully extensible and scalable blockchain development, deployment and interaction test bed. It is built to be a largely future-proof harness able to assimilate new blockchain technology as it becomes available without over-complicated decentralised coordination or hard forks. We already envision several use cases such as encrypted consortium chains and high-frequency chains with very low block times that are unrealistic to do in any future version of Ethereum currently envisioned. Finally, the coupling between it and Ethereum is extremely loose; no action on the part of Ethereum is necessary to enable trustless transaction forwarding between the two networks. In short, while Casper/Ethereum 2.0 and Polkadot share some ﬂeeting similarities we believe their end goal is substantially diﬀerent and that rather than competing, the two protocols are likely to ultimately co-exist under a mutually beneﬁcial relationship for the foreseeable future.

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.

Summary

Polkadot is a scalable heterogeneous multi-chain. This means that unlike previous blockchain implementations which have focused on providing a single chain of varying degrees of generality over potential applications, Polkadot itself is designed to provide no inherent application functionality at all. Rather, Polkadot provides the bedrock “relay-chain” upon which a large number of validatable, globally-coherent dynamic data-structures may be hosted side-by-side. We call these data-structures “parallelised” chains or parachains, though there is no speciﬁc need for them to be blockchain in nature. In other words, Polkadot may be considered equivalent to a set of independent chains (e.g. the set containing Ethereum, Ethereum Classic, Namecoin and Bitcoin) except for two very important points: • Pooled security; • trust-free interchain transactability. These points are why we consider Polkadot to be “scalable”. In principle, a problem to be deployed on Polkadot may be substantially parallelised—scaled out—over a large number of parachains. Since all aspects of each parachain may be conducted in parallel by a diﬀerent segment of the Polkadot network, the system has some ability to scale. Polkadot provides a rather bare-bones piece of 3as opposed to a one-way peg which is essentially the action of destroying tokens in one chain to create tokens in another without the mechanism to do the converse in order to recover the original tokens

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 4 infrastructure leaving much of the complexity to be addressed at the middleware level. This is a conscious decision intended to reduce development risk, enabling the requisite software to be developed within a short time span and with a good level of conﬁdence over its security and robustness. 3.1. The Philosophy of Polkadot. Polkadot should provide an absolute rock-solid foundation on which to build the next wave of consensus systems, right through the risk spectrum from production-capable mature designs to nascent ideas. By providing strong guarantees over security, isolation and communication, Polkadot can allow parachains to select from a range of properties themselves. Indeed, we foresee various experimental blockchains pushing the properties of what could be considered sensible today. We see conservative, high-value chains similar to Bitcoin or Z-cash [20] co-existing alongside lower-value “theme-chains” (such marketing, so fun) and test-nets with zero or near-zero fees. We see fully-encrypted, “dark”, consortium chains operating alongside—and even providing services to—highly functional and open chains such as those like Ethereum. We see experimental new VM-based chains such as a subjective time-charged wasm chain being used as a means of outsourcing diﬃcult compute problems from a more mature Ethereum-like chain or a more restricted Bitcoin-like chain. To manage chain upgrades, Polkadot will inherently support some sort of governance structure, likely based on existing stable political systems and having a bicameral aspect similar to the Yellow Paper Council [24]. As the ultimate authority, the underlying stakable token holders would have “referendum” control. To reﬂect the users’ need for development but the developers’ need for legitimacy, we expect a reasonable direction would be to form the two chambers from a “user” committee (made up of bonded validators) and a “technical” committee made up of major client developers and ecosystem players. The body of token holders would maintain the ultimate legitimacy and form a supermajority to augment, reparameterise, replace or dissolve this structure, something we don’t doubt the eventual need for: in the words of Twain “Governments and diapers must be changed often, and for the same reason”. Whereas reparameterisation is typically trivial to arrange within a larger consensus mechanism, more qualitative changes such as replacement and augmentation would likely need to be either non-automated “soft-decrees” (e.g. through the canonicalisation of a block number and the hash of a document formally specifying the new protocol) or necessitate the core consensus mechanism to contain a suﬃciently rich language to describe any aspect of itself which may need to change. The latter is an eventual aim, however, the former more likely to be chosen in order to facilitate a reasonable development timeline. Polkadot’s primary tenets and the rules within which we evaluate all design decisions are: Minimal: Polkadot should have as little functionality as possible. Simple: no additional complexity should be present in the base protocol than can reasonably be oﬄoaded into middleware, placed through a parachain or introduced in a later optimisation. General: no unnecessary requirement, constraint or limitation should be placed on parachains; Polkadot should be a test bed for consensus system development which can be optimised through making the model into which extensions ﬁt as abstract as possible. Robust: Polkadot should provide a fundamentally stable base-layer. In addition to economic soundness, this also means decentralising to minimise the vectors for high-reward attacks.

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.

Participation in Polkadot

There are four basic roles in the upkeep of an Polkadot network: collator, ﬁsherman, nominator and validator. In one possible implementation of Polkadot, the latter role may actually be broken down into two roles: basic validator and availability guarantor; this is discussed in section 6.5.3. Collator Fisherman Validators (this group) Validators (other groups) approves becomes monitors reports bad behaviour to provides block candidates for Nominator Figure 1. The interaction between the four roles of Polkadot. 4.1. Validators. A validator is the highest charge and helps seal new blocks on the Polkadot network. The validator’s role is contingent upon a suﬃciently high bond being deposited, though we allow other bonded parties to nominate one or more validators to act for them and as such some portion of the validator’s bond may not necessarily be owned by the validator itself but rather by these nominators. A validator must run a relay-chain client implementation with high availability and bandwidth. At each block the node must be ready to accept the role of ratifying a new block on a nominated parachain. This process involves receiving, validating and republishing candidate blocks. The nomination is deterministic but virtually unpredictable much in advance. Since the validator cannot reasonably be expected to maintain a fully-synchronised database of all parachains, it is expected that the validator will nominate the task of devising a suggested new parachain block to a third-party, known as a collator. Once all new parachain blocks have been properly ratiﬁed by their appointed validator subgroups, validators must then ratify the relay-chain block itself. This involves updating the state of the transaction queues (essentially moving data from a parachain’s output queue to another parachain’s input queue), processing the transactions of the ratiﬁed relay-chain transaction set and ratifying the ﬁnal block, including the ﬁnal parachain changes.

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 5 A validator not fulﬁlling their duty to ﬁnd consensus under the rules of our chosen consensus algorithm is punished. For initial, unintentional failures, this is through withholding the validator’s reward. Repeated failures result in the reduction of their security bond (through burning). Provably malicious actions such as double-signing or conspiring to provide an invalid block result in the loss of the entire bond (which is partially burnt but mostly given to the informant and the honest actors). In some sense, validators are similar to the mining pools of current PoW blockchains. 4.2. Nominators. A nominator is a stake-holding party who contributes to the security bond of a validator. They have no additional role except to place risk capital and as such to signal that they trust a particular validator (or set thereof) to act responsibly in their maintenance of the network. They receive a pro-rata increase or reduction in their deposit according to the bond’s growth to which they contribute. Together with collators, next, nominators are in some sense similar to the miners of the present-day PoW networks. 4.3. Collators. Transaction collators (collators for short) are parties who assist validators in producing valid parachain blocks. They maintain a “full-node” for a particular parachain; meaning that they retain all necessary information to be able to author new blocks and execute transactions in much the same way as miners do on current PoW blockchains. Under normal circumstances, they will collate and execute transactions to create an unsealed block, and provide it, together with a zero-knowledge proof, to one or more validators presently responsible for proposing a parachain block. The precise nature of the relationship between collators, nominators and validators will likely change over time. Initially, we expect collators to work very closely with validators, since there will be only a few (perhaps only one) parachain(s) with little transaction volume. The initial client implementation will include RPCs to allow a parachain collator node to unconditionally supply a (relaychain) validator node with a provably valid parachain block. As the cost of maintaining a synced version of all such parachains increases, we expect to see additional infrastructure in place which will help separate out the duties to independent, economically-motivated, parties. Eventually, we expect to see collator pools who vie to collect the most transaction fees. Such collators may become contracted to serve particular validators over a period of time for an on-going share in the reward proceeds. Alternatively, “freelance” collators may simply create a market oﬀering valid parachain blocks in return for a competitive share of the reward payable immediately. Similarly, decentralised nominator pools would allow multiple bonded participants to coordinate and share the duty of a validator. This ability to pool ensures open participation leading to a more decentralised system. 4.4. Fishermen. Unlike the other two active parties, ﬁshermen are not directly related to the block-authoring process. Rather they are independent “bounty hunters” motivated by a large one-oﬀreward. Precisely due to the existence of ﬁshermen, we expect events of misbehaviour to happen seldom, and when they do only due to the bonded party being careless with secret key security, rather than through malicious intent. The name comes from the expected frequency of reward, the minimal requirements to take part and the eventual reward size. Fishermen get their reward through a timely proof that at least one bonded party acted illegally. Illegal actions include signing two blocks each with the same ratiﬁed parent or, in the case of parachains, helping ratify an invalid block. To prevent over-rewarding or the compromise and illicit use of a session’s secret key, the base reward for providing a single validator’s illegally signed message is minimal. This reward increases asymptotically as more corroborating illegal signatures from other validators are provided implying a genuine attack. The asymptote is set at 66% following our base security assertion that at least two-thirds of the validators act benevolently. Fishermen are somewhat similar to “full nodes” in present-day blockchain systems that the resources needed are relatively small and the commitment of stable uptime and bandwidth is not necessary. Fishermen diﬀer in so much as they must post a small bond. This bond prevents sybil attacks from wasting validators’ time and compute resources. It is immediately withdrawable, probably no more than the equivalent of a few dollars and may lead to reaping a hefty reward from spotting a misbehaving validator.

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.

Design Overview

This section is intended to give a brief overview of the system as a whole. A more thorough exploration of the system is given in the section following it. 5.1. Consensus. On the relay-chain, Polkadot achieves low-level consensus over a set of mutually agreed valid blocks through a modern asynchronous Byzantine faulttolerant (BFT) algorithm. The algorithm will be inspired by the simple Tendermint [11] and the substantially more involved HoneyBadgerBFT [14]. The latter provides an eﬃcient and fault-tolerant consensus over an arbitrarily defective network infrastructure, given a set of mostly benign authorities or validators. For a proof-of-authority (PoA) style network, this alone would be suﬃcient, however Polkadot is imagined to be also deployable as a network in a fully open and public situation without any particular organisation or trusted authority required to maintain it. As such we need a means of determining a set of validators and incentivising them to be honest. For this we utilise PoS based selection criteria. 5.2. Proving the Stake. We assume that the network will have some means of measuring how much “stake” any particular account has. For ease of comparison to pre-existing systems, we will call the unit of measurement “tokens”. Unfortunately the term is less than ideal for a number of reasons, not least that being simply a scalar value associated with an account, there is no notion of individuality. We imagine validators be elected, infrequently (at most once per day but perhaps as seldom as once per quarter), through a Nominated Proof-of-Stake (NPoS) scheme. Incentivisation can happen through a pro-rata allocation of

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 6 Relay chain Validator swarm (each coloured by its designated parachain) Transaction (submitted by external actor) Parachain bridge Virtual parachain (e.g. Ethereum) Parachain Parachain queues and I/O Propagated transactions Block candidate submission 2nd order Relay-chain Parachain community Account Inbound transaction Outbound transaction Interchain transactions (managed by validators) Collator Propagated block Fisherman Figure 2. A summary schematic of the Polkadot system. This shows collators collecting and propagating user-transactions, as well as propagating block candidates to ﬁshermen and validators. It also shows how an account can post a transaction which is carried out of its parachain, via the relay-chain and on into another parachain where it can be interpreted as a transaction to an account there. funds coming from a token base expansion (up to 100% per year, though more likely around 10%) together with any transaction fees collected. While monetary base expansion typically leads to inﬂation, since all token owners would have a fair opportunity at participation, no tokenholder would need to suﬀer a reduction in value of their holdings over time provided they were happy to take a role in the consensus mechanism. A particular proportion of tokens would be targeted for the staking process; the eﬀective token base expansion would be adjusted through a market-based mechanism to reach this target. Validators are bonded heavily by their stakes; exiting validators’ bonds remain in place long after the validators’ duties cease (perhaps around 3 months). This long bond-liquidation period allows future misbehaviour to be punished up until the periodic checkpointing of the chain. Misbehaviour results in punishment, such as reduction of reward or, in cases which intentionally compromise the network’s integrity, the validator losing some or all of its stake to other validators, informants or the stakeholders as a whole (through burning). For example, a validator who attempts to ratify both branches of a fork (sometimes known as a “short-range” attack) may be identiﬁed and punished in the latter way. Long-range “nothing-at-stake” attacks4 are circumvented through a simple “checkpoint” latch which prevents a dangerous chain-reorganisation of more than a particular chain-depth. To ensure newly-syncing clients are not able to be fooled onto the wrong chain, regular “hard forks” will occur (of at most the same period of the validators’ bond liquidation) that hard-code recent checkpoint block hashes into clients. This plays well with a further footprint-reducing measure of “ﬁnite chain length” or periodic reseting of the genesis-block. 5.3. Parachains and Collators. Each parachain gets similar security aﬀordances to the relay-chain: the parachains’ headers are sealed within the relay-chain block ensuring no reorganisation, or “double-spending”, is possible following conﬁrmation. This is a similar security guarantee to that oﬀered by Bitcoin’s side-chains and mergemining. Polkadot, however, also provides strong guarantees that the parachains’ state transitions are valid. This happens through the set of validators being cryptographically randomly segmented into subsets; one subset per parachain, the subsets potentially diﬀering per block. This setup generally implies that parachains’ block times will be at least as long as that of the relay-chain. The speciﬁc means of determining the partitioning is outside the scope 4Such an attack is where the adversary forges an entirely new chain of history from the genesis block onwards. Through controlling a relatively insigniﬁcant portion of stake at the oﬀset, they are able to incrementally increase their portion of the stake relative to all other stakeholders as they are the only active participants in their alternative history. Since no intrinsic physical limitation exists on the creation of blocks (unlike PoW where quite real computational energy must be spent), they are able to craft a chain longer than the real chain in a relatively short timespan and potentially make it the longest and best, taking over the canonical state of the network.

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 7 of this document but would likely be based either around a commit-reveal framework similar to the RanDAO [19] or use data combined from previous blocks of each parachain under a cryptographically secure hash. Such subsets of validators are required to provide a parachain block candidate which is guaranteed valid (on pain of bond conﬁscation). Validity revolves around two important points; ﬁrstly that it is intrinsically valid—that all state transitions were executed faithfully and that all external data referenced (i.e. transactions) is valid for inclusion. Secondly, that any data which is extrinsic to its candidate, such as those external transactions, has suﬃciently high availability so that participants are able to download it and execute the block manually.5 Validators may provide only a “null” block containing no external “transactions” data, but may run the risk of getting a reduced reward if they do. They work alongside a parachain gossip protocol with collators—individuals who collate transactions into blocks and provide a noninteractive, zero-knowledge proof that the block constitutes a valid child of its parent (and taking any transaction fees for their trouble). It is left to parachain protocols to specify their own means of spam-prevention: there is no fundamental notion of “compute-resource metering” or “transaction fee” imposed by the relay-chain. There is also no direct enforcement on this by the relay-chain protocol (though it is unlikely that the stakeholders would choose to adopt a parachain which didn’t provide a decent mechanism). This is an explicit nod to the possibility of chains unlike Ethereum, e.g. a Bitcoin-like chain which has a much simpler fee model or some other, yet-to-be-proposed spamprevention model. Polkadot’s relay-chain itself will probably exist as an Ethereum-like accounts and state chain, possibly an EVMderivative. Since the relay-chain nodes will be required to do substantial other processing, transaction throughput will be minimised partly through large transaction fees and, should our research models require, a block size limit. 5.4. Interchain Communication. The critical ﬁnal ingredient of Polkadot is interchain communication. Since parachains can have some sort of information channel between them, we allow ourselves to consider Polkadot a scalable multi-chain. In the case of Polkadot, the communication is as simple as can be: transactions executing in a parachain are (according to the logic of that chain) able to eﬀect the dispatch of a transaction into a second parachain or, potentially, the relay-chain. Like external transactions on production blockchains, they are fully asynchronous and there is no intrinsic ability for them to return any kind of information back to its origin. Destination: gets data from prior block’s validators. Account receives post: entry removed from ingress Merkle tree Account sends post: entry placed in egress Merkle tree for destination parachain egress Source: shares data with next block’s validators proof-of-post stored in parachain egress Merkle tree routed reference placed in destination parachain’s ingress Merkle tree ingress Figure 3. A basic schematic showing the main parts of routing for posted transactions (”posts”). To ensure minimal implementation complexity, minimal risk and minimal straight-jacketing of future parachain architectures, these interchain transactions are eﬀectively indistinguishable from standard externallysigned transactions. The transaction has an origin segment, providing the ability to identify a parachain, and an address which may be of arbitrary size. Unlike common current systems such as Bitcoin and Ethereum, interchain transactions do not come with any kind of “payment” of fee associated; any such payment must be managed through negotiation logic on the source and destination parachains. A system such as that proposed for Ethereum’s Serenity release [7] would be a simple means of managing such a cross-chain resource payment, though we assume others may come to the fore in due course. Interchain transactions are resolved using a simple queuing mechanism based around a Merkle tree to ensure ﬁdelity. It is the task of the relay-chain maintainers to move transactions on the output queue of one parachain into the input queue of the destination parachain. The passed transactions get referenced on the relay-chain, however are not relay-chain transactions themselves. To prevent a parachain from spamming another parachain with transactions, for a transaction to be sent, it is required that the destination’s input queue be not too large at the time of the end of the previous block. If the input queue is too large after block processing, then it is considered “saturated” and no transactions may be routed to it within subsequent blocks until reduced back below the limit. These queues are administered on the relay-chain allowing parachains to determine each other’s saturation status; this way a failed attempt to post a transaction to a stalled destination may be reported synchronously. (Though since no return path exists, if a secondary transaction failed for that reason, it could not be reported back to the original caller and some other means of recovery would have to take place.) 5.5. Polkadot and Ethereum. Due to Ethereum’s Turing completeness, we expect there is ample opportunity for Polkadot and Ethereum to be interoperable with each other, at least within some easily deducible security bounds. In short, we envision that transactions from Polkadot can be signed by validators and then fed into 5Such a task might be shared between validators or could become the designate task of a set of heavily bonded validators known as availability guarantors.

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 8 Ethereum where they can be interpreted and enacted by a transaction-forwarding contract. In the other direction, we foresee the usage of specially formatted logs (events) coming from a “break-out contract” to allow a swift veriﬁcation that a particular message should be forwarded. 5.5.1. Polkadot to Ethereum. Through the choice of a BFT consensus mechanism with validators formed from a set of stakeholders determined through an approval voting mechanism, we are able to get a secure consensus with an infrequently changing and modest number of validators. In a system with a total of 144 validators, a block time of 4 seconds and a 900-block ﬁnality (allowing for malicious behaviour such as double-votes to be reported, punished and repaired), the validity of a block can reasonably be considered proven through as little as 97 signatures (twothirds of 144 plus one) and a following 60-minute veriﬁcation period where no challenges are deposited. Ethereum is able to host a “break-in contract” which can maintain the 144 signatories and be controlled by them. Since elliptic curve digital signature (ECDSA) recovery takes only 3,000 gas under the EVM, and since we would likely only want the validation to happen on a super-majority of validators (rather than full unanimity), the base cost of Ethereum conﬁrming that an instruction was properly validated as coming from the Polkadot network would be no more than 300,000 gas—a mere 6% of the total block gas limit at 5.5M. Increasing the number of validators (as would be necessary for dealing with dozens of chains) inevitably increases this cost, however it is broadly expected for Ethereum’s transaction bandwidth to grow over time as the technology matures and infrastructure improves. Together with the fact that not all validators need to be involved (e.g. only the highest staked validators may be called upon for such a task) the limits of this mechanism extend reasonably well. Assuming a daily rotation of such validators (which is fairly conservative—weekly or even monthly may be acceptable), then the cost to the network of maintaining this Ethereum-forwarding bridge would be around 540,000 gas per day or, at present gas prices, $45 per year. A basic transaction forwarded alone over the bridge would cost around $0.11; additional contract computation would cost more, of course. By buﬀering and bundling transactions together, the break-in authorisation costs can easily be shared, reducing the cost per transaction substantially; if 20 transactions were required before forwarding, then the cost for forwarding a basic transaction would fall to around $0.01. One interesting, and cheaper, alternative to this multisignature contract model would be to use threshold signatures in order to achieve the multi-lateral ownership semantics. While threshold signature schemes for ECDSA are computationally expensive, those for other schemes such as Schnorr signatures are very reasonable. Ethereum plans to introduce primitives which would make such schemes cheap to use in the upcoming Metropolis hardfork. If such a means were able to be utilised, the gas costs for forwarding a Polkadot transaction into the Ethereum network would be dramatically reduced to a near zero overhead over and above the basic costs for validating the signature and executing the underlying transaction. In this model, Polkadot’s validator nodes would have to do little other than sign messages. To get the transactions actually routed onto the Ethereum network, we assume either validators themselves would also reside on the Ethereum network or, more likely, that small bounties be oﬀered to the ﬁrst actor who forwards the message on to the network (the bounty could trivially be paid to the transaction originator). 5.5.2. Ethereum to Polkadot. Getting transactions to be forwarded from Ethereum to Polkadot uses the simple notion of logs. When an Ethereum contract wishes to dispatch a transaction to a particular parachain of Polkadot, it need simply call into a special “break-out contract”. The break-out contract would take any payment that may be required and issue a logging instruction so that its existence may be proven through a Merkle proof and an assertion that the corresponding block’s header is valid and canonical. Of the latter two conditions, validity is perhaps the most straightforward to prove. In principle, the only requirement is for each Polkadot node needing the proof (i.e. appointed validator nodes) to be running a fully synchronised instance of a standard Ethereum node. Unfortunately, this is itself a rather heavy dependency. A more lightweight method would be to use a simple proof that the header was evaluated correctly through supplying only the part of Ethereum’s state trie needed to properly execute the transactions in the block and check that the logs (contained in the block receipt) are valid. Such “SPV-like”6 proofs may yet require a substantial amount of information; conveniently, they would typically not be needed at all: a bond system inside Polkadot would allow bonded third-parties to submit headers at the risk of losing their bond should some other third-party (such as a “ﬁsherman”, see 6.2.3) provide a proof that the header is invalid (speciﬁcally that the state root or receipt roots were impostors). On a non-ﬁnalising PoW network like Ethereum, the canonicality is impossible to proof conclusively. To address this, applications that attempt to rely on any kind of chain-dependent cause-eﬀect wait for a number of “conﬁrmations”, or until the dependent transaction is at some particular depth within the chain. On Ethereum, this depth varies from 1 block for the least valuable transactions with no known network issues to 1200 blocks as was the case during the initial Frontier release for exchanges. On the stable “Homestead” network, this ﬁgure sits at 120 blocks for most exchanges, and we would likely take a similar parameter. So we can imagine our Polkadot-side Ethereuminterface to have some simple functions: to be able to accept a new header from the Ethereum network and validate the PoW, to be able to accept some proof that a particular log was emitted by the Ethereum-side breakout contract for a header of suﬃcient depth (and forward the corresponding message within Polkadot) and ﬁnally to be able to accept proofs that a previously accepted but not-yet-enacted header contains an invalid receipt root. To actually get the Ethereum header data itself (and any SPV proofs or validity/canonicality refutations) into the Polkadot network, an incentivisation for forwarding 6SPV refers to Simpliﬁed Payment Veriﬁcation in Bitcoin and describes a method for clients to verify transactions while keeping only a copy of all blocks headers of the longest PoW chain.

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 9 data is needed. This could be as simple as a payment (funded from fees collected on the Ethereum side) paid to anyone able to forward a useful block whose header is valid. Validators would be called upon to retain information relating to the last few thousand blocks in order to be able to manage forks, either through some protocolintrinsic means or through a contract maintained on the relay chain. 5.6. Polkadot and Bitcoin. Bitcoin interoperation presents an interesting challenge for Polkadot: a so-called “two-way peg” would be a useful piece of infrastructure to have on the side of both networks. However, due to the limitations of Bitcoin, providing such a peg securely is a non-trivial undertaking. Delivering a transaction from Bitcoin to Polkadot can in principle be done with a process similar to that for Ethereum; a “break-out address” controlled in some way by the Polkadot validators could receive transferred tokens (and data sent alongside them). SPV proofs could be provided by incentivised oracles and, together with a conﬁrmation period, a bounty given for identifying non-canonical blocks implying the transaction has been “double-spent”. Any tokens then owned in the “break-out address” would then, in principle, be controlled by those same validators for later dispersal. The problem however is how the deposits can be securely controlled from a rotating validator set. Unlike Ethereum which is able to make arbitrary decisions based upon combinations of signatures, Bitcoin is substantially more limited, with most clients accepting only multisignature transactions with a maximum of 3 parties. Extending this to 36, or indeed thousands as might ultimately be desired, is impossible under the current protocol. One option is to alter the Bitcoin protocol to enable such functionality, however so-called “hard forks” in the Bitcoin world are diﬃcult to arrange judging by recent attempts. One possibility is the use of threshold signatures, cryptographic schemes to allow a singly identiﬁable public key to be eﬀectively controlled by multiple secret “parts”, some or all of which must be utilised to create a valid signature. Unfortunately, threshold signatures compatible with Bitcoin’s ECDSA are computationally expensive to create and of polynomial complexity. Other schemes such a Schnorr signatures provide far lower costs, however the timeline on which they may be introduced into the Bitcoin protocol is uncertain. Since the ultimate security of the deposits rests with a number of bonded validators, one other option is to reduce the multi-signature key-holders to only a heavily bonded subset of the total validators such that threshold signatures become feasible (or, at worst, Bitcoin’s native multi-signature is possible). This of course reduces the total amount of bonds that could be deducted in reparations should the validators behave illegally, however this is a graceful degradation, simply setting an upper limit of the amount of funds that can securely run between the two networks (or indeed, on the % losses should an attack from the validators succeed). As such we believe it not unrealistic to place a reasonably secure Bitcoin interoperability “virtual parachain” between the two networks, though nonetheless a substantial eﬀort with an uncertain timeline and quite possibly requiring the cooperation of the stakeholders within that network.

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.

Protocol in Detail

The protocol can be roughly broken down into three parts: the consensus mechanism, the parachain interface and interchain transaction routing. 6.1. Relay-chain Operation. The relay-chain will likely be a chain broadly similar to Ethereum in that it is state-based with the state mapping address to account information, mainly balances and (to prevent replays) a transaction counter. Placing accounts here fulﬁls one purpose: to provide accounting for which identity possesses what amount of stake in the system.7 There will be notable diﬀerences, though: • Contracts cannot be deployed through transactions; following from the desire to avoid application functionality on the relay-chain, it will not support public deployment of contracts. • Compute resource usage (“gas”) is not accounted; since the only functions available for public usage will be ﬁxed, the rationale behind gas accounting no longer holds. As such, a ﬂat fee will apply in all cases, allowing for more performance from any dynamic code execution that may need to be done and a simpler transaction format. • Special functionality is supported for listed contracts that allows for auto-execution and networkmessage outputs. In the event that the relay-chain has a VM and it be based around the EVM, it would have a number of modiﬁcations to ensure maximal simplicity. It would likely have a number of built-in contracts (similar to those at addresses 1-4 in Ethereum) to allow for platform-speciﬁc duties to be managed including a consensus contract, a validator contract and a parachain contract. If not the EVM, then a WebAssembly [2] (wasm) backend is the most likely alternative; in this case the overall structure would be similar, but there would be no need for the built-in contracts with Wasm being a viable target for general purpose languages rather than the immature and limited languages for the EVM. Other likely deviations from the present Ethereum protocol are quite possible, for example a simpliﬁcation of the transaction-receipt format allowing for the parallel execution of non-conﬂicting transactions within the same block, as proposed for the Serenity series of changes. It is possible, though unlikely, that a Serenity-like “pure” chain be deployed as the relay-chain, allowing for a particular contract to manage things like the staking token balances rather than making that a fundamental part of the chain’s protocol. At present, we feel it is unlikely this will oﬀer a suﬃciently great protocol simpliﬁcation to be worth the additional complexity and uncertainty involved in developing it. 7As a means of representing the amount a given holder is responsible for the overall security of the system, these stake accounts will inevitably encode some economic value. However, it should be understood that since there is no intention that such values be used in any way for the purpose of exchanging for real-world goods and services, it should be accordingly noted that the tokens not be likened to currency and as such the relay-chain retain its nihilistic philosophy regarding applications.

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 10 There are a number of small pieces of functionality required for administrating the consensus mechanism, validator set, validation mechanism and parachains. These could be implemented together under a monolithic protocol. However, for reasons of auguring modularity, we describe these as “contracts” of the relay-chain. This should be taken to mean that they are objects (in the sense of object-orientated programming) managed by the relaychain’s consensus mechanism, but not necessarily that they are deﬁned as programs in EVM-like opcodes, nor even that they be individually addressable through the account-system. 6.2. Staking Contract. This contract maintains the validator set. It manages: • which accounts are currently validators; • which are available to become validators at short notice; • which accounts have placed stake nominating to a validator; • properties of each including staking volume, acceptable payout-rates and addresses and shortterm (session) identities. It allows an account to register a desire to become a bonded validator (along with its requirements), to nominate to some identity, and for preexisting bonded validators to register their desire to exit this status. It also includes the machinery itself for the validation and canonicalisation mechanism. 6.2.1. Stake-token Liquidity. It is generally desirable to have as much of the total staking tokens as possible to be staked within the network maintenance operations since this directly ties the network security to the overall “market capitalisation” of the staking token. This can easily be incentivised through inﬂating the currency and handing out the proceeds to those who participate as validators. However, to do so presents a problem: if the token is locked in the Staking Contract under punishment of reduction, how can a substantial portion remain suﬃciently liquid in order to allow price discovery? One answer to this is allowing a straight-forward derivative contract, securing fungible tokens on an underlying staked token. This is diﬃcult to arrange in a trustfree manner. Furthermore, these derivative tokens cannot be treated equally for the same reason that diﬀerent Eurozone government’s bonds are not fungible: there is a chance of the underlying asset failing and becoming worthless. With Eurozone governments, there could be a default. With validator-staked tokens, the validator may act maliciously and be punished. Keeping with our tenets, we elect for the simplest solution: not all tokens be staked. This would mean that some proportion (perhaps 20%) of tokens will forcibly remain liquid. Though this is imperfect from a security perspective, it is unlikely to make a fundamental diﬀerence in the security of the network; 80% of the reparations possible from bond-conﬁscations would still be able to be made compared to the “perfect case” of 100% staking. The ratio between staked and liquid tokens can be targeted fairly simply through a reverse auction mechanism. Essentially, token holders interested in being a validator would each post an oﬀer to the staking contract stating the minimum payout-rate that they would require to take part. At the beginning of each session (sessions would happen regularly, perhaps as often as once per hour) the validator slots would be ﬁlled according to each would-be validator’s stake and payout rate. One possible algorithm for this would be to take those with the lowest oﬀers who represent a stake no higher than the total stake targeted divided by the number of slots and no lower than a lowerbound of half that amount. If the slots cannot be ﬁlled, the lower bound could be repeatedly reduced by some factor in order to satisfy. 6.2.2. Nominating. It is possible to trustlessly nominate ones staking tokens to an active validator, giving them the responsibility of validators duties. Nominating works through an approval-voting system. Each would-be nominator is able to post an instruction to the staking contract expressing one or more validator identities under whose responsibility they are prepared to entrust their bond. Each session, nominators’ bonds are dispersed to be represented by one or more validators. The dispersal algorithm optimises for a set of validators of equivalent total bonds. Nominators’ bonds become under the eﬀective responsibility of the validator and gain interest or suﬀer a punishment-reduction accordingly. 6.2.3. Bond Conﬁscation/Burning. Certain validator behaviour results in a punitive reduction of their bond. If the bond is reduced below the allowable minimum, the session is prematurely ended and another started. A nonexhaustive list of punishable validator misbehaviour includes: • Being part of a parachain group unable to provide consensus over the validity of a parachain block; • actively signing for the validity of an invalid parachain block; • inability to supply egress payloads previously voted as available; • inactivity during the consensus process; • validating relay-chain blocks on competing forks. Some cases of misbehaviour threaten the network’s integrity (such as signing invalid parachain blocks and validating multiple sides of a fork) and as such result in effective exile through the total reduction of the bond. In other, less serious cases (e.g. inactivity in the consensus process) or cases where blame cannot be precisely allotted (being part of an ineﬀective group), a small portion of the bond may instead be ﬁned. In the latter case, this works well with sub-group churn to ensure that malicious nodes suﬀer substantially more loss than the collaterallydamaged benevolent nodes. In some cases (e.g. multi-fork validation and invalid sub-block signing) validators cannot themselves easily detect each others’ misbehaviour since constant veriﬁcation of each parachain block would be too arduous a task. Here it is necessary to enlist the support of parties external to the validation process to verify and report such misbehaviour. The parties get a reward for reporting such activity; their term, “ﬁshermen” stems from the unlikeliness of such a reward. Since these cases are typically very serious, we envision that any rewards can easily be paid from the conﬁscated bond. In general we prefer to balance burning (i.e. reduction to nothing) with reallocation, rather than attempting wholesale reallocation. This has the eﬀect of

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 11 increasing the overall value of the token, compensating the network in general to some degree rather than the speciﬁc party involved in discovery. This is mainly as a safety mechanism: the large amounts involved could lead to extreme and acute behaviour incentivisation were they all bestowed on a single target. In general, it is important that the reward is suﬃciently large to make veriﬁcation worthwhile for the network, yet not so large as to oﬀset the costs of fronting a well-ﬁnanced, well-orchestrated ”industrial-level” criminal hacking attack on some unlucky validator to force misbehaviour. In this way, the amount claimed should generally be no greater than the direct bond of the errant validator, lest a perverse incentive arise of misbehaving and reporting oneself for the bounty. This can be combated either explicitly through a minimum direct bond requirement for being a validator or implicitly by educating nominators that validators with little bonds deposited have no great incentive to behave well. 6.3. Parachain Registry. Each parachain is deﬁned in this registry. It is a relatively simple database-like construct and holds both static and dynamic information on each chain. Static information includes the chain index (a simple integer), along with the validation protocol identity, a means of distinguishing between the diﬀerent classes of parachain so that the correct validation algorithm can be run by validators consigned to putting forward a valid candidate. An initial proof-of-concept would focus on placing the new validation algorithms into clients themselves, effectively requiring a hard fork of the protocol each time an additional class of chain were added. Ultimately, though, it may be possible to specify the validation algorithm in a way both rigorous and eﬃcient enough that clients are able to eﬀectively work with new parachains without a hard-fork. One possible avenue to this would be to specify the parachain validation algorithm in a well-established, natively-compiled, platform-neutral language such as WebAssembly. Additional research is necessary to determine whether this is truly feasible, however if so, it could bring with it the tremendous advantage of banishing hard-forks for good. Dynamic information includes aspects of the transaction routing system that must have global agreement such as the parachain’s ingress queue (described in section 6.6). The registry is able to have parachains added only through full referendum voting; this could be managed internally but would more likely be placed in an external referendum contract in order to facilitate re-usage under more general governance components. The parameters to voting requirements (e.g. any quorum required, majority required) for registration of additional chains and other, less formal system upgrades will be set out in a “master constitution” but are likely to follow a fairly traditional path, at least initially. The precise formulation is out of scope for the present work, but e.g. a two thirds supermajority to pass with more than one third of total system stake voting positively may be a sensible starting point. Additional operations include the suspension and removal of parachains. Suspension would hopefully never happen, however it is designed to be a safeguard least there be some intractable problem in a parachain’s validation system. The most obvious instance where it might be needed is a consensus-critical diﬀerence between implementations leading validators to be unable to agree on validity or blocks. Validators would be encouraged to use multiple client implementations in order that they are able to spot such a problem prior to bond conﬁscation. Since suspension is an emergency measure, it would be under the auspices of the dynamic validator-voting rather than a referendum. Re-instating would be possible both from the validators or a referendum. The removal of parachains altogether would come only after a referendum and with which would be required a substantial grace period to allow an orderly transition to either a standalone chain or to become part of some other consensus-system. The grace period would likely be of the order of months and is likely to be set out on a perchain basis in the parachain registry in order that diﬀerent parachains can enjoy diﬀerent grace periods according to their need. 6.4. Sealing Relay Blocks. Sealing refers, in essence, to the process of canonicalisation; that is, a basic data transform which maps the original into something fundamentally singular and meaningful. Under a PoW chain, sealing is eﬀectively a synonym for mining. In our case, it involves the collection of signed statements from validators over the validity, availability and canonicality of a particular relay-chain block and the parachain blocks that it represents. The mechanics of the underlying BFT consensus algorithm is out of scope for the present work. We will instead describe it using a primitive which assumes a consensus-creating state-machine. Ultimately we expect to be inspired by a number of promising BFT consensus algorithms in the core; Tangaora [9] (a BFT variant of Raft [16]), Tendermint [11] and HoneyBadgerBFT [14]. The algorithm will have to reach an agreement on multiple parachains in parallel, thus diﬀering from the usual blockchain consensus mechanisms. We assume that once consensus is reached, we are able to record the consensus in an irrefutable proof which can be provided by any of the participants to it. We also assume that misbehaviour within the protocol can be generally reduced to a small group containing misbehaving participants to minimise the collateral damage when dealing out punishment.8 The proof, which takes the form of our signed statements, is placed in the relay-chain block’s header together with certain other ﬁelds not least the relay-chain’s statetrie root and transaction-trie root. The sealing process takes place under a single consensus-generating mechanism addressing both the relay-chain’s block and the parachains’ blocks which make up part of the relay’s content: parachains are not separately “committed” by their sub-groups and then collated later. This results in a more complex process for the relaychain, but allows us to complete the entire system’s consensus in a single stage, minimising latency and allowing for quite complex data-availability requirements which are helpful for the routing process below. 8Existing PoS-based BFT consensus schemes such as Tendermint BFT and the original Slasher fulﬁll these assertions.

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 12 The state of each participant’s consensus machine may be modelled as a simple (2-dimensional) table. Each participant (validator) has a set of information, in the form of signed-statements (“votes”) from other participants, regarding each parachain block candidate as well the relaychain block candidate. The set of information is two pieces of data: Availability: does this validator have egress transaction-post information from this block so they are able to properly validate parachain candidates on the following block? They may vote either 1(known) or 0 (not yet known). Once they vote 1, they are committed to voting similarly for the rest of this process. Later votes that do not respect this are grounds for punishment. Validity: is the parachain block valid and is all externally-referenced data (e.g. transactions) available? This is only relevant for validators assigned to the parachain on which they are voting. They may vote either 1 (valid), -1 (invalid) or 0 (not yet known). Once they vote non-zero, they are committed to voting this way for the rest of the process. Later votes that do not respect this are grounds for punishment. All validators must submit votes; votes may be resubmitted, qualiﬁed by the rules above. The progression of consensus may be modelled as multiple standard BFT consensus algorithms over each parachain happening in parallel. Since these are potentially thwarted by a relatively small minority of malicious actors being concentrated in a single parachain group, the overall consensus exists to establish a backstop, limiting the worst-case scenario from deadlock to merely one or more void parachain blocks (and a round of punishment for those responsible). The basic rules for validity of the individual blocks (that allow the total set of validators as a whole to come to consensus on it becoming the unique parachain candidate to be referenced from the canonical relay): • must have at least two thirds of its validators voting positively and none voting negatively; • must have over one third validators voting positively to the availability of egress queue information. If there is at least one positive and at least one negative vote on validity, an exceptional condition is created and the whole set of validators must vote to determine if there are malicious parties or if there is an accidental fork. Aside from valid and invalid, a third kind of votes are allowed, equivalent to voting for both, meaning that the node has conﬂicting opinions. This could be due to the node’s owner running multiple implementations which do not agree, indicating a possible ambiguity in the protocol. After all votes are counted from the full validator set, if the losing opinion has at least some small proportion (to be parameterised; at most half, perhaps signiﬁcantly less) of the votes of the winning opinion, then it is assumed to be an accidental parachain fork and the parachain is automatically suspended from the consensus process. Otherwise, we assume it is a malicious act and punish the minority who were voting for the dissenting opinion. The conclusion is a set of signatures demonstrating canonicality. The relay-chain block may then be sealed and the process of sealing the next block begun. 6.5. Improvements for Sealing Relay Blocks. While this sealing method gives strong guarantees over the system’s operation, it does not scale out particularly well since every parachain’s key information must have its availability guaranteed by over one-third of all validators. This means that every validator’s responsibility footprint grows as more chains are added. While data availability within open consensus networks is essentially an unsolved problem, there are ways of mitigating the overhead placed on validator nodes. One simple solution is to realise that while validators must shoulder the responsibility for data availability, they need not actually store, communicate or replicate the data themselves. Secondary data silos, possibly related to (or even the very same) collators who compile this data, may manage the task of guaranteeing availability with the validators providing a portion of their interest/income in payment. However, while this might buy some intermediate scalability, it still doesn’t help the underlying problem; since adding more chains will in general require additional validators, the ongoing network resource consumption (particularly in terms of bandwidth) grows with the square of the chains, an untenable property in the long-term. Ultimately, we are likely to keep bashing our heads against the fundamental limitation which states that for a consensus network to be considered available safe, the ongoing bandwidth requirements are of the order of total validators times total input information. This is due to the inability of an untrusted network to properly distribute the task of data storage across many nodes, which sits apart from the eminently distributable task of processing. 6.5.1. Introducing Latency. One means of softening this rule is to relax the notion of immediacy. By requiring 33%+1 validators voting for availability only eventually, and not immediately, we can better utilise exponential data propagation and help even out peaks in datainterchange. A reasonable equality (though unproven) may be: (1) latency = participants × chains Under the current model, the size of the system scales with the number of chains to ensure that processing is distributed; since each chain will require at least one validator and we ﬁx the availability attestation to a constant proportion of validators, then participants similarly grows with the number of chains. We end up with: (2) latency = size2 Meaning that as the system grows, the bandwidth required and latency until availability is known across the network, which might also be characterised as the number of blocks before ﬁnality, increases with its square. This is a substantial growth factor and may turn out to be a notable road blocker and force us into “non-ﬂat” paradigms such as composing several “Polkadotes” into a hierarchy for multi-level routing of posts through a tree of relaychains.

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 13 6.5.2. Public Participation. One more possible direction is to enlist public participation in the process through a micro-complaints system. Similar to the ﬁshermen, there could be external parties to police the validators who claim availability. Their task is to ﬁnd one who appears unable to demonstrate such availability. In doing so they can lodge a micro-complaint to other validators. PoW or a staked bond may be used to mitigate the sybil attack which would render the system largely useless. 6.5.3. Availability Guarantors. A ﬁnal route would be to nominate a second set of bonded validators as “availability guarantors”. These would be bonded just as with the normal validators, and may even be taken from the same set (though if so, they would be chosen over a long-term period, at least per session). Unlike normal validators, they would not switch between parachains but rather would form a single group to attest to the availability of all important interchain data. This has the advantage of relaxing the equivalence between participants and chains. Essentially, chains can grow (along with the original chain validator set), whereas the participants, and speciﬁcally those taking part in dataavailability testament, can remain at the least sub-linear and quite possibly constant. 6.5.4. Collator Preferences. One important aspect of this system is to ensure that there is a healthy selection of collators creating the blocks in any given parachain. If a single collator dominated a parachain then some attacks become more feasible since the likelihood of the lack of availability of external data would be less obvious. One option is to artiﬁcially weight parachain blocks in a pseudo-random mechanism in order to favour a wide variety of collators. In the ﬁrst instance, we would require as part of the consensus mechanism that validators favour parachain block candidates determined to be “heavier”. Similarly, we must incentivise validators to attempt to suggest the weightiest block they can ﬁnd—this could be done through making a portion of their reward proportional to the weight of their candidate. To ensure that collators are given a reasonable fair chance of their candidate being chosen as the winning candidate in consensus, we make the speciﬁc weight of a parachain block candidate determinate on a random function connected with each collator. For example, taking the XOR distance measure between the collator’s address and some cryptographically-secure pseudorandom number determined close to the point of the block being created (a notional “winning ticket”). This eﬀectively gives each collator (or, more speciﬁcally, each collator’s address) a random chance of their candidate block “winning” over all others. To mitigate the sybil attack of a single collator “mining” an address close to the winning ticket and thus being a favourite each block, we would add some inertia to a collator’s address. This may be as simple as requiring them to have a baseline amount of funds in the address. A more elegant approach would be to weight the proximity to the winning ticket with the amount of funds parked at the address in question. While modelling has yet to be done, it is quite possible that this mechanism enables even very small stakeholders to contribute as a collator. 6.5.5. Overweight Blocks. If a validator set is compromised, they may create and propose a block which though valid, takes an inordinate amount of time to execute and validate. This is a problem since a validator group could reasonably form a block which takes a very long time to execute unless some particular piece of information is already known allowing a short cut, e.g. factoring a large prime. If a single collator knew that information, then they would have a clear advantage in getting their own candidates accepted as long as the others were busy processing the old block. We call these blocks overweight. Protection against validators submitting and validating these blocks largely falls under the same guise as for invalid blocks, though with an additional caveat: Since the time taken to execute a block (and thus its status as overweight) is subjective, the ﬁnal outcome of a vote on misbehaviour will fall into essentially three camps. One possibility is that the block is deﬁnitely not overweight— in this case more than two-thirds declare that they could execute the block within some limit (e.g. 50% of the total time allowed between blocks). Another is that the block is deﬁnitely overweight—this would be if more than two-thirds declare that they could not execute the block within said limit. One ﬁnal possibility is a fairly equal split of opinion between validators. In this case, we may choose to do some proportionate punishment. To ensure validators can predict when they may be proposing an overweight block, it may be sensible to require them to publish information on their own performance for each block. Over a suﬃcient period of time, this should allow them to proﬁle their processing speed relative to the peers that would be judging them. 6.5.6. Collator Insurance. One issue remains for validators: unlike with PoW networks, to check a collator’s block for validity, they must actually execute the transactions in it. Malicious collators can feed invalid or overweight blocks to validators causing them grief (wasting their resources) and exacting a potentially substantial opportunity cost. To mitigate this, we propose a simple strategy on the part of validators. Firstly, parachain block candidates sent to validators must be signed from a relay chain account with funds; if they are not, then the validator should drop it immediately. Secondly, such candidates should be ordered in priority by a combination (e.g. multiplication) of the amount of funds in the account up to some cap, the number of previous blocks that the collator has successfully proposed in the past (not to mention any previous punishments), and the proximity factor to the winning ticket as discussed previously. The cap should be the same as the punitive damages paid to the validator in the case of them sending an invalid block. To disincentivise collators from sending invalid or overweight block candidates to validators, any validator may place in the next block a transaction including the oﬀending block alleging misbehaviour with the eﬀect of transferring some or all of the funds in the misbehaving collator’s account to the aggrieved validator. This type of transaction front-runs any others to ensure the collator cannot remove the funds prior to the punishment. The amount of funds transferred as damages is a dynamic parameter yet

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 14 to be modelled but will likely be a proportion of the validator block reward to reﬂect the level of grief caused. To prevent malicious validators arbitrarily conﬁscating collators’ funds, the collator may appeal the validator’s decision with a jury of randomly chosen validators in return for placing a small deposit. If they ﬁnd in the validator’s favour, the deposit is consumed by them. If not, the deposit is returned and the validator is ﬁned (since the validator is in a much more vaulted position, the ﬁne will likely be rather hefty). 6.6. Interchain Transaction Routing. Interchain transaction routing is one of the essential maintenance tasks of the relay-chain and its validators. This is the logic which governs how a posted transaction (often shortened to simply “post”) gets from being a desired output from one source parachain to being a non-negotiable input of another destination parachain without any trust requirements. We choose the wording above carefully; notably we don’t require there to have been a transaction in the source parachain to have explicitly sanctioned this post. The only constraints we place upon our model is that parachains must provide, packaged as a part of their overall block processing output, the posts which are the result of the block’s execution. These posts are structured as several FIFO queues; the number of lists is known as the routing base and may be around 16. Notably, this number represents the quantity of parachains we can support without having to resort to multi-phase routing. Initially, Polkadot will support this kind of direct routing, however we will outline one possible multi-phase routing process (“hyper-routing”) as a means of scaling out well past the initial set of parachains. We assume that all participants know the subgroupings for next two blocks n, n + 1. In summary, the routing system follows these stages: • CollatorS: Contact members of V alidators[n][S] • CollatorS: FOR EACH subgroup s: ensure at least 1 member of V alidators[n][s] in contact • CollatorS: FOR EACH subgroup s: assume egress[n −1][s][S] is available (all incoming post data to ‘S‘ from last block) • CollatorS: Compose block candidate b for S: (b.header, b.ext, b.proof, b.receipt, b.egress) • CollatorS: Send proof information proof[S] = (b.header, b.ext, b.proof, b.receipt) to V alidators[n][S] • CollatorS: Ensure external transaction data b.ext is made available to other collators and validators • CollatorS: FOR EACH subgroup s: Send egress information egress[n][S][s] = (b.header, b.receipt, b.egress[s]) to the receiving sub-group’s members of next block V alidators[n + 1][s] • V alidatorV : Pre-connect all same-set members for next block: let N = Chain[n + 1][V ]; connect all validators v such that Chain[n + 1][v] = N • V alidatorV : Collate all data ingress for this block: FOR EACH subgroup s: Retrieve egress[n −1][s][Chain[n][V ]], get from other validators v such that Chain[n][v] = Chain[n][V ]. Possibly going via randomly selected other validators for proof of attempt. • V alidatorV : Accept candidate proofs for this block proof[Chain[n][V ]]. Vote block validity • V alidatorV : Accept candidate egress data for next block: FOR EACH subgroup s, accept egress[n][s][N]. Vote block egress availability; republish among interested validators v such that Chain[n + 1][v] = Chain[n + 1][V ]. • V alidatorV : UNTIL CONSENSUS Where: egress[n][from][to] is the current egress queue information for posts going from parachain ‘from‘, to parachain ‘to‘ in block number ‘n‘. CollatorS is a collator for parachain S. V alidators[n][s] is the set of validators for parachain s at block number n. Conversely, Chain[n][v] is the parachain to which validator v is assigned on block number n. block.egress[to] is the egress queue of posts from some parachain block block whose destination parachain is to. Since collators collect (transaction) fees based upon their blocks becoming canonical they are incentivised to ensure that for each next-block destination, the subgroup’s members are informed of the egress queue from the present block. Validators are incentivised only to form a consensus on a (parachain) block, as such they care little about which collator’s block ultimately becomes canonical. In principle, a validator could form an allegiance with a collator and conspire to reduce the chances of other collators’ blocks becoming canonical, however this is both diﬃcult to arrange due to the random selection of validators for parachains and could be defended against with a reduction in fees payable for parachain blocks which hold up the consensus process. 6.6.1. External Data Availability. Ensuring a parachain’s external data is actually available is a perennial issue with decentralised systems aiming to distribute workload across the network. At the heart of the issue is the availability problem which states that since it is neither possible to make a non-interactive proof of availability nor any sort of proof of non-availability, for a BFT system to properly validate any transition whose correctness relies upon the availability of some external data, the maximum number of acceptably Byzantine nodes, plus one, of the system must attest to the data being available. For a system to scale out properly, like Polkadot, this invites a problem: if a constant proportion of validators must attest to the availability of the data, and assuming that validators will want to actually store the data before asserting it is available, then how do we avoid the problem of the bandwidth/storage requirements increasing with the system size (and therefore number of validators)? One possible answer would be to have a separate set of validators (availability guarantors), whose order grows sublinearly with the size of Polkadot as a whole. This is described in 6.5.3. We also have a secondary trick. As a group, collators have an intrinsic incentive to ensure that all data is available for their chosen parachain since without it they are unable to author further blocks from which they can collect transaction fees. Collators also form a group, membership of which is varied (due to the random nature of parachain validator groups) non-trivial to enter and easy

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 15 to prove. Recent collators (perhaps of the last few thousand blocks) are therefore allowed to issue challenges to the availability of external data for a particular parachain block to validators for a small bond. Validators must contact those from the apparently offending validator sub-group who testiﬁed and either acquire and return the data to the collator or escalate the matter by testifying to the lack of availability (direct refusal to provide the data counts as a bond-conﬁscating offence, therefore the misbehaving validator will likely just drop the connection) and contacting additional validators to run the same test. In the latter case, the collator’s bond is returned. Once a quorum of validators who can make such nonavailability testimonials is reached, they are released, the misbehaving sub-group is punished, and the block reverted. 6.6.2. Posts Routing. Each parachain header includes an egress-trie-root; this is the root of a trie containing the routing-base bins, each bin being a concatenated list of egress posts. Merkle proofs may be provided across parachain validators to prove that a particular parachain’s block had a particular egress queue for a particular destination parachain. At the beginning of processing a parachain block, each other parachain’s egress queue bound for said block is merged into our block’s ingress queue. We assume strong, probably CSPR9, sub-block ordering to achieve a deterministic operation that oﬀers no favouritism between any parachain block pairing. Collators calculate the new queue and drain the egress queues according to the parachain’s logic. The contents of the ingress queue is written explicitly into the parachain block. This has two main purposes: ﬁrstly, it means that the parachain can be trustlessly synchronised in isolation from the other parachains. Secondly, it simpliﬁes the data logistics should the entire ingress queue not be able to be processed in a single block; validators and collators are able to process following blocks without having to source the queue’s data specially. If the parachain’s ingress queue is above a threshold amount at the end of block processing, then it is marked saturated on the relay-chain and no further messages may be delivered to it until it is cleared. Merkle proofs are used to demonstrate ﬁdelity of the collator’s operation in the parachain block’s proof. 6.6.3. Critique. One minor ﬂaw relating to this basic mechanism is the post-bomb attack. This is where all parachains send the maximum amount of posts possible to a particular parachain. While this ties up the target’s ingress queue at once, no damage is done over and above a standard transaction DoS attack. Operating normally, with a set of well-synchronised and non-malicious collators and validators, for N parachains, N × M total validators and L collators per parachain, we can break down the total data pathways per block to: Validator: M −1+L+L: M −1 for the other validators in the parachain set, L for each collator providing a candidate parachain block and a second L for each collator of the next block requiring the egress payloads of the previous block. (The latter is actually more like worst-case operation since it is likely that collators will share such data.) Collator: M +kN: M for a connection to each relevant parachain block validator, kN for seeding the egress payloads to some subset of each parachain validator group for the next block (and possibly some favoured collator(s)). As such, the data path ways per node grow linearly with the overall complexity of the system. While this is reasonable, as the system scales into hundreds or thousands of parachains, some communication latency may be absorbed in exchange for a lower complexity growth rate. In this case, a multi-phase routing algorithm may be used in order to reduce the number of instantaneous pathways at a cost of introducing storage buﬀers and latency. 6.6.4. Hyper-cube Routing. Hyper-cube routing is a mechanism which can mostly be build as an extension to the basic routing mechanism described above. Essentially, rather than growing the node connectivity with the number of parachains and sub-group nodes, we grow only with the logarithm of parachains. Posts may transit between several parachains’ queues on their way to ﬁnal delivery. Routing itself is deterministic and simple. We begin by limiting the number of bins in the ingress/egress queues; rather than being the total number of parachains, they are the routing-base (b) . This will be ﬁxed as the number of parachains changes, with the routing-exponent (e) instead being raised. Under this model, our message volume grows with O(be), with the pathways remaining constant and the latency (or number of blocks required for delivery) with O(e). Our model of routing is a hypercube of e dimensions, with each side of the cube having b possible locations. Each block, we route messages along a single axis. We alternate the axis in a round-robin fashion, thus guaranteeing worst-case delivery time of e blocks. As part of the parachain processing, foreign-bound messages found in the ingress queue are routed immediately to the appropriate egress queue’s bin, given the current block number (and thus routing dimension). This process necessitates additional data transfer for each hop on the delivery route, however this is a problem itself which may be mitigated by using some alternative means of data payload delivery and including only a reference, rather than the full payload of the post in the post-trie. An example of such a hyper-cube routing for a system with 4 parachains, b = 2 and e = 2 might be: Phase 0, on each message M: • sub0: if $M_{\text{dest}} \in \{2, 3\}$ then sendTo(2) else keep • sub1: if $M_{\text{dest}} \in \{2, 3\}$ then sendTo(3) else keep • sub2: if $M_{\text{dest}} \in \{0, 1\}$ then sendTo(0) else keep • sub3: if $M_{\text{dest}} \in \{0, 1\}$ then sendTo(1) else keep Phase 1, on each message M: • sub0: if $M_{\text{dest}} \in \{1, 3\}$ then sendTo(1) else keep • sub1: if $M_{\text{dest}} \in \{0, 2\}$ then sendTo(0) else keep • sub2: if $M_{\text{dest}} \in \{1, 3\}$ then sendTo(3) else keep • sub3: if $M_{\text{dest}} \in \{0, 2\}$ then sendTo(2) else keep The two dimensions here are easy to see as the ﬁrst two bits of the destination index; for the ﬁrst block, the higher-order bit alone is used. The second block deals with the low-order bit. Once both happen (in arbitrary order) then the post will be routed. 9cryptographically secure pseudo-random

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 16 6.6.5. Maximising Serendipity. One alteration of the basic proposal would see a ﬁxed total of c2 −c validators, with c−1 validators in each sub-group. Each block, rather than there being an unstructured repartitioning of validators among parachains, instead for each parachain sub-group, each validator would be assigned to a unique and diﬀerent parachain sub-group on the following block. This would lead to the invariant that between any two blocks, for any two pairings of parachain, there exists two validators who have swapped parachain responsibilities. While this cannot be used to gain absolute guarantees on availability (a single validator will occasionally drop oﬄine, even if benevolent), it can nonetheless optimise the general case. This approach is not without complications. The addition of a parachain would also necessitate a reorganisation of the validator set. Furthermore the number of validators, being tied to the square of the number of parachains, would start initially very small and eventually grow far too fast, becoming untenable after around 50 parachains. None of these are fundamental problems. In the ﬁrst case, reorganisation of validator sets is something that must be done regularly anyway. Regarding the size of the validator set, when too small, multiple validators may be assigned to the same parachain, applying an integer factor to the overall total of validators. A multi-phase routing mechanism such as Hypercube Routing, discussed in 6.6.4 would alleviate the requirement for large number of validators when there is a large number of chains. 6.7. Parachain Validation. A validator’s main purpose is to testify, as a well-bonded actor, that a parachain’s block is valid, including but not limited to any state transition, any external transactions included, the execution of any waiting posts in the ingress queue and the ﬁnal state of the egress queue. The process itself is fairly simple. Once the validator sealed the previous block they are free to begin working to provide a candidate parachain block candidate for the next round of consensus. Initially, the validator ﬁnds a parachain block candidate through a parachain collator (described next) or one of its co-validators. The parachain block candidate data includes the block’s header, the previous block’s header, any external input data included (for Ethereum and Bitcoin, such data would be referred to as transactions, however in principle they may include arbitrary data structures for arbitrary purposes), egress queue data and internal data to prove state-transition validity (for Ethereum this would be the various state/storage trie nodes required to execute each transaction). Experimental evidence shows this full dataset for a recent Ethereum block to be at the most a few hundred KiB. Simultaneously, if not yet done, the validator will be attempting to retrieve information pertaining to the previous block’s transition, initially from the previous block’s validators and later from all validators signing for the availability of the data. Once the validator has received such a candidate block, they then validate it locally. The validation process is contained within the parachain class’s validator module, a consensus-sensitive software module that must be written for any implementation of Polkadot (though in principle a library with a C ABI could enable a single library to be shared between implementations with the appropriate reduction in safety coming from having only a single “reference” implementation). The process takes the previous block’s header and veriﬁes its identity through the recently agreed relay-chain block in which its hash should be recorded. Once the parent header’s validity is ascertained, the speciﬁc parachain class’s validation function may be called. This is a single function accepting a number of data ﬁelds (roughly those given previously) and returning a simple Boolean proclaiming the validity of the block. Most such validation functions will ﬁrst check the header-ﬁelds which are able to be derived directly from the parent block (e.g. parent hash, number). Following this, they will populate any internal data structures as necessary in order to process transactions and/or posts. For an Ethereum-like chain this amounts to populating a trie database with the nodes that will be needed for the full execution of transactions. Other chain types may have other preparatory mechanisms. Once done, the ingress posts and external transactions (or whatever the external data represents) will be enacted, balanced according to chain’s speciﬁcation. (A sensible default might be to require all ingress posts be processed before external transactions be serviced, however this should be for the parachain’s logic to decide.) Through this enactment, a series of egress posts will be created and it will be veriﬁed that these do indeed match the collator’s candidate. Finally, the properly populated header will be checked against the candidate’s header. With a fully validated candidate block, the validator can then vote for the hash of its header and send all requisite validation information to the co-validators in its subgroup. 6.7.1. Parachain Collators. Parachain collators are unbonded operators who fulﬁll much of the task of miners on the present-day blockchain networks. They are speciﬁc to a particular parachain. In order to operate they must maintain both the relay-chain and the fully synchronised parachain. The precise meaning of “fully synchronised” will depend on the class of parachain, though will always include the present state of the parachain’s ingress queue. In Ethereum’s case it also involves at least maintaining a Merkle-tree database of the last few blocks, but might also include various other data structures including Bloom ﬁlters for account existence, familial information, logging outputs and reverse lookup tables for block number. In addition to keeping the two chains synchronised, it must also “ﬁsh” for transactions by maintaining a transaction queue and accepting properly validated transactions from the public network. With the queue and chain, it is able to create new candidate blocks for the validators chosen at each block (whose identity is known since the relaychain is synchronised) and submit them, together with the various ancillary information such as proof-of-validity, via the peer network. For its trouble, it collects all fees relating to the transactions it includes. Various economics ﬂoat around this arrangement. In a heavily competitive market where there is a surplus of collators, it is possible that the transaction fees be shared with the parachain validators to incentivise the inclusion of a particular collator’s block. Similarly,

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 17 some collators may even raise the required fees that need to be paid in order to make the block more attractive to validators. In this case, a natural market should form with transactions paying higher fees skipping the queue and having faster inclusion in the chain. 6.8. Networking. Networking on traditional blockchains like Ethereum and Bitcoin has rather simple requirements. All transactions and blocks are broadcast in a simple undirected gossip. Synchronisation is more involved, especially with Ethereum but in reality this logic was contained in the peer strategy rather than the protocol itself which resolved around a few request and answer message types. While Ethereum made progress on current protocol offerings with the devp2p protocol, which allowed for many subprotocols to be multiplexed over a single peer connection and thus have the same peer overlay support many p2p protocols simultaneously, the Ethereum portion of the protocol still remained relatively simple and the p2p protocol as a while remains unﬁnished with important functionality missing such as QoS support. Sadly, a desire to create a more ubiquitous “web 3” protocol largely failed, with the only projects using it being those explicitly funded from the Ethereum crowd-sale. The requirements for Polkadot are rather more substantial. Rather then a wholly uniform network, Polkadot has several types of participants each with diﬀerent requirements over their peer makeup and several network “avenues” whose participants will tend to converse about particular data. This means a substantially more structured network overlay—and a protocol supporting that— will likely be necessary. Furthermore, extensibility to facilitate future additions such as new kinds of “chain” may themselves require a novel overlay structure. While an in-depth discussion of how the networking protocol may look is outside of the scope of this document, some requirements analysis is reasonable. We can roughly break down our network participants into two sets (relay-chain, parachains) each of three subsets. We can also state that each of the parachain participants are only interested in conversing between themselves as opposed to participants in other parachains: • Relay-chain participants: • Validators: P, split into subsets P[s] for each parachain • Availability Guarantors: A (this may be represented by Validators in the basic form of the protocol) • Relay-chain clients: M (note members of each parachain set will also tend to be members of M) • Parachain participants: • Parachain Collators: C[0], C[1], . . . • Parachain Fishermen: F[0], F[1], . . . • Parachain clients: S[0], S[1], . . . • Parachain light-clients: L[0], L[1], . . . In general we name particular classes of communication will tend to take place between members of these sets: • P | A <-> P | A: The full set of validators/guarantors must be well-connected to achieve consensus. • P[s] <-> C[s] | P[s]: Each validator as a member of a given parachain group will tend to gossip with other such members as well as the collators of that parachain to discover and share block candidates. • A <-> P[s] | C | A: Each availability guarantor will need to collect consensus-sensitive cross-chain data from the validators assigned to it; collators may also optimise the chance of consensus on their block by advertising it to availability guarantors. Once they have it, the data will be disbursed to other such guarantor to facilitate consensus. • P[s] <-> A | P[s']: Parachain validators will need to collect additional input data from the previous set of validators or the availability guarantors. • F[s] <-> P: When reporting, ﬁshermen may place a claim with any participant. • M <-> M | P | A: General relay-chain clients disburse data from validators and guarantors. • S[s] <-> S[s] | P[s] | A: Parachain clients disburse data from the validator/guarantors. • L[s] <-> L[s] | S[s]: Parachain light clients disburse data from the full clients. To ensure an eﬃcient transport mechanism, a “ﬂat” overlay network—like Ethereum’s devp2p—where each node does not (non-arbitrarily) diﬀerentiate ﬁtness of its peers is unlikely to be suitable. A reasonably extensible peer selection and discovery mechanism will likely need to be included within the protocol as well as aggressive planning an lookahead to ensure the right sort of peers are “serendipitously” connected at the right time. The precise strategy of peer make-up will be diﬀerent for each class of participant: for a properly scaled-out multi-chain, collators will either need to be continuously reconnecting to the accordingly elected validators, or will need on-going agreements with a subset of the validators to ensure they are not disconnected during the vast majority of the time that they are useless for that validator. Collators will also naturally attempt to maintain one or more stable connections into the availability guarantor set to ensure swift propagation of their consensus-sensitive data. Availability guarantors will mostly aim to maintain a stable connection to each other and to validators (for consensus and the consensus-critical parachain data to which they attest), as well as to some collators (for the parachain data) and some ﬁshermen and full clients (for dispersing information). Validators will tend to look for other validators, especially those in the same sub-group and any collators that can supply them with parachain block candidates. Fishermen, as well as general relay-chain and parachain clients will generally aim to keep a connection open to a validator or guarantor, but plenty of other nodes similar to themselves otherwise. Parachain light clients will similarly aim to be connected to a full client of the parachain, if not just other parachain light-clients. 6.8.1. The Problem of Peer Churn. In the basic protocol proposal, each of these subsets constantly alter randomly with each block as the validators assigned to verify the parachain transitions are randomly elected. This can be a problem should disparate (non-peer) nodes need to pass data between each other. One must either rely on a fairly-distributed and well-connected peer network to

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 18 ensure that the hop-distance (and therefore worst-case latency) only grows with the logarithm of the network size (a Kademlia-like protocol [13] may help here), or one must introduce longer block times to allow the necessary connection negotiation to take place to keep a peer-set that reﬂects the node’s current communication needs. Neither of these are great solutions: long block times being forced upon the network may render it useless for particular applications and chains. Even a perfectly fair and connected network will result in substantial wastage of bandwidth as it scales due to uninterested nodes having to forward data useless to them. While both directions may form part of the solution, a reasonable optimisation to help minimise latency would be to restrict the volatility of these parachain validator sets, either reassigning the membership only between series of blocks (e.g. in groups of 15, which at a 4 second block time would mean altering connections only once per minute) or by rotating membership in an incremental fashion, e.g. changing by one member at a time (e.g. if there are 15 validators assigned to each parachain, then on average it would be a full minute between completely unique sets). By limiting the amount of peer churn, and ensuring that advantageous peer connections are made well in advance through the partial predictability of parachain sets, we can help ensure each node keep a permanently serendipitous selection of peers. 6.8.2. Path to an Eﬀective Network Protocol. Likely the most eﬀective and reasonable development eﬀort will focus on utilising a pre-existing protocol rather than rolling our own. Several peer-to-peer base protocols exist that we may use or augment including Ethereum’s own devp2p [22], IPFS’s libp2p [1] and GNU’s GNUnet [4]. A full review of these protocols and their relevance for building a modular peer network supporting certain structural guarantees, dynamic peer steering and extensible sub-protocols is well beyond the scope of this document but will be an important step in the implementation of Polkadot. 7. Practicalities of the Protocol 7.1. Interchain Transaction Payment. While a great amount of freedom and simplicity is gained through dropping the need for a holistic computation resource accounting framework like Ethereum’s gas, this does raise an important question: without gas, how does one parachain avoid another parachain from forcing it to do computation? While we can rely on transaction-post ingress queue buﬀers to prevent one chain from spamming another with transaction data, there is no equivalent mechanism provided by the protocol to prevent the spamming of transaction processing. This is a problem left to the higher level. Since chains are free to attach arbitrary semantics on to the incoming transaction-post data, we can ensure that computation must be paid-for before started. In a similar vein to the model espoused by Ethereum Serenity, we can imagine a “break-in” contract within a parachain which allows a validator to be guaranteed payment in exchange for the provision of a particular volume of processing resources. These resources may be measured in something like gas, but could also be some entirely novel model such as subjective time-to-execute or a Bitcoin-like ﬂat-fee model. On its own this isn’t so useful since we cannot readily assume that the oﬀ-chain caller has available to them whatever value mechanism is recognised by the break-in contract. However, we can imagine a secondary “breakout” contract in the source chain. The two contracts together would form a bridge, recognising each other and providing value-equivalence. (Staking-tokens, available to each, could be used to settle up the balance-of-payments.) Calling into another such chain would mean proxying through this bridge, which would provide the means of negotiating the value transfer between chains in order to pay for the computation resources required on the destination parachain. 7.2. Additional Chains. While the addition of a parachain is a relatively cheap operation, it is not free. More parachains means fewer validators per parachain and, eventually, a larger number of validators each with a reduced average bond. While the issue of a smaller coercion cost for attacking a parachain is mitigated through ﬁshermen, the growing validator set essentially forces a higher degree of latency due to the mechanics of the underlying consensus method. Furthermore each parachain brings with it the potential to grief validators with an over-burdensome validation algorithm. As such, there will be some “price” that validators and/or the stake-holding community will extract for the addition of a new parachain. This market for chains will possibly see the addition of either: • Chains that likely have zero net contribution paying (in terms of locking up or burning staking tokens) to be made a part (e.g. consortium chains, Doge-chains, app-speciﬁc chains); • chains that deliver intrinsic value to the network through adding particular functionality diﬃcult to get elsewhere (e.g. conﬁdentiality, internal scalability, service tie-ins). Essentially, the community of stakeholders will need to be incentivized to add child chains—either ﬁnancially or through the desire to add featureful chains to the relay. It is envisioned that new chains added will have a very short notice period for removal, allowing for new chains to be experimented with without any risk of compromising the medium or long-term value proposition. 8. Conclusion We have outlined a direction one may take to author a scalable, heterogeneous multi-chain protocol with the potential to be backwards compatible to certain, pre-existing blockchain networks. Under such a protocol, participants work in enlightened self-interest to create an overall system which can be extended in an exceptionally free manner and without the typical cost for existing users that comes from a standard blockchain design. We have given a rough outline of the architecture it would take including the nature of the participants, their economic incentives and the processes under which they must engage. We have identiﬁed a basic design and discussed its strengths and limitations; accordingly we have further directions which may ease those limitations and yield further ground towards a fully scalable blockchain solution.

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 19 8.1. Missing Material and Open Questions. Network forking is always a possibility from divergent implementations of the protocol. The recovery from such an exceptional condition was not discussed. Given the network will necessarily have a non-zero period of ﬁnalisation, it should not be a large issue to recover from the relaychain forking, however will require careful integration into the consensus protocol. Bond-conﬁscation and conversely reward provision has not been deeply explored. At present we assume rewards are provided under a winner-takes-all basis: this may not give the best incentivisation model for ﬁshermen. A shortperiod commit-reveal process would allow many ﬁshermen to claim the prize giving a fairer distribution of rewards, however the process could lead to additional latency in the discovery of misbehaviour. 8.2. Acknowledgments. Many thanks to all of the proof-readers who have helped get this in to a vaguely presentable shape. In particular, Peter Czaban, Bj¨orn Wagner, Ken Kappler, Robert Habermeier, Vitalik Buterin, Reto Trinkler and Jack Petersson. Thanks to all the people who have contributed ideas or the beginnings thereof, Marek Kotewicz and Aeron Buchanan deserve especial mention. And thanks to everyone else for their help along the way. All errors are my own. Portions of this work, including initial research into consensus algorithms, was funded in part by the British Government under the Innovate UK programme.

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.