NXTER.ORG

Cervezas, apuestas y la blockchain de Nxt

Supongamos que tienes un grupo de amigos con los que te reúnes un un bar de deportes para tomar una cerveza, ver eventos deportivos y hacer apuestas. Pues es posible hacer apuestas utilizando la blockchain de Nxt utilizando una sencilla aplicación Python que lo automatice todo.

En mi primer artículo presenté los conceptos básicos de la blockchain. Tal y como vimos, el principal valor de la cadena de bloques es la inmutabilidad de los datos contenidos en las transacciones almacenadas en cada bloque, a partir de los cuales se construye la blockchain.

Hoy quería mostrar como construir una aplicación de apuestas en python de manera sencilla pero funcional. Para esta aplicación es básico que los datos sean inmutables, pero en caso de que sea necesario que una apuesta se pueda cancelar, se puede modificar la app para incluir esta funcionalidad adicional.

Prerrequisitos:
NRS (Software de Referencia Nxt) 1.10.2: https://bitbucket.org/JeanLucPicard/nxt/downloads/Python 3 (o Python 2 con una ligera modificación). Una cerveza o dos (opcional).

Lógica de la aplicación

Un usuario emite una apuesta (transfiere una determinada cantidad de monedas NXT) a la cuenta de apuestas y le añade un adjunto público y sin encriptar. En el adjunto se debería incluir el identificador de la apuesta, dos puntos, y un número indicando su elección en la apuesta correspondiente. Pongamos un ejemplo: el bar de eventos deportivos crea una porra sobre qué equipo saldrá victorioso en un partido de fútbol. Le asigna un Identificador (ID) al partido, por ejemplo “30”.

Las opciones son:
“1” – gana el equipo de casa “2” – gana el equipo visitante. “3” – empatan.

Para apostar que gana el equipo de casa, el jugador debería enviar una transacción con una determinada cantidad de NXT, adjuntando un mensaje público sin encriptar (para que sea auditable) con el siguiente contenido 30:1

Cuando llegue el momento, el gestor de la apuesta ejecuta la app para localizar a los ganadores y realizar los pagos. El gestor puede quedarse una pequeña comisión por el servicio prestado.

Implementación

El servidor Nxt recibe las peticiones en el puerto 7876. Si por defecto lo ejecutas en el mismo equipo en el que ejecutas el código python debes enviar tus peticiones a http://127.0.0.1:7876/nxt

Para nuestra app necesitaremos importar unos pocos módulos y escribir la función para hacer consultas que se usará unas cuantas veces en la ejecución de la app.

import sys, json, re

def sendQuery(Query):
  from urllib import parse, request
  params = parse.urlencode(Query)
  headers = {"Content-type": "application/x-www-form-urlencoded", 
"Accept": "text/plain"}
  req = request.Request("http://127.0.0.1:7876/nxt", 
params.encode('utf-8'))
  response = request.urlopen(req)
  return response.read()
	
myAccount = "NXT-AAAA-BBBB-CCCC-DDDDD"
totalAmount = 0
serviceFee = 0.05
players = []
secretPhrase = "bla bla bla"

La función devuelve una cadena JSON que necesita ser decodificado, con transacciones y adjuntos que necesitan ser analizados. También se inician unas determinadas variables

A continuación debes pedirle a la cuenta con las apuestas que busque en todas las transacciones entrantes.

Esta es la solicitud que puedes enviar al servidor Nxt para ejecutar esto:Query = {‘requestType’: ‘getBlockchainTransactions’,

'account': myAccount, 'type': '0', 'subtype': '0', 'executedOnly': 'true'}

decode JSON and load it to a variable for further processing.

output = sendQuery(Query)
data = json.loads(output.decode('utf-8'))

Puesto que ahora ya contamos con todos los datos, ejecutamos un loop en la tabla para deshacernos de las transacciones que no necesitamos. Por ejemplo, no necesitamos procesar las transacciones salientes, así que continuamos nuestro loop desde el siguiente objeto

for i in data['transactions']:
  txAmount = i['amountNQT']
  txSender = i['senderRS']
  if txSender == myAccount:
      continue
  txRecipient = i['recipientRS']
  if txRecipient != myAccount:
      continue

A continuación extraemos los adjuntos, nos aseguramos de que no están encriptados y quitamos los espacios en blanco

  line = i['attachment']['message']
  lineIsText = i['attachment']['messageIsText']
  if line.strip() != "" and lineIsText == True:
    line = line.strip()

El siguiente paso es hacer concordar el mensaje enviado con la expresión regular. Tiene que satisfacer el formato “Número:Número”, el primer número puede contener hasta 3 dígitos.

    matchLine = re.match(r'(\d{1,3}:\d{1})(.*)', line, re.M|re.I)

Si el mensaje adjunto tiene un formato correcto, continuamos analizando…

La aplicación para las apuestas acepta hasta un máximo de 3 argumentos en la línea de comandos: identificador de juego, el número elegido que ha ganado, y un tercer parámetro opcional entre comillas para mostrar la combinación ganadora en el mensaje con el pago.

Por ejemplo, el anfitrión de la apuesta debe ejecutarlo del siguiente modo:

python3 bet.py 30 1 “El equipo local gana”

La aplicación analizará las transacciones con id 30 y premiará a los jugadores que eligieron ‘1’.
El tercer argumento se podría omitir: python3 bet.py 30 1

A continuación debemos calcular la cantidad de dinero que ha recibido nuestro, haciendo un listado diccionario de jugadores que adivinaron el número correcto, y calculando la suma total de dinero a distribuir una vez que el anfitrión ha recibido su comisión opcional.

    if matchLine:
      if matchLine.group(1).split(':')[0] == sys.argv[1]:
        totalAmount += int(txAmount)
        if matchLine.group(1).split(':')[1] == sys.argv[2]:
          d = {txSender: matchLine.group(1).split(':')[1], 
'amount': txAmount}
          players.append(dict(d))
afterFee = float(totalAmount - totalAmount * serviceFee)

Tenemos ganadores en la lista ‘players’ de los diccionarios, tenemos dinero para distribuir en el apartado ‘afterFee’, ahora dinos los pagos de premios procesados.

sumCorrect = 0
for i in players:
  for key in i:
    if i[key] == sys.argv[2]:
      sumCorrect += float(i['amount'])
for i in players:
  for key in i:
    if i[key] == sys.argv[2]:
      t = float(i['amount']) * (afterFee / sumCorrect)
      if t > afterFee:
        strSendAmount = str(int(afterFee))
      else:
        strSendAmount = str(int(t))
      if len(sys.argv) > 3:
        reply = sys.argv[3]
      else:
        reply = sys.argv[2]
      message = "Payout for correct bet in poll " 
+ sys.argv[1] + "; your reply: " + reply
      Query = {'requestType': 'sendMoney', 'recipient': key, 
      'amountNQT': strSendAmount, 'secretPhrase': secretPhrase, 
      'feeNQT': '100000000', 'deadline': '1440', 'broadcast': 'true', 
'message': message, 'messageIsText': 'true', 'messageIsPrunable': 'true'}
      sendQuery(Query)

No es necesario decir que la app se puede optimizar para procesar errores, cancelar apuestas u, opcionalmente, permitir otros parámetros en los mensajes adjuntos. Los mensajes adjuntos se pueden emitir desde el cliente Nxt (NRS) o desde un monedero online que permita enviar adjuntos

Para realizar transacciones en la blockchain de Nxt necesitas monedas NXT, que puedes adquirir directamente cambiando Bitcoin por Nxt o participando en el proyecto del “Nodo afortunado” ejecutando un nodo público de Nxt (Nxt server).

Para saber como participar en el proyecto del “Nodo afortunado”, por favor visita https://nxtforum.org.

Hay más de un centenar de llamadas API que se pueden solicitar al servidor Nxt. Una lista completa de parámetros obligatorios y opcionales así como ejemplos está disponible en https://nxtwiki.org/wiki/The_Nxt_API.

¡Salud!

blockchain-betting

Lotería en la Blockchain de Nxt programada en Golang

En mi primer artículo hice una introducción teórica de la blockchain, de lo que puede aportar para tu proyecto de software y los conceptos básicos para interactuar con la blockchain de Nxt en PHP.

