Um artigo de opinião de Josh Primero, arquiteto-chefe de protocolo da RDX Works.  Depois de lançar o Radix Engine V2 na rede Babylon, observei mais de perto a nova onda de VMs que estão surgindo no cenário DeFi. Um dos mais atraentes é o MoveVM de Sui, uma melhoria em relação ao MoveVM original de Diem.  Já faz algum tempo que estou entusiasmado com a arquitetura do Sui, já que ele compartilha algumas filosofias técnicas importantes com o Radix:  Uso de semântica de movimento para permitir programação orientada a ativos.  Aproveite o conhecimento das dependências do estado para dimensionar o consenso por meio de ordenação parcial (em vez de abstrair demais e mover a escalabilidade para uma camada superior, a moda do dia)  Tecnicamente falando, achei muito legal como eles utilizaram uma linguagem e um código de bytes compilado que captura estaticamente as dependências de estado mínimas necessárias para executar alguma lógica.  Isto não só resulta em execução rápida, mas também proporciona benefícios de segurança, uma vez que as dependências de estado e as gravações de estado de uma transação são bem limitadas.  Essa conquista tem um custo. Os programadores DeFi devem gerenciar um modelo mais difícil e, às vezes, pouco intuitivo, repetindo até mesmo problemas bem conhecidos do EVM.  Vejamos agora esses problemas no que descobri serem quatro falhas na VM de Sui.  1. Objeto primitivo que é muito genérico  A maior inovação do MoveVM da Sui (ou MoveVM em geral) é o uso da semântica de movimentação/empréstimo na camada de bytecode. Isso significa que sua máquina de baixo nível pode compreender a propriedade e o movimento de objetos; bem legal!  Cada objeto na VM do Sui, portanto  , um valor digitado com lógica associada que pode ser de propriedade, movido e compartilhado.    age como um NFT  Infelizmente, como um objeto pode fazer muito mais coisas genéricas neste modelo, o programador DeFi fica sobrecarregado com a definição e o gerenciamento de uma máquina complexa de estados de vida útil do objeto.   Especificamente, em Sui, ao definir uma nova estrutura, um programador deve especificar uma combinação de 4 habilidades (“copiar”, “descartar”, “chave” e “armazenar”), cada uma das quais afeta a máquina de estados de maneiras diferentes. Além disso, um programador deve gerenciar se na instanciação um objeto deve ser compartilhado, transferido, retornado como um valor ou congelado.  Ter a configuração errada em qualquer um deles pode causar bugs sutis que podem levar à perda de fundos.  Por exemplo, no código a seguir, usamos o comando Sui  para implementar um empréstimo rápido simples. O problema? Adicionamos acidentalmente a capacidade de drop ao Recebimento.    Padrão de batata quente  Este pequeno erro permite que o mutuário fuja com o empréstimo sem nunca pagá-lo, desistindo ele mesmo do recibo. (Há outro bug no relacionamento FlashLoan e Receipt, veja se você consegue encontrá-lo!)  Portanto, embora seja conceitualmente elegante e simples organizar uma VM em torno de uma única abstração de objeto com um conjunto de habilidades, do ponto de vista de um programador, é difícil entender as repercussões de cada uma porque há muito estado de baixo nível para gerenciar.  Isso não é muito diferente dos problemas de gerenciamento de memória de linguagens mais antigas e do motivo pelo qual as VMs de coleta de lixo tiveram tanto sucesso. Os programadores de aplicativos não se preocupam em gerenciar estados de baixo nível, como quando a memória pode ser liberada; eles se preocupam com os objetos e com as relações entre esses objetos.  Na mesma linha, os programadores DeFi preocupam-se fundamentalmente com os ativos e com a lógica em torno da movimentação e propriedade desses ativos. Os ativos por si só não têm lógica inerente, e a lógica que gerencia esses ativos não precisa ser “movida” nem ser “possuída”.  O MoveVM de Sui combina essas duas coisas muito diferentes como uma abstração genérica de objeto que torna um modelo mental de programação DeFi difícil.  2. Sem envio dinâmico  Um recurso definidor do MoveVM é o uso de despacho estático, o que significa que não há nenhuma camada de indireção entre uma chamada de função e sua execução durante o tempo de execução. As chamadas de função e sua lógica subjacente são vinculadas estaticamente no momento em que um novo pacote é publicado. Isso permite que a VM seja rápida e previsível, mas às custas de menos flexibilidade e de um ambiente de programação mais difícil de usar.  Vejamos três repercussões da falta de despacho dinâmico.  2a) Sem composição funcional  Como a VM deve saber a função exata a ser chamada no momento da publicação do código, é impossível compor funções diferentes juntas; um padrão muito comum na programação regular (por exemplo, interfaces em linguagens OO ou características em Rust).  Vamos dar uma olhada em um incentivo simples do Liquidity Pool. Se eu escrevesse um incentivo que adicionasse 10% à sua contribuição no Rust, seria mais ou menos assim:   Dessa forma, meu LiquidityEnhancer funcionaria com qualquer pool que implemente a característica Pool (Sim, para vocês, críticos do Rust, essa característica também está vinculada estaticamente. Este é apenas um exemplo de composição de função).  Isso é impossível em Sui, pois “contribuir” deve ser uma função já definida. Em vez disso, um novo pacote vinculado às implementações exatas do pool teria que ser publicado para qualquer nova implementação do pool.  2b) Sem retornos de chamada dinâmicos ou ponteiros de função  Da mesma forma, ser capaz de executar lógica arbitrária por meio de alguma interface genérica é uma construção muito útil, especialmente no ambiente DeFi.  Imagine um futuro executor incentivado que incentiva um chamador no futuro a chamar alguma lógica arbitrária (por exemplo, para o uso de pagamentos atrasados). Em Rust, seria assim:   Isso, entretanto, não é possível no Sui devido à falta de despacho dinâmico. Em vez disso, um novo pacote IncentivizedFutureExecution teria que ser publicado para cada método que desejasse usar tal recurso.  2c) Capacidade de atualização estranha  Sui tem suporte para  . Infelizmente, devido à invariante de despacho estático, o gerenciamento de atualizações de pacotes é mais complicado e menos seguro do que seria esperado.   atualização e versionamento de pacotes  Primeiro, atualizações de código transparentes e contínuas não são possíveis. Se eu tiver um pacote que faz chamadas para outro pacote e o outro pacote tiver uma atualização de correção de bug necessária, eu mesmo devo publicar um novo pacote se quiser a correção.   Com cada vez mais dependências de pacotes, isso pode facilmente levar a uma explosão de atualização de pacotes, mesmo a partir de uma simples correção de bug de um pacote muito usado.   Em segundo lugar, todo código antigo sempre existirá (necessário, pois qualquer outro código dependente dele precisará ser capaz de chamá-lo), mesmo nos casos em que esse código possa conter bugs e/ou código malicioso. Para neutralizar isso, recai sobre a camada de aplicação a responsabilidade de manter um esquema de controle de versão sensato no estado de seus objetos.  3. Um padrão de caixa de correio estranho  Sui lançou recentemente um  que pode ser melhor descrito como uma forma de enviar um objeto para outro objeto sem que o outro objeto saiba (anteriormente, isso só era possível com Endereços). Para poder acessar esse objeto, uma transação separada com conhecimento desta transferência deve ser executada.    Padrão de transferência para objeto  Tal construção é útil para remover a dependência do estado do objeto receptor; não muito diferente de enviar UTXOs para outro endereço no modelo UTXO (a parte de recebimento também é semelhante a provar a propriedade por meio de scripts testemunha UTXO). O consenso de Sui consegue então aproveitar essa falta de contenção e paralelizar melhor tal transação.  No entanto, esse ganho de desempenho tem suas compensações de segurança. O fato de os objetos poderem ser recebidos sem informações sobre o objeto receptor (inclusive se ele existe ou não!) introduz a possibilidade de perder para sempre o acesso aos objetos enviados.  Isto é possível se o objeto receptor não suportar o objeto que está sendo enviado. Tal falha é semelhante ao envio errôneo de um token ERC-20 para um contrato inteligente que não oferece suporte a esse token (uma causa   comum de perda de fundos). muito  Além disso, o facto de existirem dois tipos de relações entre pais e filhos, um em que os pais sabem sobre os seus filhos e outro em que os filhos sabem sobre os seus pais, torna o modelo mais complicado do que o típico na programação tradicional.   Existe uma abordagem que retenha os benefícios de desempenho sem programar nesta estrutura estranha? Eu acredito que sim. Requer o uso de ponteiros imutáveis junto com outras abordagens CRDT, mas abordarei isso em um artigo futuro.  4. Programação de Estado Compartilhada Inábil  A VM da Sui é otimizada para programar e executar em um estado não contencioso. Isso levou a algumas mecânicas de programação um tanto estranhas quando realmente é necessário lidar com o estado compartilhado. Vamos dar uma olhada em alguns deles.  4a) Sem referências armazenadas  A VM do Sui não tem noção de referências armazenadas. Se houvesse, perderia a capacidade de analisar estaticamente as dependências de estado de uma função e, assim, perderia a capacidade de paralelizar. A consequência disso é que a responsabilidade de gerenciar as referências armazenadas agora recai sobre o programador/usuário.  Por exemplo, digamos que tenho um objeto que exige um preço de um Oracle específico em uma de suas funções. Em Rust, isso pode ser assim:   No Sui, como as referências não podem ser armazenadas, esta relação entre MyDefi e Oracle deve ser descrita de uma forma mais funcional:   Mas espere! Qualquer oráculo arbitrário pode agora ser transmitido. Para garantir que o oráculo correto seja usado, o  deve ser usado:    Padrão de ponteiro de ID  Este padrão, quando comparado às referências regulares, é mais frágil e deve-se tomar cuidado para implementar a relação correta. À medida que o gráfico de relacionamento entre objetos cresce e se torna mais complexo, é difícil imaginar que essa carga de programação seja escalonada muito bem (por exemplo, e se a chamada get_price do Oracle também tiver suas próprias dependências).  Além disso, sempre haverá um ônus para o chamador, seja um código de transação ou de pacote, para passar a referência correta. Se esta referência puder mudar, isso representará ainda outro fardo adicional para o chamador, para garantir que a referência foi atualizada para o estado mais recente.  4b) Segurança do tipo não dinâmico para instâncias relacionadas  Ao contrário da programação tradicional, na programação DeFi é muito útil poder verificar se uma instância faz parte do mesmo “grupo de instâncias” que outra instância.  Por exemplo, seria bom verificar se a união de duas moedas tem o mesmo identificador de moeda:   O problema na implementação disso com a semântica genérica tradicional é que os genéricos são usados para representar tipos, não “um grupo de instâncias relacionadas”.  De uma forma bastante inteligente, Sui conseguiu contornar esse problema através de seu  . Neste padrão suportado pelo sistema, eles basicamente disseram, se você quiser um novo grupo de instâncias relacionadas, crie este novo tipo especial que representará o identificador deste grupo.   Padrão de testemunha única  Um grande benefício disso é que a camada de linguagem não precisa mudar de forma alguma, e pode-se apenas usar uma semântica genérica bem conhecida para alcançar esse tipo de segurança.  A maior falha é que um novo tipo (e, portanto, um novo pacote) deve ser implantado toda vez que um novo grupo de coisas relacionadas for criado. Não se pode simplesmente criar um novo Coin<T> dinamicamente sem implantar um novo pacote, por exemplo.   Conclusão  O MoveVM da Sui foi construído de acordo com os padrões dos engenheiros de sistema: uma VM baseada em primitivos de baixo nível conceitualmente simples, aplicados estaticamente.  Infelizmente, simples não significa fácil, e sua insistência em evitar padrões normais de objetos compartilhados faz com que sua camada de aplicação seja bastante complexa e pouco intuitiva para programar.  DeFi é um mundo confuso de objetos compartilhados: pools com grande liquidez que qualquer pessoa pode acessar, protocolos de empréstimo onde qualquer pessoa pode tomar emprestado e emprestar, oráculos que podem ser chamados por qualquer pessoa e a composição e interação de todos esses objetos acontecendo ao mesmo tempo.  Paralelizar esse ecossistema é o Santo Graal dos DLTs, e a tentativa de Sui funciona bem, exceto que empurra muita confusão para a camada de aplicação.  Embora seja verdade que alguns dos problemas poderiam ser potencialmente resolvidos com melhores ferramentas e suporte de linguagem (   ), alguns são irreparáveis sem grandes mudanças na VM (   ). 1 Object Primitive que é muito genérico, 4 Awkward Shared State Programming 2 No Dynamic Dispatch, 3 An Awkward Padrão de caixa de correio

Buy XRD with card or bank transfer via Switchere.

Este áudio é produzido no idioma original da história!

MoveVM de Sui: uma revisão abrangente

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

De fóruns a feeds: como os algoritmos de mídia social moldam a interação digital

O guia completo para uma migração bem-sucedida para a nuvem: estratégias e práticas recomendadas

Quer ganhar um concurso de redação do HackerNoon? Aqui está o que os vencedores do concurso #crypto-api recomendam

Vazamento do prompt do sistema Claude Sonnet 3.5: uma análise forense

De fóruns a feeds: como os algoritmos de mídia social moldam a interação digital

O guia completo para uma migração bem-sucedida para a nuvem: estratégias e práticas recomendadas

Quer ganhar um concurso de redação do HackerNoon? Aqui está o que os vencedores do concurso #crypto-api recomendam

Vazamento do prompt do sistema Claude Sonnet 3.5: uma análise forense

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps