Padre del lenguaje Move: el lenguaje de contrato inteligente Sui Move es adecuado para productos Web3

Origen: Red Sui

Recientemente hablamos con Sam Blackshear, CTO 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 que Sui puede ampliar y el impacto de la tecnología descentralizada en la creación de beneficios. del destinatario

El siguiente es el contenido de esta entrevista:

**P1. En primer lugar, ¿puede dar una descripción general de qué es un lenguaje de programación, qué cualidades buscan más los desarrolladores al elegir un lenguaje de programación y qué lo impulsa a desarrollar su propio lenguaje de programación? **

Un lenguaje de programación es solo una herramienta para una interacción amigable, segura, eficiente y clara con las computadoras, y esto es especialmente importante para las computadoras. No podemos comunicarnos con computadoras en lenguaje natural, porque todo el significado del lenguaje natural es ser rico y expresivo. Cuando usa un tono ligeramente diferente o elige formas sutilmente diferentes de expresar palabras, su oración o párrafo puede significar algo completamente diferente.

**En los lenguajes de programación, lo más importante es tener una semántica definida con precisión. **Cuando escribes un programa, sabes lo que va a hacer. Si le hace pequeños ajustes, sabrá adónde irá ese cambio. Esto tiene que mantenerse en varios niveles, como si pudieras escribir código en un idioma de origen, tiene un significado y luego se traduce a otras formas de representación, entonces también debería tener el mismo significado, hasta que llegue a la máquina. Lo mismo ocurre con los módulos de procesamiento.

**Creo que los lenguajes de programación son de naturaleza específica de dominio o tarea específica, a diferencia de los lenguajes naturales. ** De lo contrario, con un solo lenguaje de programación, puede hacerlo todo. Pero la razón por la que existen múltiples lenguajes de programación es porque no puedes ser bueno en todas las áreas. Están tratando de apuntar a dominios de problemas específicos y enfocarse en resolver esos problemas. Como ejemplo, si observa el lenguaje de programación Rust que usamos para escribir la cadena de bloques Sui y la mayoría del otro trabajo del sistema que hacemos en Mysten, se enfoca en escribir código que sea rápido y eficaz mientras mantiene la seguridad. Le da acceso a detalles de bajo nivel como memoria, estructuras de subprocesos o concurrencia, pero no le permite cometer errores como lenguajes anteriores como C o C++.

Así que la historia de Move es muy similar a eso. Cuando lo creé, no fue para crear un nuevo idioma. Mencionaste anteriormente lo que los desarrolladores buscan en un idioma. Preguntan: "¿Este lenguaje es adecuado para lo que estoy tratando de lograr?". Pero creo que quizás lo más importante es: "¿Este lenguaje tiene una gran comunidad? ¿Hay muchas bases de datos disponibles? ¿Hay muchos programadores que lo usan? ¿Hay ¿Hay buenos recursos educativos? *" Estos son muy importantes, por lo que el listón para crear un nuevo idioma debe ser muy alto, incluso si el idioma en sí es mejor, pero si no tiene estos factores, entonces su ventaja no tiene sentido. Construir una comunidad grande y vibrante desde cero es muy difícil.

**Q2、****¿Puedes compartir más sobre el desarrollo de Move? **

**El movimiento se originó en el proyecto Libra de Facebook. **Mi tarea en ese momento no era crear un nuevo idioma, sino "Libra necesita tener contratos inteligentes, así que descubra qué debemos hacer." Observé todo tipo de cosas. ¿Podemos usar Solidity en EVM? ¿Deberíamos tomar un lenguaje regular de propósito general, como WASM o JVM, y usarlo para Libra? ¿O deberíamos crear el nuestro?

La decisión de crear algo propio se basó en investigar los contratos inteligentes existentes, comprender qué intentaban hacer los programadores y dónde los ayudaron ciertos lenguajes y dónde los decepcionaron. Mi conclusión es que, en muchos casos, los lenguajes de contratos inteligentes existentes los decepcionan.

Esto queda claro por el pobre historial de seguridad de Solidity, pero más fundamentalmente, estos contratos inteligentes no son tipos de programas muy tradicionales. Solidity no es un lenguaje construido para lo que la gente hace ahora. No lo critico porque es el primer lenguaje de contrato inteligente que aún no sabe qué quiere hacer la gente con él. Una vez que ve lo que la gente está tratando de hacer con él, creo que está claro que necesita un conjunto diferente de abstracciones y herramientas de programación que el lenguaje Solidity no proporciona.

