NXTER.ORG

Ardor Frente a la Competencia, Parte 2: NEM/Mijin/Catapult

Este artículo forma parte de una serie que pretende comparar Ardor con otros proyectos blockchain con características u objetivos similares. A continuación puedes encontrar las entradas anteriores:

Esta semana he analizado NEM, una blockchain similar a Nxt en muchos aspectos. Puesto que estoy principalmente interesado en cómo resuelve cada blockchain el problema del escalado, también he investigado acerca de Mijin, una versión de NEM para blockchains privadas y Catapult, una re-reescritura de Mijin que promete grandes mejoras de rendimiento que también serán incorporadas a los futuros lanzamientos de NEM.

NEM

Aunque los desarrolladores centrales de NEM abandonaron su idea original de lanzar NEM como un fork de Nxt, optando por empezar el proyecto desde cero, NEM y Nxt continúan siendo bastante similares. Al igual que sucede en Nxt, la plataforma NEM ofrece una serie predefinida de transacciones permitidas que las aplicaciones pueden usar como elementos base de construcción con los que crear características más complejas, en oposición al uso de scripts de lenguaje de bajo nivel para la construcción de transacciones, como sucede con Bitcoin o Ethereum.

Ambas plataformas soportan un puñado de características de “blockchain 2.0″, como pueden ser el envío de mensajes, la creación y transferencia de activos o el envío de transacciones que requieren de la aprobación por múltiples cuentas (multifirma). Y ambas plataformas ofrecen funcionalidad a través de APIs basadas en HTTP, así que los desarrolladores pueden usar virtualmente cualquier lenguaje para escribir sus aplicaciones.

A pesar de las semejanzas, NEM también tiene algunas diferencias notables con Nxt.

Quizá la más fundamental es su novedoso algoritmo de consenso, llamado Prueba de Importancia (Proof-of-Importance). Este algoritmo es similar al de Prueba de Participación (Proof-of-Stake), excepto en que la probabilidad de que una cuenta recolecte (es decir, forje) el siguiente bloque depende no solo de su saldo de XEM, la moneda nativa en NEM, sino que también depende de hace cuánto que ha realizado transacciones con otras cuentas y cuánto XEM se intercambió en ellas. Las cuentas que tienen mucho saldo de XEM y que realizan transacciones con un gran volumen frecuentemente recolectarán más bloques que las cuentas con menos XEM o aquellas cuentas que realicen pocas transacciones.

Los autores del manual de Referencia Técnica de NEM defienden que, al compararse con la prueba de participación, el algoritmo de prueba de importancia de alguna manera ofrece menos peso a las cuentas más acaudaladas a la hora de elegir el derecho a forjar/recolectar el siguiente bloque (Sección 7.8). La prueba de importancia también es vital para el filtro de spam de NEM, puesto que requiere que un atacante no solo controle muchas cuentas, lo cual es sencillo de hacer, pudiendo spamear la red con un gran número de transacciones sin confirmar, sino que también exige disponer de un considerable saldo en cada cuenta y realizar transacciones frecuentemente con otras cuentas también de gran importancia.

Desde mi punto de vista, otra gran diferencia entre NEM y Nxt es el punto hasta que las características de “blockchain 2.0″ están directamente integradas en la API. Por ejemplo, los activos (assets) en NEM, llamados “mosaicos”, comparten varias de las características de las monedas del Sistema Monetario de Nxt, pero NEM no tiene integrado un exchange descentralizado para los mosaicos. (Como apunte, la Fundación NEM ha encargado a Blockchain Global la creación de una exchange centralizado tradicional para ofrecer tokens para ICO basados en mosaicos). Del mismo modo, mientras que se podría crear un mercados descentralizado sobre NEM dónde los usuarios podrían comprar y vender bienes y servicios, NEM no tiene este tipo de mercado integrado en su API del modo que Nxt lo tiene.

Finalmente, una diferencia sutil pero muy importante entre NEM y la mayoría de otras blockchains, incluyendo la de Nxt, es la manera en que maneja las transacciones multifirma. En lugar de permitir a cualquier cuenta generar transacciones multifirma, NEM presenta el concepto de cuenta multifirma y exige que todas las transacciones multifirma se originen desde esas cuentas. Cualquier cosignatario de la cuenta puede iniciar una transacción desde ella y la transacción solo se ejecutará si un número suficiente del resto de cosignatarios la aprueban.

