NXTER.ORG

[ACTUALIZACIÓN IMPORTANTE] ¡El hardfork que viene con Nxt 1.7.4!

Cuenta atrás

¡Se aproxima el hardfork de NRS 1.7.4!

¡ACTUALIZA INMEDIATAMENTE TU NODO o quedarás aislado en un fork!

El tan esperado hardfork previsto en el Software de Referencia Nxt 1.7.4 ocurrirá en el bloque 621000, que tendrá lugar entorno al 21 de enero de 2015, momento en que se activarán nuevas características de Nxt.

Descarga la versión 1.7.4 de NRS aquí:
https://nxtforum.org/nrs-releases/nrs-v1-7-4/

Nuevas características

Jean-Luc, desarrollador principal de Nxt comentó:

Las nuevas características y mejoras en la serie 1.7 han sido documentadas en los registros de cambios desde la versión 1.7.0e hasta 1.7.3e, disponibles en la carpeta de changelogs.

Esto es un resumen de las características que se activarán tras el hard fork:

Mezclado de monedas (Coin Shuffling), un mezclador de monedas completamente descentralizado, para mejorar la privacidad de las cuentas.

Control de cuenta para transacciones condicionadas (phased transactions), el equivalente en Nxt a la multifirma.

Lanzamiento inmediato de ciertos tipos de transacciones condicionadas tras su aprobación.

Mejora del tiempo de generación de bloques, 60 segundos de media, por lo que son improbables largos tiempos por bloque.

Propiedades de cuenta, asignando un nombre arbitrario u otro tipo de valor a las cuentas de los usuarios.

Assets Singleton, útiles para intercambiar objetos que son únicos.

Comisiones dinámicas, proporcionales al tamaño relativo de la transacción.

Mejora en la apariencia de la interfaz del exchange

Datos en la nube (Data Cloud), añadiendo una interfaz gráfica y múltiples mejoras a la característica de etiquetado de datos, para de esta manera permitir la publicación y obtención de pequeños archivos, documentos o datos arbitrarios de una forma descentralizada y libre de censura. Esta característica no depende del hardfork y se podrá utilizar inmediatamente desde el momento en que se actualice a esta versión.

Cambios incompatibles en la API

Con la versión 1.6 se introdujeron algunos cambios incompatibles en la API. Los usuarios de la API que todavía utilicen las versiones 1.5.15 o anteriores deberían asegurarse de leer los registros de cambios de las versiones 1.6 así como los anuncios en el foro, antes de actualizar a la versión 1.7. Estos cambios no afectan a los usuarios finales que solo ejecutan su cliente NRS en su escritorio o nodo VPS.

Una lista detallada de los cambios introducidos en la API se encuentra en: https://nxtforum.org/nrs-releases/nrs-v1-6-2/msg199198/#msg199198, y los cambios también se han explicado en los registros de cambios de las versiones 1.6.0e, 1.6.1e y 1.6.2. Por favor, lea la información contenida en esos registros de cambios.

Resumen de cambios en la API

EvilDave / NxtFoundation redactó este resumen de cambios:

1. Cierto número de llamadas a la API, que hasta la versión 1.5.15 y anteriores devolvía información adicional que, como consecuencia, acarreaba una perdida de rendimiento, han visto modificado su comportamiento por defecto para que no devuelvan estos datos extras a menos que sean solicitados expresamente.

El formato de respuesta de la API no ha cambiado, solo los campos que se devuelven por defecto. Si tu código utiliza cualquiera de esas APIs y en algunas llamadas necesita esos campos adicionales, asegúrate de añadir el correspondiente parámetro “include” en esos sitios.

2. Las APIs getAccountTransactions y getAccountTransactionIDs, obsoletas en 1.5, se han eliminado en 1.6. Mejor usa getBlockchainTransactions en su lugar y asegúrate de utilizar correctamente las transacciones condicionadas. Las mejoras en getBlockchainTransactions, tales como ser capaz de obtener solo las transacciones condicionadas llevadas a cabo (o las no condicionadas), introducidas en 1.6.1e, deberían hacértelo más sencillo.

