Un artículo de opinión de Josh Primero, arquitecto jefe de protocolos de RDX Works.  Después de lanzar Radix Engine V2 en la red Babylon, eché un vistazo más de cerca a la nueva ola de VM que emergen en la escena DeFi. Uno de los más atractivos es MoveVM de Sui, una mejora con respecto al MoveVM original de Diem.  He estado entusiasmado con la arquitectura de Sui desde hace algún tiempo, ya que comparte un par de filosofías técnicas clave con Radix:  Uso de semántica de movimiento para permitir la programación orientada a activos.  Aprovechar el conocimiento de las dependencias estatales para escalar el consenso a través de un ordenamiento parcial (en lugar de abstraer demasiado y trasladar la escalabilidad a una capa superior, la moda del momento)  Técnicamente hablando, me pareció genial cómo utilizaron un lenguaje y un código de bytes compilado que captura estáticamente las dependencias de estado mínimas necesarias para ejecutar cierta lógica.  Esto no sólo da como resultado una ejecución rápida, sino que también proporciona beneficios de seguridad, ya que las dependencias estatales y las escrituras estatales de una transacción están bien delimitadas.  Sin embargo, este logro tiene un costo. Los programadores de DeFi deben gestionar un modelo más difícil y, en ocasiones, poco intuitivo, repitiendo incluso problemas bien conocidos del EVM.  Veamos ahora estos problemas en lo que he encontrado que son cuatro fallas en la máquina virtual de Sui.  1. Objeto primitivo que es demasiado genérico  La mayor innovación de MoveVM de Sui (o MoveVM en general) es el uso de la semántica de mover/pedir prestado en la capa de código de bytes. Esto significa que su máquina de bajo nivel puede comprender la propiedad y el movimiento de los objetos; ¡bastante fresco!  Cada objeto en la VM de Sui por lo tanto  , un valor escrito con lógica asociada que puede ser propiedad, movida y compartida.    actúa como un NFT  Desafortunadamente, debido a que un objeto puede hacer muchas más cosas genéricas en este modelo, el programador de DeFi tiene la carga de definir y administrar una máquina de estado de vida de objeto compleja.   Específicamente, en Sui, al definir una nueva estructura, un programador debe especificar una combinación de 4 habilidades (“copiar”, “soltar”, “clave” y “almacenar”), cada una de las cuales afecta a la máquina de estados de diferentes maneras. Además, un programador debe gestionar si, al crear una instancia, un objeto debe compartirse, transferirse, devolverse como un valor o congelarse.  Tener una configuración incorrecta en cualquiera de estos puede causar errores sutiles que podrían provocar la pérdida de fondos.  Por ejemplo, en el siguiente código, usamos Sui  para implementar un préstamo flash simple. ¿El problema? Accidentalmente agregamos la capacidad de entrega al Recibo.    Patrón de patata caliente  Este pequeño error permite que el prestatario se quede con el préstamo sin tener que devolverlo y abandone el recibo. (Hay otro error con la relación FlashLoan y Receipt, ¡mira si puedes encontrarlo!)  Entonces, si bien es conceptualmente elegante y simple organizar una VM alrededor de una abstracción de un solo objeto con un conjunto de habilidades, desde el punto de vista de un programador, es difícil entender las repercusiones de cada una porque hay mucho estado de bajo nivel que administrar.  Esto no es muy diferente a los problemas de gestión de memoria de los lenguajes más antiguos y a la razón por la que las máquinas virtuales recolectoras de basura tuvieron tanto éxito. A los programadores de aplicaciones no les importa administrar estados de bajo nivel, como cuándo se puede liberar la memoria; se preocupan por los objetos y las relaciones entre esos objetos.  De manera similar, los programadores de DeFi se preocupan fundamentalmente por los activos y la lógica en torno al movimiento y la propiedad de estos activos. Los activos por sí solos no tienen una lógica inherente, y la lógica que gestiona estos activos no necesita "moverse" ni ser "propiedad".  MoveVM de Sui combina estas dos cosas muy diferentes en una abstracción de objeto genérica que crea un modelo mental de programación DeFi difícil.  2. Sin envío dinámico  Una característica definitoria de MoveVM es el uso de despacho estático, lo que significa que no existe una capa de indirección entre una llamada a una función y su ejecución durante el tiempo de ejecución. Las llamadas a funciones y su lógica subyacente están vinculadas estáticamente en el momento en que se publica un nuevo paquete. Esto permite que la VM sea rápida y predecible, pero a expensas de una menor flexibilidad y un entorno de programación más difícil de usar.  Echemos un vistazo a tres repercusiones de la falta de despacho dinámico.  2a) Sin composición funcional  Debido a que la VM debe conocer la función exacta que se llamará en el momento de la publicación del código, es imposible componer diferentes funciones juntas; un patrón muy común en la programación normal (por ejemplo, interfaces en lenguajes OO o rasgos en Rust).  Echemos un vistazo a un incentivo simple del Fondo de Liquidez. Si tuviera que escribir un incentivo que agregara un 10% a tu contribución en Rust, se vería así:   De esta manera, mi LiquidityEnhancer funcionaría con cualquier grupo que implemente el rasgo Pool (Sí, para los quisquillosos de Rust, este rasgo también está vinculado estáticamente. Este es solo un ejemplo de composición de funciones).  Esto es imposible en Sui ya que “contribuir” debe ser una función ya definida. En su lugar, se tendría que publicar un nuevo paquete que vincule a implementaciones exactas del grupo para cualquier implementación nueva del grupo.  2b) Sin devoluciones de llamada dinámicas ni punteros de función  De manera relacionada, poder ejecutar lógica arbitraria a través de alguna interfaz genérica es una construcción muy útil, especialmente en la configuración de DeFi.  Imagine un futuro ejecutor incentivado que incentiva a una persona que llama en el futuro a invocar alguna lógica arbitraria (por ejemplo, para el uso de pagos retrasados). En Rust, esto se vería así:   Sin embargo, esto no es posible en Sui debido a la falta de despacho dinámico. En su lugar, se debería publicar un nuevo paquete IncentivizedFutureExecution para cada método que quiera utilizar dicha característica.  2c) Actualizabilidad incómoda  Sui tiene apoyo para  . Desafortunadamente, debido a la invariante de envío estático, la gestión de actualizaciones de paquetes es más incómoda y menos segura de lo que se esperaría.   actualización y versionado de paquetes  En primer lugar, no es posible realizar actualizaciones de código fluidas y transparentes. Si tengo un paquete que realiza llamadas a otro paquete y el otro paquete tiene una actualización de corrección de errores requerida, debo publicar un nuevo paquete yo mismo si quiero la corrección.   Con cada vez más dependencias de paquetes, esto puede conducir fácilmente a una explosión de actualizaciones de paquetes incluso con una simple corrección de errores de un paquete muy utilizado.   En segundo lugar, todo el código antiguo siempre existirá (es necesario ya que cualquier otro código que dependa de él deberá poder llamarlo) incluso en los casos en que este código pueda tener errores y/o código malicioso. Para contrarrestar esto, la carga recae en la capa de aplicación para mantener un esquema de control de versiones sensato en el estado de sus objetos.  3. Un patrón de buzón incómodo  Sui lanzó recientemente un  que se puede describir mejor como una forma de enviar un objeto a otro objeto sin que el otro objeto lo sepa (anteriormente, esto solo era posible con Direcciones). Para poder acceder a ese objeto se debe ejecutar una transacción separada con conocimiento de esta transferencia.    Patrón de transferencia a objeto  Esta construcción es útil para eliminar la dependencia del estado del objeto receptor; no muy diferente a enviar UTXO a otra dirección en el modelo UTXO (la parte de recepción también es similar a demostrar la propiedad a través de scripts testigo de UTXO). El consenso de Sui puede entonces aprovechar esta falta de discordia y paralelizar mejor dicha transacción.  Sin embargo, esta mejora en el rendimiento no está exenta de desventajas en materia de seguridad. El hecho de que los objetos puedan recibirse sin información sobre el objeto receptor (¡incluso si existe o no!) introduce la posibilidad de perder el acceso a esos objetos enviados para siempre.  Esto es posible si el objeto receptor no admite el objeto que se envía. Tal falla es similar a enviar un token ERC-20 por error a un contrato inteligente que no admite ese token (una causa   común de pérdida de fondos). muy  Además, el hecho de que existan dos tipos de relaciones entre padres e hijos, una en la que el padre conoce a sus hijos y otra en la que los hijos conocen a sus padres, crea un modelo más complicado de lo que es típico en la programación tradicional.   ¿Existe algún enfoque que conserve los beneficios de rendimiento sin programar en esta estructura incómoda? Yo creo que sí. Requiere el uso de punteros inmutables junto con otros enfoques CRDT, pero lo cubriré en un artículo futuro.  4. Programación de estado compartido incómoda  La máquina virtual de Sui está optimizada para programar y ejecutar en un estado no contencioso. Esto ha llevado a algunas mecánicas de programación bastante incómodas cuando en realidad es necesario lidiar con un estado compartido. Echemos un vistazo a algunos de estos.  4a) No hay referencias almacenadas  La máquina virtual de Sui no tiene noción de referencias almacenadas. Si lo hubiera, perdería la capacidad de analizar estáticamente las dependencias de estado de una función y, por lo tanto, perdería la capacidad de paralelizar. La consecuencia de esto es que la carga de gestionar las referencias almacenadas ahora recae en el programador/usuario.  Por ejemplo, digamos que tengo un objeto que requiere un precio de un Oráculo específico en una de sus funciones. En Rust, esto puede verse así:   En Sui, debido a que las referencias no se pueden almacenar, esta relación entre MyDefi y Oracle debe describirse de una manera más funcional:   ¡Pero espera! Ahora se puede pasar cualquier oráculo arbitrario. Para garantizar que se utilice el oráculo correcto, el  debe ser usado:    Patrón de puntero de identificación  Este patrón, en comparación con las referencias habituales, es más frágil y se debe tener cuidado para implementar la relación correcta. A medida que el gráfico de relaciones entre objetos crece y se vuelve más complejo, es difícil imaginar que esta carga de programación se amplíe muy bien (por ejemplo, ¿qué pasa si la llamada get_price de Oracle también tiene sus propias dependencias)?  Además, siempre habrá una carga para la persona que llama, ya sea un código de transacción o de paquete, para pasar la referencia correcta. Si esta referencia puede cambiar, esto supone otra carga adicional para la persona que llama para asegurarse de que la referencia se haya actualizado al estado más reciente.  4b) Seguridad de tipo no dinámico para casos relacionados  A diferencia de la programación tradicional, en la programación DeFi es muy útil poder verificar si una instancia es parte del mismo "grupo de instancias" que otra instancia.  Por ejemplo, sería bueno comprobar que la unión de dos monedas tiene el mismo identificador de moneda:   El problema al implementar esto con la semántica genérica tradicional es que los genéricos se utilizan para representar tipos, no "un grupo de instancias relacionadas".  De una manera bastante inteligente, Sui pudo solucionar este problema a través de su  . En este patrón compatible con el sistema, básicamente dijeron que si desea un nuevo grupo de instancias relacionadas, cree este nuevo tipo especial que representará el identificador de este grupo.   Patrón de testigo único  Una gran ventaja de esto es que no es necesario cambiar la capa del lenguaje en absoluto, y uno podría simplemente usar una semántica genérica bien conocida para lograr este tipo de seguridad.  El mayor defecto es que se debe implementar un nuevo tipo (y por lo tanto, un nuevo paquete) cada vez que se crea un nuevo grupo de cosas relacionadas. No se puede simplemente crear una nueva Coin<T> dinámicamente sin implementar un nuevo paquete, por ejemplo.   Conclusión  MoveVM de Sui fue construido según los estándares de los ingenieros de sistemas: una VM basada en primitivas de bajo nivel conceptualmente simples, aplicadas estáticamente.  Desafortunadamente, simple no significa fácil, y su insistencia en evitar patrones normales de objetos compartidos hace que su capa de aplicación sea bastante compleja y poco intuitiva de programar.  DeFi es un mundo de objetos compartido y desordenado: grupos con gran liquidez a los que cualquiera puede acceder, protocolos de préstamo donde cualquiera puede pedir prestado y prestar, oráculos a los que cualquiera puede invocar, y la composición e interacción de todos estos objetos ocurre al mismo tiempo.  Paralelizar un ecosistema de este tipo es el santo grial de las DLT, y el intento de Sui funciona bien, excepto que lleva demasiado desorden a la capa de aplicación.  Si bien es cierto que algunos de los problemas podrían resolverse con mejores herramientas y soporte de lenguaje (   ), algunos son irreparables sin grandes cambios en la máquina virtual (   ). 1 Objeto primitivo que es demasiado genérico, 4 Programación de estado compartido incómoda 2 Sin envío dinámico, 3 Un problema incómodo Patrón de buzón

Buy XRD with card or bank transfer via Switchere.

Este audio es producido en el idioma original de la historia!

MoveVM de Sui: una revisión completa

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Crecimiento de las criptomonedas: creación de perfiles de usuarios eficaces

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Una breve introducción a la teoría del cerebro de Boltzmann

Aumente su productividad con estas 18 herramientas para desarrolladores 🚀🔥

Crecimiento de las criptomonedas: creación de perfiles de usuarios eficaces

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Una breve introducción a la teoría del cerebro de Boltzmann

Aumente su productividad con estas 18 herramientas para desarrolladores 🚀🔥

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps