Figura 1: Las transacciones t 1 a t 3 se incluyen en la cadena de envío a lo largo de algunos bloques, donde cada una emite un mensaje de cadena cruzada, denotado por m 1 , m 2 y m 3 . Los mensajes de cadena cruzada se colocan en una transacción de actualización de cadena cruzada, indicada por CCU, que se publica e incluye en la cadena de recepción.

El ecosistema Lisk, por supuesto, constará de más de dos cadenas. Por lo tanto, la solución también es un poco más sofisticada de lo que se explicó anteriormente. Eso significa, por ejemplo, que una transacción de actualización entre cadenas puede contener varios mensajes entre cadenas que se dirigen a diferentes cadenas. Esto se explicará con más detalle en las secciones siguientes.

Tenga en cuenta que no existe una regla sobre cuántos mensajes se deben recopilar antes de que se cree una transacción de actualización entre cadenas o cuántos bloques se deben recopilar los mensajes antes de crear uno. Existe una flexibilidad total y cualquier usuario puede crear una transacción de actualización entre cadenas cuando lo desee tomando todos los mensajes entre cadenas que no se incluyeron antes en una transacción de actualización entre cadenas. 

Contenido de la transacción de actualización entre cadenas

Las transacciones de actualización entre cadenas constan de las siguientes tres partes principales:

•  Los mensajes entre cadenas.

•  Un certificado

•  Información sobre el conjunto de validadores actual de la cadena de envío.

Ya describimos la primera parte, los mensajes entre cadenas, arriba.

Un certificado es un objeto que contiene información de un encabezado de bloque finalizado que está firmado por una gran parte de los validadores de la cadena de envío y, por lo tanto, autentica un estado finalizado de esa cadena. Un estado finalizado autenticado es un requisito para aceptar mensajes de cadena cruzada en la cadena de recepción. Eso significa que un mensaje de cadena cruzada se aplica en la cadena de recepción solo si se certificó que la transacción correspondiente en la cadena de envío pertenece a un estado finalizado.

Con la información sobre el conjunto de validadores actual de la cadena de envío, la cadena de recepción sabe qué conjunto de validadores es elegible para firmar el siguiente certificado.

Transacciones de actualización entre cadenas que se originan en Lisk Mainchain

Consideremos primero el caso en el que la cadena de envío es la cadena principal. Habrá varias cadenas laterales conectadas a la cadena principal. Por lo tanto, los mensajes de cadena cruzada creados en la cadena principal también se dirigirán a diferentes cadenas laterales. Para enviar mensajes de cadena cruzada desde la cadena principal a una cadena lateral específica, todos los mensajes de cadena cruzada dirigidos a esta cadena lateral se colocan en una transacción de actualización de cadena cruzada, omitiendo los mensajes de cadena cruzada dirigidos a otras cadenas. Esta transacción luego se publica en la cadena lateral. Esto también se ilustra en la Figura 2 a continuación, donde los mensajes de cadena cruzada dirigidos a dos cadenas laterales diferentes se colocan en transacciones de actualización de cadena cruzada separadas.

Figura 2: Hay cuatro transacciones, t 1 a t 4 , incluidas en la cadena principal, donde cada una emite un mensaje de cadena cruzada, denotado por m 1 a m 4 . Los mensajes de cadena cruzada se muestran como rectángulos, las transacciones como rectángulos con esquinas redondeadas. El color de una transacción o mensaje de cadena cruzada es siempre el de la cadena de recepción, a excepción de una transacción de actualización de cadena cruzada cuyo color es el de la cadena de envío. La transacción de actualización de cadena cruzada CCU1 que contiene m 1 y m 3 se incluye en la cadena lateral 1. La transacción de actualización de cadena cruzada CCU2 que contiene m 2 y m 4 se incluye en la cadena lateral 2.

Transacciones de actualización entre cadenas que se originan en cadenas laterales

Ahora, consideramos el caso en el que la cadena de envío es una cadena lateral. En este caso, todos los mensajes entre cadenas se colocan en una transacción de actualización entre cadenas que se publicará en la cadena principal. Esto incluye mensajes de cadena cruzada dirigidos a la cadena principal, así como mensajes de cadena cruzada dirigidos a otras cadenas laterales. Cuando la transacción de actualización entre cadenas se incluye en la cadena principal, los mensajes entre cadenas se tratan de manera diferente según su cadena de destino.