En un principio, esto podría parecer una limitación, puesto que requiere una cuenta multifirma separada para juego de cosignatarios con los que un usuario quiere firmar pero tiene dos ventajas clave: la cuenta multifirma es una cuenta completa, capaz de recibir pagos, mensajes y mosaicos, por ejemplo. Además, se pueden añadir o eliminar cosignatarios, así que la custodia de la multifirma se puede transferir. Es posible crear una cuenta multifirma “1 de 1”, es decir, una cuenta con un solo guardián que puede transferir la custodia a otro guardián, si así lo desea. De esta forma, las cuentas multifirma en NEM pueden actuar como contenedores transferibles para XEM, mosaicos y mensajes.

Una aplicación particular a destacar de este concepto es el servicio de notario integrado en NEM llamado Apostille. Con Apostille, el proceso de autenticación de un documento es el siguiente:

  1. Establecer el hash y firmar el nombre del documento.
  2. Crear una cuenta multifirma para el documento derivada de la firma resultante
  3. Establecer el hash y firmar el contenido del documento.
  4. Enviar un mensaje con el resultado a la cuenta mutilfirma del documento.

Hay que darse cuenta de el último paso también añade una marca de tiempo (timestamp) al documento, puesto que la transacción que transfiere el hash firmado del documento a la cuenta multifirma queda almacenada en la blockchain.

Como muestra de una posible aplicación de Apostille, los autores del white paper exponen un caso dónde el documento autenticado sería el de la propiedad de un vehículo. La propiedad del vehículo se puede transferir cambiando los cosignatarios en la cuenta multifirma que contiene la propiedad. Se pueden enviar mensajes describiendo trabajos de mantenimiento y reparaciones para almacenar el registro de servicio del vehículo. Mosaicos emitidos por gobiernos o aseguradoras podrían atestiguar el pago de tasas. En este sentido, la cuenta multifirma representa tanto al vehículo como el historial de todas las cuentas que han interaccionado con él.

De todas formas, ya es suficiente sobre NEM. Pasemos a Mijin.

Mijin

A grandes rasgos, Mijin es una versión de NEM que tres de los desarrolladores del núcleo de NEM y una compañía llamada Tech Bureau desarrollaron como una blockchain privada y permisionada. Como cualquier otra blockchain privada (y en contraste con NEM, que es público), una blockchain de Mijin es propiedad de una autoridad central (por ejemplo una compañía) y está controlada por una ella.

Este no es el lugar adecuado para entrar en discusiones sobre la utilidad de las blockchains privadas, pero puesto que tanto Mijin como Cataplut son partes importantes del ecosistema de NEM, permitidme la licencia. En mi opinión, cuanto más “privada” se hace una blockchain privada, menos útil resulta. Aunque puedo pensar en un caso de uso para las blockchains “de consorcios”, dónde un puñado de organizaciones independientes, que no confían necesariamente las unas en las otras, cooperan para asegurar la red frente a abusos por parte de cualquier otro miembro del grupo, tengo problemas para ver el valor de una blockchain controlada por una única autoridad. Desde mi punto de vista, una blockchain sin un consenso que dependa de la no-confianza es básicamente una base de datos extremadamente ineficiente y lenta.

Sin embargo, se que hay mucha gente que no está de acuerdo conmigo, por lo que para lo que resta de artículo voy a asumir que las blockchains privadas tienen valor y existe un mercado para ellas, especialmente en los servicios financieros, los cuales parecen ser la principal industria a la que Tech Bureau pretende dar servicio utilizando Mijin.

No hay tanta información disponible en internet sobre Mijin como la hay sobre NEM, pero he descubierto algunos hechos interesantes que dan pistas sobre su potencial. Por un lado, aunque Mijin y NEM son proyectos completamente, Mijin usa la misma API que NEM (o, como mínimo, ambas ambas APIs presentan muchos aspectos comunes), lo que sugiere que sería relativamente sencillo para los desarrolladores escribir aplicaciones que funcionasen en cualquiera de las dos plataformas. Con una API común también se facilita la interacción entre las cadenas Mijin y la cadena pública de NEM, pero no he encontrado más información sobre los detalles de esta interacción.

Además, la web de Mijin afirma que Mijin soportará contratos inteligentes, aunque el white paper de Catapult parece contradecir esta afirmación cuando dice: “el enfoque aquí es hacer de los contratos inteligentes un componente externo, bien sea centralizado (es decir, tal y como se encuentra hoy en día los sistemas actuales) o descentralizado. Los resultados de estos contratos inteligentes introducirán su transacción en el libro de contabilidad a través de un proceso seguro”. Yo interpreto que los contratos en si mismo nunca serán almacenados en la blockchain ni serían ejecutados por todos los nodos de la red.

