Polkadot: visión para un marco heterogéneo de cadenas múltiples

Polkadot: Vision for a Heterogeneous Multi-Chain Framework

By Gavin Wood · 2016

🇺🇸 English (Original)

🇪🇸 Español (Translation)

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

Resumen

POLKADOT: VISIÓN PARA UN MARCO MULTICADENA HETEROGÉNEO BORRADOR 1 DR. MADERA GAVÍN FUNDADOR, ETHEREUM Y PARIDAD [email protected] Resumen. Todas las arquitecturas blockchain actuales sufren de una serie de problemas, entre ellos los medios prácticos de extensibilidad y escalabilidad. Creemos que esto surge de vincular dos partes muy importantes de la arquitectura del consenso, a saber canonicidad y validez, demasiado juntas. Este artículo presenta una arquitectura, la multicadena heterogénea, lo que fundamentalmente los diferencia. Al compartimentar estas dos partes y mantener la funcionalidad general proporcionada al mínimo absoluto de seguridad y transporte, introducimos medios prácticos de extensibilidad del núcleo in situ. La escalabilidad se aborda mediante un enfoque de divide y vencerás para estas dos funciones, ampliando su núcleo vinculado a través de la incentivación de Nodos públicos que no son de confianza. La naturaleza heterogénea de esta arquitectura permite que muchos tipos muy divergentes de sistemas de consenso interoperen en una “federación” totalmente descentralizada y sin confianza, lo que permite que las redes abiertas y cerradas tengan acceso libre de confianza a unos a otros. Proponemos un medio para proporcionar compatibilidad con versiones anteriores de una o más redes preexistentes, como Ethereum. Creemos que un sistema de este tipo proporciona un componente básico útil en la búsqueda general de una solución prácticamente sistema implementable capaz de alcanzar niveles de escalabilidad y privacidad de comercio global. 1. Prefacio Este pretende ser un resumen técnico de la “visión” de una posible dirección que se puede tomar para seguir desarrollando el paradigma blockchain junto con alguna justificación de por qué esta dirección es sensata. Se establece en Tantos detalles como sea posible en esta etapa de desarrollo. un sistema que puede dar una mejora concreta en un número de aspectos de la tecnología blockchain. No pretende ser una especificación, formal o de otro tipo. No pretende ser exhaustivo ni ser un diseño final. No pretende cubrir aspectos no esenciales. del marco, como API, enlaces, lenguajes y uso. Esto es notablemente experimental; donde los parámetros se especifican, es probable que cambien. Los mecanismos agregarse, refinarse y eliminarse en respuesta a las necesidades de la comunidad. ideas y críticas. Es probable que gran parte de este documento ser revisado a medida que la evidencia experimental y la creación de prototipos proporcionen información sobre qué funcionará y qué no. Este documento incluye una descripción básica del protocolo junto con ideas de direcciones que se pueden tomar. para mejorar diversos aspectos. Se prevé que el núcleo La descripción se utilizará como punto de partida para una evaluación inicial. serie de pruebas de concepto. Una “versión 1.0” final sería basado en este protocolo refinado junto con las ideas adicionales que se prueban y están decididas a implementar. necesarios para que el proyecto alcance sus objetivos. 1.1. Historia. • 10/09/2016: 0.1.0-prueba1 • 20/10/2016: 0.1.0-prueba2 • 11/01/2016: 0.1.0-prueba3 • 11/10/2016: 0.1.0 2. Introducción Las cadenas de bloques han demostrado ser muy prometedoras en cuanto a utilidad en varios campos, incluido el "Internet de las cosas". (IoT), finanzas, gobernanza, gestión de identidades, descentralización web y seguimiento de activos. Sin embargo, a pesar de la promesa tecnológica y gran charla, todavía tenemos que ver implementación significativa en el mundo real de la tecnología actual. Creemos que esto se debe a cinco fallos clave del presente pilas de tecnología: Escalabilidad: cuántos recursos se gastan globalmente sobre procesamiento, ancho de banda y almacenamiento para que el sistema procese una sola transacción y cuántas las transacciones pueden procesarse razonablemente bajo condiciones pico? Aislabilidad: ¿Pueden las necesidades divergentes de múltiples ¿Las partes y las solicitudes se abordarán en un grado casi óptimo bajo el mismo marco? Desarrollabilidad: ¿Qué tan bien funcionan las herramientas? hacer ¿Las API abordan las necesidades de los desarrolladores? ¿Hay materiales educativos disponibles? ¿Existen las integraciones adecuadas? Gobernanza: ¿Puede la red seguir siendo flexible ante ¿Evolucionar y adaptarse con el tiempo? ¿Pueden las decisiones ser hecho con suficiente inclusividad, legitimidad y transparencia para proporcionar un liderazgo efectivo de una ¿Sistema descentralizado? Aplicabilidad: ¿La tecnología realmente aborda una necesidad urgente por sí sola? ¿Se requiere otro “middleware” para cerrar la brecha con aplicaciones reales? En el presente trabajo pretendemos abordar los dos primeros Cuestiones: escalabilidad y aislabilidad. Dicho esto, creemos el marco Polkadot puede proporcionar mejoras significativas en cada una de estas clases de problemas. Implementaciones modernas y eficientes blockchain como el cliente Parity Ethereum [17] puede procesareses en exceso de 3000 transacciones por segundo cuando se ejecuta en hardware de consumo de alto rendimiento. Sin embargo, el mundo real actual Las redes blockchain están prácticamente limitadas a unas 30 transacciones por segundo. Esta limitación se origina principalmente en el hecho de que los actuales mecanismos de consenso sincrónico requieren amplios márgenes temporales de seguridad en el tiempo de procesamiento esperado, que se ve agravado por el 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.

Introducción

Las cadenas de bloques han demostrado ser muy prometedoras en cuanto a utilidad en varios campos, incluido el "Internet de las cosas". (IoT), finanzas, gobernanza, gestión de identidades, descentralización web y seguimiento de activos. Sin embargo, a pesar de la promesa tecnológica y gran charla, todavía tenemos que ver implementación significativa en el mundo real de la tecnología actual. Creemos que esto se debe a cinco fallos clave del presente pilas de tecnología: Escalabilidad: cuántos recursos se gastan globalmente sobre procesamiento, ancho de banda y almacenamiento para que el sistema procese una sola transacción y cuántas las transacciones pueden procesarse razonablemente bajo condiciones pico? Aislabilidad: ¿Pueden las necesidades divergentes de múltiples ¿Las partes y las solicitudes se abordarán en un grado casi óptimo bajo el mismo marco? Desarrollabilidad: ¿Qué tan bien funcionan las herramientas? hacer ¿Las API abordan las necesidades de los desarrolladores? ¿Hay materiales educativos disponibles? ¿Existen las integraciones adecuadas? Gobernanza: ¿Puede la red seguir siendo flexible ante ¿Evolucionar y adaptarse con el tiempo? ¿Pueden las decisiones ser hecho con suficiente inclusividad, legitimidad y transparencia para proporcionar un liderazgo efectivo de una ¿Sistema descentralizado? Aplicabilidad: ¿La tecnología realmente aborda una necesidad urgente por sí sola? ¿Se requiere otro “middleware” para cerrar la brecha con aplicaciones reales? En el presente trabajo pretendemos abordar los dos primeros Cuestiones: escalabilidad y aislabilidad. Dicho esto, creemos el marco Polkadot puede proporcionar mejoras significativas en cada una de estas clases de problemas. Implementaciones modernas y eficientes blockchain como el cliente Parity Ethereum [17] puede procesar más de 3000 transacciones por segundo cuando se ejecuta en hardware de consumo de alto rendimiento. Sin embargo, el mundo real actual Las redes blockchain están prácticamente limitadas a unas 30 transacciones por segundo. Esta limitación se origina principalmente en el hecho de que los actuales mecanismos de consenso sincrónico requieren amplios márgenes temporales de seguridad en el tiempo de procesamiento esperado, que se ve agravado por elPOLKADOT: VISIÓN PARA UN MARCO MULTICADENA HETEROGÉNEO BORRADOR 1 2 deseo de soportar implementaciones más lentas. Esto se debe a la arquitectura de consenso subyacente: el mecanismo de transición estatal, o los medios por los cuales los partidos cotejan y ejecutar transacciones, tiene su lógica fundamentalmente ligada en el mecanismo de “canonicalización” por consenso, o el Medio por el cual las partes acuerdan uno de varios historias posibles y válidas. Esto se aplica igualmente a los sistemas proof-of-work (PoW) como Bitcoin [15] y Ethereum [5,23] y a los sistemas de prueba de participación (PoS) como NXT [8] y Bitshares [12]: En última instancia, todos sufren la misma desventaja. es un sencillo estrategia que ayudó a que blockchains fuera un éxito. Sin embargo, acoplando firmemente estos dos mecanismos en una sola unidad del protocolo, también agrupamos múltiples diferentes actores y aplicaciones con diferentes perfiles de riesgo, diferentes requisitos de escalabilidad y diferentes necesidades de privacidad. Una talla única no sirve para todos. Con demasiada frecuencia ocurre que en un deseo de un amplio atractivo, una red adopta un grado de conservadurismo que resulta en un mínimo común denominador. servir de manera óptima a unos pocos y, en última instancia, conducir a un fracaso en la capacidad de innovar, actuar y adaptarse, a veces dramáticamente. Algunos sistemas como p.e. Factom [21] elimina por completo el mecanismo de transición de estado. Sin embargo, gran parte de los La utilidad que deseamos requiere la capacidad de cambiar de estado. según una máquina de estados compartida. Soltándolo se resuelve un problema alternativo; no proporciona una alternativa solución. Por lo tanto, parece claro que una dirección razonable explorar como una ruta hacia una computación descentralizada escalable plataforma es desacoplar la arquitectura de consenso de el mecanismo de transición estatal. Y, tal vez como era de esperar, esta es la estrategia que adopta Polkadot como solución a la escalabilidad. 2.1. Protocolo, Implementación y Red. Me gusta Bitcoin y Ethereum, Polkadot se refiere a la vez a un protocolo de red y al protocolo primario (hasta ahora presupuesto) red pública que ejecuta este protocolo. Polkadot pretende ser un proyecto gratuito y abierto, la especificación del protocolo está bajo una licencia Creative Commons y el el código se coloca bajo una licencia FLOSS. El proyecto es desarrollado de manera abierta y acepta contribuciones dondequiera que sean útiles. Un sistema de RFC, no muy diferente las propuestas de mejora de Python, permitirán un medio de colaborar públicamente en cambios y actualizaciones de protocolos. Nuestra implementación inicial del protocolo Polkadot se conocerá como Plataforma Parity Polkadot y se incluir una implementación de protocolo completa junto con API fijaciones. Al igual que otras implementaciones de Parity blockchain, PPP está diseñado para ser una pila de tecnología blockchain de uso general, no exclusivamente para una red pública ni para operación privada/consorcio. El desarrollo del mismo así hasta ahora ha sido financiado por varios partidos, incluso a través de una subvención del gobierno británico. No obstante, este documento describe Polkadot bajo el contexto de una red pública. La funcionalidad que imaginamos en una red pública es un superconjunto de la requerida en entornos alternativos (por ejemplo, privados y/o consorcios). Además, en este contexto, el alcance completo de Polkadot puede ser descritos y discutidos más claramente. Esto significa El lector debe ser consciente de que ciertos mecanismos pueden describirse (por ejemplo, interoperación con otras redes públicas) que no sean directamente relevantes para Polkadot cuando se implementa en situaciones no públicas (“permitidas”). 2.2. Trabajo anterior. Se ha propuesto informalmente desvincular el consenso subyacente de la transición estatal en privado durante al menos dos años: Max Kaye fue un defensor de tal estrategia durante los primeros días de Ethereum. Una solución escalable más compleja conocida como Chain fibras, que se remonta a junio de 2014 y se publicó por primera vez más tarde ese año1, defendió una única cadena de relés y múltiples cadenas homogéneas que proporcionaran un mecanismo de ejecución transparente entre cadenas. La decoherencia fue pagada a través de la latencia de transacciones: transacciones que requieren la La coordinación de porciones dispares del sistema tomar más tiempo para procesar. Polkadot toma gran parte de su arquitectura de eso y de las conversaciones de seguimiento con varias personas, aunque difiere mucho en gran parte de su diseño y prestaciones. Si bien no existen sistemas comparables a Polkadot actualmente en producción, varios sistemas de cierta relevancia Se han propuesto, aunque pocos en un nivel sustancial de detalle. Estas propuestas pueden serdividido en sistemas que abandonan o reducen la noción de un mundo globalmente coherente. máquina de estados, aquellas que intentan proporcionar una máquina singleton coherente a través de fragmentos homogéneos y aquellos que apuntan únicamente a la heterogeneidad. 2.2.1. Sistemas sin Estado Global. Factom [21] es un sistema que demuestra canonicidad sin el acuerdo validez, permitiendo efectivamente la crónica de los datos. Debido a la evitación del estado global y las dificultades Con la escala que esto trae, se puede considerar una solución escalable. Sin embargo, como se mencionó anteriormente, el conjunto de problemas que resuelve es estricta y sustancialmente menor. Tangle [18] es un enfoque novedoso para los sistemas de consenso. En lugar de organizar las transacciones en bloques y formar consenso sobre una lista estrictamente vinculada para dar un orden canónico global de los cambios de estado, abandona en gran medida la idea de un ordenamiento fuertemente estructurado y en su lugar impulsa un gráfico acíclico dirigido de transacciones dependientes con elementos posteriores que ayuden a canonicalizar elementos anteriores mediante referencias explícitas. Para cambios de estado arbitrarios, este gráfico de dependencia rápidamente se volvería intratable, sin embargo, para el modelo UTXO2 mucho más simple, esto se convierte en bastante razonable. Debido a que el sistema sólo es vagamente coherente y las transacciones son generalmente independientes entre sí Por otra parte, una gran cantidad de paralelismo global se vuelve bastante naturales. Usar el modelo UTXO tiene el efecto de limitar Tangle a una “moneda” puramente de transferencia de valor sistema en lugar de algo más general o extensible. Además, sin la estricta coherencia global, la interacción con otros sistemas (que tienden a necesitar un control absoluto) Un grado de conocimiento sobre el estado del sistema se vuelve poco práctico. 1https://github.com/ethereum/wiki/wiki/Chain-Fibers-Redux 2salida de transacción no gastada, el modelo que utiliza Bitcoin mediante el cual el estado es efectivamente el conjunto de direcciones asociadas con algún valor; Las transacciones recopilan dichas direcciones y las transforman en un nuevo conjunto de direcciones cuya suma total es equivalente.

POLKADOT: VISIÓN PARA UN MARCO MULTICADENA HETEROGÉNEO BORRADOR 1 3 2.2.2. Sistemas de cadenas heterogéneas. Las cadenas laterales [3] son una adición propuesta al protocolo Bitcoin que permitiría una interacción sin confianza entre la cadena principal Bitcoin y cadenas laterales adicionales. No hay ninguna disposición para ningún grado de interacción "rica" entre cadenas laterales: la interacción se limitaría a permitir que las cadenas laterales se custodios de los activos de cada uno, efectuando, en el ámbito local, jerga: una vinculación bidireccional 3. La visión final es la de un marco en el que la moneda Bitcoin pueda recibir funcionalidad adicional, si es periférica, mediante su vinculación en algunas otras cadenas con transición de estado más exótica sistemas que los que permite el protocolo Bitcoin. En este sentido, las cadenas laterales abordan la extensibilidad en lugar de la escalabilidad. De hecho, fundamentalmente no existe ninguna disposición sobre la validez de las cadenas laterales; tokens de una cadena (por ejemplo, Bitcoin) mantenidos en nombre de una cadena lateral están asegurados sólo por el la capacidad de la cadena lateral para incentivar a los mineros a canonicalizar transiciones válidas. La seguridad de la red Bitcoin no se puede hacer fácilmente la transición para trabajar en nombre de otros blockchains. Además, un protocolo para garantizar Bitcoin los mineros fusionan la mina (es decir, duplican su poder de canonicalización en el de la cadena lateral) y, lo que es más importante, validan que las transiciones de la cadena lateral estén fuera del alcance de esta propuesta. Cosmos [10] es un sistema multicadena propuesto en el Lo mismo que las cadenas laterales, intercambiando el PoW de Nakamoto. Método de consenso para el algoritmo Tendermint de Jae Kwon. Esencialmente, describe múltiples cadenas (que operan en zonas) cada una utilizando instancias individuales de Tendermint, junto con un medio para la comunicación libre de confianza a través de un cadena del cubo maestro. Esta comunicación entre cadenas se limita a la transferencia de activos digitales ("específicamente acerca de tokens") en lugar de información arbitraria; sin embargo, dicha comunicación entre cadenas tiene una ruta de retorno para los datos. por ej. informar al remitente sobre el estado de la transferencia. Conjuntos de validadores para las cadenas zonificadas y, en particular, los medios para incentivarlos, quedan, como cadenas laterales, como un problema no resuelto. La suposición general es que cada cadena zonificada tendrá un token de valor cuya inflación se utiliza para pagar validators. Aún en las primeras etapas de diseño, en la actualidad la propuesta carece de detalles completos sobre los medios económicos para lograr el escalable certeza sobre la validez global. Sin embargo, la escasa coherencia requerida entre las zonas y el centro permitirá para mayor flexibilidad sobre los parámetros de la zona cadenas en comparación con la de un sistema que impone medidas más estrictas. coherencia. 2.2.3. Casper. Hasta el momento no hay una revisión exhaustiva ni una comparación lado a lado entre Casper [6] y Polkadot Se han hecho, aunque se puede hacer un análisis bastante amplio. (y en consecuencia inexacta) caracterización de los dos. Casper es una reinvención de cómo funciona un algoritmo de consenso PoS podría basarse en que los participantes apuesten en qué bifurcación finalmente se volvería canónico. Se prestó especial atención a garantizar que fuera robusto para la red. se bifurca, incluso cuando es prolongado, y tiene cierto grado adicional de escalabilidad además del modelo básico Ethereum. como Casper hasta la fecha ha tendido a ser un personaje sustancialmente más protocolo más complejo que Polkadot y sus antepasados, y un desviación sustancial del formato básico blockchain. eso Aún no se sabe cómo repetirá Casper en el futuro. y cómo se verá si finalmente se implementa. Si bien Casper y Polkadot representan nuevos protocolos interesantes y, en cierto sentido, aumentos de Ethereum, existen diferencias sustanciales entre sus objetivos finales y caminos hacia el despliegue. Casper es un Ethereum Proyecto centrado en la cimentación diseñado originalmente ser una alteración de PoS al protocolo sin deseo de cree un blockchain fundamentalmente escalable. Fundamentalmente, es diseñado para ser un hard-fork, en lugar de algo más expansivo y, por lo tanto, todos los Ethereum clientes y usuarios serían requerido actualizar o permanecer en una bifurcación de adopción incierta. Como tal, el despliegue se hace sustancialmente más difícil, como es inherente a un proyecto descentralizado donde es necesaria la coordinación. Polkadot difiere en varios aspectos; ante todo, Polkadot está diseñado para ser totalmente extensible y escalable. blockchain prueba de desarrollo, implementación e interacción cama. Está diseñado para ser un arnés en gran medida preparado para el futuro, capaz de asimilar nuevo blockchaintecnología a medida que esté disponible sin una coordinación descentralizada demasiado complicada o bifurcaciones duras. Ya imaginamos varios casos de uso como como cadenas de consorcio cifradas y cadenas de alta frecuencia con tiempos de bloqueo muy bajos que no son realistas de hacer en cualquier versión futura de Ethereum actualmente prevista. Finalmente, el acoplamiento entre él y Ethereum es extremadamente suelto; no es necesaria ninguna acción por parte de Ethereum para permitir el reenvío de transacciones sin confianza entre los dos redes. En resumen, mientras Casper/Ethereum 2.0 y Polkadot comparten algunas similitudes fugaces, creemos que su objetivo final es sustancialmente diferente y que en lugar de competir, Es probable que en última instancia los dos protocolos coexistan bajo un relación mutuamente beneficiosa en el futuro previsible.

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.

Resumen

