Entrevista com o fundador da linguagem Move: Por que a linguagem de contratos inteligentes Sui Move é adequada para construir produtos Web3?

Recentemente, tivemos uma conversa com Sam Blackshear, o Chief Technology Officer da Mysten Labs e fundador da linguagem de programação Move, sobre por que ele desenvolveu a nova linguagem de programação de contratos inteligentes Sui Move, as capacidades de escalabilidade do Sui e os benefícios da tecnologia descentralizada para os construtores.

Segue o conteúdo da entrevista:

Q1, primeiro, você pode resumir o que é uma linguagem de programação, quais qualidades os desenvolvedores mais se preocupam ao escolher uma linguagem de programação e o que o levou a desenvolver sua própria linguagem de programação?

As linguagens de programação são uma ferramenta para interagir de forma amigável, segura, eficiente e clara com os computadores. Isso é especialmente importante para os computadores. Não podemos nos comunicar com os computadores usando a linguagem natural, pois todo o significado da linguagem natural reside na sua riqueza e capacidade de expressão. Quando você usa um tom ligeiramente diferente ou escolhe uma forma ligeiramente diferente de expressar um vocabulário, o significado da sua frase ou parágrafo pode mudar completamente.

E na linguagem de programação, o mais importante é ter semântica definida com precisão. Quando você escreve um programa, você sabe exatamente o que ele vai fazer. Se você fizer um pequeno ajuste, você sabe qual será o resultado dessa mudança. Isso precisa ser mantido em vários níveis, por exemplo, você pode escrever código em uma linguagem de origem que tem um significado, e então ser convertido para outras formas de representação, e isso também deve ter o mesmo significado, até chegar ao módulo de processamento da máquina.

Eu penso que, ao contrário das linguagens naturais, a essência das linguagens de programação é direcionada a domínios ou tarefas específicas. Caso contrário, apenas uma linguagem de programação poderia ser utilizada para realizar todas as tarefas. Mas a razão pela qual existem várias linguagens de programação é que não se pode ter um bom desempenho em todos os domínios. Elas estão se esforçando para se concentrar em problemas específicos e focadas em resolvê-los. Por exemplo, se você olhar para a linguagem de programação Rust que usamos para escrever a blockchain Sui e a maior parte dos outros sistemas que funcionam na Mysten, ela se concentra em escrever código que seja rápido e de alto desempenho, ao mesmo tempo garantindo segurança. Ela permite que você tenha acesso a detalhes de baixo nível, como memória, estruturas de threads ou concorrência, mas não permite que você cometa erros da mesma forma que linguagens anteriores (como C ou C++).

Portanto, a história do Move é muito semelhante a isso. Quando eu a criei, não era para criar uma nova linguagem. Você mencionou anteriormente o que os desenvolvedores procuram em uma linguagem. Eles perguntariam: "Esta linguagem é adequada para a tarefa que quero realizar?" Mas eu acho que pode ser mais importante perguntar: "Esta linguagem tem uma grande comunidade? Existem muitos bancos de dados disponíveis? Há muitos programadores a usá-la? Existem bons recursos educacionais?" Tudo isso é muito importante, portanto, a barreira para criar uma nova linguagem deve ser muito alta, mesmo que essa linguagem em si seja melhor. No entanto, se não tiver esses fatores, então suas vantagens não têm sentido. Construir uma comunidade grande e vibrante do zero é muito difícil.

Q2, você pode compartilhar mais sobre o desenvolvimento do Move?

Move origina-se no projeto Libra do Facebook. Minha tarefa na época não era criar uma nova linguagem, mas sim "Libra precisa ter contratos inteligentes, então descubra o que devemos fazer." Eu examinei uma variedade de opções. Podemos usar Solidity no EVM? Devemos usar uma linguagem genérica comum, como WASM ou JVM, e aplicá-la ao Libra? Ou devemos criar algo nosso?

Decidir criar nossas próprias coisas é baseado na pesquisa sobre contratos inteligentes existentes, entender o que os programadores estão tentando fazer, e em que certas linguagens os ajudam e os decepcionam. Minha conclusão é que, em muitos casos, as linguagens de contratos inteligentes existentes realmente os decepcionam.

Isto pode ser claramente visto a partir do péssimo histórico de segurança do Solidity, mas mais fundamentalmente, estes contratos inteligentes não são muito tipos de programas tradicionais. Solidity não é uma linguagem construída para as coisas que as pessoas estão a fazer agora. Não estou a criticar, pois é a primeira linguagem de contratos inteligentes e ainda não sabia o que as pessoas queriam fazer com ela. Uma vez que você vê o que as pessoas tentam fazer com isso, eu acho que é óbvio que você precisa de um conjunto diferente de abstrações e ferramentas de programação, que a linguagem Solidity não fornece.

Portanto, esses contratos inteligentes são muito simples, eles basicamente fazem duas coisas. Eles definem o tipo de ativo, incluindo quando o ativo pode ser transferido, o que você pode fazer com ele, quem pode lê-lo, quais são as regras sobre quem pode escrevê-lo. E verificam as políticas de controle de acesso, determinando quem possui o ativo, quem está autorizado a usá-lo e quem está autorizado a operá-lo. Tudo gira em torno do ativo, você quer que esses ativos tenham as mesmas propriedades que os ativos físicos. Se eu entregar algo a você, então você deve possuí-lo, eu não o possuo mais.

Nos contratos inteligentes, existe o conceito de propriedade e transferência de propriedade, mas no computador, tudo são apenas dígitos e bytes, e podem ser copiados livremente. Além disso, você sabe que esses conceitos não existem no mundo real. Portanto, você deseja que haja uma linguagem que possa fornecer uma boa abstração sobre propriedade e homogeneização. Assim como no mundo real, mas sem forçar os programadores a reinventá-la. Você deseja obter garantias básicas de segurança.

Esta é a função do Move e porque acabámos por criar esta nova linguagem. Estas tarefas são fundamentais para a programação de contratos inteligentes. Elas são difíceis de recriar em outras linguagens, incluindo as linguagens de contratos inteligentes existentes, e queremos desenhar toda a linguagem em torno da oferta destas funcionalidades básicas, de modo que os programadores possam escrever código de forma segura e eficiente, sem ter que reinventar a roda cada vez que desejam escrever algum código.

Q3, Sui utilizou uma variante do Move, chamada Sui Move. O que motivou essas mudanças? Quais características do Sui Move são particularmente adequadas para construir produtos no Web3?

Vários fatores impulsionaram essas mudanças, um dos quais é que o objetivo inicial do projeto Libra era construir uma rede de pagamentos em conformidade. Assim, tentamos projetar o Move como uma linguagem universal. Mas também fizemos algumas coisas de forma consciente, porque a Libra queria ter restrições. Uma das coisas importantes é que eles não queriam que as pessoas pudessem enviar certos ativos para qualquer lugar. Eles queriam que as pessoas criassem explicitamente uma conta e, ao criar a conta, definissem algumas regras, como o proprietário da conta ter que passar pela certificação KYC. Ou pode ser necessário pagar uma taxa para criar a conta, ou apenas um pequeno grupo de pessoas com permissão para criar contas poderia fazê-lo. Como o objetivo geral é que a Libra deseje realizar pagamentos em conformidade e contratos inteligentes em conformidade, existem essas restrições. Mas no campo mais genérico do Web3, a situação é exatamente o oposto. Você não deseja que a conformidade ocorra no nível fundamental, esse é o conceito de contratos inteligentes. Você deseja que as coisas sejam o mais livres possível, podendo enviar algo para qualquer endereço. Então, você não deveria criar contas explicitamente, pois isso bloquearia vários casos de uso. Este é um fator importante.

Outro fator é que, embora tenhamos nos concentrado em ativos no Move, na época não consideramos como trazer o foco dos ativos para a própria transação no Libra. Portanto, quando você chega ao nível de transação, você ainda tem apenas essa API, na qual você insere números e valores booleanos, coisas que não são ativos, e então no Move, você usa esses números para extrair ativos da conta e realizar outras operações. Acontece que a maior parte do código que você executa é esse trabalho de livro-razão chato, que inclui retirar essa coisa, retirar aquela coisa, retirar outras coisas, certo, eu tenho todos os ativos que quero. Eles estão aqui, no meu estúdio, agora posso começar a fazer algo significativo. Então, no final desse processo, você pode dizer: "Ok, coloque esses ativos de volta nesta conta, coloque-os de volta naquela conta, reorganize-os."

