Descripción técnica de la migración de Catapult Opt-In

Hola nembers,

Esta publicación debería proporcionar a la comunidad una mejor perspectiva sobre cómo una migración de aceptación de Catapult es técnicamente factible.

Como introducción rápida, eche un vistazo al siguiente árbol de decisiones de @Jaguar0625, quien publicó esto en Twitter aquí.

Catapult Migration Decision Tree

Razón fundamental o base lógica

Este documento analiza las implicaciones de la migración de los conjuntos de datos almacenados en una red blockchain heredada, en lo sucesivo denominados “datos de cadena de bloques NEM” y “cadena de bloques NEM”, también conocida como “cadena de bloques NIS”, en una red de cadena de bloques pública Catapult recién configurada.

La solución propuesta establece un proceso que se distribuye y puede ser auditado por terceros.

La migración propuesta de conjuntos de datos de la cadena de bloques NEM a una red de cadena de bloques pública Catapult recién configurada almacenará los datos de migración en la cadena de bloques NEM. Esto hace posible que terceros verifiquen / auditen los datos que se incluyen en el bloque de némesis leyendo conjuntos de datos en la cadena de bloques NEM.

Además, el proceso utiliza características que están disponibles en ambas redes blockchain sin modificaciones, lo que permite iniciar el proceso de migración sin demora.

La fuerte fecha límite impuesta por la estrategia de migración propuesta es claramente una desventaja, pero su efecto se puede mitigar con el hecho de que los fondos no reclamados se pueden reclamar en un momento posterior, con un período de reclamo que se extenderá durante algunos años (> 3 años).

Con las empresas que han implementado NEM funcionando hoy, nuestro objetivo era no afectar las operaciones de nuestros socios y partidarios, así como no forzar la migración de conjuntos de datos.

Almacenamiento de datos de Nemesis

El primer bloque de la red pública de Catapult contendrá todas las solicitudes de suscripción válidas en forma de transacciones convencionales de Catapult. Estas transacciones están firmadas por sus respectivos emisores.

En un intento de distribuir el conocimiento sobre lo que se incluirá en el bloque de némesis, las solicitudes de suscripción se almacenan en la cadena de bloques NEM utilizando transacciones de transferencia con mensajes simples que contienen objetos JSON.

En la siguiente captura de pantalla se muestra un ejemplo de una solicitud de suscripción válida para un registro de espacio de nombres:

Como puede ver, la transacción contiene bastante información en su campo de mensaje. Esto se debe a que contiene una Transacción de registro de espacio de nombres firmada que puede ejecutarse tal como está en la red pública de cadenas de bloques Catapult recién configurada.

De hecho, estas transacciones firmadas se crean con el SDK de TypeScript para Catapult y se almacenan en la cadena de bloques NEM utilizando las funciones de NanoWallet.

: advertencia: para permitir la migración de cuentas de múltiples firmas con la misma configuración que en la cadena de bloques NEM, se requiere que todos los cosignatarios involucrados interactúen durante el proceso de suscripción.

Implicaciones técnicas

Esta sección analiza las implicaciones de la migración de los conjuntos de datos almacenados en una red blockchain heredada, en lo sucesivo denominados “datos de cadena de bloques NEM” y “cadena de bloques NEM”, a una red de cadena de bloques pública Catapult recién configurada.

La tecnología de catapulta ofrece muchas más funciones que las mencionadas en este documento. El único propósito de explicar las características de Catapult en este documento es proporcionar la información básica necesaria para comprender los elementos específicos de decisión de migración.

Verificación de firma

Las transacciones en NEM y Catapult están firmadas criptográficamente por el propietario (s) de los fondos. Esto tiene la ventaja de ser verificable en cualquier momento con la firma y la clave pública del firmante. De hecho, una firma es determinista y puede ser verificada por terceros con la clave pública del firmante: el mismo mensaje con la misma clave privada siempre produce la misma firma.

Esta propiedad de ser verificable también es lo que permite validar la cordura / integridad de dichos datos de blockchain. De hecho, cualquier transacción que aparezca en un bloque debe haber sido firmada por el propietario (s) de la cuenta emisora.

El protocolo Catapult usa criptografía de curva elíptica, más específicamente usa la curva retorcida de Edwards (ed25519-donna). De hecho, Catapult usa pares de claves que se pueden representar como puntos en la curva ed25519. Estos pares de claves, un par de clave privada y clave pública, se utilizan para firmar datos y publicar firmas junto con conjuntos de datos en la red Catapult.

Inclusión Bloque Nemesis

El bloque de némesis en Catapult es el primer bloque de la red. Puede contener transacciones que generalmente se firman con la cuenta de némesis. La cuenta de némesis es una cuenta efímera que solo puede emitir transacciones incluidas en el bloque de némesis, no se puede usar para emitir transacciones en bloques posteriores de la red.

