Como ya se anunció a fines del año pasado, Lisk SDK 5.0.0 y Lisk Core 3.0.0 se han sometido con éxito a una auditoría de seguridad externa por parte de Least Authority , una empresa de auditoría de seguridad de renombre con mucha experiencia en la industria blockchain. En esta  queremos compartir la motivación de la auditoría de seguridad, brindar más detalles sobre el proceso general de auditoría y explicar los resultados que se dan en el Informe de auditoría de seguridad de la autoridad mínima.

Motivación para una auditoría de seguridad

Lisk SDK 5.0.0 y la próxima versión de mainnet Lisk Core 3.0.0 marcan un hito importante para el proyecto Lisk. Aparte de una gran cantidad de mejoras no relacionadas con el protocolo, se han implementado 28 propuestas de mejora de Lisk (LIP) como parte de Lisk Core 3.0.0. Cubrimos la mayoría de estos en detalle en la serie de publicaciones del blog de investigación el año pasado y también los resumimos aquí . Debido a la gran cantidad de cambios y nuestro compromiso con los más altos estándares de seguridad, era importante para nosotros que el nuevo protocolo Lisk, Lisk SDK 5.0.0 y la próxima versión de mainnet Lisk Core 3.0.0 se revisaran adicionalmente como parte de un auditoría de seguridad.

Una auditoría de seguridad de software es una revisión de una implementación con el fin de verificar si se adhiere a los estándares de seguridad, las mejores prácticas y si satisface las especificaciones y declaraciones de seguridad correspondientes. En particular, esto incluye buscar vulnerabilidades o errores en el software. Para las cadenas de bloques públicas como Lisk, la seguridad del software es de suma importancia, ya que cualquiera puede interactuar con la cadena de bloques enviando transacciones o forjando bloques y, por lo tanto, cualquier vulnerabilidad existente en el software puede explotarse fácilmente. Los grandes valores monetarios involucrados en las cadenas de bloques también brindan un gran incentivo para que los atacantes estén constantemente buscando vulnerabilidades. Por estas razones, las auditorías de seguridad independientes de los principales lanzamientos se han convertido en una práctica común en la industria blockchain.

Con esto en mente, ya comenzamos a prepararnos para una auditoría de seguridad mucho antes de completar Lisk SDK 5.0.0 y Lisk Core 3.0.0. Después de haber evaluado y hablado con varias empresas especializadas en auditorías de seguridad de blockchain, la Fundación Lisk finalmente decidió contratar a la Autoridad Mínima debido a su experiencia y un equipo sólido con conocimientos diversos. Sus comentarios positivos y el resultado de la auditoría dan confianza en nuestros estándares de seguridad, nuestros procesos de investigación y desarrollo y los próximos pasos para lanzar Lisk Core 3.0.0 a la red principal.

Proceso de auditoría

La primera parte importante del proceso de auditoría fue definir claramente el alcance de la auditoría. Para la auditoría de seguridad de Least Authority, este fue el diseño e implementación del protocolo Lisk:

• Lisk SDK 5.0.0: https://github.com/LiskHQ/lisk-sdk/tree/v5.0.0-alpha.3
• Lisk Core 3.0.0: https://github.com/LiskHQ/lisk-core/tree/v3.0.0-alpha.4
• Protocolo Lisk:
  • Documentación del protocolo: https://lisk.io/documentation/lisk-protocol
  • Lisk propuestas de mejora (labios): https://github.com/LiskHQ/lips

Por lo tanto, la auditoría cubrió el protocolo completo y, por lo tanto, todas las partes críticas para la seguridad del software del nodo. Esto incluye, por ejemplo, la capa de igual a igual, el grupo de transacciones, el algoritmo de consenso Lisk-BFT, el algoritmo de firma, así como la codificación y el procesamiento de transacciones y bloques. Puede encontrar la descripción detallada del alcance en la sección Cobertura del Informe de auditoría de seguridad .