Si un mensaje de cadena cruzada está dirigido a la cadena principal, se procesa en la cadena principal. Si un mensaje de cadena cruzada está dirigido a otra cadena lateral, digamos cadena lateral 2, entonces el mensaje de cadena cruzada se reenvía a la cadena lateral 2. Eso significa que el mensaje de cadena cruzada se incluye en una próxima transacción de actualización de cadena cruzada desde la cadena principal a la cadena lateral 2 En otras palabras, los mensajes de cadena cruzada de una cadena lateral a otra cadena lateral se enrutan a través de la cadena principal. El procesamiento en la cadena principal es muy rápido porque la cadena principal no realiza la validación completa ni aplica el mensaje entre cadenas. Ambos casos se muestran a continuación en la Figura 3.

Figura 3: En la cadena lateral 1, se incluyen tres transacciones, donde cada una emite un mensaje de cadena cruzada, denotado por m 1 , m 2 y m 3 . El color de una transacción o mensaje de cadena cruzada es siempre el de la cadena de recepción, a excepción de una transacción de actualización de cadena cruzada cuyo color es el de la cadena de envío. Los tres mensajes de cadena cruzada se entregan en una transacción de actualización de cadena cruzada, CCU1, a la cadena principal, donde se procesan m 1 y m 3 , pero no m 2 . Más tarde, m 2se entrega a la cadena lateral 2 mediante una transacción de actualización de cadena cruzada, CCU2, desde la cadena principal a la cadena lateral 2. Esta transacción de actualización de cadena cruzada contiene un mensaje de cadena cruzada adicional, m 4 , emitido por la transacción t 4 incluida en la cadena principal. 

Mensajes de cadena cruzada

Ya hemos hablado extensamente sobre los mensajes entre cadenas sin explicar realmente qué son.

Los mensajes entre cadenas son muy similares a las transacciones en el sentido de que ambos inducen una transición de estado cuando se incluyen en un libro mayor en cadena. La principal diferencia es que cada mensaje de cadena cruzada tiene las propiedades adicionales sendChainID y ReceiveChainID. La propiedad ReceiveChainID permite, por ejemplo, el enrutamiento que realiza la cadena principal.

Los mensajes de cadena cruzada pueden ser emitidos por una transacción incluida en la cadena de envío. Por ejemplo, cuando desea transferir algunos tokens de una cadena a otra, envía una transacción de transferencia de tokens entre cadenas en la cadena de envío que luego emite un mensaje de transferencia de tokens entre cadenas. La transacción de transferencia de token entre cadenas provocará un cambio de estado en la cadena de envío, es decir, el débito de la cuenta del remitente. El mensaje de transferencia de tokens entre cadenas provocará un cambio de estado en la cadena receptora, es decir, acreditar la cuenta receptora. La Figura 4 a continuación muestra un ejemplo en el que Alice envía algunos tokens LSK desde su cuenta en la cadena de envío a la cuenta de Bob en la cadena de recepción.

Figura 5: Ejemplo de interoperabilidad entre la cadena principal de Lisk y tres cadenas laterales. Los pasos 2), 4) y 6) son transacciones realizadas dentro de una sola cadena. Los pasos 1), 3) y 5) son mensajes de cadena cruzada. Los mensajes de cadena cruzada 3) y 5) son mensajes de cadena cruzada de cadena lateral a cadena lateral que se enrutan a través de la cadena principal. El mensaje de cadena cruzada 1) es un mensaje de transferencia de token de cadena cruzada de cadena principal a cadena lateral.

El papel de Mainchain

La cadena principal tiene un papel clave en el ecosistema Lisk. En primer lugar, todas las cadenas laterales deben registrarse en la cadena principal para interoperar con otras cadenas. Una vez que se registra una cadena lateral, la cadena principal mantiene la información relevante sobre la cadena lateral, como el número de mensajes de cadena cruzada que se le envían y la lista actual de validadores de cadena lateral.

Como ya se describió anteriormente, la cadena principal también sirve como un enrutador para mensajes de cadena cruzada de una cadena lateral a la otra. Tenga en cuenta nuevamente que el procesamiento de estos mensajes en la cadena principal es muy rápido ya que estos mensajes solo se reenvían. Esto significa, por ejemplo, que los mensajes personalizados de cadena cruzada cuya aplicación o validación completa es muy costosa no afectan a la cadena principal.

