Presentacion de la transaccion de actualizacion LISK entre cadenas
Esta es la próxima edición de la serie de publicaciones del blog que cubre los detalles de la solución de interoperabilidad Lisk. En la publicación anterior del blog , discutimos el ciclo de vida de una cadena lateral, su registro y su terminación. Aquí, cubrimos una transacción importante utilizada para comunicar información de una cadena a otra: la actualización entre cadenas.
Este tema se trató durante el evento Lisk.js y el discurso de Andreas Kendziorra se puede encontrar aquí .
Antes de profundizar en los detalles del tema en sí, recapitulemos el paradigma básico de la comunicación entre cadenas que se utilizará en el ecosistema Lisk, como se muestra en el diagrama a continuación.
El método estándar para la comunicación entre cadenas en el ecosistema Lisk es a través de mensajes entre cadenas (MCP). Se emiten al ejecutar ciertas transacciones, por ejemplo, una transferencia de token entre cadenas, y luego se almacenan en la bandeja de salida de la cadena de envío. Los mensajes, junto con un certificado (que se describe con más detalles a continuación), se recopilan e incluyen en una transacción de actualización entre cadenas (CCU). Son los sobres que llevan todos los mensajes. Al ejecutar una CCU, la cadena de recepción abre el sobre, agrega todos los CCM a la bandeja de entrada de la cadena y ejecuta los comandos de cadena cruzada correspondientes a los mensajes.
Roles de la CCU
El papel principal de la transacción CCU es permitir que los CCM se transmitan desde la cadena de envío a la cadena de recepción. Esto debe hacerse de manera segura y sin confianza. Seguro significa que los nodos de la cadena de recepción tienen la garantía de que los CCM se incluyeron en la cadena de envío en bloques finalizados. Sin confianza significa que cualquiera puede enviar la CCU a la cadena de recepción y no requiere ningún privilegio especial.
Garantizar la seguridad
Primero describamos el ingrediente principal de la seguridad de nuestra solución: el certificado. Los certificados son objetos compactos derivados de un encabezado de bloque y que contienen la cantidad mínima de información requerida para la interoperabilidad, a saber, el ID del bloque, la altura del bloque, la marca de tiempo del bloque, la raíz del estado, el hash de los validadores y una firma agregada. La firma agregada debe ser creada por validadores de la cadena y debe contener suficientes firmas para garantizar que la información del certificado sea definitiva. Por supuesto, no quisiéramos transmitir información a otra cadena con el riesgo de que se revierta en la cadena de envío. Esto conduciría a información de estado inconsistente entre las cadenas involucradas, lo que sería desastroso para su comunicación.
En nuestra tienda estatal, cada cadena mantiene una tienda de interoperabilidad que contiene los datos de otras cadenas con las que interactúan. Entre otras propiedades, esto incluye la raíz del estado, el conjunto de validadores, la bandeja de entrada (como un árbol de merkle de solo anexión ), la altura y la marca de tiempo. Establecer o cambiar esas propiedades solo se puede hacer si los valores están firmados por los delegados de la cadena de envío. Esto puede suceder con un certificado, de ahí que, por ello, declaramos que esos valores están certificados.
Es importante que la información relativa a otras cadenas se actualice periódicamente para que la comunicación entre cadenas se mantenga activa. Esto se hace publicando CCU que contienen certificados recientes.
¿Cómo nos permite esto garantizar la inclusión de los MCP en la cadena de envío? Bueno, como parte de la cuenta de interoperabilidad, cada cadena mantiene una bandeja de salida a la que se agregan todos los CCM. Esta bandeja de salida está autenticada por una raíz Merkle, que llamamos raíz de la bandeja de salida. Esta raíz de la bandeja de salida es parte de todo el almacén estatal que fue certificado en la CCU, es decir, por la raíz del estado. Esto significa que en la cadena de recepción, la raíz estatal certificada y una prueba de inclusión de Merkle son suficientes para verificar que se incluyó un CCM en la cadena de envío.
Por último, garantizar la seguridad solo es posible si las cadenas interoperables mantienen el conjunto correcto de validadores para las cadenas de envío. Los validadores de la cadena de envío pueden cambiar con el tiempo, y es importante que la cadena de recepción se mantenga actualizada con los nuevos validadores. A tal efecto, los certificados contienen el hash del conjunto de validadores necesarios para firmar el siguiente certificado, y la CCU contiene las claves públicas necesarias para verificar este hash.
CCU sin confianza
La propiedad sin confianza de nuestra interoperabilidad proviene naturalmente del hecho de que las firmas de certificados deben incluirse en los encabezados de los bloques. Se incentiva a los validadores a firmar certificados e intercambiar firmas, esas firmas luego se agregan e incorporan en un encabezado de bloque. En una futura publicación de blog, profundizaremos más en los detalles de la generación de certificados y la incentivación. Como la firma está fácilmente disponible, cualquiera puede utilizarla para generar un certificado y, en consecuencia, una CCU.
Figura 2: Una CCU contiene las siguientes propiedades: el ID de la cadena de envío, el certificado, la actualización del validador y la actualización de la bandeja de entrada. El certificado contiene la raíz estatal certificada, una firma que garantiza la validez del certificado y el hash del conjunto de validadores endosados para firmar el siguiente certificado de esta cadena. La actualización del validador describe cómo el conjunto de validador almacenado en los datos de la cadena debe actualizarse para que coincida con el hash del validador. La actualización de la bandeja de entrada contiene los CCM transmitidos y las pruebas necesarias de Merkle de que esos mensajes son parte de la raíz estatal certificada.
La primera CCU
Mencionemos un rol único que cumple la primera CCU. La publicación anterior del blog describió el ciclo de vida de una cadena de bloques y su inicio en la fase registrada. Esta fase puede durar todo el tiempo que se desee; solo cuando se incluye la primera CCU enviada por la cadena registrada, el estado de la cadena cambiará a activo. A partir de este punto, la cadena puede interactuar con el ecosistema.
La condición de vida
Esta condición está diseñada para garantizar que todas las cadenas activas del ecosistema actualicen periódicamente sus datos en la cadena principal. Como se detalla en nuestra publicación de blog anterior , si una cadena no actualiza sus datos cada mes, se cancelará. Este procedimiento de terminación es necesario para permitir a los usuarios recuperar fondos y mensajes que fueron enviados a la cadena inactiva. La satisfacción de la condición de vida se realiza mediante la publicación de CCU con regularidad.
Un ejemplo extendido de interacción entre cadenas
En el resto de esta publicación de blog, nos centraremos en un ejemplo particular de comunicación entre la cadena A (la cadena de envío) y la cadena B (la cadena de recepción). En este sentido, no consideraremos los bloques de la cadena A, esto se debe a que su estructura de bloques real no es relevante para la cadena B al recibir CCU. Más bien, en la cadena A, la atención se centra en los mensajes agregados a la bandeja de salida y las raíces certificadas. En la cadena B, la atención se centrará en la raíz del estado certificado, la bandeja de entrada y la raíz de la bandeja de entrada.
A continuación se muestra un escenario típico que muestra la información de interés en la cadena A, los CCM incluidos en la bandeja de salida (indicados por M0, M1, ...) y los certificados generados (en cajas verdes).
El objetivo de la comunicación entre cadenas es ahora llevar esos mensajes a la cadena B, la cadena de recepción. Esto se logra utilizando CCU y veremos a continuación las diferentes opciones disponibles para crear CCU. Para estar completamente completas, las CCU que se presentan a continuación también deberían incluir las pruebas de Merkle, las firmas y las actualizaciones del validador adecuadas; sin embargo, por simplicidad, las omitiremos aquí. Los productos Lisk proporcionarán herramientas para generar o solicitar de forma automática y sencilla las piezas que faltan.
Supongamos que en la cadena B se han recibido los 2 primeros certificados y todos los CCM hasta M5. Por lo tanto, el estado de la bandeja de entrada y las raíces certificadas es el que se muestra a continuación:
CCU contiene todos los CCM pendientes hasta un certificado
Este caso es el más probable. Aquí, todos los CCM necesarios para calcular la raíz de la bandeja de salida certificada se incluyen en la CCU. Esta es la forma más eficiente de actualizar la cadena de recepción, ya que no es necesario presentar una prueba de inclusión adicional. En nuestro ejemplo, este sería el caso del ejemplo que se muestra a continuación:
Tenga en cuenta que aunque existe un certificado adicional (el certificado para la altura 23 en nuestro ejemplo), no hay obligación de incluirlo en la cadena de recepción. El único requisito es que el certificado incluido esté firmado válidamente por el conjunto de validadores almacenado en la tienda de interoperabilidad (en la cadena B).
Faltan algunos CCM
Cabe señalar que no siempre es posible seguir el patrón que se acaba de describir. La razón es que la transacción de CCU debe encajar completamente en un solo bloque de la cadena de recepción (como es el caso de cualquier transacción). Por lo tanto, si los CCM incluidos en la bandeja de salida entre dos raíces estatales certificadas tienen un tamaño total mayor que el tamaño del bloque, es imposible incluirlos todos en la cadena B. Por esta razón, es posible certificar un estado sin incluir todos los mensajes. . Por ejemplo, publicando:
En esta CCU, el certificado 4 se incluye en la CCU junto con los CCM M12, M13 y M14. Tenga en cuenta que los CCM M15, M16 y M17 se incluyen en la raíz de la bandeja de salida certificada, pero no en la CCU. En ese caso, se incluye una prueba adicional de Merkle en la CCU para demostrar que los CCM dados fueron los incluidos en la bandeja de salida. El estado de la cadena B es ahora como se puede ver a continuación:
Completando la bandeja de entrada
Ahora es el momento de completar la bandeja de entrada. Aquí no hay obligación de incluir un nuevo certificado en la CCU y solo se pueden otorgar CCM.
Los CCM se autentican contra la raíz del estado certificado almacenado y se incluyen en la cadena de recepción:
Nuevamente, si los MCP dados fueran insuficientes para completar la bandeja de entrada (por ejemplo, si no se incluyó M17), se proporcionaría otra prueba de su inclusión en la bandeja de salida.
Ahora hemos progresado hasta M17 y la comunicación entre cadenas continuará de manera similar. Se incluirán más mensajes en la cadena A, aumentando la bandeja de salida, y esos mensajes se reenviarán a la cadena B aumentando la bandeja de entrada y actualizando la información certificada.
Conclusión y próximo tema
En esta publicación de blog, hemos cubierto las diferentes funciones de la CCU y cómo se utilizan las CCU y los certificados para garantizar que la comunicación entre cadenas se realice de forma segura. Los detalles de los CCM y el proceso de generación de certificados serán el tema principal de las futuras ediciones de esta serie de publicaciones de blog. Si desea saber más sobre cómo los CCM pueden transferir tokens y NFT, o cómo funcionan realmente las transacciones de recuperación, le recomendamos que no se los pierda.
Las especificaciones técnicas del tema tratado en esta publicación de blog se pueden encontrar en nuestro foro de Lisk Research. En particular, el LIP “Introducir transacciones de actualización entre cadenas” define la CCU y su aplicación. Este LIP, junto con 10 LIP adicionales que describen la solución de interoperabilidad, se publicaron y propusieron recientemente para el protocolo Lisk. La comunicación entre cadenas entre blockchains sigue siendo un área de investigación nueva y abierta, por lo que nos complace recibir comentarios técnicos, sugerencias o preguntas sobre nuestro enfoque en el foro de Lisk Research .
Recursos
Fuente: blog de lisk