NXTER.ORG

Ardor Frente a la Competencia, Comentarios Finales

Esta es la entrega final de una serie de artículos que comparan Ardor con otros proyectos blockchain con características u objetivos similares. A continuación puedes encontrar las entradas anteriores de esta serie:

Esta serie comenzó como una breve e informal entrada en Reddit dónde exponía mis reacciones iniciales al paper de Plasma. No supe en ese momento que me estaba embarcando en un viaje por media docena de plataformas más, desde plataformas con cadenas laterales (Lisk, Stratis, de alguna manera Komodo) a plataformas con monedas coloreadas con características exclusivas (NEM, Waves), hasta un proyecto que evita la blockchain y usa una estructura completamente diferente (IOTA). Ahora que ha llegado el momento de concluir la serie, con los dos últimos artículos centrados de nuevo en Ethereum, creo que hemos llegado a un buen sitio para concluir nuestro viaje

En esta serie hemos realizado un gran recorrido y sería imposible resumirlo todo aquí. En su lugar, me gustaría compartir mis reflexiones sobre un tema general que ha surgido recurrentemente al realizar mi investigación sobre estos proyectos.

Escalando con Seguridad

Tal y como he mencionado anteriormente, mi interés principal a lo largo de esta serie ha sido evaluar diferentes maneras de enfrentarse al problema de escalar una blockchain. Lo que he descubierto es que existen diversas estrategias, pero la mayoría tienen como contrapartida que afectan a la seguridad. Ciertamente no soy el primero en hacer esta observación, pero creo que debe ser repetido de nuevo en el contexto de esta serie.

En un extremo del espectro, la forma más seguro para lanzar un nuevo proyecto blockchain es probablemente emitir un token en una blockchain existente que se encargue de ofrecerle la seguridad necesaria. Este es el enfoque que buscan las monedas coloreadas de Nxt, NEM, Waves y Ethereum, por ejemplo. Las transacciones que involucran a estos tokens son almacenadas directamente en la blockchain subyacente y son, por tanto, tan seguras como cualquier otra transacción que tenga lugar en esa blockchain.

La parte negativa de este enfoque es que no permite escalar demasiado bien: cada nodo de la red tiene que procesar todas las transacciones de todos los tokens de la blockchain, incluso si los proyectos a los que esos tokens representan no tienen nada que ver el uno con el otro. Además, todos los datos de las transacciones son almacenados para siempre en la misma blockchain, haciendo que crezca proporcionalmente al volumen combinado de transacciones de los proyectos que corren en ella.

Así que los llamados métodos de escalado “verticales”, que pretenden que cada nodo realice la misma cantidad de trabajo más rápidamente, o se almacene la misma cantidad de datos de manera más eficiente, son la manera natural para escalar en este modelo. El proyecto Catapult de NEM es un buen ejemplo, puesto que se centra en optimizar el código del cliente completo y el protocolo de comunicación usado en la red. Waves NG, una optimización del protocolo de forjado, es otro ejemplo de lo mismo.

No obstante, este enfoque sobre la manera de escalar tiene límites. Llegará un momento en que, conforme se van añadiendo un mayor número de usuarios y transacciones, este diseño se romperá y la única forma viable para su escalado será del tipo “horizontal”, donde cada nodo de la red procese solo una sub-serie de todas las transacciones

Una forma razonable de escalar una plataforma blockchain horizontalmente es trasladar cada proyecto a su propia blockchain independiente, lo que constituye la base de las plataformas de cadenas laterales como Lisk o Stratis. Este enfoque se sitúa en el otro extremo del espectro entre seguridad y escalabilidad: se particiona tanto el poder de computación como el espacio de almacenamiento requerido para ejecutar la plataforma y se permite que existan diferentes nodos para gestionar cada partición, pero este método de escalado implica un descenso de la seguridad. Particularmente, con N proyectos funcionando en una blockchain lateral, la cadena lateral más débil esta protegido como mucho por 1/N del total de los mineros o forjadores, y posiblemente nos encontremos muy por debajo de esa cifra, especialmente en sus primeros momentos.

Ardor se sitúa en una posición intermedia en el espectro seguridad-escalabilidad, consiguiendo reducir el espacio de almacenamiento para dar servicio a los proyectos que funcionan en sus propias child chains sin tener que reducir su seguridad, pero requiriendo todavía que toda la red procese cada transacción. Será interesante ver los detalles del plan de Jelurida para hacer que el procesado de las transacciones de las child chains tenga lugar en subredes dedicadas de la red, lo que ofrecería el escalado computacional y de ancho de banda perdido, pero hasta que llegue este momento, solo podemos especular.

IOTA es un poco un caso especial, puesto que los fundamentos de su diseño son diferentes de los de una blockchain en un par de puntos importantes. Sin volver a explicar todo el mecanismo del “consenso a largo plazo” en el tangle, permitidme afirmar que el tangle de IOTA (tal y como está implementado hoy en día) me parece que es principalmente una forma de escalado vertical, con un elemento de escalado horizontal. Cada nodo ve y almacena cada transacción, y a pesar de que los nodos pueden podar continuamente el tangle conforme pasa el tiempo, reduciendo los requisitos de almacenamiento, los “permanodes” de la red deben almacenar todo el historial del tangle para que los nuevos nodos puedan arrancar sin tener que depositar la confianza en un tercero. Por otro lado, los nodos no necesitan validar cada transacción, puesto que son capaces de aceptar que las transacciones que se realizaron tiempo atrás en el tangle ya han sido confirmadas por otros nodos de la red, puesto que todas las puntas hacen referencia a ellas.

En otras palabras, IOTA particiona el trabajo de computación requerido para validar las transacciones, pero no el ancho de banda requerido para retransmitirlas o los datos que deben ser almacenados.

A largo plazo, IOTA planea introducir los nodos “manada” para dividir las tareas de validación de las transacciones y almacenamiento del tangle. Esto será una manera de partición horizontal, pero todavía no he sido capaz de encontrar los detalles técnicos, así que en mi opinión pertenece a la misma categoría que el Plasma de Ethereum y las propuestas de fragmentación: una idea que suena plausible, pero que necesita mayor desarrollo antes de que pueda ser aceptada como una solución real.

Sobre esto, me gustaría hacer un apunte final acerca del enfoque de Ardor sobre el escalado: aunque no es la panacea, al menos en estas primeras fases, es importante no subestimar el valor de una arquitectura que ya existe y realmente funciona. Quizá no sea necesario decirlo, pero los desarrolladores de Ardor no solo están lanzando hipótesis sobre soluciones teóricas a un problema difícil. Han demostrado que pueden diseñar un diseño ambicioso pero realista, implementándolo en un periodo de tiempo razonable y consiguiendo progresar hacia una blockchain realmente escalable. No todos los equipos puede afirmar lo mismo, ni aún aquellos que sus ideas iniciales sonaban prometedoras.

Reflexiones Finales

Se podría decir mucho más sobre todos estos proyectos, pero esto tendrá que ser suficiente por ahora. Espero que os hayan gustado estos artículos aunque tan solo sea la mitad de lo que he disfrutado yo escribiéndolos. Como nota personal, me gustaría agradeceros el que hayáis leído hasta aquí y por que hayáis compartido estos artículos con otros entusiastas blockchain. Ha sido muy gratificante ver como la gente ofrecía su apoyo, sus comentarios y expresaba todo tipo de reacciones. Me siento honorado y muy agradecido porque os halláis tomado el tiempo para leer mi trabajo.

Si me permitís dejaros con una reflexión de despedida, sería la siguiente: después de todo lo que se ha dicho y hecho, veo un tremendo potencial en varios de estos proyectos, pero estoy especialmente emocionado por Ardor. Su arquitectura de cadena madre / cadena hija solventa simultáneamente dos problemas muy importantes: como enfrentarse al crecimiento desmesurado de la blockchain, y como ofrecer una blockchain como servicio a los clientes que no cuentan con los recursos o experiencia para lanzar su propia blockchain. Nadie sabe que valor económico el mercado asignará a Ardor y a la forma en que soluciona estos problemas pero, en mi humilde opinión, Ardor sale favorecido en las comparaciones con la competencia en ambos puntos. Tengo muchas ganas por ver lo que el futuro nos depara.


Prueba Ardor en la testnet

Sobre la última versión de Ardor para la testnet

Ardor Frente a la Competencia, Parte 8: Ethereum (Hinchazón de la Blockchain)

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:

Este artículo continua la comparación iniciada en la entrega anterior entre Ardor y Ethereum. En esta ocasión, se explora como se enfrenta cada plataforma al problema del hinchazón de la blockchain. Para mi sorpresa, ambas plataformas son más similares al respecto de lo que había pensado, aunque también existen diferencias significativas.

Es clave para esta comparación entender cómo está organizada la blockchain de Ethereum.

Estructura de Ethereum

Al igual que Nxt, Ethereum realiza un seguimiento del estado de todas las cuentas con cada bloque nuevo. Y al igual que Bitcoin, Ethereum organiza la información en cada bloque en un arbolo del tipo Merkle (en realidad, en tres de estos árboles) y almacena su hash de raíz en la cabecera del bloque.

¿Cómo funciona esto exactamente? Este diagrama extraído de este artículo nos ayuda a entenderlo.

 

Las hojas de un árbol Merkle (es decir, las de la parte de abajo) representan todos los datos reales almacenados. Cada nodo por encima de las hojas almacena un hash criptográfico de sus dos hijas. (Nótese que estoy usando el término “nodo” aquí para referirme al elemento del árbol, no a ordenadores en una red. Cada ordenador de la red almacena todo el árbol.)

El diseño tiene la capacidad de que si incluso se cambiase un simple byte de una sola hoja, el hash de su padre también cambiaría, así como el hash del padre de su padre, así sucesivamente hasta el nodo de más arriba, llamado “la raíz Merkle”. En cierta manera, la raíz Merkle contiene un resumen de toda la información de las hojas.

Simplemente agrupando conjuntamente todos las hojas y estableciendo su hash de una sola vez se produciría un resultado similar, pero la estructura de árbol tiene una segunda propiedad interesante, que hace posible demostrar que una hoja particular del árbol está en el árbol sin necesidad de ver todo el árbol. Por ejemplo, en este diagrama es posible demostrar que la transacción realmente ha sido añadida proporcionando para ello información sobre su hermano (en amarillo), su padre (en gris) y los otros hermanos y padres hasta su camino de vuelta a la raíz. Otro usuario podría calcular los hashes relevantes en cada nivel del árbol y a continuación comparar la raíz de Merkle resultante con la que está almacenada en la blockchain. Estas “pruebas de Merkle” son la base del sistema de los clientes de verificación de pagos simplificados en Bitcoin (SPV) y también de diversas propuestas de escalado para Ethereum.

Ethereum utiliza tres árboles de Merkle separados para almacenar la información de cada bloque: uno para las transacciones de los bloques; un segundo para una serie de “receptores” de esas transacciones, los cuales representan los efectos de cada transacción; y una tercera para almacenar el estado instantáneo de cada cuenta, incluyendo sus saldos y datos asociados. Almacenar el estado completo del sistema en cada bloque aparenta ser un terrible derroche, pero puesto que cada bloque solo modifica una pequeña porción de hojas, la mayoría de las ramas del árbol de estado no cambian de bloque a bloque y cada nuevo árbol de estado puede hacer referencia a ramas completas del estado anterior con un coste mínimo. Hay unas pocas complicaciones técnicas sobre este enfoque, y es por ese motivo por el que Ethereum en realidad usa una estructura de datos ligeramente diferente llamada árbol Merkle-Patricia, pero el concepto sigue siendo el mismo.

Los Nodos de Rápida Sincronización de Ethereum

El hecho más importante de todo esto es que las propiedades de las funciones de hashes criptográficos aseguran que sea prácticamente imposible construir dos árboles diferentes con la misma raíz. Como resultado, el registro de la raíz Merkle almacenado en la cabecera del bloque en Ethereum es suficiente para establecer que la red validó en ese momento la correspondiente transacción y estado de transacciones.

En otras palabras, incluso aún después de que un nodo haya “olvidado” los contenidos de un bloque antiguo, mientras siga conservando las (mucho más pequeñas) cabeceras del bloque en el archivo, puede solicitarle a un nodo completo el contenido completo de un bloque y verificar por si mismo que el nodo completo no ha sido adulterado con ningún dato. (Hay que recordar que aquí y para el resto del artículo vuelvo a referirme a un “nodo” como a un par en la red, no un objeto del árbol de Merkle.)

Este enfoque es el que se utiliza la opción de sincronización rápida del monedero Go Ethereum (geth). Para realizar una sincronización rápida, un nuevo nodo primero descarga y verifica todas las cabeceras de los bloques, empezando por el bloque génesis (en realidad, solo uno de cada 100 cabeceras de bloque debe ser verificada; ver el enlace en GitHub para más detalles). Puesto que las cabeceras continúan la Prueba de Trabajo, este paso es suficiente para mostrar que la red alcanzó un consenso sobre la raíz de Merkle en cada cabecera en el momento en que el bloque fue minado.

En algún punto del pasado reciente, supongamos que hace 1024 bloques, el nodo recibe una versión completa del estado del árbol proveniente de sus pares y la valida frente a la raíz Merkle en su correspondiente cabecera. Desde ese punto en adelante, el nodo descarga los bloques completos desde los pares y re-ejecuta todas las transacciones hasta que alcanza el bloque más reciente, en cuyo punto simplemente se convierte en un nodo completo ordinario.

Aunque Go Ethereum actualmente no lo soporta, es también posible que los nodos poden continuamente el árbol de estado según avanza el tiempo, manteniendo al mínimo la cantidad de datos de estado que deben ser almacenados.

El Podado de las Child Chains en Ardor

Si has analizado el arquitectura de Ardor de cadena madre / cadena hija (parent chain / child chain), esta estrategia posiblemente te resulte bastante familiar. Ardor toma un enfoque muy similar respecto a sus child chains.

En pocas palabras, la plataforma Ardor consiste en un única cadena madre del tipo Prueba de Participación (proof-of-stake), también conocida como Ardor, y una serie de child chains. La cadena madre soporta solo unos pocos de tipos de transacciones, básicamente aquellos requeridos para transferir Ardor y para la forja. Las child chains, por su lado, manejan todo el negocio real que tiene lugar en la plataforma usando las transacciones inteligentes que describí en el artículo previo de esta serie.

Solo la moneda de la cadena madre (ARDR) se puede usar para forjar. Las transacciones que involucran tan solo a las monedas de las child chains no afectan los saldos de la moneda de forja, así que no son esenciales para la seguridad de la blockchain y no necesitan ser almacenadas permanentemente. Los nodos “agrupadores” especiales en cada child chain recolectan esas transacciones, las agrupan juntas, establecen su hash, y envían ese hash a la red usando un tipo de transacción especial llamado ChildChainBlock. Incluyen toda la información de la transacción junto a la transacción del tipo ChildChainBlock, así que los forjadores y resto de nodos pueden verificar que las transacciones de la child chain son válidas y producen realmente el hash indicado, pero los datos en sí mismos no son almacenados en la blockchain y tras un tiempo establecido se pueden podar. Todo lo que queda en la cadena madre es el hash de esa información.

Opcionalmente, los nodos especiales de archivo en cada cadena hija pueden almacenar el historial completo de las transacciones de esa child chain. En los casos en que el historial sea necesario, los nodos pueden obtenerlo, calcular el hash de de las transacciones de agrupación originales y verificar que los hashes se corresponden con los que están almacenados en la blockchain.

Llegados a este punto, espero que la comparación con la opción de sincronizado rápido de geth haya quedado clara: en ambos casos, los nodos no necesitan almacenar la gran mayoría de los datos de la transacción para ser capaces de verificar que la red aprobó todas esas transacciones en el momento en que fueron hechas. En Ethereum, es suficiente con verificar la prueba de trabajo en la cabecera de los bloques y la exactitud de una raíz Merkle determinada para ser capaz de confiar en el correspondiente árbol de estado. Ardor es ligeramente más complicado porque usa el algoritmo de prueba de participación para el consenso, pero almacenar todo el historial de transacciones de ARDR junto a las transacciones ChildChainBlock asegura que los nodos pueden verificar, desde el bloque génesis, que cada bloque fue forjado por un forjador legítimo.

Comparando Ambos Diseños

Llegados a este punto, espero que estés de acuerdo conmigo en que podemos establecer los siguientes paralelismos entre Ethereum y Ardor:

  • Un nodo completo de Ethereum es similar a un nodo de Ardor que almacena el historial completo de cada child chain.
  • Un nodo de sincronización rápida de Ethereum que pode de manera continua el árbol de estado es similar a un nodo ordinario de Ardor, el cual almacena toda la cadena madre pero poda todos los datos de la cadena hija.
  • Ardor ofrece la posibilidad de ejecutar un nodo que almacene toda la cadena madre, además de los datos de las transacciones almacenadas de una sola child chain. Esta opción no tiene equivalente en Ethereum.

Por supuesto que estas analogías no son perfectas. En concreto, no hay que pasar por alto que las cabeceras de los bloques de Ethereum son considerablemente más pequeñas que los bloques completos de la cadena madre de Ardor. También he pasado por alto el mecanismo que Ardor utiliza para realizar el seguimiento de las instantáneas del estado completo del sistema y almacenar los hashes de esas capturas en la cadena madre.

Aún así, creo que la comparación es de ayuda. El tercer elemento de esta lista es especialmente interesante, puesto que parece constituir la mayor diferencia cuantitativa entre ambos diseños. En Ardor, la capacidad para almacenar el historial de las transacciones de cada child chain en un juego de nodos de archivo diferenciado permite un tipo de partición vertical de la base de datos de la partición. Puesto que es probable que cada child chain sirva a diferentes negocios o proyectos, particionar el juego completo de transacciones por las líneas establecidas por las child chains parece una evolución natural. Quizás en Ethereum la mejora analogía sería un diseño dónde el usuario pudiese ejecutar un nodo completo para un único proyecto, como Golem, sin tener que ejecutar simultáneamente nodos para Augur, BAT o cientos de otros proyectos.

Sobre esto último, me llama la atención que los árboles Merkle de Ethereum puedan acomodar de manera natural ese diseño, dónde un “nodo completo de Golem” rastrearía toda la blockchain en búsqueda de todas las transacciones que involucrasen GNT, almacenaría todas las pruebas Merkle para esas transacciones y transiciones de estado permanentemente y descartaría los datos restantes. Tengo que admitir que no he pensado suficientemente sobre las implicaciones de esta idea, así que no voy a decir mucho más sobre ello.

En cualquier caso, ni esta hipotética estrategia para Ethereum, ni la arquitectura de cadena madre / cadena hija de Ardor, implica una fragmentación real de la blockchain, puesto que en ambos casos cada nodo todavía tiene que procesar todas las transacciones de toda la red. Estos diseño particionan el almacenamiento pero no el ancho de banda o el poder de computación requerido para ejecutar la blockchain. Una adecuada estrategia de escalado debería dirigir estos tres cuellos de botella.

Hablando de fragmentación…

Fragmentación

La visión de Ethereum para el escalado de la cadena a largo plazo es la fragmentación, una manera de particionar el almacenamiento, los datos y el procesado de las transacciones. El objetivo es que la mayoría de los nodos de la red tengan que procesar las transacciones de un único fragmento, liberándolos de la carga de tener que validar y almacenar las transacciones que afecta a otros fragmentos.

Ni siquiera voy a tratar de evaluar las propuestas del equipo de Ethereum aquí, puesto que este artículo ya se está extendiendo demasiado, pero si estás interesado en este tema os recomiendo visitar su fantástico documento con Preguntas y Respuestas sobre fragmentación en GitHub.

Sin embargo, la razón por la que he sacado ha relucir la fragmentación es que los desarrolladores de Ardor han sugerido que están explorando maneras de llevar el procesado de las transacciones de las child chains a redes dedicadas dentro de la red Ardor. No nos han ofrecido datos técnicos todavía, y voy a evitar especular aquí sobre la manera en que podrían funcionar pero, personalmente, la idea me parece realizable.

Si los desarrolladores pudieran ofrecer más sobre esta idea, entonces la plataforma Ardor se parecería mucho al “diseño básico de una blockchain fragmentada”, descrita en el documento del equipo de Ethereum. Esa sección del documento describe una serie de nodos “ordenadores” (agrupadores) encargados de recolectar (agrupar) las transacciones de un único fragmento (child chain), validándolos y almacenando su hash en una “cabecera de ordenación” (transacción del tipo ChildChainBlock) en la cadena madre. Los “super nodos completos” (actuales nodos de la cadena madre) procesarían todas las transacciones de todos los fragmentos; los “nodos top-level” (los futuros nodos de la cadena madre) procesarían solo los bloques de la cadena madre, pero no todos los datos de todas las ordenaciones; y los “nodos de un solo fragmento” (los futuros nodos de las child chain) procesarían todas las transacciones en la cadena madre y un único fragmento.

Casi todas las complicaciones surgen de la comunicación entre fragmentos y, como resultado, este diseño funciona mejor cuanto más independientes son los fragmentos. Como ya he mencionado, las child chains de Ardor pueden cumplir naturalmente este tipo de partición, dónde cada cadena soportará un proyecto separado, dónde las interacciones entre proyectos están permitidas pero son menos comunes que las transacciones dentro de un proyecto.

Conclusión

En estas fases tempranas estas ideas son inciertas, claro está. Sin embargo, las posibilidades son emocionantes. El diseño de Ardor ya incorpora el algoritmo de consenso de Prueba de Participación, un objetivo separado que el equipo de Ethereum se ha establecido para si mismo, además de una partición razonable de los datos de la blockchain, lo cual es un requerimiento obvio para cualquier solución fragmentada. Entre las ausencias notables en Ardor encontramos las pruebas Merkle, u otras maneras compactas de que las particiones se comuniquen información de estado entre ellas, pero no parece que estas características pudieran ser introducidas en la plataforma a través de un hard fork. Los hashes del snapshot y los hashes de los bloques child chain que se convertirían raíces Merkle ya están presentes en el protocolo, después de todo.