Hoy voy a presentar un pequeño programa de lotería escrito en Go.

Requisitos previos:
Golang (testado con Go 1.6.2)
NRS 1.10.1 (https://bitbucket.org/JeanLucPicard/nxt/downloads/)

Este programa es completamente funcional y ejecuta un sorteo de lotería todos los domingos [1]. Originalmente fue escrito en PHP, las dos fuentes están disponibles para su descarga desde el Data Cloud de Nxt [2].

Lógica de la aplicación

Los boletos enviados por los usuarios en mensajes adjuntos son el suministro de datos para esta aplicación.

Un jugador de la lotería envía 10 NXT a la cuenta de la lotería adjuntando un mensaje público no encriptado con una secuencia de 5 números, entre el 0 y el 30, separados por comas. El mensaje adjunto tiene que ser público para que las recompensas sean auditables usando la blockchain.

La app hace una llamada al servidor NXT para que le proporcione todas las transacciones desde la cuenta de la lotería, clasificándola y seleccionando únicamente las transacciones válidas para así crear un trozo de mapa (conjunto multidimensional en PHP) de todas las cuentas de los jugadores y de sus cadenas de números.Esto también calcula la suma total, de Nxt, a pagar a los jugadores calculando la suma total de todos los boletos validados.

La app, una vez que ha recibido todos los datos válidos, ejecuta 3 rondas de lotería. Cada una de esas rondas recibe una porción, de la suma total disponible para los pagos, a repartir entre los ganadores. En la ronda de 5, la aplicación encuentra los usuario que han adivinado correctamente los 5 números y envía las recompensas. En la ronda 4, la aplicación hace lo mismo para los usuarios que han adivinado 4 números, el monto restante de los boletos participantes es ahora menor que la del ganador(es) de la ronda 5. Se repite lo mismo para la ronda 3.

Esta es la esencia de como funciona la aplicación.

Un poco más sobre el funcionamiento interno

Para cada una de las tres rondas, la lotería genera secuencias de 5 números y las compara con las cadenas de números de los boletos hasta que encuentra uno o más ganadores. Se puede decir que la lotería “fuerza” encontrar una secuencia ganadora del boleto(s).

Con un número limitado de usuarios esto parece ser la única manera sensata para ejecutar una lotería y no tener que recoger y guardar un premio gordo durante meses y/o años.

Vamos a echar un vistazo a la función que genera la secuencia de los 5 números y devuelve una matriz de ellos a la función de llamada. Esta función se invoca un promedio de cientos de miles de veces para encontrar la secuencia de 5 números en una de las entradas cuando tenemos un número muy limitado de participantes. Se tarda una fracción de segundo. En PHP se necesita un poquito más de tiempo (uno o dos segundos), aunque el rendimiento de PHP 7 es realmente bueno.

func genFive(seed string) [5]int {
   var r [5]int
   seedInt, _ := strconv.Atoi(seed)
   d := false
   for a := offset; a < offset+5; a++ { 
      rand.Seed(int64(seedInt + offset)) 
      var dup [31]int 
      d = false 
      r[0] = rand.Intn(31) 
      r[1] = rand.Intn(31) 
      r[2] = rand.Intn(31) 
      r[3] = rand.Intn(31) 
      r[4] = rand.Intn(31) 
      for _, v := range r { 
         dup[v]++ 
      } 
      for k, _ := range dup { 
         if dup[k] > 1 {
            d = true
         }
      }
      offset = offset + 5
      if d == false {
         return r
      }
   }
   return r
}

Una característica importante de la lotería en la blockchain es que tiene que ser completamente transparente.
Todo el mundo debe poder validar que los resultados de la lotería no han sido alterados. Una solución lógica y simple a esto es generar secuencias de números con una semilla determinista.

El problema con las semillas deterministas es que, si se sabe de antemano, las secuencias de números se puede predecir y , a se podría llegar a hacer trampas en la lotería. Para hacer frente a este problema volvemos de nuevo a la Blockchain de NXT, para encontrar una fuente de semilla con la función getSeed().

func getSeed() (string, string) {
 type BlockchainStatus struct {
    NumberOfBlocks int `json:"numberOfBlocks"`
 }
 var status BlockchainStatus
 if seedBlockOutput, b := 
sendQuery("requestType=getBlockchainStatus", 
true); 
b != false { if err := 
json.Unmarshal([]byte(seedBlockOutput), &status); 
err != nil {
     fmt.Println(err)
   }
  }
 seedBlockHeight := 
strconv.Itoa(status.NumberOfBlocks - 11)

 type BlockId struct {
  Block string `json:"block"`
 }
 var block BlockId
 if seedBlockId, b := 
sendQuery("requestType=getBlockId&height="
+seedBlockHeight, true); b != false {
if err := json.Unmarshal([]byte(seedBlockId), 
&block); err != nil {
         fmt.Println(err)
    }
  }
 seed := block.Block[len(block.Block)-5:]
 return seed, seedBlockHeight
}

La app se ejecuta cada domingo a las 18:00 UTC.

Lo primero que esto hace en la función getSeed() es ir a buscar la identificación del bloque que se generó 10 bloques antes del inicio de la aplicación (como se puede ver en la copia local de la blockchain en el nodo de la lotería) y obtener los últimos 5 dígitos de la ID del bloque como semilla. Debido a la latencia de la red y las reorganizaciones ocasionales de la blockchain (de 1 a 3 bloques) el nodo de la lotería puede que no vea la misma información que los otros nodos. El número 10 para obtener el bloque de la semilla fue escogido por la razón que debemos estar razonablemente seguros que este bloque no será reorganizado.

Puede afirmarse que existe la posibilidad teórica de que pueda predecirse el identificador del bloque. En mi opinión, las posibilidades de que esto suceda son muy bajas, pero dejo a los lectores que lo debatan y decidan por ellos mismos.

Ahora que la App tiene su propia semilla, puede realizar su función de manera que los usuarios no necesiten confiar en el organizador de la lotería.

El código fuente “Go” no incluye la rutina de verificación de los resultados anteriores.
El código fuente “PHP” lo tiene, es totalmente funcional y se puede utilizar para verificar, de manera independiente, todos los resultados anteriores con las semillas deterministas de la blockchain.

Para “Go” yo uso la función de enviar y retornar solicitudes al servidor Nxt.

func sendQuery(Query string, Active bool) 
(output string, b bool) {
   output = ""
   b = false
   if Active == false {
      output = "Function disabled"
      return
   }
   body := strings.NewReader(Query)
   req, err := http.NewRequest("POST", 
"http://127.0.0.1:7876/nxt", body)
   if err != nil {
      output = fmt.Sprintf("%s", err)
      return
   }
   req.Header.Set("Content-Type", 
"application/x-www-form-urlencoded")

   resp, err := http.DefaultClient.Do(req)
   if err != nil {
      output = fmt.Sprintf("%s", err)
      return
   }
   bo, err := ioutil.ReadAll(resp.Body)
   defer resp.Body.Close()
   output = fmt.Sprintf("%s", bo)
   match, _ := 
regexp.MatchString(".*errorDescription.*", 
output)
   if match == true {
      fileHandle, _ := 
os.OpenFile("./error.log", os.O_APPEND, 0666)
      writer := bufio.NewWriter(fileHandle)
      defer fileHandle.Close()
      fmt.Fprintln(writer, output)
      writer.Flush()
      return
   }
   b = true
   return
}

Los resultados son recibidos como una cadena JSON y necesitan estar ordenados con una estructura apropiada.

validPlayers := make([]map[string]string, 0)

lotteryAccount := "NXT-YXC4-RB92-F6MQ-2ZRA6"

type Attachment struct {
   Message       string `json:"message"`
   MessageIsText bool   `json:"messageIsText"`
}

type Transaction struct {
   Timestamp   int        `json:"timestamp"`
   AmountNQT   string     `json:"amountNQT"`
   ID          string     `json:"transaction"`
   SenderRS    string     `json:"senderRS"`
   RecipientRS string     `json:"recipientRS"`
   Attached    Attachment `json:"attachment"`
}

type Response struct {
   Transactions []Transaction 
`json:"transactions"`
}
Query := 
"requestType=getBlockchainTransactions&account=" +
lotteryAccount + 
"&type=0&subtype=0&executedOnly=true"

if v, a := sendQuery(Query, true); a == true {
   var transactions Response
   if err := json.Unmarshal([]byte(v), 
&transactions); err != nil {
      fmt.Println(err)
   }

 p := 0
 for k, _ := range transactions.Transactions {
    // code to check tickets for validity.
    // if transaction satisfies all criteria 
    // add it to the slice of valid tickets.
		
    validPlayers = append(validPlayers, 
make(map[string]string))
    validPlayers[p][txSender] = lotteryNumbers
    p++
			
   }
}

Ahora que “validPlayers” tiene todas las entradas correctas podemos iniciar el juego.

process() recibe un número entero (5, 4, o 3) y otros parámetros, incluyendo validPlayers y ejecuta tres rondas de la lotería. Se hace una llamada a la función getWinners(), que se llama genFive() para generar secuencias de números hasta que se encuentre al menos un ganador. getWinners() devuelve los resultados a process() y este es el encargado de: enviar la recompensa, eliminar el boleto ganador y devolver las entradas restantes a main() para rondas posteriores. Hay una función auxiliar denominada preparePlayers() que recrea validPlayers sin los espacios vacíos liberados por las entradas eliminadas.

Animo a todos los programadores que programen en el blockchain NXT. Es muy sencillo gracias al enlace API de todas sus funcionalidades del núcleo. https://nxtwiki.org/wiki/The_Nxt_API

Mi próxima aplicación será probablemente una aplicación de votación, con registros de votos inmutables y guardados en la blockchain. ¿Cree usted que una aplicación como esta puede resultar útil en el mundo moderno? Por cierto, Nxt tiene incorporado su propio sistema de votación. Es muy fácil olvidar lo que Nxt tiene, porque dispone de muchas características que son accesibles a través de la API, que se encuentra amablemente programada por los desarrolladores del núcleo de Nxt para favorecer su uso. Puedes ‘mínar’ tus primeras monedas NXT para enviar las transacciones al proyecto del nodo de la suerte que se ejecuta en un nodo público, acude a nxtforum.org y encontrarás la manera.
Por favor, dejen sus sugerencias y comentarios.

 


1. Lotería en nxtforum.org.

2. Para acceder al Nxt Data Cloud (Nube de datos de Nxt), descargue e instale el NRS (Nxt Reference Software 1.10.1) y busque la palabra clave lottery. Puedes descargar el código fuente desde cualquier servidor Nxt con las API abierta, por ejemplo:

Go-> http://23.94.134.161:7876/nxt?requestType=downloadTaggedData&transaction=7872865106538381099&retrieve=true PHP: http://23.94.134.161:7876/nxt?requestType=downloadTaggedData&transaction=13031806327722095646&retrieve=true

DE VUELTA AL POST.

Programando en la Blockchain de Nxt por diversión y para obtener ganancias

Las cadenas de bloques o blockchains son útiles para múltiples aplicaciones, permitiendo llegar a una audiencia global y reforzando la infraestructura interna de una compañía. Una blockchain es una base de datos distribuida, dónde una copia de esta cadena de bloques está almacenada en cada uno de los nodos de una red entre pares (red peer-to-peer o p2p). Esta redundancia extrema podría ser considerada ineficiente pero, por favor, déjame que te explique brevemente un poco de teoría sobre las blockchains.

Puesto que cada nodo valida todas las transacciones almacenadas en la blockchain y dado que las transacciones pasadas no pueden ser deshechas ni alteradas como sucede en los tradicionales Sistemas de Gestión de Bases de Datos Relacionales (RDBMS por sus siglas en inglés), esta redundancia convierte a la blockchain en “inmutable”, siendo este uno de los grandes valores de las cadenas de bloques. La inmutabilidad de la información es algo que las bases de datos tradicionales no pueden proporcionar. Puede que necesites, o no, esta inmutabilidad de los datos, así como una una confirmación, sin tener que confiar en terceros, de que los datos no han sido alterados.

En este tutorial presupongo que esto es lo que necesitas.

Una de las cadenas de bloques más versátiles y flexibles es la blockchain de Nxt (https://nxt.org). Cuenta con más de un centenar de llamadas API https://nxtwiki.org/wiki/The_Nxt_API.

En esta ocasión te voy a mostrarlos conceptos básicos para programas en la blockchain de Nxt. Sólo voy a usar dos llamadas API en este tutorial. Dado que existen más de un centenar de llamadas API posibles, las oportunidades para los programadores no tienen límite.

Lógica de aplicación

Un cliente de una compañía o un empleado de una organización sube un archivo a través de un formulario web.

El archivo es renombrado para dotarlo de un nombre único y es almacenado en algún lugar del servidor.

Un año más tarde el cliente / empleado necesita verificar, usando la blockchain de Nxt, que el archivo no ha sido alterado. Por ejemplo, esto puede ser necesario por motivos legales. No tiene porque ser sólamente archivos. A los memorandos internos de la compañía se les puede aplicar un algoritmo hash y ser incorporados a la base de datos, para poder ser verificados en una futura auditoría.

Nxt nos permite enviar y almacenar mensajes arbitrarios (M.A.) en su cadena de bloques.

Cada transacción en la blockchain acarrea una tasa o fee. Si el tamaño de la transacción es grande, podría ser caro. Afortunadamente Nxt tiene un subtipo de M.A. llamado mensaje podable. Estos mensajes son “podados” o eliminados pasados 90 días, lo que los hace más baratos. También sería posible recuperar estos mensajes pasados 90 días a partir de los Nodos de Archivo.

El tamaño máximo de un mensaje arbitrario en la blockchain de Nxt es de aproximadamente 42Kb, el tamaño de un bloque. Un mensaje podable de 1KB cuesta 1 NXT (0,03$). 1KB es suficiente para almacenar el hash de un archivo y este será nuestro coste final para almacenar permanentemente un hash en la inmutable y distribuida cadena de bloques de Nxt.

Tan pronto cómo el cliente sube el archivo yo creo un hash del tipo SHA256 del archivo y lo almaceno este hash en la base de datos del servidor de la organización. Por sencillez yo he elegido SQlite, pero puedes usar Mysql, Postgresql, Oracle. Usaré la extensión Objetos de Datos de PHP (PDO por sus siglas en inglés) para acceder a la base de datos SQlite en PHP.

Cuando no utilizamos la base de datos inmutable (blockchain), el archivo puede ser modificado, almacenarse en la base de datos el nuevo hash del archivo modificado, haciendo difícil demostrar que el archivo era el mismo que en un principio.

La blockchain viene al rescate

Cada mensaje podable se puede recuperar desde los nodos de archivo. Cada registro de la blockchain es inmutable. Puedes estar seguro de que el hash del archivo que subiste hace un año será el mismo cuando lo descargues de la cadena de bloques. Todo lo que necesitas hacer es compararlo con el hash del RBDMS interno de la organización.

Prerrequisitos:

PHP con curl, json y algún tipo de extensión de la base de datos (yo uso sqlite3). Un servidor web es opcional, puedes utilizar php-cli. Java 8 (Oracle o OpenJDK para ejecutar Nxt). Software de Referencia Nxt: https://nxtforum.org/nrs-releases/nrs-v1-10-1/.

Instala el Software de Referencia Nxt (NRS por sus siglas en inglés. Dependiendo del contexto se le llama indistintamente Cliente Nxt o Servidor Nxt) y crea una cuenta. Dótala con unas pocas monedas. Puedes intercambiar Bitcoin por Nxt en un servicio de exchange como https://shapeshift.io o intercámbialas directamente con otros usuarios en https://nxtforum.org. También es posible “minar” algunos NXT gratis como recompensa por tener un nodo: http://test.nxter.org/the-forging-bounty-lottery-campaign-will-pay-5-million-in-rewards-to-forgers-and-nxt-nodes/.

Primero creamos una base de datos sencilla para nuestra aplicación, nada extraordinario, si necesitas almacenar más información puedes añadir más columnas. A mí me gusta utilizar el navegador de bases de datos (DB browser) para SQLite de http://sqlitebrowser.org.

Vamos a crear una base de datos vacía llamada ‘files.db’ y la guardamos en /home/lurker10/phptutorial/files.db

Usando el DB browser para SQLite crea la siguiente tabla:

CREATE TABLE "files" (
`id` INTEGER PRIMARY KEY AUTOINCREMENT,
`txid` TEXT,
`hash` TEXT,
`uploadtime` TEXT,
`filename` TEXT
)

‘txid’ es el campo para almacenar el id de la transacción que recibimos de Nxt cuando la transacción es aceptada. Es único. ‘hash’ es el hash sha256 del archivo.

En este tutorial me voy a saltar la parte del código de subida de archivos para hacerlo más breve.

Vamos a suponer que el archivo ya ha sido subido y almacenado en el servidor web. Definimos la variable para la ubicación del archivo en el código:

$uploadDir = "/home/lurker10/phptutorial/tmp/";
$fileName = "copy12345.tar";

Por defecto, el servidor Nxt recibe las solicitudes API en el puerto 7876. Si lo estás ejecutando en la misma máquina que tu código php, tu código debe enviar solicitudes a http://127.0.0.1:7876/nxt

Las otras variables importantes son la contraseña de la cuenta de Nxt que has creado y dotado de fondos previamente, así como la cuenta del receptor.

Puedes enviarte un mensaje a ti mismo, puesto que el receptor puede ser tu misma cuenta.

$host = "http://127.0.0.1:7876/nxt";
$secretPhrase = "tu contraseña";
$recipientID = "NXT-XXXX-XXXX-XXXX-XXXXX";

La siguiente parte del código es la función que envía la consulta usando curl en una solicitud POST.

Para hacer una solicitud debemos definir las variables $payload y $payload_string y después alimentarlas para sendRequest(). Es posible ejecutar el Nxt Server sobre HTTPS y usar curl para verificar el certificado SSL, pero para hacer esta app más sencilla hemos desactivado la verificación SSL en la conexión curl.

Otro punto de interés es la descripción de $error, con descodificado json desde la respuesta del servidor.

Si hay un problema con la solicitud (“No hay fondos suficientes” en tu cuenta cuando el saldo es cero), tienes que añadir una rutina para el manejo de los errores. Voy a omitir esto también. Para esta app asumo que el servidor responde como corresponde, y devuelve la respuesta a la aplicación para su posterior procesado.

function sendRequest($host, $payload, $payload_string) {
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $host);
curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "POST");
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, FALSE);
curl_setopt($ch, CURLOPT_CONNECTTIMEOUT_MS, 10000);
curl_setopt($ch, CURLOPT_TIMEOUT_MS, 10000);
curl_setopt($ch, CURLOPT_POST, count($payload));
curl_setopt($ch, CURLOPT_POSTFIELDS, $payload_string);
$output = curl_exec($ch);
$curl_error = curl_error($ch);
curl_close($ch);
$errorDescription = trim(@json_decode($output)->errorDescription);
if ($errorDescription != "") { // perform error handling; return false; }
return $output;
}