Poco después de completar el desarrollo de Lisk SDK 5.0.0 y Lisk Core 3.0.0, tuvimos una reunión con Least Authority para iniciar la auditoría, discutir el alcance y aclarar el proceso general de auditoría. A partir de entonces, los especialistas en seguridad de Least Authority revisaron nuestra documentación, especificaciones y código utilizando una variedad de herramientas y técnicas de seguridad como análisis de código estático , pruebas de fuzz , controles de seguridad contra dependencias o revisiones manuales. Puede encontrar más detalles sobre su enfoque y metodología en el informe de auditoría. Durante toda la revisión, nos comunicamos con regularidad, respondimos cualquier pregunta que surgiera y ya tuvimos la oportunidad de abordar directamente los hallazgos que compartieron con nosotros.

Después de cinco semanas de revisión del código y el protocolo, recibimos una versión inicial del informe de auditoría. Luego analizamos a fondo los hallazgos documentados y los discutimos con la Autoridad mínima. Para algunos de los hallazgos, preparamos una solución antes de recibir el informe de auditoría inicial. Con respecto a otros hallazgos, finalmente decidimos no cambiar la implementación, ya que no los veíamos como un problema de seguridad y un cambio de implementación hubiera implicado otras desventajas. Para todos los hallazgos del informe de auditoría inicial, también redactamos una respuesta detallada que también se incorporó parcialmente en el informe de auditoría final publicado. En la siguiente sección, resumimos la retroalimentación general en el informe y también explicamos los diferentes hallazgos. En particular,

Resultado de la auditoria

Retroalimentación general

La auditoría informó la alta calidad general del código base de Lisk y felicitó al proyecto Lisk por seguir las mejores prácticas en cuanto a seguridad, diseño de software y escritura de código. El equipo de Lisk siempre ha tenido como objetivo seguir los más altos estándares en esas áreas y utiliza múltiples herramientas para garantizar una alta calidad del código.

"El código está bien escrito y sigue constantemente las mejores prácticas de la industria para TypeScript".

Una parte muy importante de cualquier proyecto de software es la documentación. Como Blockchain es un campo relativamente nuevo, esto es especialmente cierto. Tener una documentación bien redactada nos permite dar la bienvenida a nuevos miembros a nuestra comunidad, ya sea como operadores de nodos o desarrolladores de cadenas laterales. En ese sentido, la auditoría encontró que nuestra documentación estaba bien redactada y cubría todos los aspectos importantes de nuestro proyecto.

"La documentación es completa, útil y precisa. Felicitamos al equipo de Lisk por brindar una cobertura completa de las opciones de diseño del sistema y el razonamiento de las decisiones de diseño".

La sencillez y la transparencia son valores fundamentales en el desarrollo del proyecto Lisk. Nuestro objetivo es ser abiertos y comunicar las decisiones de la manera más clara y objetiva. El equipo de auditoría felicitó la documentación y los LIP al proporcionar información sobre las opciones de diseño. Por último, y quizás lo más importante, la auditoría destacó el sólido enfoque de seguridad que seguimos. El equipo de investigación está trabajando arduamente para proponer actualizaciones de protocolo que sean seguras y garanticen la seguridad de la cadena de bloques Lisk.

"Descubrimos que el trabajo del equipo de Lisk es muy consciente de la seguridad: ya habían anticipado varios ataques potenciales y aplicaron mitigaciones".

Problemas y sugerencias específicos

En este apartado explicamos las tres cuestiones y dos sugerencias señaladas en el informe de auditoría y nuestro punto de vista para cada una de ellas.

Problema A: Error inesperado de Lisk-codec

El primer problema que se encontró fue un problema con el códec Lisk. La codificación predeterminada asignaría un objeto vacío a las matrices cuando no se proporcionó ningún elemento válido para la matriz, lo que resultaría en un valor de retorno no válido que no fue manejado por el códec Lisk. Por lo tanto, si la función que llama al códec Lisk no manejó correctamente el error, es posible que se hayan producido efectos secundarios no deseados. No hubo una amenaza de seguridad directa como resultado de este problema en el SDK, y ya se solucionó al final de la auditoría de seguridad.

Problema B: Cifrado mnemónico de CLI Lisk-core

El segundo problema se centró en la función de derivación de claves basada en contraseñas utilizada para crear la clave de cifrado para la frase de contraseña mnemotécnica en el lado del cliente. Para forjar bloques, los nodos delegados necesitan acceso a la frase de contraseña del delegado para firmar el bloque. Por razones de seguridad, la frase de contraseña no se almacena en el disco duro como texto sin formato, ya que, de lo contrario, cualquier persona con acceso al disco duro podría robarla fácilmente. En cambio, la frase de contraseña está encriptada con una contraseña que debe ingresar el operador del nodo para falsificarla. Es por eso que Lisk Elements implementa una función para cifrar la contraseña basada en PBKDF2 y AES. PBKDF2 es un esquema bien conocido para la derivación de claves basada en contraseñas debido a sus propiedades de estiramiento de claves . 

Como señala acertadamente el informe de auditoría, hoy en día existen algoritmos más nuevos para este propósito que tienen mejores propiedades que PBKDF2. En particular, Argon2 , que fue el ganador del Concurso de hash de contraseñas hace unos años, tiene propiedades superiores de resistencia a ASIC y agotadoras de memoria que PBKDF2. Sin embargo, PBKDF2 se usa ampliamente en muchos software críticos para la seguridad, como por ejemplo 1Password . Además, para que el ataque descrito en el informe sea posible, se asume que el atacante tiene acceso a la frase de contraseña encriptada, e incluso en este caso, no sería factible forzarla si el nodo delegado usa una contraseña segura.. Por lo tanto, después de considerar los pros y los contras del esquema actual, decidimos continuar apoyando el algoritmo PBKDF2 como el esquema predeterminado para derivar una clave de cifrado en Lisk Elements. 

Dicho esto, la opción adicional de Argon2 junto con PBKDF2 definitivamente será algo bueno para los operadores y delegados de nodos. Es por eso que hemos agregado el soporte de este algoritmo a las tareas futuras de nuestro equipo de desarrollo.

Problema C: derivación de claves de cuenta

La tercera cuestión planteada por el informe de auditoría se refería al algoritmo de derivación de claves de cuenta utilizado en Lisk. Este algoritmo calcula la clave privada para firmar bloques y transacciones a partir de la frase de contraseña proporcionada por el usuario. El método actual para derivar la clave privada de una cuenta es hash de la frase de contraseña usando la función hash SHA-256. El informe señaló que otros métodos de derivación de claves como HKDF tienen propiedades mejor probadas y recomendó que los productos Lisk utilicen dicho algoritmo. El equipo de auditoría también recomendó que todos los usuarios cambien su frase de contraseña en caso de que se implemente este cambio de algoritmo.

El informe señala que el método utilizado actualmente no corre el riesgo de ataques conocidos y que modificar este proceso sería un cambio radical. Después de haber examinado la opción propuesta, el equipo de Lisk ha decidido mantener el método de derivación de claves actual. Cambiar la derivación de claves implicaría que cada usuario de Lisk necesitaría generar una nueva contraseña y transferir todos los fondos de la cuenta anterior a la nueva. Para obtener compatibilidad con versiones anteriores, todas las carteras Lisk también deberían admitir ambos métodos de derivación de claves con la opción de cambiar entre ellos. Consideramos que la pérdida de experiencia del usuario y los riesgos de renunciar a esta migración superaban los beneficios de la propuesta.

En una nota técnica, las carteras de terceros podrían implementar un mecanismo de derivación de claves diferente y usar HKDF como lo propone el informe de auditoría. Sin embargo, tal implementación no sería compatible con la billetera oficial de Lisk, ya que generaría una clave privada diferente para la misma frase de contraseña.

Sugerencia 1: corregir errores tipográficos en la documentación

Least Authority encontró algunos errores tipográficos en nuestra documentación que arreglamos de inmediato.

Sugerencia 2: utilice una clave de dirección y una clave de firma independientes

Finalmente, Least Authority sugirió separar el par de claves usado para calcular la dirección de las claves usadas para firmar transacciones o falsificar bloques. Actualmente, no hay distinción en el protocolo Lisk entre estos dos casos de uso, y si las claves están comprometidas, el usuario tiene que crear una nueva cuenta para intentar ahorrar sus fondos. Para mitigar esto, Least Authority sugirió usar un nuevo conjunto de claves, junto con la clave pública original, para firmar transacciones. La clave privada original se utiliza luego para firmar una transacción de revocación de clave, en caso de que las nuevas claves se vean comprometidas.

Consideramos cuidadosamente esta sugerencia y finalmente decidimos no implementarla al momento de responder a la auditoría de seguridad. Creemos que la sugerencia solo aporta una ganancia de seguridad real si no complica mucho la experiencia del usuario. Por ejemplo, si los usuarios normales tuvieran que manejar varias frases de contraseña con diferentes permisos de forma predeterminada, es posible que se sientan abrumados por la complejidad, se bloqueen de sus cuentas o simplemente almacenen todas las frases de contraseña en el mismo lugar. Por lo tanto, preferimos el enfoque simple actual con una frase de contraseña por cuenta como predeterminada y la posibilidad de registrar una cuenta de firma múltiple para mayor seguridad. No obstante, estamos evaluando la posibilidad de introducir una gestión de claves más avanzada como una posible característica del Lisk SDK.

En conclusión, los resultados positivos de la auditoría de seguridad realizada por Least Authority demuestran la alta calidad de nuestra base de código, lo que nos permite lanzar de forma segura el próximo Lisk Core 3.0.0 a la red principal. Ahora que se ha completado la auditoría de seguridad, el desarrollo continúa en Lisk SDK 5.1.0. Uno de los objetivos de esta versión es agregar comandos para generar una plantilla de aplicación blockchain que incluya módulos, activos, complementos, configuración y un bloque de génesis para comenzar a desarrollar una aplicación blockchain. Otro objetivo de esta versión es agregar un complemento de tablero con el objetivo de proporcionar a los desarrolladores un explorador de blockchain integrado, que permite a los usuarios enumerar cuentas, bloques y transacciones. Otro objetivo de esta versión es agregar un marco de prueba de aplicaciones que permitirá a los desarrolladores probar partes críticas de su aplicación. Por lo tanto, como se ve en los objetivos de lanzamiento, el lanzamiento de Lisk SDK 5.1.0 viene con una experiencia de desarrollador mejorada.

Recursos:

• Lisk Chat
• Página del SDK de Lisk
• Página de investigación
• Foro de Lisk Research
• Twitter
•  Fuente: blog de Lisk
• 
  
• 

¿Qué es RSK?

En este articulo vonocerás a RSK, un increible proyecto que agrupa la creación de un ecosistema de token propio, smart contracts, red pagos instantáneos, sistema de identificación digital y almacenamiento distribuido usando para ello la blockchain de Bitcoin y soluciones sidechains integradas.

La plataforma de segundo nivel RSK, plataforma de smart contracts más segura del mundo, fue diseñada con la finalidad de permitir la creación de smarts contracts o contratos inteligentes dentro de la blockchain de Bitcoin, pero sin cambiar nada en el funcionamiento de Bitcoin.

Bitcoin fue diseñado de forma deliberada con altas restricciones a la hora de ejecutar smart contracts, debido a la búsqueda de una plataforma sólida y segura. No obstante, debido al auge de blockchains como Ethereum, que si permiten crear smart contracts evolucionados, son muchas las peticiones de poder ejecutar smart contracts avanzados en Bitcoin. Pese a que implementar los cambios necesarios en Bitcoin para que esto ocurra es algo realmente complicado a nivel de consenso, proyectos como RSK ofrecen soluciones encaminadas a satisfacer esta necesidad. 

La solución de interoperabilidad Lisk tiene como objetivo establecer un ecosistema sin permisos de aplicaciones de cadena de bloques interoperables y descentralizadas . Ahora veremos un esquema de las diferentes técnicas de interoperabilidad para luego enmarcar el enfoque de Lisk y sus funcionalidades esperadas en futuros artivulos 

Hace diez meses que se completó toda la investigación hasta la interoperabilidad de blockchain. Como se explicó en ese entonces, el enfoque principal del equipo de investigación ha estado en la última fase de la hoja de ruta del protocolo desde principios de 2020. El objetivo es ofrecer una solución de interoperabilidad blockchain escalable y descentralizada para el ecosistema Lisk.

