NEM Catapult: Nueva Versión del servidor (Cow)
El lanzamiento de la versión del servidor con nombre en código “Cow” se hizo público. Esta actualización trae nuevas características y algunos cambios de última hora a NEM2.
En las próximas semanas, presentaremos una serie de publicaciones en el blog, que analizarán las características incluidas en Cow y cómo usarlas para cada caso de uso. Puedes encontrar el registro de cambios técnicos aquí.
Actualización del Código Base
El servidor P2P y la puerta de enlace de la API REST han actualizado. El servicio bootstrap (docker) seguirá pronto, mientras que ya se han realizado cambios en los archivos docker.
Estos son cambios de última hora, por lo tanto, es esencial contar con los nuevos SDK de NEM2. Tenga en cuenta: la implementación inicialmente solo sucede con TypeScript / JavaScript. Por favor, mire la biblioteca para las actualizaciones aquí. Otros idiomas SDK seguirán en una etapa posterior.
Comunicación y hoja de ruta
Con el fin de atraer y gestionar las contribuciones al ecosistema NEM, se ha establecido un Comité de Gestión de Proyectos (PMC).
Para alinear el nuevo PMC con el canal de comunicación Slack, algunos de los canales de nem2.slack.com han sido renombrados o eliminados. Esto evita que la información se disperse en diferentes canales.
Las nuevas características propuestas se agregan como un problema a su lanzamiento correspondiente en la biblioteca del servidor. Las propuestas de mejoras NEM se pueden agregar y analizar en GitHub en la biblioteca NIP.
Outlook: La próxima versión se llamará Dragon. La hoja de ruta se presentará a continuación. Este documento se centra en el lanzamiento de “Cow”.
Hoja de Ruta
Lanzamiento | Características | Documentación |
Bison – Cow | Account filter | Protocol / Account Filters |
Persistent state in RocksDB | Protocol / Node / RocksDB | |
Merkle trees | Protocol / Block | |
Cross-chain swaps beyond NEM (ETH, Bitcoin) , ii | Built-in Features / Cross-Chain Swaps | |
Fee improvement | Protocol / Transaction/ Fee | |
Receipts | Protocol / Receipts | |
Separating mosaics from namespaces | Built-in Features / Namespace, Built-in Features / Mosaic | |
Enhancing Harvester capabilities | Protocol / Harvesting | |
Alternative to Eigentrust ++ for node reputation | Protocol / Node | |
Dragon | Next level harvesting capabilities | |
Metadata | ||
TBA | ||
F | TBA | |
TBA | ||
TBA |
Filtros de la Cuenta
Los filtros de cuenta permiten a los titulares de las cuentas bloquear ciertas transacciones. Por ejemplo: los intercambios criptográficos pueden establecer un filtro para que solo permiten transacciones con mosaicos que admiten. Otra aplicación se puede describir para la industria de la cadena de suministro, donde una cuenta se puede usar para representar un activo. La compañía decide solo permitir que los mosaicos entrantes se conozcan en una lista predefinida. Cuando una transacción entrante contiene un mosaico diferente de esa lista, la transacción simplemente falla. Lea mas
Bloqueo de transacciones spam
Filtros disponibles:
- Filtro de mosaico: se puede establecer en la lista blanca / lista negra de ciertos mosaicos
- Filtro de dirección: se puede configurar para transacciones de lista blanca / lista negra desde una dirección determinada
- Filtro de tipo de transacción: se puede configurar en la lista blanca / lista negra de ciertos tipos de transacciones salientes
Parámetros de propiedades de la cuenta
Alias
Con los alias, es posible adjuntar (sub) espacios de nombres a cuentas o mosaicos. Esto permite una distinción más legible por el hombre de los objetos. Es posible enviar una transacción a una cuenta y usar el alias de esa cuenta como una dirección. Lo mismo se aplica a los mosaicos también: puede enviar una transacción con un mosaico utilizando el alias de ese mosaico. Los alias se pueden establecer y eliminar. La vista previa de la documentación se puede encontrar aquí.
Implementación
- Alias de dirección: puede establecer / eliminar un (sub-) espacio de nombres como alias a una cuenta
- Alias de mosaico: puede establecer / eliminar un (sub-) espacio de nombres como alias a un mosaico.
Entradas
Las transacciones complejas se habilitan mediante cambios condicionales en el fondo. Por ejemplo, una Transacción Lockfund (depósito) se devuelve tan pronto como se confirma la transacción consolidada agregada. Sin embargo, no se registra ninguna transacción adicional cuando el fondo de bloqueo se devuelve automáticamente a la cuenta. Esto puede aparecer como un “cambio oculto” que aumenta el saldo de la cuenta. ¡Es por eso que los llamados recibos vienen al rescate! Los recibos proporcionan una prueba para cada cambio oculto. La vista previa de la documentación se puede encontrar aquí.
Características actualizadas
Intercambios de cadenas cruzadas
Se han agregado nuevos algoritmos de hashing para aumentar la compatibilidad con otras cadenas.
Defecto:
- SHA3–256
Nuevo:
- Keccak-256 (compatibilidad ETH)
- Op_Hash_160: primero con SHA-256 y luego con RIPEMD-160 (compatibilidad BTC)
- Op_Hash_256: la entrada se revisa dos veces con SHA-256 (compatibilidad BTC)
Mejoras en las tarifas
Se han realizado cambios a nivel de protocolo en la preparación del sistema de tarifas. Una vista previa se puede encontrar aquí. Este tema merece su propio artículo, por lo que una explicación completa seguirá tan pronto como se materialice.
Cosecha
Este cambio permite la configuración de un mosaico diferente a la moneda de la cadena primaria para la recolección. Esto permite una mayor personalización de las redes privadas y para nuevos modelos criptoeconómicos. Lea mas
Publicación por entregas
Las transacciones que se envían a la puerta de enlace REST de NEM2 se contabilizan en el SDK para un manejo más eficaz en la implementación del protocolo NEM2. Hasta ahora, la serialización fue realizada por la biblioteca flatbuffer (Google). Esta biblioteca será reemplazada por una biblioteca personalizada llamada catbuffer. Lo que generará menos gastos generales y mas confianza en comparación de otros desarrolladores de bajo nivel de terceros. Esto requiere una actualización de cómo SDKs contabiliza las transacciones. Dicha actualización también exige una implementación del generador de código en el lenguaje de programación respectivo. Lea mas
Separando los mosaicos de los namespace
Hasta ahora, los mosaicos tenían que configurarse para caducar después de x cantidad de bloques. Con la nueva implementación, es posible configurar el mosaico para que no caduque, lo que garantiza el uso de mosaicos, incluso si el creador está fuera del negocio.
Los mosaicos ya no se ubican bajo un (sub) espacio de nombres específico, pero pueden existir por sí solos. Se pueden nombrar usando alias, y los mosaicos también se pueden renombrar usando el sistema de alias. Lea mas
Old behaviour | New behaviour | |
Mosaic name | Namespace + own name | Namespace as alias |
Id | Namespace + own name | Id created from a nonce |
Expiration | Set when created | Set to expire or live forever. |
Reputación del nodo (reemplazando a Eigentrust ++)
Los nodos básicamente realizan un seguimiento de la comunicación exitosa en el pasado y utilizan esa lista para volver a conectarse. Esto juega un papel para subvertir los ataques de Sybil, donde las identidades de los nodos se forjan para perturbar el sistema P2P. Lea mas
Para mayor información, siga las redes de Twitter y Telegram
Fuente: Medium