¿Cómo realiza Polkadot una fragmentación eficaz entre paracadenas?

El protocolo de disponibilidad y validez de Polkadot (AnV: Availability and Validity) permite que toda la red se fragmente de manera efectiva entre cadenas paralelas, al tiempo que tiene sólidas garantías de seguridad.

Etapas del acuerdo AnV

El Protocolo de Disponibilidad y Validez (Protocolo AnV) se divide en seis fases.

Etapa de cadena paralela

Fase de envío de la cadena de retransmisión

Subacuerdos de disponibilidad e indisponibilidad

Comprobación de validez de aprobación de nivel 2 GRANDPA

Procedimiento de objeción de Ansher

Invoca el dispositivo de finalidad Tolerancia a fallas bizantinas para solidificar la cadena.

Etapa de cadena paralela

La fase de parachain del protocolo AnV es cuando los cotejadores de la parachain proponen bloques candidatos a los validadores actualmente asignados a la parachain.

Un bloque candidato es un bloque nuevo de un recopilador de paracadenas, que puede ser válido o no, y debe pasar una verificación de validez antes de ser incluido en la cadena de retransmisión.

Luego, los validadores verifican el bloque candidato con la funcionalidad de validación proporcionada por el código de registro de esa cadena paralela. Si la verificación es exitosa, el validador pasa el bloque candidato a otros validadores en la red de chismes. Sin embargo, si la validación falla, el validador inmediatamente considera que el bloque candidato no es válido.

Los recibos de candidatos se preparan cuando más de la mitad de los validadores de parachain están de acuerdo en que un bloque candidato de parachain en particular es una transición de estado válida. Los recibos de los candidatos eventualmente se incluirán en el estado de la cadena de retransmisión. Esto incluye:

ID de Parachain

DNI y Firma del Coleccionista

Hash de recepción de candidato del bloque principal

La raíz de Merkle del fragmento codificado por borrado del bloque

Cualquier raíz de Merkle que emita mensajes

Hash del bloque

Antes de la ejecución del bloque, la raíz de estado de la parachain

Después de ejecutar el bloque, la raíz de estado de la parachain

Toda la información anterior es constante, pero el bloque PoV real de la parachain tiene una longitud variable, que es suficiente información para cualquiera que obtenga el bloque PoV completo para verificar las transiciones de estado contenidas en él.

Durante las fases de subprotocolo de disponibilidad e indisponibilidad, los validadores circulan fragmentos de codificación de borrado en la red. Al menos 1/3 + 1 validadores deben informar que tienen sus campos de código. Una vez que se alcanza el umbral del validador, la red puede considerar el bloque PoV para el parachain.

Borrado de codificación

La codificación de borrado convierte un mensaje en un código más largo, lo que hace posible recuperar el mensaje original de un subconjunto del código sin requerir partes del código. El código es el mensaje original relleno con algunos datos adicionales, lo que permite reconstruir el código en caso de borrado.

El tipo de códigos de borrado utilizados por el esquema de usabilidad de Polkadot son los códigos Reed-Solomon, que han demostrado su uso en tecnologías fuera de la industria de la cadena de bloques. Un ejemplo se puede encontrar en la industria de los discos ópticos. Los CD usan códigos Reed-Solomon para corregir cualquier dato perdido debido a inconsistencias en la superficie del disco, como partículas de polvo o rayones.

En Polkadot, los códigos de borrado se utilizan para mantener el estado de la paracadena disponible para el sistema sin requerir que todos los validadores controlen todas las paracadenas. En cambio, los validadores comparten datos más pequeños y luego pueden reconstruir los datos completos bajo el supuesto de que 1/3 + 1 validadores pueden contribuir con sus respectivos datos.

Nota: El umbral de 1/3+1 de validadores que deben responder para construir datos de estado de parachain completos corresponde a las suposiciones de seguridad de Polkadot sobre los nodos bizantinos.

Pescador

Los Anglers son nodos completos de parachains, similares a los Collators, pero juegan un papel diferente en su relación con la red Polkadot. En lugar de empaquetar transiciones de estado y producir el siguiente bloque de paracaídas como lo hacen los recopiladores, los pescadores observarán todo el proceso y se asegurarán de que no se incluyan transiciones de estado no válidas. Los pescadores deben comprometer moderadamente una parte de las fichas en la cadena de relevos, a diferencia de los coleccionistas que no requieren fichas en la cadena de relevos. Si se determina que se ha producido una mala conducta durante el proceso de producción de la paracaídas, el pescador presentará un informe de invalidación. Si se demuestra que la mala conducta denunciada es correcta, serán recompensados ​​generosamente, pero si se demuestra que están equivocados, pueden perder parte de su participación. Los pescadores son, por lo tanto, similares a los cazadores de recompensas, a quienes se les paga generosamente cuando completan un trabajo y, por lo demás, no tienen un salario fijo.

Cómo ejecutar un nodo de pescador

Se espera que los requisitos para ejecutar un nodo Angler sean relativamente modestos en comparación con los requisitos de replanteo de un nodo validador. Registrar el estado de "pesca" en la cadena de retransmisión requerirá una cierta cantidad de tokens. Si un phisher envía un informe de invalidación incorrecto, el protocolo podría reducir estos tokens de manera significativa. El riesgo de corte existe para evitar que los phishers envíen spam a la red, ya que restablecer el estado de parachain es un proceso costoso para la cadena de retransmisión.

En términos de hardware requerido, una máquina moderadamente potente teóricamente podría ejecutar un nodo completo de una o más paracadenas. Probablemente la mayor necesidad sea almacenar los datos de cada parachain phishing. Sin embargo, las mejoras como la poda significan que el tamaño de almacenamiento final requerido para mantener un nodo completo de una cadena paracaídas se estabilizará en un nivel muy alto. Los requisitos de RAM y CPU pueden escalar con la cantidad de paracadenas pescadas, por lo que para pescar una paracadena y luego aumentar la cantidad pescada, se requiere una configuración inicial mínima. 10 o 20 instancias en la nube por mes son suficientes para comenzar.

Nota: ¡Todavía no hay phishers en las redes de Kusama o Polkadot! Este artículo se actualizará con guías de configuración lo antes posible.

Más recursos

Life of a Parachain Block: un artículo del analista de Parity Joe Petrowski que detalla las comprobaciones de validez que debe pasar un bloque de parachain para la validación de parachain. https://polkadot.network/el-camino-de-un-bloque-de-paracadena/

Disponibilidad y validez: un artículo del equipo de investigación de W3F que detalla el protocolo de disponibilidad y validez. https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV

Texto original: https://wiki.polkadot.network/docs/en/learn-availability

Tags：

FTX