Análisis de Cadenas Paralelas: Proceso de Implementación, Dificultades Técnicas, Dirección de Desarrollo Futuro, etc

¡Únase a la comunidad de PolkaWorld y construyan juntos la Web 3.0! ¿Cómo cambió la parachain de un trabajo de investigación a una implementación de código? ¿Cómo se desarrollarán en el futuro los subprocesos paralelos, las cadenas de retransmisión anidadas, etc.? ¿Dónde está el límite de escalabilidad de parachain? En la mesa redonda de Polkadot Decoded de 2021 "Análisis de las cadenas paralelas: ¿Quién creó las cadenas paralelas? ¿Qué son las cadenas paralelas? ¿Por qué hay paracadenas?", el investigador Jeff, el implementador de código Rob y el moderador Joe discutieron algunos temas relacionados con las paracadenas. desarrollo. PolkaWorld resume el contenido principal de la mesa redonda en este artículo. Jeff: Jeff Burdges, investigador de criptografía de W3F, ha investigado mucho sobre el desarrollo de parachain Rob: Robert Habermeier, cofundador de Polkadot/desarrollador principal de Parity, dirigió el equipo de implementación para hacer que las parachains se ejecutaran en la práctica Joe: Joe Petrowski, director técnico Integración, W3F, anfitrión de esta mesa redonda Joe: Hace aproximadamente un año y medio, Jeff lideró un equipo que publicó un artículo sobre usabilidad y efectividad. En el momento de la implementación, este esquema ha cambiado mucho. Jeff, ¿puedes hablar brevemente sobre cómo surgió la idea de este artículo? Jeff: Obtuvimos algunas ideas del ecosistema Ethereum, como la idea de usar códigos de borrado. Pero algunas cosas específicas en torno a estas ideas, como la forma de optimizar la fragmentación, no se han formalizado. A fines de 2019, decidimos formalizar estas ideas y proponer un enfoque más preciso. En general, de la forma en que diseñamos protocolos complejos, escribiría todas las opciones de diseño posibles y luego usaría el proceso de eliminación. A principios de 2020, escribí este diseño y lo discutí con todos. Notamos algunos problemas y se me ocurrió una técnica llamada "Inclusión de dos fases". Es decir, antes de que realmente comience, la cadena de retransmisión de parachain debe conocer un bloque, y el verificador debe decir que este bloque es válido. Luego comenzamos a hacer la codificación de borrado y luego el trabajo real de verificarlo. Uno de los beneficios de hacer esto es que debido a que alguien tiene mucho interés en el proceso, limita la cantidad de veces que pueden intentarlo. De modo que si lo atacas, también te destruyes a ti mismo. No es seguridad criptográfica, es seguridad de sistema distribuido, pero es razonable. Joe: Lo que acabo de decir puede resultar un poco abstracto para aquellos que no están familiarizados con la fragmentación. De hecho, tenemos mil verificadores. Cuando desea incluir uno de estos bloques de parachain, debe enviar el bloque de datos a todos los verificadores, lo que implica costos, complejidad, red, almacenamiento, etc. Deje que todos tengan que lidiar con esto. mensaje, por lo que realmente desea asegurarse de que estos mensajes sean mensajes válidos, y por una razón. Forbes lanzó la nominación y revisión de la lista Forbes Blockchain Top 50 de 2023: El 14 de octubre, Forbes lanzó la nominación y revisión de la lista Forbes Blockchain Top 50 de 2023. Las empresas nominadas necesitan usar tecnología blockchain Empresas maduras, incluidas empresas con una valoración de más de US $ 1 mil millones o ingresos anuales de más de US $ 1 mil millones. La campaña de nominación durará hasta el 4 de noviembre y los finalistas después de la revisión se anunciarán en febrero de 2023. [2022/10/14 14:28:02] Jeff: Sí. Los códigos de borrado son bastante antiguos y existen diferentes tipos de códigos de borrado. Pero, en términos generales, si usa criptografía, generalmente usa algo basado en la interpolación Lagrangiana o códigos Reed-Solomon. La razón es que tiene un umbral elevado, por lo que podemos recuperar la imagen completa de cualquier tercer fragmento. Entonces, ¿Cómo lo hacemos? Tenemos bloques de parachain, llamados bloques de candidatos, y tenemos validadores 3f+1. Luego, borramos el código de estas cosas en fragmentos 3f+1, y siempre que tenga fragmentos f+1, puede reconstruir el bloque original. En otras palabras, siempre que haya un poco más de 1/3 de fragmentos, puede reconstruir el bloque original. Este es un método matemático muy antiguo que en realidad nos hace más rápidos. De acuerdo con nuestro número actual de validadores, debemos encontrar algunos documentos relativamente nuevos para optimizar. Esto es lo que hicimos este año: optimizar en gran medida el código de borrado. Lo hicimos funcionar 400 veces más rápido, asintóticamente más rápido. De un algoritmo O(N²) a un algoritmo O(log n). Esto hace que los cálculos sean menos engorrosos. Podríamos hacerlo mejor después de eso. Este es nuestro último avance, por supuesto, sería bueno si lo hubiéramos resuelto antes jajaja. Joe: Convertir estos estudios en código es en realidad un gran desafío. Lanzamos la red de prueba Rococo a mediados del año pasado. ¿Puede Rob hablar sobre algunos desafíos encontrados en la implementación temprana de este protocolo? Rob: Recuerdo que el primer envío de código relacionado con la parachain fue en la segunda mitad de 2018. A mediados de 2019, tuvimos el primer borrador del llamado protocolo V0. En los primeros años, invertimos más en BABE, En términos del consenso GRANDPA, es decir, en términos de generación de bloques y confirmación de bloques, en realidad no hubo un estudio en profundidad de parachains en ese momento, porque la parte de parachain es más complicada y requiere más tiempo de desarrollo. Las cosas han progresado mucho desde mediados y finales de 2019 hasta principios de 2020. Como Jeff mencionó hace un momento, el equipo de investigación comenzó a finalizar realmente el acuerdo, como la usabilidad para garantizar que los bloques de parachain aún existan, para que otros humanos puede inspeccionarlos para controles adicionales para garantizar la seguridad. Creo que en realidad es muy difícil realizar todos estos estudios. Si está construyendo cualquier tipo de sistema, cada bit de complejidad adicional que agrega al sistema aumenta exponencialmente el tiempo que lleva crear ese sistema. Esta regla también se aplica al código, porque una vez que alcanzas una cierta cantidad de código, es realmente difícil agregar más cosas, porque las cosas nuevas definitivamente perturbarán y destruirán algunas cosas que se hicieron antes. Por lo tanto, es importante tener un buen diseño y un buen plan, ya medida que iteramos el protocolo, definitivamente iremos de un lado a otro e investigaremos un poco. Pero en 2020, enfocamos nuestra energía en la Guía de implementadores e iteramos allí, no en el código. Puedo hablar por teléfono con Jeff y Al (Alistair) para hablar sobre lo que hay en el borrador y luego escribir una página que diga "así es como escribiremos el código" en lugar de solo escribir el código, y hemos ahorrado semanas. De esta manera, después de eso, puedo asignar el trabajo de escribir código a muchos desarrolladores. Así que creo que es importante tener un buen plan al construir un sistema de este tipo. También hay un sistema modular, de modo que puede agregar una parte independiente del código y puede organizar estos códigos en paquetes pequeños, en lugar de un sistema completo, porque es difícil que una persona maneje un sistema complejo completo. Joe: Hablando de la etapa actual. Ahora Kusama ha lanzado la cadena Shell en blanco y ya hay 12 parachains en Rococo, pero el tiempo de generación de bloques de Kusama es de unos 12 segundos y estamos resolviendo este problema. ¿Cuáles son los retos a los que nos enfrentamos a corto plazo para aumentar el tiempo de bloqueo a 6 segundos y conseguir más cadenas en directo en Kusama? Rob: Creo que todo se reduce esencialmente a la web. Kusama tiene 900 certificadores, y estos certificadores son personas propietarias de KSM, y los nodos se implementan en todo el mundo para sincronizar la cadena. Esta cosa es genial, este es probablemente uno de los conjuntos de validadores más grandes del mundo. Pero cuando agrega algo de complejidad a esta red, como agregar una cadena paralela, definitivamente agregará mucha carga. De hecho, también hemos probado antes con los mismos parámetros en Rococo, pero el efecto en Kusama es completamente diferente, porque los nodos de validación se ejecutan en todo el mundo en Kusama, por lo que el principal desafío es hacer que el código de red se ejecute sin problemas. posible Cuando escribimos el código de la red, hicimos muchos mecanismos anti-trampas. Este tipo de cosas es que si nadie está jugando con él, no notarás su existencia, pero si alguien hace el mal, encontrarás que estas defensas Los mecanismos son muy importantes. Jef: Exacto. A medida que agreguemos más y más paracadenas, habrá más carga informática y veremos cómo se desarrolla en ese momento y cómo creceremos en el proceso. De hecho, observar cómo afectarán estas operaciones a la red es también un proceso de aprendizaje gradual. Joe: Para eso está Kusama, ¿no? Rob: Exacto. A medida que aumenta el número de cadenas paralelas, la carga de validadores definitivamente aumentará. Debido a que el verificador necesita verificar un bloque e hipotecar su propia moneda detrás del bloque, algunos otros verificadores optarán por verificar por sí mismos. Cuantas más paracadenas haya, más cálculos tendrá que hacer, aunque la cantidad de cálculos debería ser más lenta que el aumento de la cantidad de paracadenas, razón por la cual esta red es escalable, no inescalable como otras cadenas de bloques. Pero como validador, es posible que aún deba verificar docenas de bloques por segundo. Joe: Hablemos de algo más práctico, hablemos de los planes de Polkadot y Kusama para el próximo año. Tenemos un plan para subprocesos paralelos, que ahora se puede ver en la interfaz de usuario, porque antes de que la cadena se actualice a una parachain, se registra en forma de subproceso paralelo. Pero en el futuro, haremos que los hilos paralelos sean más prácticos. ¿Puede hablar sobre el diseño e implementación de hilos paralelos y qué trabajo queda por hacer para realizarlo? Rob: Los parathreads son similares a las parachains, la principal diferencia es la forma en que se programan. Tenemos un planificador, si es una cadena paralela, cada bloque se programará; si es un subproceso paralelo, debe realizar una subasta, y los recopiladores de subprocesos paralelos pueden competir entre sí para obtener la cantidad de bloques bien escrito. Esto provoca cambios en la red en términos de recopilación, cuando usted es un productor de bloques parathread, debe informar a los validadores que tiene bloques para enviar. Entonces, en general, hay tres desafíos: programador, subasta, cambios de red. Jeff: De hecho, había un diseño para hilos paralelos en ese momento, pero al final elegimos este con subastas. Porque este diseño puede prevenir mejor las trampas, pero para subprocesos, si no pueden enviar bloques por algún motivo, pueden perder recursos. Así que tenemos que mirar de nuevo algunos temas económicos. Joe: Dijimos que algunas funciones principales se liberarán de la cadena de retransmisión y se distribuirán a paracadenas para lograr aún más la escalabilidad y la idea de cadenas de retransmisión anidadas. ¿Quieren hablar sobre por qué hicieron esto? Jeff: En realidad, prefiero llamarlo "fragmentación de la cadena de retransmisión" en lugar de "cadena de retransmisión anidada", porque la cadena de retransmisión anidada suena como si una determinada cadena fuera dominante. En cierto sentido, la fragmentación de la cadena de retransmisión es más simple que lo que ya hemos hecho (fragmentación de parachain). Sin embargo, creo que puede ser posible hacer esto cuando hay más de 3000 validadores.Quiero decirles a todos que no hay necesidad de apresurarse a implementarlo. Antes de eso, esperamos hacer que las funciones de la cadena de retransmisión sean lo más simples posible, lo que creo que es la menor cantidad de trabajo para los desarrolladores. Rob: En la actualidad, los módulos de replanteo y elección y algunas funciones de gobierno son en realidad relativamente pesados, lo que supondrá una gran carga para la cadena de retransmisión. Todo lo que sucede en la cadena de relés debe ser ejecutado por los validadores de la cadena de relés. Por diseño, solo se requiere un subconjunto de validadores para procesar lo que sucede en una parachain. Ahí es donde entra en juego la escalabilidad, para minimizar la cantidad de cosas que debe hacer cada máquina validadora. Creo que en realidad es bastante difícil extraer de forma segura cosas como el staking y la gobernanza. Debido a que Polkadot tiene algunos modos de falla, por ejemplo, cuando un mecanismo está realizando un análisis de disputas, la cadena puede bloquearse para que no produzca bloques. Es posible que no pueda recortar las transacciones, es posible que el conjunto de validadores no pueda actualizar las transacciones, etc. Estos son desafíos difíciles. Pero esto no es realmente urgente. Antes de eso, debemos optimizar los nodos, por ejemplo, cómo procesar parachains y mensajes de red, para lograr una mayor escalabilidad y ejecutar más parachains. Jeff: Creo que nuestro objetivo debería ser, aunque este objetivo puede no lograrse, pero el objetivo debería ser alcanzar el mismo nivel, para que cada parachain tenga un validador. Puede que esto no sea posible, pero cuando lleguemos a esta situación, debemos saber la existencia de este límite y luego trabajar duro en otras direcciones. Joe: Justo ahora dijiste 3000 validadores, lo que significa 3000 cadenas paralelas. Rob ¿Cómo evalúas este objetivo como un cumplidor? Rob: (risas) Todavía no, eso es seguro. Creo que estaría feliz si el código ejecuta 80-100 parachains después de una ronda de optimización, y eso es más que suficiente para la comunidad. jeff: si Eventualmente, podríamos llegar a un punto en el que nos quedemos sin usuarios y tengamos que comenzar a convencer a más personas para que lo usen, así que supongo que podría haber muchos estallidos como ese. Rob: Creo que sí, creo que esto es un poco como el desafío de la gobernanza de Polkadot: ¿cuál es el efecto de cola larga del plan de subasta? Porque en algún momento, si toda la tecnología funciona bien, es posible que tengamos la capacidad de ejecutar más paracaídas y tal vez incluso superar la demanda del mercado de paracaídas. Pero tampoco queremos que los recursos de la parachain se llenen con algunos proyectos de basura, ocupándolos durante dos años. Por supuesto, el desarrollo de la comunidad se pondrá al día más tarde (los asientos de la parachain no serán suficientes) , y definitivamente habrá este tipo de proceso de desarrollo de ida y vuelta.

Tags：

LTC