¿En qué se diferencia Lisk de Ethereum?

Lisk será un marco de desarrollo de DApp de pila completa para crear y distribuir aplicaciones descentralizadas. Actualmente se encuentra en la etapa de financiación colectiva, pero también se agregó a la pila Blockchain-as-a-Service de Microsoft.

Anuncia que puede crear aplicaciones descentralizadas simplemente escribiendo Javascript. Pero dado que también puede crear JS-DApps para Ethereum, me pregunto, ¿cuál es la diferencia?

Esa es una buena pregunta y sería bueno tener una respuesta.

Respuestas (2)

Advertencia, no soy un gran admirador de Lisk. Obviamente, este es un lado de la historia y estoy seguro de que hay más ventajas de Lisk de las que les doy crédito. Pero no los conozco.


Una publicación de blog (no mía): Por qué Lisk es inferior a Ethereum

Puntos principales del autor con respecto a Lisk:

  • Lisk "sandbox" no se puede usar para ejecutar código que no es de confianza

  • Lisk framework no proporciona protecciones contra el comportamiento no determinista

  • Lisk no tiene la capacidad de evitar bucles infinitos y/o medir el cálculo total

  • Lisk no tiene la capacidad de prevenir el crecimiento ilimitado de la memoria y/o medir el consumo de memoria

  • Las características comunes del lenguaje JavaScript (como la iteración sobre claves en un objeto) dan como resultado un comportamiento no determinista oculto

Puntos principales del autor con respecto a ETH:

  • Ethereum protege a los desarrolladores de innumerables problemas que afectan a los desarrolladores de blockchain experimentados.

  • Aprender la sintaxis de un nuevo idioma es trivial en comparación con aprender a evitar las millones de formas en las que puedes pegarte un tiro en el pie.

  • Las aplicaciones de Ethereum no tienen posibilidad de generar un comportamiento no determinista.

  • No es necesario administrar el estado "deshacer" en Ethereum porque cualquier excepción lanzada automáticamente revierte todos los cambios (excepto la tarifa).

.


1. Lenguajes de programación

Lisk: Javascript vs Ethereum: go, C++, rust, Solidity, Serpent, etc.

lista

Una de las cosas que Lisk promocionó mucho antes de su preventa fue el hecho de que su Dapp está en Javascript, "el lenguaje más popular del mundo". De hecho, se comercializaron (a través de un anuncio de reddit )[1] como "La alternativa de Ethereum para desarrolladores de Javascript".

Todo su sistema es 100% javascript. Node.js para el backend. La interfaz. Tienen una base de datos: SQLlite, originalmente. Ahora postgresql.

Etéreo

Los contratos inteligentes para Ethereum están en Solidity o Serpent . Solidity es muy similar a Javascript, pero está hecho a medida para contratos inteligentes. Es extremadamente fácil leer estos contratos y entender lo que están haciendo. También hay algunas razones importantes para usar un lenguaje personalizado sobre Javascript (discutido a continuación) cuando se trata de contratos que mueven moneda, almacenan valor y necesitan llegar a un consenso. Esta página , aunque ya no se mantiene, tiene algunos puntos excelentes sobre lo que es Solidity, si desea obtener más información.

No sé mucho sobre Serpent, pero parece tener los mismos objetivos y propósitos que Solidity, pero está destinado a ser similar a Python (y, por lo tanto, es excelente para los desarrolladores de Python). Esto, junto con la gama de clientes, también muestra la dedicación que tiene Ethereum para atraer a una amplia gama de desarrolladores, no solo a los desarrolladores de Javascript.

Lo anterior solo cubre contratos inteligentes para Etheruem; ¿Qué pasa con el "Dapp" más completo? Bueno, es más o menos Javascript para la interfaz de usuario de Ethereum Dapp. Le recomiendo que lea el artículo de ConsenSys aquí, específicamente la Parte II. Básicamente, tienes:

  • Trufa (JS, Sass, ES6, JSX están integrados)

  • Embarque (que es JS)

  • Meteor (web3.js + meteoro (que también es JS))

  • y vienen más.

Conclusión

Entonces, que Lisk insinúe que los desarrolladores de Javascript no pueden crear Dapp para Ethereum es un poco engañoso. Absolutamente pueden usar principalmente Javascript para Dapp y luego Solidity (que está muy cerca de Javascript) para contratos inteligentes. La publicación del blog a la que se hace referencia anteriormente dice de manera sucinta:

Aprender la sintaxis de un nuevo idioma es trivial en comparación con aprender a evitar las millones de formas en las que puedes pegarte un tiro en el pie.

La diferencia es que Lisk es completamente Javascript (y node.js) de principio a fin, Ethereum tiene una gran cantidad de clientes en diferentes idiomas[2], tiene dos idiomas personalizados para contratos inteligentes y aún permite Javascript donde lo necesite. la mayoría (la interfaz de usuario).

2. Desventajas de Javascript

Lo que algunas personas no se dan cuenta es que Javascript, si bien es extremadamente popular, no lo convierte automáticamente en la mejor solución. Como dije anteriormente, la diferencia entre Ethereum y Lisk aquí es que Lisk es 100% Javascript, mientras que Ethereum tiene una tonelada de idiomas y permite que los desarrolladores de Dapp usen Javascript para la interfaz de usuario y Solidity para contratos inteligentes en la cadena de bloques. Con eso, aquí hay algunas fallas potenciales con Javascript en la cadena de bloques:

  • Los números de Javascript son.... no los mejores ni los más fiables. Además, cuando se trata de una moneda criptográfica, realmente desea que sus números estén en el punto. Básicamente, JS usa punto flotante, lo que significa que algunas cosas se aproximan y los dígitos se pierden en ciertos casos. Incluso cosas pequeñas como números de coma flotante pueden romper el consenso. Aquí hay algunas lecturas adicionales: Tenga cuidado con los números grandes y la aproximación de punto flotante . Entonces, el hecho de que todo en Lisk (incluido el propio Lisk) esté en Javascript, significa que potencialmente hay grandes problemas numéricos (tanto en términos de grandes números como de grandes problemas).

  • Lisk tiene "reglas" que piden a los desarrolladores de contratos que deben seguir para evitar romper el consenso. Esto incluye cosas como "no usar Math.random()". Con Ethereum, no tienes que tener reglas. El código no se compilará si intenta hacer algo mal. (Para tu información, no compilas Javascript). En Lisk, si usas Math.random(), se rompe.

  • Javascript utiliza escritura dinámica débil. Si no tiene cuidado, puede pasar cadenas en lugar de números. Una de las principales diferencias entre Solidity, Serpent y Javascript es que tanto Solidity como Serpent están fuertemente tipados. Wikipedia sobre fuerte vs débil lo explica así:

Es más probable que un lenguaje fuertemente tipado genere un error o se niegue a compilar si el argumento pasado a una función no coincide con el tipo esperado. Por otro lado, un lenguaje muy débilmente tipificado puede producir resultados impredecibles o puede realizar una conversión de tipo implícita.

Dado que Ethereum está ejecutando contratos en la cadena de bloques y Lisk está ejecutando Dapp en la cadena de bloques (¿cadena lateral?), podría ver por qué tener un lenguaje escrito débilmente podría generar problemas, específicamente con respecto al consenso. Es mucho mejor conocer el problema antes de que se convierta en algo inmutable en la cadena, en lugar de descubrir que todos los fondos están atrapados o que se bifurca la cadena de bloques la primera vez que alguien intenta interactuar con ella.

Las fallas adicionales de Lisk incluyen el hecho de que su "caja de arena" no se puede usar para ejecutar código no confiable y su marco no brinda protección contra el comportamiento no determinista. De la publicación de blog anterior:

Las caras de Lisk se pueden resolver con un entorno de JavaScript altamente personalizado que elimina el punto flotante, implementa interrupciones de software, cuenta de instrucciones y API más limpias para administrar el estado de la aplicación. En última instancia, crear un compilador de JavaScript para Ethereum VM podría ser menos propenso a errores que tratar de reparar un millón de fugas no deterministas en JavaScript.

2b. Desventajas de la solidez

Como señaló el usuario Jehan, Solidity tampoco es perfecto.

  • Hay poco soporte para serialización y deserialización de cualquier tipo.

  • Tiene una stdlib extremadamente anémica (ha sido actualizada significativamente recientemente)

  • No hay forma de pasar una serie de cadenas a un contrato.

