Pai da linguagem Move: a linguagem de contrato inteligente Sui Move é adequada para produtos Web3

Origem: Rede Sui

Recentemente, conversamos com Sam Blackshear, CTO da Mysten Labs e criador da linguagem de programação Move, sobre por que ele desenvolveu o Sui Move, uma nova linguagem de programação de contrato inteligente, os recursos que o Sui pode estender e o impacto da tecnologia descentralizada na construção do benefício do destinatário.

O seguinte é o conteúdo desta entrevista:

**P1. Primeiro, você pode dar uma visão geral do que é uma linguagem de programação, quais qualidades os desenvolvedores mais procuram ao escolher uma linguagem de programação e o que o leva a desenvolver sua própria linguagem de programação? **

Uma linguagem de programação é apenas uma ferramenta para interação amigável, segura, eficiente e clara com computadores, e isso é especialmente importante para computadores. Não podemos nos comunicar com computadores em linguagem natural, porque todo o significado da linguagem natural é ser rico e expressivo. Quando você usa um tom ligeiramente diferente ou escolhe maneiras sutilmente diferentes de expressar palavras, sua frase ou parágrafo pode significar algo completamente diferente.

**Em linguagens de programação, o mais importante é ter uma semântica definida com precisão. **Quando você escreve um programa, você sabe o que ele vai fazer. Se você fizer pequenos ajustes, saberá para onde essa mudança irá. Isso tem que ser mantido em vários níveis, como você pode escrever um código em uma linguagem de origem, tem um significado, e depois é traduzido em outras formas de representação, então também deve ter o mesmo significado, até chegar na máquina. o mesmo vale para os módulos de processamento.

**Acho que as linguagens de programação são de natureza específica de domínio ou tarefa específica, ao contrário das linguagens naturais. **Caso contrário, com apenas uma linguagem de programação, você pode fazer tudo. Mas a razão pela qual existem várias linguagens de programação é porque você não pode ser bom em todas as áreas. Eles estão tentando atingir domínios de problemas específicos e se concentrar em resolver esses problemas. Por exemplo, se você olhar para a linguagem de programação Rust que usamos para escrever o blockchain Sui e a maioria dos outros trabalhos de sistema que fazemos na Mysten, ela se concentra em escrever código que seja rápido e eficiente, mantendo a segurança. Ele fornece acesso a detalhes de baixo nível, como memória, estruturas de encadeamento ou simultaneidade, mas não permite que você cometa erros como linguagens anteriores, como C ou C++.

Então a história do Move é muito parecida com isso. Quando o criei, não foi para criar um novo idioma. Você mencionou anteriormente o que os desenvolvedores procuram em um idioma. Eles perguntam: "Esta linguagem é adequada para o que estou tentando realizar?" Mas acho que talvez mais importante, "*Esta linguagem tem uma grande comunidade? Existem muitos bancos de dados disponíveis? Muitos programadores usam? existem bons recursos educacionais? *" Esses são muito importantes, então a barreira para criar um novo idioma deve ser muito alta, mesmo que o idioma em si seja melhor, mas se não tiver esses fatores, sua vantagem não tem sentido. Construir uma comunidade grande e vibrante do zero é muito difícil.

**Q2、****Você pode compartilhar mais sobre o desenvolvimento do Move? **

**Movimento originado do projeto Libra do Facebook. **Minha tarefa na época não era criar uma nova linguagem, mas "Libra precisa ter contratos inteligentes, então descubra o que devemos fazer." Eu olhei para todos os tipos de coisas. Podemos usar o Solidity no EVM? Devemos pegar uma linguagem regular de uso geral, como WASM ou JVM, e usá-la para Libra? Ou devemos criar o nosso próprio?

A decisão de criar algo próprio foi baseada em pesquisar contratos inteligentes existentes, entender o que os programadores estavam tentando fazer e onde certas linguagens os ajudavam e onde os deixavam na mão. Minha conclusão é que, em muitos casos, as linguagens de contratos inteligentes existentes os decepcionam.

Isso fica claro pelo histórico de segurança ruim do Solidity, mas, mais fundamentalmente, esses contratos inteligentes não são tipos de programas muito tradicionais. Solidity não é uma linguagem construída para o que as pessoas fazem agora. Não estou criticando porque é a primeira linguagem de contrato inteligente que ainda não sabe o que as pessoas querem fazer com ela. Depois de ver o que as pessoas estão tentando fazer com isso, acho que fica claro que você precisa de um conjunto diferente de abstrações e ferramentas de programação que a linguagem Solidity não oferece.

