Lisk brinda una nueva solución de interoperabilidad

abril 02, 2021 VICTOR HUGO LAZARTE 0 Comments



En la publicación anterior del blog de investigación "Introducción a la interoperabilidad de blockchain " , proporcionamos una descripción general de varios métodos para la interoperabilidad de blockchain. La publicación del blog describió diferentes tipos de interoperabilidad de blockchain, que van desde el intercambio de tokens entre cadenas hasta mensajes generales entre cadenas Además, presentamos varias soluciones técnicas para cada caso. Por ejemplo, con respecto a los mensajes generales de cadenas cruzadas, explicamos la certificación de cadenas cruzadas, la fragmentación heterogénea de cadenas de bloques y las acumulaciones.

Ya revelamos que la solución de interoperabilidad Lisk tiene como objetivo permitir mensajes generales entre cadenas. En esta publicación de blog, ahora explicamos cómo se logra esto proporcionando una descripción general de alto nivel de la solución de interoperabilidad Lisk similar a la presentación en línea dada en el "Primer vistazo a la interoperabilidad Lisk" en el evento Lisk Updates from the Lisk Center, Berlín. a partir de noviembre de 2020. Además, ahora podemos desvelar nuestra hoja de ruta actualizada que contiene todos los objetivos de la fase de interoperabilidad de blockchain.

Solución técnica

Nuestra solución de interoperabilidad se basa en el paradigma de la certificación entre cadenas presentado en detalle en la publicación anterior del blog de investigación "Introducción a la interoperabilidad de Blockchain" . Básicamente, la certificación entre cadenas significa que la información de una cadena se envía a otra cadena utilizando un objeto firmado llamado certificado. Veamos más específicamente cómo funcionará esto en el ecosistema Lisk.

Transacciones de actualización entre cadenas

Ahora consideraremos el caso simplificado de dos cadenas interoperables, donde una es la cadena de envío y la otra la cadena de recepción. Para enviar información de la cadena de envío a la cadena de recepción, el primer paso es incluir una transacción en la cadena de envío. Esta transacción luego emite uno o más mensajes de cadena cruzada que llevan la información relevante que se supone debe enviarse a la cadena de recepción. Los mensajes de cadena cruzada se transfieren luego a la cadena de recepción. Sin embargo, no enviamos un mensaje de cadena cruzada a la cadena de recepción inmediatamente después de que se haya incluido la transacción correspondiente. En cambio, varios mensajes de cadena cruzada, posiblemente de varios bloques o incluso rondas, se recopilan juntos y se colocan en una transacción de actualización de cadena cruzada .que luego se publica en la cadena de recepción. Este concepto también se ilustra a continuación en la Figura 1. Las transacciones de actualización entre cadenas son de hecho las transacciones principales que facilitan la interoperabilidad en el ecosistema Lisk y nuestra realización de la certificación entre cadenas . Por lo tanto, también llamamos a la técnica general "actualización de cadena cruzada" en lugar de "certificación de cadena cruzada" para simplificar la presentación en línea dada en el "Primer vistazo a la interoperabilidad de Lisk" .


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 4: Alice realiza una transferencia de token entre cadenas desde su cuenta en la cadena de envío a la cuenta de Bob en la cadena de recepción. Para ello, envía una transacción de transferencia de token entre cadenas, t, en la cadena de envío. Cuando se incluye esta transacción, se carga su cuenta en la cadena de envío. Simultáneamente, se emite un mensaje de transferencia de token de cadena cruzada correspondiente, m, que contiene toda la información relevante. Este mensaje se incluye en una transacción de actualización entre cadenas, CCU, que se envía a la cadena de recepción. Cuando se incluye la transacción, se acredita la cuenta de Bob.

Sin embargo, los mensajes entre cadenas no se limitan a las transferencias de tokens. Al igual que las transacciones, los mensajes entre cadenas tienen una propiedad de activo . Por lo tanto, al crear una aplicación de cadena de bloques con Lisk SDK, puede crear mensajes personalizados de cadena cruzada definiendo el contenido de la propiedad del activo según sea necesario. Por ejemplo, puede crear un mensaje de cadena cruzada personalizado que contenga información autenticada de una cadena de Oracle en su propiedad de activo. Esta flexibilidad implica las capacidades generales de mensajes entre cadenas mencionadas en la publicación del blog "Introducción a la interoperabilidad de Blockchain" .

Ejemplo de uso de interoperabilidad

Veamos un ejemplo para tener una mejor impresión de las capacidades de nuestra solución de interoperabilidad. Todos los pasos siguientes que se describen aquí también se pueden ver en la Figura 4 a continuación. Supongamos que tenemos una cadena de intercambio, una cadena de mercado de predicción y una cadena de oráculo conectada a la cadena principal. Entonces, una historia de usuario podría verse así: suponga que un usuario tiene algunos tokens LSK en la cadena principal y le gustaría apostar en la cadena de mercado de predicción, pero esta cadena requiere un token especial para apostar. Por lo tanto, se aplicarían las siguientes acciones:

  1.  El usuario envía algunos de sus tokens LSK a la cadena de intercambio a través de un mensaje de transferencia de token entre cadenas.

  2.  Los tokens LSK se intercambian luego por los tokens de apuestas. 

  3.  Posteriormente, las fichas de apuestas se envían desde la cadena de intercambio a la cadena de mercado de predicción a través de un mensaje de transferencia de fichas entre cadenas. 

  4.  En la cadena de mercado de la predicción, el usuario apuesta por el ganador del Premio Nobel de Física.

  5.  Después del anuncio del ganador del premio Nobel, la cadena de oráculo envía el resultado a la cadena de mercado de predicción a través de un mensaje personalizado entre cadenas. 

  6. Luego, el usuario recibe sus ganancias cuando hizo la suposición correcta.

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 autoridadAdemá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

    

En la publicación anterior del blog de investigación  "Introducción a  la interoperabilidad de blockchain  "  , proporcionamos una...