Polkadot：异构多链框架的愿景

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

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.

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.

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.

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 identificado 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 confirmació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.

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 especificaciones 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.