No Sui, pensamos cuidadosamente se poderíamos abstrair isso se cada programa começasse e terminasse dessa maneira. Assim, a lógica usada para processar transações permitirá que os programadores façam isso; do ponto de vista dos programadores, eles só precisam ter os ativos necessários prontos e podem imediatamente começar a fazer o trabalho interessante. Este é o modelo de dados orientado a objetos que existe no Sui. No Move original, temos um modelo de dados baseado em contas, onde os ativos estão armazenados sob contas, e os programadores devem extraí-los explicitamente. Já no Sui, quando entram na parte Move da transação, os ativos já foram adquiridos pelo runtime do Sui. Isso é mais conveniente para os programadores, pois eles não precisam fazer todo esse trabalho de contabilidade antes e depois, e também é a arma secreta que nos permite determinar se uma transação pode ser executada em paralelo com outra, escalar horizontalmente o Sui e realizar outras operações de forma mais eficiente, sem realmente executar.

Nós também realizamos outros trabalhos muito interessantes, como a utilização de modelos de dados baseados em objetos para blocos de transação programáveis. Este é um tema mais técnico, e eu ficaria feliz em discutir mais a fundo. Mas estes dois fatores são os principais motores que levam à divergência em relação ao Move original.

Q4, pode por favor partilhar mais informações sobre blocos de transação programáveis e suas funcionalidades?

Gosto de usar uma analogia para explicar: outras blockchains são como a praça de alimentação de um centro comercial. Se você quer comer um gelado, vai ao quiosque de gelados e usa o seu cartão de crédito para pagar. Mas se decidir que também quer um hambúrguer, vai ao quiosque de hambúrgueres e paga novamente. Não sou uma pessoa gulosa, mas se eu quiser comer oito coisas, tenho que fazer oito transações separadas. Já o Sui é mais como um buffet livre, onde cada transação não é apenas uma coisa. Assim que paga a taxa do buffet, você pode fazer muitas coisas sem custos adicionais. Pode comer gelado, pode comer hambúrguer, pode misturá-los.

Para tornar este conceito mais concreto, em uma situação simples, se você quiser enviar 100 transações para cunhar 100 NFTs, você pode enviar uma transação que cunhe 100 NFTs. O custo é quase o mesmo que o de cunhar um NFT. Você também pode fazer pacotes de transações heterogêneas, por exemplo, a primeira transação no bloco retira um personagem Mario da sua carteira multi-assinatura, enquanto a segunda transação solicita um Mario e permite que você jogue. Se você ganhar o jogo e ganhar um troféu, talvez a terceira transação coloque o troféu em uma vitrine compartilhada com amigos. O legal é que os blocos de transação programáveis permitem que os programadores escrevam código dessa forma, onde o jogo não precisa saber como a carteira multi-assinatura ou o Mario são armazenados, nem precisa saber sobre sua vitrine ou como ela é implementada.

Os blocos de transação programáveis são compostos por transações que têm objetos de entrada e saída. Se você precisar de um objeto de entrada, pode obtê-lo sem se preocupar de onde ele vem, e então passar sua saída para o objeto que precisa dele, também sem se preocupar para onde será passado. Em outras blockchains, a acoplabilidade é mais forte, portanto, os jogos devem ser integrados com carteiras multisig e vitrines de troféus, ou todos devem implementar algumas interfaces comuns e ter um acoplamento mais forte. O Sui torna mais fácil o que se chama de combinações temporárias. Assim, se os tubos se encaixarem, podemos concluir em uma única transação.

Q5, quais são os benefícios dos blocos de transação programáveis para os usuários?

Para os usuários, os benefícios de um bloco de transação programável incluem custos de gas mais baixos, pois você pode agrupar todas as operações em uma única transação, em vez de realizar transações separadas. Além disso, o número de aprovações necessárias também será reduzido. Se o sistema que você está usando exigir aprovações de transação, você só precisará fazer uma aprovação, e então isso concluirá todas as operações de uma vez. Outro benefício é a atomicidade; se você quiser fazer três coisas diferentes e deseja que a terceira operação só seja bem-sucedida se as duas primeiras forem bem-sucedidas, se essas operações tiverem que ser transações independentes, você não conseguirá realizar isso. No entanto, se você puder colocá-las todas em uma única transação, poderá facilmente alcançar isso.

Q6, eu ouvi você e outras pessoas falarem que desenvolver na Sui é uma experiência incrível para os programadores, e isso é importante. Você tem alguma anedota para compartilhar sobre programadores Web3 experientes e novos começando a usar Sui Move?

Para os desenvolvedores que vêm de outras linguagens de programação Web3, a experiência de desenvolvimento em Move e Sui Move é realmente mais eficiente e segura. Acabei de participar de um podcast sobre o Bucket Protocol, onde eles estão construindo algo muito legal em Sui.