Polkadot es una multicadena heterogénea escalable. esto significa que a diferencia de implementaciones anteriores blockchain que se han centrado en proporcionar una única cadena de diferentes grados de generalidad sobre aplicaciones potenciales, Polkadot en sí está diseñado para no proporcionar ninguna funcionalidad inherente a la aplicación. Más bien, Polkadot proporciona la base “cadena de relevos” sobre la cual un gran número de datos validables, Se pueden alojar estructuras de datos dinámicas globalmente coherentes. lado a lado. A estas estructuras de datos las llamamos "paralelizadas". cadenas o paracaídas, aunque no hay una necesidad específica de son blockchain de naturaleza. En otras palabras, Polkadot puede considerarse equivalente a un conjunto de cadenas independientes (por ejemplo, el conjunto que contiene Ethereum, Ethereum Classic, Namecoin y Bitcoin) excepto dos puntos muy importantes: • Seguridad mancomunada; • Transacciones entre cadenas sin confianza. Estos puntos son el motivo por el que consideramos que Polkadot es "escalable". En principio, un problema que se implementará en Polkadot se puede paralelizar sustancialmente (ampliarse) a lo largo de una gran cantidad de paracaídas. Dado que todos los aspectos de cada Parachain puede ser conducido en paralelo por un segmento diferente de la red Polkadot, el sistema tiene cierta capacidad a escala. Polkadot proporciona una pieza bastante básica de 3a diferencia de una vinculación unidireccional que es esencialmente la acción de destruir tokens en una cadena para crear tokens en otra sin el mecanismo para hacer lo contrario para recuperar los tokens originalesPOLKADOT: VISIÓN PARA UN MARCO MULTICADENA HETEROGÉNEO BORRADOR 1 4 infraestructura, dejando que gran parte de la complejidad se aborde en el nivel de middleware. Se trata de una decisión consciente destinada a reducir el riesgo de desarrollo, permitiendo a la Software necesario que debe desarrollarse en un corto período de tiempo. y con un buen nivel de confianza sobre su seguridad y robustez. 3.1. La Filosofía de Polkadot. Polkadot debería proporcionar una base absoluta y sólida sobre la cual construir la próxima ola de sistemas de consenso, a través de El espectro de riesgos de los diseños maduros con capacidad de producción. a las ideas nacientes. Al proporcionar sólidas garantías de seguridad, aislamiento y comunicación, Polkadot puede permitir paracaídas para seleccionar entre una variedad de propiedades. De hecho, prevemos varios blockchains experimentales que impulsan las propiedades de lo que podría considerarse sensato. hoy. Nos vemos conservadores, cadenas de alto valor similares a Bitcoin o Z-cash [20] coexistiendo con valores de menor valor “cadenas temáticas” (qué marketing, tan divertido) y redes de prueba con tarifas cero o casi cero. Vemos completamente encriptado, cadenas de consorcios “oscuras” que operan paralelamente (e incluso Proporcionar servicios a cadenas abiertas y altamente funcionales. como aquellos como Ethereum. Vemos novedades experimentales. Cadenas basadas en VM, como un wasm subjetivo cargado de tiempo La cadena se utiliza como un medio para subcontratar problemas informáticos difíciles de una cadena más madura similar a Ethereum. o una cadena más restringida tipo Bitcoin. Para gestionar las actualizaciones de la cadena, Polkadot inherentemente apoyar algún tipo de estructura de gobernanza, probablemente basada sobre los sistemas políticos estables existentes y que tiene un aspecto bicameral similar al Consejo del Libro Amarillo [24]. como la autoridad última, los tenedores subyacentes de token tendrían el control del “referéndum”. Para reflejar la opinión de los usuarios. necesidad de desarrollo sino la necesidad de legitimidad de los desarrolladores, esperamos que una dirección razonable sería formar las dos cámaras de un comité de “usuarios” (compuesto por bonded validators) y un comité “técnico” formado de los principales desarrolladores de clientes y actores del ecosistema. el El cuerpo de titulares de token mantendría la legitimidad última y formaría una supermayoría para aumentar, reparar, reemplazar o disolver esta estructura, algo que No dudes de la eventual necesidad de: en palabras de Twain. “Los gobiernos y los pañales deben cambiarse con frecuencia, y por la misma razón”. Mientras que la reparametrización suele ser trivial de organizar dentro de un mecanismo de consenso más amplio, cambios más cualitativos como el reemplazo y el aumento serían necesarios. probablemente deban ser “decretos blandos” no automatizados (p. ej. mediante la canonicalización de un número de bloque y la hash de un documento que especifica formalmente el nuevo protocolo) o necesitar que el mecanismo central de consenso contenga un lenguaje suficientemente rico para describir cualquier aspecto de sí mismo que puede necesitar cambiar. Este último es un objetivo eventual, sin embargo, es más probable que se elija el primero para facilitar un cronograma de desarrollo razonable. Los principios principales de Polkadot y las reglas dentro de las cuales evaluamos todas las decisiones de diseño son: Mínimo: Polkadot debe tener la menor funcionalidad posible. Simple: no debe haber ninguna complejidad adicional en el protocolo base de lo que razonablemente puede ser descargado en middleware, colocado a través de un parachain o introducido en una optimización posterior. General: sin requisitos innecesarios, restricciones o se debe imponer una limitación a las paracaídas; Polkadot debería ser un banco de pruebas para el desarrollo de sistemas de consenso que pueda optimizarse a través de hacer que el modelo en el que encajan las extensiones sea lo más abstracto posible. Robusto: Polkadot debería proporcionar una base fundamentalmente capa base estable. Además de la solidez económica, esto también significa descentralizar para minimizar los vectores de 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.

Participación en Polkadot

Hay cuatro funciones básicas en el mantenimiento de un Polkadot red: recopilador, pescador, nominador y validator. en una posible implementación de Polkadot, este último rol en realidad, puede dividirse en dos roles: básico validator y garante de disponibilidad; esto se discute en la sección 6.5.3. alzador pescador Validadores (este grupo) Validadores (otros grupos) aprueba se convierte monitores informes malo comportamiento hacia proporciona bloque candidatos para Nominador Figura 1. La interacción entre los cuatro roles de Polkadot. 4.1. Validadores. Un validator es el cargo más alto y ayuda a sellar nuevos bloques en la red Polkadot. El papel del validator depende de un vínculo suficientemente alto siendo depositado, aunque permitimos que otras partes vinculadas nominar a uno o más validators para que actúen en su nombre y como tal parte del bono de validator no necesariamente puede ser propiedad del validator mismo sino de estos nominadores. Un validator debe ejecutar una implementación de cliente de cadena de retransmisión con alta disponibilidad y ancho de banda. en cada bloque El nodo debe estar preparado para aceptar el papel de ratificador. un nuevo bloque en una parachain nominada. este proceso Implica recibir, validar y republicar el candidato. bloques. La nominación es determinista pero prácticamente impredecible con mucha antelación. Dado que el validator no puede Se puede esperar razonablemente que mantenga un sistema totalmente sincronizado. base de datos de todas las paracaídas, se espera que validator designe la tarea de diseñar una nueva sugerencia bloque de parachain a un tercero, conocido como alzador. Una vez que todos los nuevos bloques de parachain hayan sido ratificados adecuadamente por sus subgrupos validator designados, validators entonces debe ratificar el propio bloque de la cadena de relevos. Esto implica actualizar el estado de las colas de transacciones (esencialmente mover datos de la cola de salida de una parachain a otra cola de entrada de parachain), procesando las transacciones de el conjunto de transacciones de cadena de retransmisión ratificado y la ratificación del bloque final, incluidos los cambios finales de parachain.POLKADOT: VISIÓN PARA UN MARCO MULTICADENA HETEROGÉNEO BORRADOR 1 5 Un validator que no cumple con su deber de encontrar consenso bajo las reglas de nuestro algoritmo de consenso elegido es castigado. En el caso de fallos iniciales involuntarios, esto se realiza mediante retener la recompensa del validator. Los fallos repetidos resultan en la reducción de su vínculo de seguridad (mediante la quema). Acciones demostrablemente maliciosas como doble firma o conspirar para proporcionar un bloque no válido resultará en la pérdida de todo el bono (que está parcialmente quemado pero en su mayor parte dado al informante y a los actores honestos). En cierto sentido, los validators son similares a los pools de minería. de PoW actuales blockchains. 4.2. Nominadores. Un nominador es una parte interesada quien aporta a la fianza de seguridad de un validator. ellos no tienen ningún papel adicional excepto el de colocar capital de riesgo y como tal para indicar que confían en un validator en particular (o conjunto de los mismos) para actuar responsablemente en el mantenimiento de la red. Reciben un aumento o reducción prorrateada en su depósito según el crecimiento del bono al que ellos contribuyen. Junto con los cotejadores, a continuación, los nominadores están en algunos sentido similar a los mineros de las redes PoW actuales. 4.3. Alzadoras. Clasificadores de transacciones (alzadores para abreviar) son partes que ayudan a validators a producir documentos válidos bloques de paracaídas. Mantienen un "nodo completo" para una paracadena en particular; lo que significa que conservan todo lo necesario información para poder crear nuevos bloques y ejecutar transacciones de la misma manera que lo hacen los mineros en los PoW actuales blockchains. En circunstancias normales, ellos cotejará y ejecutará transacciones para crear un documento no sellado bloquear y proporcionarlo, junto con un conocimiento cero prueba, a uno o más validators actualmente responsables de proponiendo un bloque de parachain. La naturaleza precisa de la relación entre recopiladores, nominadores y validators probablemente cambiará con el tiempo. tiempo. Inicialmente, esperamos que los alzapadores trabajen muy estrechamente con validators, ya que solo habrá unos pocos (quizás solo uno) parachain(s) con poco volumen de transacciones. el La implementación inicial del cliente incluirá RPC para permitir una nodo intercalador de parachain para suministrar incondicionalmente un nodo (cadena de retransmisión) validator con un parachain demostrablemente válido bloque. Como el costo de mantener una versión sincronizada de Todos estos aumentos de paracaídas, esperamos ver más infraestructura existente que ayudará a separar los deberes a partidos independientes y motivados económicamente. Con el tiempo, esperamos ver grupos de clasificadores que compitan por cobrar la mayor cantidad de tarifas de transacción. Dichos recopiladores pueden ser contratados para prestar servicios a validator particulares durante un período de tiempo para obtener una participación continua en los ingresos de la recompensa. Alternativamente, los recopiladores “independientes” pueden simplemente crear un mercado que ofrece bloques de parachain válidos a cambio de una parte competitiva de la recompensa pagadera de inmediato. De manera similar, los grupos de nominadores descentralizados permitirían múltiples participantes vinculados para coordinar y compartir el deber de un validator. Esta capacidad de agruparse garantiza una participación abierta. conducente a un sistema más descentralizado. 4.4. Pescadores. A diferencia de los otros dos partidos activos, Los pescadores no están directamente relacionados con la autoría del bloque. proceso. Más bien son “cazarrecompensas” independientes. motivado por una gran recompensa única. Precisamente debido a En la existencia de pescadores, esperamos que los eventos de mala conducta ocurran raramente, y cuando suceden sólo debido a la parte vinculada es descuidada con la seguridad de la clave secreta, en lugar de hacerlo con intenciones maliciosas. el nombre viene desde la frecuencia esperada de la recompensa, los requisitos mínimos para participar y el tamaño final de la recompensa. Los pescadores obtienen su recompensa al demostrar oportunamente que al menos una parte vinculada actuó ilegalmente. Acciones ilegales incluir firmar dos bloques cada uno con el mismo padre ratificado o, en el caso de paracaídas, ayudar a ratificar un bloque no válido bloque. Para evitar recompensas excesivas o el compromiso y uso ilícito de la clave secreta de una sesión, la recompensa base por proporcionar un único mensaje firmado ilegalmente por validator es mínimo. Esta recompensa aumenta asintóticamente cuanto más corroborar firmas ilegales de otros validators son proporcionado implicando un ataque genuino. La asíntota está establecida al 66% siguiendo nuestra afirmación de seguridad básica de que al menos dos tercios de los validators actúan con benevolencia. Los pescadores son algo similares a los "nodos completos" en sistemas actuales blockchain que los recursos necesarios son relativamente pequeños y el compromiso de un tiempo de actividad estable y el ancho de banda no es necesario. Los pescadores se diferencian en tanto como deben pagar una pequeña fianza.Este vínculo evita Los ataques de Sybil hacen perder el tiempo y el cálculo de validators recursos. Se puede retirar inmediatamente, probablemente no. más que el equivalente de unos pocos dólares y puede llevar a obtener una gran recompensa al detectar un mal comportamiento 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.

Descripción general del diseño

Esta sección tiene como objetivo dar una breve descripción general de la sistema en su conjunto. Una exploración más profunda de la El sistema se proporciona en la sección siguiente. 5.1. Consenso. En la cadena de relés, Polkadot logra consenso de bajo nivel sobre un conjunto de acuerdos válidos mutuamente acordados. bloques a través de un moderno algoritmo asincrónico bizantino tolerante a fallas (BFT). El algoritmo se inspirará. por el simple Tendermint [11] y el sustancialmente más involucrado HoneyBadgerBFT [14]. Este último proporciona una consenso eficiente y tolerante a fallos sobre una solución arbitrariamente infraestructura de red defectuosa, dado un conjunto de autoridades en su mayoría benignas o validators. Para una red de estilo prueba de autoridad (PoA), esto solo sería suficiente, sin embargo, se imagina que Polkadot es También se puede implementar como red en un entorno totalmente abierto y público. situación sin ninguna organización particular o confianza autoridad requerida para mantenerlo. Como tal necesitamos un medios para determinar un conjunto de validators e incentivar ellos para ser honestos. Para esto utilizamos la selección basada en PoS. criterios. 5.2. Demostrando lo que está en juego. Suponemos que la red tendrá algún medio para medir cuánta “participación” cualquier cuenta en particular tiene. Para facilitar la comparación con sistemas preexistentes, llamaremos a la unidad de medida “tokens”. Desafortunadamente el término no es ideal para una varias razones, entre ellas la de ser simplemente un escalar valor asociado con una cuenta, no existe noción de individualidad. Imaginamos que validators serán elegidos, con poca frecuencia (como máximo una vez al día, pero quizás tan raramente como una vez por trimestre), a través de un esquema de Prueba de Participación Nominada (NPoS). La incentivación puede ocurrir a través de una asignación prorrateada dePOLKADOT: VISIÓN PARA UN MARCO MULTICADENA HETEROGÉNEO BORRADOR 1 6 Relevo cadena enjambre de validadores (cada uno coloreado por su paracadena designada) Transacción (presentado por actor externo) Paracadena puente paracaídas virtual (por ejemplo, Ethereum) Paracadena Paracadena colas y E/S Transacciones propagadas Bloquear el envío de candidatos 2do orden cadena de relevo Comunidad paracadena cuenta Transacción entrante Transacción saliente Transacciones entre cadenas (gestionado por validators) alzador bloque propagado pescador Figura 2. Un esquema resumido del sistema Polkadot. Esto muestra a los recopiladores recopilando y propagando transacciones de usuarios, así como propagando candidatos de bloque a pescadores y validators. También muestra cómo una cuenta puede registrar una transacción que se lleva a cabo desde su paracadena, a través de la cadena de retransmisión y luego a otra parachain donde puede interpretarse como una transacción a una cuenta allí. fondos provenientes de una expansión de base token (hasta 100% por año, aunque lo más probable es que sea alrededor del 10%), junto con cualquier tarifa de transacción cobrada. Si bien la expansión de la base monetaria generalmente conduce a la inflación, dado que todos los propietarios de token tendría una oportunidad justa de participación, ningún titular de token necesitaría sufrir una reducción en el valor de su tenencias a lo largo del tiempo siempre que estuvieran felices de tomar una papel en el mecanismo de consenso. una proporción particular de tokens serían objeto del proceso staking; el La expansión base efectiva token se ajustaría a través de un mecanismo basado en el mercado para alcanzar este objetivo. Los validadores están fuertemente unidos por sus intereses; saliendo Los bonos de validators permanecen vigentes mucho después de que cesen las funciones de los validators (quizás alrededor de 3 meses). este tiempo El período de liquidación de bonos permite que futuras malas conductas sean castigados hasta el control periódico de la cadena. La mala conducta da lugar a castigos, como la reducción de recompensa o, en los casos que comprometan intencionalmente la integridad de la red, el validator pierde parte o la totalidad de su participación a otros validators, informantes o partes interesadas en su conjunto (mediante la quema). Por ejemplo, un validator quien intenta ratificar ambas ramas de una bifurcación (a veces conocido como ataque de “corto alcance”) puede ser identiﬁcado y castigado de esta última manera. Los ataques de largo alcance en los que “no hay nada en juego”4 se evitan mediante un simple pestillo de “punto de control” que evita una peligrosa reorganización en cadena de más de un profundidad de cadena particular. Para garantizar que los clientes recién sincronizados no se dejan engañar por la cadena equivocada, regular Se producirán “bifurcaciones duras” (de como máximo el mismo período del liquidación de bonos de validators) que codifica el bloque de puntos de control reciente hashes en los clientes. Esto funciona bien con una medida adicional para reducir la huella de “longitud de cadena finita” o reinicio periódico del bloque génesis. 5.3. Paracaídas y Alzadores. Cada paracadena obtiene Medidas de seguridad similares a las de la cadena de relevos: el Los encabezados de las paracaídas están sellados dentro del bloque de la cadena de relés. garantizar que no sea posible ninguna reorganización o “doble gasto” después de la conﬁrmación. Esta es una garantía de seguridad similar a la que ofrecen las cadenas laterales y la fusión de Bitcoin. Polkadot, sin embargo, también ofrece sólidas garantías de que las transiciones de estado de las paracaídas son válidas. esto ocurre cuando el conjunto de validators se segmenta criptográficamente de forma aleatoria en subconjuntos; un subconjunto por parachain, los subconjuntos potencialmente difieren por bloque. esto La configuración generalmente implica que los tiempos de bloqueo de las paracaídas serán ser al menos tan largo como el de la cadena de relés. El específico Los medios para determinar la partición están fuera del alcance. 4En tal ataque el adversario forja una cadena histórica completamente nueva desde el bloque génesis en adelante. A través del control de un porción relativamente insignificante de la participación en la compensación, son capaces de aumentar incrementalmente su porción de la participación en relación con todos los demás partes interesadas ya que son los únicos participantes activos en su historia alternativa. Dado que no existe ninguna limitación física intrínseca a la creación de bloques (a diferencia de PoW, donde se debe gastar energía computacional bastante real), son capaces de crear una cadena más larga que la cadena real en un período de tiempo relativamente corto y potencialmente convertirlo en el mejor y más largo, asumiendo el estado canónico de la red.POLKADOT: VISIÓN PARA UN MARCO MULTICADENA HETEROGÉNEO BORRADOR 1 7 de este documento, pero probablemente se basaría en torno a un marco de confirmación-revelación similar a RanDAO [19] o utilizar datos combinados de bloques anteriores de cada parachain bajo un hash criptográficamente seguro. Dichos subconjuntos de validators deben proporcionar una candidato de bloque de parachain que está garantizado como válido (en pena de confiscación de la fianza). La validez gira en torno a dos puntos importantes; En primer lugar, que es intrínsecamente válido: que todas las transiciones estatales se ejecutaron fielmente y que todas Los datos externos a los que se hace referencia (es decir, transacciones) son válidos para su inclusión. En segundo lugar, que cualquier dato que sea extrínseco a su candidato, como aquellas transacciones externas, tiene una disponibilidad suficientemente alta para que los participantes puedan descárgalo y ejecuta el bloque manualmente.5 Los validadores pueden proporcionar sólo un bloque "nulo" que no contenga datos de "transacciones" externas, pero pueden correr el riesgo de obtener una recompensa reducida si lo hacen. ellos trabajan junto un protocolo de chismes de parachain con recopiladores: individuos que recopilan transacciones en bloques y proporcionan una prueba no interactiva y sin conocimiento de que el bloque constituye un hijo válido de su padre (y toman cualquier transacción honorarios por sus problemas). Queda en manos de los protocolos parachain especificar los suyos propios. Medios de prevención de spam: no existe una noción fundamental de “medición de recursos informáticos” o “tarifa de transacción”. impuesto por la cadena de relevos. Tampoco existe una aplicación directa de esto por parte del protocolo de cadena de retransmisión (aunque Es poco probable que las partes interesadas decidan adoptar una paracadena que no proporcionaba un mecanismo decente). Este es un guiño explícito a la posibilidad de que existan cadenas a diferencia de Ethereum, p.ej. una cadena similar a Bitcoin que tiene un modelo de tarifas mucho más simple o algún otro modelo de prevención de spam aún por proponer. La propia cadena de relés de Polkadot probablemente existirá como un Cadena de estados y cuentas similares a Ethereum, posiblemente un derivado EVM. Dado que los nodos de la cadena de retransmisión deberán realizar otros procesamientos sustanciales, rendimiento de transacciones se minimizará en parte a través de altas tarifas de transacción y, si nuestros modelos de investigación lo requieren, un límite de tamaño de bloque. 5.4. Comunicación entre cadenas. El ingrediente final crítico de Polkadot es la comunicación entre cadenas. desde las paracaídas pueden tener algún tipo de canal de información entre ellas, nos permitimos considerar Polkadot un multicadena escalable. En el caso de Polkadot, la comunicación es tan simple como puede ser: transacciones que se ejecutan en un parachain son (de acuerdo con la lógica de esa cadena) capaces de efectuar el envío de una transacción a una segunda paracadena o, potencialmente, la cadena de relevos. Como transacciones externas en producción blockchains, son completamente asíncronos y no tienen la capacidad intrínseca de devolver nada tipo de información hasta su origen. Destino: consigue datos de antes validators del bloque. La cuenta recibe la publicación: entrada eliminada de ingreso Merkle tree La cuenta envía la publicación: entrada colocada en salida Merkle tree para destino paracaídas salida Fuente: acciones datos con el siguiente bloque validators prueba de envío almacenada en salida de parachain Merkle árbol referencia enrutada colocada en destino parachain ingreso Merkle tree ingreso Figura 3. Un esquema básico que muestra las partes principales del enrutamiento para publicados transacciones (“publicaciones”). Para garantizar una complejidad mínima de implementación, se requiere un mínimo riesgo y mínimo camisa de fuerza de futuro arquitecturas parachain, estas transacciones entre cadenas son efectivamente indistinguibles de las transacciones estándar firmadas externamente. La transacción tiene un segmento de origen, que brinda la capacidad de identificar una paracadena, y una dirección que puede ser de tamaño arbitrario. A diferencia de los sistemas actuales comunes como Bitcoin y Ethereum, las transacciones entre cadenas no vienen con ningún tipo de “pago” de tarifa asociado; Cualquier pago de este tipo debe gestionarse mediante la lógica de negociación en las paracadenas de origen y destino. Un sistema como el propuesto para La versión Serenity de Ethereum [7] sería un medio simple de gestionar dicho pago de recursos entre cadenas, aunque suponemos que otros pueden pasar a primer plano a su debido tiempo. Las transacciones entre cadenas se resuelven mediante un simple Mecanismo de cola basado en Merkle tree para garantizar fidelidad. Es tarea de los mantenedores de la cadena de relevos mover transacciones en la cola de salida de una parachain en la cola de entrada de la parachain de destino. el Las transacciones pasadas se hacen referencia en la cadena de retransmisión, sin embargo, no son relevantes.las propias transacciones de la cadena ay. Para evitar que una parachain envíe spam a otra parachain con transacciones, para que se envíe una transacción, se requiere que la cola de entrada del destino no sea demasiado grande en la hora del final del bloque anterior. Si la entrada La cola es demasiado grande después del procesamiento del bloque, entonces se considera "saturada" y no se pueden enrutar transacciones a ella. dentro de los bloques siguientes hasta que se reduzca nuevamente por debajo del límite. Estas colas se administran en la cadena de retransmisión. Permitir que las paracaídas determinen la saturación de cada una. estado; de esta manera un intento fallido de publicar una transacción a un destino detenido se puede informar de forma sincrónica. (Aunque, dado que no existe una ruta de retorno, si una transacción secundaria falla por ese motivo, no se podrá informar de ella). a la persona que llama originalmente y algunos otros medios de recuperación tendría que ocurrir.) 5.5. Polkadot y Ethereum. Debido a la integridad de Turing de Ethereum, esperamos que haya amplias oportunidades para que Polkadot y Ethereum sean interoperables con entre sí, al menos dentro de algunos límites de seguridad fácilmente deducibles. En resumen, prevemos que las transacciones de Polkadot puede ser firmado por validators y luego ingresado en 5Tal tarea podría ser compartida entre validators o podría convertirse en la tarea designada de un conjunto de validators fuertemente vinculados conocido como Garantes de disponibilidad.

