Entrevista con el padre de Move: ¿Por qué el lenguaje de contratos inteligentes Sui Move es adecuado para construir productos Web3?

Recientemente, hablamos con Sam Blackshear, director técnico de Mysten Labs y creador del lenguaje de programación Move, sobre por qué desarrolló Sui Move, un nuevo lenguaje de programación de contratos inteligentes, las capacidades de escalabilidad de Sui y los beneficios de la tecnología descentralizada para los constructores.

A continuación se presenta el contenido de esta entrevista:

Q1, en primer lugar, ¿puede resumir qué es un lenguaje de programación, cuáles son las cualidades más importantes que los desarrolladores consideran al elegir un lenguaje de programación y qué lo impulsó a desarrollar su propio lenguaje de programación?

Los lenguajes de programación son solo una herramienta para interactuar de manera amigable, segura, eficiente y clara con las computadoras, lo cual es especialmente importante para ellas. No podemos comunicarnos con las computadoras usando lenguaje natural, porque el significado del lenguaje natural radica en su riqueza y capacidad de expresión. Cuando usas un tono ligeramente diferente o eliges una forma sutilmente distinta de expresar vocabulario, el significado de tu oración o párrafo puede cambiar completamente.

En los lenguajes de programación, lo más importante es tener una semántica definida con precisión. Cuando escribes un programa, sabes exactamente qué va a hacer. Si realizas un pequeño ajuste, sabes qué resultado producirá este cambio. Esto debe mantenerse en múltiples niveles; por ejemplo, puedes escribir código en un lenguaje fuente que tiene un significado, y luego se convierte en otra forma de representación, y también debe tener el mismo significado, incluso hasta llegar al módulo de procesamiento de la máquina.

Creo que, a diferencia del lenguaje natural, la esencia de los lenguajes de programación está dirigida a un campo específico o tarea específica. De lo contrario, solo se necesitaría un lenguaje de programación para realizar todas las tareas. Pero la razón por la que existen múltiples lenguajes de programación es porque no puedes sobresalir en todos los campos. Están trabajando para enfocarse en problemas específicos y concentrarse en resolver esos problemas. Por ejemplo, si miras el lenguaje de programación Rust, que utilizamos para escribir la blockchain Sui y la mayoría de los otros sistemas en los que trabajamos en Mysten, se centra en escribir código que sea rápido y de alto rendimiento, al mismo tiempo que garantiza la seguridad. Te permite acceder a detalles de bajo nivel como la memoria, la estructura de hilos o la concurrencia, pero no te deja cometer errores de la misma manera que lenguajes anteriores como C o C++.

Por lo tanto, la historia de Move es muy similar a esto. Cuando lo creé, no fue para crear un nuevo lenguaje. Mencionaste antes qué es lo que los desarrolladores buscan en un lenguaje. Preguntan: "¿Este lenguaje es adecuado para la tarea que quiero realizar?" Pero creo que puede ser más importante preguntar: "¿Este lenguaje tiene una gran comunidad? ¿Hay muchas bases de datos disponibles? ¿Hay muchos programadores usándolo? ¿Hay buenos recursos educativos?" Todo esto es muy importante, por lo tanto, el umbral para crear un nuevo lenguaje debe ser muy alto, incluso si el lenguaje en sí es mejor, pero si no tiene estos factores, entonces su ventaja no tiene sentido. Es muy difícil construir desde cero una comunidad grande y vibrante.

Q2, ¿puede compartir más información sobre el desarrollo de Move?

Move se originó en el proyecto Libra de Facebook. Mi tarea en ese momento no era crear un nuevo lenguaje, sino que "Libra necesitaba tener contratos inteligentes, así que averigüemos qué deberíamos hacer." Miré una variedad de cosas. ¿Podemos usar Solidity en EVM? ¿Deberíamos usar un lenguaje genérico convencional, como WASM o JVM, y aplicarlo a Libra? ¿O deberíamos crear algo propio?

Decidir crear nuestras propias cosas se basa en el estudio de los contratos inteligentes existentes, entendiendo lo que los programadores intentan hacer, así como los lugares en los que ciertos lenguajes los ayudan y los decepcionan. Mi conclusión es que, en muchos casos, los lenguajes de contratos inteligentes existentes realmente los decepcionan.