En los próximos meses, divulgaremos todos los detalles de esta investigación y la solución de interoperabilidad Lisk. Sin embargo, antes de eso, veamos primero qué es la interoperabilidad blockchain y por qué es un concepto crítico en nuestra industria. Para explicar esto, daremos una introducción técnica al tema, los casos de uso, las propiedades requeridas y las principales técnicas para lograr la interoperabilidad blockchain.

¿Qué es la interoperabilidad de Blockchain?

La interoperabilidad de blockchain se está convirtiendo en el santo grial para desbloquear la amplia adopción de la tecnología blockchain y las finanzas descentralizadas (DeFi). En los últimos años, este término ha aparecido en muchos portales de noticias especializados, artículos de investigación y la hoja de ruta de muchos proyectos de blockchain. En términos generales, la interoperabilidad de blockchain se define como la capacidad de dos blockchains para transmitir información de uno a otro.

Más precisamente, decimos que dos blockchains son interoperables si una transacción o transición de estado de una cadena puede depender de una transacción o transición de estado de la otra cadena. Este escenario general se muestra en la siguiente figura: La transacción, t ₁ o la transición de estado, s ₁ en la cadena 1 pueden causar una transacción t ₂en la cadena 2. La misma idea se aplica en la otra dirección para t ' ₂ y s' ₂ en la cadena 2 y t ' ₁ en la cadena 1. 

Un ejemplo común de este escenario es una transferencia de token básica entre cadenas. Digamos que estamos en el ecosistema Lisk donde la cadena 1 es la cadena principal Lisk y la cadena 2 es una cadena lateral existente. En este caso, un usuario envía t 1 para transferir 100 tokens LSK de la cadena principal a la cadena lateral, y t 2 acredita 100 tokens LSK en la cuenta de usuario correspondiente en la cadena lateral.

Sin embargo, la interoperabilidad de blockchain se extiende más allá de este ejemplo y se puede lograr de varias maneras con diferentes compensaciones y para diferentes casos de uso.

¿Por qué la interoperabilidad Blockchain?

Las cadenas de bloques fueron concebidas para ser libros de contabilidad descentralizados autosuficientes, donde la validez de cualquier transición de estado, es decir, transacciones y bloques, solo depende del historial de la cadena de bloques en sí. Esto significa que las cadenas de bloques son independientes y autónomas, lo que implica ciertas limitaciones:

• Casos de uso limitados y aislados : la mayoría de las aplicaciones blockchain existentes sirven para casos de uso específicos, desde redes de pago hasta sistemas de almacenamiento descentralizados. Sin embargo, estas aplicaciones de blockchain solo prosperarán en el contexto de un marco general, es decir, un ecosistema, donde los usuarios tienen acceso a todas las diferentes funcionalidades sin fricciones.
• Un buen ejemplo es el ecosistema DeFi, que solo puede lograr una adopción masiva si los usuarios pueden acceder al conjunto de herramientas financieras tan fácilmente como en los sistemas financieros heredados. Se puede decir que una sola cadena de bloques general también puede servir para muchos casos de uso, pero luego puede enfrentar un segundo problema: la escalabilidad.   

• Escalabilidad limitada : una cadena de bloques independiente tiene una capacidad limitada en la cantidad de transacciones que puede procesar en un tiempo determinado. Las soluciones de escalado en cadena, como aumentar el tamaño del bloque, son un primer enfoque válido, pero eventualmente terminarán enfrentando el problema original.
  
  Esto se puede mejorar enormemente con la interoperabilidad, ya que la aplicación puede escalar con la cantidad de cadenas de bloques interconectadas. Por ejemplo, si una cadena de bloques tiene una capacidad de 15 transacciones por segundo, n cadenas de bloques interconectadas de la misma naturaleza permitirán hasta n × 15 transacciones por segundo.

Una solución sólida para interconectar blockchains puede ayudar a mejorar, o incluso resolver por completo, estas limitaciones. Las diferentes aplicaciones de blockchain podrán interoperar y fusionar su funcionalidad para los usuarios finales, mientras que las blockchains bien establecidas pero sobrecargadas podrán usar otras cadenas como soluciones de capa 2.
Entonces, ¿qué necesitamos para que una solución de interoperabilidad blockchain sea sólida? Podemos resumir las principales propiedades necesarias para la interoperabilidad blockchain en los siguientes puntos:

• Atomicidad : cuando ocurre una interacción entre cadenas, sus efectos se aplican en ambas cadenas de bloques o en ning

En el diagrama de arriba podemos ver cómo Alice (A) realiza un intercambio atómico con Bob (B):

1. Primero, Alice envía una transacción HTLC en la cadena 1 con Bob como destinatario y un hash.
2. Bob realiza una transacción similar en la cadena 2 con Alice como destinataria y el mismo hash.
3. Alice reclama los tokens en la cadena 2 al revelar la preimagen hash a tiempo.
4. Bob reclama los tokens en la cadena 1 usando la misma preimagen hash.

Los intercambios atómicos basados ​​en HTLC son simples de implementar y de naturaleza confiable. Se han utilizado en varios proyectos, como Litecoin y Monero, como medio para intercambiarlos por Bitcoin. También se implementan en intercambios descentralizados como atomex.me y atomicdex.io . Sin embargo, no son muy prácticos, ya que suelen ser lentos y requieren una sincronización adecuada entre cadenas.

Transferencia de tokens entre cadenas

En las transferencias de tokens entre cadenas, no necesitamos otra parte con quien intercambiar los tokens. Un usuario puede simplemente transferir sus tokens de una cadena a otra como vimos en el ejemplo al comienzo de esta publicación de blog. Una vez que se completa la transferencia, deberían poder usar los tokens en la cadena de recepción sin encontrar ningún problema. Los dos enfoques más representativos de este marco se pueden ver a continuación.

Conección de 2 vías federadas

En los esquemas de vinculación bidireccional federados, las transferencias de tokens son facilitadas por una federación. Una federación es un grupo de intermediarios de confianza que opera una cuenta de firma múltiple en ambas cadenas y mantiene la vinculación del token transferido.

Estos esquemas generalmente tienen una estructura de cadena principal-cadena lateral, y la federación está a cargo de acuñar y quemar tokens en la cadena lateral, de acuerdo con las transferencias de tokens en la cadena principal. La Red de Liquid es el mejor ejemplo conocido de un 2-way federados PEG. Es una cadena lateral de Bitcoin que está destinada a ayudar con su escalabilidad al ofrecer tarifas más bajas con el token L-BTC vinculado a BTC.

Las conección de dos vías federadas son fáciles de implementar y pueden mostrar un buen rendimiento, pero requieren un cierto nivel de confianza en la federación. Si la mayoría de los miembros de la federación son malintencionados, los usuarios pueden perder los tokens transferidos a la cadena lateral.

Marco de plasma

Este esquema de transferencia de tokens se propuso originalmente como una solución de capa 2 para escalar Ethereum. Una cadena lateral de Plasma está conectada a la cadena principal de Ethereum, donde publica regularmente información sobre su estado. Muchas transacciones pueden ocurrir en la cadena Plasma, y ​​luego Ethereum solo se usa como capa de liquidación para transferencias dentro y fuera de la cadena Plasma.

A diferencia de las cconecciónes federadas, los usuarios no necesitan confiar en los operadores de la cadena Plasma, ya que cualquier actividad maliciosa en la cadena Plasma puede ser cuestionada en la cadena principal. Si el desafío tiene éxito, el usuario recuperará sus fondos originales. Esto viene con el mayor inconveniente de las transferencias lentas de regreso a la cadena Ethereum. Cada solicitud de retiro en Plasma se retrasa 7 días para permitir que los usuarios la impugnen. Esta solución también requiere que los usuarios monitoreen activamente sus tokens en la cadena Plasma.  

Hay varias implementaciones de Plasma que funcionan con muchos detalles y compensaciones diferentes. Aquí acabamos de proporcionar el marco general y las características. Si desea saber más, le recomendamos explorar los enfoques adoptados por proyectos como OmiseGO con la implementación de Plasma MVP o Loom con Plasma Cash.

Mensaje general de cadena cruzada