Puesto que este archivo ya ha sido subido, creo un hash a sha256 del archivo y su marca de tiempo (timestamp):

$fileHash = hash_file("sha256", $uploadDir.$fileName);
$txTime = time();

Usaré PDO para trabajar con la base de datos.

Abre la base de datos e inserta una nueva entrada.

No sabemos el txid (identificador de transacción) hasta que hablamos con el servidor Nxt, que nos lo puede dar cuando la transacción ha sido aceptada en la red Nxt, así que por el momento insertar null para el txid.

$pdo = new PDO('sqlite:/home/lurker10/phptutorial/files.db');
$sql = "INSERT INTO files (txid, hash, uploadtime, filename)
VALUES (null, '$fileHash', '$txTime', '$fileName')";
$result = $pdo->exec($sql);

A continuación una solicitud para el envío al servidor Nxt.

Esta solicitud en particular es “sendMessage”. Puedes encontrar muchas más solicitudes con las que interactuar con la blockchain y sus parámetros obligatorios y opcionales en:

https://nxtwiki.org/wiki/The_Nxt_API.

Como ya he dicho antes, la fee por transacción es de 1NXT. 1 NXT = 100,000,000 NQT (nanoquantos).

1 NQTes la unidad más pequeña con la que se puede denominar a Nxt, similar a 1 satoshi en Bitcon.