Entonces, estos contratos inteligentes son muy simples, básicamente hacen dos cosas. Definen los tipos de activos, incluidas las reglas sobre cuándo se pueden transferir los activos, qué puede hacer con ellos, quién puede leerlos y quién puede escribirles**. **** Y verifique la política de control de acceso para determinar quién es el propietario del activo, quién puede usarlo y quién puede operar en él. **Todo gira en torno a los activos, y desea que esos activos tengan los mismos atributos que los activos físicos. Si te entrego algo, entonces deberías tenerlo y yo no lo tendré más.

**En los contratos inteligentes existe el concepto de propiedad y transferencia de propiedad, pero en una computadora todo son bits y bytes y se pueden copiar libremente. **Y, ya sabes, estos conceptos no existen en el mundo real. Entonces, desea un lenguaje que le brinde buenas abstracciones sobre propiedad y homogeneización. Como en el mundo real, pero sin obligar a los programadores a reinventarlo. Quiere garantías básicas de seguridad.

Esto es lo que hace Move y por qué terminamos creando este nuevo lenguaje. Estas tareas son fundamentales para la programación de contratos inteligentes. Son difíciles de recrear en otros lenguajes, incluidos los lenguajes de contrato inteligente existentes, y queremos diseñar todo el lenguaje en torno a proporcionar estas funciones básicas para que los programadores puedan escribir código de manera segura y eficiente sin tener que escribir código cada vez. Ambos reinventan la rueda.

**Q3、****Sui usa una variante de Move llamada Sui Move. ¿Qué motivó estos cambios? ¿Qué funciones de Sui Move son ideales para crear productos en Web3? **

Varios factores impulsaron estos cambios, uno de los cuales fue el objetivo del proyecto Libra original de construir una red de pagos compatible. Así que tratamos de diseñar Move (como un lenguaje de propósito general). Pero también hicimos algunas cosas conscientemente, porque Libra quiere tener restricciones. Una de las cosas importantes es que no quieren que las personas puedan enviar ciertos activos a cualquier lugar. Quieren que las personas creen explícitamente una cuenta y establezcan algunas reglas cuando se crea la cuenta, como que el propietario de la cuenta debe pasar por la verificación KYC. O puede haber una tarifa para crear la cuenta, o solo puede ser creado por una pequeña persona con permiso para crear una cuenta. Algunas personas crean cuentas. Dado que el objetivo de Libra es realizar pagos compatibles y contratos inteligentes compatibles, existen estas limitaciones. Pero en el mundo Web3 más general, es todo lo contrario. no quiere cumplir en el nivel básico, este es el concepto de contratos inteligentes. Quiere que las cosas sean lo más libres posible, es perfectamente posible enviar algo a cualquier dirección. Entonces no debería tener una creación de cuenta explícita porque eso bloqueará varios casos de uso.Este es un factor importante.

Otro factor es que mientras nos enfocamos en los activos en Move, en ese momento en Libra no pensamos en cómo llevar el enfoque de los activos a la transacción en sí. Entonces, cuando llega al nivel de transacción, todavía tiene esta API, donde ingresa números y valores booleanos y cosas que no son activos, y luego en Move, usa esos números para retirar activos de las cuentas y hacer otras cosas. Resulta que la mayor parte del código que ejecutas es esta desagradable contabilidad de sacar esto, sacar aquello, sacar otra cosa, y bueno, tengo todos los activos que quiero. Aquí están, en mi estudio, y ahora puedo empezar a hacer algo significativo. Y luego, al final del proceso, podría decir: "Está bien, vuelva a poner esos activos en esta cuenta, vuelva a ponerlos en esa cuenta, reorganícelos.

En Sui, hemos pensado, si cada programa comienza y termina de esta manera, ¿podemos abstraerlo? Entonces, la lógica para procesar la transacción lo hará por el programador, y desde el punto de vista del programador, solo tienen los activos que necesitan listos y comienzan a hacer el trabajo interesante de inmediato. ****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 almacenaban en cuentas y los programadores tenían que extraerlos explícitamente. En Sui, cuando ingresan a la parte Mover de la transacción, el tiempo de ejecución de Sui ya adquirió los activos. Esto es más conveniente para los programadores porque no tienen que hacer todo esto antes y después de la contabilidad, y también nos permite determinar si podemos ejecutar una transacción en paralelo con otra sin ejecutarla realmente. algunas otras cosas más eficientemente.