3. En la cadena de bloques

En Lisk, las Dapps en realidad no se almacenan en la cadena de bloques , como el código de bytes del contrato inteligente en Ethereum. En cambio, tiene enlaces externos a estos Dapp. Les gusta comparar su Dapp con el modelo tradicional de "App Store" (piense en Apple). Lo cual, si bien es atractivo para algunos usuarios, es menos atractivo cuando te das cuenta de que literalmente están usando HTTP: enlaces a archivos .zip.

Con Ethereum, tiene el código almacenado en la cadena de bloques , lo que significa que se pueden auditar y el código no se puede cambiar. Es una especie de todo el propósito de tener aplicaciones descentralizadas (IMO).

Lisk prefiere usar una definición más amplia de "descentralizado", que significa literalmente no almacenado en un lugar central, mientras que los desarrolladores y usuarios de Ethereum prefieren que descentralizado signifique algo que no se puede corromper, auditar, cambiar, llegar a un consenso, etc. [3]

4. Quién es/era Lisk

Uno de los argumentos más comunes de los amantes de Ethereum contra Lisk es que Lisk (1) no tiene un equipo de desarrolladores detrás y (2) se originó como una moneda alternativa fallida, Crypti que fue abandonada por los desarrolladores (3) esos los desarrolladores que abandonaron Crypti son los desarrolladores de Lisk, así que (4) ¿es solo un cambio de marca?

La principal diferencia que veo entre Ethereum y Lisk aquí es que Lisk son dos tipos que cambiaron el nombre de una moneda anterior que tenía una preventa y no entregaron nada, mientras que Ethereum tiene a Vitalik Buterin, un gran equipo de talentos locos conocidos, comprometidos con la comunidad. desarrolladores y una gran comunidad de desarrolladores que trabajan en el código central (todo es de código abierto), Dapps y billeteras de terceros, etc.

Otra diferencia clave es que Ethereum tiene la Fundación Ethereum, una organización suiza sin fines de lucro y Lisk tiene... una fundación/compañía desconocida asociada con ella.


[1] Aquí también hay una captura de pantalla porque ese enlace es raro.

[2] Ethereum es alucinante con la cantidad de idiomas/clientes. En este punto tenemos: Geth (Go), WebThree (C++), PyEthereum (Python), Parity (Rust), EthereumJ (Java), Ethereum-Ruby (Ruby), NEthereum (.net). Veo esto como una gran ventaja para Ethereum y, como ha señalado el equipo de Ethereum, el hecho de que haya tantos clientes en tantos idiomas ha sido invaluable para las pruebas, el descubrimiento de errores y garantizar el consenso.

[3] Más información de un hilo enojado.

Muchos puntos muy buenos, pero me gustaría decir que Solidity tiene muchos problemas, como es de esperar de un lenguaje joven. Hay poco soporte para serialización y deserialización de cualquier tipo, tiene un stdlib extremadamente anémico y faltan características básicas, como poder pasar una serie de cadenas a un contrato. No creo que sea irrazonable que los desarrolladores quieran algo más flexible para ciertos casos de uso.
Gracias por la respuesta @Jehan. No estoy tan familiarizado con Solidity como debería, y basé la mayoría de mis puntos en lo que he leído en la documentación y otros comentarios. He agregado sus puntos a mi publicación inicial, pero me encantaría que fueran más completos. ¿Ya tienes capacidades de edición? ¿O estaría dispuesto a armar un pastebin con más detalles/fuentes? ¡Gracias!
Honestamente, creo que muchas de estas cosas se arreglarán con el tiempo. No creo que Solidity sea malo, pero tampoco creo que duela que la gente experimente con cadenas de bloques programables que no tienen sus propios lenguajes de programación integrados.
La diferencia en la ejecución del contrato no se explica, pero podría ser importante. #4 debe eliminarse o reescribirse para que no parezca ad hominem.
@Come-from-Beyond #4 no hay que quitarlo pero sí explicarlo mejor, porque sí: el equipo lo es todo.
Muchos de sus puntos se basan simplemente en la creación de un compilador. El compilador Solidity compila en un pequeño conjunto de instrucciones (forma Ethereum de eliminar el comportamiento no determinista) ¿Elimina todo el comportamiento no determinista? De todos modos, el compilador como solidity se puede escribir en <2 meses :) :)