POLKADOT: VISIÓN PARA UN MARCO MULTICADENA HETEROGÉNEO BORRADOR 1 8 Ethereum donde pueden ser interpretados y promulgados por un contrato de reenvío de transacciones. En la otra dirección, Prevemos el uso de registros (eventos) especialmente formateados. proveniente de un “contrato de ruptura” para permitir una verificación rápida de que se debe reenviar un mensaje en particular. 5.5.1. Polkadot a Ethereum. A través de la elección de un BFT mecanismo de consenso con validators formado a partir de un conjunto de partes interesadas determinadas mediante una votación de aprobación mecanismo, podemos lograr un consenso seguro con un cambios poco frecuentes y un número modesto de validators. En un sistema con un total de 144 validators, un tiempo de bloqueo de 4 segundos y una finalidad de 900 bloques (lo que permite ataques maliciosos Comportamientos como votos dobles deben ser denunciados y sancionados. y reparado), la validez de un bloque puede razonablemente ser se considera probado mediante tan solo 97 firmas (dos tercios de 144 más una) y un período de verificación posterior de 60 minutos en el que no se depositan impugnaciones. Ethereum puede albergar un "contrato de asentamiento" que puede mantener a los 144 firmantes y ser controlado por ellos. Dado que la recuperación de la firma digital de curva elíptica (ECDSA) requiere solo 3000 gases según el EVM, y desde Probablemente solo querríamos que la validación se realice en un supermayoría de validators (en lugar de unanimidad total), el costo base de Ethereum confirmando que una instrucción fue validado adecuadamente como proveniente de la red Polkadot no sería más de 300,000 gas, apenas el 6% del el límite total de gas del bloque es de 5,5 millones. Aumentar el número de validators (como sería necesario para tratar con docenas de cadenas) inevitablemente aumenta este costo, sin embargo En general, se espera que el ancho de banda de transacciones de Ethereum crezca con el tiempo a medida que la tecnología madure y la infraestructura mejora. Junto con el hecho de que no todos los validator deben estar involucrados (por ejemplo, solo el más alto Los validators apostados pueden ser llamados para tal tarea) el Los límites de este mecanismo se extienden razonablemente bien. Suponiendo una rotación diaria de dichos validators (que es bastante conservador (semanal o incluso mensual puede ser aceptable), entonces el costo para la red de mantener este puente de reenvío Ethereum costaría alrededor de 540.000 gas por día o, a los precios actuales del gas, $45 por año. Una transacción básica enviada sola a través del puente costaría alrededor de 0,11 dólares; el cálculo adicional del contrato costaría más, por supuesto. Al almacenar en búfer y agrupar transacciones juntos, los costos de autorización de robo pueden ser fácilmente compartido, reduciendo sustancialmente el costo por transacción; si se requirieron 20 transacciones antes del reenvío, entonces el costo de reenviar una transacción básica se reduciría a alrededor de $0,01. Una alternativa interesante y más económica a este modelo de contrato con múltiples firmas sería utilizar firmas de umbral para lograr la semántica de propiedad multilateral. Mientras que los esquemas de firma de umbral para ECDSA son computacionalmente costosos, los de otros esquemas como las firmas Schnorr son muy razonables. Ethereum planea introducir primitivos que harían tales esquemas baratos de usar en el próximo hardfork de Metropolis. Si se pudiera utilizar este medio, los costes del gas para reenviar una transacción Polkadot al Ethereum La red se reduciría drásticamente a casi cero. gastos generales adicionales a los costos básicos para validar el firma y ejecución de la transacción subyacente. En este modelo, los nodos validator de Polkadot tendrían hacer poco más que firmar mensajes. Para que las transacciones realmente se enruten a la red Ethereum, nosotros supongamos que los validators también residirían en la red Ethereum o, más probablemente, que pequeñas recompensas ser ofrecido al primer actor que reenvía el mensaje en a la red (la recompensa podría trivialmente pagarse al originador de la transacción). 5.5.2. Ethereum a Polkadot. Conseguir que las transacciones sean reenviado de Ethereum a Polkadot utiliza la noción simple de registros. Cuando un contrato Ethereum desea enviar una transacción a una paracadena particular de Polkadot, simplemente necesita concertar un “contrato de ruptura” especial. El contrato de ruptura aceptaría cualquier pago que pudiera ser requerido y emitir una instrucción de registro para que su existencia pueda ser probada a través de una prueba Merkle y una afirmación de que el encabezado del bloque correspondiente es válido y canónico. De las dos últimas condiciones, la validez es quizás la más sencillo de demostrar. En principio, el único requisito espara cada nodo Polkadot que necesita la prueba (es decir, nodos validator designados) para ejecutar una instancia completamente sincronizada de un nodo Ethereum estándar. Desafortunadamente, esto es en sí mismo una dependencia bastante grande. un mas Un método ligero sería utilizar una prueba simple de que El encabezado se evaluó correctamente al proporcionar solo el parte del intento de estado de Ethereum necesario para ejecutarse correctamente las transacciones en el bloque y verifique que los registros (contenidos en el recibo del bloque) sean válidos. Tales “tipo SPV”6 las pruebas aún pueden requerir una cantidad sustancial de información; convenientemente, normalmente no serían necesarios en todos: un sistema de unión dentro de Polkadot permitiría unir terceros a enviar encabezados a riesgo de perder su fianza en caso de que algún otro tercero (como un “pescador”, ver 6.2.3) proporcione una prueba de que el encabezado no es válido (específicamente que la raíz estatal o las raíces receptoras eran impostores). En una red PoW no finalizada como Ethereum, el La canonicidad es imposible de probar de manera concluyente. Para solucionar este problema, las aplicaciones que intentan basarse en cualquier tipo de causa-efecto dependiente de la cadena, espere una serie de "confirmaciones", o hasta que la transacción dependiente esté en algún profundidad particular dentro de la cadena. El Ethereum, esto la profundidad varía desde 1 bloque para las transacciones menos valiosas sin problemas de red conocidos hasta 1200 bloques como era el caso durante el lanzamiento inicial de Frontier para intercambios. En la red estable “Homestead”, esta cifra se ubica en 120 bloques para la mayoría de los intercambios, y probablemente tomaríamos un parámetro similar. entonces nosotros puede imagina nuestro Polkadot-lado Ethereuminterfaz para tener algunas funciones simples: poder aceptar un nuevo encabezado de la red Ethereum y validar el PoW, para poder aceptar alguna prueba de que un registro particular fue emitido por el contrato de ruptura del lado Ethereum para un cabezazo de suficiente profundidad (y hacia adelante) el mensaje correspondiente dentro de Polkadot) y finalmente poder aceptar pruebas de que un documento previamente aceptado pero El encabezado aún no promulgado contiene una raíz de recibo no válida. Para obtener realmente los datos del encabezado Ethereum (y cualquier prueba de SPV o refutaciones de validez/canonicidad) en la red Polkadot, un incentivo al reenvío 6SPV se refiere a Verificación de pago simplificada en Bitcoin y describe un método para que los clientes verifiquen transacciones manteniendo solo una copia de todos los encabezados de bloques de la cadena PoW más larga.POLKADOT: VISIÓN PARA UN MARCO MULTICADENA HETEROGÉNEO BORRADOR 1 9 se necesitan datos. Esto podría ser tan simple como un pago. (financiado con tarifas cobradas del lado Ethereum) pagado a cualquiera capaz de reenviar un bloque útil cuyo encabezado sea válido. Se pediría a los validadores que retengan información relacionada con los últimos miles de bloques para poder ser capaz de gestionar bifurcaciones, ya sea a través de algún medio intrínseco del protocolo o mediante un contrato mantenido en el cadena de relevo. 5.6. Polkadot y Bitcoin. Bitcoin interoperación presenta un desafío interesante para Polkadot: un llamado La “vinculación bidireccional” sería una pieza útil de infraestructura. tener del lado de ambas redes. Sin embargo, debido a las limitaciones de Bitcoin, proporcionar dicha clavija de forma segura es una tarea nada trivial. Entregar una transacción desde Bitcoin a Polkadot se puede realizar en principio con un proceso similar al de Ethereum; una “dirección de ruptura” controlado de alguna manera por los Polkadot validators podrían recibir tokens transferidos (y los datos enviados junto con ellos). Las pruebas de SPV podrían ser proporcionadas por oracles incentivados y, junto con un período de confirmación, una recompensa otorgada por identificar bloques no canónicos que implican la transacción ha sido “doble gastado”. Cualquier tokens que posea en el La “dirección de ruptura” entonces, en principio, sería controlada por esos mismos validators para su posterior dispersión. Sin embargo, el problema es cómo se pueden controlar de forma segura los depósitos desde un conjunto validator giratorio. a diferencia Ethereum que es capaz de tomar decisiones arbitrarias basadas tras combinaciones de firmas, Bitcoin es sustancialmente más limitado, y la mayoría de los clientes aceptan solo transacciones con múltiples firmas con un máximo de 3 partes. Ampliar esta cifra a 36, o incluso a miles, como en última instancia se desearía, es imposible con el protocolo actual. Una opción es modificar el protocolo Bitcoin para habilitar dicha funcionalidad, sin embargo, las llamadas “bifurcaciones duras” en el Bitcoin mundo son difíciles de organizar a juzgar por los intentos recientes. Una posibilidad es el uso de firmas de umbral, esquemas criptográficos para permitir que un público pueda identificarse individualmente clave para ser controlada efectivamente por múltiples “partes” secretas algunos o todos los cuales deben utilizarse para crear una firma válida. Lamentablemente, las firmas de umbral son compatibles con ECDSA de Bitcoin son computacionalmente costosos de crear y de complejidad polinomial. Otros esquemas como Las firmas Schnorr ofrecen costos mucho más bajos; sin embargo, cronograma en el que pueden introducirse en el Bitcoin El protocolo es incierto. Dado que la seguridad última de los depósitos recae en varios validators vinculados, otra opción es reducir los poseedores de claves de firmas múltiples a solo un subconjunto vinculado del total validators tal que el umbral las firmas se vuelven factibles (o, en el peor de los casos, las firmas nativas de Bitcoin es posible la firma múltiple). Esto por supuesto reduce la cantidad total de bonos que podrían deducirse en concepto de reparaciones si los validator se comportaran ilegalmente; sin embargo, esto es una degradación elegante, simplemente estableciendo un límite superior de la cantidad de fondos que pueden circular de forma segura entre los dos redes (o incluso, en el % de pérdidas en caso de un ataque de los validators exitosos). Como tal, creemos que no es poco realista colocar una “paracadena virtual” de interoperabilidad Bitcoin razonablemente segura. entre las dos redes, aunque no deja de ser un esfuerzo sustancial con un cronograma incierto y muy posiblemente requiriendo la cooperación de las partes interesadas dentro de ese red.

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 en detalle

El protocolo se puede dividir aproximadamente en tres partes: el mecanismo de consenso, la interfaz parachain y enrutamiento de transacciones entre cadenas. 6.1. cadena de relevo Operación. el cadena de relevos voluntad Probablemente sea una cadena muy similar a Ethereum en que está basado en el estado con la dirección de asignación del estado a la cuenta información, principalmente saldos y (para evitar repeticiones) una contador de transacciones. Colocar cuentas aquí cumple un propósito: dar cuenta de lo que la identidad posee. qué cantidad de participación en el sistema.7 Sin embargo, habrá diferencias notables: • Los contratos no pueden implementarse a través de transacciones; Siguiendo el deseo de evitar la funcionalidad de la aplicación en la cadena de relés, no apoyar el despliegue público de los contratos. • No se contabiliza el uso de recursos informáticos (“gas”); ya que las únicas funciones disponibles para uso público será arreglado, la razón detrás de la contabilidad del gas ya no aguanta. Como tal, se aplicará una tarifa fija en todos los casos, lo que permite un mayor rendimiento de cualquier ejecución de código dinámico que puede ser necesario realizar y un formato de transacción más simple. • Se admite una funcionalidad especial para los contratos listados que permite la ejecución automática y la salida de mensajes de red. En el caso de que la cadena de relés tenga una VM y sea Basado en EVM, tendría una serie de modificaciones para garantizar la máxima simplicidad. probablemente tener una serie de contratos incorporados (similares a los de direcciones 1-4 en Ethereum) para permitir la configuración específica de la plataforma. deberes a gestionar, incluido un contrato de consenso, un Contrato validator y un contrato parachain. Si no es el EVM, entonces la alternativa más probable es un backend WebAssembly [2] (wasm); en este caso el total La estructura sería similar, pero no habría necesidad. para los contratos incorporados con Wasm como un objetivo viable para lenguajes de propósito general en lugar de los inmaduros e idiomas limitados para EVM. Otras posibles desviaciones del protocolo actual Ethereum son bastante posibles, por ejemplo, una simplificación del formato de recibo de transacción que permite la ejecución paralela de transacciones no conflictivas dentro del mismo bloque, como se propone para la serie de cambios Serenity. Es posible, aunque poco probable, que un modelo similar al Serenity La cadena "pura" se implementará como cadena de relevos, lo que permitirá una contrato particular para gestionar cosas como el staking token equilibrios en lugar de convertirlos en una parte fundamental El protocolo de la cadena. En la actualidad, creemos que es poco probable que esto ofrecerá una simplificación del protocolo lo suficientemente grande como para ser Vale la pena la complejidad e incertidumbre adicionales involucradas. en desarrollarlo. 7 Como medio para representar la cantidad que un titular determinado es responsable de la seguridad general del sistema, estas cuentas de participación inevitablemente codifican algún valor económico. Sin embargo, debe entenderse que dado que no existe la intención de que dichos valores se utilicen en de cualquier manera con el fin de intercambiar bienes y servicios del mundo real, debe tenerse en cuenta que los tokens no deben compararse con moneda y, como tal, la cadena de retransmisiones conserva su filosofía nihilista con respecto a las aplicaciones.POLKADOT: VISIÓN PARA UN MARCO MULTICADENA HETEROGÉNEO BORRADOR 1 10 Hay una serie de pequeñas funciones necesarias para administrar el mecanismo de consenso, el conjunto validator, el mecanismo de validación y las paracaídas. estos podrían implementarse juntos bajo un protocolo monolítico. Sin embargo, por motivos de modularidad, los describimos como "contratos" de la cadena de retransmisiones. Esto debería entenderse en el sentido de que son objetos (en el sentido de programación orientada a objetos) gestionada por el mecanismo de consenso de la cadena de retransmisión, pero no necesariamente eso se definen como programas en códigos de operación similares a EVM, ni incluso que sean direccionables individualmente a través del sistema de cuentas. 6.2. Contrato de participación. Este contrato mantiene el conjunto validator. Gestiona: • qué cuentas son actualmente validators; • que están disponibles para convertirse en validators en breve aviso; • qué cuentas han colocado participación nominando a un validator; • propiedades de cada uno, incluido el volumen staking, tasas y direcciones de pago aceptables e identidades de corto plazo (sesión). Permite que una cuenta registre el deseo de convertirse en vinculado validator (junto con sus requisitos), para nominar a alguna identidad y para validators vinculados preexistentes para registrar su deseo de salir de este estado. También incluye la propia maquinaria para el mecanismo de validación y canonicalización. 6.2.1. Participación-token Liquidez. Generalmente es deseable tener la mayor cantidad posible del total de staking tokens para ser en juego dentro de las operaciones de mantenimiento de la red desde esto vincula directamente la seguridad de la red con la "capitalización de mercado" general de staking token. Esto puede fácilmente ser incentivado inflando la moneda y entregando las ganancias a quienes participan como validators. Sin embargo, hacerlo presenta un problema: si el token está bloqueado en el contrato de participación bajo castigo de reducción, ¿cómo puede una parte sustancial permanecer lo suficientemente ¿Líquido para permitir el descubrimiento de precios? Una respuesta a esto es permitir un contrato de derivados sencillo, asegurando tokens fungibles sobre un token subyacente apostado. Esto es difícil de arreglar de manera libre de confianza. Además, estos derivados tokens no pueden tratarse por igual por la misma razón por la que los diferentes bonos gubernamentales de la eurozona no son fungibles: hay existe la posibilidad de que el activo subyacente falle y se convierta en inútil. Con los gobiernos de la eurozona, podría haber una predeterminado. Con validator apostados tokens, el validator puede actuar maliciosamente y ser castigado. Siguiendo nuestros principios, elegimos la solución más simple: no se apostarán todos los token. Esto significaría que una proporción (quizás el 20%) de tokens permanecerá líquida por la fuerza. Aunque esto es imperfecto desde una perspectiva de seguridad, es poco probable que marque una diferencia fundamental en la seguridad de la red; El 80% de las reparaciones posibles derivadas de la confiscación de bonos todavía podrían hacerse en comparación con el "caso perfecto" del 100% staking. La relación entre tokens apostados y líquidos se puede determinar de forma bastante sencilla mediante un mecanismo de subasta inversa. Básicamente, titulares de token interesados en ser validator cada uno publicaría una oferta para el contrato staking indicando la tasa de pago mínima que necesitarían para tomar parte. Al comienzo de cada sesión (las sesiones sucede regularmente, tal vez tan a menudo como una vez por hora) el validator espacios se llenarían de acuerdo con cada aspirante Tasa de participación y pago de validator. Un posible algoritmo porque esto sería tomar aquellos con las ofertas más bajas que representar una participación no superior a la participación total objetivo dividido por el número de espacios y no inferior a un límite inferior de la mitad de esa cantidad. Si las plazas no se pueden llenar, el límite inferior podría reducirse repetidamente en algún factor para satisfacerlo. 6.2.2. Nominación. Es posible nominar sin confianza unos staking tokens a un validator activo, dándoles la responsabilidad de los deberes de validator. Nominación de obras a través de un sistema de votación de aprobación. Cada posible nominador puede publicar una instrucción en el contrato staking expresando una o más identidades validator bajo cuyas responsabilidad que están dispuestos a confiar a su vínculo. En cada sesión, los bonos de los nominadores se distribuyen para ser representado por uno o más validators. El algoritmo de dispersión se optimiza para un conjunto de validators de total equivalente bonos. Los bonos de los nominadores quedan bajo la responsabilidad efectiva del validator ay ganar interés o sufrir una reducción del castigo en consecuencia. 6.2.3. Confiscación/quema de bonos. Cierto comportamiento validator resulta en una reducción punitiva de su vínculo. si la fianza se reduce por debajo del mínimo permitido, el La sesión finaliza prematuramente y se inicia otra. Una lista no exhaustiva de mala conducta punible validator incluye: • Ser parte de un grupo parachain que no puede proporcionar consenso sobre la validez de un bloque de parachain; • firmar activamente por la validez de un documento inválido bloque de paracaídas; • incapacidad de suministrar cargas útiles de salida anteriormente votado como disponible; • inactividad durante el proceso de consenso; • validación de bloques de cadena de relés en horquillas de la competencia. Algunos casos de mala conducta amenazan la integridad de la red (como firmar bloques de parachain no válidos y validar múltiples lados de una bifurcación) y, como tal, resultan en un exilio efectivo mediante la reducción total del vínculo. en otros casos menos graves (por ejemplo, inactividad en el consenso proceso) o casos en los que no se puede asignar la culpa con precisión (ser parte de un grupo ineficaz), una pequeña porción de la fianza podrá ser multado. En este último caso, este funciona bien con la rotación de subgrupos para garantizar que las personas maliciosas Los nodos sufren sustancialmente más pérdidas que los nodos benévolos con daños colaterales. En algunos casos (por ejemplo, validación de múltiples bifurcaciones y no válida firma de subbloque) validators no pueden detectar fácilmente el mal comportamiento de los demás debido a la verificación constante de cada bloque de parachain sería una tarea demasiado ardua. aquí es necesario conseguir el apoyo de partidos externos a el proceso de validación para verificar y denunciar dicha mala conducta. Las partes obtienen una recompensa por denunciar dicha actividad; su término, “pescadores”, surge de la improbabilidad de tal recompensa. Dado que estos casos suelen ser muy graves, imaginamos que cualquier recompensa puede pagarse fácilmente con la fianza confiscada. En general preferimos equilibrar la quema (es decir, reducción a nada) con reasignación, en lugar de intentar una reasignación total. Esto tiene el efecto de