En este caso, la solución de interoperabilidad permite la transferencia de cualquier tipo de datos o mensajes entre las cadenas conectadas. Nuestra solución técnica para el ecosistema Lisk irá en esta dirección y, potencialmente, cualquier mensaje o transacción personalizada se transferirá entre cadenas laterales. Veamos qué significa esto con un ejemplo: considere un ecosistema donde, entre muchas otras aplicaciones de cadena de bloques, hay una cadena lateral Lisk Oracle que autentica cualquier dato fuera de la cadena. Supongamos ahora que implementamos una solución general de interoperabilidad entre cadenas en este ecosistema.

Esto significa que podemos tener transferencias de tokens entre cadenas laterales, por ejemplo, los usuarios que transfieren tokens de la cadena lateral Lisk Gold a la cadena lateral Lisk Bet para participar en una apuesta deportiva. Pero lo que es más interesante, Lisk Oracle también puede enviar mensajes entre cadenas a Lisk Bet con los resultados deportivos y a Lisk Gold con el precio actual de una onza de oro. 

Podemos ver que una solución de interoperabilidad blockchain que permita este tipo de mensajes generales es la clave para lograr una sinergia de casos de uso y características proporcionadas por aplicaciones descentralizadas independientes. Por supuesto, este marco general implica un protocolo de interoperabilidad más complejo y requiere una definición sólida del sistema de mensajería estándar entre cadenas. Examinemos algunos enfoques potenciales en este marco.

Certificación de cadena cruzada

Este esquema define una estructura de datos específica, el certificado, que es entendido por las cadenas interoperables y sirve como una especie de paquete para entregar los mensajes entre cadenas. Este certificado también contiene información sobre su validez, por ejemplo, firmas de aprobación de los validadores de la cadena de envío. En principio, los certificados pueden funcionar de la misma forma en ambas direcciones. En el ejemplo que se muestra en la figura siguiente, la cadena 2 es la cadena de envío y la cadena 1 es la cadena de recepción. 

En términos concretos, un certificado puede contener lo siguiente:

• Los mensajes de cadena cruzada t 1 , t 2 y t 3 que se enviaron en la cadena 2 que apuntan a la cadena 1 desde el último certificado.
• Cierta información que autentica que los mensajes anteriores entre cadenas se incluyeron y finalizaron en la cadena 2 . Por ejemplo, esto lo pueden hacer los validadores de la cadena 2 acreditando con sus firmas que todos los datos incluidos hasta un determinado bloque son definitivos. 

Este esquema también requiere un retransmisor, un participante de la red a cargo de recopilar y publicar los certificados de una cadena a la otra cadena. Esto lo puede hacer cualquier usuario o los propios validadores de cadena.

Los certificados cross-chain son una solución escalable y eficiente que permite el paso de cualquier tipo de información entre cadenas. Sin embargo, implica ciertas restricciones y requisitos para las cadenas conectadas: deben poder generar certificados, validarlos y la información que contienen. Parece ser el enfoque apropiado para un ecosistema con diferentes aplicaciones de blockchain creadas a partir de una pila de tecnología común. Un ejemplo de esto son los estándares IBC de Cosmos que van en una dirección similar a la expuesta aquí. Sin embargo, probablemente el ejemplo más cercano de interoperabilidad basada en certificados es el propuesto en este documento por IOHK 

Fragmentación heterogénea de blockchain

El término 'fragmento' proviene del contexto de una base de datos y significa una partición horizontal de una base de datos o sistema. En esquemas de fragmentación de blockchain heterogéneos, un fragmento central conecta una gran cantidad de máquinas de transición de estado diferentes. En general, estas máquinas de estado no necesitan ser blockchains per se, solo necesitan cumplir ciertos requisitos para estar conectadas y aseguradas por el fragmento central.

El mejor ejemplo de tal enfoque es el ecosistema de Polkadot.. En Polkadot, cada una de estas máquinas de estado, conocidas como paracaídas, se basa en el fragmento central para su protocolo de cadena cruzada y su seguridad. Mientras el fragmento central sea seguro, las paracaídas operarán (inter) de forma segura en el ecosistema. Este esquema generalmente se conoce como "seguridad agrupada". En pocas palabras, cada parachain prepara un 'blob de información' en un formato específico, y ciertos validadores en el fragmento central se aseguran de que sea correcto contra una función de transición de estado. Si ese es el caso, entonces el fragmento central acepta el 'blob de información' y avanza el parachain. 