Pero ¿qué podemos decir sobre el estado actual de ambos proyectos? Quizá el hecho más interesante que he descubierto al investigar y escribir este artículo es que Ethereum realmente escala mucho mejor de lo que yo había pensado. La opción de sincronización rápida de Go Ethereum para los nodos completos permite algunas de las ventajas del diseño de Ardor, y si algún día incorpora el podado del estado del árbol la analogía será incluso más cercana.

Por otro lado, el mayor inconveniente del actual diseño de Ethereum es que todavía tiene que haber nodos completos en algún lugar de la red, y esos nodos completos tienen que almacenar más de 300 GB de la blockchain de Ethereum. Conforme sigue creciendo, y en consecuencia, los costes de ejecutar un nodo completo crecen a la par, uno esperaría que la proporción de nodos completos en relación a los nodos ligeros y nodos de sincronización rápida descienda. Como consecuencia, cada nodo completo probablemente acabaría teniendo que gestionar un mayor volumen de solicitudes de otros nodos, mayor incremento de los costes (en términos de ancho de banda y poder computacional) para ejecutar un nodo completo.

Incluso sin fragmentación, el diseño de Ardor mitiga este problema potencial al romper los monolíticos nodos completos de Ethereum en juegos de nodos de archivo, cada uno de los cuales almacenaría solo el estado de una child chain. Sería posible almacenar el historial de varios nodos simultáneamente si así se desease, pero unos pocos nodos, o potencialmente ninguno de ellos, serían requeridos para restaurar el historial completo del ecosistema completo

No es necesario decir que escalar una blockchain es una ardua tarea. Más allá de los diversos proyectos que he analizado para esta serie, Ardor y Ethereum me parece que ofrecen la visión más convincente para el escalado de una cadena. Y mientras espero que ambas triunfen, tengo que admitir, juzgando únicamente por el progreso concreto que cada proyecto ya ha hecho hacia conseguir su objetivo, Ardor me parece que parte de una situación ventajosa.


Prueba Ardor en la testnet

Acerca de la última versión de Ardor para la testnet

 

 

Ardor Frente a la Competencia, Parte. 7: Ethereum (Contratos Inteligentes)

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 Ethereum, el cual creo que no necesita introducción alguna.

Al estudiar varios de los proyectos que he investigado en esta serie, en ocasiones ha sido difícil encontrar información técnica detallada sobre ellos. En Ethereum sucede exactamente lo contrario: hay tanta información disponible que es difícil resumirla en un artículo de una longitud razonable sin riesgo a simplificar en exceso las ideas.

Por este motivo, he elegido solo dos aspectos de Ethereum para compararlos con Ardor. Esta entrega compara sus contratos inteligentes con las transacciones inteligentes de Ardor y el próximo artículo comparará la manera en que ambas plataformas se enfrentan al problema del crecimiento desmesurado de la blockchain (blockchain bloat). Hay muchos más temas sobre los que me habría gustado hablar, como por ejemplo su plan para convertirse en Proof-of-Stake (Casper), su estrategia state-channel (Raiden y Plasma), su asociación con grandes compañías a través de la Enterprise Ethereum Alliance y ejemplos de proyectos que lo utilizan, pero poder hablar aunque solo sea de un par de estos temas con la rigurosidad necesaria ya es suficiente desafío. Además, los dos temas que he elegido ofrecen, en mi opinión, la comparativa más interesante entre las dos plataformas (visita también el artículo de Ardor Frente a Plasma, enlazado más arriba, para algunas reflexiones sobre Plasma).

Sin más dilación, hablemos sobre los contratos inteligentes o smart contracts.

Los Contratos Inteligentes y la “Diversidad de Estados de una Cuenta”

El diseño de Ethereum combina elementos de Bitcoin y Nxt y añade además varias características novedosas. Al igual que Bitcoin, Ethereum usa un lenguaje de programación de bajo nivel para codificar las transacciones y almacena los contenidos de cada bloque en árboles del tipo Merkle cuyos hashes de raíz están almacenados en las cabeceras de los bloques (más sobre este tema en el próximo artículo). Al igual que Nxt, realiza un seguimiento del estado actual de los saldos de las cuentas y otros datos específicos de las cuentas directamente, en lugar de seguir el modelo de Bitcoin de Salida de Transacciones sin Gastar (Unspent Transaction Output – UTXO).

Las innovaciones más importantes que Ethereum añade a esta combinación son dos: la capacidad de almacenar scripts (contratos) en las llamadas “cuentas de contratos”, las cuales realizan transacciones automáticamente sin estar controladas por un usuario; y la capacidad de que las transacciones persistan en una cuenta desde una transacción hasta la siguiente. El lenguaje de programación de Ethereum es también, de algún modo, más potente que el de Bitcoin, permitiendo que los contratos incluyan loops e invoquen a otros contratos.

Combinando estas ideas, es posible crear los llamados “contractos inteligentes” con estados, que son unas líneas de código y datos que residen en las cuentas de contratos como agentes autónomos, escuchando los inputs de los usuarios y otros contratos y realizando transacciones con ellos de acuerdo a las reglas definidas en el código de su contrato. El apelativo “con estados” de la frase anterior es fundamental: puesto que un contrato inteligente puede tener su propio estado interno, es posible que una transacción afecte la forma en que las transacciones subsecuentes son procesadas. Esto es una diferencia significativa con el modelo de Bitcoin, dónde los scripts de transacciones solo se ejecutan una única vez y dónde el concepto de “estado” disponible para un script esta esencialmente limitado a si un determinado output se ha gastado o no.

(Quizá te hayas dado cuenta de que no he dicho nada sobre la exhaustividad del Turing. Dependiendo de lo escrupuloso que te quieras poner, podrías argumentar en favor de cualquiera de las posiciones acerca de si el lenguaje de programación de Ethereum es realmente Turing en su totalidad. Tal y cómo explica el presentador de este excelente vídeo, ser completamente Turing puede actuar en ocasiones cómo un falso indicador. Es mucho más importante el hecho de que los contratos inteligentes está repletos de estados y pueden realizar transacciones entre ellos y con otros usuarios de maneras muy interesantes.)

Las aplicaciones potenciales de los contratos inteligentes se extienden más allá de establecer condiciones para la transferencia de dinero de una cuenta a otra. Incluso el white paper original (una gran lectura, por cierto) proponía un puñado de usos no-financieros, incluyendo el almacenamiento de archivos, votación, computación distribuida, gobernanza de organizaciones descentralizadas y mercados descentralizados. Desde entonces, los desarrolladores han encontrado multitud de otras aplicaciones, tales como mensajería descentralizada. Y, por supuesto, la aplicación de Ethereum más comúnmente utilizada hasta el momento: llevar a cabo ventas de tokens para varios proyectos.

Las “Transacciones Inteligentes” de Ardor

Si esa lista de aplicaciones te resultan familiares, puede que sea porque todas ellas ya han sido implementadas en Nxt yArdor como como “transacciones inteligentes” predefinidas. Introducidas por el predecesor de Ardor, Nxt, las transacciones inteligentes son porciones de funcionalidades de “blokchain 2.0″ que los desarrolladores de Nxt y Ardor han publicado como parte del mismo protocolo. Estas transacciones permiten a los desarrolladores crear aplicaciones blockchain sin tener que escribir y testear sus propios contratos inteligentes.

Para permitir que los usuarios comunes (es decir, los no desarrolladores) se beneficien también de esta funcionalidad, los monederos oficiales de Nxt y Ardor incluyen un puñado de transacciones inteligentes incluidas. Se trata de:

  • el Intercambio de Activos, dónde los usuarios pueden emitir activos, comercializarlos y pagar dividendos a los poseedores del activo;
  • el Sistema Monetario, dónde los usuarios pueden emitir monedas y conducir diferentes tipos de campañas de crowdfunding;
  • un sistema de mensajería, que permite que los usuarios envíen mensajes de texto simple o codificados;
  • un sistema de votación, que permite que los usuarios realicen votaciones en función de la cuenta, balance de cuenta, balance de determinados activos o balance de determinadas monedas;
  • un coin shuffler integrado, que puede otorgar a los usuarios un cierto grado de privacidad difuminando su historial de transacciones;
  • un almacenamiento de datos descentralizado, que puede grabar el hash de un archivo permanentemente en la blockchain y, opcionalmente, almacenar el archivo en si mismo permanentemente gracias a los nodos de archivo;
  • un mercado descentralizado, donde los usuarios pueden comprar y vender bienes y servicios entre pares (peer-to-peer);
  • un nuevo Intercambio de Monedas (solo en Ardor), donde los usuarios pueden comprar y vender las monedas de las diferentes child chains directamente entre sí;
  • un número de características avanzadas, tales como las transacciones condicionadas, que permiten a los usuarios establecer unas condiciones sobre cuándo y cómo otras transacciones son ejecutadas, y las propiedades de cuenta, que pueden usarse para asociar datos arbitrarios con una cuenta.

Por supuesto que estas no son las únicas transacciones que se pueden construir a partir de las transacciones inteligentes, pero sirven para mostrar el alcance de lo que se puede llegar a alcanzar con ellas. Todas estas características, junto a unas cuantas más, estarán disponibles en Ignis, la primera child chain de Ardor. Los creadores de otras child chains contarán con la opción de implementar tantas de estas características como necesiten hasta amoldarse a sus proyectos.

He escuchado diversas analogías para describir las transacciones inteligentes, pero mi favorita es que son como Legos, mientras que los contratos inteligentes son como arcilla: el primero de ellos no permite el mismo grado de control sobre los detalles más sutiles, pero son más rápidas y fáciles de utilizar que los segundos, y se puede combinar para formar productos finales con resultados espectaculares.

La analogía no es perfecta, por supuesto. Un potente argumento a favor de los contratos inteligentes es que, por ejemplo, es potencialmente posible que toda la lógica de negocios de una aplicación descentralizada (Dapp) se almacenada permanentemente y de forma inmutable en la blockchain, mientras que una Dapp construida a base de combinar transacciones inteligentes es muy probable que incluya algo de código externo. En este último caso, usar la Dapp puede requerir cierto grado de confianza en que el desarrollador no cambiará las reglas en futuras versionas de la misma.

Desde otro punto de vista, esta comparación también pone de relieve el mayor inconveniente de los contratos inteligentes: La facilidad con que los programadores pueden cometer errores de varios millones de dólares que no se puedan corregir.

Consideraciones de Seguridad

Casi cualquier software que es mínimamente complejo contiene imperfecciones y en muchas ocasiones estas imperfecciones hacen que el software pueda ser vulnerable a ataques de un hacker. Los desarrolladores de contratos inteligentes se enfrentan a una tarea particularmente difícil, puesto que el código que escriben es inmutable y, como resultado, sus vulnerabilidades son permanentes.

Desafortunadamente, descubrir fallos catastróficos en contratos inteligentes no ha sido excepcional. El ataque que congeló el equivalente en ether a $150 M almacenado en monederos multifirma de Parity o el hackeo de $30 M del mismo monedero  unos meses antes son solo los ejemplos más recientes que hemos visto en diversos titulares, pero no son los primeros y, con toda seguridad, no serán los últimos. Para una vista general de algunas de las vulnerabilidades comunes y un análisis de diversos ataques reales, incluyendo el desafortunado hackeo del DAO, recomiendo fervientemente leer este excelente documento elaborado por tres investigadores de la Universidad de Cagliari.

No hay que pasar por alto que ni el protocolo de Ethereum ni la Máquina Virtual de Ethereum (Ethereum Virtual Machine – EVM) fueron responsables de ninguno de estos ataques. Los seguidores de Ethereum a menudo sacan a relucir este punto, argumentando que Ethereum en si mismo es bastante seguro y todo lo que se necesita es que los desarrolladores escriban mejores contratos inteligentes. En un sentido literal tienen razón, por supuesto: En todos los casos Ethereum hizo lo que se suponía que debía hacer y la culpa recae en último lugar en los desarrolladores de los contratos inteligentes.

Pero personalmente me pregunto si este juicio que pretende absolver a Ethereum es demasiado rápido y si el problema podría ser mayor que unas pocas líneas erróneas en un contrato inteligente. De cualquier modo, por ahora me parece que el argumento fundamental de Ethereum es que otorga a los desarrolladores un poder tremendo pero unas herramientas insuficientes para usar ese poder de forma segura.

La ambición de los desarrolladores casi siempre excede el nivel de complejidad que se puede alcanzar mientras se mantiene, a la vez, el código perfectamente libre de errores, y siempre existirá la tentación de hacer que las funcionalidades tengan prioridad sobre la seguridad (esto es casi universal en el desarrollo de software, por cierto). Al inmortalizar el código que han creado, que contiene errores, almacenándolo en una blockchain, el brutal y despiadado Ethereum hará que paguen por sus pecados.

Afortunadamente, hay ciertas maneras de mitigar el riesgo de escribir contratos inteligentes vulnerables. Por ejemplo, es posible designar un contrato inteligente que pueda ser actualizado delegando para ellos sus responsabilidades en un segundo contrato, habitualmente denominado “contrato librería”, en una dirección que se puede cambiar para apuntar a una nueva librería más adelante.

Este enfoque permite a los desarrolladores parchear vulnerabilidades pero, como consecuencia, introduce la peliaguda cuestión de quien debe estar autorizado para cambiar a un nuevo contrato librería. Si es una única cuenta de un tercero, entonces el diseño introduce un cierto grado de confianza entre esa cuenta y el resto de usuarios. Por otro lado, si el desarrollador toma otro enfoque, tal como permitir votar a una mayoría de usuarios para aprobar cada nuevo contrato librería, entonces pueden emerger nuevos problemas a solucionar, tales como escribir un mecanismo de votación, asegurarse de que los usuarios están lo suficientemente informados y comprometidos para votar, y evitar que un hacker cause un daño considerable durante todo el tiempo que se tarda en organizar una votación.

Otra aproximación muy prometedora sobre la seguridad de los contratos inteligentes es usar técnicas de verificación formal tomadas prestadas de las matemáticas. No sé mucho sobre estos métodos formales, así que tomad con pinzas lo que escribo aquí, pero no se si es más sencillo (o simplemente realizable) con programas sencillos cuya funcionalidad puede ser expresada como una serie de reglas sencillas y cortas. En estos casos, puede ser posible demostrar con certeza que el programa no contiene errores. Sin embargo, incluso técnicas evidentes como el looping o la recursividad pueden complicar el análisis significativamente, así que es mejor si el programa a testear es lo más sencillo posible.

¿Por qué insisto tanto en este tema? Poniendo todas estas ideas juntas podría parecer que la mejor manera para escribir contratos inteligentes implicaría: 1) mantenerlos lo más cortos y sencillos posibles; 2) delegar la lógica del núcleo de negocios a una librería de contratos que pudiese ser actualizada, en caso necesario; y 3) reutilizar librerías que han sido concienzudamente examinadas, para reducir al mínimo la cantidad de código nuevo. Si el segundo de estos puntos requiere que los usuarios de un contrato tengan que depositar su confianza en el autor de un contrato en cierto grado, como sucede habitualmente, entonces los contratos designados de acuerdo a los anteriores tres puntos comienzan a parecerse mucho a las transacciones inteligentes de Ardor: bits de código estable y concienzudamente testeado que permiten obtener las funcionalidades más comúnmente necesitadas, las cuales los desarrolladores pueden combinar para formar programas más complejos.

El Equilibro entre Seguridad y Flexibilidad

No estoy sugiriendo que las transacciones inteligentes de Ardor puedan realizar todo lo que puedan llegar a realizar los contratos inteligentes de Ethereum, ni estoy diciendo que combinaciones de transacciones inteligentes puedan siempre emular a los contratos inteligentes. Sin embargo, lo que estoy diciendo es que creo que hay una tensión natural entre la flexibilidad que una plataforma ofrece y la seguridad del código que, irremediablemente, los desarrolladores tienden a escribir usándola.

Desde este punto de vista, las plataformas blockchain están siempre asentadas en un bucle seguridad-flexibilidad. Próximo al extremo de la “seguridad” está Bitcoin, cuyo lenguaje de programación es deliberadamente bastante limitado para evitar que los usuarios bloqueen sus cuentas con scripts vulnerables (aunque esto es posible, por supuesto). Nxt y Ardor ocupan una posición intermedia en este espectro, limitando a los desarrolladores con un juego de tipos de transacciones predefinidas, pero incorporando una enorme variedad de funcionalidades en esos tipos.

Los contratos inteligentes de Ethereum, por su parte, abarcan todo el espectro. Es posible escribir scripts extremadamente simples, triviales y seguros en Ethereum y también es posible escribir scripts más complicados que contengan vulnerabilidades muy sutiles. Y lo que quizá sea igual de importante, es difícil para los usuarios diferenciar entre esos casos, y no sería razonable en ningún caso esperar que el usuario lo hiciese. Usar Ethereum de manera segura implica evitar la parte del espectro que está más próxima a la “flexibilidad”, incluso aunque esto suponga la introducción de un cierto grado de confianza entre usuarios y desarrolladores.

Finalmente, vale la pena mencionar que Ardor ofrece una nueva característica, no disponible previamente en Nxt, que le ayuda a aproximarse al lado de la “flexibilidad”: la habilidad para combinar transacciones condicionadas usando operadores booleanos tales como AND, OR y NOT, para conseguir un comportamiento semejante a unos contratos inteligentes primitivos.

En pocas palabras, las transacciones condicionadas permiten a los usuarios condicionar la ejecución de una transacción latente a que tenga lugar un determinado evento, tal como la aprobación por parte de  un determinado número de cuentas específicas, una votación en la que pueden participar todas aquellas cuentas que posean un determinado activo, el paso de una determinada cantidad de tiempo (timelock) o la revelación de un secreto (por ejemplo, un hashlock). En Ardor, las combinaciones de estos tipos de transacciones condicionadas pueden dar lugar a condiciones más complejas, tales como “la transacción X es válida si la mayoría de los accionistas de la compañía ABC la aprueban antes de una fecha Y, salvo que sean vetadas por una gran mayoría de los miembros de la junta de la empresa ABC.”

Sin duda, también se podrían combinar transacciones condicionadas de manera que permitiese la obtención de resultados inesperados, lo que podría incluir la pérdida de fondos. Pero yo diría que la ventaja sobre los contratos inteligentes en términos de seguridad todavía está ahí, puesto que los desarrolladores se pueden centrar en asegurarse que la lógica de la transacción para los negocios es segura, sin tener que preocuparse por los errores de bajo nivel (low-level bugs) tales como las condiciones de la carrera. Y por supuesto, la desventaja de ofrecer menor flexibilidad que los contratos inteligentes sigue también ahí.

Conclusión

Con un protocolo definido por una serie de transacciones inteligentes pre-compiladas en lugar de un lenguaje de programación de bajo nivel, Ardor probablemente nunca será capaz de ofrecer a los desarrolladores un rango de posibilidades tan grande como hace Ethereum, al menos en los casos en que todo deba hacerse en la cadena para no tener que depositar en la confianza entre las partes. Por otro lado, escribir contratos no triviales que sigan las mejores prácticas de seguridad requiere igualmente de confianza adicional entre usuarios y desarrolladores. Y, por supuesto, los usuarios de Ethereum tienen que acabar confiando en que los autores de los contratos inteligentes no han cometido ningún error y han escrutado concienzudamente y probado su código, para estar completamente seguros de ello.

Naturalmente, puedes pensar que esto mismo sucede con cualquier software, incluyendo las transacciones inteligentes de Ardor, pero hay una diferencia clave: simplemente hay mucho más código ejecutándose en Ethereum. Nxt ha sido de código abierto desde el comienzo, ofreciendo una gran oportunidad para ser revisado. El código de Ardor, que está basado en el código base de Nxt, será liberado pronto. Además, cada nuevo cambio añadido el protocolo ha sido chequeado en profundidad en una testnet pública antes de ser lanzado oficialmente. Lo mismo debería cumplirse para cada uno de los contratos inteligentes, pero con tanto código escrito, parece que es inevitable que existan más oportunidades para que los errores se cuelen en el entorno de producción.

En cualquier caso, sospecho que el grado en que la mayoría de las Dapps exitosas dependerán de código inmutable todavía es una pregunta sin respuesta. Si el acceso a una base de datos inmutable y a un puñado de operaciones simples sobre esos datos son suficientes para la mayoría de las aplicaciones, entonces las transacciones inteligentes de Ardor parece que tienen una clara ventaja sobre los contratos inteligentes. Por el contrario, si el concepto de que “el código es la ley” resulta ser esencial para la viabilidad de la mayoría de las Dapps, dónde cada Dapp requiera que la mayoría de su exclusivo código sea almacenado en la blockchain para no depender para nada de la confianza en un tercero, entonces el enfoque de Ethereum sea probablemente superior.

Confío en que habrá aplicaciones del mundo real que encajen en estas plataformas. Pero también me pregunto si a la larga quedará dejará claro que uno de los dos enfoques va a manejar la mayoría de las aplicaciones. Que enfoque resultará el ganador no está claro para mí, pero sospecho que el factor decisivo será la valoración de los usuarios sobre el grado de confianza que requiere cada opción. Y puesto que toda la atracción de la tecnología blockchain proviene de que permite a los usuarios realizar transacciones requiriendo de un mínimo grado de confianza, yo diría que el resultado de esa valoración será el realmente válido.

¡Gracias por leer este texto! Si te ha gustado este artículo, asegúrate de leer la siguiente parte de la serie, que comparará la forma en que Ardor y Ethereum gestionan el crecimiento desmesurado de la blockchain.


Prueba Ardor en la testnet

Acerca de la última versión lanzada de Ardor para la testnet

Ardor Frente a la competencia, Parte 6: Komodo/SuperNET

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 Komodo, la plataforma blockchain que conforma la base de Supernet.