El servidor Nxt acepta la fee en NQT, así que pagamos exactamente 100 millones de NQT (0,03$).

El parámetro “broadcast” se puede cambiar a false, en cuyo caso recibirás  ‘transactionBytes’ en la respuesta, que puede ser emitida a la red más adelante usando la petición ‘broadcastTransaction’. Pero en esta ocasión lo he fijado en ‘true’  para emitir la transacción instantáneamente.

Recuerda dotar de urlencode() al mensaje. Yo inserto el nombre de archivo en el mensaje separado del hash con una columna.

$payload = array(
"requestType" => "sendMessage",
"recipient" => $recipientID,
"secretPhrase" => urlencode($secretPhrase),
"feeNQT" => 100000000,
"deadline" => 1440,
"broadcast" => "true",
"message" => urlencode($fileName . ":" . $fileHash),
"messageIsPrunable" => "true"
);
$payload_string = "";
foreach ($payload as $key => $value) {
$payload_string .= $key . "=" . $value . "&";
}
rtrim($payload_string, "&");

Envía la petición al servidor NXT usando la función sendRequest():

$output = sendRequest($host, $payload, $payload_string);

y decodifica la respuesta JSON del servidor para obtener el identificador de la transacción:

if ($output != false) {
$txId = json_decode($output)->transaction;
}

Ahora que tenemos una respuesta positiva de la transacción aceptada y su ID es conocido, vamos a actualizar el registro en la base de datos local:

$lastId = $pdo->lastInsertId();
$sql = "UPDATE files SET txid = '$txId' where id = '$lastId'";
$result = $pdo->exec($sql);

Opcionalmente podemos proporcionar estos links a los clientes para consultas futuras y para demostrar que el hash ha sido subido:

echo "NXT Transaction ID: " . $txId . ",
JSON response";
echo "

Usa estos links para verificar el hash Sha256 del archivo guardado en tu base de datos local en lugar de un registro permanente en la blockchain de Nxt:

" . $fileHash;

Opcionalmente puedes enviarles por email a los clientes el $txId que podrán utilizar en un futuro para verificar el hash o, de algún otro modo más, proporcionales información acerca de como en un futuro recuperar información del hash de la base de datos propia y compararla con el hash almacenado en la blockchain, por el timestamp o por otro criterio.

Esta app no incluye autenticación del usuario. Normalmente el cliente o usuario de un servicio de intranet será capaz de ver sus archivos después de haberse autentificado en el sitio.

Esta aplicación también asume que la aplicación de verificación está fuera del alcance del que mantiene la base de datos interna, para evitar engaños en los datos de los resultados de verificación.

Ahora el registro es almacenado en la base de datos de la compañía. Muestra el registro de la base de datos para confirmar que se encuentra allí:

$sth = $pdo->prepare("SELECT id, txid, hash, uploadtime, filename FROM files ORDER BY id DESC");
$sth->execute();
$result = $sth->fetch(PDO::FETCH_OBJ);
if ($result != false) {
var_dump($result);
}

La aplicación de verificación

Para usar la verificación por hash el cliente tiene que tener el ID de la transacción en la blockchain de Nxt aprobada por ellos cuando la transacción fue enviada a la blockchain de Nxt.

Supongamos que el cliente la tiene, almacenada en el email o recuperada de algún otro modo. Aquí está:

$txId = "111111111111111111";

Vamos a ver lo que nuestra base de datos propia tiene para el hash del archivo. Busca y guarda en $hashInDb.

$pdo = new PDO('sqlite:/home/lurker10/phptutorial/files.db');
$sth = $pdo->prepare("SELECT hash FROM files where txid = '$txId'");
$sth->execute();
$result = $sth->fetch(PDO::FETCH_OBJ);
if ($result != false) {
$hashInDb = $result->hash;
}

Envía una petición al servidor NXT y busca toda la información almacenada en la blockchain de Nxt para transacciones con ese ID.

$payload = array (
"requestType" => "getTransaction",
"transaction" => $txId
);
$payload_string = "";
foreach ($payload as $key => $value) {
$payload_string .= $key . "=" . $value . "&";
}
rtrim($payload_string, "&");