Esto se puede ver claramente en el mal historial de seguridad de Solidity, pero más fundamentalmente, estos contratos inteligentes no son un tipo de programa muy tradicional. Solidity no es un lenguaje construido para lo que la gente está haciendo ahora. No estoy tratando de criticarlo, porque es el primer lenguaje de contratos inteligentes y aún no sabía lo que la gente quería hacer con él. Una vez que ves lo que la gente intenta hacer con él, creo que es obvio que necesitas un conjunto diferente de abstracciones y herramientas de programación que el lenguaje Solidity no proporciona.

Por lo tanto, estos contratos inteligentes son muy simples, básicamente hacen dos cosas. Definen el tipo de activo, incluyendo cuándo se puede transferir el activo, qué se puede hacer con él, quién puede leerlo y las reglas sobre quién puede escribir en él. Además, verifican la política de control de acceso, determinando quién posee el activo, quién tiene permitido usarlo y quién tiene permitido operar con él. Todo gira en torno al activo, deseas que estos activos tengan las mismas propiedades que los activos físicos. Si te entrego algo, entonces deberías poseerlo, yo ya no lo poseo.

En los contratos inteligentes existe el concepto de propiedad y transferencia de propiedad, pero en la computadora, todo son solo dígitos y bytes, que pueden ser copiados libremente. Además, sabes que estos conceptos no existen en el mundo real. Por lo tanto, deseas un lenguaje que pueda proporcionarte una buena abstracción sobre la propiedad y la homogeneización. Como en el mundo real, pero sin obligar a los programadores a reinventarlo. Deseas obtener garantías básicas de seguridad.

Esta es la función de Move y por qué finalmente creamos este nuevo lenguaje. Estas tareas son básicas para la programación de contratos inteligentes. Son difíciles de recrear en otros lenguajes, incluidas las lenguas de contratos inteligentes existentes, y queremos diseñar todo el lenguaje en torno a la provisión de estas funciones básicas, para que los programadores puedan escribir código de manera segura y eficiente, sin tener que reinventar la rueda cada vez que quieran escribir algo de código.

Q3, Sui utiliza una variante de Move, llamada Sui Move. ¿Qué motivó estos cambios? ¿Qué características de Sui Move son muy adecuadas para construir productos en Web3?

Varios factores han impulsado estos cambios, uno de los cuales es que el objetivo inicial del proyecto Libra era construir una red de pagos compliant. Por lo tanto, intentamos diseñar Move como un lenguaje general. Pero también hicimos algunas cosas de manera consciente, porque Libra quería tener restricciones. Una de las cosas importantes es que no querían que las personas pudieran enviar ciertos activos a cualquier lugar. Querían que las personas crearan explícitamente una cuenta y establecieran algunas reglas al crear la cuenta, como que el propietario de la cuenta debe realizar la verificación KYC. O tal vez se necesiten pagar tarifas para crear la cuenta, o solo un pequeño grupo de personas con permiso para crear cuentas puede hacerlo. Dado que el objetivo general es que Libra desea realizar pagos compliant y contratos inteligentes compliant, existen estas restricciones. Pero en el ámbito más general de Web3, la situación es precisamente la opuesta. No deseas que haya cumplimiento en el nivel básico, esa es la concepción de los contratos inteligentes. Quieres que las cosas sean lo más libres posible, se puede enviar algo a cualquier dirección. Entonces no deberías realizar una creación de cuenta explícita, ya que eso bloquearía varios casos de uso. Este es un factor importante.

Otro factor es que, aunque nos centramos en los activos en Move, en ese momento no consideramos cómo introducir el enfoque en los activos dentro de la propia transacción en Libra. Por lo tanto, cuando llegas al nivel de la transacción, todavía solo tienes esta API, en la que ingresas números y valores booleanos, cosas que no son activos, y luego en Move, usas esos números para extraer activos de la cuenta y realizar otras operaciones. Resulta que la mayor parte del código que ejecutas es este tedioso trabajo de libro mayor, que incluye sacar esta cosa, sacar aquella cosa, sacar otras cosas, bien, tengo todos los activos que deseo. Están aquí, en mi estudio, ahora puedo comenzar a hacer algo significativo. Luego, al final de este proceso, puedes decir: "Bien, pon estos activos de vuelta en esta cuenta, ponlos de vuelta en aquella cuenta, reorganízalos."