Portanto, esses contratos inteligentes são muito simples, eles basicamente fazem duas coisas. Eles definem os tipos de ativos, incluindo regras para quando os ativos podem ser transferidos, o que você pode fazer com eles, quem pode lê-los e quem pode escrever para eles**. **** E verifique a política de controle de acesso para determinar quem é o proprietário do ativo, quem tem permissão para usá-lo e quem tem permissão para operar nele. **Tudo gira em torno de ativos e você deseja que esses ativos tenham os mesmos atributos dos ativos físicos. Se eu entregar algo para você, então você deve ficar com isso e eu não terei mais.

**Em contratos inteligentes existe o conceito de propriedade e transferência de propriedade, mas em um computador tudo são apenas bits e bytes e podem ser copiados livremente. **E, você sabe, esses conceitos não existem no mundo real. Então você quer uma linguagem que lhe dê boas abstrações sobre propriedade e homogeneização. Assim como no mundo real, mas sem forçar os programadores a reinventá-lo. Você quer garantias básicas de segurança.

É isso que o Move faz e por que acabamos criando essa nova linguagem. Essas tarefas são fundamentais para a programação de contratos inteligentes. Eles são difíceis de recriar em outras linguagens, incluindo linguagens de contrato inteligente existentes, e queremos projetar toda a linguagem em torno do fornecimento dessas funções básicas para que os programadores possam escrever código com segurança e eficiência sem ter que escrever algum código toda vez que quiserem. a roda.

**Q3、****Sui usa uma variante de Move chamada Sui Move. O que motivou essas mudanças? Quais recursos do Sui Move são ideais para a construção de produtos em Web3? **