La cadena principal solo admite el token LSK. Además, dado que es la cadena nativa del token LSK, realiza un seguimiento de la distribución de los tokens LSK en todo el ecosistema.

Personalización de cadenas laterales

Casi no hay restricciones en las aplicaciones que puede implementar en una cadena lateral utilizando Lisk SDK. Además de la gran flexibilidad con respecto a la lógica de la aplicación, existen varias configuraciones con respecto al protocolo blockchain que se pueden personalizar, como el mecanismo de selección del validador. La versión inicial del Lisk SDK que implementa la solución de interoperabilidad Lisk admitirá Prueba de participación delegada y Prueba de autoridad. Además, las recompensas de bloque se pueden personalizar: los desarrolladores de cadenas laterales podrán elegir no tener recompensas de bloque en absoluto o tener recompensas de bloque en tokens de cadena lateral. También se pueden adaptar constantes como la longitud de ronda, el tiempo de bloque y el límite de tamaño de bloque. Finalmente, los desarrolladores de cadenas laterales pueden elegir qué tokens admitir. Esto puede incluir tokens nativos de esta cadena, pero también tokens de cadenas laterales de otras cadenas laterales. Tenga en cuenta que para ser parte del ecosistema Lisk, una cadena lateral deberá admitir el token LSK.

El papel del token LSK

El token LSK es el único token que se puede transferir a todas las cadenas dentro del ecosistema Lisk. Será el token predeterminado para las tarifas de transacción en cadenas laterales, pero será posible configurar un token de cadena lateral para las tarifas de transacción. Como el token LSK aparece en varios intercambios, en la mayoría de los casos será el token inicial que un usuario adquiere dentro del ecosistema Lisk. Una vez que un usuario posee algunos tokens LSK, puede intercambiarlos por otros tokens de cadena lateral, por ejemplo, en una cadena lateral de intercambio descentralizada.

Propiedades de nuestra solución de interoperabilidad

Al diseñar la solución de interoperabilidad para el ecosistema Lisk, teníamos varios objetivos en mente que creemos que se realizan en nuestra solución: en primer lugar, es escalable . Eso significa que no hay límites en la cantidad de cadenas laterales que se pueden conectar a la cadena principal. 

También es muy flexible en el sentido de que las transacciones de actualización entre cadenas se pueden transmitir cuando se desee. Se podría transmitir una transacción de actualización entre cadenas cada 10 segundos o solo una vez al mes. Se pueden transmitir con más frecuencia en las horas punta y con menos frecuencia en las horas tranquilas. Debido a esta flexibilidad, también es rápido : si un usuario desea que se transmita un mensaje entre cadenas lo antes posible, puede crear y publicar una transacción de actualización entre cadenas que contenga el mensaje entre cadenas por sí mismos. La creación y el envío de transacciones de actualización entre cadenas no está restringida a validadores ni a ningún otro rol. Cualquier usuario puede hacer esto.

Es seguro porque los certificados deben estar firmados por una gran parte de los validadores de la cadena de envío y todos los mensajes entre cadenas son autenticados por los certificados. Dado que las cadenas de recepción realizan un seguimiento del conjunto de validadores de la cadena de envío, es fácil para una cadena de recepción ver si las firmas de un certificado fueron creadas por los validadores legítimos. De hecho, la cadena de recepción podrá detectar y rechazar transacciones maliciosas de actualización entre cadenas siempre que se mantenga la suposición de seguridad en la cadena de envío. Sin embargo, incluso habrá medidas de seguridad adicionales, incluidas algunas que garanticen que los problemas debidos a supuestos de seguridad fallidos en las cadenas laterales se limitan a esa cadena y no se pueden propagar al exterior.

Por último, pero no menos importante, la solución es eficiente . Aunque todos los mensajes de cadena cruzada de cadena lateral a cadena lateral se enrutan a través de la cadena principal, esto no es realmente una carga para la cadena principal, ya que solo transmite los mensajes sin ningún procesamiento costoso.

La nueva hoja de ruta

Estamos organizando nuestra investigación de la solución de interoperabilidad y los LIP que estamos preparando en torno a ocho objetivos de la hoja de ruta. Cada objetivo de la hoja de ruta abarca un aspecto clave de nuestra solución de interoperabilidad que será abordado por uno o más LIP. Para estos LIP, distinguimos entre LIP centrales de interoperabilidad y LIP de soporte. Los primeros especifican la parte central de la solución de interoperabilidad Lisk y se publicarán en el evento Lisk.js 2021 en mayo. Estos últimos no forman parte estrictamente de la solución de interoperabilidad, pero son necesarios para definir la solución de interoperabilidad. Ya se publicarán antes de Lisk.js. 