POLKADOT: VISIÓN PARA UN MARCO MULTICADENA HETEROGÉNEO BORRADOR 1 11 aumentando el valor total del token, compensando el red en general hasta cierto punto en lugar de la red específica parte involucrada en el descubrimiento. Esto es principalmente como medida de seguridad. mecanismo: las grandes cantidades involucradas podrían llevar a una incentivación extrema y aguda del comportamiento si todas otorgado a un solo objetivo. En general, es importante que la recompensa sea lo suficientemente grande como para que la verificación valga la pena para la red, pero no tan grande como para compensar los costos de afrontar una transacción. criminal bien financiada y bien orquestada a “nivel industrial” ataque de piratería a algún desafortunado validator para forzar un mal comportamiento. De esta manera, la cantidad reclamada en general no debería ser mayor que el vínculo directo del errante validator, no sea que un El incentivo perverso surge de comportarse mal y reportarse para recibir la recompensa. Esto puede combatirse explícitamente a través de un requisito mínimo de vinculación directa por ser validator o implícitamente educando a los nominadores que los validators con pocos bonos depositados no tienen grandes incentivos portarse bien. 6.3. Registro de paracaídas. Cada paracadena se define en este registro. Es una construcción similar a una base de datos relativamente simple y contiene información tanto estática como dinámica sobre cada cadena. La información estática incluye el índice de cadena (un simple entero), junto con la identidad del protocolo de validación, un medios para distinguir entre las diferentes clases de parachain para que el algoritmo de validación correcto pueda ser dirigido por validators dedicados a presentar un candidato válido. Una prueba de concepto inicial se centraría en colocar los nuevos algoritmos de validación en los propios clientes, lo que efectivamente requiere una bifurcación dura del protocolo cada vez que Se agregaron clases adicionales de cadena. Aunque en última instancia, es posible especificar el algoritmo de validación en de una manera lo suficientemente rigurosa y eficiente para que los clientes estén capaz de trabajar eficazmente con nuevas paracaídas sin bifurcación dura. Una posible vía para lograrlo sería especificar el algoritmo de validación de parachain en un bien establecido, lenguaje compilado de forma nativa y neutral a la plataforma, como WebAssembly. Se necesitan investigaciones adicionales para determinar si esto es realmente factible; sin embargo, si es así, podría traer con ello la tremenda ventaja de desterrar los hard-forks para siempre. La información dinámica incluye aspectos del sistema de enrutamiento de transacciones que deben tener un acuerdo global, como como la cola de ingreso de la parachain (descrita en la sección 6.6). El registro solo puede agregar paracaídas mediante votación plena en referéndum; esto podría ser manejado internamente, pero lo más probable es que se coloque en un lugar externo. contrato de referéndum para facilitar la reutilización en virtud de componentes de gobernanza más generales. Los parámetros a requisitos de votación (por ejemplo, cualquier quórum requerido, mayoría requerido) para el registro de cadenas adicionales y otros, Las actualizaciones menos formales del sistema se establecerán en un “documento maestro”. constitución”, pero es probable que sigan una política bastante tradicional. camino, al menos inicialmente. La formulación precisa está fuera de alcance para el presente trabajo, pero p.e. una supermayoría de dos tercios para aprobar con más de un tercio del sistema total La votación positiva en juego puede ser un punto de partida sensato. Las operaciones adicionales incluyen la suspensión y eliminación de paracaídas. Es de esperar que la suspensión nunca suceder, sin embargo, está diseñado para ser una salvaguardia menos Puede haber algún problema intratable en el sistema de validación de una parachain. El caso más obvio en el que podría Lo que se necesita es una diferencia crítica de consenso entre las implementaciones que lleven a validators a no poder ponerse de acuerdo sobre validez o bloqueos. Se alentaría a los validadores a utilizar múltiples implementaciones de clientes para que puedan para detectar tal problema antes de la confiscación de la fianza. Dado que la suspensión es una medida de emergencia, sería bajo los auspicios de la dinámica validator-votación en lugar que un referéndum. La reinstalación sería posible tanto de los validators o un referéndum. La eliminación total de las paracaídas se produciría sólo después de un referéndum y con el que se requeriría una período de gracia sustancial para permitir una transición ordenada a ya sea una cadena independiente o para formar parte de alguna otra sistema de consenso. El período de gracia probablemente sería de el orden de meses y es probable que se establezca por cadena en el registro de parachain para que diferentes Las paracaídas pueden disfrutar de diferentes períodos de gracia según su necesidad. 6.4. Bloques de relés de sellado. El sellado se refiere, en esencia, al proceso de canonicalización; es decir, un dato básico transformar cualmapea el original en algo fundamentalmente singular y significativo. Bajo una cadena PoW, Sellado es efectivamente sinónimo de minería. En nuestro caso, Implica la recopilación de declaraciones firmadas de validators sobre la validez, disponibilidad y canonicidad de un bloque de cadena de relés particular y los bloques de paracadena que representa. La mecánica del algoritmo de consenso subyacente BFT está fuera del alcance del presente trabajo. nosotros lo haremos en su lugar, descríbalo usando una primitiva que asume una máquina estatal creadora de consenso. En definitiva esperamos inspirarse en una serie de consensos prometedores BFT algoritmos en el núcleo; Tangaora [9] (una variante BFT de Balsa [16]), Tendermint [11] y HoneyBadgerBFT [14]. El algoritmo tendrá que llegar a un acuerdo sobre múltiples paracaídas en paralelo, diferenciándose así del habitual blockchain mecanismos de consenso. Suponemos que una vez Se alcanza el consenso, podemos registrar el consenso. en una prueba irrefutable que puede ser aportada por cualquiera de los participantes en el mismo. También asumimos que el mal comportamiento dentro del protocolo generalmente se puede reducir a una pequeña grupo que contiene participantes que se portan mal para minimizar los daños colaterales a la hora de aplicar el castigo.8 La prueba, que toma la forma de nuestras declaraciones firmadas, se coloca juntas en el encabezado del bloque de la cadena de retransmisión. con algunos otros campos, entre ellos la raíz de estado de la cadena de retransmisión y la raíz de transacción. el sellado proceso toma lugar bajo un soltero generación de consenso mecanismo dirigiéndose ambos el bloque de la cadena de relés y los bloques de paracaídas que hacen forman parte del contenido del relevo: las paracaídas no son "comprometidas" por separado por sus subgrupos y luego cotejadas más tarde. Esto resulta en un proceso más complejo para la cadena de retransmisión, pero nos permite completar el consenso de todo el sistema en una sola etapa, minimizando la latencia y permitiendo para requisitos bastante complejos de disponibilidad de datos que son útil para el proceso de enrutamiento a continuación. 8Los esquemas de consenso BFT existentes basados en PoS, como Tendermint BFT y el Slasher original, cumplen estas afirmaciones.

POLKADOT: VISIÓN PARA UN MARCO MULTICADENA HETEROGÉNEO BORRADOR 1 12 El estado de la máquina de consenso de cada participante puede modelarse como una tabla simple (bidimensional). Cada participante (validator) tiene un conjunto de información, en la forma de declaraciones firmadas ("votos") de otros participantes, con respecto a cada candidato del bloque de parachain así como al candidato del bloque de retransmisión. El conjunto de información es de dos piezas. de datos: Disponibilidad: ¿no? esto validator tener salida información de publicación de transacciones de este bloque para que ¿Pueden validar adecuadamente los candidatos de parachain en el siguiente bloque? ellos pueden votar ya sea 1 (conocido) o 0 (aún no conocido). Una vez que ellos voto 1, se comprometen a votar de manera similar por el resto de este proceso. Votos posteriores que no respetar esto son motivo de castigo. Validez: ¿es válido el bloque parachain y es todo? datos de referencia externa (p. ej. transacciones) disponible? Esto solo es relevante para validators asignados a la paracadena por la que están votando. Pueden votar 1 (válido), -1 (inválido) o 0 (aún no conocido). Una vez que votan distinto de cero, Estamos comprometidos a votar de esta manera durante el resto del año. el proceso. Votos posteriores que no respetan esto. son motivo de castigo. Todos los validators deben enviar votos; Los votos podrán ser reenviados, calificados por las reglas anteriores. La progresión de El consenso se puede modelar como múltiples algoritmos de consenso estándar BFT sobre cada paracadena que ocurren en paralelo. Dado que estos se ven potencialmente frustrados por una relativamente pequeña minoría de actores maliciosos concentrados en un solo grupo parachain, existe el consenso general para establecer un respaldo que limite el peor de los casos. punto muerto a simplemente uno o más bloques de parachain vacíos (y ronda de castigo para los responsables). Las reglas básicas para la validez de los bloques individuales (que permiten que el conjunto total de validators en su conjunto llegue a consenso para que se convierta en el único candidato parachain para ser referenciado desde el relé canónico): • debe tener al menos dos tercios de sus validators votando positivamente y ninguno votando negativamente; • debe tener más de un tercio de validators votando positivamente a la disponibilidad de información de la cola de salida. Si hay al menos un voto positivo y al menos uno negativo sobre la validez, se crea una condición excepcional. y todo el conjunto de validators debe votar para determinar si hay partes maliciosas o si hay un accidente tenedor. Además de válidos e inválidos, existe un tercer tipo de votos. están permitidos, equivalente a votar por ambos, lo que significa que el nodo tiene opiniones contradictorias. Esto podría deberse a la propietario del nodo ejecuta múltiples implementaciones que no no están de acuerdo, lo que indica una posible ambigüedad en el protocolo. Después de contar todos los votos del conjunto completo validator, si la opinión perdedora tiene al menos una pequeña proporción (a estar parametrizado; como máximo la mitad, quizás significativamente menos) de los votos de la opinión ganadora, entonces se supone que ser una bifurcación accidental de la parachain y la parachain se suspende automáticamente del proceso de consenso. En caso contrario, asumimos que se trata de un acto doloso y castigamos al minoría que votó a favor de la opinión disidente. La conclusión es un conjunto de firmas que demuestran canonicidad. A continuación se puede sellar el bloque de la cadena de relés. y comenzó el proceso de sellado del siguiente bloque. 6.5. Mejoras para el sellado de bloques de relés. mientras este método de sellado ofrece fuertes garantías sobre el funcionamiento del sistema, no se escala particularmente bien ya que la información clave de cada parachain debe tener su Disponibilidad garantizada por más de un tercio de todos los validator. Esto significa que la huella de responsabilidad de cada validator crece a medida que se añaden más cadenas. Si bien la disponibilidad de datos dentro de redes de consenso abierto es esencialmente un problema sin resolver, existen formas de mitigar la sobrecarga colocada en validator nodos. uno simple La solución es darse cuenta de que si bien validators deben asumir asumen la responsabilidad de la disponibilidad de los datos, no necesitan almacenar, comunicar o replicar los datos ellos mismos. Silos de datos secundarios, posiblemente relacionados (o incluso con los mismos) mismos) los recopiladores que recopilan estos datos, podrán gestionar la tarea de garantizar la disponibilidad con los validator proporcionando una parte de sus intereses/ingresos en pago. Sin embargo, si bien esto podría permitir cierta escalabilidad intermedia, todavía no soluciona el problema subyacente; desde agregar más cadenas en general requerirá validators adicionales, el consumo continuo de recursos de la red (particularmente en términos de ancho de banda) crece con el cuadrado de elcadenas, una propiedad insostenible en el largo plazo. Al final, es probable que sigamos golpeándonos la cabeza. contra la limitación fundamental que establece que para una red de consenso para ser considerada disponible segura, la Los requisitos continuos de ancho de banda son del orden del total. validators multiplicado por la información de entrada total. Esto se debe a la incapacidad de una red que no es de confianza para distribuir adecuadamente la tarea de almacenamiento de datos entre muchos nodos, que se encuentra aparte de la tarea eminentemente distribuible de procesamiento. 6.5.1. Presentamos la latencia. Una manera de suavizar esto La regla es relajar la noción de inmediatez. Al requerir que el 33%+1 validators voten por la disponibilidad solo eventualmente, y no inmediatamente, podemos utilizar mejor la propagación exponencial de datos y ayudar a nivelar los picos en el intercambio de datos. Una igualdad razonable (aunque no demostrada) puede ser: (1) latencia = participantes × cadenas Según el modelo actual, el tamaño del sistema aumenta con el número de cadenas para garantizar que el procesamiento sea distribuido; ya que cada cadena requerirá al menos un validator y fijamos la atestación de disponibilidad a una constante proporción de validators, entonces los participantes crecen de manera similar con el número de cadenas. Terminamos con: (2) latencia = tamaño2 Lo que significa que a medida que el sistema crece, el ancho de banda requerido y la latencia hasta la disponibilidad se conocen en todo el mundo. red, que también podría caracterizarse como el número de bloques antes de la finalidad, aumenta con su cuadrado. esto es un factor de crecimiento sustancial y puede convertirse en un obstáculo notable y obligarnos a adoptar paradigmas “no planos” como componer varios “Polkadotes” en una jerarquía para enrutamiento multinivel de publicaciones a través de un árbol de cadenas de relés.

