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

Recentemente, conversamos com Sam Blackshear, o Chief Technology Officer da Mysten Labs e criador da linguagem de programação Move, sobre por que ele desenvolveu Sui Move, uma nova linguagem de programação para contratos inteligentes, as funcionalidades expansíveis do Sui e os benefícios da tecnologia descentralizada para os construtores.

Segue o conteúdo desta 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 motivou a desenvolver sua própria linguagem de programação?

A linguagem de programação é apenas uma ferramenta para interagir de forma amigável, segura, eficiente e clara com os computadores, o que é especialmente importante para eles. Não podemos nos comunicar com computadores usando a linguagem natural, pois o significado da linguagem natural é cheio de riqueza e capacidade de expressão. Quando você usa um tom ligeiramente diferente ou escolhe uma forma sutilmente diferente de expressar palavras, o significado da sua frase ou parágrafo pode mudar completamente.

E nas linguagens de programação, o mais importante é ter uma semântica definida com precisão. Quando você escreve um programa, você sabe exatamente o que ele fará. Se você fizer pequenos ajustes, você sabe quais serão os resultados dessa mudança. Isso deve ser mantido em vários níveis, por exemplo, você pode escrever código em uma linguagem fonte que tem um significado e depois ser convertido para outra forma de representação, e esse significado deve ser o mesmo, até mesmo quando chega ao módulo de processamento da máquina.

Eu acredito 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 realizar todas as tarefas. Mas a razão para a existência de 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 direcionar a problemas específicos e focar na resolução desses problemas. Por exemplo, se você olhar para a linguagem de programação Rust, que usamos para escrever a blockchain Sui e a maioria dos outros sistemas no Mysten, ela se concentra em escrever código que seja rápido e de alto desempenho, enquanto garante segurança. Ela permite que você tenha acesso a detalhes de baixo nível, como memória, estrutura de threads ou concorrência, mas não o deixa cometer erros como nas linguagens anteriores (como C ou C++).

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

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

Move originou-se no projeto Libra do Facebook. Minha tarefa na época não era criar uma nova linguagem, mas sim "o Libra precisa de contratos inteligentes, então descubra o que devemos fazer". Eu examinei uma variedade de coisas. Podemos usar Solidity no EVM? Devemos usar uma linguagem geral comum, como WASM ou JVM, e aplicá-la ao Libra? Ou devemos criar algo próprio?

A decisão de criar algo próprio baseia-se na pesquisa sobre os contratos inteligentes existentes, na compreensão do que os programadores estão tentando fazer e nos pontos em que certas linguagens os ajudam e os decepcionam. A minha conclusão é que, em muitos casos, as linguagens de contratos inteligentes existentes realmente os decepcionam.

Isso pode ser claramente visto a partir do histórico de segurança ruim do Solidity, mas mais fundamentalmente, esses contratos inteligentes não são exatamente o tipo de programa tradicional. Solidity não é uma linguagem construída para as coisas que as pessoas estão fazendo agora. Não estou tentando criticá-la, pois foi a primeira linguagem de contratos inteligentes, e ela ainda não sabia o que as pessoas queriam fazer com ela. Uma vez que você vê o que as pessoas estão tentando fazer com ela, 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 eles, quem pode lê-los e as regras sobre quem pode escrevê-los. 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ê deseja que esses ativos tenham as mesmas propriedades que os ativos físicos. Se eu lhe entregar algo, então você deve possuí-lo, eu não o possuo mais.

Nos contratos inteligentes, há 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 ter uma linguagem que possa fornecer uma boa abstração sobre propriedade e homogeneização. Como no mundo real, mas sem forçar os programadores a reinventa-lo. Você deseja obter garantias básicas de segurança.

Esta é a função do Move e porque é que acabamos 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 projetar toda a linguagem em torno da oferta dessas funcionalidades básicas, para que os programadores possam escrever código de forma segura e eficiente, sem ter que reinventar a roda sempre que queiram escrever algum código.

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

Vários fatores impulsionaram essas mudanças, sendo que um deles é 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, de forma consciente, fizemos algumas coisas, pois 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 uma conta de forma explícita e estabelecessem algumas regras no momento da criação da conta, como a exigência de que o proprietário da conta passasse pela certificação KYC. Ou talvez fosse 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 era que a Libra desejava realizar pagamentos em conformidade e contratos inteligentes em conformidade, essas restrições existem. Mas, no campo mais geral do Web3, é exatamente o contrário. Você não quer que haja conformidade na camada base, esse é o conceito de contratos inteligentes. Você quer que as coisas sejam tão livres quanto possível, completamente capazes de enviar algo para qualquer endereço. E então você não deveria criar contas de forma explícita, pois isso bloquearia vários casos de uso. Este é um fator importante.

Outro fator é que, embora tenhamos nos concentrado nos ativos no Move, na época não consideramos como trazer o foco dos ativos para as transações em si no Libra. Portanto, quando você chega ao nível da transação, você ainda tem apenas essa API, onde você insere números e valores booleanos, 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 contabilidade cansativo, que envolve retirar essa coisa, retirar aquela coisa, retirar outra coisa, ok, eu tenho todos os ativos que quero. Eles estão aqui, no meu estúdio, agora eu 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 o fato de que cada programa começa e termina dessa maneira. Assim, a lógica para lidar com transações será feita pelo programador; do ponto de vista do programador, ele só precisa preparar os ativos necessários e começar imediatamente a realizar um 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 são armazenados sob a conta e o programador deve extraí-los explicitamente. No Sui, ao entrar na parte Move da transação, os ativos já foram adquiridos pelo runtime do Sui. Isso é mais conveniente para o programador, pois ele não precisa fazer todo esse trabalho de contabilidade antes e depois, e também é a arma secreta que nos permite determinar, sem realmente executar, se uma transação pode ser executada em paralelo com outra, escalar horizontalmente o Sui e realizar outras operações de forma mais eficiente.

Fizemos também alguns trabalhos muito interessantes, como a utilização de modelos de dados baseados em objetos para blocos de transação programáveis. Este é um tópico mais técnico, e estou mais do que disposto a discutir em profundidade. Mas estes dois fatores são os principais motores que levam à divergência em relação ao Move original.

Q4, você poderia compartilhar 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 você decidir que também quer comer um hambúrguer, então 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. E o Sui é mais como um buffet, onde cada transação não é apenas uma coisa. Assim que você paga a taxa do buffet, pode fazer muitas coisas sem custos adicionais. Você 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 dessa transação é praticamente o mesmo que o custo de cunhar um NFT. Você também pode realizar uma empacotamento de transações heterogêneas, como a primeira transação no bloco retirando um personagem Mario de sua carteira multi-assinatura, enquanto a segunda transação solicita um Mario e permite que você jogue. Se você ganhar o jogo e receber 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ções programáveis permitem que os programadores escrevam código dessa maneira, 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 com objetos de entrada e saída. Se você precisa 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, da mesma forma, sem se preocupar para onde será passada. Em outras blockchains, o acoplamento é mais forte, portanto, os jogos devem ser integrados com carteiras multi-assinaturas e vitrines de troféus, ou todos devem implementar algumas interfaces comuns e ter um acoplamento mais forte. O Sui torna mais fácil a chamada combinação temporária. Assim, se os tubos corresponderem, podemos concluir em uma única transação.

Q5, quais são os benefícios de um bloco de transação programável para os usuários?

Para os usuários, os benefícios dos blocos de transação programáveis incluem taxas de gas mais baixas, 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ção de transação, você só precisará fazer uma única aprovação, e então ela será concluída de uma vez para todas as operações. 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 agrupá-las em uma única transação, poderá facilmente conseguir isso.

Q6, eu ouvi você e outros falarem que desenvolver na Sui é uma experiência incrível para programadores, e isso é importante. Você tem alguma anedota para compartilhar sobre a experiência de programadores Web3 experientes e novos ao começarem 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, que está a construir um não em Sui.