También hemos realizado otros trabajos realmente interesantes, como aprovechar un modelo de datos basado en objetos para bloques de transacciones programables. Este es un tema algo técnico que me complace discutir en profundidad. Pero esos dos factores fueron los principales impulsores de la divergencia del Move original.

**Q4、****¿Puede compartir más información sobre los bloques de transacciones programables y sus funciones? **

Me gusta usar una analogía para explicar que otras cadenas de bloques son como un patio de comidas en un centro comercial. Quieres un helado, vas al puesto de helados, sacas tu tarjeta de crédito y pagas. Pero si decides que todavía quieres una hamburguesa, entonces vas al puesto de hamburguesas y pagas de nuevo. No soy un glotón, pero si quisiera comer ocho cosas, tendría que hacer ocho transacciones separadas. **Donde Sui es más un buffet, cada oferta es más que una sola cosa. Una vez que haya pagado por el buffet, hay muchas cosas que puede hacer sin costo adicional. **Puedes comer helado, puedes comer hamburguesas, puedes mezclarlos todos.

Para hacer este concepto un poco más concreto, en el caso simple, si está enviando 100 transacciones para acuñar 100 NFT, puede enviar una transacción que acuña 100 NFT. Tal costo es casi el mismo que el costo de acuñar un NFT. También puede hacer paquetes de transacciones heterogéneas, de modo que la primera transacción en un bloque tome un personaje de Mario de su billetera multisig, y la segunda transacción solicite un Mario, que luego le permite jugar el juego. Si ganas el juego y obtienes el trofeo, tal vez un tercer intercambio coloque el trofeo en una vitrina de trofeos que compartes con amigos. **Lo bueno es que los bloques de transacciones programables permiten a los programadores escribir código de tal manera que el juego no tiene que saber acerca de las billeteras multisig o cómo se almacena Mario, ni tiene que saber acerca de su gabinete de trofeos o cómo se implementa. . **

**Los bloques de transacciones programables consisten en transacciones con objetos de entrada y salida. **Si necesita un objeto de entrada, puede obtener ese objeto sin importar de dónde proviene, y pasar su salida al objeto que lo necesita, y tampoco importar a dónde se pasa. En otras cadenas de bloques, el acoplamiento es más fuerte, por lo que los juegos deben integrarse con billeteras multisig y casilleros de trofeos, o todos deben implementar alguna interfaz común y tener un acoplamiento más fuerte. **Sui hace que las llamadas combinaciones ad-hoc sean mucho más fáciles. **Por ejemplo, si las tuberías coinciden, podemos hacerlo en una sola transacción.

**P5、****¿Cuáles son los beneficios de los bloques de transacciones programables para los usuarios? **

Para los usuarios, los beneficios de los bloques de transacciones programables incluyen costos de gasolina más bajos, porque puede agrupar todas las operaciones en una sola transacción en lugar de realizar transacciones separadas. Además, requiere menos aprobaciones. Si está utilizando un sistema que requiere la aprobación de transacciones, solo necesita hacerlo una vez y luego lo hace todo de una vez. Otro beneficio es la atomicidad, si desea hacer tres cosas diferentes y quiere que la tercera operación tenga éxito solo si las dos primeras operaciones tienen éxito, si esas operaciones tienen que ser transacciones independientes, entonces no puede hacer que suceda. Sin embargo, si puede ponerlos todos en una transacción, puede lograrlo fácilmente.

**P6, ****Te escuché a ti y a otros hablar sobre el desarrollo en Sui como una gran experiencia para los programadores y es importante. ¿Tiene alguna anécdota para compartir con los programadores de Web3 experimentados y nuevos que comienzan con Sui Move? **

Para aquellos desarrolladores que provienen de otros lenguajes de programación Web3, su experiencia de desarrollo en Move y Sui Move es más eficiente y segura. Acabo de estar en un podcast sobre Bucket Protocol y están construyendo un proyecto DeFi realmente genial en Sui. A medida que demuestran la arquitectura del sistema, describen cómo funcionan juntos los diferentes componentes. Dijeron que si hubieran escrito este proyecto en Solidity, podría haber tomado ocho meses, pero con Sui Move tomó solo dos meses y confían mucho en su seguridad. La forma en que funciona el lenguaje es muy cercana a la idea de una cartera de proyectos en su cabeza. En el mundo de Solidity, la conexión es menos directa.