$output = sendRequest($host, $payload, $payload_string);

Decodifica la respuesta JSON y extrae el campo añadido dónde se almacena el hash.

En la primera parte de la app nosotros almacenamos el nombre del archivo separado del hash con una columna. Ahora extraemos sólo la porción correspondiente al hash del mensaje arbitrario

$attachmentPlainData = json_decode($output)->attachment->message;
$hashInBlockchain = explode(":", $attachmentPlainData)[1];

Y compara lo que tenemos en la base de datos de la compañía con lo que fue almacenado hace 1 año en la blockchain de Nxt:

if ($hashInDb == $hashInBlockchain)
echo "Hashes are identical";
else
echo "Hashes are not identical";

NXT-crypto-developer

“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]

[ANN]Nxt: NRS 1.9 experimental (actualizado)

[one_full last=”yes” spacing=”yes” center_content=”no” hide_on_mobile=”no” background_color=”” background_image=”” background_repeat=”no-repeat” background_position=”left top” hover_type=”none” link=”” border_position=”all” border_size=”0px” border_color=”” border_style=”” padding=”” margin_top=”” margin_bottom=”” animation_type=”” animation_direction=”” animation_speed=”0.1″ animation_offset=”” class=”” id=””][fusion_text]Version: 1.9.1e (versión experimental)

INSTALADORES

[/fusion_text][/one_full][one_third last=”no” spacing=”yes” center_content=”no” hide_on_mobile=”no” background_color=”” background_image=”” background_repeat=”no-repeat” background_position=”left top” hover_type=”none” link=”” border_position=”all” border_size=”0px” border_color=”” border_style=”” padding=”” margin_top=”” margin_bottom=”” animation_type=”” animation_direction=”” animation_speed=”0.1″ animation_offset=”” class=”” id=””][fusion_text]

appletest

Nxt-download-button-grey-250hiweb[/fusion_text][/one_third][one_third last=”no” spacing=”yes” center_content=”no” hide_on_mobile=”no” background_color=”” background_image=”” background_repeat=”no-repeat” background_position=”left top” hover_type=”none” link=”” border_position=”all” border_size=”0px” border_color=”” border_style=”” padding=”” margin_top=”” margin_bottom=”” animation_type=”” animation_direction=”” animation_speed=”0.1″ animation_offset=”” class=”” id=””][fusion_text]

windows

Nxt-download-button-blue-250hiweb[/fusion_text][/one_third][one_third last=”yes” spacing=”yes” center_content=”no” hide_on_mobile=”no” background_color=”” background_image=”” background_repeat=”no-repeat” background_position=”left top” hover_type=”none” link=”” border_position=”all” border_size=”0px” border_color=”” border_style=”” padding=”” margin_top=”” margin_bottom=”” animation_type=”” animation_direction=”” animation_speed=”0.1″ animation_offset=”” class=”” id=””][fusion_text]

linux

Nxt-download-button-gold-250hiweb[/fusion_text][/one_third][fusion_text]

Firma digital: “Stichting NXT”
.sh Sha256: 4e21c830f43d9d842c7005252b2a75983a4a5a067994c1b49ac1339f8ac5ed2c  nxt-client-1.9.1e.sh
Lanzamiento v1.9.1e: https://bitbucket.org/JeanLucPicard/nxt/downloads/nxt-client-1.9.1e.zip
1.9.1e .zip sha256: 097f2d10589b43bf5882f1e0d06f83740f09ca6f037ae73252eb6c555819b212  nxt-client-1.9.1e.zip

NRS 1.9.1e nota de la versión

Se ha corregido un fallo en la interfaz de usuario que afectaba a algunos envíos de formularios.

NRS 1.9.0e notas de la versión

Este es una versión experimental.
Se trata de una actualización obligatoria para todos los nodos de la testnet, siendo opcional para la red principal.

Esta versión permite realizar múltiples capturas (snapshots) del saldo de las cuentas Nxt, cada 60 bloques y durante un período de 90 días, para la distribución del token ARDR basado en el promedio del mencionado saldo al finalizar el período de toma de las instantáneas. El token (ARDR) será la base consensuada para la distribución de Nxt 2.0.

Lectura importante: Distribución de Ardor

En la red de pruebas (testnet) el proceso de snapshot dará comienzo en el bloque 649400 y finalizará en el bloque 779000
(24 de junio).

En la red principal (mainnet), el proceso de snapshot comenzará en el bloque 870400 (se espera que sea alrededor del 14 de julio) y finalizará en el bloque 1000000 (12 de octubre).

Vea también: Nxt 2.0: La plataforma blockchain con soporte de childchains Ardor

Puesto que en la testnet ya se ha alcanzado el bloque inicial, al actualizar a esta versión se realizará automáticamente un escaneado de la blockchain con el fin de calcular saldos anteriores de la cuenta. Aquellos que demoren la actualización del nodo de la mainnet hasta pasado el bloque 870400 también tendrán que pasar por el proceso de escaneo. No obstante, el
bloque del hardfork está establecido al final del periodo de las instantáneas, por lo que el plazo final para la actualización a la v1.9 es durante los bloques 779000 y 1000000 respectivamente.

Para obtener los tokens ARDR es esencial mantener tu balance de NXT en tu propia cuenta. No es necesario ejecutar un nodo o forjar. El saldo confirmado de NXT es el usado en el proceso de snapshot, no el saldo disponible, por lo que tener algún NXT bloqueado en órdenes abiertas del Asset Exchange, en shufflings, etc., no afectará para la obtención de tus ARDR.

Para los saldos de las cuentas de las casas de intercambio (exchanges), es responsabilidad de cada exchange gestionar la
redistribución de los tokens ARDR que se enviarán de manera instantánea a su cuenta una vez el periodo de snapshot finalice.

Damelon (Bas Wisselink) el 20-06-2016, 09:46:54 pm:
“La fundación Nxt va a estar en contacto con los exchanges para ayudar con este proceso. Os mantendremos informados.”
Fuente: https://nxtforum.org/index.php?action=post;quote=219422;topic=11475.0

Se añade una nueva entrada API, getFxtQuantity, que permite conocer la cantidad de ARDR ya acumulada por cada cuenta durante el proceso de toma de instantáneas, y una estimación de la cantidad todavía por obtener. Puesto que las instantáneas se realizan cada 60 bloques, los números que esta API muestra se actualizan solo una vez cada 720 bloques.

Los saldos de las instantáneas que se utilizan para la distribución de ARDR de una cuenta específica se pueden almacenar en el registro estableciendo la opción nxt.logFxtBalance para ese número de cuenta y realizar un reescaneo si la instantánea ya ha comenzado.

Se han añadido algunos bytes adicionales para la validación de la transacción, así como de validación de ordenes condicionadas, que entrarán en vigor después del hardfork.

Se añade una nueva entrada API, getAssetDividends, para obtener el historial de pagos de dividendos de un activo.
Esto se puede consultar en el cliente pulsando el nuevo enlace “Ver dividendos del activo” que aparece en la página del Asset Exchange. Los pagos de dividendos efectuados antes de que el nodo se actualizase a la versión 1.9.0e no quedarán reflejados en el historial, a menos que se fuerce un re-escaneo manual de la blockchain.

Después del bloque del hardfork, las operaciones de pago de dividendos serán limitadas a no más de una por activo cada 60 bloques.

Se añade una nueva tabla de mensajes en la Interfaz de Usuario del cliente. Se permite subir un archivo como adjunto a un mensaje, normal o encriptado, y descargar estos mensajes como archivos. Todas las APIs de creación de transacción que permitan archivos adjuntos podables ahora también aceptan la carga de los archivos de varias partes con los parámetros
messageFile o messageToEncryptFile o, cuando se usan los datos encriptados del lado del cliente, la parte de los datos pueden subirse utilizando el parámetro encryptedMessageFile. Como la página de API de prueba no soporta parámetros de carga de archivos múltiples, actualmente no están disponibles los botones de subida para ello.

Aceptación del parámetro Accept sharedKey en downloadPrunableMessage y getPrunableMessage APIs.

Se añade soporte a la interfaz de usuario para desencriptar los mensajes usando una clave compartida que permite revelar la clave compartida de un determinado mensaje encriptado a un tercero, con el fin que sea descifrada sin tener que mostrar la contraseña de la cuenta.