Y hablando de Catapult…

Catapult

Catapult es una reescritura de Mijin con la intención de incrementar el ratio de confirmación de las transacciones. A partir del white paper (enlazado más arriba), los primeros despliegues de Catapult serán a bancos y otras instituciones financieras, dónde el autor prevé que reemplazará a los entramados de “sistemas monolíticos inconexos”, que afirma se usan habitualmente hoy en día. A la larga, los desarrolladores también están planeando integrar Cataplut en NEM para facilitar el escalado de la blockchain pública.

Al igual que Mijin, Catapult es de código cerrado en estos momentos y no se han publicado muchos detalles técnicos. Sin embargo, fui capaz de encontrar información interesante rebuscando por el blog de NEM, especialmente en este hilo de uno de los desarrolladores.

Catapult divide el trabajo que la red hace entre tres tipos de nodos:

  • Nodos P2P, que añaden nuevos bloques a la blockchain y mantienen el consenso sobre su estado
  • Nodos REST, que muestran las aplicaciones de cliente con todas las características clave que pueden usar de la API de Catapult
  • Nodos API, que como los nodos P2P, almacenan la blockchain y pueden leer directamente de ella (creo), pero que no añaden bloques a la misma. Estos nodos sirven datos a los nodos REST para cumplir las solicitudes de las aplicaciones del cliente

Este despiece aparenta estar en consonancia con la arquitectura de tres niveles usada habitualmente para las aplicaciones web, dónde la blockchain (nodos P2P) son la base datos, los nodos REST son el front-end y los nodos API manejan la lógica de negocios de interpretar e interactuar con los datos de la base de datos.

Si esta analogía es correcta, entonces presumiblemente el objetivo de estar arquitectura es el de permitir a cada nivel escalar independientemente. Especialmente para una blockchain privada, el número óptimo de nodos P2P usados para establecer un consenso puede ser mucho más pequeño el que número de nodos REST y API requeridos para manejar todas las solicitudes que las aplicaciones envían a la red. El delegar estas responsabilidades a nodos separados de la red debería permitir que los nodos de cada tipo fuesen añadidos o eliminados según fuese necesario, para optimizar el rendimiento.

Aparte de esta nueva arquitectura, Catapult también realiza algunas optimizaciones para mejorar el rendimiento. Mientras que Mijin y NEM están reescritos en Java y usan HTTP para la comunicación con los nodos completos, Catapult está escrito en C++ y la comunicación al menos entre los nodos API y los nodos REST utiliza sockets full-duplex (a a través de ZeroMQ), permitiendo potencialmente una latencia inferior que el HTTP.

Un test de rendimiento de tres nodos Catapult situados en el mismo centro de datos y configurados para aceptar solicitudes de servicio provenientes de 10,8 millones de cuentas mostró que la red era capaz de un poco más de 3.000 transacciones por segundos. No queda completamente claro en la nota de prensa, pero parece como si cada uno de los tres nodos de este test jugasen todos los roles: P2P, API y REST. Para confundir todavía más las cosas, el diagrama que lo acompaña se refiere a los nodos API como “servidores de consumo de datos blockchain” y a los nodos RES como servidores de la “puerta API”

Comparado con Ardor

Entonces ¿Cómo se compara NEM con Ardor?

Realmente, existen dos preguntas diferentes a formular, como mínimo: ¿cómo se comparan las características de NEM con las de Ardor? y ¿Cómo se enfrenta al tema de escalado NEM comparado con cómo lo hace Ardor?

Puesto que Ardor (la plataforma, no la cadena madre) permitirá usar todas las características actuales de Nxt, las comparaciones que he hecho más arriba entre NEM y Nxt aplican de igual modo a Ardor.

En particular, las child chains de Ardor tendrán a su disposición una gran variedad de tipos de transacciones integradas que admitirán un rico juego de características.

Por ejemplo, NEM no soporta de modo nativa un exchange peer-to-peer para los mosaicos, el pago de dividendos a los depositarios de mosaicos, transacciones condicionadas a la emisión de votos por parte de los depositarios de mosaicos (o la mayoría de los tipos de transacciones por fases de Nxt, por el mismo motivo), propiedades de cuenta, mercado descentralizado o nada que se parezca al shuffling o al sistema de alias integrado en Nxt.

La arquitectura de cadena madre / cadenas hijas añadirá también otras funciones extra.