Este es solo un ejemplo, pero escuchamos muchos casos similares en los que las personas dicen que se desarrollan más rápido en el idioma y se sienten más seguras cuando terminan. Me hace feliz escuchar eso. Pero en cierto modo, esto no es sorprendente, analizamos Solidity y aprendimos sobre los problemas. Diseñamos explícitamente escenarios sobre cómo hacerlo más seguro y rápido. Analizamos lo que los desarrolladores del lenguaje intentaban hacer y cómo diseñar el lenguaje para satisfacer sus necesidades, en lugar de satisfacer lo que ya existía. El idioma está diseñado para los problemas que tienen las personas, por lo que cuando cambian, realmente aprecian el idioma.

**Dicen que la ventaja de ser el primero en moverse es importante, pero supongo que en este caso, es la ventaja de ser el que llega tarde lo que importa más. **

Así es, eso es todo.

**P7、****Ha mencionado esto cuando mencionó Sui Move y las características generales orientadas a objetos de Sui. Pero, ¿puede articular más claramente la conexión entre el diseño de Sui Move y la capacidad de Sui para lograr la adopción masiva de Web3, baja latencia, bajo costo y escalabilidad? **

Una de las cosas que desconfiamos de contribuir a Sui, y el problema que enfrentan otras plataformas, es que si tiene una capacidad limitada, ya sea como 15 transacciones por segundo (TPS) como Ethereum o 100 o 1,000 transacciones, si es un número fijo, luego, cuando la plataforma tenga demasiado éxito, alcanzará el límite superior de capacidad. En este punto, se degrada la experiencia para todos los que usan la plataforma. Si solo hay 1.000 vacantes, debe elegir las 1.000 más importantes, que pueden seleccionarse mediante licitación de gas u otros métodos. Para todos, los precios de la gasolina aumentarán, la latencia aumentará, o ambos. Se excluyeron muchos casos de uso, ya que solo aquellos que pudieran pagar las tarifas más altas tendrían éxito, mientras que otros tendrían que buscar en otra parte o esperar más. Esta no es una buena situacion.

**Sui tiene como objetivo la escalabilidad horizontal. **Se puede lograr una determinada cantidad de rendimiento si se asigna una determinada cantidad de hardware. Si se requiere más rendimiento, el validador puede introducir más instalaciones de hardware, sin límite superior. Así es como funcionan todos los servicios Web2. Quiero decir, hay algunas restricciones de ingeniería con las que debe trabajar, no es algo seguro o fácil de hacer, pero todos quieren lograr la escalabilidad horizontal al diseñar servicios web escalables.

Si Sui tiene más clientes o usuarios, nuestro objetivo es que Sui siga creciendo y todo debería funcionar. Eso sí, manteniendo una latencia muy baja. No desea sacrificar la latencia mientras aumenta el rendimiento.

En el sistema Libra, estas características no se consideran. Es solo un sistema de pago a pequeña escala, con cientos de operadores de pago, y puede haber decenas de millones de pagos por día, pero no más. Así que adoptamos una arquitectura de caja única, que es más simple y suficiente. Pero en Sui, sabemos que el sistema Libra no funcionará porque no tiene la función de escalabilidad horizontal. Así que pensamos, ¿cómo diseñamos un sistema desde cero que pueda hacer eso? Aquí es donde entra en juego el modelo de datos orientado a objetos. Básicamente, abandonamos el antiguo modelo de datos basado en cuentas porque dificultaba mucho lograr la escalabilidad horizontal. En cambio, si organiza todo en objetos, el estado global es solo un gran mapa de ID de objeto a objetos. Es un almacén de valores clave, y sabemos cómo escalar los almacenes de valores clave, es un problema de ingeniería simple.

Entonces, la pregunta es, ¿cómo diseñamos una estructura de transacción que se adapte a la obtención y actualización de datos del almacén de clave-valor? ¿Cómo fragmentamos un almacén de clave-valor? ¿Cómo decidimos dónde deben procesarse las transacciones? Eso es básicamente de donde viene. Dicho esto, sabemos cómo escalar estas cosas. ¿Cómo convertimos esto en algo que tenga propiedades de cadena de bloques, lecturas verificables, que funcione con Move, etc.? Y luego cómo unirlos de la mejor manera posible.

P8、** En un nivel superior, ¿cómo analiza el potencial de la tecnología descentralizada con los desarrolladores que son escépticos en Web2? **

**Creo que blockchain y las criptomonedas son fundamentalmente una tecnología que elimina la fricción. **Hay barreras que hacen que sea muy difícil para nosotros realizar transacciones financieras, crear aplicaciones o configurar información porque la información no puede cruzar estas barreras, o si las cruza, requiere la ayuda de algunos terceros, y estos primeros El tercero cobra una tarifa por poder brindar asistencia.

