Recientemente he decidido comenzar una serie de artículos que comparen y contrasten Ardor con otros proyectos de cadenas de bloques (blockchains) que aparentan tener objetivos y características similares. Aproximadamente cada semana escogeré un proyecto que su alcance coincida, aunque solo sea en una pequeña parte, con Ardor. Analizaré la documentación técnica del otro proyecto y publicaré un resumen de mis descubrimientos.

Esta semana he estado leyendo sobre Lisk.

Lisk

En pocas palabras, Lisk es una plataforma para el desarrollo aplicaciones descentralizadas (dapps) que se ejecutan en cadenas de bloques laterales (sidechains) ancladas a la cadena de bloques (blockchain) principal de Lisk. Para mantener la seguridad de la cadena principal utiliza un mecanismo de consenso llamado Prueba-de-Participación Delegada (Delegated Proof-of-Stake ó DPOS). Cada cadena lateral es responsable de su propia seguridad (algo parecido, pero por favor lee la descripción del “mercado de delegados” que se encuentra a continuación). El protocolo utiliza una serie de transacciones predefinidas, similares a Nxt o Ardor, a diferencia del lenguaje de scrypt de bajo nivel que forma la base de Bitcoin o Ethereum.

Antes de entrar en detalle, debo comenzar diciendo que Lisk está definitivamente en una fase inicial de desarrollo. El equipo está en la mitad del proceso de volver a escribir el SDK de Lisk, encargado de apoyar el desarrollo de las cadenas laterales (sidechains) y está continuamente reconfigurando el Lisk Core, que es el nodo completo.

Con el código en flux, algunas cuestiones básicas de su arquitectura, en particular sobre las cadenas laterales (sidechains) y cómo intereactuan unas con otras y con la mainchain, todavía no parecen haber sido definidas. Por otro lado, me resultó muy difícil encontrar una fuente de información técnica y autorizada sobre Lisk, por lo que lo que presento aquí tal vez podría estar desactualizado. La mejor fuente de información que encontré fue la wiki, este artículo de uno de los co-fundadores, la hoja de ruta, y estos videos en YouTube. Desgraciadamente, ninguna de las tres fuentes es reciente, y los vídeos incluso no tratan el tema con mucha profundidad (aunque debo admitir que no he visto las más de 6 horas de estos videos). Si encuentras mejores referencia, te agradecería que me las hicieses llegar.

El grueso del marketing que rodea Lisk parece centrarse en el SDK, cuya meta es la de permitir construir y lanzar fácilmente un dapp seguro en una cadena de bloques adaptable. Los desarrolladores escribieron el SDK en Javascript porque querían hacer a Lisk accesible a una audiencia lo más amplia posible, y también desarrollaron el backend en Javascript (Node.js) porque, bueno… creo que nunca entenderé porque la gente insiste en escribir el backend en Javascript. 🙂

Pero claramente, la facilidad de desarrollar y desplegar una cadena de bloques a medida no es la única meta de Lisk. Si lo fuese, entonces ¿cuál sería el propósito de la cadena principal? Podrías también clonar Bitcoin o Nxt si todo lo que necesitas es solo un buen punto de inicio para construir tu propia cadena de bloques.

La arquitectura de cadena principal / cadena lateral (mainchain / sidechain) es realmente la característica distintiva de esta plataforma. Por lo que puedo determinar, la cadena principal tiene tres funciones primordiales:

La API de Lisk permite depósitos de LSK en la cadena principal para ser transferidos hacia/desde las cadenas laterales. Con esas dos transacciones será posible enviar LSK desde una cadena lateral a otra, por medio de la cadena principal. Desgraciadamente, de acuerdo al artículo escrito por uno de los co-fundadores, cuyo link se encuentra abajo, parece ser que enviar LSK hacia un sidechain requerirá enviarlo al dueño de la cadena lateral, lo que requiere cierto grado de confianza, obviamente. Para evitar este problema, será posible crear cadenas laterales que utilicen sus propios tokens de forjado, en lugar de LSK. Este token deberá ser tradeado por LSK para poder realizar las transacciones a través de la cadena principal con otras cadenas laterales. Alternativamente, puede que sea posible que una cadena lateral realizar transacciones directamente con otra cadena lateral sin tener que recurrir a la cadena principal, pero los desarrolladores se encuentran todavía investigando como funcionaría esto.
A la larga, el equipo planea construir un “mercado de delegados” dónde los delegados que no estén asegurando la cadena principal pueden ofrecer seguridad a las cadenas laterales. Estos delegados, podrían ser pagados por el dueño de la cadena lateral o por sus usuarios. Una vez más, los detalles son un poco confusos, pero aquí parece haber mucho valor: presumiblemente la red de Lisk ya es mucho más grande que una cadena de bloques típica y el “mercado de delegados” proporciona a las cadenas laterales un conjunto de nodos disponibles listos para utilizarse y proteger a la cadena desde sus primeros pasos.
Algunos nodos de la red (no estoy seguro de cuáles) calcularán, de manera periódica, el hash de las cadenas laterales y los almacenará en la cadena principal como una manera de “validación básica de la integridad de la cadena lateral”. Sin embargo, no me ha sido posible encontrar detalles de cómo se espera que este mecanismo funcione.

Además de estas funciones, y del papel obvio que juega en la transferencia de LSK entre cuentas, la cadena principal en sí misma no parece tener otros usos previstos. Toda la actividad se supone que será realizada en las cadenas laterales.
Comparado con Ardor

Comparado con Ardor

¿Cómo se compara esta arquitectura con el esquema de cadena madre / cadenas hijas de Ardor?

Quizá la diferencia más obvia es que cada cadena lateral debe de tener su propio conjunto de nodos para asegurarla, que puden ser proporcionados por el creador de la cadena lateral, por los usuarios o, a largo plazo, por el “mercado de delegados”.

En contraste, en la red Ardor todos los nodos validan las transacciones de las cadenas hijas, pero solo las cuentas que poseen ARDOR forjan. El hecho de que las cuentas con tokens de las cadenas hijas no los utilicen para forjar significa que no importa lo pequeñas que sean estas cadenas hijas o lo desigual que sea su distribución. Son tan seguras como la cadena madre.

Una nota adicional sobre Lisk es que, hasta el momento en que el “mercado de delegados” sea lanzado, los creadores de las cadenas laterales elijen los nodos que forjan en sus cadenas, lo que parece requerir que los usuarios depositen un buen grado de confianza en ellos. Por otra parte, el equipo ha sugerido que Lisk será suficiente flexible para permitir que las cadenas laterales utilicen un algoritmo de consenso totalmente distinto, como el de Prueba-de-Trabajo (Proof-of-Work), lo que parece indicar que los creadores de estas cadenas laterales no determinarán qué nodos mantendrán la seguridad la cadena.

También existen planes para permitir a las cadenas laterales existentes cambiar sus mecanismos de consenso, incluso después del lanzamiento, pero de nuevo no pude encontrar más detalles sobre esto.

Claramente, tanto Lisk como Ardor pretenden ofrecer ventajas de escalabilidad sobre las blockchains tradicionales. Con Lisk las ventajas computacionales para el escalado son obvias, ya que cada nodo forjador valida únicamente las transacciones en una cadena de bloques, ya sea la cadena principal o la lateral. Sin embargo, la reducción del espacio de almacenamiento requerido (crecimiento desmesurado de la blockchain) es menos claro. En comparación, por ejemplo, con Ethereum, es obvio que para un nivel de actividad total similar, las cadenas principales en el ecosistema de Lisk crecerán a un ritmo menor que la cadena única de Ethereum, sencillamente porque las cadenas laterales no almacenarán los datos de cada una de las otras.

Comparada con Ardor, los ahorros de almacenamiento serían muy reducidos. La cadena madre de Ardor crecerá a ritmos similares que la cadena principal de Lisk (ya que ambas almacenarán solamente los hashes de las cadenas laterales o de las cadenas hijas, respectivamente) en lugar de los datos en sí. Sin embargo, en Ardor se eliminarán los datos de las cadenas hijas, eliminando así el problema del crecimiento desmesurado de la Blockchain, un problema que Lisk tendrá en cada cadena lateral.

