NXTER.ORG

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.

Diseño Nxt 2.0

El software de referencia Nxt (NRS) recientemente ha completado con éxito un hardfork y ha sido actualizado a la versión NRS 1.7.5, lo que le ha aportado importantes y novedosas características tales como: tiempo de transacción establecido en 1 minuto, activos del tipo “Singleton”, mezclado de monedas, control de cuentas mediante transacciones condicionadas y datos en la nube. Todo funciona de manera estable y sin contratiempos, y por esto los desarrolladores del núcleo de Nxt han comenzado a hacer un brainstorming acerca de como deberá ser la futura versión NRS Nxt 2.0.

2.0 estará centrado en la escalabilidad. La idea es crear cadenas laterales dependientes de la blockchain principal.

Jean-Luc, desarrollador principal de Nxt, escribe:

Desde hace algún tiempo hemos estado haciendo brainstorming sobre el diseño de Nxt 2.0, y aquí presentamos nuestra propuesta actual. Este es un resumen general, del cual todavía desconocemos muchos detalles. Las decisiones de diseño más específicas se irán tomando conforme se avance en el desarrollo. Lo que proponemos es un cambio significativo en la plataforma, no solamente en un conjunto de nuevas características. Por tanto, nos llevará bastante tiempo para materializarlo.

– Se creará una nueva cadena principal, en la cual NXT se convertirá en un token (“forgingNXT” o “fNXT”) usado únicamente para forjar. El actual ecosistema NXT se transformará en una cadena hija (child chain), conservando todas sus características y propiedades, excepto la capacidad para forjar. En el bloque en el que se produzca el hard-fork, cada propietario de NXT verá sus NXT convertidos en ambos tokens en proporción 1:1 y todas sus propiedades se migrarán a esta “child chain” de NXT.

– Siempre será posible intercambiar NXT por fNXT, de modo que los pequeños inversores que no estén interesados en la forja pueden optar por vender sus fNxt a los grandes accionistas que ejecutan nodos de forja. Esto nos llevaría a una cierta centralización, pero también a un mayor porcentaje de poseedores de fNXT forjando, asegurando así el ecosistema completo de NXT.

– Las “child chains” usarán el mismo código que Nxt pero, en caso que así se quiera, cada una puede ser configurada para que solo disponga de una parte de las características. En la “child chain” de NXT se podrá seguir realizando cualquier tipo de transacción.

– Cada “child chain” tendrá su propio token / moneda, con la cual se realizarán las operaciones de pago, se establecerán las órdenes de compra y venta de activos, se pondrá precio a los bienes digitales, etc. Las comisiones de transacción de la “child chain” serán también en este token nativo.

– Todas las transacciones de todas las cadenas deberán ser procesadas por todos los nodos. Todos los nodos van a acarrear todas las “child chains” durante al menos los últimos 1440 bloques. Los nodos de archivos (archival nodes) pueden optar por almacenar una o más “child chains” durante un periodo más largo de tiempo, o hacerlo indefinidamente.

– Por defecto, las transacciones realizadas en las “child chains” se “podarán” completamente después de 1440 bloques, en aquellos nodos no específicamente configurados para archivarlas por más tiempo. Un nuevo nodo que inicie la descarga de la blockchain desde cero debe aceptar que si los forjadores y los nodos (que estaban ejecutando la blockchain en el momento en que todavía disponían de los datos que posteriormente iban a ser recortados) aprobaron esas transacciones con anterioridad, entonces el resultado de esas transacciones es válido, incluso aunque la información para validarlas de nuevo ya no esté disponible.

– Sin embargo, tiene que poderse validar que el balance efectivo fNXT de los forjadores era realmente el que decían tener. Esta es la razón por la cual las transacciones en la cadena de forjado que cambia el saldo fNXT no pueda podarse, y debe reducirse a un mínimo esencial de transacciones.

– Los bloques de la “child chain” se implementarán como un añadido “podable” de una única transacción (una por cada bloque y por cadena) del tipo “ChildchainBlock” en la cadena de bloques principal. Cualquiera puede crear un bloque en una “child chain”. Sin embargo, depende de los forjadores que incluyen bloques en la cadena principal decidir si esa transacción “ChildchainBlock” debe ser incluida en un bloque. Los forjadores, al igual que todos los nodos, hacen una validación completa de todas las operaciones de la “child chain” incluidas en un ChildchainBlock, siempre y cuando los datos no han sido “podados” todavía.

– Si no ha habido transacciones en una cadena, no hay necesidad de crear una transacción “childchainblock” para ella, a diferencia de lo que sucede en la cadena principal, donde seguiremos teniendo los bloques cada 60s incluso aunque estén vacíos. Podemos pensar en reducir el tiempo de generación de bloques de la cadena con el fin de permitir que algunas “child chains” tengan bloques más frecuentemente.