@tayvano: Desafortunadamente, no puedo comentar directamente. Necesito "50 reputación" para esto. Por lo tanto, lo escribiré como una nueva respuesta.

No sé mucho sobre Serpent, pero parece tener los mismos objetivos y propósitos que Solidity, pero está destinado a ser similar a Python (y, por lo tanto, es excelente para los desarrolladores de Python). Esto, junto con la gama de clientes, también muestra la dedicación que tiene Ethereum para atraer a una amplia gama de desarrolladores, no solo a los desarrolladores de Javascript.

La gama de clientes de Ethereum en Go, C++, Python, JavaScript, Java y otros lenguajes es un desastre de soporte. En este momento puede funcionar bien, pero una vez que Ethereum atraiga una masa crítica, habrá 1 (o tal vez 2) clientes que serán utilizados por el 99% de los usuarios. De lo contrario, simplemente no es factible.

También dice que Ethereum está tratando de atraer a una amplia gama de desarrolladores. Lisk tiende a centrarse en el grupo de JavaScript, es solo un hecho que esta ya es una gran multitud. Lisk elimina la fricción , es muy difícil conseguir desarrolladores para una plataforma. Si ahora necesitan aprender un nuevo idioma (además de todos los conceptos de blockchain), atraerlos será aún más difícil. Lisk se trata de mantenerse ágil, eficiente y enfocado.

Por cierto. JS es extremadamente poderoso: asmjs.org, pyjs.org, etc.

Lo anterior solo cubre contratos inteligentes para Etheruem; ¿Qué pasa con el "Dapp" más completo?

Aquí está la diferencia entre Lisk y Ethereum. Ethereum está haciendo contratos inteligentes que se guardan en una cadena de bloques. Si desea desarrollar una dapp en Ethereum, debe conectar las funcionalidades de varios contratos inteligentes.

En Lisk obtienes un paquete completo. No desarrolla contratos inteligentes individuales. Usted crea una aplicación completa que se ejecuta en su propia cadena de bloques. Es como si desarrollara una nueva plataforma de criptomonedas con un conjunto de funciones ampliado, la plataforma en sí ya está terminada y proporcionada por nuestro Lisk SDK. Como desarrollador, solo necesita implementar las nuevas funciones necesarias además de la plataforma ya existente.

Entonces, que Lisk insinúe que los desarrolladores de Javascript no pueden crear Dapp para Ethereum es un poco engañoso. Absolutamente pueden usar principalmente Javascript para Dapp y luego Solidity (que está muy cerca de Javascript) para contratos inteligentes.

Nunca dijimos que los desarrolladores de JavaScript no pueden crear dapps para Ethereum. Por supuesto que pueden, pero primero necesitan aprender un nuevo idioma. Esto es como dirías que un plomero no puede pintar paredes.

En Ethereum, pueden usar JavaScript para el front-end de dapp y Solidity para el back-end de dapp. No es como si estuvieran usando JavaScript "para el dapp [completo]" como dijiste. No, solo para la parte delantera.

La diferencia es que Lisk es completamente Javascript (y node.js) de principio a fin, Ethereum tiene una gran cantidad de clientes en diferentes idiomas[2], tiene dos idiomas personalizados para contratos inteligentes y aún permite Javascript donde lo necesite. la mayoría (la interfaz de usuario).

Sí, tendemos a centrarnos en una tecnología. El enfoque es clave.

Su declaración de que Ethereum "permite JavaScript donde más lo necesita (la interfaz de usuario)", es realmente solo el caso de Ethereum. JavaScript se acepta globalmente para muchas tareas diferentes en el front-end y back-end (por ejemplo, NodeJS). No solo para "la interfaz de usuario". Está haciendo que JavaScript sea más pequeño, solo para obtener más argumentos para Solidity.

Los números de Javascript son.... no los mejores ni los más confiables. Especialmente cuando se trata de una moneda criptográfica, realmente desea que sus números estén en el punto. Básicamente, JS usa punto flotante, lo que significa que algunas cosas se aproximan y los dígitos se pierden en ciertos casos.