POLKADOT: VISIÓN PARA UN MARCO MULTICADENA HETEROGÉNEO BORRADOR 1 13 6.5.2. Participación pública. Una dirección más posible es lograr la participación pública en el proceso a través de un Sistema de microdenuncias. Al igual que los pescadores, hay podrían ser partes externas para vigilar a los validators que afirman disponibilidad. Su tarea es encontrar a alguien que parezca incapaz de demostrar tal disponibilidad. Al hacerlo ellos puede presentar una microdenuncia a otros validators. prisionero de guerra o Se puede utilizar un bono apostado para mitigar el ataque de Sybil. lo que haría que el sistema fuera en gran medida inútil. 6.5.3. Garantes de disponibilidad. Una ruta final sería nominar un segundo conjunto de validators vinculados como "disponibilidad garantes”. Estos se unirían igual que con los validator normales, e incluso podrían tomarse del mismo conjunto. (aunque de ser así, se elegirían a lo largo de un período prolongado, al menos por sesión). A diferencia de los validator normales, ellos no cambiaría entre paracaídas sino que más bien Forme un solo grupo para dar fe de la disponibilidad de todos los datos importantes entre cadenas. Esto tiene la ventaja de relajar la equivalencia entre participantes y cadenas. Básicamente, las cadenas pueden crecer (junto con el conjunto de cadena original validator), mientras que Los participantes, y específicamente aquellos que participan en el testamento de disponibilidad de datos, pueden permanecer al menos sublineales. y muy posiblemente constante. 6.5.4. Preferencias del clasificador. Un aspecto importante de este sistema es asegurar que haya una selección saludable de alzadores que crean los bloques en cualquier paracadena determinada. si un un solo alzador dominó una paracadena y luego algunos ataques volverse más factible ya que la probabilidad de la falta de la disponibilidad de datos externos sería menos obvia. Una opción es pesar artificialmente los bloques de paracaídas en un mecanismo pseudoaleatorio para favorecer una amplia variedad de alzadoras. En primera instancia requeriríamos como parte del mecanismo de consenso que favorece a validators Se determinó que los candidatos del bloque parachain son "más pesados". De manera similar, debemos incentivar a validators para que intenten sugerir el bloque más pesado que puedan encontrar; este podría ser Esto se hace haciendo que una parte de su recompensa sea proporcional al peso de su candidato. Para garantizar que los alzadores reciban una remuneración justa posibilidades de que su candidato sea elegido ganador candidato en consenso, hacemos el peso específico de un Candidato de bloque de parachain determinado en una función aleatoria conectada con cada alzador. Por ejemplo, tomando la medida de distancia XOR entre la dirección del alzador y algún número pseudoaleatorio criptográficamente seguro determinado cerca del punto del bloque que se está creando (un “billete ganador” ficticio). Esto efectivamente le da a cada clasificador (o, más específicamente, la dirección de cada clasificador) un probabilidad aleatoria de que su bloque de candidatos “gane” todos los demás. Para mitigar el ataque sybil de un solo alzador que “extrae” una dirección cercana al boleto ganador y, por lo tanto, es un favorito en cada bloque, agregaríamos algo de inercia a la dirección de un clasificador. Esto puede ser tan simple como exigirles tener una cantidad base de fondos en la dirección. un mas Un enfoque elegante sería ponderar la proximidad al boleto ganador con la cantidad de fondos estacionados en el dirección en cuestión. Si bien aún no se ha hecho el modelado, es muy posible que este mecanismo permita incluso pequeños interesados para que contribuyan como recopiladores. 6.5.5. Bloques con sobrepeso. Si un conjunto validator está comprometido, pueden crear y proponer un bloque que, aunque válido, requiere una cantidad excesiva de tiempo para ejecutarse y validar. Esto es un problema ya que un grupo validator podría formar razonablemente un bloque que tarda mucho tiempo en ejecutar a menos que ya se conozca alguna información particular que permita un atajo, p. factorizar un gran prima. Si un solo recopilador conociera esa información, entonces tendrían una clara ventaja al conseguir su propio Los candidatos aceptaron siempre que los demás estuvieran ocupados procesando el antiguo bloque. A estos bloques los llamamos sobrepeso. La protección contra validators que envía y valida estos bloques se presenta en gran medida de la misma manera que para bloques no válidos, aunque con una advertencia adicional: dado que el tiempo necesario para ejecutar un bloque (y por lo tanto su estado como sobrepeso) es subjetivo, el resultado final de una votación sobre El mal comportamiento se dividirá esencialmente en tres campos. uno Lo más probable es que el bloque definitivamente no tenga sobrepeso. en este caso más de dos tercios declaran que podrían ejecutar el bloque dentro de algún límite (por ejemplo, 50% del tiempo total permitido entre bloques). Otra es que el el bloque es ddefinitivamente sobrepeso: esto sería si más de dos tercios declaran que no pudieron ejecutar el bloqueo dentro de dicho límite. Una última posibilidad es una situación bastante igual. división de opiniones entre validators. En este caso, podemos optar por aplicar algún castigo proporcionado. Para garantizar que los validators puedan predecir cuándo pueden ser Al proponer un bloque con sobrepeso, puede ser sensato exigirles que publiquen información sobre su propio desempeño para cada bloque. Durante un período de tiempo suficiente, esto debería permitirles perfilar su velocidad de procesamiento en relación con los pares que los juzgarían. 6.5.6. Seguro de alzador. Queda un problema para validators: A diferencia de las redes PoW, para comprobar el estado de un alzador. bloque para su validez, en realidad deben ejecutar las transacciones en él. Los alzadores maliciosos pueden alimentar a los validator con bloques no válidos o con sobrepeso, causándoles dolor (desperdiciando sus recursos) y exigir un costo de oportunidad potencialmente sustancial. Para mitigar esto, proponemos una estrategia simple sobre la parte de validators. En primer lugar, se enviaron candidatos a bloques de parachain a validators debe estar firmado desde una cuenta de cadena de retransmisión con fondos; si no es así, entonces el validator debería desaparecer inmediatamente. En segundo lugar, dichos candidatos deben ordenarse en prioridad mediante una combinación (por ejemplo, multiplicación) de la cantidad de fondos en la cuenta hasta cierto límite, el número de bloques anteriores que el clasificador ha propuesto con éxito en el pasado (sin mencionar cualquier castigos), y el factor de proximidad al ganador. billete como se explicó anteriormente. La gorra debe ser la misma. como los daños punitivos pagados al validator en el caso de ellos enviando un bloque no válido. Para disuadir a los recopiladores de enviar candidatos de bloque no válidos o con sobrepeso a validators, cualquier validator puede colocar en el siguiente bloque una transacción que incluya el bloque infractor que alega mala conducta con el efecto de transferir parte o la totalidad de los fondos en la cuenta del cotejador que se porta mal. cuenta al agraviado validator. Este tipo de transacción anticipa cualquier otra para garantizar que el clasificador no pueda retirar los fondos antes del castigo. la cantidad de Los fondos transferidos como daños y perjuicios son un parámetro dinámico todavía.

POLKADOT: VISIÓN PARA UN MARCO MULTICADENA HETEROGÉNEO BORRADOR 1 14 se modelará, pero probablemente será una proporción de la recompensa del bloque validator para reflejar el nivel de duelo causado. a Para evitar que validators maliciosos confisquen arbitrariamente los fondos de los cotejadores, el cotejador puede apelar la decisión de validator ante un jurado de validators elegidos al azar a cambio Para realizar un pequeño depósito. Si fallan a favor de validator, el depósito es consumido por ellos. Si no, el Se devuelve el depósito y se multa el validator (ya que el validator está en una posición mucho más abovedada, la multa probablemente sea bastante pesado). 6.6. Intercadena Transacción Enrutamiento. Intercadena El enrutamiento de transacciones es uno de los mantenimientos esenciales. tareas de la cadena de relés y sus validators. Este es el Lógica que rige cómo una transacción publicada (a menudo abreviada como simplemente "publicar") pasa de ser un resultado deseado. de una parachain de origen a ser una entrada no negociable de otra parachain de destino sin ninguna confianza requisitos. Elegimos cuidadosamente la redacción anterior; notablemente nosotros no requiere que haya habido una transacción en la fuente parachain haber sancionado explícitamente esta publicación. el unico limitaciones que imponemos a nuestro modelo es que las paracaídas debe proporcionar, empaquetado como parte de su bloque general salida del procesamiento, las publicaciones que son el resultado de la ejecución del bloque. Estas publicaciones están estructuradas como varias colas FIFO; el número de listas se conoce como base de enrutamiento y puede ser alrededor de 16. En particular, este número representa la cantidad de paracaídas que podemos soportar sin tener que recurrir a enrutamiento multifase. Inicialmente, Polkadot admitirá esto tipo de ruta directa, sin embargo, describiremos una posible proceso de enrutamiento multifase (“hiperenrutamiento”) como medio de escalar mucho más allá del conjunto inicial de paracaídas. nosotros asumir eso todos participantes saber el subgrupos para los dos bloques siguientes n, n + 1. En resumen, el El sistema de enrutamiento sigue estas etapas: • CollatorS: miembros de contacto de V alidators[n][S] • Clasificadores: PARA CADA subgrupo: asegurar al menos al menos 1 miembro de V alidators[n][s] en contacto • Alzadoras: PARA CADA subgrupo s: asumir salida[n −1][s][S] está disponible (todas las publicaciones entrantes datos a 'S' del último bloque) • Alzadoras: Componga el bloque candidato b para S: (b.encabezado, b.ext, b.prueba, b.recibo, b.salida) • Alzadoras: enviar prueba información prueba[S] = (b.encabezado, b.ext, b.prueba, b.recibo) a V alidadores[n][S] • CollatorS: garantiza datos de transacciones externas b.ext se pone a disposición de otros alzadores y validators • Alzadoras: PARA CADA UNO subgrupo es: enviar salida información salida[n][S][s] = (b.encabezado, b.recibo, b.salida[s]) a el recibiendo subgrupos miembros de siguiente bloquear V alidadores[n + 1][s] • V alidatorV: preconecta todos los miembros del mismo conjunto para el siguiente bloque: sea N = Chain[n + 1][V]; conectar todos los validators v tales que Chain[n + 1][v] = N • ValidadorV : Cotejar todos los datos ingresados para esto bloque: PARA CADA UNO subgrupo es: recuperar salida[n −1][s][Chain[n][V ]], obtenga de otros validators v tal que Chain[n][v] = Chain[n][V ]. Posiblemente recurriendo a otros validator seleccionados al azar como prueba del intento. • ValidadorV : Aceptar pruebas candidatas para esto. prueba de bloque[Cadena[n][V ]]. Validez del bloque de votos • ValidadorV : Aceptar datos de salida del candidato para siguiente bloque: PARA CADA subgrupo, aceptar salida[n][s][N]. Disponibilidad de salida del bloque de votación; volver a publicar entre los validators interesados v de modo que Cadena[n + 1][v] = Cadena[n + 1][V]. • V alidadorV : HASTA EL CONSENSO Donde: salida[n][desde][hasta] es la cola de salida actual información para publicaciones que van desde parachain 'desde', hasta parachain 'a' en el bloque número 'n'. CollatorS es un clasificador para parachain S. V alidators[n][s] es el conjunto de validators para parachain s en el bloque número n. Por el contrario, Chain[n][v] es la paracadena a la que se asigna validator v en el bloque número n. block.egress[to] es la salida cola de publicaciones de algún bloque de parachain cuyo El destino de la parachain es. Dado que los alzadores cobran tarifas (de transacción) basadas en sus bloques se vuelven canónicos y se les incentiva a asegúrese de que para cada destino del siguiente bloque, el subgrupo los miembros son informados de la cola de salida del presente bloque. Los validadores solo están incentivados a formar un consenso sobre un bloque (parachain), como tal, les importa poco cuyo bloque de alzador finalmente se vuelve canónico. en En principio, un validator podría formar una alianza con un recopilador y conspirar para reducir las posibilidades de que otros recopiladores Los bloques se vuelven canónicos, sin embargo, esto es difícil. para organizar debido a la selección aleatoriación de validators para parachains y podría defenderse con una reducción en las tarifas pagaderas por los bloques de parachain que resisten el proceso de consenso. 6.6.1. Disponibilidad de datos externos. Garantizar la seguridad de una paracadena La disponibilidad de datos externos es un problema constante con sistemas descentralizados destinados a distribuir la carga de trabajo entre la red. El meollo del problema es la disponibilidad problema que establece que dado que no es posible hacer una prueba de disponibilidad no interactiva ni ningún tipo de prueba de no disponibilidad, para que un sistema BFT funcione correctamente validar cualquier transición cuya corrección dependa de la disponibilidad de algunos datos externos, el número máximo de nodos aceptablemente bizantinos, más uno, del sistema debe dar fe de que los datos están disponibles. Para que un sistema se amplíe correctamente, como Polkadot, esto invita a un problema: si una proporción constante de validators debe dar fe de la disponibilidad de los datos, y suponiendo que validators realmente querrá almacenar los datos antes de afirmar que están disponibles, entonces, ¿cómo evitamos el ¿Problema de que los requisitos de ancho de banda/almacenamiento aumentan con el tamaño del sistema (y por lo tanto con el número de validators)? Una posible respuesta sería tener un conjunto separado de validators (garantes de disponibilidad), cuyo pedido crece sublinealmente con el tamaño de Polkadot en su conjunto. esto es descrito en 6.5.3. También tenemos un truco secundario. Como grupo, los recopiladores tienen un incentivo intrínseco para garantizar que todos los datos sean disponible para su parachain elegido ya que sin él no pueden crear más bloques a partir de los cuales puedan cobrar tarifas de transacción. Los recopiladores también forman un grupo cuya composición es variada (debido a la naturaleza aleatoria de parachain validator grupos) no trivial de ingresar y fácil