Hemos actualizado nuestra hoja de ruta para incluir estos ocho objetivos para la fase de interoperabilidad de Blockchain. Puede encontrar la lista completa de objetivos junto con una descripción de cada uno de ellos a continuación:

1. Defina el protocolo de mensajería entre cadenas . Este objetivo abarca la definición de mensajes entre cadenas y transacciones de actualización entre cadenas descritas anteriormente. Esto incluye sus reglas de validez, el enrutamiento de mensajes, etc.
2. Defina el registro y el ciclo de vida de la cadena lateral . Aquí, el objetivo es definir todo el ciclo de vida de una cadena lateral, desde su registro en la cadena principal hasta su posible terminación, incluida la recuperación de tokens de las cadenas terminadas.
3. Definir modelo de estado y raíz de estado . Como parte de este objetivo, planeamos introducir una raíz de estado que nos permita autenticar criptográficamente todo el estado de una cadena con un solo hash, utilizando pruebas de inclusión.
4. Introducir estándares de token para el ecosistema Lisk . Planeamos definir algunos estándares con respecto a tokens fungibles y tokens no fungibles. Estos estándares deberían facilitar la creación de tokens de cadenas laterales en cadenas laterales. Esto también incluye los correspondientes mensajes de transferencia de token de cadena cruzada descritos en el ejemplo anterior.
5. Actualice Lisk-BFT para la interoperabilidad . El objetivo es hacer que el protocolo Lisk-BFT sea más flexible. Por ejemplo, debería permitirse establecer diferentes pesos de validación para finalizar bloques y permitir que estos pesos de finalidad cambien con el tiempo. En particular, se pueden desear diferentes pesos para las cadenas laterales que utilizan el mecanismo de prueba de autoridad. Además, Lisk-BFT debería generar certificados que se puedan usar en transacciones de actualización entre cadenas para autenticar mensajes entre cadenas y cambios de validación.
6. Actualiza el formato del encabezado del bloque . El formato de los encabezados de bloque y los bloques de génesis debe actualizarse para tener en cuenta los cambios enumerados anteriormente.
7. Introducir un mecanismo alternativo de selección de validadores para cadenas laterales . Este objetivo apunta a especificar el nuevo mecanismo de selección del validador de prueba de autoridad.
8. Mejorar el esquema de firmas . Planeamos algunas mejoras para las firmas utilizadas en Lisk. El más importante es introducir firmas múltiples agregadas compactas, que son muy beneficiosas para limitar el tamaño de los certificados contenidos en las transacciones de actualización entre cadenas.

Conclusión

La solución de interoperabilidad Lisk se basa en el paradigma de la certificación entre cadenas. Se puede intercambiar cualquier tipo de información entre cadenas utilizando mensajes generales entre cadenas. La cadena principal de Lisk juega un papel clave en todo el ecosistema, ya que todos los mensajes de cadena cruzada entre cadenas laterales se enrutan a través de la cadena principal. Las cadenas laterales se pueden personalizar aún más, no solo con respecto a la lógica de la aplicación, sino también con respecto a la lógica general de la cadena de bloques, como el algoritmo de consenso. El token LSK se puede mover a cualquier cadena y será el token predeterminado para las tarifas de transacción en el ecosistema. Además, crear tokens de cadena lateral en una cadena lateral y transferirlos a otras cadenas será sencillo con los nuevos estándares de tokens.

La hoja de ruta de investigación actualizada ofrece una descripción general de cómo dividimos la solución de interoperabilidad en ocho objetivos de investigación clave. En el próximo evento Lisk.js del 21 al 22 de mayo de 2021 se revelarán más detalles sobre estos objetivos y los LIP que los abordan . 

Para preguntas y comentarios adicionales sobre el tema, organizaremos un AMA en Lisk.chat con Andreas Kendziorra y Jan Hackfeld el miércoles 7 de abril a las 4 pm CEST . También invitamos a todos los miembros de la comunidad a que vayan al foro de Lisk Research , donde siempre nos complace escuchar sus comentarios y participar en discusiones sobre temas de investigación para el ecosistema Lisk.

• Fuente: blog de Lisk