Solo estamos usando números enteros en Lisk. Para números grandes estamos usando bignumber.js. No se trata del idioma que elijas, se trata de tus habilidades de codificación. Si sabes lo que estás haciendo, JavaScript está completamente bien. Sin embargo, sí, esto es una debilidad. Pero una debilidad que es manejable.

Javascript utiliza escritura dinámica débil. Si no tiene cuidado, puede pasar cadenas en lugar de números.

Honestamente, si está construyendo un proyecto serio, al menos debería hacerlo bien. De lo contrario, todos los proyectos de JavaScript fallarían según su argumento.

Lisk tiene "reglas" que piden a los desarrolladores de contratos que deben seguir para evitar romper el consenso.

Sí. Parece que Ethereum tiene estas "reglas" directamente integradas en su compilador, en Lisk los desarrolladores solo tienen que seguirlas. La mayor diferencia aquí es que, si cometen un error y se rompe el consenso, entonces el dapp necesita una bifurcación dura. Pero Lisk en sí está completamente bien, porque el dapp solo se ejecuta en una cadena lateral.

Esta es una gran ventaja de seguridad. Si una dapp falla, la red Lisk ni siquiera tiene hipo. Sin embargo, si un contrato inteligente falla en Ethereum, puede significar el fin del juego para Ethereum.

Desventajas de la solidez

Otras desventajas pueden ser que es un lenguaje muy joven y por lo tanto no probado. Además, hay muy poca documentación disponible, y aún menos desarrolladores conocen este lenguaje.

en la cadena de bloques

Estás mezclando diferentes cosas ahora. Descarga el cliente Bitcoin también desde un enlace HTTP. Sin embargo, "no se puede corromper, se puede auditar, no se puede cambiar, se puede llegar a un consenso". Eso significa que todas estas propiedades importantes que menciona también son válidas para Lisk. Si cambia un código dapp, su nodo terminará en una bifurcación. Lo mismo que si cambias el código de Bitcoin.

El enlace HTTP es solo la forma de distribuir un código fuente de dapp. Más adelante integraremos métodos de almacenamiento descentralizados (por ejemplo, IPFS), de modo que la distribución en sí también pueda descentralizarse.

Sin embargo, el modelo de distribución no define si una aplicación es centralizada o descentralizada. ¿O dices que todas las criptomonedas del mercado están centralizadas? ¿Porque descarga los clientes desde una ubicación centralizada? En caso afirmativo, ¿cómo se pueden descentralizar las dapps de Ethereum si la red misma está centralizada? ;)

Su línea de argumentos es incorrecta aquí. Otro hecho importante es que este método le permite a Lisk escalar masivamente más fácilmente que Ethereum. Además de las enormes ventajas que nuestras cadenas laterales ya aportan.

No sé mucho sobre Crypti, pero tuvieron una preventa y obtuvieron una cantidad decente de dinero (al menos $ 200k USD), pero no puedo encontrar las cifras exactas porque todo se ha borrado. Nada salió de Crypti. Literalmente. Entonces... eso da miedo. La falta de transparencia, también da miedo.

Ya no estamos asociados con Crypti. Sin embargo, decir que todo está borrado y que no hay transparencia es una gran mentira. Hay más de 600 páginas en Bitcointalk ( https://bitcointalk.org/index.php?topic=654463 ) y docenas de publicaciones de blog ( https://blog.crypti.me ) que contienen TODA la información.

Además, si dices que "no salió nada de Crypti", entonces estás completamente equivocado. Crypti desarrolló una plataforma dapp funcional, el gran éxito de Lisk lo demuestra. Lo único que simplemente no funcionó en Crypti fue el marketing. Eso significa que nadie sabe sobre Crypti. También hubo una gran falta de liderazgo en Crypti.

Entonces, supongo que la principal diferencia que quiero señalar entre Ethereum y Lisk aquí es que Lisk son dos tipos que cambiaron el nombre de una moneda anterior que tenía una preventa y no entregaron nada, mientras que Ethereum tiene Vitalik Buterin, un gran equipo de comunidad bien conocida. desarrolladores talentosos y comprometidos, y una gran comunidad de desarrolladores que crean Dapp y billeteras de terceros y billeteras de hardware y todo tipo de cosas increíbles. Quiero decir, mira solo a Augur, Slock.it y ConsenSys. ¡Es una locura!

Sí, me alegro de que esos dos chicos de Google nunca hayan fundado su empresa porque había tantos motores de búsqueda geniales en ese entonces con cientos de empleados. :)

