Plataforma Waves divulga planejamento de dApps para 2019

Por: Livecoins

Waves divulga seu Roadmap de dApps para 2019

RIDE é a linguagem de programação nativa dos smart contracts da Waves. Após o lançamento bem-sucedido da funcionalidade básica, agora será concentrado o esforço de reformular o RIDE para ampliá-lo – tornando-o mais poderoso, mais fácil de usar e permitindo que o desenvolvimento acesse novas funcionalidades de blockchain.

Princípios da RIDE

A RIDE é uma linguagem de script blockchain, que permite transações blockchain inteligentes. O resultado da execução é baseado em lógica determinística, realizado usando scripts RIDE e implementado no blockchain. O objetivo da arquitetura da RIDE é criar uma camada de computação nativa na cadeia que seja a mais próxima possível da arquitetura geral de blockchain (sincronização total de dados).

Acreditamos firmemente que o Turing-complete não deve ser essencial para cálculos on-chain no blockchain. A linguagem RIDE em si, é explicitamente não-Turing complete. No entanto, no contexto de seu ambiente de execução (isto é, o blockchain), ele permite essencialmente cálculos Turing-complete que são distribuídos mais de uma transação em blocos consecutivos.

A linguagem RIDE suporta o conceito de taxas fixas: isto é, os mesmos custos computacionais para a execução de qualquer script. Isso resulta na limitação explícita da complexidade dos scripts e na falta de requisitos semelhantes ao gás, como acontece no Ethereum.

Waves e arquitetura RIDE

Antes da introdução da RIDE, o foco da Waves eram Accounts, Tokens e Dados, sendo que Accounts podem contém Tokens e Dados associados a elas.

A introdução inicial da RIDE estendeu a ideia de assinar transações: uma conta padrão exigia uma assinatura válida para qualquer transação de saída para a chave pública da conta em questão. As Smart Accounts permitiram que isso fosse alterado para uma condição personalizada: assinaturas, hashes, timelocks, dados de contas arbitrárias e assim por diante. Para descrever uma condição da Smart Account, uma função RIDE é anotada com @Verifier e retornando um valor booleano que precisa ser enviado ao blockchain.

Assim como as Smart Accounts ampliam o ‘requisito de assinatura válida’ para um ‘Requisito personalizado’ para transações de saída, os Smart Tokens reforçam a ideia de que “Qualquer operação com um token é permitida, desde que as invariáveis sejam seguras” para ‘qualquer operação com um token é permitida, dado que as invariáveis sejam seguras E o token tenha uma condição (que é, novamente, baseada em assinaturas, hashes, timelocks, dados de contas arbitrárias, etc) é satisfatória.’ Para descrever uma condição de Smart Token, um comando em RIDE que remeta um valor booleano precisa ser enviado ao blockchain.

Até agora, os recursos programáveis ​​do blockchain da Waves permaneceram passivos, simplesmente condições sobre transações iniciadas pelo usuário.

Apresentando a RIDE para dApps

Para melhorar esta falha, a RIDE para dApps (aplicativos descentralizados) está sendo introduzida. Isso concede a uma conta, uma maneira de atribuir uma função programável a si mesma. Cada função @Callable é capaz de:

  • Receber pagamentos
  • Alterar o estado da conta
  • Enviar WAVES e tokens de uma conta

Para iniciar uma solicitação, uma nova InvokeScriptTranscation precisa ser adicionada ao blockchain. O remetente paga taxas ao minerador por isso. O remetente pode, opcionalmente, anexar o pagamento em WAVES ou tokens e, na solicitação, o estado do contrato pode ser alterado e o contrato pode efetuar vários pagamentos.

A mecânica atual dos scripts de autorização será preservada sob a função @Verifier da conta. Você pode pensar nisso como uma função ‘admin’ do contrato para proprietário(s). Por padrão, os atributos de um contrato (o próprio contrato, os dados do contrato e os tokens do contrato) são controlados pela chave privada da conta. Isso pode ser alterado para multisig e assim por diante. Se @Verifier for sempre falso, o contrato é selado.

Função padrão (default)

Como experiência, estamos considerando a introdução de outro recurso: a função @Default para um contrato. A ideia aqui é especificar uma função de callback (retorno de chamada) para receber WAVES / tokens. Para que o sistema seja explicitamente não recursivo, a função @Default só pode alterar o estado do contrato.

Melhorias na RIDE

O feedback que recebemos de desenvolvedores e hackathons está relacionado à falta de clareza e imaturidade atual da API da linguagem RIDE. Nós abordaremos isso no próxima atualização.

Primeiro, introduzimos a capacidade de escrever funções não recursivas.

A próxima ponto que abordamos está relacionado à sintaxe de entendimento das utilidades de blockchain / oracles. Como o valor por chave em um oracle / contract pode não estar presente, o tipo de retorno para getInteger, getBoolean, é UNION (Integer / Unit), UNION (Boolean / Unit). Para obter o valor real, a seguinte sintaxe teve que ser usada:

Para melhorar isso, foi introduzida outra maneira de chamar funções (as chamadas esquerda e direita são as mesmas e representam apenas a mudança de sintaxe):

Atualmente, a complexidade de um script é configurada para 2,000, o que é suficiente para verificar até 19 assinaturas e qualquer subconjunto menor de operações, mas para dApps isso não é suficiente. Vamos estender a complexidade máxima em chamar funções para 10k.

A biblioteca padrão será aprimorada na próxima versão. O conjunto atual de funções e primitivos foi introduzido como o mínimo necessário para os scripts de autorização. Com aplicativos descentralizados, isso precisa ser estendido para oferecer suporte a uma ampla gama de funcionalidades comuns, como conversões binárias, aperfeiçoar a eficácia dos strings e assim por diante.

Como parte da extensão da biblioteca padrão RIDE, mais funcionalidades para consultar o estado do blockchain serão adicionadas em breve. Informações detalhadas sobre ativos, saldos, últimos blocos e mineradores serão expostas através de uma API blockchain renovada.

Chaves no armazenamento de conta/contrato são atualmente Strings. Essa é uma limitação útil para DataTransactions, uma vez que fornece legibilidade e facilidade de uso por meio da REST API, mas pode ser ineficiente para o armazenamento de dApp, já que exigirá conversão para frente e para trás se as chaves forem projetadas para serem bytevectors. Forneceremos um recurso para armazenar valores por chaves bytevector.

Testes e IDE

Atualmente, as dicas no IDE são limitadas a funções globais, tipos e campos de transação. Isto não é suficiente para uma experiência de codificação suave, por isso vamos melhorar isso.

A capacidade de testar qualquer código, especialmente smart contracts, é essencial. Tão importante quanto a execução de testes manuais no testnet, uma forma de teste de unidade em sandbox que preserva toda a semântica pode acelerar o desenvolvimento e a depuração, além de fornecer melhor garantia de qualidade. Para ajudar nisso, um framework de teste executando o atual código do node será introduzido.

Aqui está um pequeno exemplo de como este framework será:

Roadmap

A comunidade Waves no Brasil está no Twitter, Telegram e também no Facebook, sendo uma das maiores do mundo.

O artigo Plataforma Waves divulga planejamento de dApps para 2019 foi publicado originalmente em Livecoins.

Você pode gostar...