Conclusión

¿Entonces que debemos hacer con Lisk? Honestamente, estoy muy decepcionado al escribir esto, pero creo que es demasiado pronto para decirlo.T odavía existen muchos detalles que tienen que materializarse:

¿Será posible convertir el token de una cadena lateral directamente a otra cadena lateral sin convertirlo a/desde LSK? ¿Cómo?
Cuando el “mercado de delegados” abra, ¿será posible que los usuarios elijan a los delegados utilizando los tokens de la cadena lateral? ¿O tendrán que utilizar LSK? ¿O podrán los dueños de las cadenas laterales mantener el control sobre que delegados forjan?
¿Qué hará Lisk con los hashes de las cadenas laterales almacenados en la cadena principal? ¿Será posible revertir las transacciones recientes de una cadena lateral para “restaurar” el estado que tenían cuando se produjo el hash correspondiente? Si esto fuese así, ¿existirá algún periodo de tiempo después del cual no fuese posible revertir las transacciones, para que la cadena siguiese siendo considerada inmutable?
¿Proporcionará el SDK de Lisk un mecanismo claro para cambiar el algoritmo de consenso de una cadena lateral ya existente? No estoy muy seguro como sería esto.
¿Qué sucederá si la cadena lateral utilizase una bifurcación de LSK? Obviamente, los tokens LSK de cada cadena lateral resultante no podrán ser simultáneamente respaldados por las mismas reservas de LSK en la cadena principal. Asumo que el creador de la cadena lateral decidirá cuál es la cadena “real”, ya que mantiene las reservas en la cadena principal, pero no sé con seguridad si esta intrepretación es la correcta.
Dependiendo del modo en que Lisk soporte las transacciones directas entre las cadenas laterales, este problema podría requerir de confianza adicional entre los creadores de la sidechain. En particular, si los creadores de la sidechain deben mantener reservas de los tokens de cada una de las cadenas para permitir transacciones entre cadenas, lo cual parece una manera plausible de hacerlo, entonces un fork en una sidechain podría darle al creador de la otra sidechain cierta influencia sobre qué rama de la bifurcación es la válida. Además, si la cadena lateral del fork realiza transacciones con otras varias sidechain, cada una de las cuales tuviese reservas del token dividido, entonces la situación podría ponerse fea bastante rápidamente

En mi opinión, la ventaja más importante de Lisk sobre las otras plataformas de cadenas de bloques, incluyendo Ardor, es que podría alcanzar una escalabilidad computacional natural derivada de la separación de cada dapp en su propia cadena de bloques. Si sumamos que las cadenas laterales pudieran realizar transacciones entre ellas fácilmente y sin necesidad de requerir confianza en un tercero, podría tener un potencial inmenso.

Si asumimos que el equipo de Lisk implementa exitosamente todas las funciones para hacerlo posible, entonces debemos de otorgarle la misma cortesía a Jelurida y asumir que ellos llevaran a cabo también sus planes de escalabilidad. En particular, una mejora potencial en la hoja de ruta de Ardor es la de limitar el procesamiento de las transacciones de las child chains a subredes dedicadas en la red de Ardor. Parece que esto lograría una escalabilidad computacional similar a Lisk, preservando al mismo tiempo la ventaja substancial de reducir el crecimiento desmesurado de la cadena de bloques.

Concluyendo, la arquitectura de cadena principal / cadenas lateral de Lisk podría potencialmente ayudarlo a escalar para permitirle acomodar un gran número de dapps, las cuales podrían interactuar de formas interesantes. Pero, por ahora, parece haber mucha incertidumbre en los detalles técnicos. El planteamiento de Ardor es muy diferente técnicamente, pero resuelve los mismos problemas. Principalmente el crecimiento de tamaño desmesurado de la cadena de bloques, la escalabilidad del potencial computacional y la habilidad de lanzar transacciones fácilmente entre las diferentes cadenas.

Será interesante ver cómo se desarrolla Lisk en los próximos dos o tres años, pero para entonces Ardor ya habrá estado funcionando por un largo periodo.