– Los forjadores aceptarán las comisiones solo en fNXT, con la comisión mínima requerida por el protocolo para cada tipo de transacción también expresada en fNXT.

– Cuando un forjador incluye una transacción del tipo “ChildChainBlock” en la cadena principal, su creador paga una comisión en fNXT al forjador. El importe de esta comisión depende del creador del bloque en la “child chain”, pero debe ser al menos igual al total de las comisiones mínimas calculados en fNXT para cada transacción incluida. A cambio, el creador del bloque en la “child chain” recibe la comisión en el token nativo de esa “child chain”, pagado por los emisores de esas operaciones en esa “child chain”.

– La tasa de intercambio del token/moneda de la “child chain” al token fNXT será determinado por la ley de oferta y demanda. Si nadie estuviese dispuesto a incluir una operación de la “child chain” en un bloque de esa “child chain” significaría que la tarifa ofrecida en el token nativo no se considera equivalente a la comisión mínima fNXT requerida para esta transacción en particular, y dicha transacción expiraría sin confirmarse. Si el valor de la token nativo de la “child chain” se reduce a cero, nadie estará dispuesto a crear bloques de la “child chain”, y el proceso de las transacciones en esta “child chain” se detendrá.

– Las “child chains” competirán entre sí para su inclusión en un bloque, ya que al final los forjadores observarán la relación comisión / tamaño para cada transacción y querrán maximizar sus beneficios durante el forjado, dependientes del tamaño de bloque y del límite del número de transacciones.

– Antes de la “poda” cada nodo debe comprobar no sólo que el hash de la operación del bloque de la “child chain” coincide, sino que también debe comprobar si son válidas todas las transacciones de la “child chain” que contiene, es decir, asegurarse de que no hay ningún doble gasto, así como el resto de validaciones. Por eso el nodo necesita saber los saldos actuales de todas las cuentas de esa “child chain”. Pero todavía para poder hacer la poda necesitamos una operación de captura, que tome una instantánea del estado únicamente de la “child chain” en su estado actual, sin el historial de las operaciones que la llevaron a este estado. A continuación, después de que esta transacción ha sido aceptada en la blockchain por más de 720 bloques, podemos asumir que es válida, “podar” toda el historial de la cadena antes de esa captura, y desechar la captura anterior.

– La operación de captura para cada “child chain” se crea en intervalos regulares, tales como cada 1440 bloques, y se llevan a cabo por el forjador del bloque actual. Sólo contendrá el hash de la captura, no se capturarán todos los datos.

– Los datos de la captura en sí mismos no tienen que propagarse a través de la red cuando se crea la transacción de captura. Cada nodo que se encuentre actualizado ya cuenta con el estado de la “child chain” capturada, por lo que puede generar una captura por sí mismo. Sólo se debe validar que el hash calculado para el forjador de la captura de hecho coincide con su propia captura.

– Solo nodos que descargan la cadena de bloques desde cero necesitarán descargar la última captura al completo, y esta es una razón más por la que cada nodo debe generar y mantenerse alrededor de esta captura, para poder servir a estos nuevos nodos. La descarga de la captura puede ser de una manera similar a Torrent, diferentes piezas desde múltiples nodos.

– Debido a que cada nodo actualizado necesita validar todas las transacciones actuales, aún a pesar de que reducimos significativamente el problema a largo plazo de crecimiento de la blockchain (en términos de espacio en disco utilizado, y ancho de banda para descargar el blockchain desde cero), todavía habrá un cuello de botella en términos de la CPU, para procesar los datos de todas las cadenas, y el ancho de banda, para poder recibir y procesar las transacciones actuales de todas las cadenas. Pero puesto que los nodos no necesitan validar las antiguas operaciones en la “child chain” que ya han sido “podadas”, la descarga total de la blockchain desde cero debe ser más rápida y menos intensiva para la CPU.

– La cadena de forjado, que es común a todos los nodos, garantiza la seguridad incluso para las “child chain” que no tengan muchos usuarios y que tienen transacciones sólo ocasionalmente. A cambio cada una de las “child chains” podrá ser podada. Las “child chains” ya no necesitan conservar todo el historial de transacciones remontándose hasta el bloque génesis para ser seguras, porque no forjan..

– Como primer paso, vamos a empezar solamente con la cadena principal de forja, con la cadena NXT como única “child chain” de la anterior. Y tal vez una “child chain” en modo de pruebas. Una vez que las tengamos funcionando, implementaremos las características necesarias para ser capaces de crear dinámicamente nuevas “child chain”, o modificar las propiedades de las “child chains” existentes.

Este artículo está publicado originalmente en nxtforum.org.

Author: Jean-Luc. Participa en la discusión aquí:
https://nxtforum.org/core-development-discussion/nxt-2-0-design/

o en la sección en español del foro:

https://nxtforum.org/espanol-(spanish)/diseno-nxt-2-0/