SuperNET

Al igual que sucede con Waves, SuperNET fue fundado por una persona que fue muy activo en la comunidad Nxt en el pasado. Y tal y como hice en mi artículo sobre Waves, no voy a entrar en este tema en este artículo.

Es suficiente con decir que James/jl777 era desarrollador de SuperNET, el Multigateway y varios otros proyectos en Nxt, incluyendo un determinado número de activos en el Intercambio de Activos de Nxt, pero que abandonó la comunidad Nxt durante el turbulento periodo de finales de 2015 y comienzos de 2016. Desde entonces, ha creado la plataforma Komodo, que ahora funciona como elemento base de SuperNET.

La visión de SuperNET es permitir que los usuarios realicenr transacciones de forma sencilla entre diferentes tipos de criptomonedas, para disfrutar de todas las ventajas de cada moneda. Por ejemplo, si lo he entendido correctamente, una aplicación de SuperNET podría permitir que los usuarios realizasen transacciones privadas con Bitcoin, siendo convirtida desde y hacia una moneda privada como Komodo en segundo plano. Desde el punto de vista del usuario, sería como si Bitcoin hubiese “tomodo prestada” la función de privacidad de Komodo.

Supernet en si mismo no es una blockchain. En cambio, es una estructura compuesta de varios componentes. Sus principales partes son:

  1. Komodo, una blockchain ligada a Bitcoin;
  2. assetchains y geckochains, blockchains independientes ligadas a Komodo;
  3. el monedero Agama, un monedero multimoneda;
  4. BarterDEX, un exchange descentralizado (DEX) que será integrado en el monedero Agama;
  5. Iguana, el código base sobre el que se cimienta el monedero de Agama y parte de Komodo.

Hay que mencionar que muchos de los textos sobre SuperNET hacen referencia al monedero de Agama como monedero Iguana, puesto que este era su nombre anterior.

El proceso de anclaje de los elementos 1 y 2 es el algoritmo de consenso delayed proof-of-work (Prueba de Trabajo Diferida) de Komodo, que describo a continuación. Hablaré de BarterDEX más adelante.

Prueba de Trabajo Diferida

Komodo es un fork de zCash, una blockchain que usa el algoritmo zero-knowledge proofs o de prueba de conocimiento-cero (via zk-SNARKs) para permitir que los usuarios realicen transacciones sin revelar sus números de cuentas al exchange. Komodo ha añadido varias características a su ramificación del código base de zCash, incluyendo el algoritmo de Prueba de Trabajo Aplazada (dPoW), así como un mecanismo para la creación de blockchains adicionales que son ancladas periódicamente a la cadena de Komodo.

El white paper del dPoW afirma que el mecanismo del dPoW permite que cualquier blockchain se asegure a sí misma usando el hashpower de Bitcoin, gracias a que periódicamente se certifican ante Bitcoin. En pocas palabras, el consenso en las blockchains más débiles tiene lugar en dos fases: un consenso inicial siguiendo los métodos tradicionales (por ejemplo con PoW o PoS) y una segunda capa de consenso establecida periódicamente por una serie de nodos notarios, elegidos por los partícipes, que almacenan un hash de los bloques de las cadenas débiles en la blockchain de Bitcoin. Todos los nodos en la red están de acuerdo en que, en caso de fork, no reorganizarán la blockchain a un estado anterior previo al que el que fue certificado usando Bitcoin.

Sostiene el autor que de esta manera, la blockchain más débil hereda algo de la seguridad de Bitcoin. Incluso un atacante que contase con la mayoría del haspower de la red no podría modificar la blockchain más allá del último bloque certificado. Del mismo modo, alguien que espere hasta que una transacción en la blockchain más débil sea certificada en Bitcoin puede estar seguro de que no será revertida.

El white paper también propone un mecanismo para permitir que la red vuelva a su mecanismo inicial de consenso en caso de que un nodo que actúe como notario no esté disponible. La idea es que todos los nodos en la red tienen la posibilidad de minar, pero a los nodos notario se les asigna una dificultad menor que a los nodos normales. Como resultado, los nodos notario ganarán normalmente la mayoría de los bloques, pero si un atacante consiguiese de algún modo desactivarlos (con un ataque DDoS, por ejemplo) los nodos normales podrían continuar minando bloques y la blockchain continuaría su funcionamiento sin interrupción, solo que sin la seguridad adicional proporcionada por Bitcoin. De esta manera, la cadena dPoW es de algún modo menos centralizada de lo que parece en un primer vistazo.

Esta serie de razonamientos nos lleva a preguntarnos que es exactamente lo que se gana con el mecanismo de notarización/certificación. En particular, si un atacante es capaz de obtener el control de los nodos notario, puede evitar que estos firmen las transacciones Bitcoin que certifican los bloques de las cadena más débiles, obligando a la blockchain más débil a depender únicamente de su mecanismo de consenso inicial. Así que parece que la seguridad extra ofrecida por el proceso de certificación depende implícitamente en la existencia de una mayoría de nodos notario honestos.

[EDICIÓN: Tras hablar con jl777, he descubierto que Komodo permite que una minoría de los notarios (13 de 64) firmen cada transacción de certificación. Esto, a su vez, reduce las tasas de Bitcoin que deben pagarse y hacen más difícil el ataque expuesto, puesto que un atacante tendría que controlar la gran mayoría de los nodos para vencer al mecanismo de notarización. Mis afirmaciones originales estaban basadas en lo que escribió en el whitepaper del dPoW, el cual sugiere que 33 de los 64 notarios deben firmar las transacciones de certificación.]

Esto es básicamente el modelo de seguridad de las blockchains basadas en el modelo de Prueba de Participación Diferida (delegated proof-of-stake – DPOS) como Bitshares. Tanto en DPoW como en DPoS, los usuarios votan en función de su saldo (stake) en favor de una serie de cuentas “especiales” de las cuales depende la seguridad del resto de la red. Ambos sistemas también sufren las mismas debilidades: una responsabilidad para los usuarios para mantenerse al día con los temas “politicos” del sistema para saber que cuentas son lo suficientemente confiables y merecen ser votadas, y la consiguiente apatía del votante que produce esta responsabilidad.

Con todas estas consideraciones, creo que no le veo mucho sentido al dPoW sobre otras alternativas. Si el mecanismo de consenso inicial de la cadena más débil es lo suficientemente seguro para protegerlo, dado su actual valor económico, entonces pagar Bitcoin para certificarlo parece un derroche de dinero. Por otro lado, si el consenso inicial no fuese suficiente, entonces parece que la seguridad del resto de la cadena depende de la elección de notarios honestos. Pero, en ese caso, ¿Por qué no utilizar DPOS y beneficiarse del mejorado rendimiento de las transacciones que las cadenas DPOS ya han alcanzado?

Dejando de lado estas consideraciones, no hay que pasar por alto el hecho de que la plataforma Komodo usa cadenas dPoW anidadas para ayudar a conseguir el objetivo de SuperNET de conectar diversas blockchains diferentes. Las cadenas adicionales de Komodo se llama assetchains” y “geckochains. Estas cadenas se certifican a si mismas ante Komodo, quien a su vez se certifica ante Bitcoin. De nuevo se afirma que todas las cadenas involucradas heredan el nivel de seguridad de Bitcoin pero, tal y como se describe más arriba, buena parte de esto depende de los nodos notario de cada cadena.

A diferencia de los activos en Nxt y Ardor, o incluso en las child chains de Ardor, las cadenas de activos (assetchains) de Komodo son blockchains completamente independientes. Su única conexión con las cadenas de Komodo es el mecanismo de certificación dPoW. De esta manera, quizá se encuentren más próximas a las cadenas lateras que proponen Lisk y Stratis que a las férreamente dependientes child chains de Ardor.

Las geckochains son como las assetchains pero con soporte para contratos inteligentes. No he encontrado muchos detalles sobre las geckochains, y no parece que estén disponibles todavía, pero el cliente de Komodo ya soporta las assetchains a través de una interfaz de línea de comandos.

BarterDEX

El exchange descentralizado de SuperNET, llamado BarterDEX, permite a los usuarios realizar transacciones atómicas entre blockchains sin tener que depender en la confianza en terceros. El equipo todavía no lo ha integrado en la interfaz de usuario del monedero Agama pero ya están trabajando en ello. Mientras tanto, BarterDEX puede usarse por separado.

BarterDEX consiste en tres componentes principales: un juego de nodos designados para encontrar órdenes coincidentes; una serie de nodos “proveedores de liquidez”, que actuarán como creadores de mercado; y un protocolo para que los usuarios intercambien entre sí monedas de diferentes blockchains en una única operación atómica.

Los nodos para encontrar órdenes coincidentes funcionan del mismo modo que en Waves: se encargan de centralizar parcialmente las órdenes de compra y venta para ofrecer una experiencia de usuario más atractiva. De este modo, los traders no tienen que esperar al siguiente bloque en las blockchains en cuestión para saber si sus órdenes se han ejecutado o si deben cancelar una orden.

Los nodos Proveedores de Liquidez (Liquidity provider – LP) mantienen los saldos de al menos dos de las monedas soportadas y automáticamente comercializan con ellas con un margen de beneficios que es definido por el usuario, relativo a un exchange centralizado. Por ejemplo, es posible estable un nodo LP que tradee BTC y KMD en BarterDEX a la vez que en Bittrex. Los operadores de los nodos LP asumen el riesgo asociado con poseer fondos en un exchange centralizado, a cambio de beneficiarse de las oportunidades de arbitraje entre los dos mercados. El resto de usuarios de BarterDEX, por su parte, obtienen mayor liquidez y menores diferenciales entre las órdenes bid y ask que si no contaran con este servicio, sin tener que dejar sus monedas en un exchange centralizado.

Cuando la orden de un usuario se completa, posiblemente con una orden emitida por un nodo LP, BarterDEX usa un protocolo de canjeo atómico entre cadenas para fijar fijar la operación en las dos blockchains involucradas. Probablemente los detalles variarán dependiendo del par de monedas en cuestión, pero conceptualmente el proceso es similar en todos los casos. Se supone que una blockchain es compatible con Bitcoin o, como mínimo, soporta el equivalente a los Contratos de Ejecución Retardada Hasheados (Hashed timelocked contracts – HTLCs) de Bitcoin. La otra blockchain tiene que soportar 2 de 2 transacciones multifirma del tipo 2 de 2 (2-of-2 multisign).

Supongamos que Bob quiere tradear sus fondos en una cadena compatible con Bitcoin a cambio de las monedas de Alice en otra cadena. Tanto Alice como Bob crean un par de clave pública / clave privada y los hashes de las claves privadas. Alice envía a Bob una transacción multifirma 2 de 2 que él puede gastar una vez que conozca ambas claves privadas, momento en el que Bob enviará a Alice una transacción del tipo timelocked que Alice puede gastar cuando revele su clave privada. Una vez lo haya hecho, Bob la usará para desbloquear su transacción multifirma y la operación se completará.

El protocolo añade un poco de complejidad para proteger a cada parte en caso de que la otra parte cancele el procedimiento anticipadamente. Si Alice se va sin gastar la transacción que envió Bob, Bob puede recuperar sus fondos una vez que el bloqueo temporal sobre esa transacción caduque, utilizando tan solo su clave privada para ello. Por otro lado, para proteger a Alice del mismo riesgo, el protocolo requiere que Bob emita un “depósito” inicial en forma de transacción hasheada retardada. Si abandona antes de pagar a Alice, ella puede esperar a que cumpla el plazo del timelock sobre este depósito para recuperarlo.

Admito que esto solo es una visión superficial del protocolo de canjeo automático, pero espero que sirva para darte una idea de cómo funciona. La parte más importante aquí es que no existe ningún exchange centralizado para facilitar la transacción. Alice y Bob han intercambiado monedas en diferentes blockchains sin tener que confiar en la otra parte o en algún intermediario. Puedes encontrar más detalles sobre este proceso en el white paper de BarterDEX.

Comparado con Ardor

Entonces, ¿qué podemos hacer con Komodo y SuperNET? Esta cuestión depende en gran medida de si el algoritmo de prueba de trabajo diferida de Komodo ofrece un grado sustancial de mejora de la seguridad para Komodo y sus assetchains. Desde mi punto de vista, no lo consigue: ofrece aproximadamente el mismo grado de seguridad que el algoritmo de prueba de participación diferida, aún en el caso de que la blockchain notario fuese perfectamente inmutable.

Con esto en mente, las assetchains de Komodo se parecen mucho a las side chains desplegables por el usuario que tanto Lisk o Stratis pretenden ofrecer. En los tres proyectos, a diferencia de las child chains de Ardor, cada assetchain o sidechain es responsable de su propia seguridad. Sin embargo, Komodo parece tener ventaja sobre tanto Lisk como Stratis en términos de funcionalidad, puesto que los usuarios ya pueden desplegar sus propias assetchains y realizar transacciones de canjeo atómicas entre algunos pares.

Hay que darse cuenta de que las child chain de Ardor almacenan los hashes de sus bloques en la cadena de Ardor, de forma semejante a como Komodo almacena los de sus bloques en Bitcoin, pero hay una diferencia crucial: los nodos forjadores de Ardor validan todas las transacciones de todas las child chains. Cada child chain hereda de manera efectiva todo el poder de forja de la cadena de Ardor, convirtiéndolas en tan seguras como lo es Ardor y obviando la necesidad de mineros o forjadores separados.

Sobre los canjeos atómicos entre cadenas, Ardor y Komodo presentan mayores diferencias. Ardor soporta de manera nativa transacciones entre las child chains y también entre cada child chains y la cadena madre. Además, soporta un tipo de transacción por fase que es equivalente a la multifirma 2 de 2, permitiendo los mismos tipos de canjeos atómicos con las blockchains compatibles con Bitcoin que permite BarterDEX. Ardor incluso añade la capacidad de combinar múltiples operaciones condicionadas con los operadores booleanos AND, OR y NOT, permitiendo potencialmente a los usuarios a crear el equivalente a las Transacciones de Ejecución Retardada Hasheadas. Usando el enfoque de BarterDEX, esta característica podría permitir los canjeos atómicos entre cadenas hacia cualquier blockchain que soportase multifirma 2 de 2.

Conclusión

La visión de SuperNET sobre las blockchains interconectas presenta mucho atractivo, y con la combinación de la plataforma Komodo, el monedero Agama y el exchange BarterDEX, Supernet ha hecho un gran progreso para materializar ese objetivo. Aunque soy escéptico acerca de que el algoritmo de prueba de trabajo diferida ofrezca un grado sustancial de seguridad adicional a Komodo y a sus assetchains, la capacidad de desplegar rápidamente una assetchain pone a Komodo, como mínimo, por delante de Lisk y Stratis en su carrera para crear una plataforma funcional con cadenas laterales. Además, encuentro que tiene mucho valor la capacidad de realizar canjeos automáticos entre cadenas usando BarterDEX.

Aún así, no puedo evitar pensar si existe en el corazón de SuperNET una tensión fundamental entre dos de sus objetivos. Por un lado, pretende integrar las mejores características de blockchains muy dispares entre sí, ofreciendo a los usuarios y desarrolladores una manera impecable de disfrutar de las ventajas exclusivas que cada cadena ofrece. Por otro lado, ofrece a Komodo como una única plataforma para solucionar la mayoría de los problemas, permitiendo las transacciones privadas, cadenas laterales creadas por los usuarios y, en el futuro, contratos inteligentes. El éxito en cualquiera de estos objetivos parece que obstaculizará conseguir el resto.

Ardor, por su parte, también tiene una visión atractiva, y quizá sea una visión más coherente: soportar una multitud de negocios y proyectos en sus child chains, ofreciendo a cada uno de ellos una serie de características listas para su uso, permitiendo que cada una de ella interactúe con el resto y evitar que ninguna de ellas se tenga que preocupar por su seguridad o por almacenar el historial de transacciones del resto. Ardor ya ofrece ya la mayoría de la tecnología para materializar esta visión. Sólo falta que los negocios, desarrolladores y los usuarios le den buen uso a esta tecnología.


Prueba Ardor en la testnet

Ardor Frente a la Competencia, Parte 5: Stratis

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 Stratis, una plataforma blokchain-como-servicio basada en el protocolo Bitcoin.

Stratis

El objetivo del proyecto Stratis es permitir a las empresas crear sus propias blockchains a medida, partiendo de una serie de funciones predefinidas. Además, el Grupo Stratis, el cual dirige el desarrollo de Stratis, ofrecerá servicios de consultoría para ayudar a los negocios a encontrar formas de usar la tecnología blockchain de manera efectiva, a la vez que, presumiblemente, también les ayudará a desplegar blockchains a medida en la plataforma Stratis.

Presentado de esta manera, Stratis aparenta ser muy parecido a Ardor. Pero la observar la mayoría de lo pormenores (al menos con los detalles disponibles públicamente sobre Stratis) las dos plataformas presentan diferencias significativas. En breve las exponemos.

Actualmente, la plataforma Stratis está compuesta de varias partes:

  • NBitcoin, una implementación integral de Bitcoin en C# inspirada en Bitcoin Core;
  • NStratis, un fork de NBitcoin que incorpora un algoritmo de minado de Prueba de Participación y un algoritmo alternativo de Prueba de Trabajo;
  • el Nodo completo Bitcoin de Stratis, que puede funcionar tanto en la red de Bitcoin como en la de Stratis, que sirve de base para el resto de la plataforma;
  • el Monedero Breeze, un monedero con verificación simplificada de pagos (simplified payment verification – SPV) tanto para Bitcoin como Stratis que implementa TumbleBit para convertir en privadas las transacciones; y
  • el módulo de Identidad de Stratis, que permite a terceras partes comprobar la identidad de la persona que controla una cuenta de Stratis.

Hay que apuntar que la mayoría de estos componentes todavía están en fase alfa.

En la lista hay que destacar especialmente la integración de TumbleBit en el Monedero Breeze. El Documento Técnico de TumbleBit es bastante denso; si estás interesado en los detalles, recomendaría leer en su lugar esta excelente presentación elaborada por dos de los autores. En pocas palabras, TumbleBit utiliza canales de pago unidireccionales para transferir los fondos desde una serie de pagadores hacia un intermediario llamado Tumbler, y desde el Tumbler a una serie de receptores, sin que ninguna de las partes tenga que depositar su confianza en la otra. El elemento diferencial sobre otras implementaciones de sistemas de pago es que TumbleBit usa firmas ciegas RSA de una manera inteligente, de manera que se evita que el Tumbler sepa que transacción entrante se corresponde con una determinada transacción saliente. Si muchas cuentas realizan transacciones usando el Tumbler entonces es imposible trazar la relación entre una cuenta receptora y la cuenta emisora que los envió. Ni siquiera el Tumbler puede enlazar ambas cuentas.

El Monedero Breeze de Stratis ofrece la funcionalidad TumbleBit tanto para Bitcoin como Stratis, haciéndolo útil para una audiencia mucho mayor que si solo se pudiese utilizar en la red de Stratis. Además, puesto que el protocolo TumbleBit utiliza un canal de pagos fuera de cadena (off-blockchain), es posible realizar muchos pagos usando el Tumbler en aproximadamente la misma cantidad de tiempo que tomaría realizar un solo pago.

El módulo de Identidad de Stratis está todavía en un estado de prueba de concepto, pero pese a ello ya es funcional. Los usuarios pueden acceder a sus cuentas de Microsoft, Google o LinkedIn usando la aplicación móvil de Identificación de Stratis y estos servicios notificarán a Stratis del inicio de sesión realizado. Una cuenta especial, propiedad de Stratis, almacenará la confirmación de este inicio de sesión creando un hash con la información de identificación personal (por ejemplo, nombre y dirección de email) y almacenándolo en la blockchain de Stratis.

La confirmación por parte de Google de que una persona posee una determinada cuenta de Gmail puede que no sea el servicio de identificación más práctico, pero es sencillo ver como el mismo mecanismo podría ser usado para demostrar la propiedad de una determinada información que sea mucho más difícil de verificar. Por ejemplo, un agente del gobierno podría confirmar que alguien ha presentado un documento de identificación con su foto, junto a un nombre y una dirección. Si el usuario puede proveer su nombre y una dirección de manera que concuerda con el hash presente en la blockchain, eso también podría convencer a un proveedor de servicios de que el usuario posee el correspondiente identificador con foto, puesto que el agente del gobierno ya ha confirmado anteriormente esas 3 porciones de información conjuntamente.

La integración de TumbleBit en el monedero Breeze y en el módulo de Identidad de Stratis son dos ejemplos de este tipo de características que Stratis pretende ofrecer en la plataforma. No estoy seguro de haber entendido completamente el funcionamiento de la arquitectura de Stratis pero, por lo que puedo entender, la idea es que la blockchain de Stratis delegue los procesos en segundo plano para cada nueva característica, tales como TumbleBit y la Identidad de Stratis, a un juego dedicado de nodos (masternodes). Por ejemplo, el futuro Nodo Breeze (no confundir con el monedero Breeze, el cual utiliza SPV en lugar de necesitar un nodo completo) será un masternode que dará servicio a Tumbler. De forma similar, existen planes para construir masternodes que procesen las transacciones de Identidad de Stratis, aunque no se realmente lo que esto significa y no puedo encontrar más detalles sobre ello.

En último lugar, es necesario mencionar que el equipo de Stratis ha planeado varias características más, siendo la más destacada el despliegue de cadenas laterales ancladas a la cadena de Stratis. Según lo entiendo, este será el principal mecanismo con el que Stratis para ofrecer a los clientes blockchains privadas y personalizables.

Desafortunadamente, no he sido capaz de encontrar más detalles acerca de como funcionarán las cadenas laterales en Stratis. El  whitepaper de Stratis hace referncia al Documento Técnico sobre Blockchains de Blockstream, pero esa es la única pista que he encontrado hasta ahora sobre el diseño de Stratis. Particularmente, creo que no es tan fácil asegurar y transferir valor entre dos blockchains sin tener al menos algunos mineros en cada cadena para validar todas las transacciones en ambas cadenas. Los detalles, incluyendo cómo el protocolo de la cadena lateral gestiona los forks y las reorganizaciones, son cruciales para poder valorar la seguridad de este mecanismo.