En Sui, después de una cuidadosa reflexión, ¿podemos abstraer esto si cada programa comienza y termina de esta manera? Por lo tanto, la lógica para manejar transacciones será completada por los programadores, desde el punto de vista de los programadores, solo necesitan preparar los activos necesarios y comenzar de inmediato a realizar trabajos interesantes. Este es el modelo de datos orientado a objetos que existe en Sui. En el Move original, teníamos un modelo de datos basado en cuentas, los activos se almacenaban bajo cuentas y los programadores debían extraerlos explícitamente. En Sui, al entrar en la parte de Move de la transacción, los activos ya han sido adquiridos por el tiempo de ejecución de Sui. Esto es más conveniente para los programadores, ya que no necesitan realizar todo ese trabajo de registro antes y después, y también es la arma secreta que nos permite determinar si una transacción puede ejecutarse en paralelo con otra sin ejecutarla realmente, escalar Sui horizontalmente y realizar otras operaciones de manera más eficiente.

También hemos realizado otro trabajo muy interesante, como la utilización de modelos de datos basados en objetos para bloques de transacciones programables. Este es un tema bastante técnico y estoy más que dispuesto a profundizar en él. Pero estos dos factores son los principales motores que conducen a la divergencia con el Move original.

Q4, ¿podría compartir más información sobre los bloques de transacciones programables y sus funciones?

Me gusta usar una analogía para explicar, otras blockchains son como el patio de comidas de un centro comercial. Si quieres un helado, vas al puesto de helados y sacas tu tarjeta de crédito para pagar. Pero si decides que también quieres una hamburguesa, entonces vas al puesto de hamburguesas y pagas de nuevo. No soy una persona glotona, pero si quiero comer ocho cosas, tengo que hacer ocho transacciones separadas. Sui es más como un buffet, donde cada transacción no es solo una cosa. Una vez que pagas la tarifa del buffet, puedes hacer muchas cosas sin costo adicional. Puedes comer helado, puedes comer hamburguesas, puedes mezclarlas.

Para hacer este concepto un poco más concreto, en un caso simple, si necesitas enviar 100 transacciones para acuñar 100 NFT, puedes enviar una transacción que acuñe 100 NFT. El costo de esto es casi el mismo que el de acuñar un NFT. También puedes realizar empaquetamientos de transacciones heterogéneas, por ejemplo, la primera transacción en el bloque retira un personaje de Mario de tu billetera multifirma, mientras que la segunda transacción solicita un Mario y te permite jugar. Si ganas el juego y obtienes un trofeo, tal vez la tercera transacción coloque el trofeo en una vitrina compartida con amigos. Lo genial es que los bloques de transacciones programables permiten a los programadores escribir código de esta manera, el juego no necesita conocer la billetera multifirma o cómo se almacena a Mario, tampoco necesita conocer tu vitrina o cómo se implementa.

Los bloques de transacciones programables están compuestos por transacciones que tienen objetos de entrada y salida. Si necesitas un objeto de entrada, puedes obtener ese objeto sin preocuparte de dónde proviene, y luego pasar su salida al objeto que lo necesita, igualmente sin preocuparte de a dónde se pasará. En otras blockchains, la acoplamiento es más fuerte, por lo que los juegos deben integrarse con wallets multi-firma y vitrinas de trofeos, o todos deben implementar alguna interfaz común y tener un acoplamiento más fuerte. Sui hace que las llamadas combinaciones temporales sean más fáciles. Así, si las tuberías coinciden, podemos completar en una transacción.

Q5, ¿cuáles son los beneficios de los bloques de transacciones programables para los usuarios?

Para los usuarios, los beneficios de los bloques de transacción programables incluyen tarifas de gas más bajas, ya que puedes agrupar todas las operaciones en una sola transacción, en lugar de realizar transacciones individuales. Además, se reducirá el número de veces que se necesita aprobación. Si el sistema que estás utilizando requiere aprobación de transacciones, solo necesitas hacer una aprobación y luego se completarán todas las operaciones de una vez. Otro beneficio es la atomicidad; si deseas hacer tres cosas diferentes y quieres que la tercera solo tenga éxito si las dos primeras operaciones se completan con éxito, no podrás lograr esto si esas operaciones deben ser transacciones independientes. Sin embargo, si puedes incluirlas todas en una transacción, podrás lograrlo fácilmente.

Q6, he escuchado que usted y otros han comentado que desarrollar en Sui es una gran experiencia para los programadores, y eso es importante. ¿Tiene alguna anécdota que compartir sobre la experiencia de programadores Web3 con experiencia y nuevos que comienzan a usar Sui Move?

Para aquellos desarrolladores que vienen de otros lenguajes de programación Web3, su experiencia de desarrollo en Move y Sui Move es realmente más eficiente y segura. Acabo de participar en un episodio de podcast sobre Bucket Protocol, y están construyendo un no en Sui.