Migración de NIS1 a Catapult

Con Catapult, la mayoría de las funciones NIS1 disponibles anteriormente han evolucionado. Este documento lo ayudará a conocer mejor las características anteriores de NIS1 y como va ser la actualización a la nueva tecnología de Catapult disponible. 

Nota

Esta guía es un documento en vivo. La información podría cambiar a medida que avanza el desarrollo de Catapult.

Prueba de la Red

El paquete catapult-service-bootstrap trae un conjunto de scripts para implementar una red completa de prueba Catapult para fines de desarrollo y aprendizaje.

Guía: Ejecutar una red local con el Catapult Service Bootstrap

Nota

⚠️ El software de Catapult y los scripts de arranque del servicio todavía están en desarrollo. No alimente ninguna red en producción usando estos paquetes.

Incompatibilidad de API heredada

Las llamadas API heredadas que solían funcionar para los nodos de red NIS1 no son compatibles con Catapult. Con Catapult, las solicitudes API se realizan principalmente con nodos API REST, generalmente en el puerto 3000.

Hay varios Kits de Desarrollo de Software que se han desarrollado, y algunos que están, en desarrollo para las aplicaciones de consumo de libros contables distribuidos de Catapult. A partir de ahora, los SDK planificados que se admitirán están escritos en: Typecript / Javascript / NodeJS, Java, C #, Go, Python y Swift.

Como punto de partida, sugerimos revisar el SDK de TS / JS, ya que es el SDK más utilizado y los leads en la documentación. La arquitectura del TS SDK está inspirada en la Biblioteca NEM de NIS1.

Gestión de cuentas

La administración de la cuenta con Catapult no ha cambiado mucho en comparación con las cuentas de red pública NIS1 anteriores. Se han producido algunos cambios notables en cuanto a la verificabilidad pública de las cuentas y los nombres de campo devueltos en los puntos finales REST.

Transacciones heredadas

El formato de serialización de transacciones NIS1 no es compatible con Catapult. Sin embargo, la mayoría de los tipos de transacciones solo han evolucionado y ninguno ha sido eliminado. Esto implica una posible actualización de las transacciones de Catapult que implican menos cambios.

El primer cambio notable sobre las transacciones es que la respuesta de estado se recibe a través de los canales de WebSocket. En NIS1, el cliente recibió la respuesta de la llamada a la API justo después de anunciar una transacción. Catapult recibe la respuesta de la llamada de forma asincrónica, eliminando el bloqueo de llamadas.

Además, solo queda una versión de “TransferTransaction” en la que los mosaicos siempre se insertan en la matriz de mosaicos, cuando están disponibles. Esto es diferente de las transacciones de transferencia NIS1 que, en su primera versión, se adjudicó XEM sin usar la matriz de mosaicos.

Tarifas de transacción

La tarifa que debe pagarse por una transacción ahora depende del tamaño de la transacción y los propietarios de nodos pueden especificar un multiplicador de tarifa positivo (o cero). La tarifa efectiva pagada por una transacción se puede calcular leyendo el multiplicador de tarifas del bloque en el que se confirmó la transacción y multiplicándola por el tamaño de la transacción.

Las tarifas de transacción se especifican con el campo maxFee. Este campo representa la tarifa máxima que se permite pagar por esta transacción para confirmar.

Protocolo: tarifas de transacción

Mosaicos & namespaces

Se han producido cambios notables a nivel de protocolo con respecto a la gestión de mosaicos, ya que ahora son independientes de los namespaces. De hecho, en NIS1, sucedió que los namespaces expirarían por completo con los activos vinculados a ellos.

Con Catapult, los mosaicos se configuran para tener su propia duración, además de que se les asigna un valor nonce único.

Por último, los gravámenes no están disponibles en Catapult, sino que deben reproducirse con transacciones agregadas.

Los Namespaces todavía pueden referirse a mosaicos de desvíos de AliasTransactions. El propietario de un espacio de nombres puede adjuntar una cuenta o una identificación de mosaico a uno de sus namespaces. El punto final de información del espacio de nombres devolverá el objeto vinculado en el campo de alias.

Además, los namespaces de raíz tienen un campo de duración que se expresa en un recuento de bloques, lo que significa que la renovación anual ya no es obligatoria.

Para facilitar la transferencia de mosaicos, el propietario de un mosaico debe registrar un namespace y alias del mosaico con ese espacio de nombres. Los usuarios finales pueden enviar transacciones utilizando el alias para referirse al mosaico.

Cuando una transacción incluye un alias, la llamada resolución refleja el valor resuelto de ese alias en el bloque. Para obtener el identificador real detrás de una dirección o mosaico con alias, la aplicación del cliente debe buscar el recibo de resolución relacionado vinculado al bloque donde se incluye la transacción.

Gestión de firmas múltiples

Con las cuentas de firmas múltiples administradas en cadena, la implementación de firmas múltiples de NEM es diferente de muchas otras implementaciones de firmas múltiples del lado del cliente.

Una cuenta debe convertirse a una cuenta de múltiples firmas.

A diferencia de NIS1, las entradas de modificación de cuenta ahora contienen campos para aprobación mínima y eliminación mínima:

Eliminación mínima: define cuántos cosignatarios se requieren para transmitir transacciones que eliminan cosignatarios de la cuenta de múltiples firmas.

Aprobación mínima: define cuántos cosignatarios se requieren para cualquier otro tipo de transacción.

Además, los cosignatarios que se agregan a las cuentas de firmas múltiples ahora tienen que confirmar la modificación enviando una firma conjunta (proceso de suscripción). Para facilitar este proceso, las transacciones con el tipo MultisigAccountModificationTransaction deben estar envueltas en una AggregateTransaction.

2. Las transacciones con firma múltiple funcionan con transacciones agregadas.

La nueva AggregateTransaction permite agrupar varias transacciones con la participación de diferentes participantes. Si todos los participantes codirigen el agregado, las transacciones internas se incluyen atómicamente en el bloque. De lo contrario, ninguna de las transacciones se confirmará.
Para enviar una transacción multigrado como en NIS1, el iniciador de la transacción debe agregarla como una transacción interna del agregado. Luego, el número mínimo de cosignatarios definidos en la firma múltiple tendrá que cosignar el agregado para permitir anunciar transacciones desde la cuenta compartida.

Guía: envío de una transacción de firma múltiple

¿Necesitas ayuda?

Mientras migra de NIS1 a Catapult, es posible que aún tenga algunas preguntas sin respuesta. En el Centro de desarrolladores de NEM, puede encontrar más características nuevas descritas junto con guías de integración paso a paso.

También puede hacer preguntas relacionadas con la integración en StackOverflow, o comunicarse con nuestra comunidad de desarrolladores que se unen al Slack oficial.

Fuente: NEM Tech Github