Incluso suponiendo que las transferencias entre la cadena de Stratis y las cadenas laterales son seguras, todavía queda pendiente el asunto de la seguridad de las mismas cadenas laterales. El Documento Técnico de Stratis afirma numerosas veces que la cadena de Stratis proveerá, de alguna manera, seguridad para sus cadenas laterales, pero no explica como lo hará. Típicamente, las cadenas laterales son completamente independientes y deben asegurarse por si mismas.

Comparación con Ardor

En Ardor, por su lado, la cadena madre (parent chain) es la que ofrece la seguridad para cada cadena hija (child chain)

En realidad, esta es una de las diferencias más importantes entre la arquitectura cadena madre / cadena hija de Ardor y las típicas implementaciones de las cadenas laterales. Desafortunadamente, sin más información técnica por parte del equipo de Stratis, es imposible de llevar acabo una comparación adecuada entre su diseño y el modo en que es enfocado por parte de Ardor.

Una comparación que podemos establecer es entre la característica TumbleBit de Stratis y la característica de Coin Shuffling de Ardor. (Nótese que el Coin Shuffling no estará disponible en la misma cadena de Ardor, sino que estará disponible en Ignis, su primera child chain, así como en todas aquellas child chains que quieran implementarlo) Esta característica es la implementación de Nxt del algoritmo de mezclado de monedas, que permite a un grupo de usuarios transferir una cantidad determinada de monedas desde sus cuentas (entrada) a una serie de cuentas de salida, una por cada entrada, sin tener que confiar en el resto ni saber quien de estos usuario controla cada cuenta de salida. El algoritmo no es muy complicado y la sección 4.2 del Documento Técnico ofrece una buena visión general de como funciona.

No soy ningún experto en ninguno de los algoritmos, pero el planteamiento de TumbleBit parece tener un par de ventajas sobre el CoinShuffle. Dado que usa canales de pago off-blockchain, es potencialmente capaz de escalar hasta un mayor ratio de transacciones, además de añadir una medida de privacidad a los pagos, solventando dos problemas a la vez. Además, si el objetivo es evitar que un observador identifique la relación entre varios pagos (lo que podría filtrar informaciones sobre los clientes de un determinado negocio o de una cadena de suministro, por ejemplo), probablemente sería más conveniente hacer los pagos fueran retornados a la misma cuenta a través de TumbleBit en lugar de tener primero que mezclar cada pago a una nueva cuenta.

Sobre el tema de las verificaciones de identidad, creo que el módulo de Identidad de Stratis es una interesante prueba de un concepto, pero en mi opinión Ardor ofrece un juego de herramientas más amplio para los servicios relacionados con la identificación. Mientras que un servicio como el de Identidad de Stratis puede ser construido con facilidad en cualquier blockchain, Ardor ofrece un par de características únicas que podrían extender este servicio para ofrecer algunas aplicaciones interesantes.

En Ardor, los validadores de identidad serán capaces de confirmar el propietario de una cuenta a través de las Propiedades de Cuenta. Esto son bits de datos arbitrarios que pueden ser permanentemente asociados con una cuenta en la blockchain, de modo semejante a las confirmaciones en el módulo de Identidad de Stratis. Una característica novedosa que traerá Ardor es la habilidad de emitir activos que solo podrán ser intercambiados entre aquellas cuentas que cuenten con una determinada propiedad de cuenta.

En los casos en que las regulaciones del gobierno requieran que los emisores de activos necesiten saber quién ha comprado sus activos, esta características permitirá a los emisores restringir el intercambio de los activos en sus cuentas con otras cuentas en la que la identidad de sus propietarios haya sido convenientemente verificada por los proveedores de identidad establecidos. Este nivel de control podría ayudar a que las acciones lanzadas en la blockchain cuenten con un fundamento legal más firme y ayuden a los emisores a cumplir apropiadamente con la legalidad.

Aún sin cumplir con las normas regulatorias, los emisores de activos puede que encuentren otros usos para esta característica. Por ejemplo, un club u organización privada podría expresar los requerimientos para acceder a la membresía de un club como una serie de requisitos en las propiedades de cuenta, emitir un activo que solo unas cuentas elegibles pueden obtener y después usar el activo para pagar dividendos o para lanzar encuestas entre sus miembros.

Algunas Reflexiones sobre el Marketing

Incluso aunque hayas leído hasta aquí, puede que todavía te estés preguntando qué es exactamente la plataforma Stratis y cómo va a funcionar. Para ser honesto, yo mismo me he planteado estas cuestiones también, incluso tras dedicar muchas horas a estudiar Stratis. Con riesgo de hablar en el límite de mis posibilidades, creo que sería útil comparar y contrastar los esfuerzos de marketing de Jelurida y del Grupo de Stratis para arrojar algo de luz sobre por qué es tan difícil para mí responder a estas cuestiones tan básicas.

Al leer la web de Stratis y su white paper (enlazado más abajo), francamente tengo la impresión de que estos recursos no estaban realmente escritos para mí. El lenguaje que utilizan me recuerda al de los comerciales de mi empresa, y hace mucho descubrí que los ingenieros y el personal de ventas tienden a no entenderse del todo bien.

Leo que Stratis ofrece “sencillas y asequibles soluciones de extremo extremo” para “agilizar y acelerar el desarrollo de proyectos blockchain“; que es una “potente y flexible plataforma de desarrollo blockchain para cubrir las necesidades reales de los negocios y otras organizaciones que pretenden desarrollar, testear y desplegar aplicaciones en la blockchain“; y que su “arranque con un click implica que las nuevas cadenas pueden ser lanzadas con una velocidad sin precedentes, ajustadas a las necesidades del negocio”; pero todavía no entiendo realmente lo que significan todas estas cosas, y aún menos cómo Stratis las va cumplir.

Este tipo de lenguaje no ofrece información de valor para mí. Sin detalles técnicos, estoy completa y desesperadamente perdido. No obstante, se que hay mucha gente que se desenvuelven en este lenguaje de negocios y que estas personas probablemente podrían leer el white paper de Stratis y abstraer de una manera decente, o incluso muy decente, una idea concreta  de lo que la compañía plantea hacer. En cambio, yo tuve que leer el white paper múltiples veces antes de que pudiese comprender la idea, y no estoy completamente seguro de que lo haya conseguido.

Por su parte, el white paper de Ardor contiene detalles técnicos sobre cómo funciona Ardor y qué lo distingue de otras plataformas blockchain. Es obvio al observar tanto el contenido como la forma en que está organizado, que los ingenieros han jugado un papel importante a la hora de escribirlo. Cuando terminé de leerlo por primera vez, entendí con claridad los problemas que Ardor soluciona y cómo los soluciona.

A donde quiero llegar con esta comparación es que las personas con mentalidad de negocios y las personas con mentalidad técnica a menudo no hablan el mismo lenguaje y los materiales de marketing que presentan el Grupo Stratis y Jelurida parecen reflejar estas diferencias. Personalmente, me resultó frustrante encontrar tan poca información técnica entre los recursos de Stratis. Y esta frustración probablemente haya evitado que yo pudiese comprender completamente Stratis

Conclusión

¿Es mi análisis de Stratis demasiado duro? Quizá. Realmente creo que TumbleBits es una solución tecnológica interesante y me parece inteligente que el monedero Breeze lo implemente tanto para Stratis como para Bitcoin. Además, si nos olvidamos de los contenidos del white paper que dicen que la cadena de Stratis será la encargada de asegurar a sus cadenas laterales y en su lugar asumimos que cada cadena lateral será la responsable de su seguridad, entonces puedo usar mi imaginación para interpretar las lagunas y conseguir formarme una imagen mental de lo que Stratis será cuando esté completado.

No obstante, en esta imagen mental Stratis será básicamente un competidor de Lisk. Por supuesto que Stratis está basado en .NET y en el protocolo Bitcoin en lugar de en JavaScript y en los tipos de transacciones predefinidas de Lisk. Y el conjunto de características que ambos equipos pretenden ofrecer no son completamente iguales pero, en esencia, ambos proyectos pretenden ofrecer una blockchain pública central junto a una serie de herramientas para la creación de cadenas laterales en ella. Además, ambos proyectos están en fases bastante iniciales de desarrollo y esta puede ser la razón por la que no hay mucha información técnica disponible.

Ardor es bastante diferente. Construido usando el código base de Nxt, es mucho más maduro que Stratis, aún a pesar de no haberse lanzado todavía en la main net. Su arquitectura de cadena madre / cadena hija consigue el objetivo indicado en el Documento Técnico de Stratis (una forma de que los negocios puedan crear sus propias blockchains personalizadas sin tenerse que preocupar por su seguridad) mejor que las soluciones basadas en arquitecturas de cadenas laterales. Y alcanzar la rica variedad de características que ya soporta Ardor todavía le llevará bastante tiempo a Stratis.

Quizás también sea importante destacar que tanto Jelurida como la comunidad Nxt han hecho un gran trabajo para ofrecer públicamente información técnica sobre Nxt y Ardor. Esta información otorga gran credibilidad al proyecto de Ardor y fortalece la comunidad. En mi opinión, esto es lo que diferencia al marketing verdadero de la mera publicidad.


Prueba Ardor en la testnet

Ardor Frente a la Competencia, Parte 4: Waves

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:

Hasta este momento, uno de mis principales objetivos en esta serie ha sido analizar las diferentes enfoques para permitir escalara a la tecnología del Libro de Cuentas Distribuido. Sin embargo, esta semana y las dos próximas entregas me centraré en la vertiente empresarial de la tecnología blockchain. Voy a intentar explorar los problemas del mundo real que las blockchains permiten solucionar y la manera en que diferentes proyectos blockchain se han posicionado para encajar en este objetivo de mercado.

Estos temas se salen un poco de mi zona de confort, así que os agradezco vuestra paciencia en caso de que diga algo incorrecto o ingenuo. Y, cómo siempre, agradeceré vuestras críticas constructivas 🙂

El anterior descargo de responsabilidad es especialmente importante esta semana, porque esta semana he analizado Waves. Como recién llegado a Nxt que soy, he leído lo suficiente sobre su historia para saber que el fundador de Waves, Sasha Ivanov (alias Coinomat en nxtforum.org), había sido un miembro activo de la comunidad Nxt hasta el periodo turbulento que tuvo lugar a comienzos de 2016, momento en que se fue para crear Waves. No voy a intentar relanzar el debate sobre Ardor y el futuro de Nxt, el cual entiendo que finalizó cuando muchos emisores de activos como Sasha dejaron la comunidad, pero en caso de que estéis interesado, os recomendaría leer el resumen que hizo apenzl en SNAPSHOT y las referencias que allí se pueden encontrar.

En cambio, en este artículo voy a ignorar en la medida de lo posible la historia entre Nxt y Waves y voy a aproximarme a ambos proyectos con la mente abierta y una visión de futuro. Creo que habría cierto valor en un análisis histórico detallado, pero simplemente no estoy capacitado para ello.

Una vez dicho esto, vamos a hablar sobre Waves.

Waves

En un primer vistazo, Waves aparenta ser una versión básica de Nxt. Es básicamente un exchange descentralizado (DEX), inspirado y conceptualmente similar al Intercambio de Activos de Nxt (Nxt Asset Exchange). Al igual que Nxt, usa el algoritmo de Prueba de Participación (Proof-of-stake) para el consenso y permite a los usuarios ceder su saldo a otras cuentas para forjar en grupo (forging pools). Recientemente ha añadido un modo para asociar un alias inteligible por humanos a un número de cuenta, replicando parcialmente la funcionalidad del Sistema de Alias de Nxt (Nxt’s Alias System). Incluso un par de características que se encuentran todavía en desarrollo (un sistema de votación y un modo para enviar mensajes encriptados) duplican funciones que Nxt ya ofrece.

Al mismo tiempo, Waves carece de muchas de las características más poderosas con las que cuenta Nxt. Por el momento, no cuenta con nada similar a las transacciones por fases (phased transactions) u opciones para el control de cuenta, por ejemplo, aunque hay que indicar que tanto los contratos inteligentes como la multifirma de transacciones están en la agenda.

Adicionalmente, el white paper sugiere que el micromecenazgo (crowdfunding) será uno de los primeros usos para la plataforma Waves, aunque los tokens en Waves carecen de las propiedades de personalización que convierten al Sistema Monetario de Nxt en algo muy útil para estos usos. Por ejemplo, el Sistema Monetario ofrece la posibilidad de transferir los fondos cuando se ha alcanzado el objetivo de financiación, al estilo Kickstarter, y también la posibilidad de restringir el trading para evitar que los especuladores creen un mercado secundario. Al usar esta última característica, llamada moneda “Controlable” en la terminología de Nxt, es incluso posible que los emisores establezcan tanto un precio fijo de compra cómo de venta, permitiéndoles ofrecer a los compradores un reembolso parcial por sus tokens. Por contra, el crowdfunding en Waves está limitado a la emisión de un token a precio de mercado.

No obstante, en mi opinión sería un grave error descartar Waves o cualquier otra copia de Nxt que contase con menores características. Por una sencilla razón, Waves ofrece varias características clave que Nxt y otras plataformas no tienen, las cuales describiré a continuación. Quizá el más importante incluso sea que el equipo de Waves ha creado una marca sólida y ha ofrecido una visión clara y consistente desde el arranque de la plataforma. El campo está actualmente tan saturado, y las innovaciones se producen a tanta velocidad, que la combinación de un mensaje sencillo y claro con un fuerte esfuerzo en marketing y una habilidad demostrada para entregar lo que prometen puede llegar a ser más importante para el éxito a largo plazo que las muchas o potentes novedades que pueda contener su tecnología subyacente.

Características Únicas

Una característica interesante que diferencia a Waves de otras muchas plataformas es el diseño de su DEX. Es una aproximación híbrida que combina un mecanismo centralizado de concordancia de órdenes de compra y venta, llamado the Matcher, con asientos descentralizados en la blockchain de Waves.

Cuando los usuarios ponen sus órdenes en Waves, el cliente de Waves envía estas órdenes a los nodos Matcher, quienes conservan el libro de órdenes para todos los pares comercializados. Cada nueva orden, o bien se empareja frente a una orden existente, o bien es añadida al libro de órdenes para el par en cuestión, pero en cualquier caso el usuario que emitió la nueva orden es notificado de inmediato sobre si su orden se completó. Todavía se necesita esperar hasta el siguiente bloque (o bloques) en la blockchain para que la transacción quede completamente confirmada, pero durante ese tiempo el usuario sabe con un alto grado de certeza cual ha sido el resultado de su orden.

Esto puede no parecer como una gran mejora respecto a un exchange completamente descentralizado, pero a partir de un puñado de transacciones que he ejecutado en Waves he de decir que la experiencia de usuario me ha impresionado. La posibilidad de ver un libro de órdenes con actualizaciones en tiempo real y saber inmediatamente si mis órdenes han sido ejecutadas supone una diferencia mayor de la que esperaba.

En principio, cualquier nodo completo puede convertirse en un Matcher. No obstante, el cliente ligero actualmente solo se conecta por defecto a los Matchers en nodes.wavesnodes.com, así que es posible que los Matchers del resto de la red no vean mucho volumen. Con las nuevas órdenes siendo transmitidas directamente a estos nodos centralizados, siendo sólo transmitidas al resto de la red en caso de que sean ejecutadas (creo), este diseño permite que el libro de órdenes sea anónimo. No se a ciencia cierta lo importante que es que un libro de órdenes sea anónimo, pero aparenta ser una característica que los traders pueden valorar mucho.

Otra característica diferenciadora de Waves es la habilidad de tradear cualquier token frente a cualquier otro token sin necesidad de convertirlo previamente a WAVES. En combinación con las pasarelas (gateways) integradas que emiten tokens ligados al dólar, euro u otras criptomonedas, esta característica permite que Waves funcione como un mercado de intercambio internacional y descentralizado. También permite que los emisores de activos lancen sus ofertas iniciales directamente en tokens ligados a monedas fiat. Con el cliente completo, es incluso posible pagar las tasas en tokens en lugar de con WAVES.

Adicionalmente, no hay que pasar por alto las otras características que están en desarrollo o en la hoja de ruta, que también diferencia a Waves de otras plataformas. Una de ellas es el sistema de reputación que puntuará a las cuentas en función de su antigüedad, historial de transacciones y otros factores. Todavía no se han desvelado muchos detalles, pero el objetivo es ofrecer a los usuarios al menos una indicación a aproximada sobre la confiabilidad de un emisor de activos. El whitepaper va más allá al sugerir que el sistema de reputación actuará como “una forma de KYC/AML descentralizado” (normativas anti-lavado de dinero y de identificación del cliente). Aunque es difícil ver cómo un sistema de reputación descentralizado podría ayudar a los emisores a cumplir con las normativas KYC/AML, no es descabellado suponer que pudiese funcionar como un sistema análogo para la comunidad blockchain.

Hablando del cumplimiento de requisitos legales, Waves ha anunciado un nuevo proyecto, Tokenomica, que ofrecerá una “estructura 100% legal para diferentes tipos de crowdsales de tokens, incluyendo crowdsales de capital riesgo”. Desafortunadamente, esa cita extraída de la hoja de ruta de 2017 es toda la información que he sido capaz de encontrar sobre Tokenomica. Mi impresión es que el proyecto todavía está en sus fases iniciales, pero muestra que el equipo se está tomando el cumplimiento de las normativas seriamente.

Para terminar, debería mencionar que el equipo de Waves también está planeando incorporar contratos inteligentes (smart contracts) en Waves. El lenguaje de scripting no será completamente compatible con Turing y no habrá equivalente al concepto de gas de Ethereum, probablemente porque no habrá bucles. Más allá de estos detalles, no existe todavía mucha más información disponible.

Finalmente, debo mencionar la propuesta que el equipo de Waves ha esbozado para escalar. Está constituida esencialmente por dos partes: un rediseño del proceso de forjado que trocea los grandes bloques en “microbloques” para optimizar la utilización del ancho de banda; y una optimización de la forma en que los balances de cuenta son almacenados (o, mejor dicho, no almacenados), de manera que se reducen los requerimientos de memoria para los nodos completos.

La primera de estas dos propuestas, llamada Waves NG, está basada en Bitcoin NG. Básicamente, una vez que un nodo se ha ganado el derecho de forjar el siguiente bloque, este emite inmediatamente un bloque clave (key block), que normalmente está vacío, y entonces transmite los microbloques que contienen las transacciones cada pocos segundos. La razón de este diseño es que, al transmitir un gran bloque, el intervalo de bloques es una manera mucho menos eficiente de utilizar el ancho de banda de la red, y los picos correspondientes en la actividad de la red establecen un mínimo inferior en el número de transacciones que la red puede manejar. Al propagar transacciones a través de una secuencia de microbloques, es posible incrementar la tasa media de datos en la red disminuyendo la tasa máxima de datos, reduciendo el efecto que el ancho de banda y la latencia imponen en el ratio máximo de transacciones.

El segundo componente del plan de escalado es implementar las ideas descritas en este artículo de Leonid Reyzin, Dmitry Meshkov, Alexander Chepurnoy y Sasha Ivanov. Admito que no le he dedicado mucho tiempo, pero la idea es que no todos los nodos completos necesitarán almacenar en su memoria los saldos de todos los tokens para validar las transacciones. En su lugar, almacenarán un resumen compactado de esta información y aquellos forjadores que no lo almacenen en su totalidad (o una subserie de ellos, si deciden forjar las transacciones de tan solo un token específico) generarán pruebas criptográficas de que han actualizado los saldos de cuenta correctamente. Los forjadores incluirán a continuación las pruebas y un resumen actualizado en la cabecera de cada bloque nuevo. Aquellos nodos que hayan elegido no almacenar los saldos de todos los tokens involucrados en esas transacciones todavía podrán validarlas usando el resumen actual y las pruebas de los forjadores para calcular y actualizar los resúmenes, la cual podrán comparar frente a la que que anunció el forjador.

Los autores afirman que este método puede dividir por cuatro la cantidad de memoria exigida en condiciones reales por un nodo completo. Además, si esta optimización es capaz de mantener toda la información requerida en memoria en aquellos casos en los que, de otra manera, debería haberse almacenado en el disco, la mejora del rendimiento podría ser mayor, alrededor de 20 veces mejor, según sugiere el autor.

Comparación con Ardor

Aunque un par de las características descritas no estaban disponibles en Nxt, encontramos características similares en Ardor.

Concretamente, la arquitectura de cadena madre / cadena hija (parent-chain / child-chain) de Ardor permitirá a los usuarios tradear cualquier para de monedas de cualquier child chain, algunas de las cuales podrían estar ligadas a monedas fiat u otras criptomonedas. También será posible establecer el precio de los activos en cualquier moneda de las child chains y pagar las tasas en la moneda de una child chain cuando la transacción sea realizada en una child chain determinada. No será posible tradear activos (assets) entre ellos directamente, aunque seguramente muchos de estos pares tendrían tan poco volumen que no valdría la pena añadir esta característica.

Sobre las mejoras que el equipo de Waves ha hecho con su DEX al centralizarlo parcialmente, sería posible imitar esta funcionalidad construyendo un coordinador de transacciones centralizado sobre Nxt/Ardor. De hecho, el proyecto InstantDEX consiguió algo similar en el pasado, usando Nxt para fijar las transacciones de una manera descentralizada.

Respecto al escalado, la propuesta para reducir los requisitos de almacenamiento en memoria para los nodos completos es fascinante, pero me pregunto si se reducirá la seguridad (si habéis leído algún artículo anterior de esta serie, probablemente ya os habréis dado cuenta de que siempre sospecho que las mejoras en rendimiento acarrearán una merma de la seguridad). Concretamente, si los nodos no tienen que almacenar el estado completo de cada cuenta y deben basarse en las pruebas y resúmenes en la cabecera de cada bloque para validar las transacciones que los contienen, entonces asumo que esto significa que los nodos no serán requeridos, ni siquiera serán capaces, de validar las transacciones sin confirmar antes de transmitirlas a los pares. No se que consecuencias puede traer el permitir a los nodos propagar transacciones potencialmente inválidas a la red, pero sólo el pensarlo me deja intranquilo.

El enfoque de Ardor es que todos los nodos validen todas las transacciones, pero que sólo una cantidad mínima necesaria de información sea almacenada permanentemente en el blockchain de Ardor. Concretamente, sólo aquellas transacciones que modifiquen los saldos de ARDR, el token de forja, necesitan ser almacenadas en la blockchain para que otros nodos puedan verificar, sin tener que depositar la confianza en un tercero, que cada bloque fue forjado por una cuenta que realmente podía hacerlo. Por su lado, todo el historial de transacciones de las monedas de cada child chain y los activos y monedas comercializadas en esas child chains no necesita ser almacenado en la cadena de bloques, y por tanto se puede podar, dejando tras de sí tan solo sólo los hashes criptográficos de esa información. El resultado es que que el tamaño de la blockchain permanece reducido y crece más lentamente que si se almacenase toda esa información extra.

Saber qué enfoque es mejor dependerá de si el almacenamiento permanente en la blockchain o el almacenamiento en memoria de los saldos de las cuentas representa un problema mayor conforme las blockchains crecen. No se como responder a esta pregunta pero hay un par de puntos relacionados que habría que remarcar. Uno es que la escala de tiempo de ambos problemas podría ser bastante diferente: Puedo prever una explosión de activos en la plataforma Ardor que podrían ocasionar un estrés en la memoria, mientras que el problema de la hinchazón de la blockchain sería un serio problema a largo plazo para Waves, especialmente si alcanza cientos o miles de transacciones por segundo, que es el objetivo actualmente fijado. Mi otro pensamiento es que Ardor ha requerido de una arquitectura completamente nueva para implementar su solución de escalabilidad, mientras que el enfoque de Waves no. Sin duda, sería más fácil para Ardor incorporar en algún momento la solución aportada por Waves que no que Waves implementara la solución de Ardor.

Finalmente, quizá el tema más interesante de esta comparación es el problema del cumplimiento con las regulaciones. Waves se ha posicionado a si misma como la plataforma para crear y emitir tokens, con una atención especial para el crowdfunding. Tanto es así que el equipo de Waves está mirando con detenimiento todas las normativas que afectan a las campañas de micro mecenazgo (que podría afectar al hecho de vender acciones, por ejemplo) para ayudar a los usuarios a que cumplan con la ley. Mientras que la afirmación de que un sistema de reputación descentralizada pudiese reemplazar a los tradicionales requisitos de cumplimiento con la normativa KYC/AML cuesta de creer, sí que podría al menos ayudar a suprimir las estafas y a reducir las oportunidades para que actores malintencionados se aprovechen de otros. En ese sentido, podría alcanzar algunos de los objetivos que los reguladores pretenden alcanzar.

Ardor, por su parte, ofrecerá un par de mejoras sobre Nxt que pueden ser bastante valiosas para el cumplimiento de la normativa. Una de ellas es la emisión de activos que sólo podrán comercializarse bajo un tipo determinado de transacciones por fases. La otra es la inclusión de las transacciones por fases, que permite a una cuenta aprobar una transacción sólo si la cuenta tiene una propiedad específica. Al combinar estas dos características, un usuario puede emitir un activo que sólo se puede comprar por las cuentas que tienen una propiedad que, por ejemplo, haya sido asignada por un proveedor de servicios de KYC/AML para indicar que se ha verificado la identidad del propietario.

Si tu activo representa acciones de una compañía, o un fondo de inversión u otro tipo de acción, esta característica te permitirá demostrar ante los reguladores que conoces al comprador de tus tokens. Además, si eres un usuario interesado en comprar este tipo de activo, almacenar una prueba de tu identidad en la blockchain usando las propiedades de cuenta posiblemente te permitirá invertir menos tiempo tratando de convencer a los negocios de que tú eres quien dices ser y que no estás lavando dinero.

Además, será posible crear child chains que solo permitirán una subsecuencia de las características que la plataforma Ardor puede ofrecer. Esto permitirá a los creadores de la child chain desactivar ciertas características, como la del mezclado de monedas (coin shuffling), que podría hacer disparar las alarmas de algunos reguladores en determinadas jurisdicciones.

Conclusión

¿Qué hacemos entonces con Waves? Necesariamente debemos destacar el hecho de tomar un problema y tratar solucionarlo mejor que ningún otro antes. No hay duda de que abandonar el planteamiento de “Navaja suiza” que supone Nxt para centrarse en su lugar en el único objetivo de crear una gran plataforma para la comercialización de tokens hizo más sencillo lanzar, desarrollar y sacar al mercado Waves. También influye mucho el contar con una buena financiación, puesto que Waves recaudó $16M en su ICO.

Sin embargo, al mismo tiempo, no estoy seguro de que al realizar una comparación objetiva entre Waves y Ardor podamos concluir que Waves está tan maduro tecnológicamente como Ardor. (Por cierto, he tratado de realizar una comparación justa y objetiva en este artículo, pero no estoy diciendo que lo haya conseguido. Eso es algo que tú tendrás que decidir). Nxt ya es capaz de realizar todo lo que Waves hace, y eso si mencionar todas las cosas que Waves no puede hacer, a las cuales además Ardor también añade nuevas funcionalidades.

Quizá el último gran reto que queda para Ardor es realmente vender su visión de la manera en que la comunidad Bitcoin y la Fundación Ethereum han vendido sus visiones, y aquí es dónde Waves lleva ventaja. Siendo capaz de tantas cosas diferentes, pero no habiendo sido construido específicamente para ninguna en particular, Ardor tiene una ardua tarea por delante. La peor salida posible sería que tanto usuarios como negocios lo viesen como “simplemente otra plataforma blockchain“, o quizá no consiguiesen comprender todo el rango de cosas que puede llegar a hacer, y terminasen por ignorarlo por este motivo.

Respecto a Waves, estoy ansioso por ver lo que el futuro depara. Las mejoras que ha hecho sobre el Intercambio de Activos de Nxt, aunque modestas en mi opinión, la hacen destacar como un DEX formidable. Si el equipo de Waves puede cumplir con su hoja de ruta, Waves será un serio competidor para los exchanges, tanto los centralizados como los descentralizados.

Ardor Frente a la Competencia, Parte 3: IOTA

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 IOTA, un libro de contabilidad distribuido que no utiliza blockchain.

¿Por qué Comparar Ardor con IOTA?

A primera vista, IOTA es tan diferente de Ardor como puede llegar a ser un libro de contabilidad distribuido. Utiliza un grafo acíclico dirigido (Directed Acyclic Graph – DAG), cuyos desarrolladores denominan el “Tangle”, para representar el historial de transacciones, en lugar de almacenar las transacciones en una blockchain. La intención es que se use primordialmente para microtransacciones de máquina a máquina en el Internet de las Cosas (Internet of Things – IoT), una visión motivada por el hecho de que IOTA no tiene tasas por transacción. Y no soporta (todavía) las características de “blockchain 2.0″ que forman parte principal del atractivo de Ardor. A simple vista, no parece que compita con Ardor.

Así que ¿Por qué incluir IOTA en esta serie titulada “Ardor Frente a la Competencia”?

Cómo he mencionado anteriormente, mi principal interés con esta serie es explorar la aproximación que realizan diversos libros de contabilidad distribuidos al escalado y aquí es dónde la comunidad de IOTA ha hecho algunas afirmaciones extraordinarias. Conforme he ido aprendiendo más sobre IOTA para entender mejor como escala, he llegado a la conclusión de que IOTA y Ardor ofrecen soluciones complementarias (o directamente opuestas) al problema del escalado:

Ardor reduce drásticamente el crecimiento desmesurado de la blockchain pero requiere que todos los nodos de la red se pongan de acuerdo sobre el estricto orden de las transacciones; IOTA, por su lado, consigue un resultado mayor relajando para ello las reglas un poco, permitiendo discrepancias temporales entre las transacciones, pero se enfrenta a un reto importante al afrontar el crecimiento del tangle. Estas dificultades, junto a lo que he aprendido sobre la seguridad del tangle, me parecieron lo suficientemente interesantes para dedicarle un artículo en esta serie.

Pero si, a pesar de todo, no estás convencido ¡Vuelve a visitarnos la semana que viene!

Tras este artículo, planeo cambiar mi objetivo desde la escalabilidad hacia las características y el ajuste al mercado. Stratis, Ark y Waves están en la agenda, aunque todavía no estoy seguro del orden en que serán publicadas.

El Tangle

Sin lugar a dudas, la característica más representativa de IOTA es el tangle.

El resto de características únicas de IOTA, tales como la no existencia de tasas por transacción, el hecho de que las transacciones no siguen un orden estricto, aunque sigan siendo consistentes a largo plazo, y la noción de que (un poco de) spam realmente incrementa el rendimiento de la red, todas derivan del modo en que el tangle funciona.

Por esta razón, y también porque no quiero involucrarme en alguna de las controversias recientes entorno al proyecto IOTA, intentaré centrarme principalmente en entender y evaluar el tangle como conjunto, en lugar de diseccionar los detalles de su implementación específica en IOTA.

El tangle es un grafo acíclico dirigido cuyos vértices representan transacciones individuales y cuyos lados representan la “aprobación” de transacciones previas. Cada vez que un nodo transmite una nueva transacción a la red debe elegir dos transacciones previas para validarlas, a las cuales hace referencia en la nueva transacción que transmite. Conforme la nueva transacción penetra en la red, cada nodo la añade a su copia local del tangle, con un lateral apuntando a cada transacción que la nueva transacción aprobó.

He intento hacerlo lo mejor posible, pero esta descripción puede resultar confusa. Este diagrama debería ayudar. Cada cuadrado representa una transacción y las flechas que salen de cada transacción apuntando hacia otras dos representan la aprobación de las dos transacciones previas. La transacción génesis se encontraría fuera del diagrama por su lado izquierdo, y las  transacciones más nuevas, llamadas “puntas” (tips) en el white paper, se encuentra a la derecha, coloreadas de color gris.

¿Qué significa validar, y por tanto aprobar, una transacción? Conceptualmente, el nodo que hace la validación debe partir de las dos transacciones que está validando y seguir todos los caminos en orden inverso hasta la transacción del génesis, asegurándose de que nunca encuentra una contradicción (por ejemplo, un doble gasto, saldo insuficiente o cosas parecidas). Si hay una contradicción, escogerá otro par de transacciones para aprobar, sabiendo que ningún otro nodo aprobaría nunca la transacción que trata de transmitir si hubiese aprobado una serie de transacciones inconsistentes.

Hay que darse cuenta de que esto significa que cada nueva transacción no solamente aprueba cada una de las dos transacciones que ha escogido para ser validadas, sino que también indirectamente aprueba las transacciones que esas dos han aprobado, y las transacciones que esas transacciones aprobaron… y así todo el camino hasta el génesis. Esto es parte básica del “consenso a largo plazo” (eventual consensus) en el tangle.

En caso de que te estés preguntando acerca de la sobrecarga computacional para realizar esta validación, en la práctica se puede optimizar substancialmente. En los gráficos de esta página puedes observar que conforme caminas en el tangle desde las puntas (a la derecha del todo) hacia el génesis, a la larga alcanzas un punto en el pasado en el que todas las transacciones han sido (indirectamente) aprobadas por todas las puntas. En esos gráficos, las transacciones aprobadas por todas las puntas están coloreadas en verde. Por este motivo, se podría cortar el tangle a través de flechas que apunten a las transacciones en verde, validar los caminos desde esas transacciones particulares en verde hasta el génesis una sola vez, almacenar en cache los resultados y, desde ese momento en adelante, solamente validar tus nuevas transacciones hasta esas transacciones en verde. Esta optimización te evita el tiempo necesario para validar todo el tangle cada vez que quieras emitir una transacción y además permite que el tangle sea podado. Más detalle sobre esto a continuación.

Consenso

Una característica interesante de un libro de contabilidad basado en tangle como en IOTA es que los nodos que reciben las nuevas transacciones desde los pares no tienen que validarlas inmediatamente. De hecho, el tangle puede contener temporalmente transacciones contradictorias. Sin embargo, a la larga, un nodo debe decidir cual de las transacciones contradictorias debe aprobar (posiblemente indirectamente) al tener que añadir una nueva transacción.

¿Cómo elige entre transacciones en conflicto? Asumiendo que cada transacción sería válida si fuese considerada por separado, entonces la respuesta corta es que un nodo podría elegir aprobar cualquiera de ellas. Sin embargo, tiene un incentivo para aprobar aquella sobre la que el resto de la red continuará construyendo, para que igualmente su propia transacción sea aprobada a la larga. Se supone que la mayoría de los nodos de la red ejecutan el algoritmo de selección de transacciones para la aprobación, así que en caso de conflicto, un nodo tiene un incentivo para elegir la transacción que el algoritmo de referencia elegirá.

Para  entender el algoritmo de referencia, es importante entender primero el concepto de peso acumulado (cumulative weight) de una transacción.

Cada nodo que emite una transacción tiene que hacer un poco de Prueba de Trabajo (Proof-of-Work – PoW), el cual determina el “peso propio” de la transacción. El peso  acumulado de una transacción es entonces la suma de su peso propio con los pesos de las transacciones que han sido directa o indirectamente aprobadas. En un tangle genérico, el nodo puede decidir cuanto trabajo hacer para una transacción, pero en IOTA todas las transacciones requieren del mismo PoW y, por consiguiente, todas cuentan con el mismo peso. Cómo resultado, el peso acumulado de una transacción es proporcional al número de transacciones que aprueba directa o indirectamente.

Entonces ¿Qué es el algoritmo de referencia? El autor del white paper lo llama Markov-Chain Monte Carlo (MCMC, ver sección 4.1), lo cual es una manera sofisticada de decir que es el viaje aleatorio por la tangle por aquellos caminos con mayor peso acumulado. Este artículo ya se está haciendo largo, así que evitaré los detalles. Es suficiente con decir que, cuando surgen transacciones en conflicto, el algoritmo MCMC resuelve el conflicto tendiendo a elegir aquella transacción que cuenta con el mayor peso acumulado tras ella. A la larga, un subtangle se convierte en dominante y el otro se queda huérfano. Esto proceso es análogo al que las blockchains usan para resolver forks y el peso acumulado de una transacción en IOTA es una media aproximada de su finalidad de la misma forma que al añadir bloques a una blockchain estamos confirmando transacciones cada vez con mayor certeza.

Por cierto, el hecho de que los nodos no necesiten validar inmediatamente cada nueva transacción recibida de sus pares tiene grandes implicaciones para el rendimiento. Cada nodo tiene que hacer menos trabajo de este modo, validando las transacciones solo cuando transmiten nuevas transacciones y tomando por seguro que las transacciones que han sido aprobadas indirectamente por todas las puntas han sido ya validadas por el resto de la red. Además, las validaciones corren en paralelo a través de la red, puesto que los diferentes nodos eligen diferentes subseries de transacciones para aprobar.

Seguridad

Hasta este momento, mayormente solo he regurgitado la información disponible en el white paper de IOTA. Por otro lado, el asunto de la seguridad del tangle es dónde la cosa se pone interesante. Recomiendo leer el análisis que se puede encontrar en el white paper sobre los diferentes posibles ataques sobre el tangle (también recomiendo leer el resto del whitepaper, porqué está muy bien redactado) y es por esto que no hablaré sobre la mayor parte de ese análisis aquí.

En su lugar, quiero centrarme en la amenaza más obvia, que es la de un ataque del 51%. Los desarrolladores de IOTA se refieren a ello como ataques del 34%, por unas razones que no estoy seguro de comprender. Creo que es porque si un atacante esperase hasta que suceda un fork de modo natural solo necesitaría un determinado poder de hash para sobrepasar el de los nodos en cada rama del fork, es decir, más de un 50% del poder de hash del resto de la red. De cualquier modo, el número exacto no es importante y para lo que queda de artículo haré referencia a él como “ataque del 34%”.

En IOTA, un ataque del 34% tendría la siguiente apariencia. Un atacante emite una transacción que supone el gasto de unos fondos, representado por el punto rojo de más a la derecha. A continuación, proceso (o quizá haya ya preprocesado) su propio subtangle “parásito”, el cual se ancla al tangle principal en algún lugar aguas arriba de su transacción y que contendrá una transacción de doble gasto, representada por el punto rojo de más a la izquierda. Su objetivo es añadir el suficiente peso acumulado a su tangle parásito para convencer al algoritmo MCMC de que debe dejar huérfano el tangle principal y pasará a seguir el parásito.

Afortunadamente, las analogías con la blockchain son claras hasta ahora, pero todavía existe una más importante. Cómo en una blockchain PoW, el tangle está asegurado por el poder de hash actual de la red, puesto que este poder de hash es lo que añade peso acumulado al tangle legítimo. Sin embargo, al contrario de lo que sucede en una blockchain PoW, los nodos de IOTA sólo hacen PoW cuando emiten transacciones. Por tanto, la seguridad del tangle depende solo de la frecuencia de transacciones y la cantidad de PoW por transacción. Tómate un segundo para asimilar esta idea, porque es absolutamente crucial para entender la seguridad del tangle.

Puesto que la red de IOTA es todavía pequeña y el ratio de transacciones es baja, el equipo de IOTA ha establecido un único nodo de confianza, llamado el Coordinador, que es responsable en último lugar de decidir el estado actual del tangle. Su propósito es proteger la red frente a ataques del 34%, entre otros ataques. No voy a dedicarle más tiempo, pero os animo a que leáis esta crítica y la respuesta de los desarrolladores, y entonces saquéis vuestras propias conclusiones acerca de si IOTA puede llamarse descentralizado cuando funciona bajo la supervisión del Coordinador.

Vamos a ver si podemos obtener una estimación del orden de magnitud de lo segura que la red podría ser sin el Coordinador. En un reciente test de stress se alcanzaron cómodamente las 100 transacciones por segundo (tps) en una pequeña red de pruebas. El equipo sugiere que 1.000 tps por segundo serían factibles. No se cual es el requisito de PoW en IOTA, pero supongamos que el dispositivo IoT medio sea aproximadamente una Raspberry Pi que utiliza el 100% de su CPU durante 10 segundos para realizar el PoW requerido. De nuevo, estoy tratando de ser generoso; muchos dispositivos IoT son considerablemente menos poderosos que una Raspberry Pi, y pedir el máximo de la CPU durante 10 segundos para cada transacción probablemente sería un quebradero de cabeza.

Con estas premisas, podemos concluir que el poder de computación medio que asegurará la red es aproximadamente 10.000 x (el número de computaciones de Raspberry Pi en 10s) por segundo, o su equivalente, 100.000 veces el poder de computación de una Raspberry Pi. Hay múltiples matices posibles sobre el benchmark de los dispositivos, pero no nos vamos a preocupar por variaciones de factor dos o tres, ya que sólo pretendemos obtener una estimación del orden de magnitud, así que usaré algunos números gordos que he encontrado en internet.

Una Raspberry Pi3 puede realizar cientos de MFLOPS (megaflops, o millones de operaciones de coma flotante por segundo), mientras que los relojes de las GPU’s de última generación pueden realizar miles de GFLOPS (gigaflops, o billones de FLOPS), 10.000 veces mayor poder de computación. Así que en nuestro caso hipotético, un atacante con ~10 GPUs podría sobrepasar el poder de cómputo de toda la red. Añádele otro factor de 10 porque haya sido descuidado en mis cálculos (quizá las operaciones con enteros son más lentas en una GPU que las operaciones como flotante, por ejemplo) y todavía necesitarías solamente 100 GPUs para ejecutar los ataques.

Estoy seguro de que hay muchas cosas que puntualizar en este análisis. Quizá IOTA no se ejecutará continuamente en el extremo de la red, por ejemplo. En su lugar puede que se ejecute en routers y puertas de enlace a la que estos dispositivos IoT se conecten, los cuales suelen ser mucho más potentes.

De todos modos, lo que pretende decir es que PoW asegura con éxito blockchains como la de Bitcoin y Ethereum porque no está atado a la tasa de transacciones o a cualquier otro factor más allá del valor económico de la red. Conforme el valor de la recompensa por minado (en dinero fiat) aumenta según aumenta el valor de Bitcoin, los mineros añaden más hardware y consumen más energía para minarlo. El incentivo económico para minar asegura que la cantidad de poder de hash que asegura la red aumenta con el valor monetario de la red.

Por contra, en IOTA no hay incentivo económico para asegurar la red. Además, el poder de hash que asegura la red está ligado directamente al número de transacciones, el cual naturalmente tiene un límite superior que depende del ancho de banda y de la tipología de la red.

Sobre este último punto, los desarrolladores de IOTA han lanzado un argumento creativo, no mencionado en el whitepaper, que afirma que las limitaciones y la tipología de la red realmente mejoran la seguridad de la red. No he encontrado ningún argumento oficial sobre ello en ningún sitio, pero tras investigar un poco me encontré con esta conversación en Slack, que es el mayor argumento que he podido encontrar.

Esencialmente, uno de los desarrolladores de IOTA (en concreto Sergey Ivancheglo, alias Come-from-Beyond, posiblemente alias BCNext, uno de los creadores originales de Nxt), afirma que la red de IOTA consistirá en dispositivos IoT que se emparejarán exclusivamente con sus vecinos más próximos en una tipología de red en malla, en la que un atacante solo tendrá la posibilidad de emparejarse con un pequeño número de dispositivos en esa red en malla. Es decir, la gran mayoría de dispositivos no estarán disponibles desde internet u otra red de acceso y la única manera de enviarles mensajes sería a través de la malla del resto de dispositivos.

La idea general es que la malla como entidad será capaz de alcanzar un gran rendimiento, pero cada link individual en la malla tiene un ancho de banda lo suficiente bajo que haría que un atacante lo saturase al tratar de añadir el número de transacciones suficientes para que convencer a la red de que siguiese su subtangle parásito. Puesto que el atacante solo tiene unos pocos puntos de entrada a la malla, los saturará antes de que su tangle parásito acumule suficiente peso como para que su ataque sea fructífero.

Dejaré que seáis vosotros los que saquéis vuestras propias conclusiones sobre este argumento. Personalmente no creo que el equipo de IOTA haya publicado los suficientes detalles como para poder evaluarlo en profundidad.

Ya que estamos hablando de las limitaciones del ancho de bando, pasemos a hablar del escalado.

Escalabilidad

Puesto que cada nodo debe validar otras dos transacciones antes de poder emitir su propia transacción, al equipo de IOTA le gusta señalar que el spam realmente tiende a hacer la red más eficiente. Otros miembros de la comunidad IOTA se dejan llevar por este argumento, algunos veces hasta llegar a afirmar absurdamente que IOTA es “infinitamente escalable.”

Cada nodo de la red de IOTA debe, a largo plazo, recibir cada transacción para mantener un tangle mínimamente consistente. Sin embargo, transmitir transacciones a los nodos remotos requiere de tiempo y si el ratio de transacciones es lo suficientemente alto, de modo que un nodo recibe muchas transacciones de sus nodos cercanos antes de que reciba la próxima transacción desde los nodos lejanos, el algoritmo MCMC continuará seleccionando las puntas enviadas por los nodos cercanos. A la larga, el tangle se divide, con solo los nodos cercanos realizando transacciones en la copia local del tangle y los nodos lejanos realizando transacciones entre ellos, una copia divergente.

Así que el ancho de banda y la tipología de la red tiene que establecer ciertas limitaciones en el ratio de transacciones de IOTA si el tangle tiene que ser consistente a lo largo de toda la red. Tendremos que esperar a que se completen más test de estrés para descubrir cuales son las limitaciones.

Adicionalmente, como todos los libros de contabilidad distribuidos, IOTA tiene que lidiar con el problema del crecimiento desmesurado. Cada transacción de IOTA ocupa unos 1,6kB, así que un tasa de transacciones de 100tps hará crecer el tangle a un ritmo de 160 kB por segundo, o unos 14GB al día. No es necesario decir que eso es un valor de almacenamiento irreal para un dispositivo IoT.

IOTA soluciona este problema tomando capturas periódicas del tangle, que mapea su estado actual en una nueva transacción génesis, permitiendo que el historial de transacciones sea eliminado. En el supuesto límite de un podado muy frecuente, un nodo solo tendría que almacenar una parte suficiente del tangle para ser capaz de ejecutar el algoritmo MCMC.

Sin embargo, sincronizar un nuevo nodo con la red es una historia diferente. O bien el nodo descarga la última captura desde un par de confianza, o bien arranca desde la transacción génesis original y busca su camino hacia delante en todo el tangle. No hay manera de unirse de manera eficiente a la red sin depender de la confianza en un tercero.

Finalmente, hay que mencionar que el equipo de IOTA ha propuesto un tipo de partición horizontal del tangle al que llaman “manada” (swarm) dónde un grupo de nodos unidos almacenan todo el tangle, pero ninguno de ellos lo almacena en su totalidad. Desafortunadamente, todavía no contamos con muchos detalles sobre cual es su funcionamiento.

Comparado con Ardor

¿Qué tiene todo esto que ver con Ardor?

En mi opinión, hay dos comparaciones que establecer, concretamente en los aspectos de la seguridad y la escalabilidad.

Sobre la seguridad, no está claro para mí que IOTA pueda alcanzar un ratio de transacciones suficientemente alto para ser considerado seguro sin el Coordinador, debido al valor monetario de la red actual, sin elegir una exigencia muy alta de PoW.

Ardor, por su parte, tiene la ventaja de que sus child chains están aseguradas por una única cadena madre.

Una “pequeña” child chain no requerirá de un nodo de confianza como es el Coordinador de IOTA para protegerla, porque su consenso es establecido por la red al completo y almacenado (a través de los hashes de los bloques de las child chains) gracias a los forjadores en la cadena madre.

Sobre la escalabilidad, tanto IOTA como Ardor comparten el requisito de que cada nodo de la red debe procesar todas las transacciones. Con IOTA, esto simplemente significa añadir transacciones al tangle, lo que es computacionalmente barato, mientras que con Ardor, cada nodo debe validar cada transacción. Además, el diseño inteligente del tangle asegura que el tiempo de confirmación por una transacción realmente disminuye conforme la red tiene más trabajo. No me sorprendería que IOTA alcanzase un mayor rendimiento que Ardor si ambas redes crecen.

Por otro lado, IOTA se enfrenta a un tremendo reto para combatir los problemas de crecimiento desmesurado del tangle si alguna vez tiene que alcanzar cientos de transacciones por segundo, mientras que Ardor ya ha solucionado este problema.

Finalmente, hay que mencionar que la hoja de ruta de Ardor delegará el procesado de las transacciones de la child chains a sub-redes dedicadas dentro de la red. Esto podría potencialmente alcanzar una mejora computacional similar a la propuesta de “manada” de IOTA, posiblemente permitiendo un rendimiento similar.

Reflexiones Finales

Si has llegado a leer hasta aquí (¡gracias!) y ya estabas familiarizado con IOTA, entonces sin duda te habrás dado cuenta de que he dejado fuera multitud de detalles, incluyendo su algoritmo de hash casero, la falla introducida deliberadamente en el código por Come-from-Beyond como sistema anti-copia, el uso de codificación ternaria y el misterioso procesador Jinn que ofrecerá soporte hardware para IOTA en los dispositivos IoT. En el transcurso de mi investigación, me he formado unas posiciones bastante fuertes al respecto sobre estos temas, pero dudaba acerca de compartirlas aquí por dos motivos.

Primero, no tengo suficiente información para hacer afirmaciones objetivas sobre estos temas. No soy un criptógrafo y no conozco casi nada sobre la computación ternario o Jinn. Lo mejor que podría hacer es ofrecer afirmaciones subjetivas sobre las decisiones de diseño que el equipo de IOTA había hecho, pero simultáneamente habría debilitado el foco principal de este artículo y habría abierto la puerta a criticas provenientes de otras personas que pudieran tener distintas percepciones subjetivas.

Segundo, y más importante, estoy más interesado en los conceptos fundamentales tras el tangle que en la implementación específica que IOTA hace de él. Sin importar si IOTA triunfa o fracasa, el tangle es una idea bella y se merece toda la atención que le podamos dedicarle.

Entonces ¿qué podemos decir sobre el tangle? Aunque me enamora lo elegante de su diseño y las sutilezas de su mecanismo de consenso, al final me temo que soy bastante escéptico de su usabilidad para el Internet of Things. Si quitas este aspecto, incrementa los requisitos de PoW varias órdenes de magnitud y encuentra un camino para ligar el umbral del PoW al valor monetario de la red sin evitar el acceso de los usuarios comunes a sus fondos y entonces creo que el tangle tiene un enorme potencial como libro de contabilidad distribuido.

La última pieza a encajar es como combinar la no necesidad de confianza, eficiencia y crecimiento desmesurado, un problema que Ardor ha solucionado extremadamente bien. Quizá alguien encontrará una manera de combinar los mejores elementos de ambos diseños en algún punto en el futuro. Un montón de cosas pueden suceder hasta entonces, especialmente en criptolandia.

P.S. – Prometo que mi próximo artículo será más corto. 🙂

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.

Ardor Frente a la Competencia, Parte 1: Lisk

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:

  1. 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.
  2. 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.
  3. 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.

¿Significa Ardor la muerte de Nxt?

El proceso de toma de instantáneas ha terminado y los activos (ARDR) ya han sido repartidos. La cantidad de NXT en una cuenta ya no influye en el número total de tokens de forja ARDR que recibirás una vez que la red Ardor entre en funcionamiento. Ver caer el precio de NXT estos últimos meses debería dar una buena pista para todo el mundo. Ya no hay ninguna razón para mantener NXT. Ardor y sus child chains son el futuro. ¡Abran paso!

¿De verdad? Yo no lo creo.

make-way

¿Seguirá Nxt el mismo camino en 2017?

1. Ardor no será presentado hasta el tercer trimestre de 2017

La reciente distribución de “Ardor” solo es un activo que determinará el número total de tokens ARDR que vas a obtener una vez la plataforma Ardor entre en acción. Ahora mismo no es algo real ni lo será a corto plazo.

La testnet de Ardor se espera sea lanzada durante el primer trimestre de 2017 y la puesta en marcha de la red principal está prevista para el tercer trimestre de 2017. ¿Por qué no usar Nxt hasta entonces? Sigue siendo seguro, totalmente funcional y, además, es la base de muchos activos y monedas que son negociados en múltiples casas de intercambio.

2. Nxt todavía recibirá soporte

El equipo de desarrollo de Nxt ha prometido dar soporte a la plataforma Nxt, durante un año, como mínimo, tras el lanzamiento de la red Ardor. Estamos hablando de un software que va a ser mantenido al día, como mínimo, hasta finales de 2018. Y después de eso, desarrolladores con una dosis de motivación pueden adoptar el proyecto y mantenerlo.

Aunque no se agregasen nuevas características, lo cual es una posibilidad, el software sigue siendo funcional y ha demostrado ser fiable durante estos últimos tres años. Algunos activos y monedas se moverán a la plataforma Ardor, pero otros continuarán utilizando la plataforma Nxt 1.0.

Muchas altcoins no son evolucionadas o no tienen actualizaciones importantes y, a pesar de eso, todavía se siguen comprando y vendiendo de forma activa.

3. La toma de instantáneas para Ignis beneficiará Nxt

En el tercer trimestre de 2017, tendrá lugar la instantánea para la distribución de Ignis, la primera child chain de Ardor, y probablemente atraerá a una gran cantidad de especuladores. Ardor es el combustible de la red, pero Ignis es la primera moneda con todas las características que nos gustan de Nxt: votación, mezclado de moneda, alias,…

Esta segunda instantánea será una buena oportunidad para que la gente aprenda acerca de Nxt y atraer a nuevos usuarios.

look

Intentando adivinar el valor futuro de las criptomonedas

Sin embargo, la caída del precio NXT puede ser más rápida que el aumento. Después de la instantánea, lo más probable es que vuelva a caer de nuevo. “Cuánto” es la pregunta.

4. Jerulida está observando

Jelurida nace con el objetivo de proteger la propiedad intelectual del código de Nxt. Para tener éxito comercial necesita que Nxt tenga éxito. Tener un equipo trabajando a tiempo completo para mejorar y proteger Nxt tendría sentido para su futuro.

Durante la sesión de Preguntas y Respuetas tras la creación de Jelurida, se planteó la siguiente pregunta:

> @josenxt
> ¿Veremos en los próximos 6 meses otra gran sorpresa (como la de Jelurida) que se está gestando actualmente entre bastidores?

> @jean-luc
> Espero que incluso más pronto

Esperemos que beneficie a Nxt.

5. Las aplicaciones actuales seguirán siendo funcionales

La API de Nxt es muy estable y fácil de usar. Muchos desarrolladores han construido sus propias aplicaciones basadas en Nxt (MyNxt, SuperNET, nxtportal, Nxter.org, Nxt3D…). Incluso aunque la API de Ardor terminase siendo muy parecida a la de Nxt (lo que no es seguro), requerirá un cierto trabajo antes de que tales aplicaciones puedan trasladarse a Ardor (si es que deciden trasladarlas). Pero, ellos seguirán trabajando en la plataforma Nxt 1.0, sin importar lo que suceda.

Nxt tiene un gran ecosistema y llevará algún tiempo para que Ardor lo alcance, aún incluso después del lanzamiento.

6. Un NXT barato significa transacciones más baratas

Nxt siempre ha utilizado las tarifas de transacción de 1 NXT para la mayoría de las operaciones. En junio de 2016, cuando 1 NXT valía 13.000 Satoshi, una tarifa de transacción costaba alrededor de 8 céntimos de euro por transacción (aún entonces más barato que Bitcoin, por cierto). Ahora, estando casi a 1000 Satoshi, estos honorarios valen solamente 0,6 céntimos. Es básicamente gratis.

Aquellos que consideran que NXT es una moneda se sentirán decepcionados. Aquellos que ven a Nxt como una plataforma de intercambio de activos, discusiones o hosting distribuido, estarán contentos.

Un mezclado de monedas cuesta 12NXT, o 0,07€ al cambio. ¿No es un buen momento para anonimizar algunas monedas o activos? ¿Qué tal lanzar ese activo que estabas pensando? La emisión de un activo sólo cuesta 1000 NXT o alrededor de 6€, a día de hoy.

nicholas

El futuro es brillante

Lectura recomendada: http://test.nxter.org/es/desarrolladores/

Mientras que haya un puñado de personas manteniendo y forjando Nxt, la red va a ser funcional.

Recuerde que para todas aquellas personas que venden sus NXT siempre hay compradores que piensan que vale la pena comprarlos.

Este post de opinión fue enviado por mart_e: NXT-XZ53-H97E-6FK5-9RHAS

¿Quieres que se publique tu entrada de blog en nxter.org? Póngase en contacto con nosotros y haga que su voz sea escuchada.

P&R sobre Jelurida – Los desarrolladores centrales de Nxt hablan en serio

El 7 de octubre de 2016 Damelon anunció la presentación de Jelurida BV, el comienzo de una nueva compañía de desarrollo de software compuesta por los desarrolladores centrales de Nxt Jean-Luc, Riker y el miembro de la Fundación Nxt, Damelon.

Jelurida BV, poseedora de los derechos de propiedad intelectual del software Nxt y de la plataforma Ardor, tiene como objetivo crear un negocio sostenible y  próspero en todo el ecosistema Nxt, proporcionando para ello licencias de software, mantenimiento y servicios a una nueva generación de aplicaciones basadas en la Blockchain.

El anuncio sin aviso previo de esta “compañía Nxt” y el hecho de que los desarrolladores principales de Nxt y Ardor fuesen a obtener ingresos por sus servicios y de la propiedad intelectual ha desencadenado discusiones en el canal general del Slack de Nxtchat. Damelon publicó unas pocas respuestas, pero pidió a la comunidad que se guardase las preguntas para la jornada de Q&A con los desarrolladores, que se realizó ese mismo domingo.

martis [2:09 PM]
Así que ¿Nxt se ha convertido en una compañía?

damelon [2:10 PM]
No, los desarrolladores han formado ahora una compañía (junto conmigo, que también formo parte de ella). Soy el director gerente. Es un Holding compuesto por dos sociedades (BVs). Hay una sociedad que posee los derechos de Propiedad Intelectual y una sociedad que esta más “activa” y operativa.

El primer objetivo es asegurar que el código está protegido, y en segundo lugar la concesión de licencias para generar un flujo de dinero.  El beneficio directo es la continuidad y más posibilidades de asociarse con compañías reales. Esto beneficia a la comunidad y a los poseedores de Nxt. Incluso si las licencias son vendidas para cadenas privadas, esto significa que los desarrolladores reciben fondos, lo que implica que pueden seguir trabajando en el código sin necesidad de posponer otras actividades. También nos permite aumentar el grupo de desarrolladores con gente de calidad que también beneficia al código y a los usuarios.

La forma en que queremos crear valor para los poseedores de Nxt es asegurándonos de que ofrecemos un valor en forma de software y atrayendo clientes y usuarios a la plataforma. Es un paso más en la profesionalización y, también, es un gran paso para asegurarse de que Nxt y Ardor serán sostenibles en un futuro. El código de Nxt es y seguirá bajo licencia GPL, por lo que la utilización de la cadena pública no se va a ver afectado.

Además, se trata mayormente de los derechos intelectuales. Los desarrolladores no quieren que los derechos de autor se les escapen de las manos. Entregarlos a la Fundación los dejaría a merced de otras personas. Al tenerlos controlados en su propia compañía, les permite mantener el control en situaciones que así lo requieran, como cuando es necesaria la concesión de licencias.

Las Preguntas y Respuestas (P&R)

La sesión de Preguntas y Respuestas tuvo lugar en el Slack Nxtchat, el día 9 de octubre de 2016, de 20:00 a 21:46h CEST.

Esto es un resumen del evento. Se han eliminado de este sumario todas las preguntas referentes a las subidas y bajadas de precio y las preguntas acerca del “uso de Ardor”. Puedes visitar el hilo con el FAQ en Reddit para encontrar Preguntas y Respuestas (P&R) generales sobre ARDR, Ardor e Ignis.

Ahora, vamos con ello.

riker [8:05 PM]
Chicos, ¿Preparados para las P&R?

legs11 [8:06 PM]
Si

damelon [8:06 PM]
@channel Los desarrolladores ya están aquí, así que, por favor, comenzad a formular vuestras preguntas.

Ardor

jean-luc
El desarrollo va bien encaminado, pero se requiere tiempo. El calendario se está siguiendo sin cambios. Por ahora, realmente nada ha cambiado en la dirección del proyecto o  en nuestro plan sobre Ardor.

riker
Nos sentimos cómodos con la dirección del proyecto y disfrutamos de nuestro trabajo.

jean-luc
Constituye un desafío mantener el código simple. El código se basa intencionalmente en Nxt, de manera que así se minimizan los errores, pero he comenzado algunas refactorizaciones que hacen más complejas las fusiones con el código 1.0.

Jelurida

jean-luc
Jelurida pretende hacer dinero a partir de las licencias, el soporte y las consultas.

legs11
¿Hay alguna posibilidad de participar en esta empresa durante esta etapa inicial?

jean-luc
Es una empresa privada, el público en general no puede invertir en ella.

durerus
¿Quiénes son los miembros de esta compañía y qué porcentaje poseen?

jean-luc
Eso es información confidencial.

durerus
¿Puedes describir lo que obtendría un cliente que pague?

riker
Licencia para cambiar el código del núcleo NXT para su propósito. Licencia de uso para una blockchain privada. Mantenimiento, soporte y consultoría.

Muchas organizaciones no usarán una blockchain pública debido a los problemas regulatorios o a la confidencialidad. Nos gustaría entrar en el nicho de las blockchains privadas.

josenxt
¿No tiene ComeFromBeyond, por ejemplo, nada que decir sobre esto?

jean-luc
CFB ha escrito código solamente bajo la licencia MIT. Los desarrolladores que han aportado código bajo licencia GPL han transferido sus derechos de autor a Jelurida.
En estos momentos, los bancos y las empresas financieras están clonando NXT y utilizándolo de forma privada.

Si conseguimos que paguen por esto, tenemos la intención en un futuro de conseguir un desarrollo sostenible para Nxt.

apenzl
¿Cuáles son los derechos de propiedad que va a proteger Jerulida?

riker
Actualmente, la gente está copiando el código de NXT a diestro y siniestro. Incluso si quisieran pagar por utilizar el código de NXT no tienen a quien pagar. Si ahora no pagasen, podríamos ir tras ellos. Eso lo que significa proteger nuestros derechos.

jean-luc
En ausencia de una única persona jurídica que sea propietaria de los derechos de autor, es difícil de hacer cumplir la licencia GPL, hemos visto ejemplos de ello con empresas que los violan porque saben que no hay nadie para demandarlos.

Por el contrario, si una empresa busca hacer un uso comercial y está dispuesta a pagar por ello, es difícil hacerlo legalmente sin una sola entidad legal que posea los derechos de autor, situación que ha venido ocurriendo.

Jelurida para los inversores

durerus
Así que queréis entrar en el nicho de las blockchains privadas. ¿Puede decirnos por qué esto va a ser bueno para los inversores del token Ardor, NXT e IGNIS?

riker
Podemos utilizar los fondos que recibimos de las cadenas privadas para promover el desarrollo de la cadena pública, que a su vez servirá para el marketing y las relaciones públicas de NXT / Ardor y atraerá el negocio de las blockchains privadas. Esperamos conseguir dicho ecosistema para así proporcionar una situación beneficiosa tanto para los inversores de los tokens públicos como para los clientes de las blockchains privadas.

kasp
Honestamente, no parece justo para los poseedores de los tokens. Supongamos que se invierte el 60% del tiempo de desarrollo en las cadenas privadas, lo que permite obtener unas ganancias notables. ¿Cómo van a estar en ese caso los desarrolladores motivados para trabajar en Nxt/Ardor? Además, esto ralentizará el progreso.

riker
Creo que tenemos que tener en cuenta que el modelo actual de la utilización de fondos / donaciones de la comunidad para promover NXT no funciona. Este nuevo modelo tiene muchas más posibilidades.

Insisto en que esperamos generar feedbak positivo en los que se utilicen las ganancias de las blockchain privadas para promover la blockchain pública, que a su vez apoyará a la blockchain privada.

bidji
El sistema actual no es sostenible, los desarrolladores necesitan ganar dinero.

Pero me temo que el incentivo para trabajar en la cadena pública será demasiado bajo. Imagínad que tenéis éxito y tenéis una gran cantidad de contratos para construir blockchains privadas. En el momento que se os pague por ello tendréis que centrar todos vuestros recursos en esos contratos. ¿Qué pasará con la blockchain pública en ese momento? Será dejada de lado. Básicamente hay un conflicto de intereses entre el éxito de blockchain pública y el éxito del negocio privado. ¿Qué pensáis?

riker
No vamos a ser capaces de vender blockchains privadas a menos que tengamos una exitosa cadena pública. Todos nos damos cuenta de esto. NXT promoverá Jelurida y Jelurida promoverá NXT. El reto es crear una situación win-win y necesitamos su apoyo.

willtate
Creo que las relaciones públicas tendrán que recorrer un largo camino para traer clientes, así como el nuevos desarrolladores. Hay más actividades previstas planeadas en este departamento para el corto plazo?