Optimización de la forja para reducir el salto de bloque cuando se lleva a cabo un hard fork.

Otras correcciones menores y mejoras en la interfaz de usuario.

Biblioteca H2 actualizada a la versión 1.4.192, tika a 1.13, y slf4j hacia 1.7.21. Si lo instalas de forma manual, asegúrate de borrar primero la antigua carpeta lib.

Fuente: Jean-Luc, jefe de desarrollo del proyecto Nxt https://nxtforum.org/nrs-releases/nrs-v1-9-0e/

 

[menu_anchor name=”nxt-video-guides”][/fusion_text][separator style_type=”none” top_margin=”” bottom_margin=”” sep_color=”” border_size=”” icon=”” icon_circle=”” icon_circle_color=”” width=”” alignment=”” class=”” id=””][fusion_text]Desarrolladores

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

[/fusion_text][separator style_type=”none” top_margin=”” bottom_margin=”” sep_color=”” border_size=”” icon=”” icon_circle=”” icon_circle_color=”” width=”” alignment=”” class=”” id=””][one_full last=”yes” spacing=”yes” center_content=”no” hide_on_mobile=”no” background_color=”” background_image=”” background_repeat=”no-repeat” background_position=”left top” hover_type=”none” link=”” border_position=”all” border_size=”0px” border_color=”” border_style=”” padding=”” margin_top=”” margin_bottom=”” animation_type=”” animation_direction=”” animation_speed=”0.1″ animation_offset=”” class=”” id=””][fusion_text]

nxt-hepdesk-250hiweb

 [/fusion_text][/one_full]

Hoja de ruta de Nxt 2.0

Hoja de ruta de Nxt 2.0

Ha sido presentado Nxt 2.0, el sucesor de la pionera plataforma Nxt, la cual ha sido fuente de inspiración para otros muchos exitosos proyectos blockchain.

Nxt 2.0, basado en la experiencia adquirida al desarrollar Nxt 1.0 durante más de 2 años y medio, pretende solventar los problemas de escalabilidad, privacidad, liquidez y usabilidad.

Nxt 2.0 conserva todas las características principales de la primera versión de Nxt pero ampliando su concepto, añadiendo childchains seguras y escalables. Esta nueva arquitectura flexible permitirá a los usuarios crear sus propias blockchains personalizadas, que se encontrarán respaldadas por la seguridad proporcionada por el ecosistema colectivo de la plataforma Nxt 2.0.

Nxt 2.0 está siendo desarrollado por un talentoso equipo dotado de grandes y experimentados profesionales. Se trata del mismo equipo que construyó: el primer verdadero sistema Proof-Of-Stake, el primer sistema de intercambio de activos descentralizado, el primer sistema de mezclado de monedas (coin shuffling) completamente descentralizado… así como otras muchas innovadoras características para la tecnología blockchain.

El equipo de desarrollo del núcleo de Nxt ha estado presentando novedades constantemente desde el lanzamiento inicial a finales de 2013 y muchas innovaciones de Nxt han sido utilizadas en otros proyectos.

 

NXT 2.0 ha pasado la fase inicial de estudios previos. Tras poner en común sus experiencias al trabajar en Nxt 1.0 durante más de dos años, los desarrolladores Jean-Luc, Riker, ScripterRon y Petko han arrancado la primera fase de programación de Nxt 2.0.
Escribir el código de Nxt 2.0 llevará su tiempo. El equipo de desarrollo no busca un lanzamiento a bombo y platillo con un sistema a medio terminar, sino que quiere estar seguro de que la nueva plataforma mantiene los estándares de calidad de su predecesora. Consideramos que, de hecho, constituye el patrón de referencia en cuanto a estabilidad y rendimiento que una plataforma blockchain debería buscar.

La fase de programación inicial comenzó hace unas semanas y se espera que se prolongue durante al menos el resto de 2016.

Testnet

En el momento de la redacción del presente texto, el equipo de desarrollo pretende lanzar la primera versión de la red de pruebas Nxt 2.0 a principios de 2017. Durante la fase Testnet del software, habrá muchas reescrituras y reajustes, basados en la opinión de los usuarios y un uso continuo de la plataforma. La fase Testnet tendrá una duración de al menos seis meses para estar completamente seguros de que la primera versión real será segura y confiable en el momento de su lanzamiento.

Mainnet

En el momento de la redacción del presente informe, se estima que la primera versión de Nxt 2.0 se lanzará durante el tercer trimestre de 2017.

Nxt 2.0 conservará TODAS las características de la plataforma Nxt 1.0

A continuación se ha resumido el modo en que cada característica actual será transferida a la nueva childchain FNX en el momento de su lanzamiento.

Números de cuenta

Los números de cuenta se conservan, puesto que la asignación de la frase secreta, la clave pública y el identificador de cuenta no cambia. Cada frase secreta corresponderá exactamente al mismo número de cuenta en la versión 2.0. Los actuales usuarios de la versión 1.0 podrán iniciar sesión con NXT 2.0 con su contraseña actual.
La tabla de cuentas será global y cada cuenta podrá tener saldos de cualquiera de los tokens de otras childchains, así como en FXT.

Activos

Los activos existentes dentro de la plataforma Nxt 1.0 o su histórico de las transacciones no serán trasladados de manera directa a la childchain FNX.

Como Nxt 1.0 seguirá existiendo, el equipo de desarrollo cree que es mejor dejar la elección de cuándo y cómo mover los activos a Nxt 2.0 en manos de los poseedores de los activos y de sus emisores.
Seguramente la mejor manera de hacerlo sería eliminando los activos existentes, requiriendo que fuesen devueltos a la cuenta del emisor para su canjeo después tras la emisión de los nuevos activos en Nxt 2.0. O podría realizarlo el emisor del activo anunciando el momento en el cual va a tomar una instantánea de los saldos de los activos dentro de la 1.0 y, a continuación, volver a distribuirlos en la versión 2.0.

Los activos serán universales en la versión Nxt 2.0, lo que significa que cualquier activo, independientemente de la childchain en la cual se haya emitido, podrá ser comercializado en cualquier childchain que permita su comercio.

Monedas del Sistema Monetario

Los nombres de las monedas del sistema monetario también serán universales y será posible comercializarlas en cualquier childchain. Los nombres y códigos de las monedas existentes dentro del Sistema Monetario de Nxt 1.0 serán transferidos a la childchain FNX, incluyendo los saldos de las monedas de todas las cuentas. El historial de transacciones no se transferirá.
El equipo de desarrollo dará asistencia a cualquier moneda del Sistema Monetario que quiera hacer la transición a una childchain, es decir, poner en marcha una childchain con la distribución del token basado en la actual distribución de estas monedas dentro del Sistema Monetario.
Los nombres y los códigos de las monedas del sistema monetario serán exclusivos para cada childchain. Esto eliminará la posibilidad de poner el nombre para todas las cadenas. El formato propuesto para los nombres de las monedas del sistema monetario es el siguiente: CODIGODELAMONEDA.CODIGODELACHILDCHAIN, por ejemplo ELEMS.FNX.

Mensajes arbitrarios

Ningún Mensaje será transferido de la versión 1.0 a la 2.0

Etiquetas de datos

Ninguna etiqueta de datos será transferida de la versión la 1.0 a la 2.0

Bienes digitales

Ningún producto ni sus ventas serán transferidos de la versión 1.0 a la 2.0

Alias

Los alias existentes en la versión Nxt 1.0 serán transferidos a la childchain FNX. De la misma manera que los nombres y códigos de las monedas del Sistema Monetario, los Alias serán únicos sólo en su propia childchain. A nivel global, los alias se anexarán con un sufijo a la childchain para identificar a que cadena pertenecen. Por defecto, los nombres de alias que no cuenten con el sufijo de la childchain se sobreentenderá que pertenecen a la childchain FNX.

Votaciones

El sistema de votaciones estará disponible en cualquier childchain.
Las encuestas abiertas o no finalizadas NO se trasladarán a la versión 2.0. Los sondeos aún activos tendrán que terminarse en la cadena actual 1.0.

Transacciones por etapas