La distribución del mosaico de divisas de la red también se realizará en el bloque de némesis. Esto es posible porque la cuenta de Némesis es la propietaria del mosaico de monedas y el espacio de nombres de la red (por ejemplo: nem.xem). De hecho, el bloque de némesis puede incluir una serie de transacciones de transferencia emitidas por la cuenta de némesis y recibidas según lo previsto en la configuración de distribución.

En base a esta configuración de bloque de némesis, proponemos incluir cargas de transacciones firmadas dentro del archivo de configuración. Esto permitirá ejecutar 1) transacciones de modificación de cuenta de firma múltiple firmadas por cosignatarios y 2) transacciones de registro de espacio de nombres firmadas por su propietario.

Característica Catapult Multi-Signature Opt-In 

La tecnología Catapult actualiza la función de firma múltiple de varias maneras en comparación con el sistema heredado que todavía está en su lugar. Una de estas actualizaciones implica que las cuentas cosignatarias deben enviar una firma conjunta para la configuración de firma múltiple: la transacción de modificación de firma múltiple inicial.

: advertencia: esta característica no debe confundirse con la llamada migración de suscripción. De hecho, Catapult Multisig Opt-In Feature es una función de protocolo que se introdujo con catapult-server.

: advertencia: Catapult también introduce límites en ambos, el número de cosignatarios que puede tener una cuenta y el número de cuentas de los cuales uno puede ser cosignatario.

Estrategias de migración de conjunto de datos

En la siguiente tabla, encontrará las estrategias de migración de conjuntos de datos analizadas para la migración de conjuntos de datos heredados.

Estrategía Descripción 
Migración Out-putMigración automática de conjuntos de datos
Migración Opt-Out y Opt-In Migración manual de espacios de nombresMigración manual de múltiples firmas
Migración Opt-inMigración manual de cuentasMigración manual de espacios de nombresMigración manual de múltiples firmas

Inhabilitar migración

En el caso de la denominada estrategia de exclusión voluntaria, las siguientes son las implicaciones técnicas de la migración de conjuntos de datos heredados:

  • Todas las cuentas (multigrado y no multigrado) se migran sin la interacción del propietario (usuario final).
  • Todos los espacios de nombres se migran sin la interacción del propietario (usuario final).
  • El bloque de némesis mantendría transacciones que no están firmadas. Esto significa que no es posible verificar el bloque / transacciones criptográficamente.
  • : advertencia: las transacciones de modificación de firma múltiple no están firmadas, por lo tanto, no se pueden verificar criptográficamente, en el bloque de némesis.
  • : advertencia: las transacciones de registro del espacio de nombres no están firmadas, por lo tanto, no se pueden verificar criptográficamente, en el bloque de némesis.

Migración Opt-Out y Opt-In 

En el caso de una estrategia de migración denominada Opt-Out & Opt-In, las siguientes son las implicaciones técnicas de la migración de conjuntos de datos heredados:

  • Todas las cuentas que no son multigrado, excepto las que se excluyen, se migran sin la interacción del propietario (usuario final).
  • Los fondos de las cuentas no habilitadas que no sean multigrupo se mantendrán en un fondo de reserva (tokens no reclamados).
  • Las cuentas de firma múltiple que envían una solicitud de suscripción se migran con la interacción de los propietarios (usuarios finales).
  • Los fondos de cuentas multigrado que no hayan optado por el prelanzamiento se mantendrán en un fondo de reserva (tokens no reclamados).
  • Los espacios de nombres para los que se envió una solicitud de suscripción se migran con la interacción de los propietarios (usuarios finales).
  • las transacciones de modificación de firma múltiple se firman, por lo tanto, se pueden verificar criptográficamente, en el bloque de némesis.
  • las transacciones de registro del espacio de nombres se firman, por lo tanto, se pueden verificar criptográficamente, en el bloque de némesis.

Migración Opt-In 

En el caso de una estrategia de migración denominada Opt-In, las siguientes son las implicaciones técnicas de la migración de conjuntos de datos heredados:

  • Las cuentas que no son de multigrado que envían una solicitud de suscripción se migran con la interacción de los propietarios (usuarios finales).
  • Los fondos de cuentas que no sean multigrado que no hayan optado por el prelanzamiento se mantendrán en un fondo de reserva (tokens no reclamados).
  • Las cuentas de firma múltiple que envían una solicitud de suscripción se migran con la interacción de los propietarios (usuarios finales).
  • Los fondos de cuentas multigrado que no hayan optado por el prelanzamiento se mantendrán en un fondo de reserva (tokens no reclamados).
  • Los espacios de nombres para los que se envió una solicitud de suscripción se migran con la interacción de los propietarios (usuarios finales).
  • las transacciones de modificación de firma múltiple se firman, por lo tanto, se pueden verificar criptográficamente, en el bloque de némesis.
  • las transacciones de registro del espacio de nombres se firman, por lo tanto, se pueden verificar criptográficamente, en el bloque de némesis.

Catapult Opt-In Migration