Este 'blob de información' puede contener mensajes dirigidos a otras paracaídas. El fragmento central no procesa los mensajes, pero los ordena, los pone en cola y los enruta siguiendo un protocolo estándar.

El concepto de 'seguridad agrupada' junto con un protocolo de paso de mensajes debería permitir que los ecosistemas similares a Polkadot tengan interacciones sin confianza entre fragmentos. Estas interacciones pueden ser de cualquier tipo, no solo tokens, y se enrutarán de forma segura a través del fragmento central. Sin embargo, estas capacidades no vienen sin costo. El protocolo Polkadot es ciertamente complejo, tanto a nivel de implementación como en términos de incentivos para los participantes de la red. Esto también tiene un impacto en la escalabilidad ya que solo un número limitado de paracaídas podrá ser parte del ecosistema.

Como nota al margen, la comunidad Ethereum está trabajando actualmente para ofrecer una solución de fragmentación de blockchain homogénea para Eth2.0

En el caso homogéneo, las instancias de la misma base de datos se dividen en la red en diferentes fragmentos. También existe un mecanismo para enviar transacciones entre fragmentos, sin embargo, todas son parte de la misma plataforma blockchain.

Rollups

Los rollups se proponen como otra solución de capa 2 para escalar Ethereum, más flexible que el marco Plasma pero con mayor complejidad. La idea aquí es agrupar o "acumular" transacciones de cadena lateral en una sola transacción y generar una prueba criptográfica de ello. Esta prueba, que es compacta y / o se genera muy raramente, se envía luego a la cadena principal. Se requiere que la cadena principal verifique la validez de la prueba, que en Ethereum se realiza mediante un contrato inteligente específico. 

Hay dos tipos de soluciones acumuladas según la naturaleza de la prueba:

• Acumulaciones optimistas : en este esquema, los bloques de la cadena lateral simplemente se publican en la cadena principal, sin ningún procesamiento, y después de un tiempo se aceptan. Por eso se le llama optimista. Solo si se desafía el bloque de la cadena lateral, la cadena principal evaluará la (in) validez del bloque. Esto se realiza mediante pruebas de fraude. Durante el período de desafío de un bloqueo, cualquier usuario puede enviar una prueba que demuestre que hubo algún problema con el bloqueo. Los retransmisores, es decir, los usuarios que publican el bloque de la cadena lateral en la cadena principal, deben apostar algunos tokens en la cadena principal junto con el nuevo bloque. Si la prueba de fraude tiene éxito, entonces el bloque de la cadena lateral se rechaza y el retransmisor pierde su depósito.

• Paquetes acumulados de conocimiento cero (ZK-Rollups) : todas las transacciones en la cadena lateral se agrupan y se genera una prueba de conocimiento cero de su validez mediante el uso de ZK-STARK . Esta prueba se publica y valida periódicamente en la cadena principal. Esta solución es más segura que la contraparte optimista y no necesita períodos de desafío. Sin embargo, una solución general de ZK-Rollup todavía es un trabajo en progreso y las implementaciones propuestas actualmente están más cerca de un esquema de transferencia de token entre cadenas que de una solución de interoperabilidad general. Además, los ZK-STARK son computacionalmente muy costosos de generar y complejos de implementar.

Conclusiones

En esta publicación de blog, hemos visto diferentes enfoques para lograr la interoperabilidad entre blockchains con sus principales características y usos. Definitivamente creemos que un enfoque de interoperabilidad sólido es un hito crítico para la adopción masiva de esta tecnología. En particular, una solución que permita pasar cualquier tipo de mensaje de cadena en cadena puede abordar las principales limitaciones de la tecnología blockchain. El equipo de investigación de Lisk tiene como objetivo ofrecer una solución en esta dirección para el ecosistema Lisk. Este será el tema de la próxima publicación del blog, donde presentaremos la solución de interoperabilidad Lisk y cubriremos sus características principales. 

Lisk tiene la misión de permitirle crear aplicaciones blockchain descentralizadas, eficientes y transparentes. 

Recursos:

• Lisk Chat
• Página del SDK de Lisk
• Página de investigación
• Foro de Lisk Research
• Twitter
•  Fuente: blog de Lisk

•