riker
Sí, no estoy seguro de que podamos compartir planes concretos en este momento. Vamos a empezar con una web y todo el material de marketing que se espera de una startup.

logan
¿Informareis a la comunidad sobre los nuevos tratos, etc?

riker
Como empresa privada probablemente no compartamos todo públicamente. Puede que emitamos comunicados de prensa sobre acuerdos firmados, etc.

vprf
Si soy una empresa con la necesidad de una cadena privada. ¿Por qué utilizar NXT / ardor / etc. por encima de otra cripto?

riker
(1) El POS es mucho más adecuado para una cadena privada que el POW
(2) Se puede desarrollar en Java y no con raras secuencias de comandos (es decir ETH)

vprf
Entonces ¿Por qué no Lisk,  si es Java y POS?

riker
Les llevamos 2 años de ventaja y tenemos un equipo más experimentado

vprf
Quería apuntar que yo preferiría tratar con personas reales con nombres reales.

riker
Jelurida tiene una junta directiva pública que figura en el registro holandés de comercio. La identidad de los promotores reales no tienen importancia, de la misma manera que no sabes quién son los desarrolladores de Java, sino que confías en Oracle para que admita Java.

¿No conoces a Bas? ¿No has visto mi anterior presentación?

[youtube id=”soHe4UMyCCk” width=”” height=”” autoplay=”no” api_params=”” class=””]

 

wolffang
¿Las blockchains privadas se harán ahora con Nxt y después con la blockchain de Ardor? ¿O siempre en Nxt?

riker
Por ahora las cadenas privadas estarán basadas en Nxt, por supuesto. Probablemente pasaremos a Ardor cuando sea lo suficientemente estable

jean-luc
Depende de la demanda, pero Nxt 1.0 tiene una tecnología comprobada, y Ardor sería excesivo para su uso como cadena privada de una sola empresa. La mayoría de los clientes en busca de una blockchain privada de Jelurida no necesitaría la complejidad de Ardor, y sus múltiples cadenas hijas.

Contratando desarrolladores

almonte
Ahora que ya ha se ha establecido una empresa, ¿estáis pensando en contratar más desarrolladores en un futuro próximo?

jean-luc
Sí, pero es el problema de la gallina y el huevo… es difícil reclutar desarrolladores hasta que no tengamos por lo menos unos pocos clientes que nos paguen.

Si tenemos una gran demanda de cadenas privadas, también conseguiría derechos por concesión de licencias e ingresos que nos permitirían contratar a más desarrolladores

josenxt
¿Cómo va a Jelurida animar a nuevos desarrolladores a unirse al equipo de desarrollo cuando saben a ciencia cierta que su trabajo no será acreditado? ¿Sólo por el dinero que Jelurida les pagará? ¿Todos los nuevos desarrolladores van a escribir código para Jelurida y no para la comunidad Nxt de ahora en adelante?

riker
Jelurida tiene la intención de pagar los salarios o dar acciones para recompensar los desarrolladores (tal vez ambas cosas). Parte del código se puede desarrollar como código fuente cerrado y parte  será compartido con la comunidad.
En el futuro habrá millones de blockchains, algunas públicas y algunas privadas. Queremos que el mayor número posible de ellas estén basadas en NXT.

jean-luc
Los nuevos desarrolladores, después de un pequeño periodo de entrenamiento, se dedicarán a apoyar el desarrollo y las funciones de las cadenas privadas, en primer lugar, de modo que los desarrolladores más experimentados podrán centrarse en Ardor.

Jelurida y la comunidad Nxt

rubenbc
¿Cómo va a apoyar Jerulida a la comunidad si es una empresa privada?

logan
Puedo ver el efecto favorable de la promoción de las cadenas públicas para las cadenas privadas, pero no consigo verlo en la otra dirección. ¿Por qué debería Ardor obtener más valor si una empresa esta tecnología dentro suyo?

riker
Espero que Jelurida y la Fundación Nxt compartan los beneficios.

farl4bit
¿Cómo se puede animar a la comunidad a seguir trabajando como voluntario a sabiendas de que sus desarrolladores y el líder de la Fundación Nxt podrían estar trabajando para soluciones privadas?

riker
¿Quieres que los desarrolladores trabajen gratis o casi gratis para siempre? Jelurida trabajará en conjunto con la comunidad para mejorar NXT / Ardor y convertirlo en un negocio sostenible.

wolffang
¿Cuál es el papel de la comunidad en esta nueva situación? Puede suceder que gente que hasta ahora habían siendo buenos contribuyentes lo dejen. ¿Cómo evitarlo?

riker
Jelurida abrirá las puertas a lo que apoyen a NXT, y les permitirá obtener puestos de trabajo lucrativos en tareas tales como desarrollo, consultoría, soporte, formación…

josenxt
¿Querríais que el resto de la comunidad Nxt trabaje gratis o casi gratis para siempre, más aún sabiendo que desde ahora todo eso contribuye a hacer más grande una empresa privada como Jelurida? También podría verse de esta manera.

riker
Si Jelurida tiene éxito habrá un fondos suficientes para pagar a todos.

Palabras finales

josenxt
¿Descubriremos de aquí a 6 meses alguna otra gran sorpresa (como Jelurida) que en la actualidad estáis cocinando entre bastidores?

jean-luc
Esperemos que antes.

Wolffang
@riker ¿cuándo se espera que esté lista la aplicación móvil de Nxt?

riker
Está lista para el testeo inicial, pero queremos tener completado Jerulida y la distribución del token Ardor primero.

riker [9:43 PM]
¿Suficiente por hoy?

farl4bit [9:46 PM]
@riker @jean-luc Muchas gracias! Estoy deseando tener más sesiones como esta.

Y eso es todo amigos.

Puedes subscribirte al semanario de noticias de Nxt aquí.

NXT-crypto-developer

Para más información sobre Nxt & Ardor visite: http://test.nxter.org/category/nxt-newsletter-archive/

ARDR ya está en los mercados

Ayer, 13 de Octubre, a la altura de bloque 1.000.000, o 42 días antes del tercer aniversario de la blockchain de Nxt, el período de toma de instantáneas sobre el saldo NXT (snapshots) de Nxt 1.0 → Nxt 2.0 llegó a su fin y, 1 billón de activos ARDR fueron automáticamente distribuidos a todas las cuentas que hubiesen mantenido cualquier cuantía de NXT desde que se tomó la primera instantánea, lo cual sucedió hace 3 meses.

Por cada NXT que ha estado en tu cuenta desde la primera captura has recibido 1 activo de ARDR. Si has mantenido tus NXT sólo durante la mitad de este período de toma de instantáneas, habrás recibido 0,5 ARDR por cada NXT. (Para más información sobre el modelo de distribución consulta este artículo)

Este que descrbimos a continuación es el ÚNICO activo oficial Ardor:


Tomado en directo desde el AE

NXT y ARDR en los exchanges

Los activos ARDR han sido distribuidos a todas las cuentas poseedoras de NXT, incluidas las de los servicios de intercambio centralizados (exchanges), que ahora deben distribuirlos a todos sus clientes.

El equipo de Nxt escribe:

El método de distribución usado dependerá de como se organice internamente cada casa de intercambio, así que ni el equipo central ni la comunidad Nxt podemos proporcionar una solución universal para la distribución de Ardor a los clientes de los exchanges.

Los clientes que todavía no han recibido sus ARDR deberán contactar con Poloniex, Bittrex, HitBTC, BTC38, etc. para más información acerca de su método de distribución.

HitBTC y Changelly fueron las primeras casas de intercambio centralizadas en abrir un mercado BTC < > ARDR, pero se espera que,  a corto plazo, muchos otros exchanges sigan pronto su camino. Puesto que la mayoría de los exchanges que admiten NXT también operan con activos del mercado de Nxt, debería de ser muy fácil para ellos añadir ARDR.

ACTUALIZACIÓN:

Mercados ARDR < > BTC 
https://hitbtc.com/exchange/ARDR-to-BTC
https://bittrex.com/Market/Index?MarketName=BTC-ARDR

Capitalización de ARDR: http://coinmarketcap.com/currencies/ardor/

Siguiente snapshot – IGNIS

Todavía falta un snapshot si quieres obtener el máximo valor por tus NXT.

Ignis será la primera childchain, que está garantizado que va a lanzarse en la plataforma Ardor. En Nxt 2.0, Ardor es el token usado para generarse el consenso e Ignis será el primer token usado para las transacciones. Ambos se lanzarán con el bloque Génesis. Los tokens Ignis se distribuirán de manera gratuita con una proporción de 1:0,5 a todos los poseedores Nxt en el momento que se origine el bloque génesis. El último snapshot de la blockchain de Nxt se tomará justo antes de este momento y, de esta manera, podrán ser lanzadas a la vez.

Ignis heredará todas las características actuales del núcleo de Nxt, pero también se irán añadiendo además nuevos desarrollos por parte del equipo central de Nxt. La instantánea se tomará durante el tercer trimestre de 2017.

¿Qué pasará con la plataforma Nxt?

Nxt continuará y contará con el respaldo de los desarrolladores centrales.

Tal y como los desarrolladores centrales escribieron en la sesión de preguntas y respuestas de hace unos pocos días:

riker
NXT promocionará Jerulida y Jerulida promocionará NXT.

jean-luc
Habrá pequeñas empresas y consumidores finales que no necesitan, o no pueden permitirse, una blockchain privada. Aquellos, continuarán utilizando Nxt o iniciarán una childchain en Ardor.

riker
Podremos utilizar los fondos que recibamos de las cadenas privadas para promover el desarrollo de la cadena pública, que a su vez servirá de marketing y relaciones públicas para NXT / Ardor y de esta manera atraeremos más negocios de cadenas privadas.

ipsec [9:08 PM]
Ahora es muy arriesgado invertir en NXT y ARDOR ….. porque después del 13 el precio de NXT bajará

jean-luc [9:09 PM]
Todo el mundo espera una caída de precio después del día 13 … entonces todo el mundo venderá antes del 13.
Mi conjetura es que quizás la caída ya haya sucedido, pero yo no soy un especulador.
Si tu vendes, ¿qué mejor cosa puedes comprar que tenga mejor “estructura de incentivos”?

Y ese es el caso. Si Nxt no es la plataforma sobre la que empezar a programar sus nuevos proyectos sobre Ardor / Nxt 2.0, entonces ¿en cuál lo harías?

Con el marketing de de la Fundación Nxt, con un libro didáctico sobre Nxt 1.0 que está a punto de salir y con negocios apresurándose para entrar en la mejor tecnología blockchain antes de que la tecnología de por sí les pille fuera de juego… ¿Sería prudente vender tus NXT?

Jean-Luc:

Tenemos proyectos utilizando la blockchain de Nxt que tendrán que ser apoyados durante al menos los próximos 2 años y probablemente más. También estamos en el proceso de traer más desarrolladores al núcleo de Nxt, al igual que para Ardor, con el objetivo de establecer 2 equipos de desarrollo de núcleo semi-independientes.

Ha habido gran cantidad de desinformación  y confusión acerca de todo esto, así que espero que esto aclare cualquier duda que se puedan tener acerca de los planes futuros para NXT y Ardor.

¿Alguna duda? Adéntrate.

Únete a nxtforum.org o a Nxtchat Slack channel:

DeBuNe actualmente está buscando nuevos desarrolladores para unirse a su equipo distribuido. m19: “Estamos creando nuestra propia versión personalizada de NXT / Ardor y algunos de los cambios que hagamos incluso podría terminar en el núcleo, no estamos de ninguna manera competiendo con ellos, en lugar de eso, les apoyamos activamente.

https://nxtchat.slack.com/messages/job-offers/mentions/

LQD asset CEO libertynow [2:37 AM]: “Si NXT va por debajo de 1667 voy a empezar a preocuparme, bueno en realidad no. no me importa mucho. Podría utilizar NXT para dividendos si realmente lo necesitase”

Quizás estés interesado en leer: Tutorial Intercambio de Activos

Felicidades por tus activos ARDR. La compra/venta ha empezado. El futuro no será centralizado. Lo será usted.

“Snapshot de Ardor” Versión 1.9.2 de Nxt

[fusion_builder_container hundred_percent=”no” equal_height_columns=”no” menu_anchor=”” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” background_color=”” background_image=”” background_position=”center center” background_repeat=”no-repeat” fade=”no” background_parallax=”none” parallax_speed=”0.3″ video_mp4=”” video_webm=”” video_ogv=”” video_url=”” video_aspect_ratio=”16:9″ video_loop=”yes” video_mute=”yes” overlay_color=”” overlay_opacity=”0.5″ video_preview_image=”” border_size=”” border_color=”” border_style=”solid” padding_top=”” padding_bottom=”” padding_left=”” padding_right=””][fusion_builder_row][fusion_builder_column type=”1_1″ spacing=”” center_content=”no” hover_type=”none” link=”” min_height=”” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” background_color=”” background_image=”” background_position=”left top” background_repeat=”no-repeat” border_size=”0″ border_color=”” border_style=”solid” border_position=”all” padding=”” dimension_margin=”undefined” animation_type=”” animation_direction=”left” animation_speed=”0.3″ animation_offset=”” last=”no”][fusion_text]Ha sido lanzada la versión 1.9.2 del cliente de Nxt.

Lectura relecionada: Distribución de Ardor

INSTALADORES

[/fusion_text][/fusion_builder_column][fusion_builder_column type=”1_3″ spacing=”” center_content=”no” hover_type=”none” link=”” min_height=”” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” background_color=”” background_image=”” background_position=”left top” background_repeat=”no-repeat” border_size=”0″ border_color=”” border_style=”solid” border_position=”all” padding=”” dimension_margin=”undefined” animation_type=”” animation_direction=”left” animation_speed=”0.3″ animation_offset=”” last=”no”][fusion_text]

appletest

Nxt-download-button-grey-250hiweb[/fusion_text][/fusion_builder_column][fusion_builder_column type=”1_3″ spacing=”” center_content=”no” hover_type=”none” link=”” min_height=”” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” background_color=”” background_image=”” background_position=”left top” background_repeat=”no-repeat” border_size=”0″ border_color=”” border_style=”solid” border_position=”all” padding=”” animation_type=”” animation_direction=”left” animation_speed=”0.3″ animation_offset=”” last=”no”][fusion_text]

windows

Nxt-download-button-blue-250hiweb[/fusion_text][/fusion_builder_column][fusion_builder_column type=”1_3″ spacing=”” center_content=”no” hover_type=”none” link=”” min_height=”” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” background_color=”” background_image=”” background_position=”left top” background_repeat=”no-repeat” border_size=”0″ border_color=”” border_style=”solid” border_position=”all” padding=”” animation_type=”” animation_direction=”left” animation_speed=”0.3″ animation_offset=”” last=”no”][fusion_text]

linux

Nxt-download-button-gold-250hiweb[/fusion_text][/fusion_builder_column][fusion_builder_column type=”1_1″ layout=”1_1″ background_position=”left top” background_color=”” border_size=”” border_color=”” border_style=”solid” border_position=”all” spacing=”yes” background_image=”” background_repeat=”no-repeat” padding=”” margin_top=”0px” margin_bottom=”0px” class=”” id=”” animation_type=”” animation_speed=”0.3″ animation_direction=”left” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” center_content=”no” last=”no” min_height=”” hover_type=”none” link=””][fusion_text]

Firma digital: “Stichting NXT”
.sh Sha256: bf135f9d7280860b59fb69d4753e436ed23ebbcf95e1e4112cb707c7a64a20b4  nxt-client-1.9.2.sh
Lanzamiento 1.9.2: https://bitbucket.org/JeanLucPicard/nxt/downloads/nxt-client-1.9.2.zip
1.9.2 .zip sha256: 4fe0520e5b4d0fe244dc9d8ab7943c1a107a7e4227ce4ae9f3236ae1dcc1a8ab  nxt-client-1.9.2.zip

NRS 1.9.2 notas de la versión

Esta es la primera versión estable de la serie 1.9. La actualización a esta versión es opcional en la red principal hasta que se alcance el bloque 1.000.000 (12 Oct). Sin embargo, se aconseja a todos los usuarios hacerlo antes,  ya que a partir del 14 de Julio, la actualización provocará un re-escaneo de la Blockchain.

La principal novedad en la versión 1.9 es la distribución del token ARDR. Para más detalles ver el changelog de la 1.9.0e .

Se ha optimizado el rendimiento durante el re-escaneo de la Blockchain, así como para los cálculos del balance en la toma de las instantáneas. Se añade la propiedad nxt.dbMaxMemoryRows para poder establecer el parámetro FILAS H2 max_memory.

Se ha actualizado Jetty a la versión 9.3.10, por lo que deberás eliminar la antigua carpeta de librerías antes de descomprimirlo encima.

Fuente: Jean-Luc, desarrollador principal,  https://nxtforum.org/nrs-releases/nrs-v1-9-2/

Visite también: Nxt anuncia Ardor 

El proceso de toma de instantáneas comienza en el bloque 870.400 (estimado para el 14 de julio) y termina en el bloque 1.000.000 ( 12 Oct).

Para obtener tus tokens ARDR es recomendable que mantengas tu saldo de NXT en tu propia cuenta.

Con respecto a los saldos dentro de cuentas de exchanges, cada exchange es responsable de gestionar el reparto de los tokens ARDR, que el exchange recibirán automáticamente en su cuenta una vez se termine el proceso de toma de instantáneas.

Los 3 mayores exchanges que comercializan Nxt; Poloniex, BTC38y Bittrex han anunciado que van a hacer instantáneas internas de los saldos NXT de sus clientes sincronizados con la blockchain principal. Los tokens Ardor se distribuirán a sus dueños en una proporción de 1 token de Ardor por cada 1 NXT. Las casas de intercambio se preparan para recibir nuevos clientes, fuera de los Fintech y del mundo de las inversiones, que buscan comprar tokens NXT para recibir los futuros tokens Ardor directamente con sus monedas fiduciarias. Los clientes minoristas ahora son capaces de acceder a la compra de la plataforma Ardor utilizando sus monedas fiduciarias.

[menu_anchor name=”nxt-video-guides”][/fusion_text][fusion_text]Desarrolladores

The Nxt API
Nxt Blockchain Tutorial
nxt / source / — Bitbucket
https://nxtforum.org/core-development/

[/fusion_text][fusion_text]

nxt-hepdesk-250hiweb

 [/fusion_text][/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]

Distribución del token Nxt 2.0 

Han sido anunciados los detalles sobre la distribución del token Nxt 2.0.

nxt-ico kopi

Aquellas personas que han seguido Nxt 1.0 saben que el lanzamiento de Nxt 2.0 (Ardor) va a suponer un gran e importante paso adelante no sólo para Nxt, sino para la tecnología blockchain en general. Nxt 1.0 ya cuenta con una gran variedad de increibles y disruptivas funciones que están funcionando de manera estable sobre esta blockchain. El siguiente gran avance solucionará el problema del crecimiento desmesurado del tamaño de la blockchain, un problema intrínseco de todas las blockchains.

Esto podría convertir a Ardor en la primera cripto plataforma escalable de forma global. Además, Ardor permitirá a cualquier persona, empresa o comunidad lanzar su propia blockchain, de forma personalizada y completamente segura. A modo de resumen: el token de la cadena principal de Nxt 2.0 (ARDR) ‘forjará’ (~ stakear / ~ minar) todas las transacciones de las childchains, dotando a estas últimas de la seguridad porporcionada por toda la red Nxt. La primera childchain predeterminada de Nxt 2.0 (Ignis) se lanzará con el bloque génesis y consistirá en un nuevo “libro de contabilidad” que integrará todas la funcionalidades de Nxt 1.0.

La principal novedad de Nxt 2.0 es dividir la blockchain en dos. Una cadena principal (main chain) que se utilizará únicamente para la creación del consenso, y múltiples cadenas hijo (child chains) que mantienen los libros de contabilidad separados con las transacciones. Cada childchain usará su propio token/moneda.

En el anuncioJean-Luc escribe:

La rama Nxt 1.0 seguirá funcionando

La versión Nxt 1.9 va a ser el último gran lanzamiento de una versión dentro de la rama Nxt 1.0.

Nxt 2.0 no es un fork de Nxt 1.0. Los tokens NXT seguirán existiendo.
Los usuarios de la versión 1.0 podrán iniciar sesión en Nxt 2.0 con sus actuales contraseñas.

El equipo de desarrollo de Nxt se compromete a proporcionar apoyo a la versión 1.x durante un año después de la puesta en marcha de Nxt 2.0, como mínimo. Puede ser que se opte por dotar de nuevas funcionalidades al interfaz de usuario (GUI)  al cliente NRS.

La distribución de los tokens de la cadena principal Nxt 2.0

El equipo de desarrollo reconoce la enorme contribución de los inversores y poseedores del token original Nxt 1.0, sin los cuales Nxt 2.0 no sería posible y ha decidido concederles privilegios para estos nuevos tokens.

Ardor tokens

TODOS los tokens de la cadena principal (main chain) de Nxt 2.0 (ARDR) van a ser distribuidos entre los poseedores de los token Nxt 1.0

La versión de Nxt 1.9 se anunciará en breve, con un hardfork para la distribución de ARDR y sin cambios en las API.

La única manera de obtener ARDR es mediante la posesión de NXT en la cuenta durante el periodo de la fase instantánea (que comenzará cuando se lance la versión 1.9 de Nxt y estará en vigor durante los siguientes tres meses).

Jean-Luc escribe:

El Software Nxt empezará a tomar instantáneas periódicas de los saldos de NXT de todos los usuarios en intervalos regulares (probablemente una vez cada hora), durante un período de tres meses.

Para calcular el balance de NXT resultante, se calculará el promedio durante este periodo de tres meses y todas las cuentas quedarán acreditadas automáticamente con un activo, emitido dentro del Asset Exchange (Intercambio de Activos) de Nxt, dónde se reflejará el número de participaciones en ARDR.

