Estamos anunciando oficialmente el próximo Lisk.js , nuestro evento anual centrado en desarrolladores de Lisk, abierto a todos los desarrolladores, entusiastas de blockchain y miembros de la comunidad a nivel mundial. Estamos orgullosos de ponerlo al día con todas las últimas noticias, logros y hojas de ruta de Lisk en 2021 y más allá.

Como Lisk.js 2019 fue un éxito sobresaliente, que reunió a una gran cantidad de desarrolladores y entusiastas de blockchain, decidimos organizar Lisk.js 2021 como un evento virtual de dos días, con charlas de los miembros del equipo de Lisk, junto con miembros de nuestros estimados Comunidad Lisk que ha estado creando aplicaciones blockchain con Lisk SDK.

Lisk.js regresará del 21 al 22 de mayo de 2021 y estará alojado completamente en línea, para que todos puedan permanecer seguros y saludables. Por tanto, el evento se retransmitirá en directo desde el escenario del recinto Kühlhaus de Berlín. Nuestro evento de dos días contará con una agenda repleta que comprenderá las últimas presentaciones de vanguardia y en profundidad de nuestros equipos de investigación, desarrollo y marketing. Estas charlas incluirán las últimas actualizaciones, una inmersión profunda en la solución de interoperabilidad Lisk, nuestro próximo hackathon en línea, demostraciones en vivo, nuestro programa Lisk Developer recientemente mejorado, la exhibición de aplicaciones blockchain de nuestros miembros de la comunidad principal Lisk y mucho más.

Formato de evento

El enfoque principal de Lisk.js 2021 estará en las especificaciones de interoperabilidad de Lisk. Nuestro principal objetivo era ofrecer una solución de interoperabilidad blockchain descentralizada y escalable para el ecosistema Lisk. Durante el evento, se darán a conocer todos los LIP de interoperabilidad (propuestas de mejora de Lisk), así como los planes de investigación y desarrollo para el 2021. 

El evento de dos días Lisk.js 2021 ha sido diseñado para atender a todos los niveles de conocimiento técnico y experiencia, incluidos los recién llegados al ecosistema Lisk, así como los entusiastas de blockchain y los profesionales del desarrollo. Por lo tanto, para cubrir todos los temas relevantes, decidimos dividir la agenda en un período de dos días. El primer día estará dedicado a mostrar la solución de interoperabilidad de Lisk, la nueva hoja de ruta de investigación de Lisk, los últimos anuncios de desarrollo y el próximo hackatón en línea. Además, Max Kordek, nuestro CEO y cofundador de Lisk, dará un discurso de apertura sobre nuestros logros y una nueva era de Lisk, junto con la visión de Lisk para el futuro. El segundo día del evento consistirá en presentaciones en profundidad de la solución de interoperabilidad Lisk, demostraciones para desarrolladores y charlas con la comunidad.

Puntos clave


  • Explicación de la solución de interoperabilidad Lisk junto con la revelación de todos los LIP correspondientes .
  • Anuncio de más información sobre la versión Lisk Core 3.0.0 con 28 LIP implementados y muchas otras mejoras.
  • Exhibición de Lisk SDK 5.1.0 con la experiencia de desarrollador muy mejorada.
  • Introducción del nuevo programa Lisk Developer .
  • Anuncio de nuestro próximo hackathon en línea .


Agenda preliminar

21 de mayo: Apertura de Lisk.js 2021 (6:00 p. M. A 9:00 p. M. CET)


6:00 pm - 6:10 pm: Max Kordek - Introducción a Lisk.js 2021

6:10 pm - 7:05 pm: Equipo de investigación - Introducción a la solución de interoperabilidad Lisk

7:05 pm - 7:15 pm: Jan Hackfeld - Anuncio de la nueva hoja de ruta de investigación de Lisk

7:15 pm - 7:20 pm: Descanso

7:20 pm - 7:35 pm: Equipo de desarrollo - Anuncios y actualizaciones de desarrollo

7:35 pm - 7:45 pm: Equipo de desarrollo: mejora de la experiencia del desarrollador de Lisk SDK

7:45 pm - 7:55 pm: Monica Tartau - Anunciando el Programa de Desarrolladores Lisk y el Hackathon en línea

7:55 pm - 8:15 pm: Max Kordek - Discurso de apertura del CEO

8:15 pm - 8:20 pm: Descanso

8:20 pm - 8:50 pm: Preguntas y respuestas

22 de mayo: Presentaciones exhaustivas de investigación y desarrollo (11:00 a.m. a 5:00 p.m. CET)


11:00 am - 2:00 pm: Equipo de investigación - Análisis profundo de la solución de interoperabilidad Lisk 

2:00 pm - 4:00 pm: Equipo de desarrollo - Desarrollo de aplicaciones Blockchain con Lisk SDK

4:00 pm - 5:00 pm: Exhibición de aplicaciones Blockchain por la comunidad Lisk 

La agenda completa, incluidos todos los ponentes, se anunciará en las próximas semanas en la página del evento Lisk.js 2021 , así como en todos nuestros canales de redes sociales.

Lisk.js 2021, el evento anual orientado a desarrolladores organizado por Lisk, reunirá a entusiastas de blockchain, desarrolladores, miembros de la comunidad y periodistas de todo el mundo. Esperamos tener una multitud de espectadores sintonizando el evento de transmisión en vivo en nuestro canal oficial de Lisk en YouTube . Asegúrese de no perderse este evento informativo suscribiéndose a nuestro canal y regístrese en línea para recibir actualizaciones periódicas. Lisk.js 2021 promete ser un evento extraordinario para Lisk y nuestra comunidad. Esperamos poder compartir esta ocasión especial con todos ustedes.