POLKADOT: VISIÓN PARA UN MARCO MULTICADENA HETEROGÉNEO BORRADOR 1 15 para probar. Por lo tanto, a los recopiladores recientes (quizás de los últimos miles de bloques) se les permite emitir desafíos a la disponibilidad de datos externos para una parachain en particular bloquee a validators para obtener un pequeño bono. Los validadores deben comunicarse con aquellos del subgrupo validator aparentemente infractor que testificó y adquirir y devolver los datos al recopilador o escalar la situación. asunto testificando sobre la falta de disponibilidad (la negativa directa a proporcionar los datos cuenta como un delito de confiscación de fianza, por lo tanto, el mal comportamiento de validator probablemente solo desconectar la conexión) y contactar a validators adicionales para ejecutar la misma prueba. En este último caso, la fianza del alzador es devuelto. Una vez que se alcanza un quórum de validators que pueden hacer dichos testimonios de no disponibilidad, son liberados, el El subgrupo que se porta mal es castigado y el bloqueo se revierte. 6.6.2. Enrutamiento de publicaciones. Cada encabezado de parachain incluye un salida-trie-raíz; esta es la raíz de un trie que contiene el contenedores de base de enrutamiento, siendo cada contenedor una lista concatenada de puestos de salida. Se pueden proporcionar pruebas de Merkle en parachain validators para demostrar que una parachain en particular El bloque tenía una cola de salida particular para una parachain de destino particular. Al comienzo del procesamiento de un bloque de parachain, cada La cola de salida de otra parachain con destino a dicho bloque es fusionado en la cola de ingreso de nuestro bloque. Asumimos fuerte, probablemente CSPR9, ordenamiento de subbloques para lograr una operación determinista que no ofrece favoritismo entre ningún Emparejamiento de bloques de paracaídas. Los alzadores calculan la nueva cola y drenar las colas de salida de acuerdo con la parachain lógica. El contenido de la cola de entrada está escrito explícitamente. en el bloque de parachain. Esto tiene dos propósitos principales: En primer lugar, significa que la paracaídas se puede sincronizar sin confianza de forma aislada de las otras paracaídas. En segundo lugar, Simplifica la logística de datos en caso de que todo el ingreso la cola no se puede procesar en un solo bloque; validators y alzadoras pueden procesar los siguientes bloques sin tener que obtener los datos de la cola especialmente. Si la cola de ingreso de la parachain está por encima de un umbral cantidad al final del procesamiento del bloque, luego se marca saturado en la cadena de relés y no pueden recibir más mensajes. se le entregará hasta que sea liquidado. Las pruebas de Merkle son utilizado para demostrar la fidelidad del funcionamiento de la alzadora en La prueba del bloque parachain. 6.6.3. Crítica. Un defecto menor relacionado con este básico El mecanismo es el ataque posterior a la bomba. Aquí es donde todos Las paracaídas envían la máxima cantidad de publicaciones posibles. a una paracadena en particular. Si bien esto ata el objetivo cola de ingreso a la vez, no se produce ningún daño más allá un ataque DoS de transacción estándar. Funcionando con normalidad, con un conjunto de bien sincronizados y alzadores no maliciosos y validators, para N parachains, N × M total validators y L alzadoras por parachain, nosotros Puede desglosar las rutas de datos totales por bloque para: Validador: M −1+L+L: M −1 para los otros validators en el conjunto de parachain, L para cada alzador que proporciona un bloque de parachain candidato y un segundo L para cada alzador del siguiente bloque que requiere las cargas útiles de salida del bloque anterior. (Esto último es en realidad más bien el peor de los casos). operación ya que es probable que los alzadores compartan dichos datos.) Alzador: M +kN: M para una conexión a cada uno relevante bloque de parachain validator, kN para sembrar las cargas útiles de salida en algún subconjunto de cada grupo de parachain validator para el siguiente bloque (y posiblemente algún clasificador favorito). Como tal, las rutas de datos por nodo crecen linealmente con la complejidad general del sistema. Si bien esto es Es razonable, a medida que el sistema se escala a cientos o miles de paracaídas, es posible que se produzca cierta latencia en la comunicación. absorbido a cambio de una menor tasa de crecimiento de la complejidad. En este caso, se puede utilizar un algoritmo de enrutamiento de múltiples fases. para reducir el número de vías instantáneas a costa de introducir buffers de almacenamiento y latencia. 6.6.4. Enrutamiento de hipercubo. El enrutamiento de hipercubos es un mecanismo que en su mayoría puede construirse como una extensión del mecanismo de enrutamiento básico descrito anteriormente. Esencialmente, en lugar de aumentar la conectividad de los nodos con la cantidad de paracaídas y nodos de subgrupos, crecemos solo con el logaritmo de las paracaídas. Los correos pueden transitar entre colas de varias paracaídas en su camino hacia la entrega final. El enrutamiento en sí es determinista y simple. Empezamos por limitar el número de contenedores en las colas de entrada/salida; en lugar de ser el número total de paracaídas, son son losbase de enrutamiento (b). Esto se fijará como el número de cambios de paracaídas, y en su lugar se eleva el exponente de enrutamiento (e). Bajo este modelo, nuestro volumen de mensajes crece con O(be), y las vías permanecen constantes y la latencia (o número de bloques necesarios para la entrega) con O(mi). Nuestro modelo de enrutamiento es un hipercubo de dimensiones e, teniendo cada lado del cubo b posibles ubicaciones. En cada bloque, enrutamos mensajes a lo largo de un solo eje. nosotros alterne el eje en forma circular, garantizando así el peor tiempo de entrega de los bloques e. Como parte del procesamiento de parachain, con destino al extranjero Los mensajes que se encuentran en la cola de entrada se enrutan inmediatamente al contenedor de la cola de salida correspondiente, dada la número de bloque actual (y, por tanto, dimensión de enrutamiento). esto El proceso requiere una transferencia de datos adicional para cada salto. en la ruta de entrega, sin embargo, esto es un problema en sí mismo. que puede mitigarse mediante el uso de algunos medios alternativos de entrega de carga útil de datos e incluye solo una referencia, en lugar de la carga útil completa de la publicación en el post-trie. Un ejemplo de enrutamiento de hipercubo para un sistema con 4 paracaídas, b = 2 y e = 2 podrían ser: Fase 0, en cada mensaje M: • sub0: si Mdest ∈{2, 3} entonces sendTo(2) en caso contrario mantener • sub1: si Mdest ∈{2, 3} entonces sendTo(3) en caso contrario mantener • sub2: si Mdest ∈{0, 1} entonces sendTo(0) en caso contrario mantener • sub3: si Mdest ∈{0, 1} entonces sendTo(1) en caso contrario mantener Fase 1, en cada mensaje M: • sub0: si Mdest ∈{1, 3} entonces sendTo(1) en caso contrario mantener • sub1: si Mdest ∈{0, 2} entonces sendTo(0) en caso contrario mantener • sub2: si Mdest ∈{1, 3} entonces sendTo(3) en caso contrario mantener • sub3: si Mdest ∈{0, 2} entonces sendTo(2) en caso contrario mantener Las dos dimensiones aquí son fáciles de ver como la primera. dos bits del índice de destino; para el primer bloque, el Se utiliza solo el bit de orden superior. El segundo bloque trata con el bit de orden inferior. Una vez que ambas cosas suceden (en forma arbitraria) pedido) entonces la publicación será enrutada. 9 pseudoaleatorio criptográficamente seguro

