En esta serie en tres partes, revelaremos logros técnicos que pueden mejorar significativamente el procesamiento de datos de aplicaciones que se ejecutan en el Protocolo de Internet Computer (ICP).
Esta actualización es un hito en el roadmap de ICP que actualmente se está promoviendo en toda la red; Stellarator es un avance en la persistencia de datos en la cadena, mejorando enormemente la escalabilidad y capacidad de procesamiento del almacenamiento de datos, brindando nuevas oportunidades a aplicaciones ricas en datos complejos que anteriormente estaban limitadas por el sistema.
Este avance permite a los desarrolladores construir aplicaciones complejas que requieren un procesamiento de datos a gran escala, llevando la tecnología blockchain a nuevos niveles de utilidad.
En la segunda parte de esta serie, Luc Bläser nos llevará a comprender la persistencia ortogonal mejorada de Motoko; si te perdiste la primera parte sobre la persistencia de datos, puedes encontrarla aquí.
Simple, seguro, rápido: La persistencia ortogonal mejorada de Motoko
Motoko introduce la persistencia ortogonal mejorada, una característica única diseñada para aliviar la carga del programador al manejar memoria estable, proporcionando un mecanismo de actualización simple, seguro y rápido.
Motoko siempre ha sido capaz de retener automáticamente el estado del programa durante el proceso de actualización sin necesidad de código adicional para manejar la persistencia; desafortunadamente, la implementación anterior de esta función no podía escalar para datos grandes o profundamente anidados.
Esta función ahora se ha mejorado significativamente en términos de seguridad, rendimiento y escalabilidad; la innovación clave es evitar transferir el estado a la memoria estable simplemente conservando la memoria principal en lugar de borrarla.
El sistema en tiempo de ejecución ahora asegura de manera muy eficiente la consistencia de los datos durante la actualización, independientemente del tamaño de la memoria; al final, cambiamos de 32 bits a 64 bits de memoria principal, ampliando finalmente a una gran cantidad de datos persistentes.
Contexto
Las actualizaciones de contenedores son un desafío en Internet Computer, a menudo implicando una complejidad considerable, sobrecarga y algún riesgo de pérdida de datos; aunque la memoria principal del contenedor (también conocida como memoria WebAssembly) es persistente entre transacciones, en el pasado fue borrada durante las actualizaciones, lo que es un paso bastante artificial, ya que la memoria ya tiene copias de seguridad en archivos en Internet Computer.
La razón de este comportamiento es que las implementaciones de lenguajes de programación de uso común no consideraron la persistencia al diseñar; reorganizan estructuras de memoria de manera no controlada al volver a compilar o ejecutar, y no pueden simplemente usar la memoria de versiones anteriores para restaurar la ejecución del programa modificado.
Por lo tanto, los programadores deben explícitamente utilizar la API de memoria estable o estructuras de datos estables especiales para guardar datos durante el proceso de actualización, algo similar a la arquitectura de computadoras tradicionales que ofrece memoria principal volátil y almacenamiento auxiliar persistente, pero a costa de una mayor complejidad en el desarrollo de software (piense en mapeadores de bases de datos de objetos, etc.).
A diferencia de eso, en Motoko podemos controlar completamente el compilador y el sistema en tiempo de ejecución, lo que también nos permite controlar completamente el diseño de la memoria, lo que permite el soporte de persistencia ortogonal en Motoko, y seguir utilizándolo incluso durante las actualizaciones.
Por lo tanto, los programadores de Motoko pueden desarrollar cómodamente cualquier estructura de datos (tipos de primer orden) en conceptos de lenguaje estándar sin tener que utilizar memoria estable explícita, estructuras de datos estables dedicadas o otras abstracciones similares a bases de datos, ya que el sistema en tiempo de ejecución conservará automáticamente los objetos necesarios.
Anteriormente, el sistema en tiempo de ejecución de Motoko lograba la persistencia ortogonal serializando y deserializando el gráfico de objetos persistentes en memoria estable, lo que causaba serios problemas de escalabilidad y rendimiento, ya que el proceso de serialización/deserialización era muy costoso, incluso podría superar los límites de instrucciones, obstaculizando finalmente las actualizaciones; estos defectos lo hacían poco práctico para aplicaciones más grandes, y por eso rediseñamos el soporte para la persistencia ortogonal en Motoko.
A través de cambios en Internet Computer y el sistema en tiempo de ejecución de Motoko, logramos actualizaciones escalables sin la necesidad de realizar costosas serializaciones y deserializaciones en un espacio de memoria estable auxiliar; en cambio, simplemente mantenemos la persistencia de la memoria principal durante el proceso de actualización, mientras ampliamos el espacio de direcciones de la persistencia ortogonal a 64 bits para poder (en el futuro) expandirnos a la misma capacidad que ofrece la memoria estable de 64 bits.
Persistencia ortogonal mejorada
Nuestro objetivo es simplificar el desarrollo de software en Internet Computer y aliviar la carga del programador al manejar memoria estable; para ello, Motoko ha sido optimizado para la persistencia en Internet Computer, logrando actualizaciones simples, seguras y rápidas:
Simple: A través de la persistencia ortogonal (variables estables en Motoko), cualquier estructura alcanzable de tipo de primer orden se persistirá automáticamente durante el proceso de actualización, sin necesidad de memoria estable o estructuras de datos estables.
Seguridad: El sistema en tiempo de ejecución verifica estrictamente la compatibilidad de tipos durante la actualización y admite múltiples cambios de datos mediante migraciones implícitas, cualquier migración más compleja se puede lograr mediante código personalizado, lo que puede prevenir cualquier daño o malentendido de datos a nivel de memoria.
Rápido: La actualización se vuelve extremadamente rápida, ya que la memoria principal se conserva durante la actualización sin necesidad de copiarla a memoria estable o copiarla desde memoria estable; la memoria principal se ha ampliado a 64 bits para que en el futuro pueda expandirse a un tamaño igual al de la memoria estable.
Descripción general del diseño
Como condición previa para la persistencia ortogonal mejorada, el Protocolo de Internet Computer ha sido ampliado para admitir la retención de memoria principal a través de actualizaciones y memoria principal de 64 bits basada en la propuesta de WebAssembly Memory64.
A través de un diseño personalizado de compilador y sistema en tiempo de ejecución, Motoko define un diseño de memoria invariable en el que todos los objetos se asignan en un montón dinámico y vienen con suficiente metadatos que permiten a la nueva versión del programa acceder de manera segura al estado de versiones anteriores.
Por lo tanto, los segmentos de datos pasivos de WebAssembly se han demostrado útiles, ya que permiten retrasar la asignación de datos estáticos del programa (como texto) en el sistema en tiempo de ejecución, sin necesidad de retener rangos de direcciones estáticas.
Incluso conservaremos el estado del recolector de basura incremental (GC) durante el proceso de actualización, lo que significa que la actualización se puede realizar en cualquier momento, sin tener que esperar a que el GC termine de ejecutarse.
Para asegurar una estricta seguridad de memoria y tipos, el sistema en tiempo de ejecución almacena los tipos de la versión actual del programa y utiliza esta información para verificar la compatibilidad de la memoria al intentar actualizar a una nueva versión del programa.
Dado que esta verificación solo depende del número de tipos y no del número de objetos, la velocidad de actualización es extremadamente rápida y puede escalar a cualquier tamaño de memoria; ciertas migraciones de datos (como agregar o eliminar variables estables, elevar tipos, agregar opciones de variantes, etc.) se admitirán automáticamente, mientras que cualquier migración más compleja se puede programar manualmente, protegiendo continuamente la seguridad de tipos.
Motoko implementó una migración automática de datos de la persistencia clásica tradicional a la persistencia ortogonal mejorada; para permitir cambios radicales en la disposición de la memoria que puedan surgir en el futuro (que esperamos que ocurran raramente), Motoko también incluye un mecanismo de persistencia auxiliar basado en la serialización de memoria estable y algoritmos de copia gráfica, así como un tiempo de fragmentación de determinación infinita que no está sujeto a ninguna limitación de instrucciones del Protocolo de Internet Computer.
Puede encontrar más detalles sobre la persistencia ortogonal mejorada, su diseño, implementación, escenarios de migración de datos y evaluación de rendimiento en nuestro artículo recientemente publicado (Implementando Actualizaciones de Contratos más Inteligentes con Persistencia Ortogonal).
Promoción de producción
El primer paso, la persistencia ortogonal mejorada, se puede usar como una función opcional activada mediante la opción del compilador '--enhanced-orthogonal-persistence', los parámetros correspondientes se pueden especificar en dfx.json de la siguiente manera:
Motoko migrará automáticamente de la antigua persistencia clásica de 32 bits a la persistencia ortogonal mejorada, pero tenga en cuenta que no se admite la operación inversa de degradar de EOP a la persistencia clásica de 32 bits.
En la versión actual, aunque hemos cambiado a 64 bits, Internet Computer solo proporciona 4 GB de memoria principal, lo que es solo una medida conservadora en la primera etapa; seguimos una forma de lanzamiento que evita riesgos, comenzando por lo pequeño y luego aumentando gradualmente la capacidad con el tiempo.
De hecho, debido al cambio a 64 bits y la limitación inicial de 4 GB, se espera que el uso neto de memoria en la fase inicial sea menor que el de 32 bits (ya que el tamaño del puntero se ha duplicado) y el costo de instrucciones para acceder a la memoria de 64 bits también ha aumentado para cubrir conservadoramente los costos de hardware, aunque podría disminuir en el futuro.
Pero lo más importante es que las actualizaciones se volverán muy rápidas y ya no alcanzarán las limitaciones de instrucciones de Internet Computer, incluso en el uso máximo de la pila (también considerando que ya no se requieren ganchos de actualización).
El siguiente paso, tras recopilar comentarios y potencialmente mejorar el sistema y aumentar la capacidad de memoria, es que planeamos hacer de la persistencia ortogonal mejorada el modo predeterminado.
Conclusión
La persistencia ortogonal mejorada de Motoko permite a los desarrolladores de Internet Computer centrarse en sus aplicaciones centrales sin preocuparse por la memoria estable.
Esto no solo permite lograr una persistencia simple y segura, sino que también reduce significativamente el costo de las actualizaciones y el acceso a los datos de Internet Computer.
La persistencia ortogonal mejorada solo se puede lograr a través de un compilador y un sistema en tiempo de ejecución personalizados, tal como lo tenemos ahora para Motoko.
Más información
Luc Bläser, Claudio Russo, Gabor Greif, Ryan Vandersmith y Jason Ibrahim, Implementando Actualizaciones de Contratos más Inteligentes con Persistencia Ortogonal, VMIL 2024:
https://dl.acm.org/doi/10.1145/3689490.3690401
Publicación en el foro de DFINITY - Beta de prueba de la persistencia ortogonal mejorada:
https://forum.dfinity.org/t/beta-testing-motoko-s-enhanced-orthogonal-persistence-eop/35787
Documentación - Persistencia Ortogonal Mejorada de Motoko:
https://internetcomputer.org/docs/current/motoko/main/canister-maintenance/orthogonal-persistence/enhanced
Documentación - Variables estables, actualizaciones y migraciones de datos en Motoko:
https://internetcomputer.org/docs/current/motoko/main/canister-maintenance/upgrades
Estamos encantados de recibir sus comentarios, por favor comparta sus pensamientos en el canal DFINITY Developers X o en el repositorio de GitHub de Motoko.
Únase a nosotros mañana en la Parte 3 de nuestro viaje Stellarator, donde Kamil Popielarz y Yvonne-Anne Pignolet nos enseñarán cómo mejorar el rendimiento de mensajes de entrada.
Contenido IC que le importa
Avances técnicos | Información del proyecto | Actividades globales
Siga el canal de Binance IC
Manténgase al día
