Este es un mensaje conjunto para nuestra comunidad en nombre del Symbol Migration Group, compuesto por The NEM Foundation, NEM Studios, NEM Ventures y Tech Bureau Holdings.
Tokenomics
Recientemente, las discusiones de NIS1 han ocupado un lugar destacado en la agenda del Comité de Migración. Hemos ilustrado en el pasado (en respuesta al sentimiento de la comunidad) que avanzaríamos con el desarrollo de Symbol sin olvidarnos de la red NEM que lo inició todo. Las conversaciones actuales y la planificación giran en torno a 4 temas principales:
Programa supernodo futuro en NIS1
Plan de garantía de nodo más amplio implementado
Revisión de Tokenomics
Comunidad y soporte para desarrolladores
Ingeniería
Servidor
Se realizó un lanzamiento del parche en el servidor para la versión 0.9.3.2. Este pequeño parche cubre una actualización de la versión rocksDb con un aumento a v6.6.4. Se han publicado imágenes de lanzamiento y se han actualizado las referencias de imágenes relacionadas en la herramienta de arranque testnet.
El equipo está trabajando para completar la próxima actualización importante, actualmente destinada a ser la versión 0.9.4.1. Esta actualización traerá un gran cambio en las comunicaciones entre pares / servidor que se cambiarán para aprovechar el estándar TLS 1.3.
Opt-In
Se sigue avanzando en las herramientas para impulsar el proceso de suscripción. El último esfuerzo de trabajo se ha centrado en la actualización para admitir los cambios introducidos en la versión 0.9.3.x del servidor, específicamente la actualización para dejar de admitir la compatibilidad con versiones anteriores de las claves NIS1. Las actualizaciones 0.9.3.x se completarán pronto con un esfuerzo de trabajo y luego se centrará en finalizar los flujos y la funcionalidad de UI / UX tanto para el complemento de billetera nano como para una aplicación de suscripción móvil dirigida. Una vez listo, el equipo intentará lanzar una versión NIS1 testnet para las pruebas finales previas al lanzamiento y recopilar comentarios del público.
Móvil
La billetera móvil está a punto de completarse y está lista para pruebas externas. Para aquellos que se han inscrito para participar, gracias por hacerlo y ser pacientes. El equipo apunta a la función beta completa esta semana. A partir de ese momento, los pasos finales serán la aplicación de actualizaciones de marca, similares a las actualizaciones de marca recientes aplicadas a la billetera de escritorio, luego la configuración y el uso compartido para probadores externos.
Pruebas
Las pruebas generales de los diversos componentes continúan. Un nuevo esfuerzo que comenzará esta semana es una campaña de prueba pública en la plataforma HackerOne. Para aquellos interesados en participar, regístrese allí (https://hackerone.com). La campaña se lanzará esta semana.
Este es un mensaje conjunto para nuestra comunidad en nombre del Symbol Migration Group, compuesto por la Fundación NEM, NEM Studios, NEM Ventures y Tech Bureau Holdings.
Actualización de Tecnología y Producto
El equipo ha estado trabajando durante las últimas semanas en la preparación de la versión 0.9.3.1. Este lanzamiento marca un conjunto clave de actualizaciones en el trabajo hacia el candidato de lanzamiento final. Si bien las actualizaciones son de naturaleza más pequeña, tienen un mayor impacto en varios elementos, incluida la migración de nis1 a la nueva red Symbol, el proceso de suscripción relacionado y el movimiento para romper la compatibilidad clave con nis1.
Gracias por aquellos que han estado trabajando para ayudar a probar los diversos componentes de software. Para aquellos que estén interesados, agradecemos su ayuda y participación, puede unirse a la comunidad de desarrolladores para obtener ayuda o simplemente rastrear los últimos acontecimientos en tiempo real.
El último enlace de invitación siempre está disponible en la parte inferior del sitio del centro de desarrolladores: https://nemtech.github.io.
Los canales de Slack más populares para obtener ayuda en relación con testnet y pruebas generales son:
#help
#sig-testing
0.9.3.1 Actualizaciones de lanzamiento
Servidor
La versión 0.9.3.1 traerá consigo algunas correcciones e incluirá dos cambios importantes de las versiones anteriores del servidor y sdk (s):
NIP # 9: Transacción de solicitud de delegación persistente (LINK): se examinaron las transacciones de solicitud de delegación persistente disponibles anteriormente y el tercero con el que estamos comprometidos hizo algunas recomendaciones para su revisión y comentarios. Se recomendaron actualizaciones al esquema de derivación de claves, así como prácticas de intercambio de claves involucradas en firmas asimétricas y sistemas de encriptación.
NIP # 10: Generación de pares de claves de símbolos y formato de dirección (LINK): También se ha introducido un cambio en el algoritmo de generación de pares de claves y el formato de direcciones. Estos cambios introducen el uso de Sha512 en lugar de los algoritmos de hash Keccak y Sha3 anteriores. Una de las principales características de este cambio es que los pares de claves se generarán utilizando openssl, que está estandarizado en todos los protocolos de comunicación.
NOTA: Con esta actualización del servidor y los cambios clave, habrá ajustes de última hora entre las versiones anteriores. Con esta versión, se creará la próxima generación de la red de prueba. La participación en la nueva versión será la misma que las anteriores, más en la red de prueba a continuación.
Billetera de Escritorio
El equipo de la billetera de escritorio ha estado trabajando en una limpieza y revisión de la base del código. El objetivo es tener la billetera de escritorio en una posición para una gama más amplia de uso y pruebas, incluida la revisión externa a través de una campaña de hackerone (hackerone.com). Este trabajo también se realiza en paralelo con el trabajo inicial de cambio de marca de Symbol, por lo que comenzará a ver una nueva apariencia para la billetera.
Algunas tareas notables en las que se ha trabajado últimamente incluyen las siguientes mejoras:
Uniformización del procedimiento de desbloqueo de cuenta (# 911): la billetera de escritorio solía adoptar un enfoque roto e inseguro de las verificaciones y validaciones de contraseñas. Esos han sido refactorizados y mejorados para usar medidas de seguridad de contraseña estándar.
Uniformización de la creación de firma de transacción (# 923): la revisión del código fuente para la billetera de escritorio incluye un manejo del proceso de firmas que se adapta mejor para trabajar con el protocolo Symbol.
Reescribir el núcleo del software de la billetera de escritorio (# 911): en el ámbito de las mejoras de limpieza y estabilidad, hemos agregado un núcleo de software mejor estructurado a la billetera de escritorio de modo que ahora utilizaría Vuex para mejorar la administración del estado en todo el software.
Billeteras para Móviles
El proyecto de billetera móvil también ha progresado hacia una versión beta pública inicial en las últimas semanas y las pruebas internas para Android e iOS continúan. La limpieza final y las pruebas se llevarán a cabo en las próximas dos semanas, con pasos para aplicar el último tratamiento de diseño para reflejar la marca Symbol. Luego publicaremos el lanzamiento para aquellos interesados en probar.
Para aquellos interesados en participar en la prueba de billetera móvil a través de Android y / o iOS, pueden registrarse aquí:
El esfuerzo relacionado con la billetera móvil está relacionado con la aplicación de la biblioteca de suscripción escrita para Nanowallet e incluye la misma biblioteca y funcionalidad en la billetera móvil. Este esfuerzo ahora está comenzando con el enfoque de la finalización de la biblioteca y el proceso de suscripción. A medida que nos acerquemos a la funcionalidad, anunciaremos cuándo la aplicación de suscripción móvil estará lista para su uso.
Explorador
Explorer continúa actualizándose con una combinación de correcciones de errores y limpieza general. Se ha prestado especial atención al cambio de marca y el tratamiento de diseño de símbolos a la última versión, así como a continuar haciendo que el uso de dispositivos móviles sea más amigable.
Como lista de algunos elementos notables trabajados:
No se puede mostrar el detalle de la transacción: # 308: Debido a que la transacción se ha enviado utilizando el alias (espacio de nombres) en lugar de la identificación del mosaico y el explorador no puede detectar, y se informa en https://nem2.slack.com/archives/GLK87TKM4 / p1581193788037000
La paginación no funciona correctamente en espacios de nombres y lista de mosaicos # 322: porque las solicitudes están tomando el espacio de nombres o la identificación de mosaico incorrectos.
SearchBox agregó soporte de alias # 304: ahora puede buscar alias en el explorador en la búsqueda.
Algunos esfuerzos notables en curso:
Implementar una vista del mosaico de restricción y cuenta de restricción #262#261
Implementar la vista de datos de merkle en el bloque. #324
SDK (s)
La versión NEM2-SDK 0.17.0 (mayor / menor) se ha publicado para tener en cuenta los cambios en la versión 0.9.3.1. Además de las actualizaciones relacionadas con NIP9 y NIP10 anteriores, el equipo también ha abordado:
Mejora de la base de código de prueba de extremo a extremo mediante el uso de promesa asíncrona / espera para todas las pruebas de punto final de descanso
Se actualizó la biblioteca de código del cliente de descanso generado a la última versión 0.8.3. Se agregó el nuevo punto final de tarifas de red y el punto final de salud del nodo. Divida los puntos finales de almacenamiento de nodo e información del servidor de la ruta de diagnóstico a la raíz del nodo.
El parche de servidor NIP10 se ha desarrollado para TS-SDK con PR elevado https://github.com/nemtech/nem2-sdk-typescript-javascript/pull/445
NOTA: como se mencionó anteriormente, NIP 10 se ha aplicado a los SDK, cualquier clave o versión anterior no será compatible con ninguna versión 0.9.3.1 o posterior
CLI
Recientemente ha habido varias actualizaciones de NEM2-CLI con la última versión 0.17.1. Los siguientes son algunos elementos notables trabajados con la última versión:
Restricciones de mosaico y comandos de metadatos: con estos nuevos comandos, podemos decir que la herramienta CLI admite la emisión de todo tipo de transacciones (excepto las transacciones agregadas personalizadas).
Solicitudes de delegación persistentes: intente delegar su importancia a un nodo desde la herramienta de línea de comandos siguiendo esta guía.
Vista previa de transacciones: ahora, puede ver todas las propiedades de las transacciones en un formato legible antes de anunciarlas. Además, puede usar la CLI para depurar cualquier transacción con su carga útil.
Para descargar la última versión, ejecute npm install -g nem2-cli @ latest en su terminal. Recuerde hacer una copia de seguridad y eliminar el archivo ~ .nem2rc.json antes de instalar cualquier versión> 0.16.x.
Test Network
Como se mencionó anteriormente en las notas sobre la actualización de la versión del servidor 0.9.3.1, se introdujeron algunos cambios importantes para que la red de prueba se actualice y actualice.
Similar a las actualizaciones anteriores, nuestro objetivo es lograr una interrupción mínima o nula para todos los que se están desarrollando en la plataforma. Levantaremos una nueva red y comenzaremos a desaprobar la red actual 0.9.2.1 en las próximas semanas.
NOTA: aviso de desaprobación final de la red 0.9.1.1, los nodos finales se eliminarán inmediatamente
Para aquellos que han estado ejecutando nodos de prueba en la red, el proceso para la nueva versión será el mismo. Simplemente tendrá que detener sus servicios en ejecución, eliminar la versión que tiene, descargar la última versión e iniciarla. Una vez iniciado, lo mismo que antes, los servicios se iniciarán y comenzarán a sincronizarse con la nueva red. Se publicará una actualización una vez que se actualicen las herramientas de red de prueba 0.9.3.1.
Actualizaciones relacionadas con la marca de Symbol
Además de los esfuerzos de diseño visual en curso en las billeteras, el explorador de bloques y otros elementos con elementos de interfaz de usuario, también hay un gran esfuerzo para comenzar la migración de otras partes del proyecto para adoptar nombres de símbolos y descripciones relacionadas. Estos incluyen varios repositorios de código fuente, nombres de compilación / paquete y varias referencias de documentación. El proyecto está rastreando este tipo de esfuerzos a través de:
El trabajo de desarrollo y prueba continúa en relación con el software / herramientas opcionales. También se han realizado pruebas en la parte de procesamiento de datos de back-end del esfuerzo del proyecto, mientras que el diseño y las actualizaciones se están aplicando para que las cosas sean compatibles con los últimos cambios 0.9.3.1. Hay otras pocas semanas de revisión y tiempo de prueba para que ocurra después de que 0.9.3.1 esté en vivo, una vez verificado, el equipo se moverá para prepararse para el lanzamiento y el inicio del proceso de suscripción.
Como se mencionó anteriormente en la sección de actualización de billetera móvil, se está trabajando para incluir también la posibilidad de optar por la billetera móvil. Parte de este trabajo está comenzando ahora, algunos dependerán de finalizar el soporte de Nanowallet.
NOTA: con las actualizaciones relacionadas con 0.9.3.1, el proceso de suscripción lo obligará a generar una nueva clave para usar en la red Symbol. Recomendamos mover la generación de claves de todos los usuarios para usar frases mnemotécnicas de forma predeterminada (estilo BIP32).
NOTA: si realiza la suscripción a través de la billetera nano, podrá exportar su cuenta e importar a través de cualquiera de las billeteras / clientes de Symbol admitidos
Notas de propuesta para mejorar
NIP # 6: Jerarquía de múltiples cuentas para carteras deterministas Con las aplicaciones de nuestros clientes abiertas para probar en público, es cada vez más importante que definamos rutas de derivación de uso comunes, como por ejemplo la ruta de derivación de billetera predeterminada para billeteras Symbol o la ruta de derivación de cuenta remota predeterminada para billeteras Symbol.
Se han realizado pocos cambios en NIP#6 desde que se abrió, pero haremos algunos cambios en las próximas semanas debido a los cambios en el nivel de protocolo entrante para la generación de pares de claves.
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í.
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-put
Migració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-in
Migració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
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:
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.