3. Algunas APIs ya no hacen un chequeo detallados de errores en los datos introducidos por el usuario. Las APIs que acepten tipos de objeto tales como cuenta, asset, o moneda, pero no necesitan obtener el objeto real, ya no comprueban automáticamente su existencia. Estas APIs devolverán ahora una lista de resultados vacia en lugar de un mensaje error, cuando se le introduzcan datos tales como por ejemplo un identificador de asset que no existe.

4. Las transferencias de assets a la cuenta Génesis se considera ahora como un borrado de esas participaciones en esos assets y, por consiguiente, ya no se pueden obtener usando la API getAssetTransfer. La quantityQNT del asset JSON devuelta por las APIs tal como getAsset ahora corrije ese borrado del asset. La
cantidad del asset original emitido se muestra como initialQuantityQNT en el asset JSON.

Los cambios incompatibles de la API arriba mostrados deben ser tenidos en cuenta a la hora de actualizar de 1.5.15 a 1.6.2. La API 1.7 será consistente con la 1.6.2 y no serán necesarios más ajustes.

Además de los ajustes en la API, hay dos cambios de importancia que tendrán lugar con el hardfork en 1.7, que requieren actuaciones y ser previstos con anticipación:

1. Para prácticamente todos los tipos de transacciones en 1.7, las comisiones que se apliquen ya no serán constantes (actualmente 1 NXT), sino que se basarán en el tamaño real de la transacción. Puesto que no es posible insertar el código con la lógica para el cálculo de las comisiones en cada cliente de la API, el modo de proceder recomendado es dejar al servidor determinar y usar la mínima comisión requerida, que se aplica cuando se emite una transacción con el parámetro feeNQT=0. Esta característica está completamente soportada en 1.6.2 y, por tanto, la migración a usar un sistema de comisiones calculadas en el lado del servidor ya se puede utilizar.

2. El tamaño máximo de los mensajes adjuntos permanentes (cifrados o no) se ha reducido significativamente, de 1000 bytes a 160 bytes. Si usas mensajes permanentes, sin importar el tipo de transacción a la que vayan unidos, necesitas asegurarte de que su tamaño no excede los 160 bytes. Puesto que las comisiones para los mensajes permanentes también se han incrementado significativamente y son proporcionales al tamaño real del mensaje, se recomienda encarecidamente cambiar a mensajes eliminables en su lugar. Para crear un mensaje como eliminable, el único cambio requerido es añadir el parámetro messageIsPrunable=true a la llamada API para la creación de la transacción. El formato JSON de la transacción es el mismo para mensajes permanentes y eliminables (este es el motivo por el que ambos no pueden coexistir en la misma transacción), por lo que no se necesitan cambios para analizar la respueta JSON. Los mensajes eliminables se eliminan por defecto pasados 90 días. Si tu aplicación necesita que estén disponibles más tiempo, o indefinidamente, puedes configurarlo en el archivo nxt.properties, y es también posible recuperar esos mensajes eliminables caducados desde nodos de archivo de la red Nxt. Los mensajes eliminables fueron presentados en la versión 1.5, y los nodos de archivo fueron presentados en la 1.6.2 por lo que, de nuevo, la migración de mensajes permanentes a eliminables puede comenzar ya, sin tener que esperar a la versión estable 1.7.

Por favor, visita este hilo del foro (en inglés) para más información y conversaciones acerca de
la transición a mensajes eliminables y los cambios en el cálculo de las comisiones.

También hemos puesto en marcha una lista de correo, para permitir una mejor y más directa comunicación con el equipo de desarrollo de Nxt. Así que si eres el responsable de un proyecto basado en Nxt, apúntate aqui:
http://nxt.org/cgi-bin/mailman/listinfo/nrs-development

Fuente: https://nxtforum.org/nrs-releases/nrs-v1-6-2/msg201497/#msg201497