No me malinterpreten, me gusta Ethereum y todo el equipo/movimiento detrás de él. Soy un gran partidario. Pero simplemente estás rechazando la innovación en este momento. Estás comparando una plataforma de 2 años (Ethereum) con 18 millones en fondos, con una plataforma que ni siquiera se lanzó (Lisk) sin acceso a los fondos hasta el momento. Eso es un poco tonto.

Otra diferencia clave es que Ethereum tiene la Fundación Ethereum, una organización suiza sin fines de lucro y Lisk tiene... una fundación/compañía desconocida asociada con ella.

Todos en Lisk saben que estamos en proceso de crear una entidad legal en Alemania, muy probablemente como gGmbH. Esta es también una estructura de organización sin fines de lucro.

Una nota final: a Lisk realmente le gusta afirmar que tienen asociaciones con grandes nombres. Primero fue ShapeShift. Ahora es Microsoft. Les encanta usar esa palabra de asociación. En realidad, solo estaban usando el botón Shifty, no realmente una asociación.

Tuvimos una asociación tecnológica con ShapeShift. Fue un gran malentendido en ese momento. Ya arreglaron ese error.


Considerándolo todo, me gustaría decir que sus puntos son bastante débiles. No señalaste las mayores debilidades de Lisk. En mi opinión, esto es seguridad de cadena lateral. Eso significa que los dapps pequeños probablemente no tendrán la oportunidad a largo plazo de atraer suficientes nodos para asegurarlos.

Para esto, sospecho que habrá dapps especiales, que ejecutarán dapps más pequeñas de forma SaaS. Hasta que implementamos un mercado de falsificación de cadenas laterales, encontrar falsificadores de cadenas laterales también era una tarea bastante difícil. Sin embargo, todos estos son solo problemas iniciales. Todo es solucionable. Al final del día, Lisk es solo un software que se desarrolla activamente.

Es importante mencionar que Lisk acaba de empezar y ya estamos haciendo grandes cambios. En este momento, es demasiado pronto para evaluar a Lisk y al equipo (nosotros) detrás de él. Solo debe esperar un año antes de llegar a una conclusión final. Todos los argumentos en este momento solo parecen que tienes miedo. Personalmente, creo que hay espacio mucho más que suficiente para Ethereum y Lisk. Al final estamos resolviendo los "problemas" de manera muy diferente y estamos atrayendo nichos diferentes.

Espero que Ethereum y Lisk puedan trabajar juntos en el futuro para resolver problemas importantes dentro de la industria de dapp y blockchain. Lo repito, estamos juntos en este "juego".

Hola y bienvenido a Ethereum Stack Exchange. Gracias por proporcionar información adicional a la respuesta de tayvanos.
Parece que puedo comentar en mi propia publicación sin necesidad de "reputación". Gracias por la cálida bienvenida 5chdn. Gracias por hacer preguntas importantes sobre Lisk. :)
@MaxKK Agregue un descargo de responsabilidad que diga que es el director ejecutivo de Lisk.
"Esta es una gran ventaja de seguridad. Si falla una dapp, la red Lisk ni siquiera tiene hipo. Sin embargo, si falla un contrato inteligente en Ethereum, puede significar el fin del juego para Ethereum". -- Esto es extremadamente incorrecto. Si falla un contrato inteligente en Ethereum, el contrato se rompe. Etherem en sí está bien. Si Lisk realmente mejora esto, ¿puede explicar cómo?
@MaxKK ¡Todo lo que dijiste suena genial! Pero mi opinión personal (depende de usted si desea considerarlo o no) es que su equipo necesita algunos nombres importantes (personas con una gran formación académica), doctorados y documentos y, por supuesto, ingenieros de software sólidos que puedan implementar esas ideas. Son importantes para pasar al siguiente nivel. A LISK le está yendo bien financieramente, ¿por qué no contratarlos? Si soy el CEO de una empresa, no me guiaré simplemente por lo que mi CTO tiene que decir; de hecho, creo que la mayoría de los CTO son incompetentes. ¡Siempre hay que contratar a alguien más inteligente que tú! ¡¡y simplemente no te quedes ciego con Oliver!!