Como se anunció en la primera actualización del comité de migración, el comité de migración recomendó una migración de aceptación con un proceso de asignación de tokens: también es posible utilizar la estrategia de exclusión y el comité de migración está inspeccionando su ejecución en paralelo. En esta sección se detallarán los detalles de la ejecución técnica de Catapult Opt-In Migration.

Declaraciones de problemas

Las cuentas con varias firmas solo se pueden migrar con el consentimiento de sus firmantes.

Las transacciones de registro del espacio de nombres deben estar firmadas por los propietarios del espacio de nombres.

Solución propuesta

Como es posible firmar transacciones Catapult sin conexión, se puede implementar un complemento de NanoWallet Opt-In para ejecutar la creación de transacciones Catapult firmadas. Múltiples tipos de transacciones entrarán en juego para cubrir más conjuntos de datos a ser portados.

Las transacciones catapulta firmadas se almacenarán en la cadena de bloques NEM mediante mensajes de transacciones de transferencia que contienen objetos de transferencia de datos predefinidos (DTO). En particular, estos DTO mantendrán toda la información requerida para ejecutar las transacciones en la red pública Catapult recién configurada.

Los objetos de transferencia de datos (DTO) predefinidos que estarán involucrados en esta migración opcional incluyen transacciones Catapult firmadas con:

a) Transacciones de registro de espacio de nombres con una duración de un año.

b) Transacciones de modificación de cuenta de firma múltiple.

El proceso de migración debe ser reproducible fuera de NanoWallet dado que algunos usuarios finales administran su XEM con diferentes aplicaciones de cliente. Esto se abordará con el lanzamiento en forma de un paquete de suscripción publicado en NPM. Una implementación de referencia para el proceso de suscripción se entregará como un Complemento NanoWallet para ser incluido en una versión posterior.

Definición del proceso

  1. El usuario final debe enviar una solicitud de suscripción preformateada para los conjuntos de datos que desea poseer en la red Catapult recién configurada. Esto se ilustra en la siguiente imagen:

2. En el momento de un bloque de instantáneas predefinido, se recopilarán todas las solicitudes de suscripción y reflejarán el contenido del bloque de némesis. Una ilustración de esto se encuentra en la siguiente imagen:

3. La herramienta de generación de bloques de némesis  lee un bloque preprogramado de propiedades de archivo e incluye propiedades de transacciones firmadas.

Ventajas clave

Fortalezas

Todos los conjuntos de datos copiados de la cadena de bloques NEM y recreados en la red pública de cadenas de bloques de Catapult son verificables y están registrados en Catapult con transacciones Catapult firmadas convencionales.

Las solicitudes de aceptación se almacenan en una red pública de blockchain en funcionamiento y, por lo tanto, ninguna de las entidades involucradas en el proceso de migración no puede alterarlas ni alterarlas.

El bloqueo de némesis resultante puede ser auditado / verificado por cualquier tercero provisto con la información de clave pública de la cuenta de némesis de Catapult.

Los usuarios finales dan su consentimiento para la migración: esto evita la aplicación de la migración y es menos probable que tenga consecuencias legales para las partes ejecutoras.

El proceso también se puede usar después del lanzamiento con un origen de fondos diferente.

Desventajas clave

Debilidad

Fecha límite sólida para las solicitudes de suscripción previa al lanzamiento.

El procedimiento no se ajusta a todas las jurisdicciones. Sin embargo, probablemente ninguno lo hará.

Solución complicada que aprovecha dos protocolos diferentes de blockchain para migrar conjuntos de datos.

Debates en curso

La comunidad ha mencionado la idea de definir una estrategia que aproveche los procesos de ambos: Migración de exclusión voluntaria y Migración de exclusión voluntaria. Esto permitiría requerir menos interacciones de los usuarios finales.

De hecho, es posible definir la siguiente estrategia:

Todas las cuentas que no son multigrado se migran de manera predeterminada, excepto aquellas que envían una solicitud de exclusión explícita.

Las cuentas con varias firmas que deben migrarse deben enviar una solicitud de suscripción.

Los propietarios de espacios de nombres que deben migrarse deben enviar una solicitud de suscripción.

El cambio en la definición del proceso es trivial. De hecho, una solicitud de exclusión voluntaria puede formatearse de la misma forma que una solicitud de exclusión voluntaria para cuentas que no son de múltiples registros. El comité de migración está investigando actualmente el cambio para implementar solicitudes de exclusión voluntaria para cuentas que no sean multigrado.

Como se mencionó en Twitter y en nuestro Foro, es importante que comparta sus comentarios con nosotros sobre este tema.

Próximos pasos

  • Se debe determinar un bloque para cuando ocurre la instantánea.
  • El comité de migración está trabajando en la ejecución del proceso de migración propuesto.
  • Se está evaluando el cambio de incluir una opción de exclusión para cuentas que no son multigrado.
  • Actualmente se realizan pruebas con respecto a la recopilación de solicitudes de suscripción.

Fuente: Foro de NEM