Las transacciones por etapas estarán disponibles en cada sidechain.
La configuración actual del Sistema de Control de Cuentas NO serán transferidos a la nueva childchain FNX.

Leasing

El leasing de cuenta se mantiene, pero únicamente en la cadena principal FXT, ya que los saldos FXT son los únicos que proporcionarán seguridad a la blockchain (forja). Los leasings existentes en la versión 1.0 NO serán transferidos, se tendrán que volver a crear.

Plugins

Nxt 2.0 será compatible con los Plugins. Pero los existentes deberán ajustarse a la configuración de la plataforma 2.0

¿Qué va a pasar con la versión 1.0?

El equipo de desarrollo de Nxt está comprometido a proporcionar asistencia, corrección de errores y cualquier posible actualización de emergencia a la actual cadena NXT 1.0.
No será necesario eliminar las monedas 1.0 para recibir los tokens 2.0 y además eres libre de tradear los tokens FXT que recibirás después de que el proceso de toma de instantáneas haya finalizado.

El equipo de desarrollo busca hacer la migración a la versión 2.0 lo más sencilla posible, por lo que se permite una amplia ventana de tiempo para realizar este movimiento.
En resumen, nada va a cambiar para Nxt 1.0, excepto que el trabajo activo en nuevas características se detendrá. La plataforma se mantendrá activa y los usuarios se beneficiarán de una plataforma segura y bien cuidada.
El equipo de desarrollo también proporcionará ayuda y apoyo a los usuarios que deseen mover sus negocios de Nxt 1.0 a Nxt 2.0.

La primera innovación que presenta Nxt 2.0 es dividir la blockchain en una cadena principal, que se utilizará solo para la creación del consenso, y múltiples cadenas (childchains), las cuales tienen su propio libro de transacciones utilizando su propia moneda o token.

Esto significa que inicialmente habrán dos distribuciones de tokens: una para el token de la cadena principal (por ahora se llama FXT), y otra para el token de la primera childchain que se pondrá en marcha (por ahora se llama FNX).

El equipo de desarrollo reconoce las enormes contribuciones de los inversores y titulares del original NXT 1.0, sin los cuales Nxt 2.0 no sería posible, y han decidido concederles privilegios para estos nuevos tokens.

Es importante señalar que ¡el lanzamiento de Nxt 2.0 no significa el cese de la versión Nxt 1.0! El equipo central se ha comprometido a seguir prestando apoyo a Nxt 1.0 durante al menos un año después de la puesta en marcha de Nxt 2.0 y, probablemente bastante más.

No será necesario eliminar de Nxt 1.0 con el fin de recibir, ya sea, FXT o FNX

Distribución:

FXT (Tokens de la cadena principal)

Todos los poseedores de NXT recibirán los tokens FXT en el lanzamiento de la Mainnet.

Poco después de la liberación de la versión Nxt 1.9 (destinada a ser la última versión importante en la rama Nxt 1.0), 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á un promedio durante el periodo de tres meses y todas las cuentas quedarán acreditadas automáticamente con un saldo representativo del nuevo token, que representa las participaciones en FXT, emitido como un activo en el intercambio de activos de Nxt.

Los activos FXT podrán ser comercializados libremente.

La distribución de las monedas reales FXT (se harán el día del lanzamiento de la Mainnet de Nxt 2.0 en el tercer trimestre de 2017) se basará en la titularidad de los activos FXT de cada usuario en la blockchain de Nxt 1.9, tomada poco antes de la creación del bloque génesis de Nxt 2.0.

FNX (Tokens de transacción de la Childchain FNX)

La distribución del token FNX estará basado en las tenencias de cada cuenta de NXT en el momento de la creación del bloque Génesis de NXT 2.0.

En el momento de escribir el presente documento, el equipo de desarrollo ha decidido abonar el 50% de las tenencias a cada nueva cuenta de FNX, aunque se reserva el 50% de los FNX para la financiación del equipo de programadores, el desarrollo de negocios y otras operaciones que necesitarán financiación para hacer que NXT 2.0 sea un éxito.

El equipo de desarrollo reconoce que no incluir este paso en la distribución de 2013 ha sido un error ya que dejó al proyecto con una insuficiencia de financiación crónica.

Como un modelo basado en la donación no es sostenible, el equipo de desarrollo ha decidido optar por la asignación del 50% para el desarrollo y sostenibilidad del proyecto.

Financiación a largo plazo del núcleo de Nxt

En el artículo anterior ya adelantábamos como Nxt2.0 había abierto un debate sobre la financiación y la posible falta de fondos para continuar con el desarrollo del proyecto y su promoción.
El líder de los desarrolladores de Nxt, Jean-Luc, afirma que seguirá trabajando un año más en calidad de voluntario, hasta que termine la nueva versión, pero sigue contemplando la posibilidad de una IPO para garantizar la viabilidad.

Jean-luc: La IPO es la única forma de conseguir fondos sin dejar de ser independientes y sin poner en peligro el futuro de la blockchain pública. Voy a desarrollar Nxt2.0 con o sin IPO. Pero si en lugar de organizarse una campaña de crowdfunding acabamos siendo financiados por inversores privados, ellos serán los que decidirán el camino.
No recuerdo a la “corporación” Nxt haber vendido nunca ninguna acción a los inversores. Los 21 BTC recolectados por BCNext se han quedado atrás (y no se dónde, ya que yo no soy BCNext). Si hubiese una IPO, sería la primera verdadera IPO en la historia de Nxt. Sería una notable ronda de financiación que significarían para el desarrollo y la comercialización. Y sin ella, la buena voluntad y las donaciones serán simplemente insuficientes.

Los representantes de la fundación y del proyecto Tennessee garantizan que la comunidad dispone de los fondos necesarios para continuar un año más (Recordemos que Tennessee fue inicialmente ideado para 12 meses y que la fundación Nxt dispone de un fondo para desarrollo). Pero dejan clara la situación de escasez de fondos a la que se enfrenta la comunidad.

Damelon: BCNext no nos hizo ningún favor dejando a la comunidad con una severa falta de fondos. A pesar de ello, esto nos ha ayudado a ser extremadamente creativos. De cierta manera ha sido una gran ganancia.

La falta de marketing, las exitosas campañas de recaudación efectuadas por otras iniciativas fuera del ecosistema NXT, la actual limitación de fondos que afronta la comunidad, añadido a las declaraciones de Jean-Luc… todo este conjunto de sucesos ha alentado a las opiniones pro-recaudadoras y, por lo tanto, contrarias a la distribución 1:1 de (f)NXT.

Marc de Mesel: Yo estoy dispuesto a apoyar la IPO si los fondos obtenidos van a una cuenta dónde la mayoría de los titulares de la moneda decidan dónde y en qué gastarlo.

Abtc: Si, porque Jean-Luc aboga por ella y porque las sidechains son un nuevo invento, por eso deben someterse a IPO. Nadie en la IPO de 21BTC del año 2013 pagó por las nuevas sidechains.

La mayoría de la comunidad, mediante encuestas dentro de Nxt, ha manifestado que no está de acuerdo en realizar ninguna campaña de recaudación, pero el debate sobre la escasez de fondos no ha hecho nada más que empezar.

¿Cómo podemos auto-gestionar y garantizar los fondos para la viabilidad del proyecto?

nxt-ico

A diferencia de otras moneda, NXT, no es de carácter inflacionario ni deflacionario. Recordemos que Nxt consta de 1.000.000.000 de tokens, ni uno más ni uno menos.
Vamos a ver algunas de las diferentes propuestas expuestas por reputados miembros y veremos como podrían afectar a la marca Nxt. ¿Podemos o debemos modificar la naturaleza de Nxt aunque sea por una buena causa?

Sugerencia 1: Inflación controlada.
El inversor Marc de Messel propuso la idea de crear nuevos token NXT, de forma controlada, para pagar el equipo de desarrollo. Se puede ver la votación aquí. Sin embargo, ganó el NO de manera aplastante, como era de esperar.

Sugerencia 2: Vender características

Sebastien 256: Otra posibilidad puede ser la de vender características. Por ejemplo: moviendo el almacenamiento en la nube de la childchain 2.0 y crear una nueva childchain con solo esa característica pero con un nuevo token. No se si esto es realizable, pero sería una posibilidad.