Un ejemplo clásico que a la gente le gusta usar es comprar una casa. Hay un comprador y un vendedor, pero cuando realmente realiza los pagos, tiene que haber un agente de plica que no hace nada más que sentarse y depositar los fondos porque el comprador y el vendedor no confían plenamente el uno en el otro. Este es un hecho de la vida. Vamos a lidiar con esto. Sin embargo, si el agente de custodia puede ser un código que sea visible para ambas partes, o verificado por un tercero, entonces puede hacer el trabajo gratis o por mucho menos. El propósito de blockchain no es eliminar a los agentes de custodia en bienes raíces. Este es solo uno de los casos de uso, pero a menudo es el caso.

**Si ya no existe una barrera de interoperabilidad entre la aplicación A y la aplicación B, pero se basa en la misma plataforma subyacente, puede hacer que las cosas fluyan de una aplicación a otra, ya sean elementos dentro de la aplicación, datos, promociones o terceros. -Productos para fiestas construidos sobre ambos. ** O imagine Internet, donde los sitios web comparten datos entre sí a través de cookies, pero esas cookies son solo metadatos de solo lectura. ¿Y si estas cookies pudieran convertirse en moneda? ¿O podría ser un artículo prescindible? ¿O podrían ser programas de fidelización y cupones? Todo tiene esta funcionalidad incorporada. Es muy abstracto, pero ahí es donde reside el potencial. Por lo general, una persona que está construyendo pensará en estos como nuevos superpoderes que puede usar para construir algo más atractivo.

P9、** Para los usuarios finales, incluso si no tienen conocimientos técnicos, ¿sientes dudas cuando consideran la confianza en el código, incluso si la otra opción es una gran entidad central que es opaca? **

No lo creo. Porque hacemos cosas como esta todos los días, ¿verdad? Cuando inicio sesión en mi correo electrónico, no me preocupa que el código elimine uno de mis correos electrónicos, o que cuando envíe un correo electrónico, en realidad no lo envíe. Si eso sucede, entonces probablemente dejaré de usar el correo electrónico o usaré otro proveedor. Creo que es muy similar, por supuesto, no todo el mundo puede leer algo y comprobar cómo funciona.

Y, ya sabes, si quiero comprobar el código del correo electrónico, no puedo porque el código no está allí. Así que la transparencia es un aspecto importante de eso. Si bien no todos pueden hacer esto, algunos pueden probarlo. Y combine eso con la reutilización de cualquier cosa, además de la inmutabilidad. Esa es la clave aquí. Cuando inicio sesión en mi correo electrónico, no sé si el código ha cambiado desde la última vez que hice algo. No hay transparencia en esto. Incluso conociendo esta información, puede obtenerla en Web3 y no puede obtenerla en ningún otro lado.

**Q10、****¿Cuáles son sus expectativas para el desarrollo futuro de Sui Move? **

**Muchas de las funciones en las que nos estamos enfocando actualmente se basan en nuestra experiencia con desarrolladores que lanzaron sus lotes iniciales de paquetes Sui Move y luego analizaron cómo querían desarrollar esas funciones, cuáles eran fáciles de desarrollar y cuáles. unos eran más difíciles. **Sui Move es un gran lenguaje para un paquete de primer lanzamiento, pero para el tipo que voy a cambiar, voy a agregar algunos campos, voy a agregar algunas funciones, lo haré de una manera que sea cohesiva pero que no vaya en contra del uso del paquete inicial Para operar de una manera en la que los usuarios confíen, esto se convierte en un problema muy desafiante. Mucho de lo que hacemos es observar esto y determinar qué características de nivel de lenguaje podemos agregar que brinden a los programadores la flexibilidad de extender mientras mantenemos la confianza de los usuarios del código original.

**Estamos trabajando en muchas características relacionadas con esto, especialmente en los tipos de enumeración. **También estamos trabajando mucho para mejorar la experiencia de conectar Move con el código front-end. A menudo bromeamos diciendo que una aplicación Sui típica tiene un 5 % de código de movimiento y un 95 % de código de front-end. Así que estamos muy enfocados en ese 95%. Pasamos mucho tiempo hablando de Move, pero también nos enfocamos mucho en hacer que otras partes sean más eficientes y facilitar las conexiones. En general, estamos muy enfocados en cómo hacer que la aplicación consista más en Move para mayor seguridad. Al mismo tiempo, ¿cómo hacemos que el 95 % del código sea comprensible tanto para los programadores de Move como para los que no son de Move?