En particular, los usuarios serán capaces de intercambiar diferentes tokens de child chains entre ellos directamente, sin tener que convertirlos previamente a ARDR. Esto será especialmente útil en el caso de las child chains ligadas a otros valores, dónde los usuarios podrán tradear con monedas ligadas al dólar directamente por monedas ligadas al bitcoin (por ejemplo), mientras que en NEM alguien que posea un mosaico ligado al dolar tendrá que venderlo por XEM para luego poder comprar un mosaico ligado al bitcoin.

A pesar de estas diferencias, NEM todavía ofrece un rico juego de características que los desarrolladores de aplicaciones pueden usar de maneras muy interesantes. Quizá el mejor ejemplo sea el uso creativo que hace Apostille de las características únicas multifirma de NEM. No estoy seguro de cómo sería replicar este tipo de funcionalidad en Ardor.

[EDITADO]: Lior Yaffe, desarrollador central y cofundador de Jelurida, nos hace llegar el siguiente comentario:

Con NXT esto se puede realizar usando los activos singleton para cada registro de licencias y enviándolo entre cuentas.

Sobre el tema de cómo escalar, las diferencias son más destacadas.

En enfoque de Catapult, el cual NEM incorporará a largo plazo, consta de dos partes: una nueva arquitectura de tres niveles para distribuir las responsabilidades de la red entre tres nodos especializados; y una serie de optimizaciones a nivel de aplicación, por ejemplo el uso de C++ en lugar de Java. Tendremos que posponer nuestro veredicto hasta más adelante, cuando se hayan publicado resultados con los test de rendimiento, pero con la debida precaución todavía podemos lanzar unas especulaciones sobre las implicaciones de la nueva arquitectura.

La mayor ventaja parece ser para las blockchains privadas, dónde el usuario puede afinar las cantidades de los nodos de cada uno de los tres tipos. Además, en ese contexto, el crecimiento desmesurado de la blockchain no es un problema severo como lo es para las blockchains públicas puesto que las compañías pueden fácilmente destinar terabytes de almacenamiento en sus servidores para almacenar la blockchain.

La mejora del rendimiento de NEM con la nueva arquitectura, por otro lado, es más difícil de predecir. No está claro si cada par de la red tendrá que ejecutar los tres servicios (P2P, API, REST) o solo uno de los tres. En el primer caso, la ventaja para escalar de esta nueva arquitectura se perderá. En el segundo caso, el clásico equilibrio entre velocidad (menores nodos P2P, más nodos API y REST) y seguridad (mayor proporción de nodos P2P) se mantendría. Y puesto que nadie podría controlar el número de nodos de cada tipo en un red pública, la pregunta es que balance óptimo se debería buscar.

Por su lado, el diseño de Ardor intenta no obtener el máximo rendimiento, al menos inicialmente. En su lugar, el objetivo de escalado de Ardor busca reducir el tamaño y la tasa de crecimiento de la blockchain. Para ello utiliza una arquitectura única de cadena madre / cadenas hijas, dónde todos los nodos de la red validan todas las transacciones, pero sólo  aquellos que pertenecen a cuentas que poseen la moneda de la cadena madre (ARDR) pueden forjar. Puesto que las monedas de las child chains no pueden forjar, el historia de transacciones de las child chains es irrelevante para la seguridad de la red, y puede podarse.

No obstante, vale la pena recordar que el escalado computacional está en la hoja de ruta de Ardor.

Concretamente, es posible que el procesado de las transacciones de las child chains sea delegado a diferentes subredes de la red Ardor en un futuro, permitiendo que la mayoría de nodos ignoren la mayoría de transacciones.

Conclusión

Tanto Ardor como NEM ofrecen un juego de características interesantes, que en muchos aspectos se solapan.

En general, mi impresión es que los desarrolladores muy probablemente serán capaces de construir aplicaciones igual de complejas en cualquiera de estas dos blockchains, con una facilidad comparable. En este sentido, ambas plataformas son competidoras directas.

En su enfoque sobre el escalado, Ardor y NEM son bastante diferentes.

Mientras que Catapult obtendrá una mejora significativa en el ratio de transacciones confirmadas por las blockchains privadas, soy más escéptico sobre la mejora del rendimiento que se podría alcanzar en una blockchain pública como la de NEM usando el mismo enfoque.

Por su lado, Ardor no intenta dirigir (por ahora) el tema del escalado computacional, pero ha encontrado una solución muy efectiva al problema del crecimiento desmesurado de la blockchain.

Supongo que el tiempo nos dirá si el escalado computacional o el crecimiento de la blockchain supondrá el mayor problema a largo plazo para la tecnología blockchain. El tiempo dirá también si alguna plataforma ha encontrado la solución adecuada.

View this in: English 简体中文

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.