Sugerencia 3: Vender futuras características

Sugerencia 4: Expropiaciones, recaudación de los darkNXT o cuentas muertas

Lurker10 : Si una cuenta no envía un mensaje, durante un periodo de 6 meses, no recibirá los (f)NXT. Es fácil y elegante. Definimos una altura de bloque en el hardfork hacia la 1.9 y enviamos únicamente los activos a las cuentas que han enviado ese mensaje. El resto va a la IPO.
Bcdev: seria peor que lo que hizo Bitshares o Dash en su día. Definitivamente esto mataría a Nxt.
Cassius: Cualquier tipo de expropiación mataría a la cripto.

Sugerencia 5: Hacer un crowfunding por etapas

Brangdon: para empezar estaríamos hablando de emitir cuatro nuevas monedas en modo crowdfunding, con nombres como May_2016, Jun_2016, Jul_2016, Aug_2016, que se activarían el primer día de cada mes. La cantidad a recaudar podrían ser 200.000, 300.000, 400.000, 600.000 NXT. Si el primer mes tiene éxito podría servir para financiar Tennessee durante una semana, lo que en sí ya vale la pena. Si podemos llegar al punto de poder recaudar todos los meses la cantidad necesaria para permitir financiar a Tennessee durante un mes más, los fondos con los que cuenta en la actualidad podrían usarse como colchón.
Mi propuesta es utilizar el crowdfunding de particulares al corto plazo, desarrollándose con el patrocinio de las empresas a largo plazo, cómo en la fundación Linux.

Sugerencia 6: Pagar efectivo para desarrollar NXT2.0

Neofelis:Voy a pagar directamente en efectivo a los desarrolladores para desarrollar Nxt2.0 como si fuese una ICO. Tengo unos pocos miles a invertir y creo que esto es una buena dirección para la criptografía y estoy dispuesto a poner dinero en efectivo para conseguirlo.

Sugerencia 7: Monetizarnos a nosotros mismos y donar parte de los ingresos

Apenzl: ¿por qué no construimos servicios de uso fácil y sistemas comerciales, obtenemos beneficios económicos de nosotros mismos y donamos algunos fondos IPO y algún % del beneficio para el desarrollo del núcleo de Nxt?

Sugerencia8: Donativo del 10%

Brangdon: Done el 10% de su posesión al fondo de D&O.

Sugerencia 9: Plan del usuario Nxter.

Paso 1: Lanzar una nueva marca: nuevo nombre, nuevos colores, nuevo logo y nuevo eslogan. Tenemos que captar la esencia de Nxt2.0 con esto.
Paso 2: Usar el sistema monetario de Nxt para llevar a cabo la propuesta de crowdfunding de Nxt2.0 (perfecto caso de uso para el sistema monetario)
Paso 3: Una enorme campaña de marketing para presentar la nueva marca y las características 2.0: vídeos, artículos, presencia en las redes sociales, grandes presentaciones en las conferencias, acercamiento a potenciales inversores/empresas, anunciar la asociación con Azure, anunciar una ICO.
Paso 4: ICO sobre la nueva marca y aceptar solo pagos en BTC. El NXT recaudado en la etapa 3 será distribuido con esta ICO. Una ICO genera una gran cantidad de exposición, debate y expectativas. Esto es libre comercialización!
Step 5: Pagar las donaciones NXT en BTC usando el 50% de los fondos recaudados en la ICO (los nxters podrían utilizar esos BTC para recomprar Nxt si lo desean). El otro 50% de los fondos se pueden usar para hacer esta plataforma corporativa: expandir la fundación y contratar a un equipo de desarrolladores para ayudar a Jean-Luc y Riker.

Sugerencia10: Plan de devlux y su activo Evolve.

Devlux: En este momento, tenemos una oportunidad de recaudar fondos para construir un negocio que ayude al uso empresarial de NXT. En este punto, este es el único camino correcto. El mercado B2B tiene un valor de billones de dolares y será mucho más fácil que tratar de ir hacia la versión 2.0. Tener en cuenta el desastre absoluto que hizo Bitshares cuando se mudó a la versión 2.0. Es difícil poderlo hacer mejor pero, a la vez, no creo que se pueda hacer peor.
NXT es un producto muy superior pero falta darle visibilidad en el mercado.

 

El libro del segundo aniversario de Nxt cuenta con un excelente artículo redactado por Damelon, titulado “The original spirit”, donde hace una reflexión que nos sirve perfectamente como conclusión para los dos últimos artículos publicados, poniendo de manifiesto el funcionamiento de la comunidad de Nxt y su modo de afrontar los problemas:

Aún a pesar de que los desarrollares son vitales en Nxt, no son los líderes del proyecto. El proyecto Nxt no se lidera de un modo convencional, sino que funciona a base de individuos que lanzan iniciativas que, o bien tienen éxito o, por el contrario, fracasan.
Esto explica por qué la gente que observa la comunidad Nxt desde el exterior generalmente se llevan una impresión de un grupo desorganizado e inconexo de gente hablando de objetivos diferentes. Algunos encontrarán esto como desconcertante, especialmente aquellos que piensan que el progreso sólo se puede conseguir siguiendo una línea dónde los puntos están claramente predefinidos con anterioridad que siempre se pueden unir con líneas rectas.

Anuncio: Características de la versión 1.8

El trabajo efectuado sobre Nxt y su cliente NRS, continúa. Los desarrollares del núcleo de Nxt han enviado una lista con las nuevas características que se implementarán en el próximo lanzamiento de la versión NRS 1.8, esperada para Abril.

  • Cartera en el escritorio

    Ejecuta el cliente como una aplicación de escritorio.

Riker escribe:

Hasta ahora, cuando iniciamos el cliente NXT, el usuario tenía que:  esperar a que el servidor arrancase, luego, abrir el navegador y dirigirnos a http://localhost:7876 para iniciar la cartera en el navegador web.

A partir de este lanzamiento, cuando ejecutemos el cliente NXT, se iniciará inmediatamente como una aplicación de escritorio del monedero, basada en el mismo diseño.

Consulte: https://bitbucket.org/JeanLucPicard/nxt/issues/338/desktop-wallet

  • Monitorización de cuentas

    Componente del servidor que dota de fondos automáticamente a las cuentas específicas en base a varios criterios. Asegurando que la cuenta del titular siempre cuente con la cantidad suficiente de NXT para realizar las transacciones.

ScripterRon comenta:

Usted puede monitorizar NXT, Activos o Monedas.

Cuando el balance de la cuenta monitorizada comienza a ser inferior al prefijado, se inicia la transferencia, de NXT, Activos o Monedas, desde la cuenta de los fondos hacia la cuenta monitorizada.

Usted puede activar múltiples monitorizaciones. Las cuentas monitorizadas son identificadas mediante una propiedad de cuenta.  La propiedad de la cuenta debe ser establecida por el titular de la cuenta de financiación.

  • Personalización de la cartera

    Abrir la cartera en una página específica o modal.

Riker escribe:

Esta característica permite vincular la cartera online de Nxt a una página, específica o modal, o enlace web externo.

Por ejemplo: conectando a: http://localhost:7876#account=NXT-22222-…&modal=send_money_modal&recipient=NXT-33333

ingresarías a la cuenta NXT-22222 abriría el modelo estándar “Send Money” y rellenaría el campo del destinatario con el valor NXT-33333

Consulte: https://bitbucket.org/JeanLucPicard/nxt/issues/320/start-the-client-on-a-specific-page-or

  • Add-Ons

    Estructura sencilla para incorporar plugins

Únete a la conversación sobre Nxt 1.8 en Nxtforum:
https://nxtforum.org/general-discussion/upcoming-features-in-1-8-release/

En paralelo a lo anterior, el desarrollador, Jean-Luc ha comenzado a trabajar en el diseño Nxt 2.0.

Lea más sobre la propuesta de diseño para Nxt2.0:
http://test.nxter.org/nxt-2-0-design/
[vídeo] http://test.nxter.org/nxt-2-0-design-proposal-should-investors-and-asset-issuers-be-afraid/

Puedes publicar comentarios e ideas para el diseño de Nxt2.0 en:
https://nxtforum.org/core-development-discussion/nxt-2-0-design/

[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