POLKADOT: VISIÓN PARA UN MARCO MULTICADENA HETEROGÉNEO BORRADOR 1 16 6.6.5. Maximizando la serendipia. Una alteración de lo básico. propuesta vería un total fijo de c2 −c validators, con c−1 validators en cada subgrupo. Cada bloque, en lugar de hay una repartición no estructurada de validators entre paracaídas, en lugar de cada subgrupo de paracaídas, cada validator sería asignado a un único y diferente subgrupo parachain en el siguiente bloque. esto seria llevar a la invariante que entre dos bloques cualesquiera, para cualquier dos pares de parachain, existen dos validators que han intercambiado responsabilidades de parachain. Si bien esto no puede utilizarse para obtener garantías absolutas de disponibilidad (un solo validator ocasionalmente se desconectará, incluso si benévolo), no obstante, puede optimizar el caso general. Este enfoque no está exento de complicaciones. La adición de una paracadena también requeriría una reorganización del conjunto validator. Además, el número de validator, vinculado al cuadrado del número de paracaídas, comenzaría inicialmente muy pequeño y eventualmente crecería mucho demasiado rápido, volviéndose insostenible después de alrededor de 50 paracaídas. Ninguno de estos son problemas fundamentales. En el primer caso, La reorganización de conjuntos validator es algo que debe realizarse. hecho regularmente de todos modos. Respecto al tamaño del validator establecido, cuando es demasiado pequeño, se pueden asignar varios validator a la misma paracadena, aplicando un factor entero a la total general de validators. Un mecanismo de enrutamiento de múltiples fases como el enrutamiento Hypercube, discutido en 6.6.4, aliviar el requisito de una gran cantidad de validators cuando hay una gran cantidad de cadenas. 6.7. Validación de paracadena. El propósito principal de un validator es testificar, como actor bien vinculado, que una paracadena El bloque es válido, incluyendo, entre otros, cualquier transición de estado, cualquier transacción externa incluida, la ejecución de cualquier puesto de espera en la cola de ingreso y el estado final de la cola de salida. El proceso en sí es bastante sencillo. Una vez que el validator selló el bloque anterior quedan libres para comenzar a trabajar para proporcionar un bloque de parachain candidato candidato para la próxima ronda de consenso. Inicialmente, el validator encuentra un candidato a bloque de parachain a través de un intercalador de parachain (descrito a continuación) o uno de sus co-validators. Los datos candidatos del bloque parachain incluye el encabezado del bloque, el encabezado del bloque anterior, cualquier dato de entrada externo incluido (para Ethereum y Bitcoin, dichos datos se denominarían transacciones; sin embargo, en principio pueden incluir estructuras de datos arbitrarias para fines arbitrarios), datos de la cola de salida y datos internos para demostrar la validez de la transición de estado (para Ethereum (estos serían los distintos nodos de prueba de estado/almacenamiento necesarios para ejecutar cada transacción). La evidencia experimental muestra este conjunto de datos completo para un bloque Ethereum reciente ser como máximo unos cientos de KiB. Simultáneamente, si aún no se ha hecho, el validator será intentar recuperar información relativa a la transición del bloque anterior, inicialmente del bloque anterior validators y posteriores de todos los validators que firman para el disponibilidad de los datos. Una vez que validator haya recibido dicho bloque candidato, luego lo validan localmente. El proceso de validación está contenido dentro del módulo validator de la clase parachain, un módulo de software sensible al consenso que debe escribirse para cualquier implementación de Polkadot (aunque en principio una biblioteca con una C ABI podría permitir que una sola biblioteca ser compartido entre implementaciones con el apropiado reducción de la seguridad derivada de tener una sola implementación de “referencia”). El proceso toma el encabezado del bloque anterior y verifica su identidad a través de la cadena de retransmisión recientemente acordada. bloque en el que se debe registrar su hash. Una vez que se determina la validez del encabezado principal, la paracadena específica Se puede llamar a la función de validación de la clase. Esta es una función única que acepta varios campos de datos (aproximadamente los dados anteriormente) y devolver un valor booleano simple proclamando la validez del bloque. La mayoría de estas funciones de validación comprobarán primero la campos de encabezado que pueden derivarse directamente de el bloque principal (por ejemplo, padre hash, número). Siguiendo esto, llenarán cualquier estructura de datos interna como necesarios para procesar transacciones y/o publicaciones. Para una cadena similar a Ethereum, esto equivale a poblar una Pruebe la base de datos con los nodos que serán necesarios para la ejecución completa de las transacciones. Otros tipos de cadenas pueden tener otro pMecanismos reparadores. Una vez hecho esto, las publicaciones de ingreso y las transacciones externas (o lo que sea que representen los datos externos) serán promulgado, equilibrado según las especiﬁcaciones de la cadena. (Un El valor predeterminado sensato podría ser exigir que todas las publicaciones de ingreso sean procesado antes de que se atiendan las transacciones externas, sin embargo, esto debería ser decisión de la lógica de la parachain). A través de esta promulgación, se establecerán una serie de puestos de salida creados y se verificará que estos efectivamente coincidan el candidato del clasificador. Finalmente, el lugar debidamente poblado El encabezado se comparará con el encabezado del candidato. Con un bloque candidato completamente validado, el validator Luego puede votar por el hash de su encabezado y enviar toda la información de validación necesaria a los co-validators de su subgrupo. 6.7.1. Alzadores de paracaídas. Los alzadores de Parachain son operadores no vinculados que cumplen gran parte de la tarea de los mineros. en las redes blockchain actuales. son especificos a una paracadena en particular. Para poder operar deben mantener tanto la cadena de relevos como el sistema completamente sincronizado. paracadena. El significado preciso de "completamente sincronizado" dependerá de la clase de parachain, aunque siempre incluirá el estado actual de la cola de ingreso de parachain. En el caso de Ethereum también implica al menos mantener una base de datos Merkle-tree de los últimos bloques, pero podría También incluye varias otras estructuras de datos, incluido Bloom. Filtros para la existencia de cuentas, información familiar, registro. salidas y tablas de búsqueda inversa para el número de bloque. Además de mantener sincronizadas las dos cadenas, También debe “pescar” transacciones manteniendo una cola de transacciones y aceptando transacciones validadas adecuadamente. de la red pública. Con la cola y la cadena, es capaz de crear nuevos bloques candidatos para los validators elegidos en cada bloque (cuya identidad se conoce ya que la cadena de retransmisión está sincronizada) y enviarlos, junto con el diversa información auxiliar, como prueba de validez, a través de la red de pares. Por su problema, cobra todas las tarifas relacionadas con las transacciones que incluye. Varias economías flotan en torno a esto. arreglo. En un mercado altamente competitivo donde hay hay un excedente de alzadoras, es posible que la transacción las tarifas se compartirán con la parachain validators para incentivar la inclusión de un bloque alzador particular. Similarmente,

POLKADOT: VISIÓN PARA UN MARCO MULTICADENA HETEROGÉNEO BORRADOR 1 17 algunos alzadores pueden incluso aumentar los honorarios requeridos a pagar para hacer el bloque más atractivo para validators. En este caso, debería formarse un mercado natural. con transacciones que pagan tarifas más altas y se saltan la cola y tener una inclusión más rápida en la cadena. 6.8. Redes. Creación de redes en blockchains tradicionales como Ethereum y Bitcoin tiene requisitos bastante simples. Todas las transacciones y bloqueos se transmiten en un simple chisme no dirigido. La sincronización es más complicada, especialmente con Ethereum pero en realidad esta lógica estaba contenida en la estrategia de pares en lugar del protocolo en sí, que se resolvió en torno a algunos tipos de mensajes de solicitud y respuesta. Si bien Ethereum avanzó en las ofertas de protocolos actuales con el protocolo devp2p, que permitió a muchos Los subprotocolos se multiplexarán a través de una única conexión de pares y, por lo tanto, tendrán la misma superposición de pares. Admiten muchos protocolos p2p simultáneamente, la parte Ethereum de el protocolo seguía siendo relativamente simple y el p2p El protocolo por ahora permanece inconcluso con importantes Faltan funciones como la compatibilidad con QoS. Lamentablemente, el deseo de crear un protocolo “web 3” más ubicuo se ha extendido en gran medida. falló, y los únicos proyectos que lo utilizaron fueron aquellos explícitamente financiado por la venta colectiva Ethereum. Los requisitos para Polkadot son bastante más sustanciales. Más bien una red totalmente uniforme, Polkadot tiene varios tipos de participantes, cada uno con diferentes requisitos sobre la composición de sus pares y varias redes “vías” cuyos participantes tenderán a conversar sobre datos particulares. Esto significa una superposición de red sustancialmente más estructurada (y un protocolo que la respalde). probablemente será necesario. Además, la extensibilidad para facilitar adiciones futuras, como nuevos tipos de “cadenas”, puede ellos mismos requieren una estructura superpuesta novedosa. Si bien una discusión en profundidad sobre cómo la creación de redes El protocolo puede parecer fuera del alcance de este documento, algunos análisis de requisitos son razonables. podemos dividir aproximadamente a los participantes de nuestra red en dos conjuntos (cadena de relés, paracaídas) cada uno de los tres subconjuntos. podemos También indique que cada uno de los participantes de parachain son solo interesados en conversar entre ellos mismos en lugar de participantes en otras paracaídas: • Participantes de la cadena de retransmisiones: • Validadores: P, dividido en subconjuntos P[s] para cada paracaídas • Garantes de Disponibilidad: A (esto puede estar representado por Validadores en la forma básica del protocolo) • Clientes de cadena de retransmisión: M (nota los miembros de cada El conjunto de paracadenas también tenderá a ser miembros de M) • Participantes de Parachain: • Alzadores de Parachain: C[0], C[1], . . . • Pescadores de Parachain: F[0], F[1],. . . • Clientes de Parachain: S[0], S[1], . . . • Clientes ligeros de Parachain: L[0], L[1], . . . En general nombramos clases particulares de comunicación. tenderá a tener lugar entre miembros de estos conjuntos: • P | un <-> P | R: el lleno conjunto de validators/garantes debe ser bien conectado a lograr consenso. • P[s] <-> C[s] | P[s]: Cada validator como miembro de un grupo parachain determinado tenderá a chismorrear con otros miembros similares, así como con los coladores de esa parachain para descubrir y compartir candidatos de bloque. • A <-> P[s] | C | R: Cada garante de disponibilidad necesitará recopilar cadenas cruzadas sensibles al consenso datos de los validators que se le asignaron; alzadoras también puede optimizar las posibilidades de consenso sobre sus bloquear anunciándolo a los garantes de disponibilidad. Una vez que los tengan, los datos serán desembolsados a otro garante similar para facilitar el consenso. • P[s] <-> A | P[s']: Parachain validators Es necesario recopilar datos de entrada adicionales del conjunto anterior de validators o de los garantes de disponibilidad. • F[s] <-> P: Al informar, los pescadores pueden colocar un reclamo ante cualquier participante. • M <-> M | P | R: Los clientes generales de la cadena de retransmisión desembolsan datos de validators y garantes. • S[s] <-> S[s] | P[s] | R: Los clientes de Parachain desembolsan datos de validator/garantes. • L[s] <-> L[s] | S[s]: clientes ligeros de Parachain desembolsar datos de los clientes completos. Para garantizar un mecanismo de transporte eficiente, se necesita un red superpuesta, como devp2p de Ethereum, donde cada El nodo no diferencia (no arbitrariamente) la idoneidad de sus Es poco probable que sus compañeros sean adecuados. Un razonablemente extensible Es probable que se necesite un mecanismo de selección y descubrimiento de pares. para ser incluido dentro del protocolo así como agresivo planificar una anticipación para garantizar el tipo correcto de pares están conectados “por casualidad”realizado en el momento adecuado. La estrategia precisa de composición de pares será diferente para cada clase de participante: para una escala adecuadamente ampliada multicadena, las alzadoras deberán estar continuamente reconectarse con los validators elegidos en consecuencia, o lo haremos Necesita acuerdos continuos con un subconjunto de validators. para asegurar que no estén desconectados durante la gran mayoría del tiempo que son inútiles para ese validator. Naturalmente, los alzadores también intentarán mantener uno o conexiones más estables en el garante de disponibilidad preparados para garantizar una rápida propagación de sus políticas sensibles al consenso. datos. Los garantes de disponibilidad intentarán principalmente mantener una conexión estable entre sí y con validators (para el consenso y los datos de parachain críticos para el consenso a los que dan fe), así como a algunos alzadores (para el parachain datos) y algunos pescadores y clientes completos (para dispersar información). Los validadores tenderán a buscar otros validator, especialmente aquellos en el mismo subgrupo y cualquier alzadores que puedan suministrarles candidatos a bloques de parachain. Pescadores, así como cadenas de relevos y paracaídas en general. Los clientes generalmente intentarán mantener una conexión abierta a un validator o garante, pero muchos otros nodos similares a sí mismos de otra manera. Los clientes ligeros de Parachain también intentarán estar conectados a un cliente completo de parachain, si no solo otros clientes ligeros de parachain. 6.8.1. El problema de la rotación de pares. En la propuesta de protocolo básico, cada uno de estos subconjuntos se modifica constantemente de forma aleatoria con cada bloque como los validators asignados para verificar las transiciones de parachain se eligen al azar. esto puede ser un problema si es necesario conectar nodos dispares (no pares). pasar datos entre sí. Uno debe confiar en una red de pares bastante distribuida y bien conectada para

POLKADOT: VISIÓN PARA UN MARCO MULTICADENA HETEROGÉNEO BORRADOR 1 18 Asegúrese de que la distancia de salto (y, por lo tanto, la latencia en el peor de los casos) solo crezca con el logaritmo del tamaño de la red. (un protocolo similar a Kademlia [13] puede ayudar aquí), o uno debe introducir tiempos de bloqueo más largos para permitir que se lleve a cabo la negociación de conexión necesaria para mantener un conjunto de pares que Refleja las necesidades de comunicación actuales del nodo. Ninguna de estas son grandes soluciones: tiempos de bloqueo prolongados ser forzado a la red puede hacerla inútil para aplicaciones y cadenas particulares. Incluso un perfectamente justo y la red conectada provocará un desperdicio sustancial del ancho de banda a medida que escala debido a que los nodos desinteresados tienen transmitirles datos que no les son útiles. Si bien ambas direcciones pueden formar parte de la solución, una optimización razonable para ayudar a minimizar la latencia sería ser para restringir la volatilidad de estas parachain validator conjuntos, ya sea reasignando la membresía solo entre series de bloques (por ejemplo, en grupos de 15, que a los 4 segundos El tiempo de bloqueo significaría alterar las conexiones solo una vez por minuto) o rotando los miembros de forma incremental, p. cambiando por un miembro a la vez (por ejemplo, si hay hay 15 validators asignados a cada parachain, entonces, en promedio, sería un minuto completo entre completamente únicos conjuntos). Limitando la cantidad de abandono de pares y garantizando que las conexiones ventajosas entre pares se establezcan bien en avanzar a través de la previsibilidad parcial de parachain conjuntos, podemos ayudar a garantizar que cada nodo mantenga un estado permanente selección fortuita de compañeros. 6.8.2. Camino hacia un protocolo de red eficaz. Probablemente el El esfuerzo de desarrollo más efectivo y razonable se centrará en utilizar un protocolo preexistente en lugar de implementarlo. el nuestro. Existen varios protocolos base peer-to-peer que Podemos usar o aumentar, incluido el propio devp2p de Ethereum. [22], libp2p de IPFS [1] y GNUnet de GNU [4]. Una revisión completa de estos protocolos y su relevancia para construir un Red modular de pares que admite ciertas garantías estructurales, dirección dinámica de pares y subprotocolos extensibles. está mucho más allá del alcance de este documento, pero será una paso importante en la implementación de Polkadot. 7. Aspectos prácticos del Protocolo 7.1. Pago de transacciones entre cadenas. Si bien es un gran Se gana mucha libertad y simplicidad al eliminar la necesidad de un marco de contabilidad de recursos computacionales holístico como el gas de Ethereum, esto plantea una pregunta importante: sin gas, ¿cómo se puede hacer parachain? ¿Evitar que otra paracadena la obligue a realizar cálculos? Si bien podemos confiar en la cola de ingreso posterior a las transacciones buffers para evitar que una cadena envíe spam a otra con datos de transacciones, no existe ningún mecanismo equivalente proporcionado por el protocolo para evitar el spam del procesamiento de transacciones. Este es un problema que se deja al nivel superior. desde cadenas son libres de adjuntar semántica arbitraria al mensaje entrante datos de publicación de transacciones, podemos garantizar que el cálculo debe pagarse antes de comenzar. En una línea similar a la modelo adoptado por Ethereum Serenidad, podemos imaginar un contrato de "intrusión" dentro de una paracadena que permite una validator se le garantizará el pago a cambio del provisión de un volumen particular de recursos de procesamiento. Estos recursos pueden medirse en algo como gas, pero también podría ser algún modelo completamente nuevo, como el tiempo de ejecución subjetivo o un modelo de tarifa fija similar a Bitcoin. Por sí solo, esto no es tan útil, ya que no podemos asumir fácilmente que la persona que llama fuera de la cadena tenga disponible cualquier mecanismo de valor que sea reconocido por el robo contrato. Sin embargo, podemos imaginar un contrato secundario de “ruptura” en la cadena de origen. Los dos contratos juntos formarían un puente, reconociéndose mutuamente y proporcionando equivalencia de valor. (Replanteo-tokens, disponible para cada uno, podría utilizarse para liquidar la balanza de pagos.) Llamar a otra cadena similar significaría hacer proxy a través de este puente, que proporcionaría los medios para negociar la transferencia de valor entre cadenas para pagar los recursos informáticos necesarios en la parachain de destino. 7.2. Adicional Cadenas. mientras el adición de un Parachain es una operación relativamente barata, no es gratuita. Más paracaídas significa menos validators por paracaídas y, eventualmente, un número mayor de validators cada uno con un bono promedio reducido. Si bien la cuestión de un menor costo de coerción por atacar una parachain se mitiga mediante pescadores, el creciente conjunto validator esencialmente obliga a Mayor grado de latencia debido a la mecánica del consenso subyacente.método. Además, cada paracadena trae consigo el potencial de entristecer a validators con un Algoritmo de validación demasiado engorroso. Como tal, habrá algún “precio” que validators y/o la comunidad interesada extraerá para el Adición de una nueva paracadena. Este mercado de cadenas posiblemente vea la adición de: • Cadenas que probablemente tengan un pago de contribución neta cero (en términos de bloquear o quemar staking tokens) para formar parte (por ejemplo, cadenas de consorcio, cadenas Doge, cadenas específicas de aplicaciones); • cadenas que entregan valor intrínseco a la red mediante la adición de una funcionalidad particular difícil llegar a otra parte (por ejemplo, confidencialidad, escalabilidad interna, vinculaciones de servicios). Esencialmente, la comunidad de partes interesadas necesitará ser incentivado a agregar cadenas infantiles, ya sea financiera o a través del deseo de agregar cadenas características al relevo. Se prevé que las nuevas cadenas añadidas tendrán un efecto muy breve plazo de aviso para la retirada, lo que permite la instalación de nuevas cadenas. ser experimentado sin ningún riesgo de comprometer la propuesta de valor a medio o largo plazo. 8. Conclusión Hemos esbozado una dirección que uno puede tomar para escribir un Protocolo multicadena heterogéneo y escalable con el potencial de ser compatible con ciertas versiones preexistentes. blockchain redes. Según dicho protocolo, los participantes trabajar con un interés propio ilustrado para crear un sistema global que pueda ampliarse de una manera excepcionalmente gratuita y sin el coste típico para los usuarios existentes que proviene de un diseño estándar blockchain. hemos dado un esbozo aproximado de la arquitectura que se necesitaría, incluyendo la naturaleza de los participantes, sus incentivos económicos y los procesos bajo los cuales deben participar. tenemos identificó un diseño básico y discutió sus fortalezas y limitaciones; en consecuencia tenemos más direcciones que puede aliviar esas limitaciones y avanzar más hacia una solución blockchain totalmente escalable.POLKADOT: VISIÓN PARA UN MARCO MULTICADENA HETEROGÉNEO BORRADOR 1 19 8.1. Material faltante y preguntas abiertas. La bifurcación de red siempre es una posibilidad debido a implementaciones divergentes del protocolo. La recuperación de tal La condición excepcional no fue discutida. Dado que la red necesariamente tendrá un período de finalización distinto de cero, No debería ser un gran problema recuperarse de la bifurcación de la cadena de retransmisión, sin embargo, requerirá una integración cuidadosa en el protocolo de consenso. La confiscación de bonos y, a la inversa, la provisión de recompensas no ha sido explorado profundamente. Actualmente asumimos recompensas. se proporcionan sobre la base de que el ganador se lo lleva todo: es posible que esto no Ofrecer el mejor modelo de incentivos para los pescadores. Un proceso de confirmación-revelación de corto plazo permitiría a muchos pescadores para reclamar el premio dando una distribución más justa de las recompensas, sin embargo, el proceso podría provocar una latencia adicional en el descubrimiento de mala conducta. 8.2. Expresiones de gratitud. Muchas gracias a todos los correctores que han ayudado a que esto quede vagamente forma presentable. En particular, Peter Czaban, Björn Wagner, Ken Kappler, Robert Habermeier, Vitalik Buterin, Reto Trinkler y Jack Petersson. gracias a todos las personas que han aportado ideas o los inicios Entre ellos, merecen una mención especial Marek Kotewicz y Aeron Buchanan. Y gracias a todos los demás por su ayuda. a lo largo del camino. Todos los errores son míos. Partes de este trabajo, incluida la investigación inicial sobre algoritmos de consenso, fue financiado en parte por los británicos Gobierno bajo el programa Innovate UK.