Los activos ARDR podrán  comercializarse libremente.

La distribución de los verdaderos tokens ARDR estará basado en la propiedad de los activos ARDR de cada usuario en el mismo momento que se cree el bloque génesis de Nxt 2.0.

No será necesario destruir assets de Nxt 1.0 con el fin de recibir los tokens de ARDR o Ignis

Los tokens ARDR se usarán para forjar en Nxt 2.0 (es decir, staking/ minería). Estos tokens son los responsables de mantener y asegurar la red e incentivar a la gente que configure su propio nodo. Los usuarios de cualquier childchain de Nxt 2.0 tendrán que pagar las tasas de transacción a los titulares de ARDR.

Riker explica:

Los tokens ARDR tienen la habilidad de agrupar muchas operaciones de las child chains en un único bloque (childchain block) dentro de la cadena principal (main chain) (es decir, convertirse en un bundler) y forjar las transacciones en la cadena principal.

El lanzamiento de la cadena Ardor está previsto para el tercer trimestre de 2017.

IGNIS, los tokens de la childchain de Nxt

Presentando Ignis.

Como se ha indicado anteriormente, la versión Nxt 1.x continuará funcionando y conservarás todos los NXT que ya poseas.

La cadena equivalente a la versión 1.x de Nxt se lanzará junto al bloque génesis de Nxt 2.0, en un “libro de contabilidad” (ledger) nuevo. Su token para las transacciones ha sido apodado como Ignis y será el único token transaccional de la nueva red Nxt 2.0. hasta que se generen las nuevas childchains.

Los tokens de Ignis serán distribuidos del siguiente modo: ~ 50% para los poseedores de NXT y ~ 50% para el equipo de desarrollo.

El ~ 50% del total de los tokens Ignis que serán distribuidos al equipo de desarrollo se utilizarán para continuar financiando el desarrollo de la plataforma Nxt 2.0.

Jean-Luc escribe:

Los tokens Ignis se crearán en el bloque génesis de Nxt 2.0. En ese mismo momento, los titulares de NXT obtendrán un 50% de su balance en NXT en Ignis. El otro 50% se reservará para los desarrolladores para, por ejemplo, hacer una ICO o alguna otra cosa. Como esto sigue siendo a un año vista, todavía, se está debatiendo el método exacto de llevarlo a cabo.

Esto significa que, además de los tokens de la cadena principal (ARDR), a los poseedores de NXT 1.0 se les acreditará un número de Ignis (tokens de transacción en Nxt 2.0) equivalente al 50% de NXT que tengan en posesión cuando se lance Ardor, previsto para el tercer trimestre de 2017.

Como una advertencia a los traders, Riker comenta que: “Si mantienes tus NXT en un exchange será necesario que verifiques con el exchange la forma en que manejarán la distribución de ARDR e Ignis ya que serán distribuido a la cuenta del exchange. La casa de intercambio obtendrá los tokens ARDR / Ignis y decidirá qué hacer con ellos.”

Nuestro mejor consejo es que lo mejor es que mantengas tus NXT en su propia cuenta Nxt, conservando tu mismo tu contraseña (passphrase)

A los desarrolladores de Nxt – sentiros seguros de programar con Nxt

Nxt ha tenido problemas manteniendo la compatibilidad con versiones anteriores, debido a los preparativos para el cambio hacia Nxt 2.0 / Ardor

La API de Nxt 1.10.x no sufrirá cambios, por lo que todos los desarrolladores que trabajen con la API de Nxt 1.10.x pueden estar seguros de que su código seguirá funcionando en la rama 1.0. Además, si lo desean, podrán trasladar fácilmente sus proyectos de Nxt al nuevo libro de contabilidad de Nxt 2.0. El equipo de desarrollo Nxt está  dispuesto a ofrecer su ayuda en ese sentido, en caso de que fuera necesario.

Una excepción al compromiso de compatibilidad con las versiones anteriores es, según se anunció en el lanzamiento, la característica Nxt add-ons (disponible para desarrolladores a partir de la versión Nxt 1.8.0e), ya que necesitará someterse a “una refactorización significativa en la versión 2.0”.

Puedes testearlo, hacer pruebas con él, pero como Jean-Luc escribe: “Mantenga sencillo el código de sus add-ons, y esté preparado para adaptarlo a 2.0 o eliminarlo”.

Usted puede seguir el desarrollo de Nxt en nxtforum.org/ y, si tiene dudas sobre cualquier cosa, pregunte a los desarrolladores centrales.

Controversia sobre el reparto de (f)NXT en la v2.0

Estamos viviendo un 2016 muy intenso en la comunidad Nxt. El inicio ha sido marcado por un exitoso hardfork hacia la versión del SRN 1.7. proporcionando nuevas características y mejoras a la red, entre ellas el Coin Shuffling y los tiempos de bloque prefijados a 1 minuto, poniendo punto final a aquellos bloques que parecían atascarse en la Blockchain. Pero nos ha dejado la parte agridulce: a causa de los cambios efectuados en las API’s, y tras desapacibles discusiones, empresas como Supernet o Coinomat, dos ilustres dentro del Asset Exchange, decidieron poner punto y final a su relación con Nxt y empezar a trabajar en su propia Blockchain: Iguana y Waves, respectivamente.

Mientras tanto, los desarrolladores de Nxt llevaban tiempo planeando una nueva hoja de ruta: la versión 2.0 de NXT y no tardaron mucho en exponerla públicamente para su discusión. El modelo presentado hizo recordar a muchos de los presentes la idea de BCNext.

Básicamente Nxt 2.0 pretende ser un sistema escalable capaz de reducir la hinchazón de la Blockchain, solucionando los dos principales problemas de las blockchain en la actualidad. Un gran reto que cuenta con un año por delante para su desarrollo.

Riker:

Esto permite podar la actual Blockchain de Nxt a niveles mínimos

Todo apunta a un largo año de diálogos y contraposición de ideas. Poner de acuerdo a tantas partes no es tarea fácil y menos cuando se nada a contracorriente dentro de un mercado movido en gran parte por la especulación que, como era de prever, no tardó en reaccionar provocando una caída de precios. Recordemos que los NXT invertidos en los activos no pertenecen al balance. Varias personas decidieron abandonar Nxt, y otras fortalecieron sus posiciones aún más. Está clara una cosa; al mercado le encanta los cambios.

nxt-2.0

Sin tiempo para celebrar el exitoso hardfork de la versión 1.7, el anuncio del camino a seguir en la versión 2.0 supuso un giro de 180 grados. El concepto básico consiste en crear un token (f)NXT que poseerá el poder de forjado de la red Nxt, y los actuales tokens de NXT se convertirán en una childchain de los primeros, conservando las mismas características que ya disponía salvo la capacidad de forjado. De esta manera, al no tener que conservar la información correspondiente a la forja, la childchain NXT podrá ser podada, solucionando los problemas de escalabilidad.

La comunidad se vió inmersa en acaloradas discusiones acerca de cómo distribuir el futuro token de nueva creación exclusivo para el forjado(1NXT=1(f)NXT), suscitando opiniones controvertidas entre las partes más interesadas; usuarios, inversores, desarrolladores externos, ballenas, los desarrolladores del núcleo, emisores de activos, inversores de activos, forjadores y los holders.

Paralelamente a las conversaciones sobre la manera de distribución, Damelon hizo una encuesta, quizás motivado por la idea de un miembro que sugería trabajar en otros aspectos y dejar la escalabilidad y la hinchazón para cuando resultasen ser un problema.

Damelon: Do you want Nxt 2.0 to happen?
1-SI – 145.035.072NXT
2-NO – 57.092.131NXT

Es posible que la mayoría de los votantes tuviera en cuenta que Nxt no tiene el problema de escalabilidad e hinchazón porque actualmente su Blockchain está trabajando a mínimo rendimiento y, cuando llegase el momento, la manera de solucionar estos aspectos sería trabajando sobre múltiples Blockchain. (véase hipercube de ethereum). La idea de NXT 2.0 tomaba sentido.

La discusión sobre el momento de efectuar la captura, en caso de realizarse, dio lugar a la segunda encuesta de Damelon

Jean-Luc en uno de sus mensajes dejaba esta reflexión:

¿Cómo hacemos la transición, o re-distribución, sin causar daños, por ejemplo, a los precios de activos ni causar otros efectos económicos inesperados?

Durante los dos meses de discusiones se han barajado las siguientes posibilidades:

  • 1NXT=1(f)NXT en el momento del hardfork hacia la versión 2.0. Es la que toma más consistencia, el fork estaría previsto para enero de 2017, dando tiempo a todas las partes interesadas a obrar sus estrategias.

Allwelder y Sebastien256 no tardaron en dejar su claro punto de vista:

NO IPO. Solo apoyaré la decisión 1NXT=1(f)NXT. Es la mejor solución tanto para los usuarios activos como los que no. El Snapshot al mismo momento que el fork me parece la mejor opción

En mi opinión, todo lo que no sea una distribución 1:1 se convierte en un robo de las capacidades de los NXT de alguien. Simplemente por poseer los tokens NXT, posees y has pagado por el derecho de forja, aunque no estés forjando en este momento, en mi humilde opinión.

  • 1NXT=1(f)NXT en el momento del hardfork hacia 1.7

blackyblack1 comenta que esto sería un robo. Solo una decisión previamente anunciada sería una solución legítima.

  • Repartirlos a los poseedores del activo NSC (Next Security Coin)

Riker desmintió esta idea aportando el dato que actualmente hay una cuenta con el 99.98% de los activos y esto centralizaría el proceso de forjado.

  • Coretech propuso crear el nuevo token de forja he introducirlo en los nuevos bloques, a razón de aproximadamente 1000Tokens por bloque, así cualquier persona interesada en participar en NXT2.0 lo único que tendría que hacer es comprar NXT y empezar a forjar.

Jean-Luc no tardo en contestar y afirmó que era buena propuesta, pero ejecutarla, podría retrasar el desarrollo unos 6 meses, por lo tanto quedaba desestimada.

Las opciones expuestas, implican la creación de una masa monetaria nueva y jl777 en uno de sus últimos mensajes recalca:

Hablo en calidad de hombre de negocios, inversor y emisor de activos: En el próximo cambio fNXT: NXT, no existe mecanismo de división para los activos, por lo tanto  inmediatamente perderán la mitad de su valor, 1 + 1 = 2   NXT2.0 = (NXT fNXT)

Así que, además de obtener una pérdida inmediata de 50%, la situación podría empeorar en el caso de que el valor de NXT esté por debajo de la mitad de  NXT2.0 combinado + fNXT. Mi mayor prioridad es proteger a los millones de dólares invertidos en mis activos.

  • 0,5NXT futuros + 0,5(f)NXT para que no originar más masa monetaria. NXT2.0 es un ecosistema diferente a NXT 1.0 y por lo tanto tiene que tener un token diferente. Perder el 50% del poder de forja no es recomendable. A raíz de plantear distribuciones diferentes de 1:1 se pensó que podría ser un método de financiación.

Al mismo tiempo, fuera del ecosistema Nxt, las IPO forman parte del mainstream y consiguen atraer muchos recursos y miradas, al menos en estos meses previos al halving de Bitcoin. Esto a hecho a algunos plantear la posibilidad de intentar combinar el lanzamiento de fNXT con el de una IPO, para dotar de financiación a los desarrolladores y a los equipos que trabajan en la promoción de NXT, tales como la NXT Foundation. Este será un tema que trataremos en un próximo artículo”

En el momento de este artículo NXT está a 1640 satoshis en Poloniex.

No te pierdas la ultima jornada de preguntas y respuestas efectuada el día 12/04/16 http://pastebin.com/8UmKpYvE

Consigue publicarlo y obtén un salario

¿Cómo me pagan?

Te pagan en Nxterpoints (NXTP).

NXTP son puntos de fidelidad otorgados a los lectores que contribuyen a NXTER.ORG.

Como agradecimiento a su dedicación, donamos nuestros beneficios a los titulares del activo NXTP, en forma de dividendos. Debido a que hemos emitido y distribuido los NXTP en el Intercambio de Activos de Nxt , usted puede transferirlos, venderlos o simplemente mantenerlos y seguir ganando dividendos mes tras mes.

Los dividendos, se pagan en NXT al principio de cada mes, se financian con los ingresos generados por NXTER.ORG de cualquier fuente, incluyendo patrocinadores, publicidad, artículos y ventas de libros + otros servicios que nosotros (o usted) puede introducir en el futuro. Si usted decide dejar de contribuir a NXTER.ORG, todavía seguiremos pagando dividendos por sus NXTP, como muestra de agradecimiento por su lealtad y su anterior contribución.

¿Cómo puedo contribuir a NXTER.ORG?

Tus noticias o puntos de vista sobre sobre Nxt, moneda, plataforma o ecosistema económico. Tu código como desarrollador de servicios para NXTER.ORG o imágenes relevantes y/o diseño web para NXTER.ORG.

Si usamos o publicamos su contribución, se le otorgarán NXTP, dependiendo de la duración y / o la calidad de su trabajo.

Categoría 1 

Una entrada de blog

Categoría 2 

Un artículo en la primera página de Nxter.org

Categoría 3 

Una actualización inédita de noticias o descripción de los activos

Categoría 4

Traducción

Categoría 5

Cualquier otra contribución que ayude a Nxt a través de NXTER.ORG. No dude en preguntar o proponer

 

Detalles sobre las categorías de contribución

Categoría 1: Una entrada en el blog

Los lectores pueden enviar mensajes en el blog de invitados.

Para cada entrada de blog aprobada, el contribuyente recibirá de 100 a 250 NxterPoints. La cantidad exacta dependerá de la calidad y la longitud de la entrada del blog.

Usted puede escribir cualquier cosa relacionada con Nxt, incluidos aspectos sociales o de negocio, que puedan incluir Nxt como moneda o como plataforma y el papel que puede o podría desempeñar.

Estamos constantemente buscando nuevas historias y personas que quieran expresar su punto de vista; por ejemplo; si usted está preocupado por la vigilancia, usted podría ser un emprendedor social, estudiante, desarrollador o activista. ¡También puede ser un bloguero interesado en cryptomonedas! Sea cual sea su punto de vista o perspectiva, si tiene algo que aportar, no dude en ponerse en contacto.

El equipo de Nxter.org está considerando invitar a las personas que tengan publicadas 3 o más entradas de blog para escribir de una manera regular en la página principal y poder ganar Nxterpoints adicionales.

Nos reservamos el derecho de modificar / borrar las entradas de blog. Antes de hacerlo, nos pondremos en contacto con usted por correo electrónico (suponiendo que nos ha proporcionado su dirección de correo ) o de otra manera como por ejemplo mediante la mensajería del cliente Nxt.

 

Categoría 2: Artículo en la primera página de Nxter.org

  • Hasta 750 palabras: 200 a 300 puntos de fidelidad.
  • De 750 a 1000 palabras: 300 a 400 puntos de fidelidad.
  • 1000 palabras y posteriores: 400 hasta 500 puntos de fidelidad.

Siempre estamos interesados en nuevas historias y personas que quieran compartir sus conocimientos y opiniones sobre cualquier cosa relevante para Nxt, sea como criptomoneda, como token o como sistema financiero.

¿Tienes una buena historia que contar o un punto de vista que desea expresar? o ¿hay algo que usted piensa que debamos saber?

Quizás ya has escrito tu artículo y ahora estás buscando publicarlo. O tal vez ¿te gustaría formar parte de nuestro equipo de escritores y encargarte de escribir los artículos?

Estamos siempre dispuestos a recibir artículos no solicitados para su posible publicación.

No dude en ponerse en contacto en cualquier momento.

La cantidad exacta de NXTP otorgados en la categoría 2 dependerán de la cantidad y la calidad de la edición requerida.

 

Categoría 3Una publicación inédita de nuevas noticias o descripciones de activos.

¿Acabas de leer alguna noticia de última hora en los foros? ¿Tienes alguna noticia rompedora?

Tal vez usted ha oído algo de alguna fuente de información privilegiada o tal vez usted está a punto de lanzar un nuevo activo en el intercambio de activos o, por el contrario, usted acaba estafado por un activo fraudulento y quiere dar la alarma sobre el mismo. Sea lo que sea, háganoslo saber (vea las notas de abajo para obtener más información del contacto) y si publicamos lo que nos envía, se le adjudicarán 25-100 NxterPoints, la cantidad exacta dependerá de nuestra evaluación acerca de su valor informativo.

Si se trata de una historia o un comunicado de prensa sobre un proyecto suyo y que a usted le gustaría dar a conocer (¡ estamos dispuestos a poder satisfacer siempre que sea posible!) Por favor, utilice el formulario de contacto (no remunerado).

 

Categoría 4: Traducción

Nxt es un fenómeno global que queremos celebrar

El sitio principal es en inglés, pero Nxter.org ha ampliado sus fronteras hasta albergar un total de 10 idiomas!

El sitio francés (http://test.nxter.org/fr) se puso en marcha como prueba y estamos orgullosos de decir que lo consideramos un éxito, gracias a eso, decidimos lanzar los otros idiomas. Nosotros sólo pagamos por traducciones donde hay un mercado local (que podemos aprovechar) y una gran parte de ese mercado no entienda el inglés. Sin embargo, estamos siempre abiertos a sugerencias sobre otros idiomas, por lo que si usted piensa que esto se puede ampliar (y usted puede contribuir a hacerlo) por favor póngase en contacto con nosotros.

Los editores locales no solo publican artículos originales en su propio idioma, también traducen contenidos de nxter.org en su propio idioma.

Queremos reflejar la descentralización de Nxt. También ocurre que nxter.org hace “campañas” para que se publiquen los artículos en todos los idiomas al mismo tiempo (por ejemplo, sobre las nuevas funciones principales Nxt o como un servicio de pago a las empresas Nxt).

 

Categoría 5: Cualquier otra contribución que ayude a Nxter.org

Cuéntanos que podemos necesitar de usted.

Siempre estamos abiertos a sugerencias. ¿Eres bueno con el uso de redes sociales o con los comunicados de prensa? Enviamos material a otros medios también. ¿Eres un artista que puede hacer las imágenes más destacadas para los artículos que nosotros? ¿Un desarrollador que no puede soportar ver que no somos capaces de vender productos digitales del mercado Nxt en nuestro sitio, pero, sin embargo no tiene los medios que tenemos nosotros? Tal vez lo que desea es una lluvia de ideas o invertir horas en construir un negocio paralelo al nuestro dentro de NXTER.ORG. Estamos abiertos a nuevas asociaciones.

Cuéntanos si tienes una buena idea o los conocimientos para ejecutarla.

 

Notas para todos los contribuyentes

Los mensajes de blog de los lectores se publican directamente, están sujetos a revisión por parte del editor.

Por favor envíe previamente noticias publicadas utilizando el formulario de contacto Breaking News.

Por favor, envíe todas las contribuciones destinadas para su posible publicación en la página principal de NXTER.ORG AQUÍ.

Los traductores y contribuyentes de la categoría 5 (para cualquier otra contribución), por favor contacten mediante este formulario de contacto.

Todas las contribuciones de cualquier tipo presentadas por el contribuyente como por el autor, deben ser su trabajo original y no haber sido publicado anteriormente.

La edición de las contribuciones se centra principalmente en la prueba de lectura para errores tipográficos y hacer cambios (gramaticales o estilísticos) con el fin de aclarar el significado.

Sin embargo, el trabajo del editor es también (cuando sea posible) ayudar a asegurar que las contribuciones son correctas. Un hecho es una afirmación que puede ser demostrada objetivamente, verdadera o falsa; es decir, es objetivamente verificable.

Una opinión es una declaración de la creencia o juicio que no puede ser probada objetivamente verdadera o falsa; es decir, no es objetivamente verificable. Ver más: http://en.wikipedia.org/wiki/Fact y http://en.wikipedia.org/wiki/Opinion

Todos tenemos derecho a nuestras propias opiniones, y de hecho queremos que los autores se expresen libremente, pero no tenemos derecho a nuestra propia realidad.

A los autores se les pide que comprueben los hechos de sus contribuciones antes de su presentación.

Cuando un “hecho” todavía no se ha demostrado, ya sea verdadero o falso, es una hipótesis y debe ser referido como tal. Se supone que el autor está familiarizado con el tema en relación y con cualquier hipótesis que se refiera, por lo que será capaz de citar la información relevante sobre el tema a tratar con fuentes dignas de crédito (a la que, en los casos necesarios, los lectores pueden ser referidos, ya sea a través de los enlaces en el artículo o en las respuestas a los comentarios de este artículo)

Las preguntas para considerar la credibilidad de una fuente de información incluyen:

  • ¿Parece bien investigada la información que se presenta como un hecho?
  • ¿La información se cita de una manera lógica?
  • ¿El autor parece objetivo e imparcial?
  • ¿La información comparada con otras fuentes, ¿es aparentemente creíble?
  • ¿El autor cita referencias?
  • ¿La información incluye opiniones disfrazadas de hechos?

Las contribuciones publicadas en nxter.org pueden ser vueltas a publicar por:

  • NXTER.ORG en cualquier forma.
  • El contribuyente, siempre que NXTER.ORG sea reconocida como el lugar original de publicación, por ejemplo: publicado en http://test.nxter.org

NXTER.ORG no se responsabiliza por el valor futuro de Nxterpoints / NXTP. Los aportes le dan su valor. NXTP son comerciables en NxtAE. Los dividendos se pagarán en Nxt o cualquier otra criptomoneda basada en la plataforma Nxt. NXTER.ORG puede estipularlo en el futuro.

Cualquier cambio en los términos y condiciones anteriores se dará a conocer al menos 1 mes de antelación sobre NXTER.ORG en todos los idiomas destacados.

Para obtener más detalles acerca de la distribución mensual NXTP, haga clic aquí.

La cuenta de emisión es: NXT-EAVH-VESL-KSEE-EE2KP. LA ID del activo NXTP es 17290457900272383726.