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

Recientemente, hablamos con Sam Blackshear, el director técnico de Mysten Labs y el fundador 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. Primero, ¿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 llevó a desarrollar su propio lenguaje de programación?

Los lenguajes de programación son herramientas para interactuar de manera amigable, segura, eficiente y clara con las computadoras. Esto es especialmente importante para las computadoras. No podemos comunicarnos con las computadoras usando un lenguaje natural, porque el significado total 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 un vocabulario, el significado de tus oraciones o párrafos puede cambiar completamente.

Y en los lenguajes de programación, lo más importante es tener semánticas definidas con precisión. Cuando escribes un programa, sabes exactamente qué va a hacer. Si haces un pequeño ajuste, sabes qué resultado producirá ese cambio. Esto debe mantenerse en múltiples niveles, por ejemplo, puedes escribir código en un lenguaje fuente que tiene un significado, y luego ser convertido a otras formas de representación, y también debería tener el mismo significado, hasta que llegue 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 dominios específicos o tareas específicas. De lo contrario, solo se necesitaría un lenguaje de programación para completar todas las tareas. Pero la razón por la que existen múltiples lenguajes de programación es porque no se puede sobresalir en todos los campos. Están trabajando para enfocarse en áreas problemáticas específicas y en resolver esos problemas. Por ejemplo, si miras el lenguaje de programación Rust que usamos para escribir la blockchain Sui y la mayoría de los otros sistemas 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 memoria, estructuras de hilos o concurrencia, pero no te deja cometer errores en ello como lo hacían lenguajes anteriores (como C o C++).

Por lo tanto, la historia de Move es muy similar a esto. Cuando lo creé, no era para crear un nuevo lenguaje. Mencionaste anteriormente qué buscan los desarrolladores en un lenguaje. Preguntan, "¿es este lenguaje adecuado para la tarea que quiero completar?" Pero creo que puede ser más importante preguntar, "¿tiene este lenguaje 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 que la barrera para crear un nuevo lenguaje debe ser muy alta; incluso si ese lenguaje en sí es mejor, 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 sobre el estado de desarrollo de Move?

Move se originó en el proyecto Libra de Facebook. Mi tarea en ese momento no era crear un nuevo lenguaje, sino "Libra necesita 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, entender lo que los programadores intentan hacer y en qué áreas ciertos lenguajes les ayudan y les decepcionan. Mi conclusión es que, en muchos casos, los lenguajes de contratos inteligentes existentes realmente les decepcionan.

Este punto 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 criticándolo, 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 pueden transferir los activos, qué se puede hacer con ellos, quién puede leerlos y quién puede escribir las reglas para ellos. Y verifican las políticas de control de acceso para determinar quién posee el activo, quién tiene permiso para usarlo y quién tiene permiso para manipularlo. 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, y se pueden copiar libremente. Además, sabes que estos conceptos no existen en el mundo real. Por lo tanto, deseas un lenguaje que te brinde 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 fundamentales para la programación de contratos inteligentes. Son difíciles de recrear en otros lenguajes, incluidas las lenguas de contratos inteligentes existentes. Queremos diseñar un lenguaje completo que ofrezca estas funciones básicas, de modo 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? ¿Cuáles son las características de Sui Move que son muy adecuadas para construir productos en Web3?

Los siguientes factores impulsaron estos cambios, uno de los cuales es que el objetivo original del proyecto Libra era construir una red de pagos compliant. Por lo tanto, intentamos diseñar Move como un lenguaje universal. Pero también hicimos algunas cosas de manera consciente, porque Libra quería tener condiciones restrictivas. 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 momento de crear la cuenta, como que el propietario de la cuenta debe realizar la verificación KYC. O podría ser necesario pagar una tarifa para crear la cuenta, o solo un pequeño grupo de personas con permisos de creación de cuentas podría crearla. Dado que el objetivo general es que Libra quiera realizar pagos compliant y contratos inteligentes compliant, existen estas limitaciones. Pero en el ámbito más general de Web3, la situación es exactamente 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, y que se pueda enviar algo a cualquier dirección. Luego no deberías hacer 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, a pesar de que nos centramos en los activos en Move, en ese momento no consideramos cómo introducir el enfoque en los activos en la propia transacción en Libra. Por lo tanto, cuando llegas al nivel de transacción, todavía solo tienes esta API, donde ingresas números y valores booleanos, entre otras cosas que no son activos. Luego, en Move, utilizas 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 trabajo de libro mayor tedioso, que implica sacar esta cosa, sacar aquella cosa, sacar otras cosas, bien, tengo todos los activos que quiero. Están aquí, en mi estudio, ahora puedo comenzar a hacer algo significativo. Luego, al final de este proceso, podrías decir: "Está bien, devuelve estos activos a esta cuenta, devuélvelos a aquella cuenta, reorganízalos."

En Sui, hemos reflexionado profundamente, si cada programa comienza y termina de esta manera, ¿podemos abstraerlo? Por lo tanto, la lógica para manejar las transacciones permitirá a los programadores realizar esta operación, desde la perspectiva del programador, solo necesitan preparar los activos necesarios y comenzar inmediatamente a trabajar en algo interesante. Este es el modelo de datos centrado en objetos que existe en Sui. En el Move original, teníamos un modelo de datos basado en cuentas, los activos se almacenan bajo cuentas y los programadores deben extraerlos explícitamente. Mientras que en Sui, al entrar en la parte de Move de la transacción, Sui ya ha adquirido los activos. Esto es más conveniente para los programadores, ya que no necesitan hacer todo ese trabajo de contabilidad antes y después, y también es el secreto que nos permite determinar, sin ejecutar realmente, si una transacción se puede ejecutar en paralelo con otra, escalar Sui horizontalmente y realizar otras operaciones de manera más eficiente.

También hemos realizado otros trabajos muy interesantes, como el uso de modelos de datos basados en objetos para bloques de transacciones programables. Este es un tema algo técnico, y estoy muy dispuesto a discutirlo en profundidad. Pero estos dos factores son el principal motor detrás de las divergencias 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 cadenas de bloques son como la zona de comida de un centro comercial. Quieres comer 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. Y Sui es más como un buffet, 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 deseas 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 empaquetado de transacciones heterogéneas, por ejemplo, la primera transacción en el bloque saca 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 colocará 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 tiene que saber cómo se almacena la billetera multifirma o Mario, tampoco tiene que saber tu vitrina de trofeos 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 obtenerlo 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 acoplación es más fuerte, por lo que el juego debe integrarse con billeteras multisig y vitrinas de trofeos, o todos deben implementar alguna interfaz común y tener un acoplamiento más fuerte. Sui hace que lo que se llama combinación temporal sea más fácil. Así, si las tuberías coinciden, podemos completarlo en una transacción.

Q5, ¿cuáles son los beneficios de un bloque 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, el número de aprobaciones requeridas también se reduce. Si el sistema que estás utilizando requiere aprobaciones de transacción, solo necesitas realizar 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 operación solo tenga éxito si las dos primeras operaciones son exitosas, no podrás lograrlo si estas operaciones deben ser transacciones independientes. Sin embargo, si puedes agruparlas en una sola transacción, podrás lograrlo fácilmente.

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

Para los desarrolladores que provienen 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 programa de pódcast sobre el Bucket Protocol, donde están construyendo algo muy interesante en Sui.