Fuente: blog de Lisk

  

Estamos anunciando oficialmente el próximo  Lisk.js  , nuestro evento anual centrado en desarrolladores de Lisk, abierto a todos los desarro...

Los desarrolladores de Bitcoin han propuesto una fecha para activar la actualización Taproot. Las fechas propuestas incluyen un “Speedy Trial” en mayo y el lanzamiento de Taproot en noviembre.

Taproot pretende mejorar la escalabilidad y la privacidad del Bitcoin. Será la mayor actualización activada en años.

Jeremy Rubin, colaborador de Bitcoin Core, describió estos planes en un Internet Relay Chat (IRC) público. En las notas, explica que el consenso confirma que se debería realizar un Speedy Trial a mediados de mayo. En caso de tener éxito, la actualización estaría disponible alrededor del 15 de noviembre.

El Speedy Trial tiene un plazo de tres meses para ver si los mineros apoyan la actualización.

Por lo tanto, cuanto antes comience la señalización, antes se activará Taproot. Sin embargo, Rubin señala que existe un consenso para no aplazar la activación más allá del 15 de noviembre, fecha que cae en las vacaciones.

“… pasado el Día de Acción de Gracias está la Navidad, luego Año Nuevo, después el Año Nuevo Chino y, de ser así, la actualización no se programaría hasta marzo“, escribe.

Aunque estas notas son una señal prometedora de que dicha actualización de Bitcoin está cerca de implementarse, como ocurre con todo desarrollo de Bitcoin, no hay certeza de que sea así.

Taproot, una actualización no controvertida

A pesar de ser una actualización no controvertida, los planes sobre la activación de Taproot han tardado en cuajar: la propuesta inicial tuvo lugar en mayo de 2019.

En diciembre de 2020, Binance Pool se unió a otros mineros para darle el visto bueno al soft fork Taproot, lo que elevó el consenso entre los mineros hasta un 91,05%.

A pesar del consenso general sobre Taproot, la nota también tiene una subsección sobre un soft fork simultáneo activado por el usuario (UASF). Los desarrolladores están codificando dicho UASF en caso de que el Speedy Trial falle y, en ese caso, el UASF funcionará online.

La discusión se centró en si el UASF debería poder lanzarse antes del Speedy Trial. Sin embargo, Rubin dice que esto socava el esfuerzo por evitar un fork polémico.

Sin embargo, es poco probable que, si se lleva a cabo un Speedy Trial, falle debido a que Taproot es bastante popular.

¿Qué es Taproot?

Taproot es un "soft fork" que mejora los scripts de Bitcoin para así incrementar la privacidad y favorecer otros factores vinculados a transacciones complejas. Las transacciones de la red Bitcoin pueden utilizar una serie de funciones que las hacen más complejas, como por ejemplo las emisiones con timelocks, los requisitos de multifirma (multi-signatures) y otros.
Sin Taproot, cualquiera puede detectar transacciones que empleen estas funcionalidades complejas -las cuales requieren la creación de múltiples transacciones. Sin embargo, la actualización Taproot hará posible "encubrir" todos los componentes móviles de una transacción de Bitcoin que incluya dichas funciones. Así que aunque las transacciones adoptan estas funciones, tendrán la misma apariencia que una transacción única. Se trata de una gran victoria para los defensores de la privacidad en Bitcoin.

De hecho, Taproot permite ocultar el hecho de que un script de Bitcoin ha llegado a ser ejecutado. Por poner un ejemplo, gastar Bitcoin utilizando Taproot podría hacer que una transacción en un canal de la Lightning Network, una transacción peer-to-peer, o un smart contract sofisticado resulten indistinguibles. Cualquiera que monitorizara dichas transacciones no vería nada más que una transacción peer-to peer. Cabe señalar, sin embargo, que esto no alterará el hecho de que los monederos del emisor y receptor final seguirán estando expuestos.

La propuesta de Taproot sería desvelada inicialmente en enero de 2018 por Greg Maxwell, desarrollador de Bitcoin Core. En octubre de 2020, Taproot habría sido ya integrado en la "library" (biblioteca/librería) de Bitcoin Core, tras un "pull request" de Pieter Wuille. Para que la actualización sea totalmente implementada, los operadores de nodos deben adoptar las nuevas reglas de consenso de Taproot. Dependiendo de cómo se desarrolle esto, la activación podría tardar meses.

Se espera que Taproot se implemente junto con otra actualización llamada firmas Schnorr. Esto no sólo hace posible la implementación de Taproot, sino que también habilita una característica muy esperada llamada agregación de firmas.

Junto con las Schnorr signatures (firmas Schnorr), Taproot es una actualización tecnológica de Bitcoin muy esperada desde la introducción de SegWit. El objetivo de Taproot es cambiar la forma en que operan los scripts de Bitcoin para mejorar la privacidad, escalabilidad y seguridad. Esto y mucho más será posible al combinar Taproot con una actualización vinculada, denominada Schnorr signatures.

Cualquiera que esté familiarizado con la comunidad cripto sabe que privacidad, escalabilidad y seguridad son preocupaciones muy importantes. Aunque Bitcoin es la criptomoneda más popular del mundo, dichas cuestiones aún deben ser solventadas. Taproot se propone hacer precisamente eso.

Fuentes: academy.binance, beincrypto

 

Los desarrolladores de  Bitcoin  han propuesto una fecha para activar la actualización Taproot. Las fechas propuestas incluyen un “Speedy Tr...



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...