Vários fatores impulsionaram essas mudanças, um dos quais era o objetivo do projeto Libra original de construir uma rede de pagamentos compatível. Então, tentamos projetar o Move (como uma linguagem de propósito geral. Mas também fizemos algumas coisas conscientemente, porque Libra quer ter restrições. Uma das coisas importantes é que eles não querem que as pessoas possam enviar certos ativos para qualquer lugar. Eles querem que as pessoas criem explicitamente uma conta e definam algumas regras quando a conta for criada, como o proprietário da conta deve passar pela verificação KYC. Ou pode haver uma taxa para criar a conta, ou só pode ser criado por uma pessoa pequena com permissão para criar uma conta Algumas pessoas criam contas. Como todo o propósito do Libra é fazer pagamentos compatíveis e contratos inteligentes compatíveis, existem essas limitações. Mas no mundo Web3 mais geral, é o oposto. Você não quer ser compatível no nível básico, este é o conceito de contratos inteligentes. Você quer que as coisas sejam o mais livres possível, é perfeitamente possível enviar algo para qualquer endereço. Então você não deve ter criação de conta explícita porque isso bloqueará vários casos de uso. Esse é um fator importante.

Outro fator é que enquanto a gente focava em ativos em Move, na época em Libra não pensávamos em como trazer o foco de ativos para a transação em si. Então, quando você chega ao nível da transação, você ainda tem essa API, onde você insere números e booleanos e coisas que não são ativos e, em seguida, no Move, você usa esses números para retirar ativos de contas e fazer outras coisas. Acontece que a maior parte do código que você executa é essa contabilidade desagradável de retirar isso, retirar aquilo, retirar outra coisa e, ok, tenho todos os ativos que desejo. Aqui estão eles, no meu estúdio, e agora posso começar a fazer algo significativo. E então, no final do processo, você pode dizer: "OK, coloque esses ativos de volta nesta conta, coloque-os de volta nessa conta, reorganize-os.

Em Sui, pensamos, se todo programa começa e termina dessa maneira, podemos abstrair isso? Assim, a lógica para processar a transação fará isso para o programador e, do ponto de vista do programador, eles apenas têm os ativos de que precisam prontos e começam a fazer o trabalho interessante imediatamente. Este é o **** modelo de dados centrado no objeto que existe no Sui. **No Move original, tínhamos um modelo de dados baseado em conta, os ativos eram armazenados em contas e os programadores tinham que extraí-los explicitamente. No Sui, quando eles entram na parte Move da transação, os ativos já foram adquiridos pelo tempo de execução do Sui. Isso é mais conveniente para os programadores porque eles não precisam fazer tudo isso antes e depois da contabilidade e também nos permite determinar se podemos executar uma transação em paralelo com outra sem realmente executá-la. algumas outras coisas de forma mais eficiente.

Também fizemos outros trabalhos realmente interessantes, como alavancar um modelo de dados baseado em objeto para blocos de transação programáveis. Este é um tópico um tanto técnico que estou feliz em discutir em profundidade. Mas esses dois fatores foram os principais impulsionadores da divergência do Move original.

**Q4、****Você pode compartilhar mais informações sobre os blocos de transação programáveis e suas funções? **

Gosto de usar uma analogia para explicar que outras blockchains são como uma praça de alimentação em um shopping. Você quer um sorvete, vai até a sorveteria, pega o cartão de crédito e paga. Mas se você decidir que ainda quer um hambúrguer, vá até a lanchonete e pague novamente. Não sou glutão, mas se quisesse comer oito coisas, teria que fazer oito transações separadas. **Onde Sui é mais um buffet, cada negócio é mais do que apenas uma coisa. Depois de pagar pelo buffet, há muito o que fazer sem nenhum custo extra. **Você pode tomar sorvete, pode comer hambúrgueres, pode misturar tudo.

Para tornar esse conceito um pouco mais concreto, no caso simples, se você está enviando 100 transações para cunhar 100 NFTs, você pode enviar uma transação que cunha 100 NFTs. Esse custo é quase o mesmo que o custo de cunhagem de um NFT. Você também pode fazer pacotes de transações heterogêneas, de modo que a primeira transação em um bloco pegue um personagem Mario de sua carteira multisig e a segunda transação solicite um Mario, que permite que você jogue o jogo. Se você ganhar o jogo e conseguir o troféu, talvez uma terceira troca coloque o troféu em um armário de troféus que você compartilha com os amigos. **O que é legal é que os blocos de transação programáveis permitem que os programadores escrevam código de forma que o jogo não precise saber sobre carteiras multisig ou como o Mario é armazenado, nem sobre seu armário de troféus ou como ele é implementado . **

**Os blocos de transação programáveis consistem em transações com objetos de entrada e saída. **Se você precisa de um objeto de entrada, você pode obter esse objeto sem se importar de onde ele veio e passar sua saída para o objeto que precisa dele e também não se importar para onde ele é passado. Em outras blockchains, o acoplamento é mais forte, então os jogos precisam se integrar com carteiras multisig e armários de troféus, ou todos precisam implementar alguma interface comum e ter um acoplamento mais forte. **Sui torna as chamadas combinações ad-hoc muito mais fáceis. **Tipo, se os pipes combinarem, podemos fazer isso em uma transação.

**P5、****Quais são os benefícios dos blocos de transação programáveis para os usuários? **

Para os usuários, os benefícios dos blocos de transação programáveis incluem custos de gás mais baixos, porque você pode agrupar todas as operações em uma transação em vez de fazer transações separadas. Além disso, requer menos aprovações. Se você estiver usando um sistema que requer aprovação de transação, você só precisa fazer isso uma vez e, em seguida, faz tudo de uma vez. Outro benefício é a atomicidade, se você deseja fazer três coisas diferentes e deseja que a terceira operação seja bem-sucedida apenas se as duas primeiras operações forem bem-sucedidas, se essas operações tiverem que ser transações independentes, você não poderá fazer isso acontecer. No entanto, se você puder colocá-los todos em uma transação, poderá conseguir isso facilmente.

**P6, ****Ouvi você e outros falarem sobre desenvolver no Sui como uma ótima experiência para programadores e é importante. Você tem alguma anedota para compartilhar com os programadores Web3 experientes e novos que estão começando com o Sui Move? **

Para aqueles desenvolvedores vindos de outras linguagens de programação Web3, sua experiência de desenvolvimento em Move e Sui Move é realmente mais eficiente e segura. Eu estava em um podcast sobre Bucket Protocol e eles estão construindo um projeto DeFi muito legal no Sui. À medida que demonstram a arquitetura do sistema, eles descrevem como os diferentes componentes funcionam juntos. Eles disseram que se tivessem escrito este projeto no Solidity, poderia ter levado oito meses, mas com o Sui Move levou apenas dois meses, e eles estão muito confiantes em sua segurança. A forma como a linguagem funciona é muito próxima da ideia de um portfólio de projetos na cabeça. No mundo Solidity, a conexão é menos direta.

Este é apenas um exemplo, mas ouvimos muitos casos semelhantes em que as pessoas dizem que desenvolvem mais rápido o idioma e se sentem mais confiantes quando terminam. Fico feliz em ouvir isso. Mas, de certa forma, isso não é surpreendente, analisamos o Solidity e aprendemos sobre os problemas. Criamos explicitamente cenários sobre como torná-lo mais seguro e rápido. Vimos o que os desenvolvedores da linguagem estavam tentando fazer e como projetar a linguagem para atender às suas necessidades, em vez de atender ao que já existia. O idioma é projetado para os problemas que as pessoas têm, então, quando eles mudam, eles realmente apreciam o idioma.

**Eles dizem que a vantagem do pioneirismo é importante, mas acho que, neste caso, é a vantagem do pioneirismo que importa mais. **

Isso mesmo, é isso.

**Q7、****Você tocou nisso quando mencionou o Sui Move e os recursos gerais orientados a objetos do Sui. Mas você pode articular mais claramente a conexão entre o design do Sui Move e a capacidade do Sui de obter adoção em massa do Web3, baixa latência, baixo custo e escalabilidade? **

Uma das coisas com as quais estamos muito preocupados em contribuir com o Sui, e o problema que outras plataformas enfrentam, é que se você tiver capacidade limitada, seja como 15 transações por segundo (TPS) como Ethereum ou 100 ou 1.000 transações, se for um número fixo, então, quando a plataforma se tornar muito bem-sucedida, atingirá o limite superior de capacidade. Nesse ponto, a experiência de todos que usam a plataforma é degradada. Se houver apenas 1.000 vagas, você deve escolher as 1.000 mais importantes, que podem ser selecionadas por meio de licitação de gás ou outros métodos. Para todos, os preços do gás aumentarão, a latência aumentará ou ambos. Muitos casos de uso foram excluídos, pois apenas aqueles capazes de pagar as taxas mais altas teriam sucesso, enquanto outros teriam que procurar outro lugar ou esperar mais. Esta não é uma boa situação.

**Sui tem como alvo a escalabilidade horizontal. **Uma certa quantidade de taxa de transferência pode ser alcançada se uma certa quantidade de hardware for alocada. Se for necessário mais rendimento, o validador pode introduzir mais recursos de hardware, sem limite superior. É assim que todo serviço Web2 funciona. Quero dizer, existem algumas restrições de engenharia que você precisa contornar, não é uma coisa fácil ou certa de fazer, mas todo mundo quer alcançar escalabilidade horizontal ao projetar serviços da Web escaláveis.

Se a Sui tiver mais clientes ou usuários, nosso objetivo é que a Sui continue crescendo e tudo deve funcionar. Claro, mantendo uma latência muito baixa. Você não quer sacrificar a latência enquanto aumenta a taxa de transferência.

No sistema Libra, essas características não são consideradas. É apenas um sistema de pagamento de pequena escala, com centenas de operadores de pagamento, e pode haver dezenas de milhões de pagamentos por dia, mas não mais. Por isso, adotamos uma arquitetura de caixa única, mais simples e suficiente. Mas no Sui, sabemos que o sistema Libra não funcionará porque não possui o recurso de escalabilidade horizontal. Então pensamos, como podemos projetar um sistema do zero que possa fazer isso. É aqui que entra o modelo de dados orientado a objetos. Basicamente, abandonamos o antigo modelo de dados baseado em contas porque tornava muito difícil atingir a escalabilidade horizontal. Em vez disso, se você organizar tudo em objetos, o estado global será apenas um grande mapa de IDs de objeto para objetos. É um armazenamento de valor-chave e sabemos como dimensionar armazenamentos de valor-chave, é um problema simples de engenharia.

A questão então se torna: como projetamos uma estrutura de transação que acomode a busca e atualização de dados do armazenamento de valor-chave? Como fragmentamos um armazenamento de chave-valor? Como decidimos onde as transações devem ser processadas? É basicamente daí que vem. Dito isso, sabemos como escalar essas coisas. Como transformamos isso em algo que possui propriedades de blockchain, leituras verificáveis, funciona com Move, etc. E então como juntá-los da maneira mais suave possível.

Q8、** Em um nível mais alto, como você discute o potencial da tecnologia descentralizada com desenvolvedores que são céticos em Web2? **

**Acho que blockchain e criptomoedas são fundamentalmente uma tecnologia que remove o atrito. **Existem barreiras que dificultam muito a realização de transações financeiras, criação de aplicativos ou configuração de informações porque as informações não podem cruzar essas barreiras ou, se cruzarem essas barreiras, exigirão a ajuda de terceiros e estes primeiro O terceiro cobra uma taxa para poder prestar assistência.

Um exemplo clássico que as pessoas gostam de usar é comprar uma casa. Há um comprador e um vendedor, mas quando você realmente faz os pagamentos, deve haver um agente fiduciário que não faça nada além de sentar e depositar os fundos porque o comprador e o vendedor não confiam totalmente um no outro. Isso é um fato da vida. Nós vamos lidar com isso. No entanto, se o agente de custódia puder ser um código visível para ambas as partes ou verificado por terceiros, ele poderá fazer o trabalho de graça ou por muito menos. O objetivo do blockchain não é eliminar os agentes de custódia no setor imobiliário. Este é apenas um dos casos de uso, mas geralmente é o caso.

**Se não houver mais barreira de interoperabilidade entre o aplicativo A e o aplicativo B, mas construído na mesma plataforma subjacente, para que você possa fazer as coisas fluírem de um aplicativo para outro, sejam itens no aplicativo, dados, promoções ou terceiros -Party produtos construídos em cima de ambos. ** Ou imagine a internet, onde os sites compartilham dados uns com os outros por meio de cookies, mas esses cookies são apenas metadados somente leitura. E se esses cookies pudessem se tornar moeda? Ou poderia ser um item descartável? Ou poderiam ser programas de fidelidade e cupons? Tudo tem essa funcionalidade incorporada. É muito abstrato, mas é aí que reside o potencial. Normalmente, uma pessoa que está construindo pensará nisso como novos superpoderes que pode usar para construir algo mais atraente.

P9、** Para os usuários finais, mesmo que não tenham conhecimento técnico, você sente hesitação quando eles consideram o código confiável, mesmo que a outra opção seja uma grande entidade central opaca? **

Eu não penso assim. Porque fazemos coisas assim todos os dias, certo? Quando eu faço login no meu e-mail, não estou preocupado que o código exclua um dos meus e-mails ou que, quando eu enviar um e-mail, ele não o envie. Se isso acontecer, provavelmente vou parar de usar e-mail ou usar outro provedor. Eu acho que é muito parecido, claro que nem todo mundo pode realmente ler algo e verificar como funciona.

E, você sabe, se eu quiser verificar o código do e-mail, não posso porque o código não está lá. Portanto, a transparência é um aspecto importante disso. Embora nem todos sejam capazes de fazer isso, alguns podem experimentá-lo. E combine isso com a reutilização de qualquer coisa, além da imutabilidade. Essa é a chave aqui. Quando entro no meu e-mail, não sei se o código mudou desde a última vez que fiz algo. Não há transparência sobre isso. Mesmo sabendo dessas informações, você pode obtê-las na Web3 e não em outro lugar.

**Q10、****Quais são suas expectativas para o desenvolvimento futuro do Sui Move? **

** Muitos dos recursos nos quais estamos focando atualmente são baseados em nossa experiência com desenvolvedores que lançaram seus lotes iniciais de pacotes Sui Move e, em seguida, analisaram como eles queriam evoluir esses recursos, quais eram fáceis de desenvolver e quais os outros eram mais difíceis. **Sui Move é uma ótima linguagem para um primeiro pacote de lançamento, mas para o tipo que vou mudar, vou adicionar alguns campos, vou adicionar algumas funções, vou fazer isso de uma forma que seja coesa, mas não vá contra o uso do pacote inicial Para operar de uma forma que os usuários confiem, isso se torna um problema muito desafiador. Muito do que fazemos é olhar para isso e determinar quais recursos de nível de linguagem podemos adicionar para dar aos programadores a flexibilidade de estender, mantendo a confiança dos usuários do código original.

**Estamos trabalhando em muitos recursos relacionados a isso, especialmente tipos de enumeração. **Também estamos trabalhando muito para melhorar a experiência de conectar o Move com o código front-end. Costumamos brincar que um aplicativo Sui típico é 5% código Move e 95% código front-end. Portanto, estamos muito focados nesses 95%. Passamos muito tempo conversando sobre o Move, mas também focamos muito em tornar outras partes mais eficientes e facilitar as conexões. Em geral, estamos muito focados em como fazer o aplicativo consistir mais em Move para obter mais segurança. Ao mesmo tempo, como tornamos esses 95% do código compreensíveis para programadores Move e não programadores Move.